Skip to main content

IPv4 Residual Deployment across IPv6-Service networks (4rd) A NAT-less solution
draft-despres-softwire-4rd-00

Document Type Expired Internet-Draft (individual)
Expired & archived
Author Rémi Després
Last updated 2010-10-18
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

During the long transition period from IPv4-only to IPv6-only, networks will have not only to deploy the IPv6 service but also to maintain some IPv4 connectivity for a number of customers, and this for both outgoing and incoming connections and for both customer- individual and shared IPv4 addresses. The 4rd solution (IPv4 Residual Deployment) is designed as a lightweight solution for this. It applies not only to ISPs have IPv6-only routing networks, but also to those that, during early transition stages, have IPv4-only routing, with 6rd to offer the IPv6 service, those that have dual- stack routing networks but with private IPv4 addresses assigned to customers. In some scenarios, 4rd can dispense ISPs from supporting any NAT in their infrastructures. In some others it can be used in parallel with NAT-based solutions such as DS-lite and/or NAT64/DNS4 which achieve better IPv4-address sharing ratios (but at a price of significantly higher operational complexity).

Authors

Rémi Després

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)