use-case for requesting addresses (not prefixes) using DHCPv6

Hi,

During the last DMM meeting there was discussion about using DHCPv6 to 
request addresses, and to qualify these addresses ('sustained', 
'nomadic', etc.)

There was comment that it may not be good to use DHCPv6 to request 
addresses, but rather use SLAAC for that, or use DHCPv6-PD to request 
prefixes, not addresses.  This is RECOMMENDED in RFC 7934 section 8:

> Due to the drawbacks imposed by requiring explicit requests for
>    address space (see Section 4), it is RECOMMENDED that the network
>    give the host the ability to use new addresses without requiring
>    explicit requests.  This can be achieved either by allowing the host
>    to form new addresses autonomously (e.g., via SLAAC) or by providing
>    the host with a dedicated /64 prefix.  The prefix MAY be provided
>    using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.


There is however a use-case I am concerned with which needs DHCPv6 for 
addresses. The use case involves a M2M Router connecting to 4G and 
giving access with USBnet to other routers and hosts in its moving network.

The M2M Router hears a /64 prefix from the operator, forms multiple /80 
prefixes for its 'inner' routers and hosts, a DHCPv6 Server, and listens 
to DHCPv6 requests for addresses from these 'inner' routers and hosts.

In this case, SLAAC does not work for these inner hosts, because the 
prefix length is /80.

This is why DHCPv6 for addresses is needed in this use-case.

The operator does not implement DHCPv6 Prefix Delegation, and I think 
there is no 4G operator at this time that implements it.  I have some 
ongoing discussions with an incumbent operator about DHCPv6-PD on 
Ericsson base stations (not to name them), but I think nobody else is 
doing it at this time.

_If_ a cellular operator implements DHCPv6-PD, and _if_ it delivers 
plens shorter than /64 to cellular UEs, then the need for 
DHCPv6-for-addresses may disappear.  My gut feeling at this time is that 
we are way way far from such a time.

Alex

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm