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]