Subject: Comments on draft-lemon-stub-networks-ps-00

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Aug 2020 16:04:50 +0200

Hi,

I read the draft on self-configuring stub networks,
draft-lemon-stub-networks-ps-00.

I have several comments.

Overall I can understand and like the structure of the document.  It is
organized in a matrix manner and most arguments seem valid to me.

I can find 'discoverability' in the dictionary, but not 'reachability'.
  I do understand reachability of a host as its characteristic of being
able to be found in the Internet - if I can ping then it has
reachability.  I do know that the term is widely used in RFCs and
Internet Drafts.  I just note.

In the discoverability parts, I will not discuss DNS-SD neither 
multicast DNS.  Just a note to say that I find it strange to recommend 
DNS-SD proxies, as much as I dont like ND proxies, or DHCP proxies. 
Maybe a DNS-SD is possible which has some form of IP-enabled 
intermediary routers (like DHCP Relay).

In the IPv4 parts: I will not read or comment the NAT64.  However, I 
would like to briefly mention the following: at recent IETF meeting 
there was gather.town.  While on IPv6 I could not connect to others who 
were on IPv4.  It was said that was so because of the nature of 
peer-to-peer.  But I doubt that a conversion method like NAT64 would 
have worked to make a connection possible in gather.town between people 
on IPv6 and people on IPv4.  It's just an intuition, and I might be wrong.

> Motivating factors include:
> 
> o  Transitory connectivity: a mobile device acting as a router for a
>  set of co-located devices could connect to a network and gain
> access to services for itself and for the co-located devices. Such a
> stub network is unlikely to have more than one stub router.
> 
> o  Incompatible media: for example, a constrained 802.15.4 network 
> connected as a stub network to a WiFi or ethernet infrastructure 
> network.  In the case of an 802.15.4 network, it is quite possible 
> that the devices used to link the infrastructure network to the stub 
> network will not be conceived of by the end user as routers. 
> Consequently, we cannot assume that these devices will be on all the 
> time.  A solution for this use case will require some sort of 
> commissioning process for stub routers, and can't assume that any

(commissioning?)

> particular stub router will always be available; rather, any stub 
> router that is available must be able to adapt to current conditions 
> to provide reachability.

Here, it makes me think of a more generic motivating factor:
o impossibility to bridge particular pairs of link layers; for example,
   it is impossible for a computer to bridge an IP-enabled USB interface
   to its IP-enabled Ethernet interface.  Other such pairs are: 802.11-
   OCB (earlier known as 802.11p) and 802.11 link; cellular link and
   Ethernet link.  There might be more.

> o  Convenience: end users often connect devices to each other in 
> order to extend networks

[...]

> Both the locally-reachable and globally-reachable use case should be 
> able to be made to work,

it is a nit: use cases.

> Unfortunately, the way that such an HNCP server should behave is not
>  documented, and it's not actually clear how it should behave.  What
>  if the DHCP server allocates it a /64?  HNCP is designed to get a 
> larger prefix and subdivide it--there is no provision for requesting
>  multiple delegations.  So if we wanted to use HNCP to solve this 
> problem, we would need to do additional work.

That might be indeed an HNCP problem.

Other than HNCP, or more generally, the problem is simply in allocating
a /64 to a stub router.  A stub router that gets allocated a /64 from
the infrastructure will need to form one or several /65s for its links
in the stub network.  Assuming that the stub router will use SLAAC as
known for address auto-configuration on the links in the stub network,
then there is a problem for the linux Hosts in these links.  The linux
Hosts can not self-form Interface IDs of length 63 (only of length 64
can they form).  In this way, SLAAC can not be used in the stub networks
when the stub router is allocated a /64.

The solution to this problem might need to consider (1) allocation of
prefixes of length shorter than 64 (e.g. 63) to a stub router, together
with (2) a mechanism to self-form intermediary bits between an IID of
length 64 and the prefix length for SLAAC and (3) a more generic
mechanism of SLAAC with other than 64bit prefix lengths and Interface ID
lengths.

I must share with you that we work on a separate Internet Draft for such
a problem statement (SLAAC with variable length prefix) and some
implementation on linux kernel since some time now.  We expect
publication some of these days.

> 2.2. Stub reachability using RA, 2.2.2 Addressability
> 
> Addressability on the stub network is provided using a ULA prefix 
> generated by the stub router.  Addressibility on the infrastructure 
> link is either provided by the infrastructure, or else must be 
> provided by the stub router.
Yes, an ULA prefix makes sense.  But it could also be a globally unique
prefix, provided the infrastructure is disconnected from the Internet.

Even the infra might be connected to the Internet and that place is the
only place where the stub network can connect to it.

Or the infra might still be connected to the Internet and the set of
places where this stub network connects to are not very much disturbing
the routing system.

I mean, the use of ULA in the stub network is probably the most
recommended alternative, and others are possible too.

> 2.3. Global reachability, 2.3.1 Reachability
> 
> Reachability in this case requires integration into the routing 
> infrastructure.  This is most easily accomplished by having the 
> DHCPv6 prefix delegation server add an entry in the routing table 
> pointing to the stub router to which the prefix has been delegated.

yes, pointing to the stub router, or to the DHCPv6 Relay who points to
the stub router.

> Stub routers can also advertise reachability to the stub network 
> using router advertisements, but these will only work on the local 
> link.

[...]

> o  In the case of multiple stub routers,

YEs, stub routers of the same stub network.

> stub routers must cooperate both in acquiring and renewing prefixes
> acquired using prefix delegation.  Stub routers must communicate
> complete routing information to the DHCPv6 prefix delegation server
> so that it can install routes.

... complete routing info to the DHCPv6 prefix delegation server, or to 
the DHCPv6 Relay...

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2020 10:20:21 -0400

> when the stub router is allocated a /64.

Can you expand on this?  I don’t understand why this would be necessary or desirable. If you mean that the stub router could serve multiple stub networks, that’s not really a new use case—it’s no different than having several stub routers each serving a single stub network, and can be addressed the same way.  I have no interest in opening up the >/64 prefix can of worms, and don’t see it as necessary.

> prefix, provided the infrastructure is disconnected from the Internet.

Why would that be beneficial? That is, (a) why do we even care about this use case, since it’s addressed by a ULA and doesn’t require a GUA, and (b) what advantage would there be in using a GUA instead of a ULA?