On 12/30/13 1:04 PM, "Ryan Harden" <hardenrm@uchicago.edu> wrote:
On Dec 24, 2013, at 8:15 AM, Lee Howard <Lee@asgard.org> wrote:
default route information via DHCPv6. That's what I'm still waiting for.
Why? You say, "The protocol suite doesn't meet my needs; I need default gateway in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why?
Lee
There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there¹s little interest (read: budget) in rewriting everything for IPv6.
Thank you very much for presenting an actual use case. Seems like a dot1x kind of application, where the host is in a temporary VLAN until authenticated (etc.), right? Same use case, different network solution.
'Rewrite all of your tools and change your long standing business practices¹ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care much for that when you have to ask for developer time to rewrite everything.
Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, "Make sure you call IP family agnostic libraries and increase field sizes, then let it run" and "Rebuild your network security." DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network. As for "why not add it?" my answer is that if it's needed, we should add it. If it's not needed, we should not add it. "I want default gateway in DHCPv6" does not answer the question of whether it's needed, which is why I asked why.
Disclaimer: I don¹t condone said methods and trickery mentioned above, just pointing out their use.
Will consider more. Lee
/Ryan