SLAAC(autoconfig) vs DHCPv6

---------- trejrco@gmail.com wrote: ------------

As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...

To try to stay operational about this, I have a reality testing question
I've used in IPv4 and, for that matter, bridged networks:

If you want to test a resource, be it the end user or an infrastructure
interface, how do you know how to foo it (foo being some value of ping,
traceroute, look it up in SNMP/NetFlow, etc)?

I submit that if you use dynamic assignment of any sort, you really have to
have DNS dynamic update, so you can use a known name to query the function
that's indexed by address. Otherwise, static addresses become rather
necessary if you want to check a resource.

This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?

Howard

Howard C. Berkowitz wrote:

To try to stay operational about this,

Hmmmm. I think this is an operational topic, but I can see how it would be seen as more of a strategic item.

I have a reality testing question
I've used in IPv4 and, for that matter, bridged networks:

I submit that if you use dynamic assignment of any sort, you really have to
have DNS dynamic update, so you can use a known name to query the function
that's indexed by address. Otherwise, static addresses become rather
necessary if you want to check a resource.
  
Naturally. DNS name would be required, or a static address. In an ISP/service provider environment I imagine that being able to hand out dynamic ranges would be useful. Having to handle that statically would be painful. :slight_smile:
This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?
  
l2ping works on bluetooth devices on Linux. Might work for other stuff as well. Not sure what Cisco offers in this regard.

Hey Scott,

From: "TJ" <trejrco@gmail.com>

As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...
----------------------------------------------------

I'm still an IPv6 wussie and would like to learn more before moving forward, so would anyone care to share info on experiences with this decision?

Here's some pro's and con's to both

SLAAC:
- widely implemented in host v6 stacks that have shipped
- widely implemented on v6 routers
- really, really, really broken: it didn't support handing out
   any DNS info until RFC 5006, thus SLAAC still requires human
   intervention on a client to make "teh v6 interwebs" work. It
   will probably be a painful wait until 5006 gets more widely
   implemented on hosts (if ever, for some) & routers.
- probably "faster" than dhcpv6 w/ tuning timers. Could be
   better for mobile thingys.
- supports RFC 3041 "security by obscurity" extensions.

DHCPv6
- doesn't ship w/ some OS's
- new (danger code), not all features implemented
- router support for dhcpv6 relay very limited
- advanced things like prefix delegation don't really seem to
   have been ironed out.

In case you weren't confused enough between the two, they are not
mutually exclusive. You can run both SLAAC and DHCPv6 at the same
time on the same L2.

Links for (2) dhcpv6 implementations:
http://klub.com.pl/dhcpv6/
http://www.isc.org/index.pl?/sw/dhcp/dhcp4_0.php

Cheers,
Dale

From: Scott Weeks [mailto:surfer@mauigateway.com]
Sent: Monday, August 18, 2008 3:34 PM
To: nanog@nanog.org
Subject: SLAAC(autoconfig) vs DHCPv6

---------- trejrco@gmail.com wrote: ------------
From: "TJ" <trejrco@gmail.com>

As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...
----------------------------------------------------

I'm still an IPv6 wussie and would like to learn more before moving forward,
so would anyone care to share info on experiences with this decision?

Which one?
"If we gave them static IPv4 addresses we will give them static IPv6 addresses"
Or
"SLAAC(autoconfig) vs DHCPv6"

For the first ... at the simplest, it is familiar and comfortable.
In general:
  Servers, Routers, Firewalls, Switches (atleast those with L3 addresses) == static address
  Hosts == dynamic ... either SLAAC or DHCPv6. Manual Configuration of hosts is a non-starter for most environments.

For the latter ... that gets more involved.
Many (most?) platforms do not support DHCPv6 client functionality. Ditto on the server side.
OTOH, SLAAC alone cannot currently give you DNS information ... a possible deal-breaker, that.
(Some work under way to change that, or the environment can cheat 0 rely on IPv4 transport for DNS :slight_smile: )

scott

HTH!
/TJ

From: Howard C. Berkowitz [mailto:hcb@netcases.net]
Sent: Monday, August 18, 2008 3:42 PM
To: nanog@nanog.org
Subject: RE: SLAAC(autoconfig) vs DHCPv6

To try to stay operational about this, I have a reality testing question
I've used in IPv4 and, for that matter, bridged networks:

If you want to test a resource, be it the end user or an infrastructure
interface, how do you know how to foo it (foo being some value of ping,
traceroute, look it up in SNMP/NetFlow, etc)?

I submit that if you use dynamic assignment of any sort, you really have to
have DNS dynamic update, so you can use a known name to query the function
that's indexed by address. Otherwise, static addresses become rather
necessary if you want to check a resource.

While I mostly agree, replace Dynamic DNS with "dynamic name resolution
services" (or, perhaps, a stable endpoint address) and I agree even more :).
Aside from static addresses, Dynamic DNS is one approach (currently the most
common).
  PNRP, LLMNR are other possible solutions (depending on the scope we
are talking about).

WRT the "stable endpoint" piece, tunneling can work here.
  Mobile IPv6, for example, starts off with my machine always being
reachable at the same address.
  Some tunnel providers also allocate stable addressing - i.e.
wherever I am in IPv4-land I still have the same IPv6 address.

This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?

I prefer Layer 11 - the money :slight_smile:
(8 = people, 9-politics, 10=religion, 11=money)

Howard

/TJ

From: Dale W. Carder [mailto:dwcarder@wisc.edu]
Sent: Monday, August 18, 2008 4:24 PM
To: surfer@mauigateway.com
Cc: nanog@nanog.org
Subject: Re: SLAAC(autoconfig) vs DHCPv6

Hey Scott,

From: "TJ" <trejrco@gmail.com>

As a general rule, most clients are following the "If we gave them
static
IPv4 addresses we will give them static IPv6 addresses"
(infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6
is a separate (albeit
related) conversation ...
----------------------------------------------------

I'm still an IPv6 wussie and would like to learn more before moving
forward, so would anyone care to share info on experiences with this
decision?

Here's some pro's and con's to both

SLAAC:
- widely implemented in host v6 stacks that have shipped
- widely implemented on v6 routers
- really, really, really broken: it didn't support handing out
  any DNS info until RFC 5006, thus SLAAC still requires human
  intervention on a client to make "teh v6 interwebs" work. It
  will probably be a painful wait until 5006 gets more widely
  implemented on hosts (if ever, for some) & routers.

Or rely on IPv4 to do the DNS part. I call this "cheating", but do not mean
to include the negative connotations that come with that word :).

- probably "faster" than dhcpv6 w/ tuning timers. Could be
  better for mobile thingys.
- supports RFC 3041 "security by obscurity" extensions.

DHCPv6
- doesn't ship w/ some OS's

And some vendors have publicly stated that they would never support DHCPv6.
While I may not fully believe them (never is a long time), that is atleast
an indication not to expect it "soon".

- new (danger code), not all features implemented
- router support for dhcpv6 relay very limited
- advanced things like prefix delegation don't really seem to
  have been ironed out.

In case you weren't confused enough between the two, they are not mutually
exclusive. You can run both SLAAC and DHCPv6 at the same time on the same
L2.

Indeed, Stateless DHCPv6 is exactly that. I should have mentioned that by
now - sorry!

Links for (2) dhcpv6 implementations:
http://klub.com.pl/dhcpv6/
http://www.isc.org/index.pl?/sw/dhcp/dhcp4_0.php

Cheers,
Dale

/TJ

- really, really, really broken: it didn't support handing out
any DNS info until RFC 5006, thus SLAAC still requires human
intervention on a client to make "teh v6 interwebs" work.

While I agree that it is bad that the DNS configuration issue took so long to fix, I wouldn't consider this a flaw of stateless autoconfiguration, which works extremely well. There have been many times that I was at conferences where the IPv4 DHCP wouldn't work so it was impossible to go online, while stateless autoconfig rarely creates any problems. (Although there could be connectivity problems upstream, though.)

DHCPv6
- doesn't ship w/ some OS's

Forget about it on XP, but it's in Vista. You can add it to BSD/Linux without too much trouble (are there good, bugfree implementations for those yet?) but Mac is a problem for prospective DHCPv6 users because the network configuration mechanisms are fairly proprietary and DHCPv6 isn't likely to be supported any time soon.

- new (danger code), not all features implemented
- router support for dhcpv6 relay very limited
- advanced things like prefix delegation don't really seem to
have been ironed out.

Actually the prefix delegation has worked just fine for me. This is the redeeming feature in DHCPv6.

In my opinion, DHCPv6 was severely misdesigned. For instance, there are stateful and stateless variations, and the _client_ has to choose which to use. DHCPv6 also doesn't give you a subnet prefix length or a default gateway, so you still need router advertisements (that are also used for stateless autoconfig). The latter can be considered a feature, but I'm guessing the lack of a subnet prefix other than the assumption that the whole world uses /64 has been giving DHCPv6 server implementers a lot of headaches.

In case you weren't confused enough between the two, they are not
mutually exclusive. You can run both SLAAC and DHCPv6 at the same
time on the same L2.

Of course there's no telling what exactly the clients are going to do in that case...

Iljitsch

Iljitsch van Beijnum wrote:

DHCPv6
- doesn't ship w/ some OS's

Forget about it on XP,

Hmmm. MS says otherwise: http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx

but it's in Vista. You can add it to BSD/Linux without too much trouble (are there good, bugfree implementations for those yet?)

Bugfree? Nothing is bugfree :slight_smile:

but Mac is a problem for prospective DHCPv6 users because the network configuration mechanisms are fairly proprietary and DHCPv6 isn't likely to be supported any time soon.

Hmmmm. I have yet to play with the Mac Ipv6 support (typing this on a Mac now I should try in my lab later). What auto configuration mechanisms are you referring to? Bonjour? Isn't there an RFC or two for Zeroconf?

From: Charles Wyble [mailto:charles@thewybles.com]
Sent: Monday, August 18, 2008 5:28 PM
To: nanog@merit.edu
Subject: Re: SLAAC(autoconfig) vs DHCPv6

Iljitsch van Beijnum wrote:

DHCPv6
- doesn't ship w/ some OS's

Forget about it on XP,

Hmmm. MS says otherwise:
http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx

Did you see somewhere on that site, that WinXP does DHCPv6?
I don't. And it would be wrong, to boot.
(Not just IPv6 support - that is one simple command ...)

but it's in Vista. You can add it to BSD/Linux without too much
trouble (are there good, bugfree implementations for those yet?)

Bugfree? Nothing is bugfree :slight_smile:

but Mac is a problem for prospective DHCPv6 users because the network
configuration mechanisms are fairly proprietary and DHCPv6 isn't
likely to be supported any time soon.

Hmmmm. I have yet to play with the Mac Ipv6 support (typing this on a Mac
now I should try in my lab later). What auto configuration mechanisms are
you referring to? Bonjour? Isn't there an RFC or two for Zeroconf?

No, I believe he is referring to the actual network configuration.
Not the (almost) automatic/automated service/device discovery ...

--
Charles Wyble (818) 280 - 7059

/TJ

Nope. XP does not support DHCPv6 - only Vista/Windows Server 2008 (and later) can do that.

Sean

Sean Siler wrote:

Nope. XP does not support DHCPv6 - only Vista/Windows Server 2008 (and later) can do that.

Sean

http://internecine.eu/systems/windows_xp-ipv6.html and http://internecine.eu/software/dibbler_dhcpv6.html discuss how to deploy dhcpv6 on xp. It's 3rd party but doable.

Forget about it on XP,

Hmmm. MS says otherwise: http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx

None of the XP systems here (even with all the latest service packs installed) seem to do DHCPv6.

but it's in Vista. You can add it to BSD/Linux without too much trouble (are there good, bugfree implementations for those yet?)

Bugfree? Nothing is bugfree :slight_smile:

Indeed. The Vista client has some real problems with retaining DNS info.

Antonio Querubin
whois: AQ7-ARIN

Yep - absolutely. I was referring to built-in support from the stack.

Dibbler is the primary third party provider we have seen for DHCPv6 support on downlevel clients.

Sean

Hmmm I'm getting "You don't have permission to access /systems/windows_xp-ipv6.html on this server."

Antonio Querubin
whois: AQ7-ARIN

Charles Wyble wrote:

This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?
  
l2ping works on bluetooth devices on Linux. Might work for other stuff as well. Not sure what Cisco offers in this regard.

The ideal solution would be OAM. Of course not everything supports that and it's not on by default either. Of all the things to turn off by default, this is one thing that I'd like to see on.

Justin

If anyone is aware of any bugs in ISC dhclient -6, please submit them
to dhcp-bugs@isc.org.

1. I think ARP is effectively a ping for a mac. It verifies connectivity on level 2 between two hosts. You have to be on the same segment though....

To make it work, you would have to know the mac address of the remote host, clear the arp table the local host, then send the ARP request out.

This would still require that each host have IP stacks in place with functioning IP addresses. Although ARP acts under IP, it still requires IP to function.

2. I think you might be able to fudge it using RARP, if you just look for signals sent to that address.

3. A kind of constant ping might be... if you knew the remote's MAC address you could poison the ARP table with an announcement, spoof the MAC locally, then do MITM stuff and relay communications.

4. Ok, after all that craziness I did a google search and found ARPING: http://en.wikipedia.org/wiki/Arping

ARPING still seems to rely upon a proper IP stack and address on both hosts.

Meh, your best bet might be just to scan your arp tables for the mac you are interested in. I think all NICs broadcast periodically saying "I am here". Passive ping.
--p

That's close. If you use dynamic assignment via DHCP (v4 or v6),
then you have a handy database of all the IPv4 addresses assigned and
whatever information you want to discern them by (if not by hostname)
that was available to the DHCP server at the time of assignment.
Strictly speaking, Dynamic DNS isn't even necessary, but it could be
reasonably handy (because IPv6 addresses do not pass 'the phone
test').

With technologies like SLAAC, tho, you are right. You're going to
have to give devices a means to register with the network
independently of their IP address allocation, because it only takes
one client to Router Solicit to configure multiple clients upon the
broadcast Router Advertisement reply. Unless you start sniffing for
their neighbor discovery probes (part of SLAAC is to ensure the new
address is not already in use), there's no transaction where the
resource(s) are assigned.

There is quite obviously a key distribution problem with that kind of
model, and if you have to manually configure a system to configure
itself dynamically, there is a significantly diminished reward.

At this point in the excercise, you may as well do what the rest of us
in the current SLAAC-only world have done; disable SLAAC and set v6
addresses (and DNS) manually. Welcome to 1985, the era DHCPv4 saved
us from.

But this leads you back to today's IPv6 operational problem; if you
need registered clients, then you can install any DHCPv6 software you
can find to get it via either its database or Dynamic DNS (quite a
lot of DHCPv6 server software supports Dynamic DNS). But you still
wont' have any DHCPv6 clients outside of Vista.

This is where the chicken meets the egg on our faces.