On Sun, Feb 27, 2011 at 11:53 PM, Franck Martin <franck@genius.com> wrote:
Oh... did not know about the heavy baggage...
No, when I first played with IPv6 only network, I found out that RD was silly, it gives an IP adddress but no DNS, and you have to rely on IPv4 to do that. silly, so my understanding is then people saw the mistake, and added some DNS resolution... Because the only option was to get DHCPv6 to get the DNS, but then why create RD in the first place?
So I found this whole saga, to put it mildly "stupid", like when people were talking about migrating to IPv6 but the root servers did not even have an IPv6 address: silly!
So I really don't care between RD and DHCPv6, what I care, is that they should be able to do their job correctly on their own.
Really, if you look back at the archives of this list these arguments are starting to get "silly" as you put it. It seems that every few months, as people discover that IPv6 isn't going away and they should brush up on it, people go through this process of debating the way IPv6 was designed as if it were 1998, and ultimately make posts like this. IPv6 is simple, elegant, and flexible. DHCPv6 was always a core component of IPv6 (just like ICMPv6 is a core components of IPv6, or should we throw ping and traceroute into RA as well...) This is why we have flags in RA to signal how addressing is done on a network for a prefix: A - Autonomous Flag, allows hosts to perform stateless addressing for a prefix. O - Other Flag, signals that additional configuration information is available (such as DNS) and DHCPv6 should be used. M - Managed Flag, signals that hosts should request a stateful address using DHCPv6. The real point, initially at least, for stateless addressing was to make the Link-Local scope work. It's brilliantly elegant. It allows all IPv6 configuration to be made over IPv6 (and thus use sane constructs like multicast to do it). Router Advertisements shift gateway and prefix configuration to the routers (which are the devices that actually know if they're available or not) rather than a DHCP server. If you set things up right, making a change to your RA will be seen by hosts almost instantly, and you won't need to go through the headache of waiting for DHCP leases to expire before hosts see that a network isn't available and let go of that route. One thing to keep in mind is that even though DHCPv6 and DHCP have a similar name, they're still pretty different. DHCPv6 was designed as part of IPv6. DHCP was an afterthought. Like many things in IPv6, they have been re-designed and included as a core component of IPv6. Don't go making assumptions that DHCPv6 was "added" to IPv6 to turn IPv6 into IPv4, and don't try to modify DHCPv6 to make that the case, please. What is needed now is protocol stability, and implementation of the current standards, not the re-writing of them mid-deployment. RDNSS is what I would consider "silly". IPv6 already allows for an environment in which stateless is used and DHCPv6 only provides DNS (and other) information. This is because none of the flags are exclusive. In fact, you can use both Stateless and DHCPv6 on the same network, and host will get two IPv6 addresses (for example to configure servers with pre-determined addresses). This was the design intent. If you don't use DHCPv6 to assign addresses and are using SLAAC, you can still use DHCPv6 to provide other information only, or "DHCPv6 Light", and this is already supported in most routing platforms to be configured right on the router. Implementation-wise, DHCPv6 Light and RDNSS have almost no difference. What RDNSS manages to do is embed DNS into RA (where it doesn't belong IMHO) seemingly for the sake of not calling it DHCPv6. Keeping DNS information out of RA is a Good Thing (which makes RDNSS a Bad Thing). Why? Because DNS might not always be the method we use for mapping names to addresses; it might see a rewrite like IP itself has seen, and there will likely be a desire to provide hosts with more configuration information. Looking DNS information into RA is a slippery slope. What's next, another option to RA for next-server information? DHCPv6 is separate from RA because they know that the needs for host configuration are more likely to change over time than IPv6 itself, and keeping them separate keeps IPv6 stable. The question isn't "Stateless or DHCPv6". The question is "Why are people implementing IPv6 without a core component?" That's pretty much like saying you support IPv6 but not including ICMPv6 or MLD. This isn't a war of Stateless vs. DHCPv6. They're both the same thing. They're both core components of IPv6, and they both provide specific, non-conflicting, functionality. The argument of "Having to implement DHCPv6 is more work" is "silly" for these same reasons. "Well I'm not going to support address scope because that's more work." Thankfully, with Apple seemingly supporting DHCPv6, that means Windows, Linux, Mac, and BSD will all have full IPv6 implementations, and if you don't want to use DHCPv6 for addressing you don't have to. If the goal was really to keep DNS simple for IPv6, rather than RDNSS, they should have written an autonomous anycast or multicast DNS spec rather than cluttering up RA with DNS server messages. RDNSS is a cancer IMHO and I hope we don't see it implemented. Just replace RDNSS with "DHCPv6 Light" and you get the same thing without breaking IPv6. Most of the people who want RDNSS wanted to avoid implementing DHCPv6, but its already been implemented, so I'm not sure what all the extra effort bought us, except that now we're seeing confused companies like Apple implement both RDNSS and DHCPv6 because they don't know which one will be needed. So what I'm saying here is that RDNSS is successful is doing the opposite of its goal: Instead of making IPv6 implementation more simple, they've made it more complex. DHCPv6 has nothing to do with "wanting to do things the way we always have". It has everything to do with "we might not always do things the same way we do today, so lets split this from being in RA". When it comes down to it, for hosts that provide content (servers) you'll always need a way of knowing that address. I'm sure manual IPv6 configuration works fine for you, but in something significant, say a VM cluster, I for one would rather not go back to the dark ages of manually configuring IPv6 addresses on each host. Privacy addressing is more to mask the MAC address of a host than to provide "privacy". This is because some systems are easily identifiable by their MAC address, such as Apple computers, and embedding that into the source IP provides potential attackers with a guess as to what the device is. That said, host that use both DHCPv6 and Stateless addresses will use their stateless address for new outgoing requests, by the way, effectively making the stateful address an alias. So I'm not sure what the issue is here. Apple is probably cringing at this thread going on for so long and not getting berried because of the inaccurate topic. :-) On Sun, Feb 27, 2011 at 11:53 PM, Franck Martin <franck@genius.com> wrote:
Oh... did not know about the heavy baggage...
No, when I first played with IPv6 only network, I found out that RD was silly, it gives an IP adddress but no DNS, and you have to rely on IPv4 to do that. silly, so my understanding is then people saw the mistake, and added some DNS resolution... Because the only option was to get DHCPv6 to get the DNS, but then why create RD in the first place?
So I found this whole saga, to put it mildly "stupid", like when people were talking about migrating to IPv6 but the root servers did not even have an IPv6 address: silly!
So I really don't care between RD and DHCPv6, what I care, is that they should be able to do their job correctly on their own.
----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Franck Martin" <franck@genius.com> Cc: "Matthew Palmer" <mpalmer@hezmatt.org>, nanog@nanog.org Sent: Sunday, 27 February, 2011 6:08:28 PM Subject: Re: Mac OS X 10.7, still no DHCPv6
Look, can we stop arguing about whether someone needs DHCP or not, whether they need SLAAC or not. Let's just get both solutions to a mature and useful state where a network administrator can pick the one that works best for their environment and move on.
Devices, routers, OSs, etc. should support both. The IETF should stop letting the two working groups focus on damaging the other protocol and we should stop treating this as a competition or a battle and start treating it as options to accomplish a task.
Owen
On Feb 27, 2011, at 1:25 PM, Franck Martin wrote:
Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no?
----- Original Message ----- From: "Matthew Palmer" <mpalmer@hezmatt.org> To: nanog@nanog.org Sent: Sunday, 27 February, 2011 4:06:29 PM Subject: Re: Mac OS X 10.7, still no DHCPv6
On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote:
Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS server information in an IPv6-only environment. Of course nobody else has implemented that yet, making Apple a "special case" host once again (I don't even think Cisco supports the option in their T series yet).
radvd and rdnssd work together on Linux nicely to provide RDNSS support. Works a treat.
- Matt
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/