Network Working Group R. Despres Internet-Draft July 13, 2005 Expires: January 14, 2006 The v5 Approach for the Transition from IPv4 to IPv6 draft-despres-v6ops-transition-v5roadmap-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document introduces a new approach intended to lead to a simple roadmap from the IPv4 Internet to a pure IPv6 one. With it, applications, protocol stacks and customer edge devices need only one standardized intermediate v5 version between v4 and v6. Internet service providers upgrade their v4 service to two intermediate services: one with a v4 address and a v6 prefix, and one with only a v6 prefix but with access to transition tools within the Despres Expires January 14, 2006 [Page 1] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 network. Provision is also made for a standardized upgrade of 3GPP networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Customer entities and their versions . . . . . . . . . . . . . 5 3. Site Paths and their types . . . . . . . . . . . . . . . . . . 6 4. Wan services of the transition period . . . . . . . . . . . . 8 5. Packet types of the roadmap . . . . . . . . . . . . . . . . . 10 6. Network architecture of the v5 roadmap with its possible packet types . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. End to End Connectivity analysis . . . . . . . . . . . . . . . 16 8. The v5 Address format . . . . . . . . . . . . . . . . . . . . 18 9. Further work . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 23 Despres Expires January 14, 2006 [Page 2] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 1. Introduction Large efforts have been devoted to the problem of transition from IPv4 to IPv6 [1], but a single unified roadmap, encompassing manufacturer, provider and customer considerations, has still to be proposed. This purpose of this draft is to outline one, the v5 roadmap. Its objectives have been the following: 1. Customer entities which may independently move from a transition version to another (i.e. applications, host protocol stacks, customer edge routers, and customer site routers), should need only one intermediate version, the "v5" version, between its legacy v4 version and its target pure v6 version. The v5 version should, independently for each entity, be an upward compatible extension of the v4 one so that customers can adopt it readily as soon as available. 2. The number of different Wan services standardized for the roadmap should be a compromise between two objectives: on one hand minimize this number, for the simplicity of the roadmap and for ease of identification of which connectivities are possible between customers of different Wan services; on the other hand standardize enough intermediate Wan services for customers to obtain v6 connectivities before losing their v4 ones, and for new customers who get only v6 addresses to keep enough v4 connectivities. 3. When packets between two communicating applications can follow several paths end to end, e.g. one via the v6 native infrastructure and the other one via the native v4 infrastructure, rules of the roadmap should be such that the selected path optimum according to well understood criteria. To work out such a roadmap, it was not an objective that already specified transition tools such as 6to4, Isatap, tunnel brokers, Teredo, Bump-in-the-stack, Bump-in-the API, DSTM, NAT-PT, had to be used, collectively or individually. On the other hand, it was an objective that a new transition tool should be introduced only if strictly necessary for effectiveness and simplicity of the solution. An important simplifying choice has been to dispense the roadmap of having to support fragmentation of packets during the transition Despres Expires January 14, 2006 [Page 3] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 period. Reasons for finding this acceptable are that: v4 protocol stacks now have provisions to adapt to minimum packet sizes along end to end paths, which suppresses the need for fragmentation; practically all v4 network links now support 1500 octet frames, which is more than sufficient to convey v6 packets (the maximum size of which is 1280 octets) in v4 ones with any realistic encapsulation headers needed during the transition period. The v5 roadmap presented here is still incomplete. Until detailed specifications of all functions of v5 modules are produced, there may even be a risk of impossibility. Yet it is believed that the approach is sound and can greatly facilitate a willful and graceful deployment of IPv6. Despres Expires January 14, 2006 [Page 4] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 2. Customer entities and their versions In customer sites, entities which may, independently of each other, be v4, v6 or v5 are: o Applications (Ax) o Host protocol stacks (Hx) o Site local routing (LRx) o Customer edge devices (Ex) Abbreviations of their versions are as follows: .-------------.--------------------------------------------. | Customer | Version | . Entity .--------------.--------------.--------------. | | v4 | v5 | v6 | | | (legacy) |(intermediate)| (target) | .-------------.--------------.--------------.--------------. | | | | | | Application | A4 | A5 | A6 | | | | | | .-------------.--------------.--------------.--------------. | Host | | | | | Protocol | H4 | H5 | H6 | | Stack | | | | .-------------.--------------.--------------.--------------. | Site | | | | | Local | LR4 | LR5 | LR6 | | Routing | | | | .-------------.--------------.--------------.--------------. | Customer | | | | | Edge | E4 | E5 | E6 | | Device | | | | .-------------.--------------.--------------.--------------. Despres Expires January 14, 2006 [Page 5] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 3. Site Paths and their types In a customer site various combinations of customer entities are possible. The path which goes from an application in a host to the interface of its customer site to a Wan service is called the "site path" of this application. The analysis of which connectivities exist end to end between applications depending on their site paths and Wan services is a highly combinatorial problem. Its complexity is significantly reduced if it can be assumed, that v5 applications have the sum of connectivities of v4 an v6 ones, and that v5 protocol stack provide to v4 applications v6 connectivities (the v5 protocol stack H5 includes the Bump In the API function [3].) Also, it can be noted that in multi-host sites, once versions of a host and that of the customer edge device of the site are known, the version of site local routing does not influence possible connectivities with hosts in other sites. It is then convenient to analyze connectivity to introduce a "site path type" which combines versions of host and of the edge device of the path. The table below presents site path types for all possible site paths. Despres Expires January 14, 2006 [Page 6] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 .------------.----------.---------------.--------------.----------. | | Host | Site | Customer | Site | |Application | Protocol | Local | Edge | Path | | | Stack | Routing | Device | type | .------------.----------.---------------.--------------.----------. | A4 or A5 | H4 | |no edge device| H4E0 | .------------.----------.---------------.--------------.----------. |A4, A5 or A6| H5 | |no edge device| H5E0 | .------------.----------.---------------.--------------.----------. | A5 or A6 | H6 | |no edge device| H6E0 | .------------.----------.---------------.--------------.----------. | A4 or A5 | H4 | RL4 or RL5 | E4 | H4E4 | .------------.----------.---------------.--------------.----------. |A4, A5 or A6| H5 | RL4 or RL5 | E4 | H5E4 | .------------.----------.---------------.--------------.----------. | A4 or A5 | H4 | RL4 or RL5 | E5 | H4E5 | .------------.----------.---------------.--------------.----------. |A4, A5 or A6| H5 |RL4, RL5 or RL6| E5 | H5E5 | .------------.----------.---------------.--------------.----------. | A5 or A6 | H6 | RL5 or RL6 | E5 | H6E5 | .------------.----------.---------------.--------------.----------. |A4, A5 or A6| H5 | RL5 or RL6 | E6 | H5E6 | .------------.----------.---------------.--------------.----------. | A5 or A6 | H6 | RL5 or RL6 | E6 | H6E6 | .------------.----------.---------------.--------------.----------. SITE PATHS AND THEIR TYPES Despres Expires January 14, 2006 [Page 7] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 4. Wan services of the transition period Legacy v4 Wan services which are considered in the roadmap are the following: o "W4", the "v4 Wan service". With it, a fixed site customer has a v4 fixed address or prefix. o "W4D", the "dynamic v4 Wan service". With it where a fixed site customer has a v4 dynamic address, subject to DHCP assignment. o "WM4", the "mobile v4 Wan service". With it, a mobile customer gets a v4 dynamic address in a private address space (as in 3 GPP services). A provider gateway "GM4" performs NAPT address and port translation. Target Wan services are: o "W6", the"v6 Wan service". With it, a fixed site customer has a fixed v6 prefix. It may replace one of the intermediate Wan services when the customer no longer needs connectivity with v4 hosts at v4 global addresses, typically late in the transition period. o "WM6", the "mobile v6 Wan service". With it, a mobile customer gets a dynamic v6 prefix. Intermediate Wan services of the roadmap are the following: o "W5A", the "v5A Wan service". With it, a fixed site customer has a fixed v4 address (or prefix) and a fixed v6 prefix. It is the natural service to be offered to W4 customers to upgrade their v6 connectivities. o "W5B", the "v5B Wan service". With it, a fixed site customer has no v4 address but has a fixed v6 prefix and, to maintain satisfactory v4 connectivities, is authorized to use packet Despres Expires January 14, 2006 [Page 8] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 transformation service of some gateways within the network. These in-network gateways are: + A "G6" gateway, or "v6 gateway", converts, both ways, between native v6 packets at its v6 side and v6 packets encapsulated in v4 packets at its v4 side. (Having stateless operation, this gateway can, for scalability, be implemented in a set of parallel devices sharing the same v4 address and the same v6 prefix). + A "GT" gateway, or "translating gateway" performs stateful translation, both ways, between UDP or TCP v6 packets at its v6 side, and UDP or TCP v4 packets at its v4 side, connections being initiated from the v6 side. (For scalability, this gateway can be implemented in a set of parallel devices having load balancing on their v6 side, based on source and/or destination v6 addresses.) The W5B service is a natural service to be offered to W4D customers so that they get permanent addresses without consuming using a permanent v4 address. When the Wan service offered to a customer changes from W5A to W5B, the v4 address of the W5A service has to remain operational for some time, say 24 hours. Thus, ordinary connections using this address when the W5B service is entered are not disrupted. (Only connections lasting more than the 24 hours may have to be re-established.) o "WM5", the "mobile v5 Wan service". With it, a mobile customer gets a v4 dynamic address in a private address space and a dynamic v6 prefix. A "GMB" gateway (v5 mobile provider gateway), in addition to the NAPT function of GM4 gateways, routes v6 packets between the mobile access network and the native v6 routing network. It also converts, both ways, between native v6 packets, at its mobile access side, and v6 packets encapsulated in v4 ones at its v4 global routing network. Despres Expires January 14, 2006 [Page 9] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 5. Packet types of the roadmap Types of packets which flow across the network can be analyzed considering two subtypes: o "Application packet types", which apply end to end o "Link packet types", which apply independently on each traversed link Application packet types depend on whether the communicating applications are v6 (128 bit addresses) or v4 (32 bit addresses). They also depend, in the v4 case, on whether addresses seen by the two communicating applications are the same or are translated somewhere along the end to end path. They also depend on whether a port or the two ports seen by applications have or not values imposed by a port forwarding function somewhere along the end to end path. Application packet types of a connection at a given entity interface are noted as follows: o "4xx", the "v4 application" packet types, where each x, which concerns one end of the connection, can be N, F, T or P "N" means "native v4 end": there is no constraint on the payload (a host port may not even be defined), and source and destination addresses known by applications are the same at both ends. "F" means "port forwarding end": the host port at this end is used for port forwarding. Its value is imposed by a customer edge device in which, by a static table, a correspondence is established between this value and the (local) v4 address of the host. The v4 address of this end is translated somewhere along the end to end path. "T" means "address and port translation end": the host address of this end IS translated and the host port MAY BE translated, by a NAT or NAPT function, somewhere along the end to end path. The connection is necessarily initiated by the host at this end. "P" means "protocol translation end": the protocol is changed, the host address IS translated, and the host port MAY BE Despres Expires January 14, 2006 [Page 10] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 translated, by a GT gateway of the V5R Wan service. The connection is necessarily initiated by the host at this end. The first x concerns the end which, at the considered entity interface is in the direction opposite to the v6 routing network. The second x concerns is that of the end in the direction of the v6 routing network. "6", the "v6 application" packet type. Applications at both ends are v6. The packet payload is completely free, and the two communicating applications sees the same pair of host addresses (as in the native v4 case 4NN). Link packet types "/4", "/6" and "/F/4" are combined with application packet types as follows: o "6/4" is the "v6 in v4 encapsulation" packet type. A 6/4 packet is a v6 application packet encapsulated in an IPv4 packet. In the v4 packet, the protocol field is set to 41 (the same as in 6to4 [2] for the same purpose: encapsulation of v6 packets in v4 ones). Addresses of the v4 packet are derived from that of the v6 packet in a way which depends only on where the encapsulation is made (an implementation of zero configuration tunneling). o "6/F/4" is the "v6 over port forwarding encapsulation" packet type. A 6/F/4 packet is a v6 application packet encapsulated in UDP over IPv4. This type of encapsulation is used to transmit v6 packets across v4 customer edge devices which perform port forwarding. The v4 destination address is extracted from the v6 destination address, and the v4 source address is that of the last device which has created or modified the v4 packet. For an end subject to port forwarding, the UDP port is the forwarding port of its host, extracted from the v6 host Despres Expires January 14, 2006 [Page 11] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 address. For an encapsulating end not subject to port forwarding, the UDP port is 3554 (the port used in Teredo [4] for the same purpose: v6 packet encapsulation in UDP over IPv4). o "4xx/6" is the "v4 in v6 encapsulation" packet type. A 4xx/6 packet is a 4xx packet encapsulated in a v6 packet the two addresses of which are equivalent to v4 addresses. In the v6 packet, the protocol field is set to a value which should be the same as in DSTM (work in progress) if one is chosen for the same purpose: encapsulation of v4 packets in v6 ones. Each address in the v6 packet starts with 2002:xxxx:xxxx where xxxx:xxxx is the v4 addresses (0x2002 is the same /16 prefix as in 6to4 [2] for the same purpose, routing in v6 toward v4 addresses). o "4xx/4" and "6/6" are respectively the "v4 null encapsulations" and the "v6 null encapsulation" packet types. A 4xx/4 packet is a v4 application packet transmitted as a native v4 packet on the considered link. A 6/6 packet is a v6 application packet transmitted as a native v6 packet on the considered link. Despres Expires January 14, 2006 [Page 12] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 6. Network architecture of the v5 roadmap with its possible packet types Figure 1 presents the complet network architecture of the v5 roadmap. It includes: o Hosts of the 3 types (H4, H5, H6) o Site local routings of the 3 types (LR4, LR5, LR6) o Customer edge devices of the 3 types (E4, E5, E6) o Global routings of 2 types (R4, R6) o Mobile access networks of 2 types(3GPP4, 3GPP5) o Gateway functions of 6 types: * "GM" : gateway between a v4 mobile access network ("3GPP4") and the global v4 routing network (R4). * "GM5" : gateway between a v5 mobile access network ("3GPP5"), on one side, and the global v4 and the v6 routing networks on the other side (R4 and R6). * "G4", "G6" and "GT", the gateways between the v4 and v6 global routing networks (R4 and R6). They respectively concern connections between v4 applications at both ends, v6 applications at both ends, v6 application at the v6 side and v4 application at the v4 side. * "GE", the edge gateway function between a W5A customer interface and the v4 and/or v6 global routing networks. It is such that the provider infrastructure may, in the node of the interface, have v4 routing only, v6 routing only or both v4 and v6 routings. It performs, both ways, all the necessary packet transformations. Despres Expires January 14, 2006 [Page 13] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 o Wan service interfaces of the 8 types of Section 4 (legacy W4, W4D and WM4; target W6 and WM6; transition W5A, W5B and WM5) Boxes representing functional entities are linked by lines showing possible packet paths, with separate lines for v4 links and v6 links. Wan service interfaces are represented by vertical lines crossing packet path lines. Packet types which may be seen at interfaces of functional boxes are indicated next to boxes. Despres Expires January 14, 2006 [Page 14] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 WAN 3GPP SERVICES NETWORKS | | V V _ |3| _ _ (WM4) |G| | | | | HOSTS SITE CUSTOMER ! 4Tx/4 |P|4Tx/4|G|4Tx/4 | | | LOCAL EDGE .--!-------|P|-----|M|-----. | | | ROUTING DEVICES | |4| |_| | | | V V V +---+ |_| | | | | |(W4) | | | 4xx/4, 6/4, 6/F/4 | |(W4D) | | | .---------------------+ | ! 4xx/4, 6/4, 6/F/4 | | | | | +--!-----------------------+ | | | _ 4Tx/4 4Tx/4| | _ | |R| _ | | | 4Fx/4 _ 4Fx/4| | |3| _ +--+4| |H|4xx/4 | |L| 6/F/4|E|6/F/4| |(WMB)4Tx/4|G|4Tx/4|G|4Tx/4| | | |4|-----. +-|R|-. .-----|4|-----+ +--!-------|P|-----|M|-----' | | |_| | | |4| | | |_| | +-|--!-------|P|-----|B|-----. | | | | |_| | | | | | 4Tx/6|B|4Tx/6|_|4Tx/6| | | +-+ | | | | | 6/6|_| 6/6 6/6 | | | | | +-+ 4Tx/4| | | | | | 4xx/4| | _ | | 4Tx 4Fx/4| | |(WB) _ 4xx/4, 6/4, 6/F/4 | | _ 6/4 | | | | | | 4Fx _ 6/4 | | +--!-----| |---------------|--+ | | |6/F/4| | |L| | | 6/4| |6/F/4| | !4xx/4| | .-<-------' | | |H|-----' '-|R|-' '-----|E|-----' | ! 6/4| | | _ .--|_| |B|-----. .-|B|-. .-----|B|-----. | !6/F/4|E| | | | '---<---. |_|4Nx/6| | | | | |4Tx/6|_|4Tx/6| | ! |G| | | | _ | 4Tx/6| | |_| | | 6/6 6/6 | | ! | | | |R|4Nx/6| |4Nx/4| 6/6 | | | | | | !4xx/6| |4xx/6| |6|-----|G|-----+ | | +-+ | | ! 6/6| |6/6 | | | |4| | +-+ _ | | | +----!-----| |-----+ | | |_| | _ 4Tx/6| | | | | |4Tx/6 _ 4Tx/6+-+ |_| +-+ | _ | |H|6/6 | | |L| | | 6/6|E|6/6 | | (W6+) 6/6| | | | |6/4 | |6|-----' +-|R|-' '-----|6|-----+ | ! /--------+ | | 6/6|G|6/F/4| |_| | |6| |_| | +----!---+---------|-+-+-----|6|-----+ | |_| | | \ | | | |_| | | | | \ | | | _ | '---------------------' | (W6) \ | | |4Px/6| |4Px/4| 4Nx/6, 4Px/6, 6/6 | (WM6) \-----|-+-+-----|G|-----' | ! | | | |T| '----!-------------' | | |_| 6/6, 4Px/6 |_| ROADMAP NETWORK ARCHITECTURE WITH ITS PACKET TYPES Figure 1 Despres Expires January 14, 2006 [Page 15] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 7. End to End Connectivity analysis Connectivity between two end applications depends on site paths and Wan services at both ends. An interesting result is that, with the v5 roadmap, to determine whether two end applications can communicate or not, it is sufficient to look at the possible packet formats of the [site path, Wan service] couples, for the two ends, and to see whether there include "compatible" packet formats or not. Figure 2 shows in a column what are the possible packet types for each site path type, and details in subsequent columns which of these packet types remain possible for each of the possible Wan services. Compatibility rules of two packet formats are the following: 1. 6/x and 6/y are compatible if x = y or, if one is 4 and the other 6, provided at least one of the Wan services is an intermediate one (W5A, W5B or WM5). 2. 4xx/y and 4xx/y are compatible provided they don't both impose where the connection comes from (both ends cannot be 4Tx/y or 4Px/y). A > signs in the table help viewing which packet types impose connection orientation. Despres Expires January 14, 2006 [Page 16] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 +-----------+--------+-----------------------------------------------+ | |possible| WAN SERVICE | | SITE PATH | packet +---------------+-------------------------------+ | | types | W4-W4D| WM4 | W5 | W6+ | WM5 |W6-WM6 | |--------------------+-------+-------+-------+-------+-------+-------+ |LE | H4E0 |4Nx/4 |4Nx/4 | |4Nx/4 | | | | |GA +-------+--------+-------+-------+-------+-------+-------+-------+ |CY | H4E4 |4Fx/4 |4Fx/4 | |4Fx/4 | | | | | | |4Tx/4 > |4Tx/4 >|4Tx/4 >|4Tx/4 >| |4Tx/4 >| | +---+-------+--------+-------+-------+-------+-------+-------+-------+ | | |4Nx/4 |4Nx/4 | |4Nx/4 | | | | | | H5E0 |6/4 |6/4 | |6/4 | | | | | | |6/F/4 |6/F/4 | |6/F/4 | | | | | +-------+--------+-------+-------+-------+-------+-------+-------+ | | |4Fx/4 |4Fx/4 | |4Fx/4 | | | | | T | H5E4 |4Tx/4 > |4Tx/4 >| |4Tx/4 >| |4Tx/4 >| | | R | |6/F/4 |6/F/4 | |6/F/4 | | | | | A +-------+--------+-------+-------+-------+-------+-------+-------+ | N | |4Fx/y |4Fx/4 | |4Fx/y | | | | | S | H4E5 |4Tx/y > |4Tx/4 >|4Tx/4 >|4Tx/y >| |4Tx/4 >| | | T +-------+--------+-------+-------+-------+-------+-------+-------+ | I | |4Fx/y |4Fx/4 | |4Fx/4 | | | | | O | |4Tx/y > |4Tx/4 >|4Tx/4 >|4Tx/4 >| |4Tx/4 >| | | N | H5E5 |4Px/6 > | | | |4Px/6 >| | | | | |6/y |6/4 | |6/y |6/6 |6/6 |6/6 | | | |6/F/4 |6/F/4 | |6/F/4 | | | | | +-------+--------+-------+-------+-------+-------+-------+-------+ | | |4Px/y > |4Px/4 >|4Px/4 >|4Px/4 >|4Px/6 >|4Px/6 >| | | | H6E5 |6/y |6/y | |6/y |6/6 |6/6 |6/6 | | | |6/F/4 |6/F/4 | |6/F/4 | | | | | +-------+--------+-------+-------+-------+-------+-------+-------+ | | H5E6 |4Px/6 > | | | |4Px/6 >| | | | | H5E6 |6/6 | | |6/6 |6/6 |6/6 |6/6 | +---+-------+--------+-------+-------+-------+-------+-------+-------+ |TAR| H6E0 |6/6 | | |6/6 |6/6 |6/6 |6/6 | |GET+-------+--------+-------+-------+-------+-------+-------+-------+ | | H6E6 |6/6 | | |6/6 |6/6 |6/6 |6/6 | +---+-------+--------+-------+-------+-------+-------+-------+-------+ POSSIBLE PACKET TYPES FOR [SITE PATH TYPE, WAN SERVICE] COUPLES Figure 2 Despres Expires January 14, 2006 [Page 17] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 8. The v5 Address format Network entities which transform packets, after having determined the format of received packets, must decide which packet format to use for transmission and, in case of encapsulation, must decide which addresses, and possibly which ports, to put in encapsulating headers. To do this appropriately it appears that many v6 addresses have to contain more information than with currently specified v6 address formats. It seems necessary and sufficient, for all configurations of the v5 roadmap architecture, that the v6 address of a host, may contains the following: o "HxEy", an indication of the type of the host site path. o "Wz", an indication of the Wan service at the host site. o Address components of the following list which are applicable to the host: * "P6", the v6 prefix of the site (a /48 prefix in the ordinary v6 address space for W5A, W5B, WM5, W6 and WM6 Wan services; the 0x2002 /16 prefix followed by a v4 address for the W4 service). * "GA4", the v4 global address of the site (for W4 and W5A services), or the v4 global address of an assigned G6 gateway (for the W5B service). * "LR4", the v4 local address of the host (for H4 or H5 hosts in multi-host sites having an E5 edge device). * "FP", the forwarding port of the host (for H4 or H5 hosts in multi-host sites having an E4 edge device and where at least one port is assigned to the host). * "IID", the IID of the host, at its standard place in bits 64 to 127 (for a H6 host in a single host site having a W6 or WM6 service, or in a site with a E5 or E6 edge device). The following detailed address format is proposed to show a possible implementation of the above principles, and also to provide for compatibility of independent experimentations of the v5 approach which may be engaged: Despres Expires January 14, 2006 [Page 18] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 48 16 16 16 16 16 .-----------------.--------.--------.--------.--------.----------. | P6 | GA4a | "HEW" | GA4b | LA4a |LA4b or FP| '-----------------'--------'--------'--------'--------'----------' V5 ADDRESS FORMAT The "HEW" field ("Host-Edge-Wan" field) contains a code for the HxEyWz information. It has 11 in its 7th and 8th bits, so that it can be distinguished from all other unicast v6 formats (universal IIDs have in these bits 10 and local ones 00 or 01). The HEW field is decomposed as follows: 4 4 4 4 .------------.------------.------------.------------. | Hx | 1 1 1 1 | Ex | Wx | .------------.------------.------------.------------. HEW FIELD FORMAT Values of the Hx and Ex fields are, to facilitate readability, 4, 5 and 6, respectively, to code H4, H5, H6 and E4, E5, E6. Coded values of the Wx field are the following, in hexadecimal: +-------------+----------+------+---------+------+------+ | Wan Service |WM4 or W4D| W4 |W6 or WM6| W5A | W5B | +-------------+----------+------+---------+------+------+ | Code | 3 | 4 | 6 | A | B | +-------------+----------+------+---------+------+------+ CODED VALUES OF THE Wx FIELD Despres Expires January 14, 2006 [Page 19] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 9. Further work First, exchanging views on the above approach to v4 to v6 transition is a highly expected next step. Since time has been too short to construct a complete specification of v5 customer entities and of the gateways of the roadmap architecture, an obvious other next step is to elaborate one. It is not unlikely that it leads to some (hopefully minor) corrections or enhancements of the above specification. Security considerations, should be incorporated. Implementing and experimenting is yet another obvious next step. The author believes that, more generally, the newly opened avenue, with its notion of a standardized and simple roadmap for v6 deployment, can lead to a number of interesting and useful other developments. Despres Expires January 14, 2006 [Page 20] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 10. Acknowledgements The study of a unified transition model toward extended addressing, which started in early 2003 with a personal work of the author leading to two patent applications, has benefited from numerous contacts with IPv6 experts. First and not least has been the contribution of Laurent Toutain, and that of its collaborators of the ENST-B in Rennes, Francis Dupont and Octavio Medina. Their advices helped greatly to integrate general ideas into the real world of existing IPv6 developments. Besides, Francis implemented of a workable demonstrator of some of the ideas, in one of their earlier versions (in particular the introduction of a host type in v6 addresses and the use of a v6 to v4 translation to reach v4 hosts in private sites). He has to be thanked for this. Many brief and informal contacts during IETF meetings 61 an 62 have also been essential to identify futureless directions and to reorient some of the ideas. In particular Erik Nordmark, Alain Durand and Tony Hain, who may not have been conscious of how useful and productive their remarks and challenges have been, while the project was still in a very immature stage, also deserve acknowledgements. 11. References [1] "Basic Transition Mechanisms for IPv6 hosts and Routers (work in progress)", March 29 2005. [2] "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [3] "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002. [4] "Teredo: Tunneling IPv6 over UDP through NATs (work in progress)", March 8 2004. [5] "Basic Transition Mechanisms for IPv6 hosts and Routers (work in progress)", March 29 2005. Despres Expires January 14, 2006 [Page 21] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 Author's Address Remi Despres 3, rue du President Wilson Levallois 92300 FR Phone: +33 6 72 74 94 88 Email: remi.despres@rd-iptech.com Despres Expires January 14, 2006 [Page 22] Internet-Draft Transition to IPv6 - The v5 Approach July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Despres Expires January 14, 2006 [Page 23]