Re: [Snac] Host Requirements for SNAC Use?

[Erik Auerswald <[e-mail]>]

Hi,

On Fri, Aug 25, 2023 at 03:33:17PM +0000, Esko Dijk wrote:
> 
> Thanks for the responses. Given the expected behavior of home routers
> you mention it seems wise to specify the scope for SNAC-simple to be
> Type C IPv6 hosts.
> 
> > 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).
> 
> By the way, is there any potential issue that the stub-router-provided
> ULA prefix would somehow interfere with IPv4 connectivity? I'm assuming
> here that IPv4 provides a default route (e.g. via the home router/ISP)
> while the stub router does not provide a default route.

That was the case in the past, but RFC 6724 introduced a "label" for ULA
that is distinct from GUA.  Since matching labels are preferred, the match
between two IPv4 addresses (one label for IPv4) is preferred over the
mismatched labels of GUA and ULA.  There is another possible failure case,
when a remote ULA is received via DNS although the traffic would have to
go via Internet.  This case is solved in RFC 6724 by specifying a lower
"precedence" for ULA than for IPv4.  (Not all hosts implement the latter
part, e.g., GNU/Linux has a higher preference for ULA than for IPv4.)

> That way there is no wrongly provided impression that the stub router
> has IPv6 connectivity to the internet. So, the Router Lifetime field
> would be always '0' for the stub router. (Which we may clarify in
> the draft)

That should work, but RFC 4191 states that in section 4:

    "When ceasing to be an advertising interface and sending Router
     Advertisements with a Router Lifetime of zero, the Router
     Advertisement SHOULD also set the Route Lifetime to zero in all
     Route Information Options."

RFC 4861 describes in section 6.2.3:

    "A router might want to send Router Advertisements without advertising
     itself as a default router.  For instance, a router might advertise
     prefixes for stateless address autoconfiguration while not wishing
     to forward packets.  Such a router sets the Router Lifetime field
     in outgoing advertisements to zero."

So using a router lifetime of 0 does not imply that the interface is not
an advertising interface.  This combination does not seem obvious to me,
but it seems valid.

Going back to RFC 4191, section 5.2 mentions the combination of router
lifetime 0 with RIOs with lifetime > 0 as a solution for type C hosts.
The solution for type B hosts for a single isolated network is preference
based, and there is no solution for type A hosts.

I think that Route Information Options should be accepted from RAs with
a Router Lifetime of 0 according to those RFCs.

> There's somewhat related text in the draft:
> 
>     The stub router MAY advertise itself as a default router on the
>     stub network, if it itself has a default route on the AIL. In some
>     cases it may not be desirable to advertise reachability to the
>     Internet as a whole; in this case the stub router is not required
>     to advertise itself as a default router.
> 
> But it doesn't mention the case of itself advertising as default router
> on the AIL. That seems not advisable; e.g. if stub router 1 decides to
> advertise default route then stub router 2 may think there is a default
> route and will follow the above rule, with unwanted consequences ...

Yes, several stub routers each using each others as Internet gateways
would not work.  Thus I think that stub routers must not advertise
themselves as default routers on the AIL.  Perhaps this could be made
explicit?

I would like the draft to be explicit regarding RA contents, preferably
with a rationale.  I would really like to read short explanations for
the specific settings, i.e., how this is supposed to work.

It would be great if draft-ietf-snac-simple could mention section 5.2
of RFC 4191 and that a lifetime of 0 should suffice for type A and B
hosts to ignore the stub router, i.e., do no harm, but a type C host is
required for stub network reachability from the host.

Since supporting a type B host would risk creating problems for a type
A host, I would prefer SNAC to only work for type C hosts.

As soon as more than one stub network is connected to the AIL, only type
C hosts can reliably choose the correct stub router anyway.  The case
of multiple stub networks is more complex than the scenario from RFC
4191 section 5.2.

Best regards,
Erik
-- 
A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable.
                        -- Leslie Lamport