Re: RFC6724-bis?

[Ted Lemon <[e-mail]>]

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.

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