Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt

[Ted Lemon <[e-mail]>]

On Jul 29, 2015, at 1:44 AM, Tore Anderson <[e-mail]> wrote:
> - Device 1 receives a delegated (<=) /64 from ISP/network (either 3GPP
>  or DHCPv6-PD), which it then chops up in (for example) 2^16 /80s
>  which may be handed out using DHCPv6-PD to downstream devices or
>  local software functions (which would includes including its own
>  loopback interface, local containers/VMs, etc.)
> - Any downstream device that receives an /80 from the above device
>  chops it up in 2^16 /96s which in the same way may be handed out to
>  downstream devices or local software functions.
> - Any downstream device that receives a /96 from a device at the above
>  level can chop it up in 2^16 /112s and use it in the same way.

This implies that you are advertising prefixes wider than /64 on the downstream side of these devices.   That’s not what Lorenzo is talking about in his draft, and if that’s not clear to your reading of it, he should probably clarify.   Lorenzo may indeed think that I am proposing to do that, but I’m not.   I’m just proposing that if SLAAC only needs 30 addresses, and we want to allocate 30 addresses on the advertised prefix using DHCP, DHCP PD would be one way to deliver those addresses in such a way that they need only occupy a single slot in the forwarding table for the on-link router(s).   The hierarchical allocation model you are talking about really doesn’t make sense in this context: if some host several hops down the link is sharing the prefix, then it can just get its own /120 (or whatever) chunk of the prefix, rather than getting a chunk of the upstream host’s chunk.

But even going down this rabbit hole shows why this isn’t a great idea: whether you are using SLAAC or DHCP-PD, what you really have here is something akin to a homenet router, and if that’s the case, then you should just own it and not try to pretend that it’s just a host.