Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
Are there any IPv6 technologies that support translating one-to-one mapping from IPv4 to IPv6 for the whole Class A range, like 10.0.0.0/8 network to a particular IPv6/40 range?
Preferably for A10 AX series, but when I tried with NAT46-stateless, it is only supporting up to 1024 addresses.
First IPv4 network classes are dead, killed in 1993 by RFCs 1518 and 1519, which defined CIDR (Classless Inter-Domain Routing). Modern networking doesn't use network classes, and it has not for many years. Please let them rest in peace.
Second IPv4 and IPv6 are completely separate protocols. Attempts to convert from one to the other are really kludges. In fact, the IETF has deprecated NAT46. See RFC 4966, Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status:
- Introduction
The Network Address Translator - Protocol Translator (NAT-PT) document [RFC2766] defines a set of network-layer translation mechanisms designed to allow nodes that only support IPv4 to communicate with nodes that only support IPv6, during the transition to the use of IPv6 in the Internet.
[RFC2766] specifies the basic NAT-PT, in which only addresses are translated, and the Network Address Port Translator - Protocol Translator (NAPT-PT), which also translates transport identifiers, allowing for greater economy of scarce IPv4 addresses. Protocol translation is performed using the Stateless IP/ICMP Translation Algorithm (SIIT) defined in [RFC2765]. In the following discussion, where the term "NAT-PT" is used unqualified, the discussion applies to both basic NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if points apply to the basic address-only translator.
A number of previous documents have raised issues with NAT-PT. This document will summarize these issues, note several other issues carried over from traditional IPv4 NATs, and identify some additional issues that have not been discussed elsewhere. Proposed solutions to the issues are mentioned and any resulting need for changes to the specification is identified.
Whereas NAT is seen as an ongoing capability that is needed to work around the limited availability of globally unique IPv4 addresses, NAT-PT has a different status as a transition mechanism for IPv6. As such, NAT-PT should not be allowed to constrain the development of IPv6 applications or impose limitations on future developments of IPv6.
This document draws the conclusion that the technical and operational difficulties resulting from these issues, especially the possible future constraints on the development of IPv6 networks (see Section 5), make it undesirable to recommend NAT-PT as described in [RFC2766] as a general purpose transition mechanism for intercommunication between IPv6 networks and IPv4 networks.
Although the [RFC2766] form of packet translation is not generally applicable, it is likely that in some circumstances a node that can only support IPv4 will need to communicate with a node that can only support IPv6; this needs a translation mechanism of some kind. Although this may be better carried out by an application-level proxy or transport-layer translator, there may still be scenarios in which a revised, possibly restricted version of NAT-PT can be a suitable solution; accordingly, this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status to avoid it from being used in inappropriate scenarios while any replacement is developed.
The current model for IPv4/IPv6 translation is defined in RFC 4213, Basic Transition Mechanisms for IPv6 Hosts and Routers:
- Introduction
The key to a successful IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will streamline the task of transitioning the Internet to IPv6. This specification defines two mechanisms that IPv6 hosts and routers may implement in order to be compatible with IPv4 hosts and routers.
The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. We expect that most nodes in the Internet will need such compatibility for a long time to come, and perhaps even indefinitely.
The mechanisms specified here are:
- Dual IP layer (also known as dual stack): A technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers.
- Configured tunneling of IPv6 over IPv4: A technique for establishing point-to-point tunnels by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
The mechanisms defined here are intended to be the core of a "transition toolbox" -- a growing collection of techniques that implementations and users may employ to ease the transition. The tools may be used as needed. Implementations and sites decide which techniques are appropriate to their specific needs.
This document defines the basic set of transition mechanisms, but these are not the only tools available. Additional transition and compatibility mechanisms are specified in other documents.
Although, I will strongly caution you that translation is like an opiate. It serves a purpose, but it is very easy to become addicted. It should be used sparingly, only where it is absolutely needed.
RFC 6144, Framework for IPv4/IPv6 Translation is an Informational RFC that discusses translation more in depth, and I urge you to read the RFC in its entirety:
- Introduction
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT (Network Address Translation - Protocol Translation) [RFC2766], which was deprecated by [RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6-only network.
NAT-PT was deprecated to inform the community that NAT-PT had operational issues and was not considered a viable medium- or long- term strategy for either coexistence or transition. It wasn't intended to say that IPv4<->IPv6 translation was bad, but the way that NAT-PT did it was bad, and in particular using NAT-PT as a general-purpose solution was bad. As with the deprecation of the RIP routing protocol [RFC1923] at the time the Internet was converting to Classless Inter-Domain Routing (CIDR), the point was to encourage network operators to actually move away from technology with known issues.
[RFC4213] describes the IETF's view of the most sensible transition model. The IETF recommends, in short, that network operators (transit providers, service providers, enterprise networks, small and medium businesses, SOHO (Small Office, Home Office) and residential customers, and any other kind of network that may currently be using IPv4) obtain an IPv6 prefix, turn on IPv6 routing within their networks and between themselves and any peer, upstream, or downstream neighbors, enable it on their computers, and use it in normal processing. This should be done while leaving IPv4 stable, until a point is reached that any communication that can be carried out could use either protocol equally well. At that point, the economic justification for running both becomes debatable, and network operators can justifiably turn IPv4 off. This process is comparable to that of [RFC4192], which describes how to renumber a network using the same address family without a flag day. While running stably with the older system, deploy the new. Use the coexistence period to work out such kinks as they arise. When the new is also running stably, shift production to it. When network and economic conditions warrant, remove the old, which is now no longer necessary.
The question arises: what if that is infeasible due to the time available to deploy or other considerations? What if the process of moving a network and its components or customers is starting too late for contract cycles to effect IPv6 turn-up on important parts at a point where it becomes uneconomical to deploy global IPv4 addresses in new services? How does one continue to deploy new services without balkanizing the network?
This document describes translation as one of the tools networks might use to facilitate coexistence and ultimate transition.
