The 64th IETF was a big milestone for IPv6. It marked the end of the IPv6 working group and hopefully the beginning of large scale adoption of IPv6. It was concluded that this would be the last face-to-face meeting of the IPv6 WG but that the working group should stay open until all unfinished work is done. There are no big items left on the charter although several documents are currently being revised (e.g. address selection RFC 3484). The largest remaining task is perhaps the shepherding of the core specifications to Internet standard. During its existence the IPv6 working group has produced 69 RFCs and it still has 11 drafts on their way to RFC.
RFC2461bis is one of the documents underway and the last remaining piece was the issue about the meaning of the ‘Managed address configuration’ flag and the ‘Other configuration’ flag. The accepted solution at the meeting was to say that M flag indicates a client should use DHCPv6 for all configuration information and only use DHCPv6lite if just the O bit is set. Related to the management flag discussion was the issue when an ISP wants to force a user to use a specific address. Even if the management bit is set by a router there is no guarantee that the client doesn’t use any other address such as privacy addresses. This will create problems with access control since the client address isn’t always predictable. One solution would be not to include a prefix in the router advertisements.
There’s no lack of operational issues related to IPv6. One big task at the meeting was to figure out what to take up as work within the WG and what to send off to other groups. Documents that already are WG items and now starting to be finalized are Broadband deployment scenarios, Enterprise Analysis, and Network architecture protection. The Broadband deployment document will ship without an updated cable networks section since the new cable network specification isn’t quite ready. The Enterprise analysis will just have a small rewording regarding DSTM before moving to the IESG. One document that was taken up as a new WG item was IPv6 Implications for TCP/UDP Port Scanning. There are many other interesting documents in the working group and the work would definitely gain from a wide community review since all operational input is useful.
At IETF63, Softwires was a BoF but it has been very active and has held an interim meeting to finalize the problem statement. Softwires was approved as WG during IETF64 and will now start working on flexible tunneling mechanisms that work in two different scenarios; the first being hubs and spokes and the second mesh. These more or less represent end host and core network cases. One of the important goals is to make the mechanisms independent of the tunnelling protocol so that it can be optimized to different networks and provide integrity when needed.
IPv6 over IEEE 802.16(e) Networks
This was a BoF to start a working group that would work with IPv6 over 802.16 networks or WiMax. There was some confusion as to what was the actual problem since it is possible to run IPv6 over 802.16 today. The statement was that the functions in 802.16 networks make IPv6 perform poorly and that there has to be additional work done. One question many asked was if this shouldn’t be something that should be fixed in the 802.16 standard instead of in the IETF. In the end there was no clear consensus on how to proceed and there will not be a WG created right now.