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

[Mark Smith <[e-mail]>]

On Tue, 19 Mar 2024, 05:11 Brian E Carpenter, <[e-mail]>
wrote:

> 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...
>

You're right I've confused the threads, however if nearly everything I
thought I was writing about rfc6724-update also applies validly to a
rfc6296-bis discussion, I think that says it's a single problem space and a
solution or related solutions need to cover the single problem space.

Regards,
Mark.



> >
> > 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>
> >      >
> --------------------------------------------------------------------
> >
>