Subject: [homenet] A few comments about draft-lemon-stub-networks-02

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 01 Sep 2021 23:52:17 +0200

I haven't been following Ted's work on stub networks, and I've only just
taken some time to read through the latest draft.  Sorry if I repeat
things that have already been said, I haven't caught up yet with my
Homenet mail.

A few quick comments while I think it over.

1. There's a lack of definitions

The draft speaks about "stub networks", but I couldn't find where the term
is defined.  Is a stub network a single layer-2 link, or can it be a layer
3 mesh ?  Is a stub network connected through a single router, or can it
be connected through multiple ones?  If there are multiple stub routers,
do they need to be connected to the same infrastructure link, or can they
be connected to distinct links?  To different providers (think BCP 38)?

I think the draft could be usefully improved if the terms were more
clearly defined.

2. There's a lack of a problem statement

I couldn't work out what problem the draft is aiming to solve.  In Section
3.2, it appears to be about client tethering, but in Section 3.5, it would
appear to be about some sort of DMZ, that makes services available to the
rest of the homenet.

I think the draft would be improved if it were circuscribed by a clear
problem statement.

3. NAT64 is controversial

The draft recommends NAT64 as the IPv4 connectivity technique.  I'm
certainly not alone in this group in disliking NAT64, which combines all
the problems of NAT with all the problems of split-horizon DNS.  (See also
RFCs 7368 and 9080, both products of this WG, which clearly discourage the
use of NAT.)

I think that the draft would be less contentious if the part about NAT64
were removed.

Hope this helps,

-- Juliusz