[IPv6]Re: SNAC questions regarding the 6724 update

[Jeremy Duncan <[e-mail]>]

Hi all, it’s been a couple months since this discussion, we seem to be stuck again, and I am at a loss of what would need to be modified in the draft to move this forward regarding SNAC?

Ted, can you help me understand what exactly may be missing? What exactly needs to be specified and where?


-Jeremy


From: Ted Lemon <[e-mail]>
Sent: Monday, November 11, 2024 3:21 PM
To: Nick Buraglio <[e-mail]>
Cc: Tim Chown <[e-mail]>; Jeremy Duncan <[e-mail]>; [e-mail]; 6MAN <[e-mail]>
Subject: Re: SNAC questions regarding the 6724 update

[EXTERNAL] Verify links and attachments with sender.
The problem is that SNAC isn't allowed to specify new host behavior. This document is specifying new host behavior. If we think that there should be new host behavior for SNAC, it makes more sense to specify it here than in a SNAC document, not only because it's out of charter, but also because it's unlikely implementors will think to read the SNAC document unless they are implementing SNAC. I think it would be really weird to add new constraints around source address selection in a SNAC document even if it were in charter.

So I think if we need to specify this, we need to specify it here. If we don't need to specify it here, we don't need to specify it at all.

Regarding your question about GUA selection, yes, this is correct behavior. Basically, we don't ever benefit from SNAC prefixes being treated as known-local.


On Mon, Nov 11, 2024 at 7:02 PM Nick Buraglio <[e-mail]<mailto:[e-mail]>> wrote:
Ted,

On Thu, Nov 7, 2024 at 4:00 AM Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:
Oh, regarding the DHCPv6-PD prefix, we probably can treat that as known-local, but I think we can tell it's known-local from router advertisements on non-adjacent networks. So we don't need to infer that from a SNAC-router-provided RIO: in the case of a SNAC-router-provided RIO, as with a self-generated ULA, if we see a destination on that prefix, we won't have any other choice of destination address, and so we will wind up doing the right thing without known-local. On non-neighboring links, we either have a route that would lead to that prefix, in which case it's seen as known-local on that link, or we do not. But in either case, either there is a viable route (perhaps through the default route) to that prefix, or there is not. If there is, that destination address is going to be our only choice, so source address selection should do the right thing.
+1

Another case to consider is where there are two SNAC routers, each depending from a different infrastructure link. One has working PD, the other does not. The one without PD has at some time advertised a ULA on its infrastructure link because of a router reachability problem, and that prefix is still remembered, but there is a GUA as well. In this case, if we are not treating the SNAC-router-provided ULA prefix as known local, we'll choose the GUA source address (I think!). And so this will work.

This seems like correct behavior to me, no?


On Thu, Nov 7, 2024 at 9:52 AM Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:
Indeed I did—sorry about that. I'm replying to this CCing 6man since it seems like the working group needs to consider this.

So the thing about SNAC-generated GUAs is that they can only work on a single link, so the only reason to ever choose them in source address selection is that our only choice for destination address gives us the longest match.

There are actually three types of addresses that are involved in SNAC networking: the adjacent infrastructure (AIL) prefix, the self-generated off-stub-network-routable (OSNR) prefix, and the DHCP-PD-provided OSNR prefix. In theory, the AIL prefix and the self-generated OSNR prefix come from the same ULA /48, although in the case of Thread they are actually different. And, as you say, if there is more than one stub router, we can at least temporarily see more than one ULA /48 for the OSNR prefix simply because two might be advertised and then one withdrawn, for example.

In principle, the DHCPv6-PD OSNR prefix always supersedes the self-generated OSNR prefix, but they can coexist across time because we might not get a DHCPv6 answer before we time out and provide a non-DHCP OSNR prefix, and then if we get a DHCP prefix, we deprecate the OSNR prefix.

The question is really, does it do harm for us to mark stub router prefixes known-local, and also does it benefit us to treat them as known-local? I suspect the answer to the first question is yes, and the answer to the second is no. If we only have a stub-network-generated AIL prefix, this prefix is by definition not routed, and that means that if we happen to have a source address on that prefix, and no other local ULA prefix on the infrastructure link, and we are aware of a destination address that is a known-local ULA, we will choose the self-generated AIL prefix when sending packets to the known-local ULA destination. It would be preferable in this case to use a GUA if available, and if not, probably preferable to use IPv4 if available.

The proof that there is no benefit to treating these prefixes as known-local is that stub routers already work without this update to 6724.

So I think that we probably need to say in the document that router advertisements where the SNAC router bit is set MUST NOT be considered when determining that prefixes are known-local.

How would you feel about referencing 6724-update in the SNAC drafts, detailing these use cases? As I noodle through this, I am finding it difficult to word in such a manner that is general enough to cover the use case without it relating directly to SNAC, which I would like to avoid in this document, if possible. The known-local reference should lend itself where applicable to SNAC, since SNAC uses ULA in some cases. Further defining the details in this document *feels* like more detail that may be better contextually understood from the SNAC PoV (although I probably have some bias to get this out the door since it's so close, and I am fairly unfamiliar with SNAC, so perhaps I am outright incorrect).
However, if we leverage the SNAC drafts as opposed to adding more text to 6724-update, it does have a few [arguable] advantages:

It allows for a detailed description that is context aware given that it is within the SNAC protocol definitions.
This draft can proceed for further implementations as a reference without further delay.

Within the SNAC drafts we could list something to the tune of "Source selection MUST|SHOULD follow the heuristic defined in [[rfc6724-update]]. When receiving router advertisements where the SNAC router bit is set MUST NOT be considered when determining that prefixes are known-local."


Thoughts?



On Thu, Nov 7, 2024 at 9:37 AM Tim Chown <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ted,

I did ask you about SNAC and 6724-update a few weeks ago, I guess you missed it… see below.

Tim

On 18/09/2024, 14:51, "Tim Chown" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ted,

(copying co-authors)

I think you’ve followed the 6724 update and the known-local concept being introduced.

I’d like to pick your brain on whether in an unmanaged model, we can expect RIO information to propagate, for cases where ULA(s) and GUA(s) are used across the network.  We’d like all hosts in a home to know all other ULA prefixes in use such that if they also have GUAs they can pick ULAs for use.

I think in the general SNAC model it’s not an issue. Is the following correct…

Consider a home network with an ISP router offering a /64 GUA and a /64 ULA (out of a /48 ULA) to the local subnet.  If a couple of SNAC routers are plugged in, and the ISP router doesn’t offer a /64 GUA to them over DHCP-PD for their stub network use, I believe the SNAC routers will each use a ULA /64 from a (different) /48 ULA they each generate.  Then we have three ULA /64s in use from three ULA /48s. I think this case doesn’t matter, in that hosts in the stubs ONLY have ULAs, so will use them, even to/from the main home subnet, so long as the routing propagates.

But if the stub does get a /64 GUA via DHCP-PD from the homenet router will it also generate a ULA anyway?  My understanding is SNAC says don’t also use ULAs?  If it DOES use ULAs as well, then we need to have RIOs propagating somehow between the stubs so that all hosts in the stubs and main subnet can determine which ULA prefixes are known-local and use those ahead of GUAs.

Any other thoughts on the home network scenario and SNAC with respect to known-local ULAs is also welcome, and whether you think at least in principle it’s a good idea.  We’re about to issue the -10 and we still want a little more clarity on the common(er) use cases.

In managed networks it’s not such a problem as the admins will configure the right RIOs in the managed routers for the ULAs in use (if they all fit in one RA!).

Best wishes,
Tim