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

[Erik Auerswald <[e-mail]>]

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