Re: RFC6724-bis?

On Fri, 23 Sept 2022, 02:51 David Farmer, <farmer=40umn.edu@dmarc.ietf.org>
wrote:

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

You're optimising for the uncommon case.
.

>
> Thanks.
>
> On Thu, Sep 22, 2022 at 11:05 Vasilenko Eduard <vasilenko.eduard=
> 40huawei.com@dmarc.ietf.org> 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:mellon@fugue.com]
>> *Sent:* Thursday, September 22, 2022 6:54 PM
>> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
>> *Cc:* Mark Smith <markzzzsmith@gmail.com>; 6man WG <ipv6@ietf.org>
>> *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 <
>> vasilenko.eduard@huawei.com> wrote:
>>
>> The longest match helps to choose what is local
>>
>> It is rule 8 in RFC 6724.
>>
>> Already works.
>>
>> Ed/
>>
>> *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Ted Lemon
>> *Sent:* Thursday, September 22, 2022 6:35 PM
>> *To:* Mark Smith <markzzzsmith@gmail.com>
>> *Cc:* 6man WG <ipv6@ietf.org>
>> *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 <markzzzsmith@gmail.com>
>>
>>
>>
>> On Thu, 22 Sept 2022, 20:38 Ted Lemon, <mellon@fugue.com> 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 <
>> brian.e.carpenter@gmail.com>
>>
>> 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 <buraglio@es.net> 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 <tjc.ietf@gmail.com> 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 <buraglio@es.net> 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 <tjc.ietf@gmail.com>
>> 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
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>