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

[Brian Carpenter <[e-mail]>]

Not a problem. The host makes no conclusion about off-link, only the
selection prefix is increased.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)


On Mon, 26 Sep 2022, 20:53 Vasilenko Eduard, <[e-mail]>
wrote:

> > a PIO with L=0 and A=0
> A little problem with the wording in RFC 4861:
> " if the L flag is not set a host MUST NOT conclude that an address
> derived from the prefix is off-link."
> But looks like it is exactly what is assumed below.
> "MUST NOT" is a pretty strong statement. It has justification in the next
> sentence:
> " That is, it MUST NOT update a previous indication that the address is
> on-link."
> Eduard
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Saturday, September 24, 2022 11:39 PM
> To: [e-mail]
> Cc: David Farmer <farmer=[e-mail]>; 6man WG <[e-mail]>;
> Vasilenko Eduard <vasilenko.eduard=[e-mail]>
> Subject: Network merge [Re: RFC6724-bis?]
>
> 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).
>
> 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.
>
> 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.
>
> (Credit where credit is due: Ted Lemon suggested this.)
>
>     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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>