This is OT of NAT, but follows the existing discussion. Since discussion has warped around to host configuration DHCP (again), it might be useful to review discussions dating from 2011: The stupidity of trying to "fix” DHCPv6 and The Business Wisdom of trying to "fix” DHCPv6 which also refer to discussions from 2009. The pertinent Business View is
The security domain for HOST should not overlap the security domain for ROUTER.
That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social-engineering distributed malware began to affect BGP! It is imperative to supply the features that End System Operators find useful for their business. This simple position is independent of IPv4/IPv6 differences.
Since DHCP is a Host Configuration tool and is quite independent of router configurations except for DHCP forwarding entries, we must quit requiring ongoing fiddly network router configuration changes to make End System configuration changes. These can be centrally managed by DHCP run to meet End System configuration requirement, even including providing default routes. This simple position is independent of IPv4/IPv6 differences. All that is necessary is for us to end the years of religious debate of DHCP vs RA and to start providing solutions that meet business management needs. James R. Cutler James.cutler@consultant.com PGP keys at http://pgp.mit.edu
On Dec 19, 2015, at 1:01 PM, Matthew Petach <mpetach@netflight.com> wrote:
On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard <Lee@asgard.org> wrote:
On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of.
Tell me again why you want this, and not routing information from the router?
Apologies for the delay in replying, work has been insanely busy as we come to the end of the quarter.
The problem is when you have multiple routers in a common arena, there's no way to associate a given client with a given router unless the DHCP server can give out that information.
In an enterprise wireless environment, you have many different subnets for different sets of employees. Unfortunately, the reality of common RF spectrum dictates you can't do separate SSIDs for every subnet your employees belong to; so, you have one SSID for the company that employees associate with, and then the DHCP server issues an appropriate IP to the laptop based on the certificate/credentials presented. In the v4 world, you get your IP address and your router information all from the DHCP server, you end up on the right subnet in the right building for your job classification, and all is good. In the v6 world, your DHCP server hands you an IP address, but the client sees an entire spectrum of routers to choose from, with no idea of which one would be most appropriate to make use of. Do I use the one that's here in the same building as me, or do I use one that's several blocks away in an entirely different part of the campus?
The wonderful thing about modern wireless setups for enterprises is that you can allow your employees to all have their laptops configured to associate with the same SSID, and handle all the issues of assigning them to a particular subnet and vlan at the RADIUS/DHCPv4 level; you don't have to have different employees on different SSIDs for finance vs engineering vs HR vs sales. In v4, you can segment the employees very nicely after they've associated with the AP and give them all the necessary information for building in which they're in. V6 doesn't provide that ability; so, I associate with the AP, I get my IPv6 address, and then I look at which possible routers are announcing information about my subnet, and I see there's one in building B, one in building F, and one in building W, and I just randomly pick one, which may be nearby, or may be across the other side of campus. Furthermore, I also see all the announcements from routers for subnets I'm *not* a part of, cluttering up the spectrum. Rather than have routers spewing out "here I am" messages and taking up RF spectrum, I'd much prefer to explicitly tell clients "you're in sales, you're in building W, here's your IP address, and use the upstream router located in your building." No extra RF spectrum used up by routers all over the place saying "here I am", no issues of clients choosing a less-optimal upstream router and then complaining about latency and performance.
I can see where in some environments, routers using RAs to announce their presence to clients makes sense. Large-scale enterprise wireless isn't one of those; so, give us the *ability* to choose to explicitly give out router information via DHCPv6 in those situations. I'm not saying RAs are bad; I'm simply saying that the IETF plugging its ears to the needs of enterprises and claiming that we just don't 'get' how IPv6 is supposed to work and therefore they won't support assigning router information via DHCPv6 is an impediment to more rapid adoption.
And for those of you who say "but just use different SSIDs for every subnet in the company", please go do some reading on how SSIDs are beaconed, and what the effective limit is on how many SSIDs you can have within a given region of RF coverage. It's generally best to keep your SSID count in the single digits; by the time you get more than a dozen SSIDs, you're using up nearly half of your RF spectrum just beaconing the SSIDs.
Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
There¹s a mix of people at IETF, but more operator input there would be helpful. I have a particular draft in mind that is stuck between ³we¹d rather delay IPv6 than do it wrong² and ³be realistic about how people will deploy it."
Lee
I agree more operator input would be good; unfortunately, it's easier for management to say "let's just delay IPv6 until they get it working" than it is to justify sending employees to IETF meetings all over the place to explain why their model of how IPv6 should work isn't working out for the enterprise.
In effect, the IETF's stance is making it more expensive for companies to deploy IPv6 than simply stay on IPv4--so is it any wonder that people aren't moving faster?
Reduce the friction preventing companies from being able to do parallel, homologous IPv6 deployments, and you'll see faster movements. Right now, the insistence that IPv6 *must* be done differently, and *must* be done with an orthogonal network design and topology is an increased cost companies are unwilling to bear. And there is *NO* technical reason that DHCPv6 could not be allowed to provide identical information as DHCPv4; it is purely human stubbornness on the part of IETF members who insist that *their* model of how IPv6 should be deployed is better, and therefore they won't even allow the *option* to do it a different way.
Such hubris! Is it any wonder people avoid dealing with the IETF?
OK. Taking some deep breaths and calming back down now...
Fundamentally, Lee, the challenge is when you have multiple routers for a given subnet, how do you put some set of clients pointing to one router, and a different set of clients pointing to another router using RAs?
Thanks!
Matt