Edge routers for IPv6 migration

Organisations today are too dependent on the Internet to experience any downtime when upgrading from IPv4 to IPv6.

But help is on the way.

The Internet Engineering Task Force (IETF) has defined several technologies that, when combined, can make the transition from IPv4 to IPv6 virtually seamless, while adding value and extending the capabilities of edge routers.

An edge router connects the "last feet" between a device and its connection to the Internet. It is the box that takes your Internet connection and makes it available to your systems connected on a LAN.

Many of today's edge routers include network address translation (NAT), which lets users conserve IP addresses. NAT substitutes a LAN system's TCP/IP address with that of the NAT router, making it appear as though there is only one system connected.

Trouble zone

Despite saving space, however, NAT isn't trouble-free. With NAT, external users "see" your entire subnet as one computer, and this causes inherent problems.

For example, it makes it impractical to host multiple Web servers, each of which needs its own IP address. Multimedia and interactive Internet activities are also hard, sometimes impossible, to set up through a NAT router. And you can't nest NAT devices to create multiple subnetworks.

NAT, as generally deployed today, also limits the extensibility of VPNs; limits encryption and security; and, most importantly, does not play nicely at all in IPv6-based networks.

Since there is a massive installed base of IPv4-based hardware and software, the transition to IPv6 will only be possible if it is made simple. The IETF has published a series of documents that define a transitional edge router.

These specifications are:

-- DNS-ALG (Domain Name System extensions to network address translators, RFC 2694) defines DNS extensions to NAT and outlines how DNS can alter address mapping of hosts as DNS packets cross from one address realm into another.

-- SIIT (Stateless IP/ICMP Translation Algorithm, RFC 2765) defines a way to translate between IPv4 and IPv6 packet headers that lets IPv6 hosts communicate over an IPv4-based router network.

-- NAT-PT (NAT-Protocol Translation, RFC 2766) defines a methodology for converting private IPv4 packets into public IPv6 packets.

-- 6to4 (Connection of IPv6 Domains via IPv4 Clouds, RFC 3056) defines a methodology for encapsulating IPv6 packets for seamless transition over IPv4 backbones.

Building transitions

When you combine these documents with a little architectural glue, you get an environment that lets existing v4 systems communicate on a v6 backbone. An edge router with this complement of software would provide a very reasonable transition for exiting v4 clients.

If you add v4 IP Security (for VPN tunnels); a configurable, per-protocol firewall; an IPv6 router; autoconfiguration; multimedia services; and a Web-based interface to manage it all, you'll get an edge router that eliminates the shortcomings of today's NAT, plus a seamless way to migrate to the upcoming IPv6 Internet backbone. And you can eliminate many of today's networking headaches.

Benefits

For example, administrators can choose to hide or expose network elements such as Web servers and databases to general Internet users, regardless of their physical location. IP addresses can be duplicated on separate subnetworks, alleviating the need to manage IP addresses in a VPN. Users can have simultaneous access to the Internet and private VPN resources automatically.

Service providers can deliver access-point devices that provide scalable services to home users. They can also configure devices and services remotely from the head end, without rolling trucks.

End users would have seamless multimedia communications, and when the Internet transitions to IPv6, there would be no change required to the devices behind the edge router.

Finally, as IPv6 deploys to end nodes, no changes would be required on edge routers.

Join the newsletter!

Error: Please check your email address.

More about ExtensibilityIETFInternet Engineering Task Force

Show Comments