Internet Engineering Task Force J. Bi Internet-Draft Y. Wang Intended status: Experimental X. Leng Expires: July 10, 2009 Tsinghua University Jan 6, 2009 Connecting IPvX Networks over IPvY with a P2P Method draft-jbi-pxp-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. Copyright and License Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Bi, et al. Expires July 10, 2009 [Page 1] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 Abstract This document presents a new method - PXP- to connect IPvX islands together over IPvY network and reduce the reliance on the relays of existing transition mechanisms by shifting the burden to edge gateways on each island. In this method, direct tunnels are set up between the IPvX islands, and a P2P overlay network is maintained between their gateways to propagate information of tunnel end points. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of the Solution . . . . . . . . . . . . . . . . . . . 8 5. The P2P Overlay Network . . . . . . . . . . . . . . . . . . . 10 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. New Subscription . . . . . . . . . . . . . . . . . . . . . 10 5.3. Failure Detection . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Details of the P2P Network . . . . . . . . . . . . . 12 6.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 12 6.2. Protocols between Newly Arrived Node and RS . . . . . . . 12 6.3. Protocols between Overlay Neighbors . . . . . . . . . . . 13 6.4. Protocol Formats . . . . . . . . . . . . . . . . . . . . . 15 6.4.1. Message Header . . . . . . . . . . . . . . . . . . . . 15 6.4.2. Hello Message . . . . . . . . . . . . . . . . . . . . 16 6.4.3. Update Message . . . . . . . . . . . . . . . . . . . . 16 6.4.4. Ack Message . . . . . . . . . . . . . . . . . . . . . 18 6.4.5. Request Message . . . . . . . . . . . . . . . . . . . 18 6.4.6. Register Message . . . . . . . . . . . . . . . . . . . 18 6.4.7. Reply Message . . . . . . . . . . . . . . . . . . . . 19 7. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Bi, et al. Expires July 10, 2009 [Page 2] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Bi, et al. Expires July 10, 2009 [Page 3] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 1. Introduction Due to rapid expansion of the Internet and the lack of unallocated global IPv4, the transition from IPv4 to IPv6 is proposed to solve the issues and becomes a worldwide trend as the Internet develops. Given the prevalence of the existing IPv4 network, the transition will need considerable time to complete. Some IPv4 subnets may, while having had their network infrastructure upgraded to support IPv6, still lack direct links to the native IPv6 network. In another scenario, some subnets inside the native IPv6 network may also want to communicate with the users inside native IPv4 network or use IPv4 applications. That is, there will be isolated IPvX (IPv6 or IPv4) islands inside the global IPvY (IPv4 or IPv6) network. In the existing methods, these islands use IPvX-in-IPvY tunnels (IPv6-in- IPv4 or IPv4-in-IPv6) via relay gateways maintained by IPvX service providers to join the native IPvX network. However, in these scenarios, all traffic from an IPvX island to another IPvX island will be forwarded via the IPvX-relay gateways from the source island to native IPvX network, and then be forwarded back from the native IPvX network to the destination island. Therefore, these relay gateways can potentially become the communication bottlenecks. A peer-to-peer (P2P) based algorithm PXP is proposed here in which direct tunnels are built between isolated IPvX islands to reduce the burden of IPvX-relay gateways maintained by service providers. A P2P overlay network is set up among the gateways of IPvX islands to propagate TEP (tunnel end point) information (IPvX prefixes, IPvY address of edge gateway) and set up the full mesh tunnels. When an IPvX island dual-stack gateway receives a data packet sent to the IPvX network, it firstly checks whether there is a direct tunnel to the destination address. For packets being transmitted, the shortcut tunnels between the source and destination islands are assigned higher route priority than tunnels to relay gateways of service providers. Bi, et al. Expires July 10, 2009 [Page 4] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] In addition, new terms are defined below: o Edge Gateway (EG): A dual-stack edge gateway of a IPvX (IPv6/IPv4) island inside IPvY (IPv4/IPv6) networks o Registration Server (RS): A server that helps the newly arrived node to join the P2P network. o TEP information: The information of a tunnel end point (TEP), such as: IP prefix, prefix length, IP address of this tunnel end, etc. Bi, et al. Expires July 10, 2009 [Page 5] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 3. Problem Statement In the process of the deployment of IPv6, native IPv6 networks - both IPv6-only and dual stacks - will connect with each other to eventually become an IPv6 continent. The upgrade of IPv4 networks to support IPv6, due to the huge existing investment in IPv4, will necessarily be a gradual process, and native IPv4 networks and native IPv6 networks will coexist for a long time. During this period of coexistence, there are two methods for dual stack hosts in an IPvY (IPv6/IPv4) continent to communicate with hosts in an IPvX (IPv4/ IPv6) continent and to use IPvY application. The first way is to directly set up a tunnel on the dual stack host itself. The second way is to make the local network support both IPv4 and IPv6 and set up a tunnel on the edge gateway of the local network. In this second method, the local network becomes an isolated IPvX island. When the internal information of local network needs to be protected, it is recommended that the second solution be used[I-D.v6ops-security-overview]. Existing methods for providing access service for IPvX islands inside IPvY networks include: 1. Automatic tunnels, such as 6to4 mechanism [RFC3056] where 6to4 addresses are used; 2. Configured tunnels, such as IPv4/IPv6 configured tunnel [RFC2893] where normal addresses are used. Without explicit tunnel setup, 6to4 technology is a simple solution for isolated IPv6 islands to communicate with each other and access the IPv6 continent with the help of 6to4 relays. The automatic tunnels between 6to4 networks can effectively mitigate the burden of 6to4 relays. This method does, however, pose significant management challenges for ISPs, and there are also security problems with 6to4 brought about by the automatic tunneling mechanism [RFC3964]. Even worse, there is no this kind of automatic tunneling mechanism when IPv4 over IPv6. With configured tunnels using normal addresses, the isolated islands can be treated as natural extensions of the IPvX continent. Furthermore, the manual configuration makes this kind of tunnel easy to control, and the security problems are greatly diminished when compared with 6to4. For the purpose of decreasing the configuration overhead, the model of Tunnel Broker (TB)[RFC3053] is often used to manage the configured tunnels automatically. The mechanisms with normal addresses generally use IPvX-relay gateways to provide the access service. As shown in Figure 1, all Bi, et al. Expires July 10, 2009 [Page 6] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 the traffic from IPvX islands will be forwarded by the relay gateways, even if the traffic is between IPvX islands. The relay gateways can potentially become communication bottlenecks. Since the existing optimization algorithms are mainly focusing on the service providers, the only way to increase overall performance is to increase the performance or the number of relay gateways, which could be a costly exercise. ,,.--.,,_ .'` '. ,.-., ' \+----+ ,' ``. | IPvX island | EG |- ,' . , /+----+ \ / \ ',_ ,- ` / , `''--''`` \ | | `. | | . | | ,,.--.,,_ . +------+ \ .'` '. \| | | ' \+----+ ,,.| RELAY| | | IPvX island | EG |--'``` /| | IPvX Continent | , /+----+ / +------+ | ',_ ,- / | | `''--''`` / \ / / | | / | | ,,.--.,,_ / | | .'` '. / \ ` ' \+----+/ \ / | IPvX island | EG | `. ' , /+----+ `. ,' ',_ ,- IPvY Continent `'-'`` `''--''`` Figure 1. Scenario of IPvX islands Bi, et al. Expires July 10, 2009 [Page 7] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 4. Overview of the Solution Here we present an optimizing algorithm PXP for the scenario above to provide high performance IPv4/6 access service. Besides the service providers, we also consider the customers - the edge gateways of the isolated islands. In this algorithm, direct tunnels are set up between IPvX (IPv6/IPv4) islands to transmit the traffic between these islands. When an IPvX island gateway receives a data packet with a destination address in another IPvX island, it directly forwards this packet to the destination island gateway through the IPvX network. Otherwise, it sends the packet to the relay gateway of the service provider. In PXP, a lookup operation is inserted into the flow for packet forwarding of IPvX island edge gateways. The steps of the proposed algorithm are described as follows: 1. Form a Tunnel Table on each IPvX island gateway by exchanging TEP information (IPvX prefixes, IPvY address of edge gateway) between the gateways. 2. When an island gateway receives an IPvX data packet, firstly, it examines the Tunnel Table to find out whether there is a direct tunnel to the destination. If yes, it then sends this packet directly to the IPvY address specified by the Tunnel Table; Otherwise, it then forwards this packet to the relay gateway of IPvX service provider The PXP algorithm is based on that for configured tunnels, inheriting the advantages for control, management and security. In addition, since the nearby subnets may have the same network environment, the IPvX islands may surround with each other and come into several clusters. For the principle of locality, the traffic forwarded by the relay gateways will be mostly restricted between IPvX islands. Furthermore, the network status between IPvX islands may be better than that between the islands and relay gateway. Therefore, as with 6to4, the direct tunnels between IPvX islands can effectively reduce the burden on the relay gateways and greatly increase the access performance of the isolated IPvX islands. In contrast to 6to4, there are no special addresses used in these islands, especially in the IPv4 islands. This makes it impossible for the island gateways to get the TEP information from the destination address of a data packet. How a gateway of IPvX island gets the TEP information of all the other IPvX islands is the key consideration in this algorithm. One solution is to set up a central server to hold all the information, send it to each island gateway and to propagate the updates. However, this method is not scalable, Bi, et al. Expires July 10, 2009 [Page 8] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 and will make the central server a weak point of the system. Another solution is to build a P2P overlay network between the edge gateways of IPvX islands with the help of a Registration Server (RS). The TEP information is propagated and updated by the P2P network. The RS is only the tracker of the P2P network and can be used for future control and management. In the PXP algorithm, we adopt this second option. The architecture of PXP is shown in Figure 2. EG1, EG2, �&# 65533; are edge gateways of IPvX islands. A P2P network is maintained by them to share TEP information. With the TEP information, shortcut tunnels are set up on each gateway for transferring data packets between these islands. _,,,,..-----..,,,,_ ,.-`` ``'., / ` \ P2P Overlay Network ' `'.,, _..-` | ```''''-----''''``` | | | | | _,.---.,, | | _,.--.,, .` `. | | .` ` , ' \+--\--+ XoverY Tunnel +--\--+/ \ | IPvX island | EG1 |----------------| EG2 | IPvX island | , /+-----+ +-----+\ / ', ,- IPvY Continent ', ,- ``''--'`` `''--''` Figure 2. The PXP Algorithm Bi, et al. Expires July 10, 2009 [Page 9] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 5. The P2P Overlay Network 5.1. Overview A P2P network is set up to propagate TEP information among the IPvX island gateways. Each IPv4 island edge gateway broadcasts its TEP information inside the P2P network and gets the other gateways&# 65533;� TEP information from its peers. As the PXP algorithm should not introduce too much overhead, we have chosen to use an Unstructured P2P network where each node chooses its neighbors randomly. A Registration Server is set up as a tracker to help the gateways of IPvX islands join the P2P network gradually. It then knows the IPv6 addresses of all nodes in the P2P network. For future control and management extension, it has to discover the changes of the P2P network, either from the removal or failure of nodes or from the changes of IPvY addresses. Fortunately, these are already contained within the information spread inside the P2P network. We put the Registration Server into the P2P network as a normal node, that these changes are easily noticed by the update scheme of the P2P network. The flooding scheme is used to broadcast the TEP information inside the P2P network. When a node receives an update packet from one of its neighbors, it refreshes the related items in its local database, and then forwards the packet to all the other neighbors. Although flooding can be a waste of network resources, it��s a reliable scheme to spread TEP information to all nodes in the P2P network. 5.2. New Subscription In PXP, a Registration Server is set up to help the IPvX island gateways join the P2P network. When the Registration Server receives a subscription request from a newly arrived gateway, it randomly chooses 20 of all existing nodes and sends their IPv6 addresses to the new one. The new node then gets the TEP information of all the islands corresponding to the nodes specified by the received IPv6 addresses and forms a Tunnel Tables for data forwarding. The steps of a new subscription are described as follows: 1. Register. The newly arrived node registers at the Registration Server, and gets a list of IPvX addresses for 20 existing nodes. 2. Make overlay neighborhoods. The new node tries to make overlay neighborhoods with the nodes specified by the received IPv6 addresses. Bi, et al. Expires July 10, 2009 [Page 10] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 3. Exchange the TEP information. The new node gets the TEP information of all other islands from its neighbors. Meanwhile, it spreads its TEP information inside the P2P network. 4. Form a Tunnel Table. With the TEP information received, the new node sets up a Tunnel Table for data transmission. The robustness of the registration scheme is a key issue. The failure of the Registration Server may make it impossible for a new node to join the P2P network. PXP uses multiple A-records for the same domain name of Registration Server in DNS to prevent the falures. 5.3. Failure Detection It is common to hold the overlay neighborhoods of the P2P network by sending keep-alive messages periodically. When a node detects that it hasn��t received such keep-alive message from its neighbor for a certain time, it broadcasts the failure notice to the whole P2P network through its live neighbors. Furthermore, in order to increase the stability of the P2P network, we set the minimal degrees d for each node to be 5. When a node finds the count of its live neighbors is less than d, it randomly chooses some nodes from the TEP information stored locally and tries to make new overlay neighborhoods until the count of its live neighbors reaches d. Bi, et al. Expires July 10, 2009 [Page 11] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 6. Protocol Details of the P2P Network 6.1. Protocol Overview In PXP, the P2P overlay network is setup to propagate and update TEP information between IPvX island gateways, the protocols of this P2P network are used to: o Register/Reply: The newly arrived node needs to register at Registration Server (RS), and the RS randomly chooses IPvY addresses of some nodes inside the P2P network and sends them back to the new node as a reply. o Neighborhoods Setup and Maintaining: The new node needs to setup the neighborhoods with some nodes already exist in the P2P network and keep-alive with each other. o TEP information Propagate and Update: The neighbors also need to exchange the TEP information their known with each other, propagate and update the newer ones to the whole overlay network. 6.2. Protocols between Newly Arrived Node and RS As described above, the protocols between newly arrived node and the Registration Server is used to help the new node join the P2P network. There are two kinds of messages designed for this purpose: o Register Message: Used for the newly arrived node to send register information to the RS o Reply Message: Used for the RS to send the IPv4 addresses of some nodes inside the overlay network back to the new node A two-state machine is designed to show the running statement of the new arrived node: o Init: the initialized statement of a new node o Registered: the statement after registered successfully The transfer between different states is described as follows: o Send Register message to RS and set local state to Init o When waiting for Reply message: if receive Reply message from RS successfully, set local state to Registered; else if timeout, keep Init and send Register message again. Bi, et al. Expires July 10, 2009 [Page 12] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 /--------- | | | | | +---------+ +----------+ | | | | | \--->| Init |--------------->|Registered| | | | | +---------+ +----------+ Figure 3. State Machine for a New Node 6.3. Protocols between Overlay Neighbors The protocols between overlay neighbors are used to setup overlay neighborhoods and propagate TEP information between neighbors. There are four kinds of messages designed for these purpose. o Hello Message: Used to setup neighborhoods and keep-alive between overlay neighbors. Can be divided into two types: 1-Hello sent to the existing neighbors, and H-hello sent to the others o Request Message: Used to ask one neighbor to send the TEP information it owns back to the local one. o Update Message: Used to propagate TEP information to the other neighbors. o Acknowledgement Message: Used to acknowledge the Update messages. A four-state machine is designed to show the running statement of a neighbor: o None: invalidate state, the initialized state of a new neighbor; o OneWay: the state of a way with one direction, it indicates a 0-hello been sent and no reply received yet; o TwoWay: the state of a way with both two directions, it indicates the succeed to setup new neighborhood; o Full: this state indicates that the local TEP information has already sent to this neighbor. The transfer between different states is described as follows: Bi, et al. Expires July 10, 2009 [Page 13] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 +--------+ +--------+ | | -------------------> | | | None | <------------------- | OneWay | | | -----------------\ | | +--------+ | +--------+ | /\ | /\ /\ | | | | | | | | | | | | | | \---------\ | | | | | | | | | | | /--------------------------/ | | | | | | | | \/ | | | | \/ +--------- | | +--------+ | | | \-> | | | Full | \------------- | TwoWay | | |<---------------------| | +--------+ +--------+ Figure 4. State Machine for an Overlay Neighbor o When state of a neighbor is None: * if receives 0-Hello, set neighbor state to OneWay and send 1-Hello back to this neighbor * if receives 1-Hello, set neighbor state to TwoWay and send Request to this neighbor o When state of a neighbor is OneWay: * if receives 0-Hello, keep neighbor state OneWay and send 1-Hello back to this neighbor * if receives 1-Hello, set neighbor state to TwoWay and send Request to this neighbor o When state of a neighbor is TwoWay: * if receives 0-Hello, set neighbor state to OneWay and send 1-Hello back to this neighbor * if receives 1-Hello, keep neighbor state TwoWay and send Request to this neighbor * if receives Request, keep neighbor state TwoWay and send Update to this neighbor Bi, et al. Expires July 10, 2009 [Page 14] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 * if receives Update, keep neighbor state TwoWay and send Ack to this neighbor: + if some TEP information in the Update is older than local ones, send Update with the local ones back to this neighbor; + if some TEP information in the Update is newer than local ones, refresh local database with the newer ones, forward them to the other neighbors and set all the other neighbors with Full state to TwoWay. o When state of a neighbor is Full: * if receives 0-Hello, set neighbor state to OneWay and send 1-Hello back to this neighbor * if receives 1-Hello, keep neighbor state Full. * if receives Request, keep neighbor state Full and send Update to this neighbor * if receives Update, send Ack to this neighbor: + if some TEP information in the Update is older than local ones, set neighbor state to TwoWay and send Update with the local ones back to this neighbor; + if some TEP information in the Update is newer than local ones, refresh local database with the newer ones, forward them to the other neighbors and set all the other neighbors with Full state to TwoWay. * if receives Ack, keep neighbor state Full. Besides, when timeout for an keep-alive message (Hello), set neighbor state to None directly. 6.4. Protocol Formats Here we take IPv6 over IPv4 for example to show the detail format of protocols. 6.4.1. Message Header The message header of PXP protocols contains the following fields: Bi, et al. Expires July 10, 2009 [Page 15] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Packet length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: This 1-octet unsigned integer indicates the type of message: 0 for Hello, 1 for Update, 2 for Ack, 3 for Request, 4 for Register and 5 for Reply o Packet Length: This 2-octet unsigned integer indicates the length of this message including the header o Router ID: This 4-octet unsigned integer indicates the id of the sender, mostly is its IPv4 address 6.4.2. Hello Message The Hello message is used to setup overlay neighborhoods and keep- alive between the neighbors, besides the fields in message header, this kind of message contains the following ones: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0 | Packet length | Hello Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Hello Type: This 1-octet unsigned integer indicates the type of this Hello message, 0 for the one not already been local neighbors, 1for message between neighbors 6.4.3. Update Message The Update message is used to propagate and update TEP information inside the P2P overlay network. Besides the fields in message header, this kind of message also contains the following ones: Bi, et al. Expires July 10, 2009 [Page 16] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Packet length | Sync Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TEP Data(Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Sync Number: This 1-octet unsigned integer is used to synchronized between sender and receiver. o TEP Data: This is a variable length field that contains a list of the TEP information. Each TEP info record contains the following field: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix length | Enabled | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Sequence Number: This 4-octet unsigned integer indicates the sequence of this TEP information, and is used to show the difference between updates for each TEP. * IPv4 Address: This 4-octet unsigned integer indicates the IPv4 address of the TEP * IPv6 Prefix: This 16-octet unsigned integer indicates the IPv6 address prefix of this IPv6 island * Prefix Length: This 2-octet unsigned integer indicates the length of the above IPv6 prefix * Enable: This 1-octet unsigned integer indicates the state of this TEP, 1 for available and 0 for not. Bi, et al. Expires July 10, 2009 [Page 17] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 6.4.4. Ack Message The Ack message is used to acknowledge the received Update message. Besides the fields in the header, this kind of message also contains: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 | Packet length | Sync Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Sync Number: This 1-octet unsigned integer has the same effect with the one in Update message, and is used to indicates the acknowledgement of the specified Update o Destination ID: This 4-octet unsigned integer indicates the id of the receiver, mostly is its IPv4 address. 6.4.5. Request Message The Request message is used to ask the neighbor to send back the TEP information its own. The format of this kind of message is described as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3 | Packet length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.6. Register Message The Register message is used to register at the RS for a newly arrived node. The format of this kind of message is described as follows, and we can also introduce some authentication fields for some security reason in future. Bi, et al. Expires July 10, 2009 [Page 18] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Packet length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.7. Reply Message The Reply message is used for RS to send back some IPv4 addresses to the new node and help the new one to join the P2P overlay network. Besides the fields in the header, this kind of message also contains the IPv4 address list of some nodes that already inside the P2P network. The format of Reply message is shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=5 | Packet length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ... | Bi, et al. Expires July 10, 2009 [Page 19] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 7. Data Plane In data plane, with TEP information from the P2P overlay network, each EG of IPvX island need to setup the direct IPvX over IPvY tunnels with the other islands. The data plane of PXP can be divide into three parts: o RT Control: This part receives the TEP information from P2P System, forms the Tunnel Table, and inserts the forwarding information into the Routing Table of the EG in order to assign the direct tunnels with higher route precedence than other routes and to make the traffic to the destination islands all forwarded to the Virtual Interface. o Tunnel Table: This part holds the information of direct tunnels between IPvX islands, and point out the IPvY address of the destination gateway for the Virtual Interface when packet forwarding. o Virtual Interface: When the Virtual Interface receives a data packet to a destination IPvX island, it looks up the Tunnel Table to find out the IPvY address of the remote island gateway, encapsulates this packet with an IPvY header, and sends it back to the forwarding scheme of the local gateway. Bi, et al. Expires July 10, 2009 [Page 20] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 8. IANA Considerations This document makes no request of IANA. Bi, et al. Expires July 10, 2009 [Page 21] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 9. Security Considerations We will study on security enhancements of our algorithm in the future. Since the edge gateways of isolated islands are sometimes lightweight devices and cannot support the heavy overhead of an end- to-end security scheme like IPSec between each pair of TEPs, the SPM technology can be deployed to provide a lightweight security guarantee for data transmission. The security consideration about the P2P network will also be an important research topic. Bi, et al. Expires July 10, 2009 [Page 22] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. 10.2. Informative References [I-D.v6ops-security-overview] Davies, E., "IPv6 Transition/Co-existence Security Considerations", March 2006. Bi, et al. Expires July 10, 2009 [Page 23] Internet-Draft The PXP Algorithm for IPv6 Transition Jan 2009 Authors' Addresses Jun Bi Tsinghua University FIT 3-212 Beijing 100084 P.R.C Phone: +86-10-62795818-6270 Email: junbi@tsinghua.edu.cn You Wang Tsinghua University FIT 4-204 Beijing 100084 P.R.C Email: wangyou@netarchlab.tsinghua.edu.cn Xiaoxiang Leng Tsinghua University FIT 4-204 Beijing 100084 P.R.C Phone: +86-10-62795818-6932 Email: xleng@netarchlab.tsinghua.edu.cn Bi, et al. Expires July 10, 2009 [Page 24]