Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

[Brian E Carpenter <[e-mail]>]

On 11-Apr-24 04:10, Kyle Rose wrote:
> I am still in favor of advancing this document to publication. Preferably ASAP.
> 
> I am not in favor of hardening the language for inserting known-local prefixes into the policy table to "MUST". The need for this is not universal:
> 
>   * At my sites I am fine with preferring GUA->GUA over ULA->ULA, in large part because I don't have any names that map to both types of address.

But that isn't universally true. I think we want a default that covers the most probable case, and of course flexibility for other cases. So

All implementations MUST support inserting known-local prefixes.
This feature MUST be configurable on or off.
This feature SHOULD be configured on by default.

The last point is IMHO the normal case; why would you configure ULAs if you don't want to use them? But certainly there is room for disagreement on that point, as Kyle indicates.

> 
>   * I regard seeing or attempting to use unreachable ULA (e.g., discovered in global DNS or found in other configuration) as a configuration error that should be resolved by fixing the source of the unreachable addresses.

Yes, but that says nothing about whether GUA->GUA or ULA->ULA is preferred.

> 
> I would actually be in favor of*softening*the normative language to"MAY",or to add an opt-in mechanism via "SHOULD, if configured to do so, enable ..."as the need for policy table updates is entirely a function of how a particular network is administered. I have no need for that functionality, and would rather not deal with the complexity it might introduce when all I really want out of this entire effort is preferring ULA->ULA over IPv4->IPv4. A standard means for changing this configuration setting (e.g., via RA) could then be specified later.

No, we shouldn't leave anything we know about today for "later". Tomorrow never comes.

    Brian

> 
> Kyle
> 
> 
> On Wed, Apr 10, 2024 at 11:29 AM Bob Hinden <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Given the number of changes since the first w.g. last call, the chairs, in consultation with the authors, are staring a second 6MAN working group last call for this document.
> 
>     This email starts a second two week 6MAN Working Group Last Call on advancing "Preference for IPv6 ULAs over IPv4 addresses in RFC6724" document
> 
>     https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/ <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/>
> 
>       as a Standards Track document.
> 
>     A summary of changes since the -06 version is below.   A good diff to review is:
> 
>     https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-08&url2=draft-ietf-6man-rfc6724-update-06&difftype=--html <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-08&url2=draft-ietf-6man-rfc6724-update-06&difftype=--html>
> 
>     [New draft on left due to line length problem with old draft]
> 
>     Substantive comments and statements of support for publishing this document should be directed to the [e-mail] <mailto:[e-mail]> mailing list. Editorial suggestions can be sent to the authors.  This last call will end on 24 April 2024 23:59 UTC.
> 
>     Also, one issue the authors would like feedback on is if the requirement is a SHOULD or MUST for inserting known-local ULA prefixes into their policy table with a precedence above both GUAs and IPv4, while leaving all other general ULAs at a lower precedence.  It is a SHOULD in the -08 draft, but there has been support for a MUST in the discussion.
> 
>     Bob, Jen, Ole
>     6MAN chairs
> 
> 
>>     Begin forwarded message:
>>
>>     *From: *Tim Chown <Tim.Chown=[e-mail] <mailto:[e-mail]>>
>>     *Subject: **Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-08.txt*
>>     *Date: *April 9, 2024 at 7:47:57 AM PDT
>>     *To: *IPv6 List <[e-mail] <mailto:[e-mail]>>
>>
>>     Hi,
>>
>>     Actually it works better I notice with 08 on the left and 06 on the right, as -06 has the broken formatting, so please check the diff from -06 to the current -08 using:
>>
>>     https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-08&url2=draft-ietf-6man-rfc6724-update-06&difftype=--html <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-08&url2=draft-ietf-6man-rfc6724-update-06&difftype=--html>
>>
>>     The changes are largely around making the MAY insert local entries into a SHOULD insert known-locals, with a little more text on how we’d determine those.
>>
>>     Tim
>>
>>>     On 9 Apr 2024, at 15:13, Nick Buraglio <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>     We have published -08 of the rfc6724 update, this fixes some
>>>     formatting and other typographical oversights
>>>     The following sections address comments from the lis (difft from -06
>>>     to -08 is the most useful comparison):
>>>     https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-06&url2=draft-ietf-6man-rfc6724-update-08&difftype=--html <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-06&url2=draft-ietf-6man-rfc6724-update-08&difftype=--html>
>>>
>>>
>>>     Brief overview of the changes from -06:
>>>
>>>     Section 2:
>>>     Add terminology section and define known-local
>>>
>>>     Section 3:
>>>     Add section on elevating
>>>     upgrades the requirement in RFC 6724 for nodes to insert a higher
>>>     precedence entry in the policy table for observed ULA prefixes that
>>>     are known to be local, referred to in this document as "known-local"
>>>     ULAs, from a MAYto a SHOULD.
>>>
>>>     Section 4:
>>>     Changes the 6to4 prefix deprecation to match Teredo, adds further
>>>     clarity and reference to RFC6724 section 10.7
>>>
>>>     Section 5:
>>>     Add text to upgrade the requirement to automatically insert
>>>     known-local ULAs into a node's policy table from a MAY to a SHOULD.
>>>
>>>     Section 5.3
>>>     Further define insertion and removal parameters and requirements for
>>>     known-local ULA prefixes into table and associated values and label
>>>
>>>     Section 7.2:
>>>     Further clarify GUA-GUA preferred over ULA-ULA details
>>>
>>>     Section 7.3:
>>>     Further clarify ULA-ULA preferred over IPv4-IPv4 details
>>>
>>>     Section 8:
>>>     Housekeeping and formatting changes
>>>
>>>     Section 9.2:
>>>     Describe the new known-local interaction and how it addresses issues
>>>     with ULAs in global DNS
>>>
>>>
>>>
>>>     Further copy edit and housekeeping.
>>>
>>>     Thanks!
>>>
>>>     --------------------------------------------------------------------
>>>     IETF IPv6 working group mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>>     --------------------------------------------------------------------
>>
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>     --------------------------------------------------------------------
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------