Guidelines for Migrating to IPv6 Network Addresses

Transcription

1 European Workshop for Open Systems EWOS/ETG 071 Guidelines for Migrating to IPv6 Network Addresses Approved by EWOS/TA (1996) European Workshop for Open Systems EWOS Secretariat: Rue de Stassart 36, 5th Floor, 1050 Brussels Tel: Fax:

2

3 European Workshop for Open Systems All rights reserved. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and the foregoing restriction on reproduction and use extend to all media in which the information may be embodied. 1

4 Table of contents Page 1. SCOPE AND OBJECTIVES REFERENCES TERMINOLOGY AND DEFINITIONS IPv6 ADDRESSING Address types Interface address assignment principles Initial address allocation Representation of IPv6 addresses Unicast addresses Forms of unicast addresses Provider-based addresses Local-use addresses Anycast addresses Multicast addresses Pre-defined addresses Address resolution Address allocation TRANSITION AND COEXISTENCE Dual IP layer Transition mechanisms IPv6 addresses with embedded IPv4 addresses Routing topologies Tunneling IPv6-over-IPv4 tunneling Tunnel addressing Header translation Upgrade dependencies OSI NSAP address mapping Restricted NSAP address mapping into 16-octet IPv6 address Truncated NSAP address used as an IPv6 address Normal IPv6 address, full NSAP address in IPv6 option IPv6 address carried as OSI address...20 ANNEX A - Internal structure of an IPv6/IPv4 node ANNEX B - Examples...23 B.1 Automatic IPv6-over-IPv4 tunneling B.2 Configured IPv6-over-IPv4 tunneling...24 ANNEX C - Data structure for IPv4 and IPv6 headers...25 C.1 IPv4 header structure...25 C.2 IPv6 header structure...26 ANNEX D - Sending algorithm...27 ANNEX E - List of IPv6 specification documents

5 1. SCOPE AND OBJECTIVES In addition to being a fundamental step to the support of network growth, the development of version 6 of the Internet Protocol is at the base of the increase of the network protocol functionality and performance, and will enable the deployment of new applications over the Internet, opening a broad field of technological development. Nevertheless, the deployment of a new internet protocol is not problem free: network managers will have to change the protocol stack software in every networked device, namely changes at the operating system level in hosts and routers. The need to develop a new version of the Internet network protocol was due to several factors, namely address exhaustion, emerging new markets (e.g., nomadic personal computing, network entertainement, general device control), new applications (e.g., real time integrated services), quality of service and security. The present document is based on key documents of the IPv6 specification, and constitutes an introductory text to the new version of the IP protocol (IPv6) addressing architecture and migration/coexistence guidelines. The document presents the general addressing principles of IPv6, and covers the main transition and coexistence schemes, namely for IPv4/IPv6 and NSAP/IPv6 environments. In addition, annex A presents the internal structure of an IPv6/IPv4 node, annex B presents some tunneling examples, annex C presents the structure of IPv4 and IPv6 headers, annex D summarizes a combined IPv4 and IPv6 sending algorithm that IPv6/IPv4 nodes can use, and annex E lists IPv6 specification documents for further reading. 2. REFERENCES [1] - Robert M. Hinden, Stephen E. Deering, RFC IP Version 6 Addressing Architecture, December 1995 (18 pages). [2] - Robert M. Hinden, IP Next Generation Overview, Connexions - The Interoperability Report, ISSN , vol. 9, no. 3, pp. 2-18, March [3] - S. Thomson, C. Huitema, RFC DNS Extensions to support IP version 6, December 1995 (5 pages). [4] - IAB, IESG, RFC IPv6 Address Allocation Management, December 1995 (2 pages). [5] - R. Gilligan, E. Nordmark, RFC Transition Mechanisms for IPv6 Hosts and Routers, April 1996 (19 pages). [6] - J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd, OSI NSAPs and IPv6, Internet Draft, May 1996, to be published as an RFC (formerly, <draft-ietf-ipngwg-nsap-ipv6-01.txt>) (17 pages). [7] - ISO/IEC 8348: Information technology - Open System Interconnection - Network Service Definition (63 pages). [8] - On-line IPng home page -

6 3. TERMINOLOGY AND DEFINITIONS Node: a device that implements IP. Interface: a physical network point of attachment. Router: a node that forwards IP packets not explicitly addressed to itself. Host: any node that is not a router. Packet: an IP header plus payload. Address: an IP identifier for an interface or set of interfaces. IPv4-only node: a host or router that implements only IPv4. An IPv4-only node does not support IPv6 operation. IPv6/IPv4 (dual) node: a host or router that implements both IPv4 and IPv6 as well as other transition mechanisms such as tunneling. IPv6-only node: a host or router that implements IPv6, and does not implement IPv4. IPv6-only nodes also implement a few minimal transition mechanisms, but do not implement tunneling. IPv6 node: any host or router that implements IPv6. Both IPv6/IPv4 and IPv6-only nodes are IPv6 nodes. IPv4 node: any host or router that implements IPv4. Both IPv6/IPv4 and IPv4-only nodes are IPv4 nodes. IPv6/IPv4 header translating router: an IPv6/IPv4 router that performs IPv6/IPv4 header translation. IPv4-compatible IPv6 address: an address, assigned to an IPv6 node, that can be used in both IPv6 and IPv4 packets. IPv4-mapped IPv6 address: the address of an IPv4-only node represented as an IPv6 address. IPv6-only address: an IPv6 address that does not necessarily hold an IPv4-address embedded in the loworder 32-bits. IPv6-only addresses bear prefixes other than 0:0:0:0:0:0 and 0:0:0:0:0:FFFF. IPv4-complete area: a region of infrastructure that can route IPv4 packets only. IPv6-complete area: a region of infrastructure that can route IPv6 packets only. IPv6-over-IPv4 tunneling: the technique of encapsulating IPv6 packets within IPv4 packets, so that they can be carried across an IPv4-complete area. IPv6-in-IPv4 encapsulation: IPv6-over-IPv4 tunneling. IPv6/IPv4 header translation: the technique of translating the Internet headers of IPv6 packets into IPv4, and headers of IPv4 packets into IPv6, so that IPv4-only and IPv6-only hosts can interoperate. 4

7 4. IPv6 ADDRESSING This section presents the general addressing architecture for IPv6. RFC 1884 [1] is the main reference for this section. 4.1 Address types IPv6 addresses are 128-bit (16 octets) identifiers for interfaces and sets of interfaces. There are three types of addresses: unicast, anycast, and multicast. There are no broadcast addresses in IPv6, their function being superseded by multicast addresses. Unicast addresses identify a single interface. A packet sent to an unicast address is delivered to the interface identified by that address. Anycast addresses identify a set of interfaces, typically belonging to different nodes. A packet sent to an anycast address is delivered to one of the interfaces identified by that address. The interface which will receive the packet is the "nearest" one, according to the routing protocols' measure of distance. Multicast addresses identify a set of interfaces, typically belonging to different nodes. A packet sent to a multicast address is delivered to all interfaces identified by that address. 4.2 Interface address assignment principles Since each interface belongs to a single node, any of that node's interfaces unicast addresses may be used as an identifier for the node. An IPv6 unicast address refers to a single interface. A single interface may have multiple IPv6 addresses of any of the address types identified in 4.1 above. There are two exceptions to this: 1) a single address may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as one interface when presenting it to the internet layer. 2) routers may have unnumbered interfaces (i.e., no IPv6 address assigned to the interface) on point-topoint links to eliminate the necessity to manually configure and advertise the addresses. 4.3 Initial address allocation IPv6 supports addresses with four times the number of bits compared to IPv4 addresses (128 bits versus 32). This correspondes to an address space (2 96 ) times the size of the IPv4 address space. Although this is an extremely large address space, the assignment and routing of addresses requires the use of hierarchical schemes that reduce the efficiency of the address space usage. Nevertheless, it is estimated that, in the worst case, 128-bit IPv6 addresses can accomodate hosts, which is still extremely large (more than 1500 addresses per square meter of the Earth surface [2]). The specific type of an IPv6 address is indicated by the leading bits in the address. The current allocation of the prefixes is presented in Fig. 1.

8 Allocation Prefix (Binary) Fraction of Address Space Reserved /256 Unassigned /256 Reserved for NSAP Allocation /128 Reserved for IPX Allocation /128 Unassigned /128 Unassigned /32 Unassigned /16 Unassigned 001 1/8 Provider-Based Unicast Address 010 1/8 Unassigned 011 1/8 Reserved for Geographic-Based 100 1/8 Unicast Addresses Unassigned 101 1/8 Unassigned 110 1/8 Unassigned /16 Unassigned /32 Unassigned /64 Unassigned /128 Unassigned /512 Link Local Use Address /1024 Site Local Use Address /1024 Multicast Addresses /256 Note: the unspecified address (section 4.5.1), the loopback address (section 4.5.1), and IPv6 addresses with embedded IPv4 addresses (section 5.2.1) are assigned out of the format prefix space. Figure 1 - Initial IPv6 address allocation 4.4 Representation of IPv6 addresses There are three conventions for representing IPv6 addresses as text strings: the preferred form (full IPv6 address form in hexadecimal values), the compressed form (with substitution of zero strings) and the mixed form (convenient for mixed environments of IPv4 and IPv6 nodes). The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. Some examples are: FEDC:2A5F:709C:216:AEBC:97:3154:3D :2A9C:0:0:0:500:200C:3A4 In this form of address representation it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field. 6

9 Due to the method of allocating IPv6 addresses (see Fig. 1), it will be common for addresses to contain long strings of zero bits. In order to make the writing of addresses containing long chains of zero bits easier, the compressed form can be used. The use of two consecutive colons, "::", indicates multiple groups of 16-bits of zeros. The "::" can only appear once in an address. For example: FF08:0:0:0:0:0:209A:61 may be represented as FF08::209A: :2A9C:0:0:0:500:200C:3A4 may be represented as 1030:2A9C::500:200C:3A4 0:0:0:0:0:0:0:1 may be represented as ::1 In mixed environments of IPv4 and IPv6 nodes, a more convenient form of address representation can be used: the mixed form. In this form, node addresses are expressed as x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address in the standard IPv4 representation. Some examples are: or, in compressed form, 0:0:0:0:0:0: :0:0:0:0:FFFF: :: ::FFFF: Unicast addresses Forms of unicast addresses Presently, there are several forms of unicast address assignment in IPv6: the global provider based unicast address; the geographic based unicast address; the NSAP address; the IPX hierarchical address; the site-local-use address; the link-local-use address; the IPv4-capable host address. IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays (e.g., host versus router). At a minimum, a node may consider that unicast addresses (including its own) have no internal structure (Fig. 2). 128 bits (16 octets) node address Figure 2 - Unicast address seen as containing no hierarchical structure More sophisticated hosts (e.g., routers) may be aware of hierarchical boundaries in the unicast address. The known boundaries will differ from node to node, depending on the role of the node and its position

10 in the infrastructure hierarchy. Figure 3 illustrates the case where a site or organization requires several layers of internal hierarchy. s bits n bits m bits 128-s-n-m bits Prefix Area ID Subnet ID InterfaceID Figure 3 - Unicast address with several layers of internal hierarchy The address 0:0:0:0:0:0:0:0 is called the unspecified address. It must never be assigned to any node. It indicates the absence of an address. One example of its use is in the Source Address field of any IPv6 datagrams sent by an initializing host before it has learned its own address. The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 datagram to itself. It may never be assigned to any interface and it must not be used as a source address of any IPv6 datagrams that are sent to the network Provider-based addresses Provider-based unicast addresses are used for global communication. Their format is illustrated in Figure 4. 3 bits n bits m bits o bits 125-n-m-o bits 010 Regitry ID Provider ID Subscriber ID Intra-subscriber Figure 4 - Provider-based unicast address format The first three bits identify the address as a provider-based address. The following fields are assigned respectively to registry authorities, who then assign portions of the address space to service providers, who then assign portions of the address space to subscribers. The intra-subscriber portion of the address is organized according to the subscriber local internet topology Local-use addresses A local-use address is a unicast address that has only local routability scope. There are two types of local-use addresses: link-local and site-local. Link-local-use addresses are designed to be used for addressing on a single link, for purposes such as auto-address configuration, neighbor discovery, or when no routers are present. Site-local addresses may be used for sites or organizations that are not connected to the global Internet. The low-order part of both types of local use addresses contains an interface ID field which must be unique in the domain in which it is being used. In most cases this field will contain the node s IEEE bit address. 4.6 Anycast addresses 8

11 An IPv6 anycast address is an address that is assigned to more than one interface, typically belonging to different nodes. A packet sent to an anycast address is routed to the nearest interface having that address, according to the routing protocols measure of distance. One expected use of anycast addresses is to identify the set of routers belonging to an Internet service provider. Some other possible uses are to identify the set of routers attached to a particular subnet, or the set of routers providing entry into a particular routing domain. Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address. Until more experience has been gained, the following restrictions are imposed on IPv6 anycast addresses: - an anycast address must not be used as the source address of an IPv6 packet; - an anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. 4.7 Multicast addresses An IPv6 multicast address is an identifier for a group of nodes, and its format is as follows: 8 bits 4 bits 4 bits 112 bits flgs scop group ID The fields have the following meanings: Figure 5 - Multicast address format at the start of the address identifies the address as being a multicast address; flgs is a set of 4 flags. The high-order 3 flags are reserved, and must be initialized to 0. The value 0 for the low-order flag indicates a permanently-assigned ( well-known ) multicast address, assigned by the global Internet numbering authority. The value 1 for the low-order flag indicates a non-permanently-assigned ( transient ) multicast address; scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: 0 Reserved 1 Node-local scope 2 Link-local scope 3, 4 (unassigned) 5 Site-local scope 6, 7 (unassigned) 8 Organization-local scope 9 - D (unassigned)

12 E F Global scope Reserved group ID identifies the multicast group. Multicast addresses must not be used as source addresses in IPv6 datagrams or appear in any routing header Pre-defined multicast addresses Figure 6 presents some well-known multicast addresses that are reserved or pre-defined. FF00:0:0:0:0:0:0 FF01:0:0:0:0:0:0 FF02:0:0:0:0:0:0 FF03:0:0:0:0:0:0 FF04:0:0:0:0:0:0 FF05:0:0:0:0:0:0 FF06:0:0:0:0:0:0 FF07:0:0:0:0:0:0 FF08:0:0:0:0:0:0 FF09:0:0:0:0:0:0 FF0A:0:0:0:0:0:0 FF0B:0:0:0:0:0:0 FF0C:0:0:0:0:0:0 FF0D:0:0:0:0:0:0 FF0E:0:0:0:0:0:0 FF0F:0:0:0:0:0:0 FF01:0:0:0:0:0:1 FF02:0:0:0:0:0:1 FF01:0:0:0:0:0:2 FF02:0:0:0:0:0:2 Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved All nodes (node-local scope) All nodes (link-local scope) All routers (node-local scope) All routers (link-local scope) Figure 6 - Some pre-defined multicast addresses 4.8 Address resolution The Domain Name System (DNS) is used to map hostnames into both IPv4 and IPv6 addresses. IPv4 addresses (32-bit addresses) are listed in A resource records. A new resource record type named AAAA has been defined [3] in order to store a host s IPv6 address (128-bit address). A host that has more than one IPv6 address must have more than one such record. Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they must provide resolver libraries capable of dealing with IPv4 A records as well as IPv6 AAAA records. 4.9 Address allocation 10

13 The Internet Assigned Numbers Authority (IANA) has the responsibility for the management of the IPv6 address space [4], with the advice of the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG). Address allocation management will be carried out with a small element of central authority over the delegation to regional registries. These regional registries will make specific address allocations to network service providers and other subregional registries. The IANA will develop a plan for the initial IPv6 address allocation, including a provision for the automatic allocation of IPv6 addresses to holders of IPv4 addresses. 5. TRANSITION AND COEXISTENCE This section presents IPv6 transition and coexistence mechanisms. Document [5] is the main reference for this section. 5.1 Dual IP layer The most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes is by providing a complete IPv4 implementation. Such nodes are called IPv6/IPv4 nodes. IPv6/IPv4 nodes have the ability to send and receive both IPv4 and IPv6 packets. They can directly interoperate with IPv6 nodes using IPv6 packets. Conceptually, the protocol layering in IPv6/IPv4 dual nodes is represented in Figure 7. Annex A presents a diagram of a possible internal structure of an IPv6/IPv4 node at the physical, internet and transport layers. Telnet, FTP, SMTP, etc. TCP, UDP, etc IPv4 IPv6 Ethernet, FDDI, PPP, etc.

14 Figure 7 - Protocol layering in IPv6/IPv4 dual nodes The dual IP layer technique may or may not be used in conjunction with the IPv6-over-IPv4 tunneling techniques, which are described in section 5.3. An IPv6/IPv4 node that supports tunneling can support both configured and automatic tunneling, or configured tunneling only. Thus, three configurations are possible: - IPv6/IPv4 node that does not perform tunneling; - IPv6/IPv4 node that performs configured tunneling and automatic tunneling; - IPv6/IPv4 node that performs configured tunneling only. Automatic tunnels are used to deliver IPv6 packets all the way to their end destinations. Configured tunnels are used to deliver IPv6 packets to an intermediary IPv6/IPv4 router. 5.2 Transition mechanisms This section describes the address forms used in the transition and how they will be operationally deployed IPv6 addresses with embedded IPv4 addresses The transition uses two special formats of IPv6 addresses, both of which hold an embedded IPv4 address: IPv4-compatible IPv6 address format, and IPv4-mapped IPv6 address format. IPv4-compatible addresses are assigned to IPv6/IPv4 nodes that support automatic tunneling, and have the following structure: 80 bits 16 bits 32 bits (10 octets) (2 octets) (4 octets) 0:0:0:0: IPv4 address Figure 8 - IPv4-compatible IPv6 address format The addresses of IPv4-only nodes are represented as IPv4-mapped IPv6 addresses. These addresses have the following structure: 80 bits 16 bits 32 bits (10 octets) (2 octets) (4 octets) 0:0:0:0:0 FFFF IPv4 address Figure 9 - IPv4-mapped IPv6 address format The remainder of the IPv6 address space (that is, all addresses with 96-bit prefixes other than 0:0:0:0:0:0 or 0:0:0:0:0:FFFF) is termed "IPv6-only address space" because it may only be used by IPv6 nodes. IPv4-compatible IPv6 addresses are designed to be used by IPv6 nodes that wish to interoperate with IPv4 nodes. These addresses are listed in the DNS in both IPv6 "AAAA" records and IPv4 "A" records. 12

15 The AAAA record holds the entire 128-bit (16 octets) address, while the "A" record holds the IPv4 address portion (the low-order 32-bits). Both types of address records are listed so that proper responses are made to queries from both IPv4 and IPv6 hosts. IPv4-mapped IPv6 addresses are only used to represent the addresses of IPv4 nodes. They are never assigned to IPv6 nodes. Thus they are listed in the DNS only in "A" records. Even though the addresses of all IPv4 nodes can be represented as IPv4-mapped IPv6 addresses, they are not listed in "AAAA" records. This practice simplifies DNS administration. IPv6-only addresses are only assigned to IPv6 nodes and can not be used for interoperation with IPv4 nodes. Thus these addresses are listed in the DNS only in "AAAA" records. They can not be listed in "A" records because they do not hold an embedded IPv4 address. When administrators assign IPv4-compatible IPv6 addresses to IPv6 nodes, they must assign the loworder 32-bits (the IPv4 address portion) according to the IPv4 numbering plan used on the subnet to which that node is attached. The IPv4 address part must be a valid, globally unique, IPv4 address. The entire space of IPv6-only addresses is available for use in a global IPv6 addressing plan that is not burdened with transition requirements. This allows, for example, the addressing plan for auto-configured addresses to be developed independent of the transition mechanisms. Figure 10 below summarizes, for each of the three types of IPv6 addresses, what type of node may be assigned to what type of address, and whether the address holds an embedded IPv4 address or not. Address Type High-order 96-bit prefix Embedded IPv4 Addr Type of Node IPv4-mapped 0:0:0:0:0:FFFF Yes IPv4-only IPv4-compatible 0:0:0:0:0:0 Yes IPv6/IPv4 or IPv6-only IPv6-only All others No IPv6/IPv4 or IPv6-only Figure 10 The ability of IPv4-only, IPv6/IPv4 and IPv6-only nodes configured with the various types of address to interoperate is depicted in Figure 11. IPv4- only node IPv6/IPv4 node with IPv4-compatible address IPv6/IPv4 node with IPv6-only address IPv6-only node with IPv4-compatible address IPv6-only node with IPv6-only address IPv4-only node D D N T N IPv6/IPv4 node with D D D D D IPv4-compatible address IPv6/IPv4 node with N D D D D IPv6-only address IPv6-only node with T D D D D IPv4-compatible address IPv6-only node with N D D D D

16 IPv6-only address D: Direct interoperability T: Interoperability with aid of a translating router N: Non interoperable Routing topologies Figure 11 - IPv4-IPv6 interoperability capabilities IPv4-complete areas are topologies that are totally connected by IPv4 routing. There is at least one IPv4 router attached to every subnet in an IPv4-complete area. These areas may also have partial IPv6 routing to some subnets, but no IPv6 routing is required. An area that provides only IPv4 routing would be considered an IPv4-complete area, as would one in which IPv6 routing was in the process of being deployed. IPv6-complete areas are topologies that are totally connected by IPv6 routing. There is at least one IPv6 router attached to every subnet in an IPv6-complete area. These areas may also have partial IPv4 routing to some subnets, but this is not required. A topology of dual IPv6/IPv4 routing, with IPv4 routing in the process of being de-commissioned, would be considered an IPv6-complete area, as would one which provides only IPv6 routing. IPv4-complete areas naturally impose some restrictions on what types of hosts can operate within their boundaries. Since there is no guarantee that IPv6 traffic can be handled, only hosts that can send and receive IPv4 can safely be deployed. This means that IPv4-only and IPv6/IPv4 hosts can be freely deployed within IPv4-complete areas, but that IPv6-only hosts generally cannot. Like IPv4-complete areas, IPv6-complete areas have natural restrictions on what types of hosts they can support. Since an IPv6-complete area carries only IPv6 traffic, only hosts that can send and receive IPv6 packets can be deployed. That means that IPv6/IPv4 and IPv6-only hosts can be freely deployed within IPv6-complete areas, but that IPv4-only hosts generally cannot. The two major protocol mechanisms used in the transition - tunneling and header translation - are based on some assumptions about the way that routing topologies will develop. The general model is that IPv4 routing infrastructures will incrementally evolve into IPv6. In most cases, IPv6 routing will initially be deployed in parallel with an already existing IPv4 routing infrastructure. The deployment of IPv6 routing will take place by upgrading existing IPv4-only routers to IPv6/IPv4. This will occur over a period of time, not all at once. The site will eventually be transformed into a complete dual IPv6/IPv4 infrastructure. At some later point, IPv4 routing will be turned off. This process will also likely be incremental. The later transition may take place by upgrading IPv6/IPv4 routers to IPv6-only, or by "turning off" the IPv4 software in IPv6/IPv4 routers. After this stage, a pure IPv6 infrastructure will be formed. The above described model is represented in the next figure. IPv4 IPv6/IPv4 14

17 IPv6/IPv4 IPv6 Figure 12 - IPv6 routing deployment A summary of which types of hosts may be deployed in each of the two types of topologies is given in Figure 13. IPv4-complete IPv6-complete IPv4-only Yes No IPv6/IPv4 Yes Yes IPv6-only No Yes Figure 13 - Hosts-topology compatibility IPv4-complete and IPv6-complete areas can be interconnected with header translating routers, as illustrated in Figure 14, below. The translating router allows IPv4-only hosts in the IPv4-complete area to interoperate with IPv6-only hosts in the IPv6-complete area. IPv4-complete area Translating Router IPv6-complete area Figure 14 - Interconnection of IPv4-complete and IPv6-complete areas 5.3 Tunneling IPv6-over-IPv4 tunneling IPv6 packets can be carried across segments of an IPv4-complete topology by using the IPv6-over-IPv4 tunneling technique. An IPv6/IPv4 node that has IPv4 reachability to another IPv6/IPv4 node may send IPv6 packets to that node by encapsulating them within IPv4 packets (see Fig. 15). In order for this technique to work, both nodes must be assigned IPv4-compatible IPv6 addresses. This is necessary because the low-order 32-bits of those addresses are used as source and destination addresses of the encapsulating IPv4 packet. IPv4 header (Protocol header field = 41) IPv6 header encaps > IPv6 header

18 Transport layer header < decaps. Transport layer header Data Data Figure 15 - Encapsulation and decapsulation of IPv6 packets Two types of tunneling are used. Automatic tunnels are used to deliver IPv6 packets all the way to their end destinations. Configured tunnels are used to deliver IPv6 packets to an intermediary IPv6/IPv4 router. Both types of tunneling make use of the IPv4 address embedded in IPv4-compatible IPv6 addresses. In automatic tunneling, the tunnel endpoint address is taken from the IPv4 address embedded in the IPv6 destination address. No additional configuration information is needed because the destination address is carried in the IPv6 packet being tunneled. In configured tunneling, the tunnel endpoint address is that of an intermediate IPv6/IPv4 router. That address must be configured. This configuration information could come in the form of a routing table entry on a host, or neighbor configuration information on a router. Automatic tunneling is a basic feature of the transition. Hosts and routers will make extensive use of automatic tunneling when there is still a significant amount of IPv4 routing infrastructure. Hosts use configured tunneling less often, while routers may commonly use configured tunnels. Annex B presents some tunneling examples Tunnel addressing In both types of tunneling (automatic and configured), the source address of the IPv4 header of the tunneled packet is the low-order 32-bits of the IPv4-compatible IPv6 address of the node that performs the encapsulation. The IPv4 destination address is low-order 32-bits of the IPv4-compatible IPv6 address of the tunnel endpoint. Except for the case of header translating routers, the intermediary routers on the path between the encapsulating node and the decapsulating node do not look at the IPv6 header of the packet. They route the packet based entirely on its IPv4 header. This is the case even if the routers along the path are IPv6/IPv4 routers. Figure 16 summarizes the two types of tunneling. Tunneling Type Encapsulating Node Decapsulating Node Tunnel Endpoint IPv4 Address Automatic Source Host Dest. Host Low order 32-bits of dest. host IPv6 address Automatic Router Dest. Host Low order 32-bits of dest. host IPv6 address Configured Source Host Router Low order 32-bits of decapsul. router IPv6 address Configured Router Router Low order 32-bits of decapsul. router IPv6 address Figure 16 - Tunneling 16

19 5.4 Header translation Header translation is an optional mechanism that is used when one wishes to allow IPv6-only nodes to interoperate with IPv4-only nodes. Header translation is performed by header translating routers, which interconnect IPv4-complete and IPv6-complete areas. Most of the traffic crossing the boundary between these areas must be translated. This traffic can come in a number of different forms: i) terminating IPv4 traffic - IPv4 packets that are addressed to a node inside the IPv6-complete area; ii) transit IPv4 traffic - IPv4 packets that are addressed to a node that is outside the IPv6- complete area, but that must pass through the IPv6-complete area; iii) terminating IPv6 traffic - IPv6 packets that are addressed to a node inside the IPv4-complete area; iv) transit IPv6 traffic - IPv6 packets that are addressed to a node outside the IPv4-complete area, but that must pass through the IPv4-complete area; v) encapsulated IPv6 traffic - IPv6 packets encapsulated in IPv4 packets. Header translators are IPv6/IPv4 routers. They operate by translating the headers of IPv4 packets into IPv6, and IPv6 headers into IPv4. They require some configuration information in order to know which packets should be translated, and which should be simply forwarded unmodified. Figure 17 illustrates the case where header translation is being used to communicate between an IPv4- complete area and an IPv6-complete area. Header translators must translate all IPv4 packets that are addressed to nodes located within the IPv6-complete area, or that must transit the IPv6-complete area. IPv4 Packet Translate IPv6 Packet IPv4-complete area Translating Router IPv6-complete area IPv4-only node IPv6-only node Fig Interoperation by means of translation When translating IPv6 packets to IPv4, translating routers use the low-order 32-bits of the source and destination IPv6 addresses to generate the addresses for the IPv4 packet. Both the source and destination must be IPv4-compatible IPv6 addresses in order for the packet to be translated. When translating IPv4 packets to IPv6, translating routers add the prefix 0:0:0:0:0:0 to the IPv4 source address to generate the source address for the IPv6 packet. They add either the prefix 0:0:0:0:0:FFFF or 0:0:0:0:0:0 to generate the destination address. Determining which prefix to add requires some

20 configuration information. Translators use the 0:0:0:0:0:0 prefix if the destination is located within the attached IPv6-complete area, and the prefix 0:0:0:0:0:FFFF if the destination is located outside. Annex C presents the data structures (using the C programming language) for IPv4 and IPv6 headers. 5.5 Upgrade dependencies Figure 18 summarizes the operational dependencies that network and system administrators must consider in planning the upgrade of systems to IPv6. Transition Step DNS upgrade to support AAAA records Upgrade IPv4 host or router to IPv6/IPv4 Deploy new IPv6/IPv4 host or router Change IPv4-complete area to IPv6-complete Upgrade IPv6/IPv4 host or router to IPv6-only Deploy new IPv6-only host or router Depends On None DNS upgrade to support AAAA records DNS upgrade to support AAAA records Install Translating router at border Upgrade all routers within area to IPv6/IPv4 Change area from IPv4-complete to IPv6-complete Change area from IPv4-complete to IPv6-complete Figure 18 - Upgrade dependencies 5.6 OSI NSAP address mapping The fraction of IPv6 address space reserved to NSAP address allocation is 1/128. The mapping between NSAP addresses and IPv6 addresses is still under study [6]. Document [6] corresponds to work in progress, and does not address issues associated with migrating the routing protocols used with OSI CLNP (ES-IS or IS-IS) and transition of their network infrastructure. The general format for NSAP addresses mapped into IPv6 adresses is presented in Figure bits 121 bits to be defined Figure 19 - IPv6 NSAP address format ISO/IEC 8348 [7] specifies a maximum NSAP address size of 20 octets, and some metwork implementors have designed address allocation schemes which make use of this 20 octet address space. On the other hand, IPv6 addresses are 16 octets long. Address mapping can also lead to problems in terms of routing. Typically, NSAP addresses can be routed hierarchically down to an area level, but must be flat-routed within an area. On the other hand, 18

21 IPv6 addresses can be routed hierarchically down to the physical subnet level and only have to be flatrouted on the physical subnet. This may have a signifficant implication for routing, since it means that routing between the two worlds is unlikely to be optimised. Document [6] presents four mechanisms for NSAP-IPv6 mapping, that take into account the different sizes and different approaches adopted in these two addressing schemes: - restricted NSAP address mapping into 16-octet IPv6 address - truncated NSAP address for routing, full NSAP address in IPv6 option - normal IPv6 address, full NSAP address in IPv6 option - IPv6 address carried as OSI address In the following sections, a summary of the address mapping mechanisms defined in [6] is presented Restricted NSAP address mapping into 16-octet IPv6 address This mechanism identifies a way to map a subset of the NSAP address space into the IPv6 address space. The mechanism relies on the fact that the longest CLNP routing prefixes known to be in active use today are 5 octets, enabling the semantics of existing 20-octet NSAP addresses to be fully mapped, as presented in Figure AFcode IDI (last 3 digits) Prefix(octet 0) 4-7 Prefix (octets 1 through 4) 8-11 Area (octets 0 and 1) ID (octets 0 and 1) ID (octets 2 through 5) The AFcode nibble is overloaded, and encoded as follows Implied AFI value is 47 (ICD) (0-9 decimal) AFcode is first BCD digit of the ICD IDI is last three BCD digits of the ICD 1010 Implied AFI value is 39 (DCC) (hex. A) IDI is the three BCD digits of the DCC Reserved, not to be used. (hex. B-F) Figure 20 - Restricted NSAP address mapping into 16-octet IPv6 address Truncated NSAP address used as an IPv6 address This mechanism is based on the fact that an NSAP address contains routing information whose format and length are typically compatible with a 16-octet IPv6 address. If this form of address mapping is used, either an NSAP address destination option or an encapsulated CLNP packet must be present. It is

22 the responsibility of the destination system to take the appropriate action (e.g., forward, decapsulate, discard) for each received IPv6 packet. The following figure illustrates this mapping mechanism High order octets of full NSAP address 4-7 NSAP address continued 8-11 NSAP address continued NSAP address truncated... zero pads if necessary Figure 21 - Truncated NSAP address used as an IPv6 address Normal IPv6 address, full NSAP address in IPv6 option This mechanism relies on the use of normal IPv6 addresses (unicast address or anycast address) and on the carrying of the full NSAP address in a destination option. A destination option may also be present in the case of a truncated NSAP address used as an IPv6 address (see above). The NSAP address destination option is illustrated in Figure 22. The option type code is (195 decimal). The NSAP encodings follow ISO/IEC 8348 exactly Opt Data Len Source NSAP Len Dest. NSAP Len + + Source NSAP Destination NSAP + + Figure 22 - NSAP address destination option IPv6 address carried as OSI address This mapping mechanism allows the embedding of IPv6 addressses inside 20-octet NSAP addresses. Possible uses of this mechanism would be to allow CLNP packets that encapsulate IPv6 packets to be routed in a CLNP network using the IPv6 address architecture. The address format is presented in Figure 23, below. 20

23 AFI = 35 ICP = 0000 IPv6 (byte 0) 4-7 IPv6 (bytes 1-4) 8-11 IPv6 (bytes 5-8) IPv6 (bytes 9-12) IPv6 (bytes 13-15) Figure 23 - IPv6 address inside an NSAP address The first three octets are an IDP in binary format, using the AFI code in the process of being allocated to IANA (the AFI value provisionally allocated is 35, but this requires a formal modification to ISO/IEC 8348). The second and third octets of the IDP are known as the ICP (Internet Code Point) and must be zero. All other values are reserved for allocation by the IANA. Recursive address embedding is considered dangerous since it might lead to routing table anomalies or to loops. Thus embedded IPv6 addresses must not have the prefixes 0x02 (restricted NSAP address in a 16-octet IPv6 address) or 0x03 (truncated NSAP address used as an IPv6 address), and an NSAP address with the IANA AFI code must not be embedded in an IPv6 header.

24 ANNEX A - INTERNAL STRUCTURE OF AN IPv6/IPv4 NODE This annex presents a possible structure for IPv6/IPv4 dual nodes, at the physical, internet and transport layers. TCP Transport drivers for IPv4 Transport drivers for IPv6 ❷ ❸ ip_forward ip_output ipv6_input ipv6_forward ipv6_output IPv4 ❶ IPv6 ❹ ipintr ether_output v4 ether_output v6 ipinitr if_snd ether_input Packets in Ethernet Packets out Paths ❶ and ❷ - testing paths, for use with previous transport drivers (transport drivers for IPv4) Paths ❸ and ❹ - tunneling paths Figure A.1 - Internal structure of an IPv6/IPv4 node 22

25 ANNEX B - EXAMPLES This annex presents some tunneling examples. Additional information can be found in document [5]. B.1 Automatic IPv6-over-IPv4 tunneling When automatic IPv6-over-IPv4 tunneling is used between two IPv6/IPv4 hosts, it is "end-to-end". Automatic tunneling can also be used "router-to-host". IPv6/IPv4 routers may send IPv6-in-IPv4 packets to IPv6/IPv4 hosts that are connected to a common IPv4-complete area without requiring any configuration information. Automatic tunneling is generally used between IPv6/IPv4 hosts that are connected to a common IPv4- complete area. For example, consider two IPv6/IPv4 hosts H1 and H2: IPv6/IPv4 IPv6/IPv4 Host H1 IPv4-complete area Host H2 (0:0:0:0:0:0: ) (0:0:0:0:0:0: ) Figure B.1 If H1 wishes to send an IPv6 packet to H2, it encapsulates that packet within an IPv4 packet as follows: src = dst = src = 0:0:0:0:0:0:129: dst = 0:0:0:0:0:0: IPv4 Header IPv6 Header Figure B.2 When H2 receives this packet, it decapsulates it (removes the IPv4 header), and then processes the IPv6 header as it would for any received IPv6 packet. Note that the source address of the encapsulating IPv4 packet is the low-order 32-bits of H1's IPv4- compatible IPv6 address, and the destination address is the low-order 32-bits of H2's IPv4-compatible IPv6 address.

26 B.2 Configured IPv6-over-IPv4 tunneling Tunneling can also be used between two IPv6/IPv4 routers, or by an IPv6/IPv4 host to an IPv6/IPv4 router. In these cases, the tunnel does not extend all the way to the packet's final destination. It runs only as far as an intermediary router. For example, consider two IPv6/IPv4 hosts H1 and H2 and router R1: IPv6/IPv4 IPv6/IPv4 Host H1 IPv4 complete area Router R1 (0:0:0:0:0:0: ) (0:0:0:0:0:0: ) IPv6/IPv4 Host H2 (0:0:0:0:0:0: ) Figure B.3 If H1 wishes to send an IPv6 packet to H2 by tunneling to router R1, it could encapsulate that packet within an IPv4 packet as follows: src = dst = src = 0:0:0:0:0:0:129: dst = 0:0:0:0:0:0: IPv4 Header IPv6 Header Figure B.4 Note that the IPv4 destination address is the low-order 32-bits of R1's IPv6 address, while the IPv6 destination address is H2's address. In this case, R1 is the tunnel endpoint. When R1 receives this packet, it decapsulates it (removes the IPv4 header), and then processes the IPv6 header, as it would for any received IPv6 packet. It then forwards the IPv6 packet based on its IPv6 destination address, and delivers the packet to H2. 24

27 ANNEX C - DATA STRUCTURES FOR IPv4 AND IPv6 HEADERS This annex presents examples of data structures that can hold the various fields of IPv4 and IPv6 headers. The data structures are written using the C programming language. C.1 IPv4 header structure IPv4 header /* * Internet address (a structure for historical reasons) */ struct in_addr { u_long s_addr; }; /* * Structure of an internet header, naked of options. * * We declare ip_len and ip_off to be short, rather than u_short * pragmatically since otherwise unsigned comparisons can result * against negative integers quite easily, and fail in subtle ways. */ struct ip { #if BYTE_ORDER == LITTLE_ENDIAN u_char ip_hl:4, /* header length */ ip_v:4; /* version */ #endif #if BYTE_ORDER == BIG_ENDIAN u_char ip_v:4, /* version */ ip_hl:4; /* header length */ #endif u_char ip_tos; /* type of service */ short ip_len; /* total length */ u_short ip_id; /* identification */ short ip_off; /* fragment offset field */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ }; u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src, /* source address */ ip_dst; /* dest address */

28 C.2 IPv6 header structure IPv6 header /* IPv6 address structure (128 bits) */ struct inng_addr { u_long sng_addr[4]; }; /* * Internet header, naked of options. */ struct ipng { #if BYTE_ORDER == LITTLE_ENDIAN u_long ipng_fb:28, /* flow label */ ipng_v:4; /* version */ #endif #if BYTE_ORDER == BIG_ENDIAN u_long ipng_v:4, /* version */ ipng_fb:28; /* flow label */ #endif short ipng_plen; /* payload length */ u_char ipng_nexth; /* next header */ u_char ipng_hopl; /* hop limit */ struct inng_addr ipng_src, /* source address */ ipng_dst; /* dest address */ };

29 ANNEX D - SENDING ALGORITHM This annex summarizes a combined IPv4 and IPv6 sending algorithm that IPv6/IPv4 nodes can use, presented and discussed in document [5]. The algorithm can be used to determine when to send IPv4 packets, when to send IPv6 packets, and when to perform automatic or configured tunneling. It illustrates how the techniques of dual IP layer, configured tunneling, and automatic tunneling can be used together. The algorithm, summarized in the form of a table, has the following properties: - sends IPv4 packets to all IPv4 destinations; - sends IPv6 packets to all IPv6 destinations on the same link; - using automatic tunneling, sends IPv6 packets encapsulated in IPv4 to IPv6 destinations with IPv4- compatible addresses that are located off-link; - sends IPv6 packets to IPv6 destinations located off-link when IPv6 routers are present; - using the default IPv6 tunnel, sends IPv6 packets encapsulated in IPv4 to IPv6 destinations with IPv6-only addresses when no IPv6 routers are present. End Node Address Type End Node On Link? IPv4 Router On Link? IPv6 Router On Link? Packet Format To Send IPv6 Dest. Addr IPv4 Dest. Addr Dlink Dest Addr IPv4 Yes N/A N/A IPv4 N/A E4 EL IPv4 No Yes N/A IPv4 N/A E4 RL IPv4 No No N/A UNRCH N/A N/A N/A IPv4-compat Yes N/A N/A IPv6 E6 N/A EL IPv4-compat No Yes N/A IPv6/4 E6 E4 RL IPv4-compat No No Yes IPv6 E6 N/A RL IPv4-compat No No No UNRCH N/A N/A N/A IPv6-only Yes N/A N/A IPv6 E6 N/A EL IPv6-only No N/A Yes IPv6 E6 N/A RL IPv6-only No Yes No IPv6/4 E6 T4 RL IPv6-only No No No UNRCH N/A N/A N/A Notes N/A: Not applicable or does not matter. E6: IPv6 address of end node. E4: IPv4 address of end node (low-order 32-bits of IPv4-compatible address). EL: Datalink address of end node. T4: IPv4 address of the tunnel endpoint. R6: IPv6 address of router. R4: IPv4 address of router. RL: Datalink address of router. IPv4: IPv4 packet format. IPv6: IPv6 packet format. IPv6/4: IPv6 encapsulated in IPv4 packet format. UNRCH: Destination is unreachable. Don't send a packet. Figure D.1 - Sending algorithm

30 ANNEX E - LIST OF IPv6 SPECIFICATION DOCUMENTS A list of documents simillar to the one presented in this annex can be found in reference [8]. Internet drafts correspond to work in progress and are draft documents valid for a maximum of six months. They may be updated, replaced, or obsoleted by other documents at any time. E.1 IPv6 Specification S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 1883, December E.2 Addressing Architecture R. Hinden, S. Deering, IP Version 6 Addressing Architecture, RFC 1884, December IAB, IESG, IPv6 Address Allocation Management, RFC 1881, December Y. Rekhter, T. Li, An Architecture for IPv6 Unicast Address Allocation, RFC 1887, December Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel, An IPv6 Provider-Based Unicast Address Format, Internet Draft, draft-ietf-ipngwg-unicast-addr-fmt-04.txt, March R. Hinden, IPv6 Testing Address Allocation, RFC 1897, January R. Elz, Identifying Interfaces in IPv6 link-local addresses, Internet Draft, draft-ietf-ipngwg-iid-02.txt, May E.3 Internet Control Message Protocol A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6), RFC 1885, December E.4 Path MTU Discovery J. McCann, S. Deering, Path MTU Discovery for IP version 6, Internet Draft, draft-ietf-ipngwgpmtuv6-03.txt, May E.5 Header Compression M. Degermark, B. Nordgren, S. Pink, Header Compression for IPv6, Internet Draft, draft-degermarkipv6-hc-00.txt, February E.6 Packet Tunneling A. Conta, S. Deering, Generic Packet Tunneling in IPv6 Specification, Internet Draft, draft-ietf-ipngwg-ipv6-tunnel-01.txt, February

31 E.7 Domain Name System S. Thomson, C. Huitema, DNS Extensions to support IP version 6, RFC 1886, December E.8 Transition Mechanisms R. Gilligan, E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, RFC 1933, April D. Haskin, R. Callon, Routing Aspects of IPv6 Transition, Internet Draft, draft-ietf-ngtrans-routingaspects-01.txt, May E.9 Routing G. Malkin, RIPng for IPv6, Internet Draft, draft-ietf-rip-ripng-03.txt, June Y. Rekhter, P. Traina, IDRP for IPv4 and v6, Internet Draft, draft-ietf-idr-idrp-v4v6-02.txt, January R. Coltun, J. Moy, OSPF Version 2 For IP Version 6, Internet Draft, draft-ietf-ospf-ospfv6-02.txt, June M. Shand, M. Thomas, Multi-homing Support in IPv6, Internet Draft, draft-shand-ipv6-multi-homing- 01.txt, June E.10 Security R. Atkinson, Security Architecture for the Internet Protocol, RFC 1825, August R. Atkinson, IP Authentication Header, RFC 1826, August R. Atkinson, IP Encapsulating Security Payload (ESP), RFC 1827, August P. Metzger, W. Simpson, IP Authentication using Keyed MD5, RFC 1828, August P. Karn, P. Metzger, W. Simpson, The ESP DES-CBC Transform, RFC 1829, August E.11 Discovery T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), Internet Draft, draft-ietf-ipngwg-discovery-06.txt, March E.12 Auto Configuration S. Thompson, T. Nartin, IPv6 Stateless Address Autoconfiguration, Internet Draft, draft-ietf-addrconfipv6-auto-07.txt, December J. Bound, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Internet Draft, draft-ietf-dhcdhcpv6-04.txt, February E.13 Program Interfaces