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.