Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erik Kline's Transport Comment 2 #4514

Closed
LPardue opened this issue Jan 6, 2021 · 5 comments
Closed

Erik Kline's Transport Comment 2 #4514

LPardue opened this issue Jan 6, 2021 · 5 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus. iesg An issue raised during IESG review.

Comments

@LPardue
Copy link
Member

LPardue commented Jan 6, 2021

Erik Kline said:

[ section 9.6.3 ]

  • Entirely optional, but I wonder if it's worth noting that in certain
    situations, for example an IPv6-only client and IPv4-only server, the
    client might be required to evaluate use of an alternate address family
    address if, for example, some transition mechanism (a la NAT64) was in
    use.
@LPardue LPardue added -transport iesg An issue raised during IESG review. labels Jan 6, 2021
@LPardue LPardue added this to the transport-iesg milestone Jan 6, 2021
@martinthomson
Copy link
Member

My personal preference is to avoid the transition technology quagmire. However, that is partly because I'm not very well versed in it. I would also prefer if servers offer v6 for v6-only clients.

If someone were able to offer text I might be OK with that. As we do send IP literals in the protocol, it isn't crazy to acknowledge the need to deal with that.

As it is, I think that we're OK without reference to transition technologies.

@martinthomson martinthomson added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Jan 6, 2021
@ianswett
Copy link
Contributor

ianswett commented Jan 6, 2021

I think I'd prefer to not add any text on this one.

@ekline
Copy link

ekline commented Jan 7, 2021

Fair enough!

@MikeBishop
Copy link
Contributor

Yeah, presumably a v6-only client using a transition technology has some mechanism to deal with v4 addresses anyway, whether that's a way to map them to a v6 address or simply failing to transition.

@ekline
Copy link

ekline commented Jan 10, 2021

Well, sometimes client implementations might be aware of the transition mechanism. This can happen when, for example, DNS64 is used and the IPv6 address received is a NAT64 address that makes things "just work" for the IPv6-only client contacting an IPv4-only server.

If you wanted some sample text, I might suggest something along these lines:

Note that if the only non-zero address available is from a different address family than the endpoint implementation
can make reasonable use of (e.g., and IPv6-only client receives only an IPv4 address), the implementation may
need to coordinate with any address family transition technologies in use. The precise mechanisms by which this
can be done vary by transition technology and are out of scope of this document.

This shouldn't cause any unnecessary Informative references to be added.

Again: only if you want to note it so that implementors can bear it in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus. iesg An issue raised during IESG review.
Projects
None yet
Development

No branches or pull requests

5 participants