Re: Network merge [Re: RFC6724-bis?]

[Nick Buraglio <[e-mail]>]

----
nb

On Sat, Sep 24, 2022 at 3:38 PM Brian E Carpenter
<[e-mail]> wrote:
>
> Just focusing on the corner case:
>
> On 25-Sep-22 07:47, Nick Buraglio wrote:
> >
> >
> > On Fri, Sep 23, 2022 at 8:12 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>
> ...
> >     But there is still a corner case: if two networks using ULAs are
> >     merged, and the necessary routes are installed, the individual
> >     hosts would still need manual intervention. A high precedence for
> >     fc00::/7 would avoid that.
> >
> >
> > At least to me at this time it seems that although this use case is real, it should just be noted as an edge case that is out of scope.
>
> I think we need to say a little more, since the network merge case was one of the original motivations for ULAs in the first place (otherwise, statistical uniqueness has no real value).

Fair point.

>
> At least, we need to say that in the case of a network merge, human intervention to configure ULA precedence will be needed. I still find that unsatisfactory, since the idea was always that unplanned merges might happen (in unmanaged networks, not in enterprise networks). If we decide to leave that unsolved, I think we'll be back to this problem later.

Also a good point.

>
> Now as to how to fix this without a global precedence for ULAs, I am wondering about a PIO with L=0 and A=0 (exactly as recommended in RFC 8028, but for other reasons). If a host sees such a PIO for a ULA prefix, it could serve as a signal that the prefix is to be given a suitable precedence, even though it is not on-link and not used for SLAAC.

This feels like a really good, achievable solution. What I was hoping
to avoid was structural changes that would take forever to implement -
especially given the lackluster track record for existing
implementations involving the GAI file -  I think the PIO option
avoids that.

>
> (Credit where credit is due: Ted Lemon suggested this.)

Indeed, it is a smart idea.

>
>     Brian
>
> > Anything more is changing the conversation to a much larger change. Given the intention of ULA was always centered around /48, it seems right to keep that focus. As always, I’m totally willing to be convinced otherwise, but the two changes I mentioned in my last email feels like the right path.
> >
> >
> >
> >           Brian
> >
> >      >
> >      >>
> >      >> On Fri, Sep 23, 2022 at 6:10 PM David Farmer <farmer=[e-mail] <mailto:[e-mail]>> wrote:
> >      >>>
> >      >>> To be honest, I don't understand the nuances of RFC 6724 well enough to judge what may or may not break by changing the priority for the whole ULA prefix (fc00::/7).
> >      >>>
> >      >>> RFC 6724, section 10.6, states the following;
> >      >>>
> >      >>>     By default, global IPv6 destinations are preferred over
> >      >>>     ULA destinations, since an arbitrary ULA is not necessarily
> >      >>>     reachable:
> >      >>>
> >      >>>    .....
> >      >>>
> >      >>>     Since ULAs are defined to have a /48 site prefix, an implementation
> >      >>>     might choose to add such a row automatically on a machine with a ULA.
> >      >>>
> >      >>> I've been told that implementations that follow the suggestion quoted above don't have the problem we are discussing. Therefore, I think the most conservative change to RFC 6724 is to change the above from a suggestion to a mandatory and automatic feature. This really doesn't change how RFC 6724 operates, and I feel this change is completely consistent with RFC 6724. It's not likely to break anything, it is already part of RFC6724, and there are successful implementations of it.
> >      >>>
> >      >>> Whereas changing the priority for the whole ULA prefix (fc00::/7) seems like a much larger change to me, fraught with much more uncertainty, and I'm much more worried about unintended consequences. It's quite common to fix one bug and create three others. However, if the authors of RFC 6724 are comfortable with changing the priority of the whole ULA prefix (fc00::/7) and essentially eliminating the need for section 10.6. I guess I'd be ok with that.
> >      >>>
> >      >>> Nevertheless, the concern that "arbitrary ULA is not necessarily reachable" stated in RFC 6724 or that I've been calling remote ULAs, still rings true for me, and I need to understand why that isn't a problem if we change the priority of the whole ULA prefix (fc00::/7), as you are suggesting.
> >      >>>
> >      >>> Thanks
> >      >>>
> >      >>> On Fri, Sep 23, 2022 at 7:31 AM Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
> >      >>>>
> >      >>>> Hi David, thanks. But it is not enough for an explanation.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Section 2.2.2 RFC 5200 example is just not relevant to the current situation, it was relevant to RFC 3484.
> >      >>>>
> >      >>>> It is solved by default because the separate label has been attached to ULA in RFC 6724.
> >      >>>>
> >      >>>> Now, IPv4_DA/IPv4_SA would be prioritized above GUA_DA/ULA_SA because of rule 5 (label match).
> >      >>>>
> >      >>>> No problem.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> If you have any other scenario that may affect static ULA prioritization above anything else – please show it.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Why do you believe that address expansion above 2000::/3 would be affected?
> >      >>>>
> >      >>>> If people would continue to use ::/0 as the default and RFC6724 has it in the RC6724 table
> >      >>>>
> >      >>>> Then how the problem could happen?
> >      >>>>
> >      >>>> I do not understand this use case too.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>>> Let’s only fix the problem and not make new problems for the next generation of network engineers and operators.
> >      >>>>
> >      >>>> I claim that the ULA problem is very small. It may be treated as a pure configuration problem. Just add static:
> >      >>>>
> >      >>>>       fc00::/7               45    13
> >      >>>>
> >      >>>> to gai.conf. Hence, the draft in v6ops is enough.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> PS: it does not solve MHMP but it is a problem that possible to separate
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Eduard
> >      >>>>
> >      >>>> From: ipv6 [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of David Farmer
> >      >>>> Sent: Friday, September 23, 2022 2:17 PM
> >      >>>> To: Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>>
> >      >>>> Cc: 6man WG <[e-mail] <mailto:[e-mail]>>
> >      >>>> Subject: Re: RFC6724-bis?
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Please read the first paragraph of RFC6724 section 10.6 and all it’s references very carefully. In particular, read 2.2.2 of RFC 5220.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Your argument contradicts the conclusions of 2.2.2 of RFC 5220. In short, your argument is only true today while we are using 2000::/3 for GUA. When that eventually changes, and it will some day, we would have to yet again rejigger the table.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> RFC 6724 is almost correct, the only thing it got wrong is that the section 10.6 modifications must be mandatory and automatic, and not optional, otherwise ULA is broken and dysfunctional.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Let’s only fix the problem and not make new problems for the next generation of network engineers and operators.
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Thanks
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> On Fri, Sep 23, 2022 at 02:27 Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
> >      >>>>
> >      >>>> I still do not understand why Ted and David care about "remote ULA".
> >      >>>> If this ULA has been delivered to the local host by
> >      >>>> Then it has been done intentionally.
> >      >>>> Such a type of misconfiguration does not make sense to optimize.
> >      >>>> Hence, it is possible to operate FC/7 as a whole, no need to split it for /48s.
> >      >>>>
> >      >>>> Hence, why not install permanent precedence to FC/7 in gai.conf?
> >      >>>> It would not play any role on the host till the local router would deliver ULA PIO.
> >      >>>> And even after this, it would not be used till DNS would show the ULA destination
> >      >>>> Because rule 5 (matching labels) would make GUA_DA/ULA_SA a low priority, GUA/GUA would be chosen.
> >      >>>>
> >      >>>> What is the problem with permanently changed FC/7 precedence even above GUA?
> >      >>>>
> >      >>>> Eduard
> >      >>>> -----Original Message-----
> >      >>>> From: ipv6 [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Brian E Carpenter
> >      >>>> Sent: Friday, September 23, 2022 4:47 AM
> >      >>>> To: Ted Lemon <[e-mail] <mailto:[e-mail]>>; David Farmer <farmer=[e-mail] <mailto:[e-mail]>>
> >      >>>> Cc: 6man WG <[e-mail] <mailto:[e-mail]>>
> >      >>>> Subject: Re: RFC6724-bis?
> >      >>>>
> >      >>>> On 23-Sep-22 12:50, Ted Lemon wrote:
> >      >>>>> Op do 22 sep. 2022 om 20:40 schreef David Farmer <farmer=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >>>>>
> >      >>>>>      I think leaving unknown, most likely remote, ULA at a lower priority and adding the /48 or other known local ULA to the table at a higher priority automatically should help mitigate ULA in the public DNS and the possible response of turning off IPv6.
> >      >>>>>
> >      >>>>>      In someways those that put ULA in the public DNS get what they deserve, I’m just worried about the remote user’s response to the brokenness, causing even more brokenness.
> >      >>>>>
> >      >>>>>
> >      >>>>> Hm, okay. I think we are all actually in agreement then, since I heard Brian admitting earlier that it might be better to dynamically update the table.
> >      >>>>
> >      >>>> Indeed, which was exactly why I wrote gai_wrap.py as a userland proxy for that approach.
> >      >>>>
> >      >>>>      Brian
> >      >>>>
> >      >>>>> I must have misunderstood what you meant by optimizing for the uncommon case—sorry about that!
> >      >>>>>
> >      >>>> --------------------------------------------------------------------
> >      >>>> IETF IPv6 working group mail <https://www.google.com/maps/search/Pv6+working+group+mail?entry=gmail&source=g>ing list
> >      >>>> [e-mail] <mailto:[e-mail]>
> >      >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> >      >>>> --------------------------------------------------------------------
> >      >>>>
> >      >>>> --
> >      >>>>
> >      >>>> ===============================================
> >      >>>> David Farmer Email:[e-mail] <mailto:[e-mail]>
> >      >>>> Networking & Telecommunication Services
> >      >>>> Office of Information Technology
> >      >>>> University of Minnesota
> >      >>>> 2218 University Ave SE        Phone: [phone]
> >      >>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> >      >>>> ===============================================
> >      >>>
> >      >>>
> >      >>>
> >      >>> --
> >      >>> ===============================================
> >      >>> David Farmer Email:[e-mail] <mailto:[e-mail]>
> >      >>> Networking & Telecommunication Services
> >      >>> Office of Information Technology
> >      >>> University of Minnesota
> >      >>> 2218 University Ave SE        Phone: [phone]
> >      >>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> >      >>> ===============================================
> >      >>> --------------------------------------------------------------------
> >      >>> 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>
> >      >> --------------------------------------------------------------------
> >      >
> >      > --------------------------------------------------------------------
> >      > 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>
> >      > --------------------------------------------------------------------
> >
> > --
> > ----
> > nb