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

[Ted Lemon <[e-mail]>]

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] <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>> 
>>> 
>>> *Attachments:*
>>>  • signature.asc
>>