This week I’ve been busy participating in the IETF meeting in Paris – number #83 from start! With three meetings a year, you can calculate how long this has been going on. The IETF meetings are not conferences or tutorials, it’s working group meetings to agree or disagree on items in face to face meetings. The meetings are planned down to the minute – and there’s never enough minutes for all the things there are to discuss. I’ve split my attention between IPv6 and SIP-related meetings, so this is just my personal point of view – not a complete or formal report. The protocols, the audio files and the jabber chats are all available at www.ietf.org.
Note 1: IPv6 matters to everyone
While we have at least two IPv6 working groups, v6ops and v6man, there’s a lot of IPv6 going on in other groups as well. This shows clearly that IPv6 no longer is an isolated island – no longer in the IETF and not in the real world. The DHC working group and many others had a lot of IPv6 and dual stack documents to discuss.
Note 2: IPv6 is mostly done
The IPv6 working group did not spend time discussing basic IPv6 features, corrections to the core or necessary additions. The discussions was focused on deployment technologies, migration solutions and how to solve real life problems reported by service providers deploying IPv6. The work is now spread out and there’s still a lot of work in the application layers and implementations.
Note 3: CPE management is still an issue
The Customer Premises Equipment – the home router or the CPE – is still an issue. There are two models here that require special attention – the provider-provisioned CPE and the boxes you buy in the closest electronics store. A new point of view is that providers wants to make sure that transition to native IPv6 can happen soon and smoothly. In this case, the CPE may start with a tunneled approach and then move to native connections without breaking connectivity at any point. In fact, the device may have both IPv6 native and tunneled at the same time, in which case the native interface should have priority over the tunnel. Since there are multiple configurations – IPv4 tunneled over IPv6 and IPv6 tunneled over IPv4 you might end up with a device that enables just about everything and the end result in that case may very well be that you have two IPv4 interfaces and two IPv6 interfaces, which clearly adds a requirement to prioritize native connections.
Note 4: DHCPv6 is expanding
DHCPv6 is certainly expanding. New functions are added, many discussions happen. It is important to qualify which information that belongs to the Router Advertisments and which that belongs to DHCPv6.
One important piece that is being worked on is the ability to send the client’s hardware address in the DHCPv6 requests. Quoting the Internet Draft:
“Currently, the DHCPv6 protocol specification [RFC3315] does not define a way for DHCP clients to specify client link-layer address in the DHCPv6 message sent towards DHCPv6 Server. Similarly DHCPv6 Relay or Server cannot glean client link-layer address from the contents of DHCPv6 message received. DHCPv6 protocol specification mandates all clients to prepare and send DUID as the client identifier option in all the DHCPv6 message exchange. However none of these methods provide a simple way to extract client’s link-layer address.This presents a problem to an operator who is using an existing DHCPv4 system with the client hardware address as the customer identifier, and desires to correlate DHCPv6 assignments using the same identifier. Modifying the system to use DUID based correlation across DHCPv4 and DHCPv6 is possible, but it requires a modification of the DHCPv4 system and associated back-ends.
Providing an option in DHCPv6 messages to carry client link-layer address explicitly will help above mentioned scenarios. For e.g. it can be used along with other identifiers to associate DHCPv4 and DHCPv6 messages from a dual stack client. Further, having client link-layer address in DHCPv6 will help in proving additional information in event debugging and logging related to the client at relay and server. The proposed option may be used in wide range of networks, two notable deployment models are service provider and enterprise network environments.”
This addition will make DHCPv6 more useful and manageable for many system and network admins.
Note 5: IPv6 is the coolest working area, judging from the t-shirts
Gonzalo Camarillo - an IETF profile
IETF is a lot about t-shirts. There are quite a lot of people here walking around with super-cool IPv6 t-shirts – and there’s plenty of them. This makes me feel like an outsider, since I have yet to get my hands over and my body inside an IPv6 t-shirt. I’ve seen no RTCweb shirts, no SIPrec t-shirts or MPLS t-shirts at this IETF meeting. I regret not trying to document all of them, but here’s a sample – Gonzalo Camarillo in a T-shirt saying “IPv6 – Been there, Done that”. Another one was filled with animals in pairs, with one pair of unicorns in a different color. The text said simply “IPv6. Don’t miss the boat.”
Executive summary: You’ve run out of excuses!
The executive summary of today is simple: You’ve run out of excuses. Everything is ready for the World IPv6 Launch – but are you?