So here is the thing. You can try to use enhanced functionality which depends on multiple addresses as justification for saying DHCPv6 is not supported. In practice, your device will just not be supported. As you pointed out, there isn't anything that forces adoption of IPv6 right now. If your client is broken because of an incomplete implementation, I just won't give it an IPv6 address at all. I think a lot of others feel the same way. At least on our network, the number of Apple devices dwarf Android by several times. With Android being a minority and not implementing DHCPv6 support you force us to make Android a second class citizen. I'm perfectly find NATing Android, and don't see us giving up the operational benefits to DHCPv6 anytime soon. Also, in terms of hotspot functionality being the major driver ... I already provide ubiquitous wireless coverage. I don't want users enabling a hotspot (rogue AP) on campus because it has a negative impact on service for others, so the whole argument is really meaningless in the context of higher education and campus networking. A phone makes a terrible AP when the laptop supports full 802.11ac. I really don't know anyone who connects through their phone when WiFi is available and the phone is also connected to the same WiFi network. It's not even a use case I think most people would consider common or valid but we're using it a justification to not support something that IS very common and widely deployed. On Wed, Jun 10, 2015 at 7:16 AM, Lorenzo Colitti <lorenzo@colitti.com> wrote:
On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann <sander@steffann.nl> wrote:
I can also see more deployment issues (much more state in the routers for all those PDs, needing huge amounts of /64s (or larger) to be able to deal with a few hundred/thousand clients) but it would be very nice if this was possible :)
Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in exactly the same way and give every client a /64. A /24 becomes a /56, and your 10/8 becomes a /40. A /40 is really not hard to get.
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net