Re: [Snac] Host Requirements for SNAC Use?

[Esko Dijk <[e-mail]>]

Hello,

I can try to respond from my viewpoint. This could help to identify the open issues.

> BCP 220 also recommends (but does not require)
> adherence to RFC 8028 for first-hop router selection.

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.

> 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.  

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.

> 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.  

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. 

> If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule
> 5.5, 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?

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:
1. Stub router uses its generated ULA prefix to assign a prefix for the stub network; and also to assign a prefix for the AIL.  
2. 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.
3. 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 <[e-mail]> On Behalf Of Erik Auerswald
Sent: Sunday, August 20, 2023 20:24
To: SNAC List <[e-mail]>
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
5.5, 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
[e-mail]
https://www.ietf.org/mailman/listinfo/snac