Re: RFC6724-bis?

[Nick Buraglio <[e-mail]>]

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