IPv6 work is progressing in many parts of the IETF and the IPv6 working group is slowly moving to its close. This doesn’t mean that there isn’t a lot of debate and work going on in many areas. Looking at this IETF, and at the community as a whole, the address assignment plans are the things mostly discussed right now. This is due to the fact that the first real allocations, in accordance with the allocation guidelines, happened last year and have continued at a rather rapid rate. These allocations have been very large and this seems to have triggered people’s attention. The usual reaction is that the consumption rate is a bit unhealthy when seen in a long perspective. Seeing that IPv6 probably will be around for many decades to come it might be wise to apply a somewhat more conservative allocation policy. A common view is that these resources should at least be good for a century or two.
One possible approach would be to change the HD ratio of the assignments so that there would be less overhead for the ISPs or to change the default site allocation size. The latter would be simplified by changing RFC 3177 which talks in favour of having one allocation size. There is a proposal for an update of RFC 3177 which tries to highlight that there are no real technical reasons for having only a /48 boundary and suggests a /56 boundary for smaller sites, such as homes. This would save a huge amount of space, even more than changing the HD ratio.
Some see the 64 bit division as a tremendous waste and that it perhaps should be revisited. But as it was commented at the meeting, the initial plan was to have only 64 bits for the next generation protocol and instead we now have 64 bits only for networks and people still aren’t content, perhaps nothing is enough to satisfy everybody! Changing the 64 bit division would also have a tremendous engineering impact since it is built-in to many implementations and also used in other standards.
As IPv6 becomes a natural part of the Internet the work with IPv6 has to continue. One good example is the work with IPv6 over 802.16 or WiMAX, which was presented at the meeting. 802.16 differs somewhat from the usual Ethernet MAC layer addressing and IPv6 needs to be adapted to fit this. Another thing that shows that there is still work needed on the details is a draft about how to write a link local address in the web browser or other application. An application can’t know which address you are referring to if you only input the address without any reference to an interface. The draft suggests adding this reference to the input of the address.
As part of showing that IPv6 now is mature the IPv6 working group (IPv6) is scheduled to be closed by the end of this year. One thing the chairs would like to do before the closure is to move the base specifications to Internet Standard to clearly mark that IPv6 is implemented and out in the market. There were some objections at the meeting about all documents not being mature enough, since they have been recently updated, and it would be fair to wait a little bit longer with these documents.
A quick look at the work with mobile IPv6 shows that it is at more or less the same stage as the work with the core IPv6 specifications. The focus of the work is on optimizing the solutions to be able to work in the different emerging network scenarios, rather than on the basic spec. The work with optimizing mobile IPv6 will probably continue for quite a while as mobility becomes more and more important in many environments.
IPv6 Operations
What has been shown on the operational side is the limited operational experience. Many topics in the IPv6 operations working group highlight this problem. One example is the document on ICMP filtering. ICMP filtering is very different from IPv4 and something that will require rethinking. There is still a lot feedback needed from the community before there will be a good best practice document. Renumbering is another case where there has been an effort to try to document actual renumbering trials, but where it was pointed out that the experience with renumbering is still limited and that there are many pieces missing to make the renumbering effortless.
To compensate for the lack of operational experience a lot of effort has gone into documents that describe different scenarios and how they should be tackled. The documents discussed at this meeting covered enterprise networks and broadband access networks. The broadband access network document covers many different deployment cases, but not all. It was pointed out that it doesn’t comply with the latest standard for cable networks, DOCSIS 3.0, but as the draft is more or less ready for last call there was bit of reluctance to wait too long for input on that topic.
One document that highlights clearly the difference between IPv4 and IPv6 is the network architecture protection draft. It documents the perceived benefits of IPv4 NATs and shows how these benefits can be implemented in IPv6 without losing end to end connectivity. As it gives a very comprehensive view of a popular topic and includes solutions to all the problems it will hopefully soon be approved by the working group.
Shim6
The lack of multi-homing capability is seen by many as biggest problem with IPv6. Therefore the Shim6 working group has put forward a very aggressive plan where most things should be documented and ready by the end of next year. As the multi-homing approach using a shim layer is extremely complex many new questions will arise as the work with the protocol progresses. Right now there are already a number of questions to be answered. One is the triggers to change communication path. To some extent this has already been documented in a draft about reachability detection. The discussion regarding this document showed that it isn’t trivial to define what is or is not a failure. This area will need continued work as will the work with upper layer interaction which was decided to be started as working group item. These are only small parts of the whole design but still very important. Another area that might have to be studied is traffic engineering, which today isn’t covered at all. Right now the focus is on getting the basic architecture through the standardization process.
Tunnelling mechanisms
Something that has been a hot topic for a long time is different tunnelling mechanisms and at the last IETF there was a BOF about a tunnel discovery and configuration protocol. That BOF didn’t lead to a working group but at IETF63 there was a new BOF on almost the same topic. This time the BOF was called Lightweight Reachability softWires (LRW) and tried to describe the problems instead of the solutions. Even with the focus on the problems it wasn’t clear what the use cases were since there were very many different scenarios where people saw a need for a deterministic tunnelling mechanism. As tunnel mechanisms are things that are needed in the initial stage of IPv6 deployment the time frame for this potential working group is short and the work needs to be started more or less now to be of any use. If the WG is approved the chairs wanted to have an interim meeting to write the problem statement before the next IETF.
As a final note it is worth mentioning the Dynamic Host Configuration working group (DHC) which is a good example of where IPv6 has spread and is a natural part of the WG work. A lot of efforts are going in to writing standards for DHC that can work with both IPv4 and IPv6, which isn’t as trivial as it might seem at first glance, especially in a mixed environment with several DHC servers.
Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects a personal perspective on some current highlights.