While IPv6 was standardized by the IETF, the Internet Engineering Task Force, many years ago, it’s now that we see the experience of operating IPv6 during many years and implementing it in various applications. There are many documents still coming out, some proposing new functions, correcting old ones that turned out bad and some documenting best current practice. I will take you by the hand and browse through some documents, not cover them all. Let’s take a look!
The IETF has a large amount of Working Groups. Many of them are touching the subject of IPv6 from one perspective or another, like the SIP area or the routing area. There are still some groups focused on the IPv6 topic. Let’s go through the major ones:
The IPv6 maintenance working group has this charter:
The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF.
The IPv6 Renumbering group(6renum) has a long charter, but the core of it can be found in this part:
If IPv6 site renumbering continues to be considered difficult, network managers will turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space.
The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.
Drafts and documents in the RFC publishing queue
The V6ops group has produced the very important Happy Eyeballs document, which currently waits to be published as an RFC. This document applies to almost every TCP/IP service that needs to connect over dual stack connections. The abstract is clear:
“When a server’s IPv4 path and protocol is working but the server’s IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay, and provides an algorithm.”
Another set of documents from this group is the “Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)” and the “IPv6 Router Advertisment Guard (RFC 6105)“that addresses the issue of devices that accidentally or on purpose start announcing IPv6 prefixes on a LAN.
“When operating IPv6 in a shared layer-2 (L2) network segment without complete SEcure Neighbor Discovery (SEND) support by all devices connected or without the availability of the infrastructure necessary to support SEND [RFC3971], there is always the risk of facing operational problems due to rogue Router Advertisements (RAs) generated maliciously or unintentionally by unauthorized or improperly configured routers connecting to the segment.”
“This document describes a solution framework for the rogue-RA problem [RFC6104] where network segments are designed around a single L2-switching device or a set of L2-switching devices capable of identifying invalid RAs and blocking them.”
Renumbering an IPv6 network
The 6renum group has a few documents that are trying to outline the problem area and set up requirements for a solution to the problem of renumbering. If they do not succeed, many enterprises will get provider independent IPv6 addresses and that will put a lot of pressure on the routing system. Another way is for sites to use NAT66 like they used NAT in the IPv4 network, something a lot of IPv6 gurus wants to avoid at all cost. There is a draft called “IPv6 Enterprise Network Renumbering Scenarios and Guidelines” that covers this in a good way:
“IPv6 site renumbering is considered difficult. Network managers currently prefer to use Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems and PI space is not always available for enterprise according to the RIR (Regional Internet Registry) policies. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. In any case, renumbering may be necessary for other reasons. This document undertakes scenario descriptions, including documentation of current capabilities and existing BCPs, for enterprise networks. It takes [RFC5887] and other relevant documents as the primary input.”
The enterprise renumbering draft also covers a few reasons on why a enterprise network will need renumbering:
- Switching to a new ISP
- Adding new prefixes from uplink provider
- Adding a new uplink for multihoming
- Company merger or split
- Change of network topology and/or sub netting
6man – managing the IPv6 protocol
Executive summary: The polls are coming in and the IETF is listening
- ISOC Deploy360: 4 IETF mailing lists to follow