Re: RFC6724-bis?

[Ted Lemon <[e-mail]>]

Based on what data is this the uncommon case?

Op do 22 sep. 2022 om 19:59 schreef Mark Smith <[e-mail]>

>
>
> On Fri, 23 Sept 2022, 02:51 David Farmer, <farmer=[e-mail]>
> 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=
>> [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
>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>>       Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------
>