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

Reply via email to