Much-maligned feature being added to IPv6

Page 3 of 4

IPv6 NAT proposals

For the past year, the IETF's IPv6 Operations working group has been discussing how best to develop NATs for IPv6.

The IETF first considered network address translation with IPv6 in 2000, when it created a document entitled RFC 2766, Network Address Translation - Protocol Translation (NAT-PT). NAT-PT provided a mechanism for the dynamic allocation of public IPv4 addresses for IPv6-only nodes to allow IPv6-only nodes to communicate with IPv4-only nodes.

Last year, the IETF announced that NAT-PT causes too many deployment problems and security vulnerabilities. The rationale for avoiding NAT-PT, including the fact that it leaves networks open to denial-of-service attacks, is described in RFC 4966, Reasons to Move the Network Address Translation-Protocol Translation (NAT-PT) to Historic Status.  

After much debate, the IPv6 Operations Working Group in May issued a document that outlines the requirements for NATs for IPv6. This document will be sent to the IETF leadership for approval this summer, Baker said. 

Also working on NATs for IPv6 are the IETF's Behavior Engineering for Hindrance Annoyance (BEHAVE) working group, which specializes in issues related to the use of NATs over the Internet, as well as the Softwires working group, which is developing tunneling and other mechanisms to ease the transition between IPv4 and IPv6.

"The work is important," says Dan Wing, chair of BEHAVE. Wing, a Cisco engineer, says BEHAVE will spend a significant amount of time at its face-to-face meeting in Dublin discussing NATs for IPv6.

The issue of NATs for IPv6 also is on the agenda for the Internet Area's open meeting in Dublin.

"We are going to evaluate NAT designs that avoid the problems described in RFC 4966," Wing says. "After the Dublin meeting, the [IETF leadership] will decide how to split the effort between the SOFTWIRE, INTERAREA, V6Ops and BEHAVE working groups."

The IETF is looking at five approaches for NATs for IPv6. 

Choosing the best and simplest NAT approach for IPv6 is a priority for the IETF.

"A big concern of mine is that we'll make a NAT solution so good that no one moves to IPv6," Baker quips.

Geoff Huston, chief scientist at APNIC and an expert on IPv4 address depletion, says it's important for the IETF to develop high-quality NATs for IPv6 instead of ignoring the requirement as it did with NATs for IPv4.

"Frankly, it's a NAT-dense Internet these days, and I for one would rather see the world as it is than steadfastly maintain a position of high principle in the face of reality," Huston says. "The challenge to the IETF is whether it is prepared to shed its biases here and figure out what would makes NATs in IPv6 slightly less odious than what we did in IPv4."

Huston says NATs are useful for addressing, packet filtering and other functions. He says the real problem with NATs is that they lack standards, and that is an area where the IETF can make improvements in NATs for IPv6.

"The IETF's position of ignoring NATs some years back forced NAT software builders to exercise their own creativity when designing their version of NATs," Huston says. "This variation of NAT behavior is a far, far worse problem than NATs themselves."