Re: [Snac] Relax the requirement on a single 'root' ULA prefix generated by stub router?

[Esko Dijk <[e-mail]>]

Hi,

Thanks for the summary of points.

> A host implementing the RFC 6724 section 10.6 procedure would detect
>    the stub router's 48-bit ULA prefix on the AIL as local.  

If there are say N stub routers, each with own stub network, there would be N different ULA prefixes.
Suppose the AIL on-link prefix has been assigned from a global IPv6 prefix from the ISP.  The default router (e.g. home AP) provides this AIL on-link prefix, which is non-ULA.

Now the Host would use a global IPv6 source address and ULA IPv6 dest address for its packet.  If the host is "Type C" (see other email thread) then that should just work, right?
There is no source address selection problem at least because there's only one to select from.

In another case, it may happen that the ISP / Home AP only provides IPv4 internet. In that case one of the N stub routers assigns an AIL ULA prefix.
However it's only one out of N, so there may be N-1 other ULA prefixes that could be used as destination IPv6 address, that are *not* derived from the same base as that one AIL ULA prefix.
Similar to the global address case above, the packet delivery should just work, or not?
Why is the "local ULA prefix detection" needed here?

We assume also that the case of one auto-assigned ULA prefix and one GUA prefix on the AIL is not applicable, since the stub router only assigns the ULA prefix if there's nothing else already assigned.

Esko

-----Original Message-----
From: Erik Auerswald <[e-mail]> 
Sent: Wednesday, August 16, 2023 11:21
To: SNAC List <[e-mail]>
Cc: Esko Dijk <[e-mail]>
Subject: Re: [Snac] Relax the requirement on a single 'root' ULA prefix generated by stub router?

Hi SNAC WG,

On Thu, Aug 10, 2023 at 01:17:19PM +0200, Erik Auerswald wrote:
> On Wed, Aug 09, 2023 at 11:06:23AM +0000, Esko Dijk wrote:
> > 
> > One issue found during implementation is that snac-simple-02 requires
> > a single ULA prefix as a 'root' to derive further ULA prefixes from
> > for the stub network and the AIL.
> > But in practice it may be desirable to use 2 ULA prefixes for these
> > respective cases. The proposal is to relax the requirement to allow
> > such use.
> > 
> > Issue is created here:
> > https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/31

There have been additional comments on this GitHub issue from Esko Dijk,
Michael Richardson, and me.

> Using a single ULA prefix may allow to implement the example procedure
> from [RFC 6724 section 10.6.][1], specifically the following part:
> 
>   | Since ULAs are defined to have a /48 site prefix, an implementation
>   | might choose to add such a row automatically on a machine with
>   | a ULA.
> 
> [1]: https://www.rfc-editor.org/rfc/rfc6724#section-10.6

To *me*, the gist of the additional GitHub comments seems to be:

 - Thread gateways may create a random ULA on-mesh prefix.

 - Thread gateways may create a ULA prefix for the AIL based on the
   "Extended PAN ID".

 - Those two ULA prefixes are unrelated and thus most likely different.

 - A stub router is intended to provide connectivity to the stub network
   for hosts on the AIL.

 - In the era of RFC 3484, ULA were dangerous, because they could break
   IPv4 Internet connectivity, as described in RFC 5220 section 2.2.2[2]
   (I experienced this problem first hand, thus I do not consider it
   purely theoretical).

 - RFC 6724, among many other things, fixed the problem described in
   RFC 5220 section 2.2.2.  This fix affected the usability of ULAs[3],
   because ULA are considered to *not* be local by default, unless
   either configured or detected, e.g., via the RFC 6724 section 10.6
   procedure[1], as local.  The need for local configuration when ULA
   are used is actually explicitly stated in the Proposed Standard RFC
   4193 section 4.5[4].

 - The RFC 6724 section 10.6 procedure automatically detects the *local*
   48-bit ULA prefix by looking at a ULA active on the host.

 - A host implementing the RFC 6724 section 10.6 procedure would detect
   the stub router's 48-bit ULA prefix on the AIL as local.  If the
   stub network were using the same 48-bit ULA prefix, the host would
   consider the stub network local and prefer the corresponding ULA
   for communication.  This would not work if the stub network would
   use a different 48-bit ULA prefix than used on the AIL.

 - Allowing the use of different 48-bit ULA prefixes on the same stub
   router would go against the assumptions underlying the Proposed
   Standard RFC 6724.  It seems to me that new IETF work should avoid
   needlessly breaking existing IETF Proposed Standard specifications.

 - The currently used requirement for a single 48-bit ULA prefix, as
   currently required in section 5.2.2 of draft-ietf-snac-simple-02[5],
   seems to me to be consistent with current Proposed Standard RFCs.
   As I see it, relaxing this would not be consistent with current
   Proposed Standard RFCs.

[1]: https://www.rfc-editor.org/rfc/rfc6724#section-10.6
[2]: https://www.rfc-editor.org/rfc/rfc5220#section-2.2.2
[3]: https://blog.ipspace.net/2022/05/ipv6-ula-made-useless.html
[4]: https://www.rfc-editor.org/rfc/rfc4193#section-4.5
[5]: https://www.ietf.org/archive/id/draft-ietf-snac-simple-02.html#section-5.2.2-1

> My impression was that ULA generation in SNAC was intended for local
> IPv6 connectivity inside a site.  I might be worth it to provide
> compatibility with existing specifications that cater to ULA use for
> IPv6 connectivity inside a site.

In this case, I intended "site" to mean, e.g., a home network with a
single AIL, to which one (or more) stub router(s) is (are) connected.
This was not intended to pertain to extended sites with many internal
gateways.

Additionally, if more than a single stub router is connected to the AIL,
a host on the AIL that uses RFC 6724 section 5 rule 5.5[6] would avoid
connectivity problems.  This is also described in the Proposed Standard
RFC 8028 section 3.3[7].

[6]: https://www.rfc-editor.org/rfc/rfc6724#section-5
[7]: https://www.rfc-editor.org/rfc/rfc8028.html#section-3.3

Best regards,
Erik
-- 
To have our best advice ignored is the common fate of all who take on
the role of consultant, ever since Cassandra pointed out the dangers of
bringing a wooden horse within the walls of Troy.
                        -- C.A.R. Hoare