Re: Automatically connecting to stub networks...

[Ted Lemon <[e-mail]>]

On Dec 3, 2020, at 1:25 PM, Michael Richardson <[e-mail]> wrote:
> I'm assuming that it's the gateway that does DHCPv6-PD.
> If that works, then we are done.

Not quite. We still need to advertise reachability to the prefix, and do all the work to set up numbering on the local link. Assume no management, and an arbitrary number of stub routers potentially connecting to an 802.15.4 mesh. How does DHCPv6-PD even work in this scenario? I’m not saying it can’t, but it’s not “just do DHCPv6-PD”!

> We don't necessarily need the ULA or the NAT64 at that point.
> (Although, the delegated prefix might not be a GUA.)

Right, have to account for that. Also probably should account for the case where the infrastructure network provides NAT64 via ipv4only.arpa, so we don’t have to do it in the border router. This is obviously HIGHLY preferable. :)

> It's when it does not work that I think your draft comes into play.
> One is essentially bring IPv6 to a LAN where there might not any.
> I think that's okay.
> {I also think that the thing bring that ULA to the LAN should be a DHCPv6-PD
> server as well: there could be another gateway that needs IPv6}

We have to use what we’re given. If there’s DHCPv6-PD, we should figure out a way to use that. The Apple solution is very careful not to add anything to the network that’s unnecessary—if  you have a prefix from your ISP, it doesn’t advertise an IPv6 prefix on the infrastructure link, because there’s already a usable prefix.