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

[Ted Lemon <[e-mail]>]

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