Interoperability mechanisms between IPv4 and IPv6

In document Interoperabilidade e mobilidade na internet do futuro (Page 53-56)

2.3 Deployment and interoperability

2.3.3 Interoperability mechanisms between IPv4 and IPv6

Along with the initial deployment of IPv6, a set of mechanisms to ease and smooth the migration between IPv4 and IPv6 protocols were proposed which, consequently, also promoted the interoperability between both protocols. Although, these mechanisms were proposed in scope of IPv4 and IPv6, this section intends to overview the proposed solutions so that a set of lessons could be extracted and used as guidelines for the work developed in this thesis.

IPv6, designed as the successor of IPv4 protocol, defines a different packet format and addressing schemes (i.e., the size of addresses is increased from 4 bytes to 16 bytes). Entities only supporting the IPv4 protocol are not able to forward IPv6 packets and, in a similar way, entities only supporting IPv6 protocol are not able to forward IPv4 packets. As a result, IPv6 created a parallel networking environment that coexists with its IPv4 counterpart. The deployment of IPv6 has been slowly happening for a long time [26, 31], although in the recent years we have witnessed an increased traction on the IPv6 adoption8.

During this transition period, where both IPv4 and IPv6 coexist simultaneously in the Internet, the interoperability strategies described in Section 2.3.2 have been used


in the migration from IPv4 to IPv6 protocol, aiming to promote a smooth adoption of IPv6 by maintaining connectivity of both IPv4 and IPv6 networks and enabling the interoperability between IPv4- and IPv6-only hosts as well.

Following a dual-stack strategy, network entities (e.g., hosts and routers) run complete implementations of both IPv4 and IPv6 in parallel [48]. Such entities have the ability to handle both IPv4 and IPv6 packets and, thus, they can directly interoperate with IPv4 nodes using IPv4 packets and with IPv6 nodes using IPv6 packets. In addition, it enables IPv4 and IPv6 applications to operate in the same node, whenever dual stack is supported in the host [103]. Although most of the currently sold network equipments and hosts already support both protocols, to be possible to use such strategy in the whole Internet infrastructure, the legacy equipment supporting only IPv4 protocol would need to be replaced or updated.

To overcome such limitation of a dual-stack strategy, tunneling strategies started to be considered as well, as a mean to carry IPv6 packets over unmodified IPv4 routing infrastructure [48], acting as a bridge between IPv6 networks across incompatible IPv4 networks [103]. The tunnel endpoints can either be hosts or routers supporting both IPv6 and IPv4 protocols, on which the tunnel is established between: host-to-host, host-to-router, router-to-host or router-to-router. In the tunnel entry point an IPv4 header is added to the original IPv6 packet (i.e., the original IPv6 packet is encapsulated in an IPv4 packet). The packet can then be routed towards the tunnel exit point on which the IPv4 header is removed and the original IPv6 packet sent through the IPv6 routing infrastructure towards the original destination. To avoid explicit tunnel setup which introduces large management overheads, several approaches have been proposed to automate tunnel configuration. Proposals such as 6over4 [62], 6to4 [22], 6rd [34], and Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [53] defines addresses that contain embedded IPv4 addresses, used to determine the source and destination IPv4 addresses when IPv6 traffic is tunneled across an IPv4 network. Another approach [36] relies on tunnel brokers which are responsible for automating tunnel management for requests originated from the users.

As IPv6 adoption becomes widespread, IPv6-only deployments are expected to occur. In order to maintain connectivity of residual IPv4 deployment (e.g., isolated IPv4 networking islands), it may be required to established tunnels over the IPv6 infrastructure. In the tunnel entry point an IPv6 header is added to the original IPv4 packet (i.e., the original IPv4 packet is encapsulated in an IPv6 packet). Dual- Stack Lite (DS-Lite) [35] uses IPv4 over IPv6 tunnels to forward traffic from a dual-stack host or Customer-Premises Equipment (CPE) provided with IPv6-only connectivity by the service provider (also called, DS-Lite Basic Bridging BroadBand (B4)), towards a carrier-grade IPv4-IPv4 NAT (also called, DS-Lite Address Family

2.3. Deployment and interoperability 31 Transition Router (AFTR)). Upon decapsulating packets coming from the tunnel, the AFTR performs IPv4-IPv4 NAT translation. B4 devices discover the AFTR via out- of-band mechanisms, manual configuration or using DHCPv6 options. Lightweight 4over6 approach [29] builds upon the mechanisms of DS-Lite, relocating the NAPT functionalities to the B4 device, in order to reduce the amount of centralized state at the AFTR. The approach proposed in [30] also leverages a tunneling IPv4 over IPv6 strategy where global IPv4 addresses are assigned to users, avoiding the need for carrier-side address translation. Although this last approach is in use in some existing deployments, future deployments of similar scenarios are recommended to use Lightweight 4over6 instead [30].

Finally, scenarios considering the communication between IPv4-only and IPv6-only applications/hosts (and vice-versa) are also addressed, with solutions exploring and proposing the translation between both protocols:

❼ The Stateless IP/ICMP Translation Algorithm (SIIT) [15] defines bidirectional algorithms for translating between IPv4 and IPv6 packets (and between ICMPv4 and ICMPv6 messages), not including IPv4 Options or IPv6 extensions headers (except the Fragment Header). Due to the stateless nature of this approach, packets between both protocols are translated based on the configuration of the translator and information contained within the packets being translated. ❼ Regarding the introduction of translators in the network path between hosts

deployed in IPv4 and IPv6 architectures, IPv6-to-IPv4 Transport Relay Translator (TRT) [111] defines an intermediary entity that enables IPv6-only hosts to initiate and exchange TCP and UDP traffic with IPv4-only hosts. Following a stateful strategy, the TRT maintains two connections: one with the IPv6 host and another with the IPv4 host, relaying traffic between both connections.

❼ SOCKS-based IPv6/IPv4 Gateway [66] makes use of SOCKS protocol to enable IPv4/IPv6 traffic to be forwarded from the initiator applications to a relaying entity (i.e., the SOCKS server), which in turn establishes the correspondent IPv6/IPv4 connection with the destination node. This intermediary entity is, as in the previous case, responsible for relaying traffic between both connections. ❼ Bump-in-the-Host (BIH) [58], a successor and combination of the Bump-in- the-Stack (BIS) [13] and Bump-in-the-API (BIA) [65], proposes to allow IPv4- only applications running in dual-stack hosts to communicate with IPv6-only peers. The translation can be made at the socket API layer, with the translator intercepting IPv4 socket API function calls and, in turn, invoking

the corresponding IPv6 socket API fucntion calls; or at the network layer, with packets being intercepted and converted using the algorithms defined in SIIT approach.

The migration from IPv4 to IPv6 proved to be far more complex than expected, with several mechanisms being proposed to mitigate such complexity. Most of the mechanisms proposed to ease and smooth the migration process have relied (i) in gateways supporting both protocols that (ii) followed a tunneling or translation approach to enable traffic to be sent across a different network architecture, (iii) while making the communication transparent to applications.

In document Interoperabilidade e mobilidade na internet do futuro (Page 53-56)