Re: [Snac] Host Requirements for SNAC Use?

[Erik Auerswald <[e-mail]>]

Hi,

On Thu, Aug 24, 2023 at 11:25:51AM +0000, Esko Dijk wrote:
> 
> 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

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.

> [...]
> > 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!

I agree.

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

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.

> If that is the case, we can still support Type A/B hosts although with
> some degraded performance/latency.

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

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

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

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.

> [...]
> But this Type A/B host problem is there independent of the source
> address selection.  Or am I missing something?

I think you are correct.

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

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.

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

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