[IPv6]Re: [Snac] Re: Re: I-D Action: draft-ietf-6man-rfc6724-update-21.txt

[Timothy Winters <[e-mail]>]

Hi Nick,

Thanks for the rapid response, this addresses all my comments.

~Tim

On Thu, Jul 24, 2025 at 1:03 PM Nick Buraglio <[e-mail]>
wrote:

> I believe I have addressed the comments in the INTDIR review as well as
> the issues that Lorenzo has brought up. A diff of the changes can be found
> here:
> https://github.com/buraglio/draft-buraglio-6man-rfc6724-update/pull/55/files
>
> If we are happy with this, I will merge the changes and we can submit
> (hopefully) the final version for release to the RFC Editor. If there are
> further changes requested or if I have missed something let me know and I
> will get it addressed prior to the submission.
>
> nb
>
> On Tue, Jul 22, 2025 at 3:31 PM Lorenzo Colitti <[e-mail]>
> wrote:
>
>> Nick,
>>
>> Thanks for making the changes.
>>
>> I reviewed the whole document again and have the suggestions below. They
>> are all minor and likely optional, with the exception of the "are
>> deprecated" -> "become invalid" change which I think is important, but
>> perhaps something that should be discussed in the WG.
>>
>> Cheers,
>> Lorenzo
>>
>> Abstract:
>> OLD:
>> It further clarifies the unconditional requirement for implementing Rule
>> 5.5 of RFC 6724
>>
>> NEW:
>> It makes introduces a requirement to implement Rule 5.5 of RFC 6724
>>
>> ====
>>
>> Section 1.1:
>> OLD:
>> This document therefore introduces two changes to RFC6724 to support a
>> node implementing elevated or differential precedence for known-local ULAs
>>
>> NEW:
>> This document therefore introduces two changes to RFC6724 to require that
>> nores implement elevated or differential precedence for known-local ULAs
>>
>> ====
>>
>> Section 2
>> OLD:
>> Known-local ULA: A ULA prefix that an individual organization/site has
>> determined to be local to a given node/network/administrative domain
>>
>> NEW:
>> Known-local ULA: A ULA prefix that a node has determined to be local to a
>> given node/network/administrative domain
>>
>> (Rationale: the thing that needs to "know" whether the ULA is local or
>> not is the host.)
>>
>> ====
>>
>> Section 3
>> OLD:
>> second to change Rule 5.5 adjusts precedence of addresses in a prefix
>> advertised by the next-hop to a requirement
>>
>> NEW:
>> second to change Rule 5.5, which adjusts precedence of addresses in a
>> prefix advertised by the next-hop, to a requirement
>>
>> ====
>>
>> Section 3.1
>> OLD:
>> $known_local/48       45    14 (**)
>>
>> NEW:
>> $known_local/4x       45    14 (**)
>>
>> OLD:
>> (**) $known_local = the ULA Known-Local /48 IPv6 prefix(es) (if any)
>>
>> NEW:
>> (**) $known_local = the ULA Known-Local IPv6 prefix(es), with lengths
>> between /40 and /48 (if any)
>>
>> (Rationale: the document is very clear that known locals are not exactly
>> /48 but are between /40 and /48)
>>
>> ===
>>
>> Section 3.3
>> OLD:
>> These known-local ULA prefixes are inferred from ULA addresses assigned
>> to interfaces or learned from Prefix Information Options (PIOs) in Router
>> Advertisements (RAs) [RFC4861] received on any interface regardless of how
>> the PIO flags are set. Further, they are learned from Route Information
>> Options (RIOs) in RAs received on any interface by Type C hosts that
>> process RIOs, as defined in [RFC4191].
>>
>> NEW:
>> These known-local ULA prefixes are inferred from ULA addresses assigned
>> to interfaces or learned from Prefix Information Options (PIOs) in Router
>> Advertisements (RAs) [RFC4861] received, regardless of how the PIO flags
>> are set. Further, they are learned from Route Information Options (RIOs) in
>> RAs received by Type C hosts that process RIOs, as defined in [RFC4191].
>>
>> (Rationale: saying that the RIO can be received "on any interface" could
>> suggest that hosts connected to multiple provisioning domains would merge
>> known-local ULAs from different interfaces.)
>>
>> OLD:
>> when the announced RIOs or PIOs are deprecated
>>
>> NEW:
>> when the announced RIOs or PIOs become invalid
>>
>> (Rationale: a local ULA is still local even if it's deprecated.)
>>
>> ===
>>
>> Section 5.4
>> OLD:
>> Known-local ULA-ULA preferred over IPv4-IPv4
>>
>> NEW:
>> Known-local ULA-known-local ULA preferred over IPv4-IPv4
>>
>> (Rationale: the last sentence in the section makes it clear that this is
>> for pairs where both source ULA and destination ULA are local.)
>>
>> ===
>>
>> Section 5.5
>> OLD:
>> An IPv6 ULA address will only be preferred over an IPv4 address
>>
>> NEW:
>> An IPv6 ULA source address will only be preferred over an IPv4 address
>>
>> ===
>>
>> Section 7.2
>> OLD:
>> are not recommended being installed in the global DNS
>>
>> NEW:
>> not recommended to be installed in the global DNS
>>
>> (Rationale: the text should match what RFC 4193 actually says)
>>
>> On Fri, Jul 4, 2025 at 6:27 PM Ted Lemon <[e-mail]> wrote:
>>
>>> LGTM. Thanks, Nick!
>>>
>>> On Fri, Jul 4, 2025, at 6:06 PM, Nick Buraglio wrote:
>>>
>>> Before I submit a new draft, can folks take a look at the diff to
>>> confirm that these are what we want? The changes are in section 3.3 and
>>> address:
>>>
>>> Erroneous re-import of rule 6 (now removed)
>>> SNAC generated GUA changed to ULA in rule 5 per Ted.
>>>
>>>
>>> https://github.com/buraglio/draft-buraglio-6man-rfc6724-update/pull/52/files
>>>
>>> On Wed, Jul 2, 2025 at 2:41 PM Ted Lemon <[e-mail]> wrote:
>>>
>>>
>>> A network can have more than one non-SNAC subnet. On such a network, if
>>> a device on an infrastructure link adjacent to the SNAC link treats the
>>> SNAC-advertised ULA prefix as known-local, it might attempt to use it as a
>>> source address when communicating with a device on a non-SNAC-adjacent
>>> link. This would fail because the SNAC ULA prefix can’t be routed. Hence
>>> the prohibition on using SNAC router RAs when identifying ULAs as known
>>> local.
>>>
>>> Regarding ULAs and PD on the local link, it is expected that CE routers
>>> will generate a ULA prefix, and that they will delegate /64s from it. These
>>> /can/ and /should/ be treated as known-local. But since  /64s from this
>>> prefix will be advertised on non-SNAC links in the home network, the ULA
>>> /64 prefix allocated to the SNAC router should also be treated as
>>> known-local, even if the SNAC router’s RA is ignored for the purposes of
>>> deciding which ULA prefixes are known-local.
>>>
>>> On Wed, Jul 2, 2025, at 8:53 PM, Michael Richardson wrote:
>>>
>>>
>>> Ted Lemon <[e-mail]> wrote:
>>>     > The fix is to just change SNAC-generated GUAs to SNAC-generated
>>> ULAs.
>>>
>>> Glad to know I didn't get something wrong here.
>>> I was like... wait... did I mis-understand SNAC in some fundamental way?
>>> Yes, change it to "SNAC-generated ULAs"
>>>
>>> But, I'm still surprised any text needs to mention SNAC and the S-bit.
>>>
>>>     > That said, it's also true that if a SNAC router gets a ULA from a
>>> DHCP
>>>     > prefix delegation, that _is_ provided by infrastructure, and
>>> _could_ be
>>>     > treated as known-local. Hopefully infrastructure is advertising a
>>>     > prefix in infrastructure-provided RAs that covers the delegated
>>> /64. I
>>>     > don't think we can really solve this problem in some other way,
>>> but in
>>>     > practice I think it's unlikely to be a problem.
>>>
>>> A home router could generate a RIO for the entire (GUA) prefix delegated
>>> by
>>> the ISP.   I've never seen that done.  More and more pubs in Ottawa seem
>>> to
>>> have v6 with PD.  They likely don't have a stub network (yet).
>>>
>>> I think that source address selection works fine when going to a GUA
>>> prefix
>>> not on the infrastructure link.   The rules pick the GUA, and assuming
>>> the
>>> home router is doing the right hair-pin routing to get packets there,
>>> there
>>> should be no issue.
>>>
>>> Now, you actually wrote, above, that the SNAC router gets a **ULA** from
>>> DHCPv6.
>>> This would be in the ULA that the home router has randomly allocated to
>>> be
>>> local. (as per 7804, etc.)
>>>
>>> But, then you wrote "delegated /64", and I was confused, because the ISP
>>> didn't delegate a ULA, but you mean the /64 that the home router
>>> delegated to
>>> the SNAC Stub Router.
>>>
>>> My understanding is that the overall effect of all this work is that
>>> we'll
>>> mark the entire /48 as local and higher priority than NAT44, so
>>> everything
>>> should just work even if there were v4-addresses for the STUB network,
>>> which
>>> there ought not to be.  Again, I'm not sure why we had to exclude S-bit
>>> RAs.
>>> If a host (ignorant of these changes) picks its GUA to talk to the SNAC
>>> delegated ULA, then that also ought to work.
>>>
>>> --
>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
>>> consulting )
>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>> *Attachments:*
>>>
>>>    - signature.asc
>>>
>>>
>>>
>>> --
>>> Snac mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>