Archive for the ‘DHCPv6’ Category

No DHCPv6 for Snow Leopard? :-(

Sunday, September 13th, 2009

Well since the release of MacOS X Snow Leopard has come and gone with no one exclaiming “DHCPv6!” I’m assuming MacOS X still doesn’t support it 🙁 Unfortunate. It seems there must be a behind the scenes reason why DHCPv6 hasn’t been ported to MacOS X; I’d love to know what this reason is.

Wrinkles in creating a DHCPv6-only world

Wednesday, August 22nd, 2007

As currently implemented, router advertisements do not support options for DNS server information, necessitating DHCPv6 for acquiring DNS server information. Tim Chown noted in a presentation before the Dynamic Host Configuration (dhc) and IPv6 Operations (v6ops) working groups at the Summer 2007 IETF that DHCPv6 does not support providing default router information, necessitating that stateless address autoconfiguration configure the default router, at which time SAA hands off the client to DHCPv6 for DNS server information.

This has started anew (sounds like a soap opera, doesn’t it 🙂 ) a discussion of the merits of enhancing the DHCPv6 protocol to allow it to provide default router information and/or adding options to the stateless address autoconfiguration protocol to enable SAA to provide DNS server information.

It has been argued that DHCPv6 has advantages in some network environments and stateless address autoconfiguration has advantages in other network environments. Network designers and administrators should be empowered to determine which protocol they prefer to provide addressing and DNS information to newly connected client computers. The IETF should enhance both DHCPv6 and stateless address autoconfiguration and let network designers and adminstrators decide which protocol will ultimately dominate in the new world order of IPv6.

The challenge of autoconfiguration vs. DHCPv6

Thursday, November 16th, 2006

Stateless Address Autoconfiguration is touted as a feature for IPv6. As the line goes, stateless address autoconfiguration makes it possible for small devices such as sensors to easily acquire their own IPv6 addresses.

Such a statement ignores the ground that DHCPv4 (which is typically only referred to as DHCP) has gained in the 12 years since IPv6 was first introduced and how pervasive and easy it has become. My $90 home wireless router can be both a DHCPv4 client and a DHCPv4 server. My home security camera has a DHCPv4 client. It is hard to think of many devices that would be too small or too simple that they couldn’t sport a DHCP client implementation.

So why is stateless address autoconfiguration so special? In my opinion, it isn’t. Even more so, there were few engineering types that I talked to at IETF in San Diego that thought stateless address autoconfiguration made more sense than DHCPv6.

One of the biggest problems with stateless autoconfiguration is that it cannot provide a client with DNS server addresses. This is a major drawback. This very limitation is one of the main contributors to the disappearance of the RARP protocol.

A possible easy fix for SAA not providing DNS server information existed with site local addressing. By default an operating system stack could look for a DNS server at specific site-local address if a DNS server address was not already defined. However, since site-local has been deprecated, this solution is no longer available.

One concern that pushes network administrators to select DHCPv6 over stateless address autoconfiguration is the perception that DHCPv6 provides more control than SAA does. There are some who think that this is primarily because administrators prefer DHCP because they are already familiar with it.

Time will tell if SAA becomes the mechanism of choice (or even a choice used anywhere) for acquiring IPv6 addresses. We will have to wait until functional DCHPv6 clients and servers exist before we can genuinely evaluate the merits of SAA and its place as a benefit of IPv6.