Re: RFC6724-bis?

[Ted Lemon <[e-mail]>]

It's entirely valid to have a ULA configured locally that is not reachable
remotely. And it is entirely reasonable for this to happen on a network on
which a ULA is configured that is reachable from the network on which the
more locally-scoped ULA is present.

If you are lucky, you will get an ICMP destination unreachable based on
your source address when a packet sourced from that ULA hits the edge of
the ULA's scope of validity, but I think it's unreasonable to rely on the
network doing this. That's more of a best case scenario, network admin gets
a cookie kind of situation. I think a destination unreachable response is
more likely when the /remote/ ULA is unreachable from the point of origin
of the connection, but I still don't think that we should assume
reachability, because even if the network administrator doesn't get a
cookie in this situation, it's still quite likely that there are many
networks where such a response will not occur.

On Thu, Sep 22, 2022 at 1:47 PM Vasilenko Eduard <
[e-mail]> wrote:

> I hope ULA in public DNS is not pointing to Google or something big. Then
> why is it a problem if ULA is advertised for abcd.efgh.klmno.com?
>
> It is a problem only for this resource. Good luck to them.
>
>
>
> It would not be a problem for another organization till the organization
> would increase precedence for FC/7 above GUA.
>
>
>
> Moreover, it is not a problem for another organization till the
> organization would not activate ULA PIO inside,
>
> Because Rule 5: Prefer matching label would prefer GUA despite ULA and GUA received in the DNS.
>
> If no PIO – nothing to match for the source even if FC/7 is already the highest precedence.
>
>
>
> And only if the organization would activate ULA PIO, change FC/7 preference above GUA, and somebody requests abcd.efgh.klmno.com– then would be a problem.
>
> It looks pretty artificial situation.
>
>
>
> Then TCP would not receive ACK. In 300ms (old style HYv1) host would
> switch to IPv4.
>
> HYv2 is faster (50ms) but supported only by Apple.
>
>
>
> Ed/
>
> *From:* David Farmer [mailto:farmer=[e-mail]]
> *Sent:* Thursday, September 22, 2022 8:21 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* 6man WG <[e-mail]>; Ted Lemon <[e-mail]>
> *Subject:* Re: RFC6724-bis?
>
>
>
> Experience has shown us that despite recommendations to the contrary, ULAs
> are in the Public DNS, how much is questionable, but it exists nonetheless.
>
>
>
> Further, using the converse to the argument that address collisions are a
> very low probability event, if ULA prefixes are randomly selected, as
> recommended in RFC 4193; therefore, any such randomly selected ULA prefix
> learned from the DNS is going to have a very high probability that it is
> unreachable. This is why, we shouldn’t prefer ULA address unless there is
> knowledge the ULA prefix is actually locally connected.
>
>
>
> It’s worth repeating, unless a ULA prefix is know to be locally connected,
> there is a very high probability that any connections to it will simply
> fail.
>
>
>
> Now I have some related questions, is this connection failure going to
> result in a full TCP timeout or happy eyeballs timer expiring? Or, will an
> ICMP destination unreachable or other ICMP message shortcut the TCP timeout
> or the happy eyeballs timer? Will most CPEs on the market generate an ICMP
> destination unreachable, an ICMP administratively disallowed, or simply
> just forward the packet to the upstream ISP using the default route? Would
> most ISPs generate an ICMP destination unreachable for the ULA in this
> case? Finally, even if the ISP’s router generates the ICMP destination
> unreachable, in most cases, I don’t believe the ISP will have a route back
> to the originating ULA address anyway.
>
>
>
> So, I think we are probably better off with SA/DA selection not preferring
> ULA unless the prefix is know to be local.  This is the best guess.
>
>
>
> Thanks.
>
>
>
> On Thu, Sep 22, 2022 at 11:05 Vasilenko Eduard <vasilenko.eduard=
> [e-mail]> wrote:
>
> I hope DNS advertising ULA is not foreign. Problem solved.
>
> If the organization is using many ULA prefixes – they should be
> distributed everywhere,
>
> Or DNS should announce different views for different company regions.
>
>
>
> You are looking for the solution for the configuration inconsistency: DNS
> has announced something but routing is not available.
>
> Ed/
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Thursday, September 22, 2022 6:54 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* Mark Smith <[e-mail]>; 6man WG <[e-mail]>
> *Subject:* Re: RFC6724-bis?
>
>
>
> If I have a GUA and no ULA, and I get a ULA, I'm going to guess that I
> should use the GUA because I have no choice. If I have a GUA and a ULA, and
> I see a foreign ULA, longest match will choose the ULA, not the GUA, but
> there is no guarantee that the ULA is reachable from the foreign ULA. So
> no, longest match isn't actually going to reliably guess right here.
> Practically speaking, in this case using the GUA is always better, because
> even if my ULA happens to be reachable from the device with the foreign
> ULA, the GUA will still also work.
>
>
>
> On Thu, Sep 22, 2022 at 11:50 AM Vasilenko Eduard <
> [e-mail]> wrote:
>
> The longest match helps to choose what is local
>
> It is rule 8 in RFC 6724.
>
> Already works.
>
> Ed/
>
> *From:* ipv6 [mailto:[e-mail]] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, September 22, 2022 6:35 PM
> *To:* Mark Smith <[e-mail]>
> *Cc:* 6man WG <[e-mail]>
> *Subject:* Re: RFC6724-bis?
>
>
>
> Still, a local ULA can be presumed reachable, whereas a ULA that is not
> configured locally may or may not be reachable. Ideally we want to try the
> thing that will work first. And we’ve actually seen non-local ULAs fail in
> the wild. So while doing happy eyeballs is a great way to avoid failing
> when your best guess is wrong, making better guesses is still good.
>
>
>
> Op do 22 sep. 2022 om 11:30 schreef Mark Smith <[e-mail]>
>
>
>
> On Thu, 22 Sept 2022, 20:38 Ted Lemon, <[e-mail]> wrote:
>
> Wouldn’t increasing the ULA priority have the problem that we’d get
> longest match wins on alien ULAs though?  I think that was why the “add
> local ULAs to the table” rule was originally proposed.
>
>
>
> Why is do people think the static default DA/SA selection will always
> accurately choose the best outcome for a dynamic network?
>
>
>
> The set of answers from DA/SA selection are supposed to be tested until
> one of them succeeds.
>
>
>
> A ULA response in a DNS RR should be the best answer most of the time,
> however sometimes the alternative GUA will be better and be successful.
>
>
>
> That is, try the ULA destination, and if that fails, try the GUA DA, when
> both are provided in a DNS response.
>
>
>
> A static algorithm like default DA/SA selection is sometimes going to be
> wrong when being applied to a dynamic situation.
>
>
>
> Regards,
>
> Mark.
>
>
>
>
>
> Local ULAs might also be discovered through mDNS, which is I pretty much
> ubiquitous on home networks.
>
>
>
> Op do 22 sep. 2022 om 01:25 schreef Brian E Carpenter <
> [e-mail]>
>
> I agree with Bob that a stand-alone draft (Updates: 6724) is probably
> a simpler approach than re-opening the whole RFC to comments.
>
> Apart from that, the proto-draft says:
>
>     An implementation MUST automatically add additional site-specific rows
>     to the default table based on its configured addresses, such as for
>     Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
>     for instance (see Sections 10.6 and 10.7 for examples).
>
> That doesn't really compute, because 6to4 is pretty much ancient history.
> If we make a change of this kind, I think it should be specific to ULAs.
> And if we want to make the section 10.6 behaviour mandatory, I think we'd
> want the wording to be precise (with an explicit description of the
> algorithm the kernel should use).
>
> We should also, I think, state clearly that the expectation is that ULAs
> will normally be discovered via split-horizon DNS, or some other local
> discovery mechanism (e.g. the one in GRASP [RFC8990]).
>
> The other question is: would it be sufficient to do something much simpler,
> i.e., simply boost the ULA prefix in the default policy table and all
> examples:
>
>       fc00::/7              31    13
>
> Where's the harm in that? It will mean that ULAs are picked by the
> longest match rule when they are present. That won't happen unless
> there *are* ULAs, so it has precisely zero impact on sites that don't
> use them.
>
> It does no harm to add higher precedence for locally defined ULAs, but
> I am not convinced it's useful either, in the normal case.
>
> The proto-draft also says:
>
>     This behavior is required for proper functioning of ULA addressing,
>     thus preserving the preference of IPv6 over legacy IPv4 in dual stacked
>     environments as detailed in draft-v6ops-ula. Additionally, requiring
>     local site-specific addressing entry into all nodes preference list
>     further scopes the network communication to local and remote per the
>     respective addressing blocks and creates a more consistent operational
>     model and user experience.
>
> I agree with the statement, but it would sit more naturally in a
> stand-alone update than as a patch on RFC6724.
>
> Regards
>     Brian
>
> On 21-Sep-22 20:47, Nick Buraglio wrote:
> > I've gotten some feedback that the diff is hard to read because of the
> > formatting, so here is a link to the proposal. Please bear in mind
> > that this is *very* crude and was meant to simply track the idea.
> > https://github.com/buraglio/ietf-draft-buraglio-rfc6724-update
> >
> > ----
> > nb
> >
> > On Wed, Sep 21, 2022 at 10:29 AM Nick Buraglio <[e-mail]> wrote:
> >>
> >> Totally agree - this is just a starting point. I am happy to work on
> >> whatever the group feels is the right approach and what we feel will
> >> reach consensus.
> >>
> >> ----
> >> nb
> >>
> >> On Wed, Sep 21, 2022 at 10:25 AM Tim Chown <[e-mail]> wrote:
> >>>
> >>> Thanks Nick.
> >>>
> >>> I think the aim here is to see if the WG can get consensus on an
> approach to address the problem, and document that for consideration for WG
> adoption.  Nick has diffs below to 6724, but it could be a short standalone
> document the updates 6724.
> >>>
> >>> Tim
> >>>
> >>>> On 21 Sep 2022, at 09:02, Nick Buraglio <[e-mail]> wrote:
> >>>>
> >>>> The changes that I had proposed in my github repo are below, these are
> >>>> just a starting point, I welcome any and all input.
> >>>>
> >>>>
> >>>>
> >>>> @@ -12,7 +12,7 @@ ISSN: 2070-1721
> >>>>        A. Matsumoto
> >>>>
> >>>>
> >>>>      Default Address Selection for Internet Protocol Version 6 (IPv6)
> >>>> -
> >>>> +                ietf-draft-buraglio-rfc6724-update.txt
> >>>> Abstract
> >>>>
> >>>>     This document describes two algorithms, one for source address
> >>>> @@ -347,14 +347,14 @@ RFC 6724           Default Address Selection for
> >>>> IPv6     September 2012
> >>>>        fec0::/10              1    11
> >>>>        3ffe::/16              1    12
> >>>>        fec0::/10              1    11
> >>>>        3ffe::/16              1    12
> >>>>
> >>>> -   An implementation MAY automatically add additional site-specific
> rows
> >>>> +   An implementation MUST automatically add additional site-specific
> rows
> >>>>     to the default table based on its configured addresses, such as
> for
> >>>>     Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056]
> addresses,
> >>>>     for instance (see Sections 10.6 and 10.7 for examples).  Any such
> >>>>     rows automatically added by the implementation as a result of
> address
> >>>>     acquisition MUST NOT override a row for the same prefix configured
> >>>>     via other means.  That is, rows can be added but never updated
> >>>> -   automatically.  An implementation SHOULD provide a means (the
> >>>> +   automatically.  An implementation MUST provide a means (the
> >>>>     Automatic Row Additions flag) for an administrator to disable
> >>>>     automatic row additions.
> >>>>
> >>>> @@ -363,7 +363,15 @@ RFC 6724           Default Address Selection for
> >>>> IPv6     September 2012
> >>>>     addresses, 6to4 source addresses with 6to4 destination addresses,
> >>>>     etc.  Another effect of the default policy table is to prefer
> >>>>     communication using IPv6 addresses to communication using IPv4
> >>>> -   addresses, if matching source addresses are available.
> >>>> +   addresses, if matching source addresses are available.
> >>>> +
> >>>> +   This behavior is required for proper functioning of ULA
> addressing,
> >>>> +   thus preserving the preference of IPv6 over legacy IPv4 in dual
> stacked
> >>>> +   environments as detailed in draft-v6ops-ula. Additionally,
> requiring
> >>>> +   local site-specific addressing entry into all nodes preference
> list
> >>>> +   further scopes the network communication to local and remote per
> the
> >>>> +   respective addressing blocks and creates a more consistent
> operational
> >>>> +   model and user experience.
> >>>>
> >>>>     Policy table entries for address prefixes that are not of global
> >>>>     scope MAY be qualified with an optional zone index.  If so, a
> prefix
> >>>> @@ -1541,7 +1549,7 @@ RFC 6724           Default Address Selection for
> >>>> IPv6     September 2012
> >>>>                     C., and M. Azinger, "IANA-Reserved IPv4 Prefix for
> >>>>                     Shared Address Space", BCP 153, RFC 6598, April
> 2012.
> >>>>
> >>>> -
> >>>> +
> >>>>
> >>>>
> >>>>
> >>>> @@ -1775,6 +1783,9 @@ Authors' Addresses
> >>>>
> >>>>
> >>>> ----
> >>>> nb
> >>>>
> >>>> On Tue, Sep 20, 2022 at 6:06 PM Tim Chown <[e-mail]> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> As an author of RFC6724 I’ve had the discussions about a possible
> update of RFC6724 brought to my attention.
> >>>>>
> >>>>> An example thread over on v6ops is
> https://mailarchive.ietf.org/arch/msg/v6ops/W6HjHc11JX364soq3t3gFMHSawE/,
> but there are others.
> >>>>>
> >>>>> Nick Buraglio has documented the problem in
> draft-ietf-v6ops-ula-00.  The short of it is that RFC1918 IPv4 addresses
> may be preferred to IPv6 ULAs in certain circumstances, which I would agree
> is not desired behaviour.
> >>>>>
> >>>>> There are a few ways we might look to address this.  There is a
> proposal from Nick (not yet published outside a git repo) to address it by
> changing wording in section 2.1, with a couple of MAYs becoming MUSTs, and
> adding an extra explaining paragraph.  This basically firms up the
> requirement to follow 6.10 on adding an extra precedence line for local ULA
> prefix(es).
> >>>>>
> >>>>> Now, that may or may not be the preferred solution of the WG, but I
> think there’s a few questions to consider:
> >>>>>
> >>>>> 1. Is there agreement we should address the problem?  I’d assume so
> because Nick's problem draft was adopted by v6ops.
> >>>>>
> >>>>> 2. If so, is 6man the place to do it?  I think it has to be.
> RFC6724 was born here.
> >>>>>
> >>>>> 3. How do we determine the best solution to the problem?  I suspect
> there are nuances in play that will make a one size fit all ’simple’ fix
> tricky, but I look forward to the discussion.  Nick has one proposal that
> counts to a couple of word changes and an extra paragraph, which I’d
> encourage him to share here, but there are other approaches proposed on
> v6ops.  I think either way, it will require some update to or for RFC6724.
> >>>>>
> >>>>> 4. Does this work warrant a full -bis or would a separate RFC that
> updates 6724 be better?  A separate Updating draft might better highlight
> the issue to implementors.  But then RFC6724 is now ten years old, and
> RFC3484 which it replaced was nine years before that.
> >>>>>
> >>>>> 5. If we choose to open up a full -bis, are there any other worms in
> this can?  I have a feeling also here I know the likely answer….
> >>>>>
> >>>>> Anyway, over to the WG… thoughts?
> >>>>>
> >>>>> Tim
> >>>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --
>
> ===============================================
> David Farmer               Email:[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
> ===============================================
>