Re: [Iotops] Automatically connecting to stub networks...

[Ted Lemon <[e-mail]>]

On Dec 4, 2020, at 3:19 AM, [e-mail] wrote:
> Let's me see if I can dissect Ted's arguments against HNCMP in https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00#section-1.3, and if restricting the problem to only allowing stub routers to be connected to a single router helps. (A topology with a single root router and a single level of branches).
> 
> 1) HNCP only works if all routers in the AS runs it. It's a routing protocol so that's not surprising.
> Solutions would have to either participate in routing and a prefix assignment protocol.
> The degenerate case for routing is default route upstream and a static route for the assigned prefix downstream.
> All traffic to sieblings would go via root router.

HNCP is not a routing protocol. Babel is a routing protocol. HNCP is a mesh discovery protocol. It has a lot in common with routing protocols, but it’s really its own beast.

For the stub network case, HNCP simply isn’t necessary. I think the disconnect with HNCP is that it is aimed at a problem nobody wants to solve. The stub network problem is a problem that we wanted to solve enough that we spent two years working on it. HNCP was a choice we considered, but it simply wasn’t an option. I guess if you want routable IPv4, HNCP would help with that for the stub network case, but I don’t find this compelling—IPv6 works fine.

> Ted also mentions that HNCP does not deal with the case where only a /64 has been delegated to the site.
> In homenet we did a conscious choice of requiring a site to get enough addressing to get a /64 for each link.
> I do know that the implementation in OpenWRT does support a single /64 (it subnets into /80s and does DHCP address assignment).
> How to deal with a case of not enough addresses assigned is not a problem unique to HNCP though.

The point of saying that is that we need some way to do outbound connectivity in this case. Our solution to this problem is to use NAT64. Hopefully as v6only deployments happen, service providers will get real about assigning narrower prefixes.

> The degenerate case for addressing is:
> a) Split up a /64 in pools of addresses for DHCP
> b) If less than a /64 (e.g. already shared) then NAT

No point in doing NAT66 when you can do NAT64.

> 2) HNCP is too complex and does too much and is not implemented.
> Not enough details to make any arguments for or against this one.
> If one standard isn't deployed and implemented is a weak argument for inventing a new protocol and standardising that, that's neither specified, implemented nor deployed.

From my perspective, needing to ship a product that will work on real networks, and not rely on imaginary networks, the fact that there are no implementations and none coming meant that we simply couldn’t use HNCP, even though because of my time in the Homenet WG I was personally predisposed to do so and spent quite a bit of time evaluating it as a solution before abandoning it.

> Question, what are the requirements here?
> 
> A) Stub network. Is it possible to restrict the topology to a single root/single level of leafes?
> It prohibits multi-homing. What about the case where a node is attached to the stub with a hypervisor and VMs requiring addressing?
> Is sending all traffic via the root acceptable? Instead of short-cutting between stub routers?

I see no reason to do this.

> B) Is it possible to restrict the solution to the site having been delegated enough address space?
> Or do you need to handle the cases where the site has:
> a) not received enough /64s to number all links
> b) have only been delegated a single /64
> c) have only a shared /64
> d) have only a single address

Our solution works in all of these cases except the v6-only /64-only case.

(I say our solution meaning what we did in the HomePod Mini and the open source Thread border router—we don’t have a specification yet, and didn’t actually do any protocol work.)