On Sat, 26 Feb 2011, Joel Jaeggli wrote:

On 2/26/11 9:05 PM, Randy Bush wrote:

...

...

With copies out to developers we now have confirmation that Apple still hasn't included DHCPv6 in the next release of OS X.

what is it about ipv6 which attracts religious nuts?

you sure it's not macos (says joel from a v6 enabled mac).

On a more serious note, I can on my Ubuntu machine just "apt-get install wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in resolv.conf for dns-over-ipv6 transport, even though the connection manager knows nothing about it, at least dual stack works properly. Can one do the equivalent easy addition to OSX? -- Mikael Abrahamsson email: swmike@swm.pp.se

On Sat, 26 Feb 2011, Joel Jaeggli wrote:

On 2/26/11 9:27 PM, Mikael Abrahamsson wrote:

...

On Sat, 26 Feb 2011, Joel Jaeggli wrote:

...

On 2/26/11 9:05 PM, Randy Bush wrote:

...

...

With copies out to developers we now have confirmation that Apple still hasn't included DHCPv6 in the next release of OS X.

what is it about ipv6 which attracts religious nuts?

you sure it's not macos (says joel from a v6 enabled mac).

On a more serious note, I can on my Ubuntu machine just "apt-get install wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in resolv.conf for dns-over-ipv6 transport, even though the connection manager knows nothing about it, at least dual stack works properly.

Can one do the equivalent easy addition to OSX?

You can, the actual integration issue is that network mangler (on ubuntu/fedora etal) and the osX airport connection manager will give up on a subnet on which they can't obtain an ipv4 address in prefernce to one where they can... this can also be worked around but it makes v6-only operation (Assuming that were desired, or even a good idea at this point) something that the majority of the users wouldn't be able to achive without the default behavior changing.

I'm not that interested in v6 only, I'm after requiring DHCPv6 and disallowing SLAAC, which clients can use IPv6 then? List afaik: Can: Windows Vista/Win7 (default) Linux (with non-default software) *BSD (with non-default software) Probably: OSX (with non-default software) Can't: Windows XP Don't know: Symbian Android Apple iOS -- Mikael Abrahamsson email: swmike@swm.pp.se

* Mikael Abrahamsson

On Sat, 26 Feb 2011, Joel Jaeggli wrote:

...

You can, the actual integration issue is that network mangler (on ubuntu/fedora etal) and the osX airport connection manager will give up on a subnet on which they can't obtain an ipv4 address in prefernce to one where they can... this can also be worked around but it makes v6-only operation (Assuming that were desired, or even a good idea at this point) something that the majority of the users wouldn't be able to achive without the default behavior changing.

I'm not that interested in v6 only, I'm after requiring DHCPv6 and disallowing SLAAC, which clients can use IPv6 then?

List afaik:

Can: Windows Vista/Win7 (default) Linux (with non-default software) *BSD (with non-default software)

Actually, with Linux, you do not need any non-default software. For quite some time now, the GNOME NetworkManager have supported most IPv6 flavours: * Static addressing, * SLAAC (including the RDNSS option), * Information-only DHCPv6, * Stateful DHCPv6, and * Any combination of the above. The problem is only that IPv6 support is not enabled in the default connection profile. In the default case, the kernel will on its own do SLAAC, but you won't get any IPv6 resolvers used, nor will it be able to connect to a IPv6-only network, due to the fact that NetworkManager will shut down the interface if it do not get any IPv4 connectivity (at least on wireless connections). See: https://bugzilla.redhat.com/show_bug.cgi?id=538499 Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27

On Feb 27, 2011, at 1:56 AM, Mikael Abrahamsson wrote:

On Sat, 26 Feb 2011, Joel Jaeggli wrote:

...

On 2/26/11 9:27 PM, Mikael Abrahamsson wrote:

...

On Sat, 26 Feb 2011, Joel Jaeggli wrote:

...

On 2/26/11 9:05 PM, Randy Bush wrote:

...

...

With copies out to developers we now have confirmation that Apple still hasn't included DHCPv6 in the next release of OS X.

what is it about ipv6 which attracts religious nuts?

you sure it's not macos (says joel from a v6 enabled mac).

On a more serious note, I can on my Ubuntu machine just "apt-get install wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in resolv.conf for dns-over-ipv6 transport, even though the connection manager knows nothing about it, at least dual stack works properly.

Can one do the equivalent easy addition to OSX?

You can, the actual integration issue is that network mangler (on ubuntu/fedora etal) and the osX airport connection manager will give up on a subnet on which they can't obtain an ipv4 address in prefernce to one where they can... this can also be worked around but it makes v6-only operation (Assuming that were desired, or even a good idea at this point) something that the majority of the users wouldn't be able to achive without the default behavior changing.

I'm not that interested in v6 only, I'm after requiring DHCPv6 and disallowing SLAAC, which clients can use IPv6 then?

List afaik:

Can: Windows Vista/Win7 (default) Linux (with non-default software) *BSD (with non-default software)

Probably:

OSX (with non-default software)

Can't:

Windows XP

Don't know:

Symbian Android Apple iOS

Mikael, try: http://sourceforge.net/projects/wide-dhcpv6/ http://wouter.horre.be/doc/stateless-dhcpv6-on-mac-os-x or http://klub.com.pl/dhcpv6/ There are others out there. I prefer wide for now. Works on 10.6. Haven't tried it on 10.5. Tom

Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment? This is often required for legislation compliance. DHCP does this well. -- Leigh Porter On 27 Feb 2011, at 14:04, "Chuck Anderson" <cra@WPI.EDU> wrote:

On Sat, Feb 26, 2011 at 09:46:17PM -0800, Joel Jaeggli wrote:

...

On 2/26/11 9:27 PM, Mikael Abrahamsson wrote:

...

On a more serious note, I can on my Ubuntu machine just "apt-get install wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in resolv.conf for dns-over-ipv6 transport, even though the connection manager knows nothing about it, at least dual stack works properly.

Can one do the equivalent easy addition to OSX?

You can, the actual integration issue is that network mangler (on ubuntu/fedora etal) and the osX airport connection manager will give up on a subnet on which they can't obtain an ipv4 address in prefernce to one where they can... this can also be worked around but it makes v6-only operation (Assuming that were desired, or even a good idea at this point) something that the majority of the users wouldn't be able to achive without the default behavior changing.

NetworkManager on Fedora fully supports IPv6 now, including DHCPv6. You can easily configure it to require an IPv4 address or an IPv6 address or both to consider the connection successfull.

On Feb 27, 2011, at 10:22 PM, Mikael Abrahamsson wrote:

Which is one of the reasons why some of us want DHCPv6 support in hosts.

Also for traceback when hunting down compromised/abusive hosts. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde

On Sun, 27 Feb 2011, Steven Bellovin wrote:

I'm not saying there are no uses for DHCPv6, though I suspect that some of the reasons proposed are more people wanting to do things the way they always do, rather than making small changes and ending up with equivalent effort. I am saying that security is not a strong argument.

Well, rest assurend that you have plenty of people disagreeing with you. The again your views are shared by a lot of people for IPv4 as well, thus meaning it took until now before the IETF even hade a SAVI like working group to handle the security issues that has been around since forever but that was solved for IPv4 outside of IETF around 10 years ago but stil has no widespread implementation for IPv6 (but it's getting there). -- Mikael Abrahamsson email: swmike@swm.pp.se

I'm not saying there are no uses for DHCPv6, though I suspect that some of the reasons proposed are more people wanting to do things the way they always do, rather than making small changes and ending up with equivalent effort.

add noc and doc costs of all changes, please randy

On 02/28/2011 08:25 AM, Steven Bellovin wrote:

On Feb 28, 2011, at 1:10 21AM, Randy Bush wrote:

...

...

I'm not saying there are no uses for DHCPv6, though I suspect that some of the reasons proposed are more people wanting to do things the way they always do, rather than making small changes and ending up with equivalent effort.

add noc and doc costs of all changes, please

Sure. How do they compare to the total cost of the IPv6 conversion excluding SLAAC? (Btw, for the folks who said that enterprises may not want privacy-enhanced addresses -- that isn't clear to me. While they may want it turned off internally, or even when roaming internally, I suspect that many companies would really want to avoid having their employees tracked when they're traveling. Imagine -- you know the CEO's laptop's MAC address from looking at Received: lines in headers. (Some CEOs do send email to random outsiders -- think of the Steve Jobs-grams that some people have gotten.) You then see the same MAC address with a prefix belonging to some potential merger or joint venture target. You may turn on DHCPv6 to avoid that, but his/her home ISP or takeover target may not.)

One of the items we worried about at OLPC (not that I remember if we ended up doing anything about it), is that in some countries, kidnapping is a very serious problem. Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. It must be *possible* to be anonymous, even if some environments by policy won't provide service if you choose to be anonymous. - Jim

On 02/28/2011 08:44 AM, Dobbins, Roland wrote:

On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote:

...

Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue.

We already have this with MAC addresses, unless folks bother to periodically change them, do we not?

And we certainly discussed randomising MAC addresses, for exactly the reasons stated. - Jim

On Feb 28, 2011, at 9:01 PM, Joe Abley wrote:

By embedding the MAC into the layer-3 address, the concern is that the information becomes accessible Internet-wide.

Given the the toxicity of hotel networks alone, my guess is that it already is pretty much available Internet-wide, at least to those who stand to illicitly profit by it the most. ;> And let's not get started on IMEIs, ESNs, and MEIDs, heh. SMTP headers and various IM client sessions are also quite revealing, for that matter - and in near- or real-time, in many cases. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde

-----Original Message----- From: Jeff Kell [mailto:jeff-kell@utc.edu] Sent: Monday, February 28, 2011 8:49 AM To: Dobbins, Roland Cc: nanog group Subject: Re: Mac OS X 10.7, still no DHCPv6

...

On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote:

...

Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to

On 2/28/2011 8:44 AM, Dobbins, Roland wrote: periodically change them, do we not?

Not globally, no.

Jeff

Can someone explain what exactly the security threat is? If you are going to say that knowing the MAC address of the end device allows the "bad guy" to know what type of equipment you have and as such to attempt known compromises for said equipment, then please just don't reply. :) - Brian

On Mon, 28 Feb 2011 10:04:23 EST, Joe Abley said:

I don't think this has ever been cited as a global, general threat that must be eliminated (just as people are generally happy to use the same credit card as they move around the planet and don't generally stress about the implications).

It's not a global threat. However, it *is* a *specific* threat to some people. We support the ability of students to restrict "directory information" to various levels, from "don't list home address" to "we won't admit they are a student without a court order or other authorization". I happen to know that 299 students (out of roughly 7,000) in our graduating class currently have their privacy set high enough to exclude them from being listed in the program for the 2011 graduation ceremony. Sure would be a shame if the network itself insisted on making them trackable... (Some of these students are just privacy minded, but we have a fair number that are children of diplomats/etc, or are literally in hiding from ex'es or non-custodial parents and have restraining orders out - these people *really* don't want to be tracked/found...)

On 01/03/2011, at 1:23 AM, Brian Johnson wrote:

Can someone explain what exactly the security threat is?

If I see two IPv6 addresses which share the same 64 bit suffix, I can be reasonably certain that they both correspond to the same device because they'll both be generated by the same MAC address. Your IPv6 address has thereby become a token I can use to track your whereabouts, which is the kind of thing that privacy advocates often find upsetting. RFC4941 should be (but generally isn't) enabled by default. Having said that, implementation of RFC4941 is lossy. On MacOS, long-held TCP sessions time-out when a new privacy suffix is generated and the old one ages out. I'd have thought that a better outcome would be for old addresses to continue working until their refcount drops to zero.

If you are going to say that knowing the MAC address of the end device allows the "bad guy" to know what type of equipment you have and as such to attempt known compromises for said equipment, then please just don't reply. :)

It's not about that; there are already plenty of other attack vectors that can be used to find out someone's IP address, such as web-bugs, logfiles behind phishing and malware distribution websites, etc. The new attack vector which SLAAC with EUI64 creates is one of "trackability." I can't passively accumulate IPv4 logs which tell me which ISPs you've used, which cities you're in, which WiFi hotspots you've used, which companies you've worked at, which websites you've visited, etc. I can accumulate logs which tell me which IP addresses have done those things, but I can't (for example) correlate them to your personal smartphone. I can with IPv6. That's new, and (to my mind) threatening. We've not even begun to consider the attack vectors that'll open up. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

On 2/28/11 9:34 PM, Dobbins, Roland wrote:

On Mar 1, 2011, at 12:23 PM, Mark Newton wrote:

...

That's new, and (to my mind) threatening. We've not even begun to consider the attack vectors that'll open up.

given that rfc 3041 had it's 10th birthday in january there's nothing new about any of this.

I don't think it's new at all, given the amount of information available today that you already cite, down to and including sniffing on toxic hotel networks and the like.

Folks are already easily pwn3d to extremes - look at HB Gary. This doesn't constitute some huge new attack surface or information leakage - especially given the existence of VPNs/proxies, the tendency to store more and more data/apps on servers/in 'the cloud', and so forth.

In fact, the device one is actually using at any given moment and where one is located when using said device is becoming less and less relevant.

...

From a physical-security standpoint, leaky IM, SMTP headers, et. al. already give the game away.

We've been living in this situation for years. Nothing about EUI-64 changes this fact, IMHO. I dislike it immensely, but it isn't a game-changer, IMHO.

-----------------------------------------------------------------------

Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

The basis of optimism is sheer terror.

-- Oscar Wilde

On 2/28/11 6:48 AM, Jeff Kell wrote:

On 2/28/2011 8:44 AM, Dobbins, Roland wrote:

...

On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote:

...

Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to periodically change them, do we not?

Not globally, no.

As is, present in layer-3...

Jeff

On Feb 28, 2011, at 10:27 PM, Owen DeLong wrote:

Having a MAC address as a permanent identifier is a very different problem from having that MAC address go into a layer 3 protocol field.

Given the plethora of identifiable information already frothing around in our data wakes, I'm unsure this is as big a deal as it might initially seem, especially given the existence of VPNs and proxy servers. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde

On 27 Feb 2011, at 15:35, sthaug@nethelp.no wrote:

...

...

Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment?

You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't "get" an IPv6 address, it "takes" one.

...

This is often required for legislation compliance. DHCP does this well.

Which is one of the reasons why some of us want DHCPv6 support in hosts.

Agreed. In our environment Mac OSX hosts will either have to get the necessary DHCPv6 functionality, or the customer will have to buy a router (which can then get DHCPv6 PD from us, and offer RA/SLAAC on the LAN side).

SLAAC for our ISP customers just won't happen, for a lot of reasons.

I really do not get the lack of DHCPv6, the Apple 'it should be easy' is all very well and good, but it really does not help those people who have to run the networks at all. So for the foreseeable future SLAAC seems to be a requirement especially for WiFi operators for example who will have to support a multitude of unknown hosts. Has anybody found a usable method of achieving IPv6 address logs for such networks or will I just have to write some awful sniffer that spits out into a database that later on I'll have to correlate with WiFi AP RADIUS logs? -- Leigh Porter

On 27 Feb 2011, at 19:07, Antonio Querubin wrote:

On Sun, 27 Feb 2011, Mikael Abrahamsson wrote:

...

On Sun, 27 Feb 2011, Leigh Porter wrote:

...

Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment?

You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't "get" an IPv6 address, it "takes" one.

...

This is often required for legislation compliance. DHCP does this well.

Which is one of the reasons why some of us want DHCPv6 support in hosts.

So how does DHCP prevent a host from just taking or hijacking an IP address?

Antonio Querubin e-mail/xmpp: tony@lava.net

You can have devices that peek at the DHCP messages and then open filters so that you at least know that any host that pops up on the network has used DHCP to obtain an IP address. Now you cannot usually prevent somebody from later hijacking that IP address using a fake MAC unless you do something else as well but at least you have something of a statefull relationship between an host and the IP address it uses. -- Leigh Porter

In fairness, said device can do the same sort of inspection of SLAAC traffic. It just looks at neighbor discovery messages instead of DHCP messages.

<http://tools.ietf.org/html/draft-ietf-savi-fcfs>

Any known (existing) or planned implementations of this? Steinar Haug, Nethelp consulting, sthaug@nethelp.no

But the ND messages don't tell you anything other than the Mac address about which host it actually is. In theory, at least, snooping the DHCP messages might include a hostname or some other useful identifier. Owen On Feb 27, 2011, at 11:53 AM, Richard Barnes wrote:

In fairness, said device can do the same sort of inspection of SLAAC traffic. It just looks at neighbor discovery messages instead of DHCP messages.

<http://tools.ietf.org/html/draft-ietf-savi-fcfs>

On Sun, Feb 27, 2011 at 2:17 PM, Leigh Porter <leigh.porter@ukbroadband.com> wrote:

...

On 27 Feb 2011, at 19:07, Antonio Querubin wrote:

...

On Sun, 27 Feb 2011, Mikael Abrahamsson wrote:

...

On Sun, 27 Feb 2011, Leigh Porter wrote:

...

Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment?

You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't "get" an IPv6 address, it "takes" one.

...

This is often required for legislation compliance. DHCP does this well.

Which is one of the reasons why some of us want DHCPv6 support in hosts.

So how does DHCP prevent a host from just taking or hijacking an IP address?

Antonio Querubin e-mail/xmpp: tony@lava.net

You can have devices that peek at the DHCP messages and then open filters so that you at least know that any host that pops up on the network has used DHCP to obtain an IP address.

Now you cannot usually prevent somebody from later hijacking that IP address using a fake MAC unless you do something else as well but at least you have something of a statefull relationship between an host and the IP address it uses.

-- Leigh Porter

On Feb 28, 2011, at 7:35 PM, Tony Finch wrote:

It ought to be possible to look at SMB or mDNS messages to get more information about what the host claims to be...

We can't trust those, they're easily manipulated and/or situationally-irrelevant. Or not present at all, if the endpoint customer is security-conscious. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde

On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote:

...

This is often required for legislation compliance. DHCP does this well.

Does it really matter what address a customer has as long as it comes from the /64, /56 or /48 assigned to them?

You are assuming an access technology that lends itself to subnet-per-customer. I run a network with 50,000+ end users using ethernet-based access to the user's room. In IPv4, I run 1 or more subnets per building (depending on the number of rooms in the build). I use DHCP to assign IPs, and record the DHCP assignments allow me to trace users in the event of abuse complaints. I use DHCP Option82 to allow me to correlate multiple devices in a user's room. I feed the DHCP information into my bandwidth management platform to enforce different levels (i.e. speeds) of service per user depending on what they've purchased. I have yet to come up with a viable solution to do all of the above in IPv6 without using DHCPv6. At the moment, that means that OSX users are not going to get IPv6. Simon For IPv4, I use DHCP to

On Feb 27, 2011, at 2:39 PM, Mark Andrews wrote:

In message <20110227204511.GM27578@virtual.bogons.net>, Simon Lockhart writes:

...

On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote:

...

...

This is often required for legislation compliance. DHCP does this well.

Does it really matter what address a customer has as long as it comes from the /64, /56 or /48 assigned to them?

You are assuming an access technology that lends itself to subnet-per-custome r.

I run a network with 50,000+ end users using ethernet-based access to the user's room. In IPv4, I run 1 or more subnets per building (depending on the number of rooms in the build). I use DHCP to assign IPs, and record the DHCP assignments allow me to trace users in the event of abuse complaints. I use DHCP Option82 to allow me to correlate multiple devices in a user's room. I feed the DHCP information into my bandwidth management platform to enforce different levels (i.e. speeds) of service per user depending on what they've purchased.

I have yet to come up with a viable solution to do all of the above in IPv6 without using DHCPv6. At the moment, that means that OSX users are not going to get IPv6.

Have you *asked* your vendors for a alternate solution?

DHCP kills privacy addresses.

In many environments, this is a feature, not a bug.

DHCP kills CGAs.

In many environments, this is a feature, not a bug. I would, in fact, posit that some of the people complaining about the lack of DHCP are doing so precisely because of a desire to kill these things in their environment. Owen

In message <CA58D5C5-3826-4DA8-BCC6-5057AB912D5C@delong.com>, Owen DeLong writes:

On Feb 27, 2011, at 2:39 PM, Mark Andrews wrote:

...

...

On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote:

...

...

This is often required for legislation compliance. DHCP does this = well. =20 Does it really matter what address a customer has as long as it = comes from the /64, /56 or /48 assigned to them? =20 You are assuming an access technology that lends itself to = subnet-per-custome r. =20 I run a network with 50,000+ end users using ethernet-based access to =

...

user's room. In IPv4, I run 1 or more subnets per building (depending = on the=20 number of rooms in the build). I use DHCP to assign IPs, and record =

...

DHCP assignments allow me to trace users in the event of abuse = complaints. I use DHCP Option82 to allow me to correlate multiple devices in a = user's room. I feed the DHCP information into my bandwidth management platform to = enforce different levels (i.e. speeds) of service per user depending on what =

=20 In message <20110227204511.GM27578@virtual.bogons.net>, Simon Lockhart = writes: the the=20 they've

...

purchased. =20 I have yet to come up with a viable solution to do all of the above = in IPv6 without using DHCPv6. At the moment, that means that OSX users are = not going to get IPv6. =20 Have you *asked* your vendors for a alternate solution? =20 DHCP kills privacy addresses.

In many environments, this is a feature, not a bug.

...

DHCP kills CGAs. =20 In many environments, this is a feature, not a bug.

I would, in fact, posit that some of the people complaining about the = lack of DHCP are doing so precisely because of a desire to kill these things in = their environment.

Owen

Sure there are some envionments where it is a feature. But in many you really don't care what address the machine gets. You are actually looking for to tie the address(mac) to a accounting record and DHCP is the only currently available solution and rather than look for a better solution DHCP is being used. One could have the machine generate its own addresses and register them using DHCP. You get the accounting without throwing out the ability to do things like privacy addresses and CGA. The DHCP server can also prevent the machine using a reserved address for the few things on the net that need it. You also get IPv6 reverse maintenance thrown in for free. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Mon, 2011-02-28 at 09:39 +1100, Mark Andrews wrote:

DHCP kills privacy addresses. DHCP kills CGAs.

For temporary addresses couldn't a client clamp the upper limits of its received lifetimes to the desired lifetimes, then rebind instead of renew, sending a DECLINE if it gets the same address (as it presumably will)? The "temporaryness" would then be pretty much in the hands of the client (arguably where it belongs). That does kill the privacy aspect of temporary addresses, at least locally. Perhaps that is only a partial loss, as the addresses would still be "private" as far as the wider world was concerned. How does ISC DHCPv6 allocate addresses? Random, sequential...? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

In a message written on Mon, Feb 28, 2011 at 09:39:24AM +1100, Mark Andrews wrote:

Have you *asked* your vendors for a alternate solution?

DHCP kills privacy addresses. DHCP kills CGAs.

Not true. Some would like to use DHCPv6 to hand a host things like DNS servers, NTP servers, PXE boot information, domain name search paths, and the like. There's no reason once the host gets a DHCP address and that information it can't also generate and use a privacy address or CGA. While this thread has focused on folks who want to use DHCPv6 to preclude these items by for instance having switches and routers filtered to only the "allowed" address (assigned via DHCP) there's no requirement a network operator do that. DHCP has a couple of hundred defined options. Vendors have tried adding ONE to the RA protocol (DNS servers) as replacement functionality. That leaves them a few hundred options short, in my book. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Mon, 2011-02-28 at 12:57 +1100, Mark Andrews wrote:

Except in the senarios being described they are also blocking the other addresses. I would also think setting the "M" bit would prelude the host from generating such addresses as they are unmanaged.

I think the M flag says "you can get an address via DHCP" - it doesn't say "and don't get an address via any other means". From RFC 4861: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If you want to disable SLAAC, you instead use the AdvAutonomousFlag in the Prefix Information option included for the given prefix in the link's Prefix List.

...

DHCP has a couple of hundred defined options. Vendors have tried adding ONE to the RA protocol (DNS servers) as replacement functionality. That leaves them a few hundred options short, in my book.

Which is what the O bit was for.

Welll - the number of options defined so far for DHCPv6 is very small compared to the number of options defined for DHCPv4. I think that's what Leo meant. The "O" bit will avail you naught if you want, for example, a boot server address. I do think though, that assuming DHCP is the way to get some of these things might be shooting from the hip. Perhaps there is a better way, with IPv6? The difficulty is that now everyone is in a tearing hurry; they just want everything to work the exact same way, and they want it NOW. There is "suddenly" no time to work out better ways. And goodness knows there must be a better way to boot a remote image than delivering an address via DHCP! With apologies to the musical "Keating": "Give us back our comfy little network Take us back to safer days of yore Nothing alien or scary, la-di-da or airy-fairy Just put it back the way it was before..." Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

On Feb 28, 2011, at 9:16 PM, Leo Bicknell wrote:

Those who designed IPv6 appear to have ignored the problem space.

This is true of many, many aspects of IPv6. And those of us who didn't get involved in the process to try and address (pardon the pun, heh) those problems bear a burden of the responsibility for the current state of affairs. So, it's very obvious that there's a lot of work to be done in order to make pure IPv6 viable for a non-isignificant proportion of the user base (including spimes and such in that population). Dual-stack is an appropriate transitional mechanism to make some steps towards that goal in some circumstances, and so it shouldn't be summarily dismissed, that's all. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde

You can write script to poll routers for IPv6 neighbors, and store those in a database. That will get you the IPv6 to MAC association. Then poll L2 devices for MAC address tables for the MAC to port association. We've had such a system in place for a few years now to map addresses to ports, etc., it also checks for rogue RA. It's messy (and I don't like the extra load it causes on routers). If we had things like DHCPv6 snooping, RA guard (which you can implement with PACLs), and IPv6 source verification we wouldn't need it. Thankfully most of these are all in the pipeline. On Sun, Feb 27, 2011 at 5:32 PM, Karl Auer <kauer@biplane.com.au> wrote:

On Sun, 2011-02-27 at 14:47 +0000, Leigh Porter wrote:

...

Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment?

How do you define "what host"? If it's by MAC address (and you are not using temporary, cryptographic or random addresses), then the MAC is in the address the host ends up using.

Also, as someone else said, hosts don't "get" addresses via SLAAC - they generate them. That means that while you may be able to predict what they *will* use, you would need to snoop NDP to find out what they *are* using, and even more so for temporary, cryptographic and random addresses.

I have no experience of anything that actually does this, but it would be fairly simple to do. NDP will end up snooped in routers and switches for lots of reasons, so expect to see such features in real kit pretty soon. Make sure you let your vendor know what you want/need...

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au)                   +61-2-64957160 (h) http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On a more serious note, I can on my Ubuntu machine just "apt-get install wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in resolv.conf for dns-over-ipv6 transport, even though the connection manager knows nothing about it, at least dual stack works properly.

This is finally getting fixed now. NetworkManager 0.8.3, to be shipped in the upcoming Ubuntu 11.04 (Natty) seems to do the right thing, including using the OtherConfig-Flag in RA to trigger a stateless DHCPv6 request. Haven't tested stateful yet. Bernhard

One issue with this is that distributions like RHEL don't open DHCPv6 in the default firewall policy. On Mar 4, 2011 7:17 AM, "Jay Cornwall" <jay@jcornwall.me.uk> wrote:

On Fri, 4 Mar 2011 00:24:48 +0000 (UTC), Bernhard Schmidt wrote:

...

Mikael Abrahamsson <swmike@swm.pp.se> wrote:

...

On a more serious note, I can on my Ubuntu machine just "apt-get install wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in resolv.conf for dns-over-ipv6 transport, even though the connection manager knows nothing about it, at least dual stack works properly.

This is finally getting fixed now. NetworkManager 0.8.3, to be shipped in the upcoming Ubuntu 11.04 (Natty) seems to do the right thing, including using the OtherConfig-Flag in RA to trigger a stateless DHCPv6 request. Haven't tested stateful yet.

I've tested stateful configuration and it works correctly (with stateless/stateful and stateful only) in NetworkManager with ISC DHCP 4.

The DHCP client uses a dynamic DUID based on the link-local address and time. That's not quite as flexible as WIDE or Dibbler.

-- Jay Cornwall http://www.jcornwall.me.uk/

On Feb 27, 2011, at 1:30, Phil Regnauld <regnauld@nsrc.org> wrote:

Joel Jaeggli (joelja) writes:

...

You're going to have to perform stateless autconfiguration in ipv6 and provide an ipv4 nameserver at the very minimum for a long time, if you don't do it for macos you'll have to do it for windows xp...

One of those operating systems is 10 years old and unmaintained...

Which one has more machines in production? -- TTFN, patrick

You're going to have to perform stateless autconfiguration in ipv6 and provide an ipv4 nameserver at the very minimum for a long time

apple is gonna look very very st00pid on world ipv6 day. and a bunch of folk are considering not turning things off after that day. randy

On Feb 27, 2011, at 4:21 AM, Randy Bush wrote:

...

...

You're going to have to perform stateless autconfiguration in ipv6 and provide an ipv4 nameserver at the very minimum for a long time apple is gonna look very very st00pid on world ipv6 day. and a bunch of folk are considering not turning things off after that day.

on second thought, guess where the support calls are gonna go. our customer support lines, because we deliver zipless ipv6.

NOC: are you running a macintosh? User: yes, how did you guess? NOC: because it is broken. get vista.

randy

While I'm as big a fan of IPv6 as anybody, I think in a comparison of relative brokenness, Mac comes out quite favorably compared to Vista in spite of their DHCPv6 deficiencies. Owen

(I'm just waiting for Apple's lawyers to try an get names out of me...) But yes, it does appear that Apple is addressing the issue: ----8<---- cat /etc/ip6addrctl.conf # default policy table based on RFC 3484. # usage: ip6addrctl install path_to_this_file # # $FreeBSD$ # #Format: #Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 ----8<---- On Sun, Feb 27, 2011 at 6:41 PM, Tore Anderson <tore.anderson@redpill-linpro.com> wrote:

* Owen DeLong

...

On Feb 27, 2011, at 4:21 AM, Randy Bush wrote:

...

NOC: are you running a macintosh? User: yes, how did you guess? NOC: because it is broken.  get vista.

While I'm as big a fan of IPv6 as anybody, I think in a comparison of relative brokenness, Mac comes out quite favorably compared to Vista in spite of their DHCPv6 deficiencies.

Absolutely not. Mac OS X does not do proper source address selection according to RFC 3484. That makes it do things like preferring the use of link-local IPv6 addresses when connecting to global dual-stacked destinations, which of course won't work - as a result a 75 second long timeout is incurred for every single outgoing TCP connection. Versions earlier than 10.6.5, still in use by a considerable amount of users, will also prefer the use of 6to4 to IPv4, again something which is causing lots of brokenness. (Windows ICS is responsible for causing lots of OS X hosts to have 6to4 addresses in the first place, though.)

OS X also has a bug that will make it interpret a router lifetime of 0 in a RA as infinite, causing more troubles when found behind IPv6 CE routers using ULAs in compliance with I-D.ietf-v6ops-ipv6-cpe-router, one example of which is the AVM FritzBox as far as I understand.

See also:

http://getipv6.info/index.php/Customer_problems_that_could_occur http://fud.no/ipv6/snapshot-20101221/gnuplot/noosx-t10-historic.png

My guess is that about 70-80% of the users calling Randy and others to report problems on «World IPv6 Day» will be running Mac OS X.

Ray: Do you know if RFC 3484 has been implemented in OS X 10.7?

-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Feb 27, 2011, at 3:41 PM, Tore Anderson wrote:

* Owen DeLong

...

On Feb 27, 2011, at 4:21 AM, Randy Bush wrote:

...

NOC: are you running a macintosh? User: yes, how did you guess? NOC: because it is broken. get vista.

While I'm as big a fan of IPv6 as anybody, I think in a comparison of relative brokenness, Mac comes out quite favorably compared to Vista in spite of their DHCPv6 deficiencies.

Absolutely not. Mac OS X does not do proper source address selection according to RFC 3484. That makes it do things like preferring the use of link-local IPv6 addresses when connecting to global dual-stacked destinations, which of course won't work - as a result a 75 second long timeout is incurred for every single outgoing TCP connection. Versions earlier than 10.6.5, still in use by a considerable amount of users, will also prefer the use of 6to4 to IPv4, again something which is causing lots of brokenness. (Windows ICS is responsible for causing lots of OS X hosts to have 6to4 addresses in the first place, though.)

OS X also has a bug that will make it interpret a router lifetime of 0 in a RA as infinite, causing more troubles when found behind IPv6 CE routers using ULAs in compliance with I-D.ietf-v6ops-ipv6-cpe-router, one example of which is the AVM FritzBox as far as I understand.

You're talking about IPv6-specific brokenness. I'm talking about overall OS brokenness. On IPv6, yes, Micr0$0ft actually (finally) got something mostly right. On just about everything else... Windows... Nah, can't say I miss it at all. Owen

SLAAC is fine (even great) for small environments. For a lot of enterprise (or in our case, academic) networks you really want the central control of what addresses hosts get. Saw some mention of being unsure that it was possible to disable SLAAC. Every OS I've tested so far respects the A flag (which signals whether a prefix can be used for SLAAC or not) of an RA, so of course you can disable SLAAC (right from the prefix you advertise). Apple has said before that they don't want to use DHCPv6 because IPv6 should be "easy". I'm not really sure what about DHCPv6 is difficult. 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). Once again, SLAAC and RDNSS is great for quick, small, plug-and-play networks, and maybe even the opposite end: very very large (mobile) networks. But DHCPv6 is a powerful tool and one that shouldn't be thrown out. With SLAAC, as soon as you enable it every host on a network starts talking IPv6, by disabling SLAAC and using DHCPv6, you can selectively respond to hosts and do a phased deployment, enabling IPv6 on a per-host basis. Even though we have good native IPv6 available, we've adopted a DHCPv6 only deployment model. It works great for Windows and Linux systems, and even Android devices (I believe the iPhone even supports DHCPv6), really too bad that OS X doesn't support it because on our network it means they won't be getting IPv6 anytime soon. On Sun, Feb 27, 2011 at 8:05 AM, TR Shaw <tshaw@oitc.com> wrote:

On Feb 27, 2011, at 6:27 AM, Randy Bush wrote:

...

...

You're going to have to perform stateless autconfiguration in ipv6 and provide an ipv4 nameserver at the very minimum for a long time

apple is gonna look very very st00pid on world ipv6 day.  and a bunch of folk are considering not turning things off after that day.

Now why would you say that, Randy?  My home is dual stacked with a IPv6 tunnel to HE at my router. All off the shelf. No special config. All Apple. So whats the beef?

Tom

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

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

On Mon, 28 Feb 2011, Karl Auer wrote:

Well - that draft very recently (i.e., only a few months, if that) became standards track, so it'll be a while before it's built into everything as a matter of course, but yes, it's "fixed". RFC 6109. ^ Maybe you mean RFC 6106?

Antonio Querubin e-mail/xmpp: tony@lava.net

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

The documents are done, but, I would argue that neither provides a mature set of features. Yes, they've (sort of) resolved the DNS server issue for SLAAC, but, that's recent and getting it into vendor support will be nice. The lack of NTP and certain other options in SLAAC is still a disappointment and I would argue that a fully matured SLAAC process would include a mechanism for specifying extensible choices of things. For DHCP, the lack of ability to deliver routing policies or recommendations through DHCP is a roadblock for some deployments which is still in place in the documents and should be fixed to produce a mature implementation. Owen On Feb 27, 2011, at 3:23 PM, Joel Jaeggli wrote:

On 2/27/11 3:08 PM, Owen DeLong wrote:

...

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.

The documents are done at least for sufficient pieces to make it work. it's in the hands of vendors and has been for a while. The simple fact is that if you want to do it a particular way and you have an installed base that doesn't support doing it that way, then you're not doing it that way.

...

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

On 02/27/2011 15:08, Owen DeLong wrote:

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.

Speaking as an OS implementor, no, please don't do that. :) Let SLAAC be what it is, and give DHCPv6 feature parity with DHCPv4. Having all options supported in both methods is N-squared complexity for OS developers, never mind how difficult it's going to make actually using the stuff. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/

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/

On 28/02/2011 13:52, Ray Soucy wrote:

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).

Wonderful, brilliant design.

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.

Yes, it's all brilliant, wonderful. Elegant too, this idea of having two sets of protocols, because two is always better than one. It provides balance. I will be a lot more sympathetic about listening to arguments / explanations about this insanity the day that the IETF filters out arp and ipv4 packets from the conference network and depends entirely on ipv6 for connectivity for the entire conference. "But we couldn't do that??!?!", I hear you say. I understand completely. Nick

On Feb 28, 2011, at 9:59 PM, Joe Abley wrote:

There's no point worrying about v6-only operations if we can't get dual-stack working reliably.

I think this is the most insightful, cogent, and pertinent comment made regarding IPv6 in just about any medium at any time. [Yes, I know that dual-stack brings its own additional complexities to the table, but there really isn't any other choice, is there?] ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde

On 2011-02-28, at 10:27, Nick Hilliard wrote:

On 28/02/2011 14:59, Joe Abley wrote:

...

I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably.

That's "dual-stack" as in "dual-stack-except-one-of-the-stacks-really-doesn't-work-properly-so-we'll-fudge-around-it"? :-)

You're describing where we are. I'm talking about where I think we should be planning to arrive.

Look, my original point is that RA is a brilliant solution for a problem which never really existed. Now, can we all just ignore RA and work towards DHCPv6 because that's what's actually needed in the real world?

RA and DHCPv6 work together. It's different from DHCP in IPv4. Run with it. Sending people back to the drawing board at this late stage in the game (a) isn't going to happen and (b) isn't going to help anybody.

We haven't got there because I can't plug in my laptop into any arbitrary ipv6-only network and expect to be able to load up ipv6.google.com.

Is that too high a standard to work towards? :-)

As I thought I mentioned, yes. Forget v6-only right now. Dual-stack is an operationally-harder problem, and it's a necessary prerequisite. Joe

On Feb 28, 2011 8:45 AM, "Owen DeLong" <owen@delong.com> wrote:

On Feb 28, 2011, at 7:34 AM, Joe Abley wrote:

...

On 2011-02-28, at 10:27, Nick Hilliard wrote:

...

On 28/02/2011 14:59, Joe Abley wrote:

...

I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably.

That's "dual-stack" as in

...

You're describing where we are. I'm talking about where I think we

should be planning to arrive.

...

Your description sounds more like where we should be making a plane change. The eventual destination is IPv6-only. Dual-stack is a temporary stopover along the way. However, you are partially right in that we should be focusing on arriving at the first stop-over until we arrive there. Then we can start navigating from there to the final destination.

...

...

Look, my original point is that RA is a brilliant solution for a

"dual-stack-except-one-of-the-stacks-really-doesn't-work-properly-so-we'll-fudge-around-it"? :-) problem which never really existed. Now, can we all just ignore RA and work towards DHCPv6 because that's what's actually needed in the real world?

...

RA and DHCPv6 work together. It's different from DHCP in IPv4. Run with

it. Sending people back to the drawing board at this late stage in the game (a) isn't going to happen and (b) isn't going to help anybody.

...

And the model breaks badly at layers 8-10 in most enterprises and many other organizations.

...

...

We haven't got there because I can't plug in my laptop into any arbitrary ipv6-only network and expect to be able to load up ipv6.google.com .

Is that too high a standard to work towards? :-)

As I thought I mentioned, yes. Forget v6-only right now. Dual-stack is an operationally-harder problem, and it's a necessary prerequisite.

For some situations at this point, that may not actually be true. It will be soon enough that it won't even be possible.

Owen is right. Ipv6-only is a very near term reality for networks with very fast growing edges like mobile phones and wireless machine to machine communications. It is not prudent to install an electricity meter today with a 30 year expected life span ... and include ipv4. These systems are being deployed today as ipv6 only, not in the future. Also, you can expect many types of mobile phones to be ipv6-only soon. Ipv4 is not going away, dual stack fell short of being the universal transition mechanism but is still useful in many palaces -especially content hosts, and ipv6-only will pop up soon in as many places as it possibly makes sense. Remember, from a network planner / designer / architect perspective, ipv4 is not a resource for future network growth.

Owen

On 28/02/2011 15:45, Dobbins, Roland wrote:

At that moment, the master was enlightened.

One day a master from another monastery came upon Dobbins and Abley as they were watching a 14 year-old cripple learning how to fly. "I do not believe we should waste time teaching children to walk", said Abley. "Indeed not", agreed Dobbins, "a waste of time and a distraction from the long term goal of flight. We have kept the child restrained from birth so that he can concentrate on the loftier ideal". The sojourner then seized the book from the child, flung it at Abley and Dobbins, called social services to lodge a complaint about child neglect, then stalked off in disgust, rolling his eyes and muttering under his breath about the rank stupidity of humanity. At that moment, Dobbins and Abley were enlightened. Nick

On Feb 28, 2011, at 6:59 AM, Joe Abley wrote:

On 2011-02-28, at 09:51, Nick Hilliard wrote:

...

I will be a lot more sympathetic about listening to arguments / explanations about this insanity the day that the IETF filters out arp and ipv4 packets from the conference network and depends entirely on ipv6 for connectivity for the entire conference.

It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably.

I disagree. Those of us who know what it costs to do double maintenance on a continuing basis would like to drive a stake through the heart of IPv4 sooner rather than later. IPv6-only viability is the real goal. This is, in the long run, a transition from v4 to v6. Dual-stack is an interim stop-gap, not an end solution. Dual stack is mostly working reliably at this point. There are some improvements needed in IPv6 for enterprises and they are needed for both dual stack and for IPv6 only, so, I'm not sure why that becomes particularly relevant to this thread. However, we should always keep our eye on the prize as it were. That's the eventuality of realizing huge cost savings (lower CAM utilization, better scaling, etc.) of a v6-only world.

[I also find the knee-jerk "it's different from IPv4, the IETF is stupid" memes to be tiring. Identifying questionable design decisions with hindsight is hardly the exclusive domain of IPv6; there are tremendously more crufty workarounds in IPv4, and far more available hindsight. Complaining about IPv6 because it's different from IPv4 doesn't get us anywhere.]

How about attempting to point out the areas where IPv6 could be improved, which, is how I regard most of this thread. Owen

It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably.

facile but fallacious fanboyism o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. o if ipv6 can not stand on its own, then dual-stack is a joke that will be very un-funny very shortly, as one partner in the marriage is a dummy. randy

...

o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own.

Do you think I was suggesting that IPv6 as a protocol doesn't need to be able to stand on its own two feet?

you may want to read your words and the thread which followed. randy

On Feb 28, 2011, at 12:34 PM, Joe Abley wrote:

On 2011-02-28, at 15:27, Randy Bush wrote:

...

o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own.

Do you think I was suggesting that IPv6 as a protocol doesn't need to be able to stand on its own two feet? Because I wasn't; that's patently absurd.

It is both absurd and pretty much exactly what you said.

However, a fixation on v6-only operation makes no sense for general-purpose deployment when most content and peers are only reachable via IPv4.

I guess this is a matter of perspective. For some of us that already have complete dual stack deployments, focusing on the issues present in IPv6-only operation is just the next logical step. In some cases, I would say that the v6-only considerations are well worth considering as you prepare to deploy dual-stack so that you don't deploy dual-stack in such a way as to create unnecessary inter-protocol dependencies that will hurt you later. The reality is that IPv6-only networks are not likely in the foreseeable future is only a true statement if your foreseeable future ends in the past. There are already a certain number of functional operating deployed IPv6-only networks. Further, it's not going to be more than a few months before we start seeing networks that have very limited or degraded IPv4 capabilities, if any, due to the inability to grant addresses to new networks in some areas.

I appreciate that there are walled gardens, captive mobile applications, telemetry networks and other niche applications for which v6-only networks make sense today. I'm not talking about them. I'm talking about the network that supports what the average user thinks of as the Internet.

And how do you think the average residential end user is going to see the IPv4 internet next year?

The immediate task at hand is a transition from IPv4-only to dual stack, regardless of how many NATs or other transition mechanisms the IPv4 half of the dual stack is provisioned through.

Yes, but, given the nearly immediate runout of IPv4, I would say that doing so in a way that best facilitates IPv6-only hosts being functional is very much worthy of consideration in this process. Owen

Small (say, under 50,000 customer) ISPs in my experience have a planning horizon which is less than five years from now. Anything further out than that is not "foreseeable" in the sense that I meant it. I have much less first-hand experience with large, carrier-sized ISPs and what I have is a decade old, so perhaps the small ISP experience is not universal, but I'd be somewhat surprised giving the velocity of the target and what I perceive as substantial inertia in carrier-sized ISPs whether there's much practical difference.

Ready or not, IPv6-only (or reasonably IPv6-only) residential customers are less than 2 years out, so, well within your 5-year planning horizon, whether those ISPs see that or not. Denial is an impressive human phenomenon.

So, what's a reasonable target for the next five years?

In five years we should be just about ready to start deprecating IPv4, if not already beginning to do so.

1. Deployed dual-stack access which interact nicely with consumer CPEs and electronics, the IPv4 side of the stack deployed through increased use of NAT when ISPs run out of numbers.

Icky, but, probably necessary for some fraction of users. Ideally, we try to avoid these multi-NAT areas being done in such a way that the end user in question doesn't also have reasonably clean IPv6 connectivity.

2. IPv6-only access, CPE and hosts, with some kind of transition mechanism to deliver v4-only content (from content providers and v4-only peers) to the v6-only customers.

This is, IMHO, preferable to option 1.

Perhaps it's because I've never seen a NAT-PT replacement that was any prettier than NAT-PT, but I don't see (2) being anything that a residential customer would buy before 2016. Perhaps I'm wrong, but I don't hear a lot of people shouting about their success.

Personally, I think DS-Lite is the cleanest solution, but, it isn't without its issues. The reality is that post-runout IPv4 is going to be ugly, regardless of whether it's NAT64 ugliness, LSN ugliness, or DS-LITE ugliness. IPv4 is all about which flavor of bitter you prefer at this point. The sweetness is all on IPv6.

Note, I'm not talking about the ISPs who have already invested time, capex and opex in deploying dual-stack environments. I'm talking about what I see as the majority of the problem space, namely ISPs who have not.

The majority of the problem space IMHO is end-user-space at ISPs that have put at least some dual-stack research effort in, but, haven't come to solutions for end-users. However, we're less than 2 years away from seeing what happens in those environments without IPv4. Owen

On Feb 28, 2011, at 5:35 PM, Dobbins, Roland wrote:

On Mar 1, 2011, at 7:00 AM, Owen DeLong wrote:

...

In five years we should be just about ready to start deprecating IPv4, if not already beginning to do so.

That's been said about so many things, from various legacy OSes to other protocols such as SNA and SMB/CIFS.

None of those things are as prevalent as IPv4 is today. And yet, they're still around to haunt us.

I said beginning to turn it off, not done with it.

I think we're going to be dealing with IPv4 for a long, long time - far longer than two years.

Oh, I agree. However, I think in 5 years we'll start seeing a few residential providers announcing things like IPv4 is now a $20/month optional service. Owen

On Feb 28, 2011, at 6:38 PM, Majdi S. Abbas wrote:

Anyone care to start the IPv4 dead pool, Price is Right style, for when the last v4 NLRI is removed from the DFZ?

That's funny, I don't care what galaxy you're from :) -b

From: Randy Bush Sent: Monday, February 28, 2011 12:27 PM To: Joe Abley Cc: NANOG Operators' Group Subject: Re: Mac OS X 10.7, still no DHCPv6

...

It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably.

facile but fallacious fanboyism

o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own.

o if ipv6 can not stand on its own, then dual-stack is a joke that will be very un-funny very shortly, as one partner in the marriage is a dummy.

randy

Dual stack isn't always the best approach. For networks that pass a large amount of traffic to a relatively small number of destinations, NAT64/DNS64 on a native v6 platform might be a better migration approach. If 90% of your traffic is v6, it is probably less trouble to use NAT64/DNS64 to reach that 10% than it is to dual-stack. Networks such as the sort described above would be expected to see the majority of their traffic migrate very quickly to v6 once only a few remote networks are v6 capable. This is a case where the pain is front-loaded. The amount of NAT64/DNS64 required to support such a topology is great at first, then quickly steps down as the destinations exchanging the most traffic become v6 capable, and then gradually tails off as the outliers catch up. G

On Feb 28, 2011 12:28 PM, "Randy Bush" <randy@psg.com> wrote:

...

It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably.

facile but fallacious fanboyism

o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own.

o if ipv6 can not stand on its own, then dual-stack is a joke that will be very un-funny very shortly, as one partner in the marriage is a dummy.

+1 Well said. V6 needs to stand on its own. Cb

randy

On 2/28/11 6:51 AM, Nick Hilliard wrote:

I will be a lot more sympathetic about listening to arguments / explanations about this insanity the day that the IETF filters out arp and ipv4 packets from the conference network and depends entirely on ipv6 for connectivity for the entire conference.

Oddly enough the meeting NOC is in the business of providing services to customers and we generally assume that to be with the highest availability and minimum breakage feasible under the circumstances...

"But we couldn't do that??!?!", I hear you say.

I would direct your attention to the ietf-v6ONLY SSID present during the meeting and ask you to ponder what purpose it serves.

I understand completely.

I am mystified.

Nick

Really, if you look back at the archives of this list these arguments are starting to get "silly" as you put it.

Yes and no...

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.

This may apply to some fraction of posters, but, I think many of the posters in this thread are actually fairly knowledgeable on IPv6.

IPv6 is simple, elegant, and flexible.

Parts of it are. Other parts are rigid, inflexible, and represent design decisions only theorists could love.

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...)

The intertwining of RA/DHCPv6 as it currently stands in IPv6 is an example of a design decision only theorists could love. In the real world, you have organizations where the people that manage hosts and host policy are not the people that run routers. In such environments, creating this kind of cross-organizational dependency that requires a constant coordination of even trivial changes on either side is far from optimal.

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.

That's all well and good, but, when you consider the real world implications, it starts to break down in most organizations... Now, the people that run the routers have full control over the selection of addressing schemes for the network. The people who set host policy have no control short of statically configuring the hosts or getting buy-in from the people that run the routers for their particular preference in address selection methods. Yes, in a theoretical world, everyone gets along and cooperates easily and stuff just works out with whatever decision is agreed upon. In the real world, this becomes a constant source of tension between the two groups and increases workload on both sides of the equation unnecessarily.

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).

All well and good, but...

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.

Which also means: 1. Multiple subnets on the same media that are intended for different hosts and have different routers are no longer feasible. (Yes, you can argue they're less than desirable in IPv4 and I would agree, but, they exist in the real world for a variety of layer 8-10 reasons and re-engineering an organization to make it fit into IPv6 is non-trivial). 2. RA has the problem of treating all routers claiming to have the same priority are of equal value to all hosts. Routers are considered fully interchangeable units and it is assumed that all routers are a viable path to everything. DHCPv4 actually provides facilities for dealing with more complex topologies where different destinations may be in different directions from different hosts. It also allows for providing different default gateways to different hosts based on policy decisions. Yes, in the most basic cases, RA can be superior to getting routing information from DHCP. However, in the real world, there are many cases where it simply breaks things and is a step backwards from capabilities in use in IPv4.

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.

While you have some things right in the first half of that paragraph, there are real world problems with the approach in the second half and there are changes that are needed. RDNSS is a positive step in the right direction (making router-centric host configuration more viable). Making server-centric configuration more viable is also necessary.

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.

That's all great in a purely theoretical world or a small organization. In the real world, there are many organizations for whom that set of tradeoffs and combination of dependencies is far from optimal.

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.

Which is a major change in the administrative boundaries for the vast majority of enterprises. Such changes may not be so welcome at the layer 8-10 levels of the stack and may, indeed, create substantial resistance to deployment.

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.

Only in theoretical implementations or implementations where the routers and host policy are administered by the same organization.

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?

Which is why it would be better if RA supported a more flexible set of host configuration options rather than just cobbling DNS onto it.

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.

I guess that really depends on your perspective. In the real world, it does a better job of keeping IPv6 from getting deployed in the enterprise.

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 framing of the issue utterly ignores the reality of how things are handled in the real world and what happens in the enterprise environment across organizational boundaries.

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."

It certainly was such a war for some time in the IETF and it was carried out in a way that much damage was done to both sides of the equation. The end result is a construct with a very limited set of choices for implementers almost all of which include cross-organizational interdependency in most enterprise environments that will create continuing friction and exacerbate the usual level of dysfunction.

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.

However, if you want to put host policy completely in the hands of the host administrators, you still can't. If you want to have the router administration group provide a complete set of host parameters, you still can't. The only way to provide a complete set of host configuration information through automated processes is to get some fraction from the routers and some fraction from other servers. This should be improved.

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.

We can agree to disagree.

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.

True, as far as it goes, but, there is also an issue of not wanting to completely redesign the org-chart because IPv6 is utterly dysfunctional with the current organizational boundaries. In some organizations, you have to get up to the point of a VP before you find common management shared by the groups that have to cooperate in the current implementation. The average VP regards the details of host configuration relatively below his pay grade and will likely consider any protocol that requires major changes to his org chart to be, well, broken.

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.

Uh, no, it's more to mask the MAC address of devices that move around so that you can't track their movement easily by matching up the last 64 bits of their IPv6 address and using the first 64 as a location identifier.

Apple is probably cringing at this thread going on for so long and not getting berried because of the inaccurate topic. :-)

Whether or not Apple is cringing, this thread (or something like it) will probably continue until theory and implementation in IPv6 advance to the point of matching reality. Owen

On 2/27/2011 11:53 PM, Franck Martin wrote:

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?

Well, for the malware authors, it really is an awful lot of trouble to go broadcasting gratuitous ARPs claiming to be the default gateway, and then blasting those spoofed gratuitous ARPs at the gateway claiming to be the clients, and having to do all that packet-forwarding foo just to get to be the man-in-the-middle... when you can just generate an RA and you don't even have to set the evil bit!! And why bother with all those silly DNS-changer malware pointing the resolvers off to Inhoster-land so you can provide your own interesting answers for interesting names you'd like to phish, when you can just sit there and listen on the DNS anycast address and answer the ones you want!! And why bother parsing out the Facebook friends or AOL buddies or MSN contacts list to spew out those phishing URLs to everybody we know, when we can just sit back and let Bonjour/Rendezvous/iChat do all the work for us? Plug and Play malware is the future :-) Jeff