Re: Extending a /64

[Philip Homburg <[e-mail]>]

> The problem is from the perspective of an end-user.  What should
> an end-user do if the only thing available on that link is a /64.
> 
> That problem isn't just restricted to mobile operators.  For example
> if I connect a host with VMs to my employer's network, I cannot
> extend it. No DHCPv6-PD is supported. Nor HNCP.  This works
> "perfectly" fine for IPv4.
> 
> While I think it's perfectly fine to not accept that this is a
> problem, and require all network operators be it Enterprise or SPs
> to support DHCPv6-PD and HNCP.  It might be worth taking a second
> look at that.
> 
> And note that extending the /64 boundary doesn't really solve this.
> At least not in a very non-hackish way.

I guess the issue is that with NAT we got used to being able to hide
an entire IPv4 network behind a single address. Of course, that also
works with IPv6, but we don't want to do that.

With IPv6 we are doing a new thing, and the net result is that it is a bit
chaotic:
- relavtively short prefixes are typically distributed using DHCPv6 PD.
  Such a prefix can be split into one or more /64s.
- /64s are used to number subnets and can be split using L2 bridging
- a /64 can also be split into smaller prefixes and then DHCP IA_NA can be
  used on those (though it techincally violates the address architecture)

So what you can do today is allocate addresses within VMs using DHCP IA_NA.

On IPv4 every network runs DHCPv4 because that is what is needed. On IPv6
every network has RA because that is what is needed.

We are now at a stage where DHCPv6 PD is needed, but too many network don't
support is.

I guess replacing one protocol that is not deployed with a future protocol
that also needs to be deployed doesn't make a lot of sense.

In the case of a VM, typically a host is connected to a multi-access network.
So the /64 of the subnet cannot be subdivided by the host. It would require
changes on the router to have a unique /64 per host.

In that case why not implement DHCP PD?