Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[Brian E Carpenter <[e-mail]>]

Mark,
On 19-Mar-24 01:36, Mark Smith wrote:
> 
> 
> On Mon, 18 Mar 2024, 18:42 Brian E Carpenter, <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 18-Mar-24 21:35, Mark Smith wrote:
>      > On Mon, 18 Mar 2024 at 18:03, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>      >>
>      >> Right. In fact I think we recommend that for the home router use case already. Sorry, I was really trying to figure out a reason why we’d want this, but internal ULA handles the “no renumbering” concern, so that’s not a reason.
>      >>
>      >
>      > ULAs won't solve the renumbering problem after
>      > draft-ietf-6man-rfc6724-update (and doesn't  with RFC 6724).
>      >
>      > Once GUAs are preferred over ULAs by default, then GUAs will
>      > automatically be used when ULAs are available to reach a host, if they
>      > share a single DNS/mDNS name.
>      >
>      > A host could have 2 distinct DNS names, one for the ULA address, and
>      > one for the GUA address, however that makes the first step of
>      > Destination Address selection an unstated and unfriendly one, each and
>      > every time - a human takes the first DA selection step, deciding which
>      > DNS name they use for the host.
>      >
>      > Happy Eyeballs v3 won't solve this problem either, it uses
>      > RFC6724(-update) sort order to choose which IPv6 addresses to attempt
>      > to connect to first, so GUA will be chosen first (and of course Happy
>      > Eyeballs doesn't get supplied with or chooses between 2 DNS names for
>      > the same node.)
> 
>     HE v3 can still be changed. See the discussion a few months ago about
>     get_addr_pairs() for example.
> 
>     https://github.com/becarpenter/getapr/blob/main/ProofOfConcept.md <https://github.com/becarpenter/getapr/blob/main/ProofOfConcept.md>
> 
> 
> I don't think it needs to be charged. It's primary purpose is to deal with reachability problems in the presence of a DNS entry with multiple IPv6 and/or IPv4 addresses.

Sure. But if the multiple DNS entries happen to include both a ULA and a GUA for the same FQDN, HE will give what you consider below to be the wrong answer. (Since I agree with you, my get_addr_pairs() is coded to give the right answer, i.e. prefer ULA-ULA.)

So HE needs at least to have a built-in policy option for this.

> Why not let HE deal with the rarely unreachable ULAs if somebody erroneously puts them in global DNS, or when a ULA much be unreachable for some other reason.

It will. Which is why I think Lorenzo's concern about unreachable ULAs is unnecessary.

> 
> RFC 6724 got 2 things wrong:
> 
> - put ULAs below IPv4
> 
> - put ULAs below GUAs
> 
> RFC6724-update only fixes one of those problems.

That's really for the other thread...

> 
> ULAs are the replacement for site-locals, just without the ambiguity of site-locals.
> 
> Site-locals were preferred over GUAs, due to the scope comparison. ULAs, being the direct replacement for site-locals, should also be preferred over GUAs (not via a scope check, however the outcome should be the same).
> 
> I think anybody who takes the position that the first IPv6 DA returned by getaddrinfo() must work,

Indeed. get_addr_pairs() claims that the first address pair _should_ work, which is a rather different claim.

    Brian


> which is implied by GUAs being preferred over ULAs, is really saying the following:
> 
> - IPv6 hosts should only ever have a single address, because having multiple addresses implies that multiple addresses are needed because there may be reachability problems to act if those addresses.
> 
> - getaddrinfo() only needs to return a single IPv6 address for any and all DNS look ups, making DA/SA selection much simpler.
> 
> - Happy Eyeballs only needs to attempt to connect to a single IPv6 address and a single IPv4 address, also making HE simpler.
> 
> - Multipath transport layer protocols have no value since there would only be a single IPv6 address to connect to on a host.
> 
> Regards,
> Mark.
> 
> 
> 
>           Brian
> 
>      >
>      > Regards,
>      > Mark.
>      >
>      >> Op ma 18 mrt 2024 om 16:37 schreef Lorenzo Colitti <[e-mail] <mailto:[e-mail]>>
>      >>>
>      >>> On Mon, Mar 18, 2024 at 4:09 PM Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>      >>>>
>      >>>> On Mon, Mar 18, 2024 at 3:53 PM Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
>      >>>>>
>      >>>>> I agree.
>      >>>>> We had 6RENUM WG sometime ago.
>      >>>>> (It's confusing that "RENUM" BOF has no link to 6RENUM in the datatracker)
>      >>>>
>      >>>>
>      >>>> I think we were a bit naive when we did that work. I think if we want renumbering to be usable, we actually need to account for all the configuration data that contains IPv6 addresses, and I don't think we did that. Dynamically regenerating the entire distributed configuration database whenever our prefix changes is very difficult to get right. We need a solution that's on the same level of difficulty as RA, not a giant distributed database problem.
>      >>>
>      >>>
>      >>> A better solution to this problem is to run both ULA and global space. Internal resources and networks can use ULAs and will never need to be renumbered. Client-facing links can additionally have global addresses configured. Those do need to be renumbered when changing ISPs, but no databases need to be updated.
>      >>
>      >> --------------------------------------------------------------------
>      >> IETF IPv6 working group mailing list
>      >> [e-mail] <mailto:[e-mail]>
>      >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>      >> --------------------------------------------------------------------
>      >
>      > --------------------------------------------------------------------
>      > IETF IPv6 working group mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>      > --------------------------------------------------------------------
>