NAT
Network components
DS-Lite enables service providers to natively allocate IPv6 addresses to new customers while continuing to support IPv4 customers. Main functional components involved in DS-Lite are B4 (Basic Bridging BroadBand) and AFTR (Address Family Translation Router) as shown in figure below:
Following sequence describes the connection establishment process using DS Lite:
- Host with private IPv4 address initiates a connection to a resource on the public internet
- Traffic is sent to B4, which is the default gateway
- B4, using its service provider network facing IPv6 addresses establishes the tunnel with AFTR. Address of the AFTR can be pre-configured or can be discovered using DHCPv6
- B4 encapsulates the IPv4 packets in IPv6 transport and sends across to AFTR
- AFTR terminates the tunnel and de-capsulate the IPv4 packet
- AFTR device performs IPv4-IPv4 NAT before sending traffic to the destination IPv4 network
There are many benefits that DS Lite provides:
- A lightweight solution to allow IPv4 connectivity over IPv6 network
- Avoids the need of multiple levels of NAT as in case of LSN
- Allows service providers to move their core and access networks to IPv6 thus enabling them to benefit from IPv6 advantages
- Allows coexistence of IPv4 and IPv6
- Helps resolve IPv4 address scarcity issue
- Allows incremental migration to native IPv6 environmen
But as always is the case, benefits don’t come without its own set of challenges:
- DS Lite does not provide IPv6 and IPv4 hosts to talk to each other
- Increases the size of traffic due to tunnel headers – requires MTU management to avoid fragmentation
- Need to manage and maintain bindings between customer addresses and public addresses used for translation in the AFTR device
- Brings in additional challenges for DPI in service provider network
6rd is a mechanism to facilitate IPv6 rapid deployment across IPv4 infrastructures of Internet service providers (ISPs).
6rd is just opposite of DS lite (just replace v4 to v6)
It is derived from 6to4, a preexisting mechanism to transfer IPv6 packets over the IPv4 network, with the significant change that it operates entirely within the end-user's ISP's network, thus avoiding the major architectural problems inherent in the original design of 6to4. The name 6rd is a reference to both the rapid deployments of IPv6 it makes possible and, informally, the initials (RD) of its inventor, Rémi Després. A description of 6rd principles and of how they were first used by Free is published in RFC 5569.[1]
Service Providers to provision IPv6 addresses to end customers without upgrading their core infrastructure to IPv6. 6rd enables IPv6 hosts separated by IPv4 networks to communicate with each other by establishing an IPv4 tunnel. The tunnel origination point on the sender’s side of the tunnel encapsulates the IPv6 traffic within IPv4 packets, and sends them over IPv4 to the device at the remote end of the tunnel. The device on the other end of the tunnel decapsulates the packets and sends them over the IPv6 network to their destination.
Though 6rd helps ISPs to provision IPv6 connectivity to end users but it does not allow IPv6 clients to talk with IPv4 servers. For that to work solutions like NAT64 / SLB64 are required.
3. NAT64
This brings in the challenge of ensuring that new IPv6 enabled devices are able to access any content – hosted on IPv4 or IPv6. NAT64 is technology that provides the bridge between IPv6 and IPv4 by doing the protocol transformation that the other side understands.
NAT64 does the translation from IPv6 to IPv4 based on a pre-assigned /96 prefix that is carried in the destination IPv6 address of packets. Last 32 bits of the IPv6 address carry the
IPv4 address of the destination IPv4 host. As the traffic passes through the NAT64 device, it looks for the prefix match – if the match is found, the device knows that the destination is IPv4 host and needs translation. Unlike the good old NAT devices, NAT64 devices need to perform protocol transformation – creating an IPv4 header based on the information in the IPv6 header. There are additional requirements to make sure that two disparate networks can talk to each other like ICMP translation along with translation of traditional applications that embed Layer 3/4 information in the packets (e.g. FTP, SIP etc).
IPv4 address of the destination IPv4 host. As the traffic passes through the NAT64 device, it looks for the prefix match – if the match is found, the device knows that the destination is IPv4 host and needs translation. Unlike the good old NAT devices, NAT64 devices need to perform protocol transformation – creating an IPv4 header based on the information in the IPv6 header. There are additional requirements to make sure that two disparate networks can talk to each other like ICMP translation along with translation of traditional applications that embed Layer 3/4 information in the packets (e.g. FTP, SIP etc).
Now the question is – how does the connection initiating IPv6 host knows the destination address? This gap is filled by DNS64 device. Whenever DNS64 device gets a query (AAAA) to resolve a name – it first tries to fetch the IPv6 address. If the address is found, it is returned to the host but if there is no IPv6 address – DNS64 device gets the IPv4 address prepends it with the preconfigured 96 bit prefix and returns to the host. Following diagram shows the sequence of events when an IPv6 host tries to connect with an IPv4 server.
In early stages of IPv6 transition content providers are primarily providing access to web content hosted on IPv4 servers. In such scenarios SLB64 offer advantages over pure NAT64 technology. SLB64 is Server Load Balancing by exposing IPv6 connection points for IPv4 servers – so SLB64 devices not only provide translation but also provide other benefits that come along with advanced ADCs like NetScaler.
There are many detractors of NAT yet there is no denying that NAT has been in use for years and is not going away anywhere soon. For IPv6 transition it is emerging as a very strong enabling technology.
No comments:
Post a Comment