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.
No DHCPv6 for Snow Leopard? :-(
September 13th, 2009IPv6 Testing
October 17th, 2007It is frequently hard to identify what kinds of testing one must take and how much testing is enough. In the case of IPv6, one must consider a number of things.
First look at where IPv6 is being deployed in the network and identify what features are likely to be utilized in the segment of the network that IPv6 is being deployed in. For example, testing DHCPv6 or stateless address auto configuration may be critical for deployment on the campus level, but is not important for the backbone network. If the deployment is backbone based, focus on items important to the backbone.
Evaluate the devices in the network and test those devices which are the most common and the most significant for the highest number of network users. If 50% of the network routers are one specific model, this model should certainly be high on the list of devices to be tested. This specific router’s performance has a significant impact on the performance of the network.
If one specific area being tested appears problematic on a number of devices, consider testing all devices which could be impacted by failures in this area. Adapt testing strategies based on what is found in earlier testing.
Understand why specific test cases must be completed. If one can not state why a specific test case should be tested, this test case should be reconsidered.
IPv6 deployment will occur as a whisper, not as a bang
October 8th, 2007IPv6 is the next generation Internet Protocol which is rapidly becoming this generation’s Internet Protocol.
IPv6 isn’t officially deployed in many places. However, unofficially it is deployed in most of today’s network environments.
At the command prompt of practically every current Linux, UNIX (including MacOS 10.4) and Windows (Vista) operating system, try the following in almost any office network and prepare to be surprised: ping “ff02::1” or “ping6 ff02::1.” Every IPv6-enabled network device in the office network will respond to this ping unless explicitly blocked by the network administrator (As defined by IETF RFC4291, ff02::1 is the IPv6 all nodes IPv6 address, which all nodes must respond to).
Although the network administrator may know nothing about IPv6, IPv6 is pervasive in most office networks.
Much of the controversy regarding IPv6 is a matter of policy. Meanwhile operating system designers have been silently enabling IPv6 by default. IPv6 is becoming an effective network protocol within Ethernet “broadcast” domains, even if network administrators haven’t configured its use across Ethernet domains and campus networks.
Because there is little fundamental difference between IPv4 and IPv6, the transition from IPv4 to IPv6 could occur as a whisper, not as a bang. Gradually network administrators will learn how to use IPv6 in their networks and will find transitioning to IPv6 less difficult or problematic as they originally feared.
IPv6 is not fully cooked. But neither is IPv4. Within 3-5 years it will be apparent that IPv4 can no longer support the needs of the global Internet community. It will also be apparent that a wholesale replacement to the Internet Protocol will take decades to design and implement. IPv6 will be the only viable protocol to support the ballooning global network infrastructure. IPv6 must happen.
Is IPv6 Addressing Easier than IPv4 Addressing??
September 14th, 2007Every existing network implementor and administrator today is disadvantaged by having years of experience with addressing IPv4-style. In the IPv6 workshops I’ve been involved with, grasping IPv6 addressing is usually slow for attendees who can rattle-off IPv4 addresses.
But are IPv6 addresses really that difficult? Once the Internet community gets past the initial paradigms with IPv6 addressing, IPv6 addressing may actually look easier. When the community reaches the point when students learn IPv6 addressing first, I think the students may cringe at having to handle “legacy” IPv4 addresses.
It is easier to subnet along hexadecimal boundaries than octet boundaries. It is easier to visualize how to split-up 16-bit address space when one knows each digit is 4-bits than when one has to split-up an octet. Which is easier: Determining that the 12-bit boundary of an “IPv6-style” 16-bit address space is after the third hex digit (subnet mask: FFF0) or that the 12-bit boundary of two octets is really subnetted something like “255.128”?
A complaint I often hear is that there is no way anyone will remember an IPv6-address. There is some truth to this. I would challenge any network guru to recide the MAC address of the 10/100/1000 interface of their laptop computer. However, if one uses creative addressing formats for well-known network addresses (such as “fa1” for the first ethernet interface on their router, it isn’t hard to remember an IPv6 address. I can still remember the full IPv6 address I set for a Linux box I had two year ago.
Wrinkles in creating a DHCPv6-only world
August 22nd, 2007As 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.
Source Routing and IPv6: Source routing is still a bad idea.
May 19th, 2007The more people think there is something special about IPv6, the more they discover that IPv6 has the same problems that occurred with IPv4.
Source routing was a bad idea with IPv4. After two researchers studied source routing with IPv6 they came to the conclusion that source routing was a bad idea with IPv6. This shouldn’t be a surprise. Yet, there were many articles that came out that panicked about the latest IPv6 security wrinkle. The obvious solution was the same that came to mind with IPv4 — disable this feature.
This really shouldn’t be a surprise. I think the initial research was valuable, after which engineers should have noted that source routing with IPv6 should be disabled by default, as it is with IPv4. This should be included in best current practices documents. But the multiple media reports were unncessary.
The challenge of autoconfiguration vs. DHCPv6
November 16th, 2006Stateless 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.