Code change:
Based on comment: URL and responses: URL URL it is clear that the SNAC stub router solution may in some cases not work if the IPv6 Host on the AIL that needs to send an IPv6 packet to a host on a stub network is a Type A or Type B Host. In fact, our assumption so far has been that it is a Type C host. Proposal: add clarification that solution scope is intended for Type C hosts on the AIL. (Though it might work for Type A and B hosts in particular cases, this is not in our scope.) Refer to RFC 4191 Section for the 3 host types. (FYI NAME
Looks like a good place to add this scoping information - in the goals section. Thanks Hello, I can try to respond from my viewpoint. This could help to identify the open issues. I don't see how RFC 8028 is relevant here. It has the following applicability: IPv6 host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering The network/link (AIL) considered for SNAC-simple is a link with a single IPv6 on-link prefix. Either a global/ULA prefix allocated by e.g. a home router, or if that is missing, a ULA prefix allocated by one of the stub routers. So there's not "more than one prefix" and I don't see immediately if any problem would occur if we would have > 1 prefix. For example the IPv6 host on the AIL would remain reachable from an on-stub-network host, regardless of the IPv6 source address that the host on the AIL used. See also below for more info on this case for the packets in the other direction. This part I agree should be clarified in SNAC-simple. I assumed a Type C host for sure. And I would consider Type A and Type B to be even out of scope if required to keep the solution simple! One question is: what if a Type A/B host sent an IPv6 packet to the ULA dest address of a stub-Host ; and the packet would be routed to the default router of the home network? (E.g. home router / Wi-Fi AP / ISP box) Wouldn't that default router immediately discover that the correct route is to send it to the stub router, based on the RA RIO advertisements? So the routing is not most efficient then but it works. If that is the case, we can still support Type A/B hosts although with some degraded performance/latency. I think we could clarify that the stub router must never ever advertise itself as a default router (or advertise a default route ::/0) on the AIL. This isn't in the draft yet. Not sure if that is what you meant here? The existing mentions of "default route(r)" in SNAC-simple are pertain to advertising itself as default route on the stub network side, not the AIL side, I believe. Given the above, even if the host would not follow rule 5.5, it would pick another source address, but still that address would be based on an IPv6 prefix that is on-link. So it means the stub router can correctly route back to that prefix and use IPv6 ND to find the host back on the link. And the IPv6 host if it is type C would still use the RA RIO advertisements to pick the next-hop router, regardless of its IPv6 source address. The only question I have is for the Type A/B hosts - they might pick a default router instead and the question is there if it would route back the packet to the right stub router on the AIL instead of sending the packet out onto the wider Internet. (My expectation is that it would work, but ... ) But this Type A/B host problem is there independent of the source address selection. Or am I missing something? Also keep in mind that there are in total 3 possible cases for a given stub router: Stub router uses its generated ULA prefix to assign a prefix for the stub network; and also to assign a prefix for the AIL. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another stub-router (there may be N stub routers in total, each with a different stub network) has assigned the AIL prefix. That means the prefixes don't use a shared ULA prefix. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another non-stub-router (e.g. home AP) has already assigned a prefix for the AIL. That means the prefixes don't use a shared ULA prefix. So we cannot rely on features that only work well when a single ULA prefix is used to derive the AIL on-link prefix and the stub network on-link prefix. Esko -----Original Message----- From: Snac On Behalf Of Erik Auerswald Sent: Sunday, August 20, 2023 20:24 To: SNAC List Subject: [Snac] Host Requirements for SNAC Use? Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems Snac mailing list EMAIL URL
Hi, I was looking for existing methods for a host to select the correct gateway when there are more than one. RFC 8028 is one example. I agree. I would not expect an existing home router to look at any RAs from inside the home network, much less to populate its routing table with the information from those. As such, the home router would either forward the packet via its default route, or drop it. I doubt that to be the case. I think that a stub router following the new SNAC ideas could learn routes from RAs received on the AIL, and use these to forward packets towards the home router or even other stub networks. But as fas as I know this is not common home router behavior. This might be nice to avoid breaking Internet connectivity when adding a stub router to a home network But for reliable connectivity to the stub network, the host would still need to select the stub router as gateway. If the stub router sends an RA with a non-zero lifetime, it advertises itself as a default router. An RFC 4191 type B or C host would evaluate a default router preference and should thus prefer the home router if the stub router uses a Low Preference (unless the home router were also to use a Low Preference), but an RFC 4191 type A host does not evaluate the Preference. I would suggest to require a stub router to use a Low Preference in the RA, but a High Preference for its stub network prefix(es). I have read RFC 6724 again, and I think I made a mistake. RFC 6724 expects that the first hop gateway is selected via destination address, and then describes how to optionally choose a better source address for use with this gateway. This does pertain to RFC 8028, but not to SNAC. I think you are correct. I would expect independent stub networks to use different 48-bit ULA prefixes. In general, a single stub network should suffice with using a single 48-bit ULA prefix, but current implementations may not restrict themselves to this since it is not seen as necessary. I think we cannot rely on many features to be consistently present in existing home networks. Currently, SNAC implicitly requires RFC 4191 type C host behavior. This could be made explicit. I think that would improve the draft. I do not see a rationale for the requirement of a single ULA prefix in draft-ietf-snac-simple-02. It seems logical that a stub router would not need more than one ULA prefix, and one such prefix might be nice. It might help in troubleshooting. It might help keep RAs sufficiently small. It might help keeping routing tables small. It might work together with source address selection to help selecting the stub router as first hop gateway (but that is not described in RFC 6724, but a rather different idea). With no explicit reasons for a single ULA prefix, the requirement could be reduced to a SHOULD or even dropped from the draft. The current motivation to drop the single ULA prefix requirement seems to be that an existing stub router implementation does not limit itself to a single prefix. I find this reasoning quite weak. I wrongly interpreted RFC 6724 section 5 rule 5.5 to help select a gateway after selecting the source address, but it works the other way around. Thus I do not have a strong reason for a single 48-bit ULA prefix any more. I do think that it would be neat to have just one 48-bit ULA prefix per stub network, but that is insufficient for a MUST, I'd say. Best regards, Erik The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- Edsger W. Dijkstra
Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems

Related discussion:
text: sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the