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

[Mark Smith <[e-mail]>]

Hi Kyle,

On Thu, 11 Apr 2024, 02:11 Kyle Rose, <krose=[e-mail]>
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.
>

If I understand correctly, you're using different internal/ULA or
external/GUA DNS names for the same node?

In that case you're making the first step of destination address selection
between ULA or GUA one performed by human at DNS name choice time, meaning
that the sending host would never have to then make a choice between
preferring ULA over GUA DA (or vice versa) after the DNS resolution is
performed, because the sending host never would receive a DNS result that
includes both a local ULA and GUA AAAA RR.

So how would a MUST prefer local ULA over GUA would have any negative or
any effect at all in your scenario?


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

We could have solved the IPv4 over ULA problem with different and exclusive
IPv6 ULA, GUA and IPv4 DNS names for the same node that humans select too,
however that's of course not practical for non-technical users who don't
understand what IPv4, IPv6, ULAs and GUAs are.

Non-technical users are really who we're trying to provide
automatic/default address selection to, so they can use a single DNS name
for a node that eventually connects via one or more (e.g. MP-QUIC) of the
reachable multiple addresses a node has regardless of if those addresses
are any combination of IPv4, ULA or GUA (or LLA with mDNS).

Regards,
Mark.


> A standard means for changing this configuration setting (e.g., via RA)
> could then be specified later.
>
> Kyle
>
>
> On Wed, Apr 10, 2024 at 11:29 AM Bob Hinden <[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/
>>
>>  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
>>
>> [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] 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]>
>> *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]>
>>
>> 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
>>
>> 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]>
>> 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
>>
>>
>> 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]
>> 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
> --------------------------------------------------------------------
>