Re: RFC6724-bis?

[Ted Lemon <[e-mail]>]

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