Internet DRAFT - draft-ma-mobility-support-ipv4-ipv6
draft-ma-mobility-support-ipv4-ipv6
Network Working Group Zhegming Ma
Internet Draft Qingyu Tan
Intended status: Standards Track Zheng Xiang
Expires: December 2008 Zhongshan University
June 28, 2008
Mobility Support in IPv4/v6
draft-ma-mobility-support-ipv4-ipv6-00.txt
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 December 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies a protocol named Mobile IPv4/v6, which allows
mobile nodes to remain reachable while moving in IPv4/v6 mixed
networks. A translation gateway called Mobile IPv4/v6 Translation
Gateway (MIPv4/v6-TG) is introduced in this protocol. MIPv4/v6-TG is
based on NAT-PT gateway and equipped with a newly introduced
application level gateway called MIP-ALG. MIPv4/v6-TG is located
between IPv4 network and IPv6 network. On IPv4 network side,
Ma Expires December 28, 2008 [Page 1]
Internet-Draft Mobility Support in IPv4/v6 June 2008
MIPv4/v6-TG acts as a Mobile IPv4 entity and interacts with other
Mobile IPv4 entities under Mobile IPv4, while on IPv6 network side,
it acts as a Mobile IPv6 entity and interacts with other Mobile IPv6
entities under Mobile IPv6. In MIPv4/v6-TG, Mobile IPv4 entities and
Mobile IPv6 entities are translated with each other. In order to
maintain each of Mobile IP sessions that pass through MIPv4/v6-TG, a
data structure called Mobile IP Table is introduced.
Table of Contents
1. Introduction...................................................3
2. Comparison with Mobile IP for IPv4 and IPv6....................5
3. Terminology....................................................6
3.1. General Terms.............................................6
3.2. Mobile IPv4/v6 Terms......................................7
4. Overview of Mobile IPv4/v6.....................................8
5. Extended Messages and New Messages............................10
5.1. Extended Registration Request Message....................11
5.2. Agent Request Message....................................13
5.3. Agent Reply message......................................14
6. Requirements for Types of Nodes...............................16
6.1. All IPv4 Nodes...........................................16
6.2. All IPv6 Nodes...........................................16
6.3. Mobile Nodes moving in IPv4/v6 mixed networks............16
6.4. MIPv4/v6 Translation Gateway.............................17
7. Mobile Nodes Operation........................................18
7.1. Overview.................................................18
7.2. Conceptual Data Structures...............................18
7.3. The Acquisition of Related Addresses.....................19
7.3.1. Acquiring Addresses of HA and CN through DNS Query..19
7.3.2. Acquiring Home Address..............................19
7.4. Movement Detection.......................................20
7.5. Supporting New Messages..................................20
8. MIPv4/v6-TG Operation.........................................21
8.1. Conceptual Data Structures...............................21
8.2. Intercepting Mechanisms of MIPv4/v6-TG...................22
8.3. Creating MIP Table Entries...............................23
8.3.1. Creating Entries triggered by Agent Request messages25
8.3.2. Creating Entries triggered by BU messages...........27
8.3.3. Creating Entries triggered by Extended Registration
Request messages...........................................31
8.3.4. Creating Entries triggered by HoTI messages or CoTI
messages...................................................34
8.4. The Usage of MIP Table...................................36
8.4.1. The usage of Type 1 MIP Table Entry.................36
8.4.2. The usage of Type 2 MIP Table Entry.................37
Ma Expires December 28, 2008 [Page 2]
Internet-Draft Mobility Support in IPv4/v6 June 2008
8.4.3. The usage of Type 3 MIP Table Entry.................38
8.4.4. The usage of Type 4 MIP Table Entry.................38
8.4.5. The usage of Type 5 MIP Table Entry.................38
8.4.6. The usage of Type 6 MIP Table Entry.................39
8.5. The Update of MIP Table Entries..........................40
8.5.1. The Update of Type 1 MIP Table Entries..............40
8.5.2. The Update of Type 2 MIP Table Entries..............41
8.5.3. The Update of Type 3 MIP Table Entries..............42
8.5.4. The Update of Type 4 MIP Table Entries..............43
8.5.5. The Update of Type 5 MIP Table Entries..............44
8.5.6. The Update of Type 6 MIP Table Entries..............45
9. Protocol Constants............................................46
10. Security Considerations......................................46
10.1. Security policy for HA, MN and CN.......................46
10.2. Security Considerations for MIPv4/v6-TG.................46
11. IANA Considerations..........................................47
12. Normative References.........................................48
Authors' Addresses...............................................48
Intellectual Property Statement..................................49
Disclaimer of Validity...........................................49
1. Introduction
This document specifies a protocol named Mobile IPv4/v6, which allows
mobile nodes to remain reachable while moving in IPv4/v6 mixed
networks. Mobile IP studies how to support mobile communications on
the Internet. Specifically, Mobile IPv4 [1] studies how to support
mobile communications on IPv4 network; Mobile IPv6 [2] studies how to
support mobile communications on IPv6 network. Mobile IPv4/v6 studies
how to support mobile communications on IPv4/v6 mixed networks. IETF
has specified the latest versions of Mobile IPv4 and Mobile IPv6 in
RFC3344 and RFC3775. But no RFC on Mobile IPv4/v6 has been published.
This document provides a protocol on Mobile IPv4/v6.
Mobile IP (Mobile IPv4/Mobile IPv6/Mobile IPv4/v6) defines three
entities: mobile node (MN), home agent (HA) and correspondent node
(CN). Among these three entities, HA and CN are usually considered as
stationary nodes, while MN can move around from one link to another.
In IPv4/v6 mixed networks, some entities may be located in IPv4
network, while other entities may be located in IPv6 network. In this
circumstance, without additional mobility support, communications
between the entities located in the different networks may not be
available. Therefore, a new protocol on Mobile IPv4/v6 has to be
introduced.
Mobile IPv4/v6 studies how to maintain communications between MN and
CN when MN moves in IPv4/v6 networks. According to the combination of
Ma Expires December 28, 2008 [Page 3]
Internet-Draft Mobility Support in IPv4/v6 June 2008
IP versions of networks where HA and CN are located, Mobile IPv4/v6
problems can be divided into the following four base problems:
o HA and CN are located in IPv6 network, while MN moves between
IPv4/v6 networks.
o HA and CN are located in IPv4 network, while MN moves between
IPv4/v6 networks.
o HA is located in IPv6 network, CN is located in IPv4 network,
while MN moves between IPv4/v6 networks.
o HA is located in IPv4 network, CN is located in IPv6 network,
while MN moves between IPv4/v6 networks.
According to the movement of MN, each base problem can further be
divided into four sub-problems:
o MN moves within IPv6 network.
o MN moves within IPv4 network.
o MN moves from IPv6 network to IPv4 network.
o MN moves from IPv4 network to IPv6 network.
Mobile IPv4/v6 will provide detailed solutions to each of the above
16 sub-problems. In order to maintain mobile communications in
IPv4/v6 networks, a translation gateway called Mobile IPv4/v6
Translation Gateway (MIPv4/v6-TG) is introduced in this protocol.
MIPv4/v6-TG is based on NAT-PT [3][4] gateway and equipped with a
newly introduced application level gateway called MIP-ALG. MIPv4/v6-
TG is located between IPv4 network and IPv6 network, and functions as
follows.
o On IPv6 network side, MIPv4/v6-TG acts as one of the Mobile IPv6
entities (HAv6, MNv6 or CNv6) to interact with other MIPv6
entities inside the IPv6 network as specified in RFC3775.
o On IPv4 network side, MIPv4/v6-TG acts as one of the Mobile IPv4
entities (HAv4, MNv4 or CNv4) to interact with other MIPv4
entities inside the IPv4 network as specified in RFC3344.
o Inside MIPv4/v6-TG, the Mobile IP entities that MIPv4/v6-TG acts
as are transformed from one to another, namely, from a MIPv4
entity to a MIPv6 entity or vice versa.
Ma Expires December 28, 2008 [Page 4]
Internet-Draft Mobility Support in IPv4/v6 June 2008
o MIPv4/v6-TG maintains a conceptual data structure called the
Mobile IP Table (MIP Table). The function of MIP table is similar
to that of NAT table on NAT-PT. Each entry of MIP table maintains
a MIP session that passes through MIPv4/v6-TG. The contents
recorded in a MIP table entry are the IP versions of HA, MN and CN,
the bindings of home address and care-of address, entrances for
the entry, and so on. It is based on the entry contents that
MIPv4/v6-TG processes the messages and datagrams involved in the
corresponding MIP session.
2. Comparison with Mobile IP for IPv4 and IPv6
Compared with Mobile IPv4 and Mobile IPv6, Mobile IPv4/v6 has the
following major differences.
o Mobile IPv4/v6 is designed for IPv4/v6 mixed networks, while
Mobile IPv4 and Mobile IPv6 are designed for pure IPv4 network and
pure IPv6 network, respectively. This makes these three protocols
different from each other.
o IPv4/v6 mixed network is a transition network from IPv4 to IPv6.
Mobile IPv4/v6 is a transition protocol from Mobile IPv4 to Mobile
IPv6, and should be able to work compatibly with both Mobile IPv4
and Mobile IPv6 to ensure a smooth transition process. In Mobile
IPv4/v6, a translation gateway, called Mobile IPv4/v6 Translation
Gateway and made up of NAT-PT and Mobile IP-ALG, is introduced to
translate between Mobile IPv4 and Mobile IPv6.
o Among the three Mobile IP entities (HA, MN and CN), HA and CN are
usually considered as stationary nodes. In this protocol, if HA or
CN is located in IPv4 network or IPv6 network, it can operate
under Mobile IPv4 or Mobile IPv6, and needn't know whether MN is
moving in IPv4 network or IPv6 network. If MN only moves within
IPv4 network or IPv6 network, it can operate under Mobile IPv4 or
Mobile IPv6, and needn't care whether HA and CN are located in
IPv4 network or IPv6 network. If MN moves from IPv4 network to
IPv6 network or from IPv6 network to IPv4 network, it should
support extra functions introduced in Mobile IPv4/v6. Firstly, MN
must be able to detect whether it is in IPv4 network or IPv6
network, and shift to Mobile IPv4 or Mobile IPv6 accordingly.
Secondly, MN must keep in mind the domain names of HA and CN. When
HA or CN is located in the network of IP version different from
that of MN, the addresses acquired through DNS query are in fact
the addresses of NAT-PT. Finally, when MN moves from IPv6 network
to IPv4 network, it must support the following messages introduced
in Mobile IPv4/v6: the extended Registration Request message, the
Agent Request message and the Agent Reply message.
Ma Expires December 28, 2008 [Page 5]
Internet-Draft Mobility Support in IPv4/v6 June 2008
3. 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 BCP 14, RFC 2119 [5].
3.1. General Terms
IP: Internet Protocol
IPv4: Internet Protocol Version 4
IPv6: Internet Protocol Version 6
MIP: Mobile IP
MIPv4: Mobile IPv4
MIPv6: Mobile IPv6
Node: A device that implements IP (IPv4, IPv6 or both)
Router: A node that forwards IP packets not explicitly addressed to
itself.
Link: A communication facility or medium over which nodes can
communicate at the link layer, such as an Ethernet (simple or
bridged). A link is the layer immediately below IP.
Interface: A node's attachment to a link.
Packet: An IP header plus payload.
Message: A kind of packet specially used in the registration process.
MIPv4/v6 messages: The three messages newly introduced in this
protocol. They are the extended Registration Request message, the
Agent Request message and the Agent Reply message.
Datagram: A kind of packet that carries data in the payload, used in
the communication process.
"#": A symbol that is attached after an IPv4 address to indicate that
this is an IPv4 address from the NAT-PT address pool, which is used
by the NAT-PT to map an IPv6 address.
Ma Expires December 28, 2008 [Page 6]
Internet-Draft Mobility Support in IPv4/v6 June 2008
"*": A symbol that is attached after an IPv6 address to indicate that
this is an IPv6 address formed by adding a 96-bit NAT-PT prefix to an
IPv4 address.
"<-->": A symbol connecting two IP addresses, used in a binding or an
address mapping.
3.2. Mobile IPv4/v6 Terms
Home address (HoA): A unicast routable address assigned to a mobile
node. This address is within the mobile node's home link. A mobile
node with an IPv4 home agent is assigned an IPv4 home address, while
a mobile node with an IPv6 home agent is assigned an IPv6 home
address.
Home subnet prefix: The IP subnet prefix corresponding to a mobile
node's home address.
Home link: The link on which a mobile node's home subnet prefix is
defined.
Mobile node (MN): A node that can change its point of attachment from
one link to another within IPv4 network, IPv6 network, or between
IPv4/v6 mixed networks, while still being reachable via its home
address.
Movement: A change in a mobile node's point of attachment to the
Internet such that it is no longer connected to the same link as it
was previously. If a mobile node is not currently attached to its
home link, the mobile node is said to be "away from home".
Correspondent node (CN): A peer node with which a mobile node is
communicating. The correspondent node may be attached to IPv4 network
or IPv6 network, and it may be either mobile or stationary.
Foreign subnet prefix: Any IP subnet prefix other than the mobile
node's home subnet prefix.
Foreign link: Any link other than the mobile node's home link.
Care-of address (CoA): A unicast routable address associated with a
mobile node while visiting a foreign link; the subnet prefix of this
IP address is a foreign subnet prefix.
Home agent: A router on a mobile node's home link with which the
mobile node has registered its current care-of address. In this
protocol, communication between mobile nodes and correspondent nodes
Ma Expires December 28, 2008 [Page 7]
Internet-Draft Mobility Support in IPv4/v6 June 2008
use "route optimization" mode. Therefore, packets do not have to pass
through the home link. This reduce burden of the home link and home
agent.
HAA: Home Agent Address
CNA: Correspondent Node Address
Binding: The association of the home address of a mobile node with a
care-of address for that mobile node, along with the remaining
lifetime of that association.
Registration: The process during which a mobile node informs its home
agent or correspondent node of the new care-of address.
MIP Table: A data structure maintained by MIPv4/v6-TG that is used to
record some useful information for all the mobile IP communication.
Each entry of the table corresponds to a communication process. There
are in sum six different kinds of MIP entries. More information about
MIP table is available in chapter 8.
4. Overview of Mobile IPv4/v6
Mobile IPv4/v6 is a protocol that supports mobile communications on
IPv4/v6 mixed networks. There are mainly three mechanisms for the
transition of IPv4 to IPv6: dual stacks, tunneling and NAT-PT. This
protocol is based on NAT-PT. NAT-PT gateway is a network layer device
that is located between the IPv4 network and IPv6 network, making the
two networks transparent and independent to each other.
Due to the differences between IPv4 and IPv6, the ways for them to
support the same application, such as mobile communication, are also
different. Therefore, an ALG (Application Level Gateway) is often
added on the NAT-PT gateway to support an application on the IPv4/v6
mixed network. FTP-ALG and DNS-ALG are two famous examples. Motivated
by the idea of ALG, Mobile IPv4/v6 specified in this document adds a
MIP-ALG on NAT-PT gateway to support mobile communication on IPv4/v6
mixed network.
Mobile IPv4/v6 uses a traditional NAT-PT and a MIP-ALG added on the
NAT-PT to form a new device named MIPv4/v6-TG. On IPv6 network side,
MIPv4/v6-TG acts as one of the Mobile IPv6 entities (HAv6, MNv6 or
CNv6) to combine with other MIPv6 entities inside the IPv6 network to
form a complete MIPv6 model described in RFC3775. In this way, inside
the IPv6 network, the registration process and communication process
can be performed as specified in RFC3775. Similarly, on IPv4 network
side, MIPv4/v6-TG acts as one of the Mobile IPv4 entities (HAv4, MNv4
Ma Expires December 28, 2008 [Page 8]
Internet-Draft Mobility Support in IPv4/v6 June 2008
or CNv4) to combine with other MIPv4 entities inside the IPv4 network
to form a complete MIPv4 model described in RFC3344. In this way,
inside the IPv4 network, the registration process and communication
process can be performed as specified in RFC3344.
Among the MIP entities, HA and CN are regarded as stationary nodes,
(although CN may also change its location), while MN can move within
the network with the same IP version or across the networks with
different IP versions. The role that MIPv4/v6-TG acts varies with the
location of HA, MN and CN.
(1) HA and CN are located in IPv4 network, while MN moves within IPv4
network. In this scenario, on the IPv6 network side, MIPv4/v6-TG acts
as MNv6 and communicates with CNv6 according to RFC3775. On the IPv4
network side, MIPv4/v6-TG acts as CNv4 to receive packets and as HAv4
to send packets through a tunnel according to RFC3344.
(2) HA and CN are located in IPv4 network, while MN moves within IPv6
network. In this scenario, on IPv4 network side, MIPv4/v6-TG acts as
MNv4 and communicate with HAv4 and CNv4 according to RFC3344. On IPv6
network side, MIPv4/v6-TG acts as CNv6 and communicates with MNv6
according to RFC3775.
(3) HA is located in IPv6 network, CN is located in IPv4 network:
o MN moves in IPv6 network. In this scenario, on IPv6 network side,
MIPv4/v6-TG acts as CNv6 and communicates with MNv6 according to
RFC3775. On IPv4 network side, MIPv4/v6-TG acts as HAv4 to receive
packets from CNv4 and as MNv4 to send packets to CNv4 according to
RFC3344.
o MN moves in IPv4 network. In this scenario, on IPv4 network side,
MIPv4/v6-TG acts as HAv4 and communicates with CNv4 and MNv4
according to RFC3344.
(4)HA is located in IPv4 network, CN is located in IPv6 network.
o MN moves in IPv4 network. In this scenario, on IPv4 network side,
MIPv4/v6-TG acts as CNv4 and communicates with HAv4 and MNv4
according to RFC3344. On IPv6 network side, MIPv4/v6-TG acts as
MNv6 and communicates with CNv6 according to RFC3775.
o MN moves in IPv6 network. In this scenario, MNv6 and CNv6 can
communicate directly with each other. In order to make HAv4 keep
aware the location of MN, MIPv4/v6-TG must maintain the binding of
HoA and CoA.
Ma Expires December 28, 2008 [Page 9]
Internet-Draft Mobility Support in IPv4/v6 June 2008
In order for MIPv4/v6-TG to maintain every communication process that
goes through MIPv4/v6-TG, this protocol introduces a data structure
called MIP table. The features and functions of MIP table are as
follows:
(1) MIP table is maintained by MIP-ALG and is used together with NAT
table, which is maintained by NAT-PT.
(2) There are totally six types of table entries in the MIP table,
each of which corresponds with a combination of locations of HA, MN
and CN.
(3) Each entry of the MIP table maintains a communication process
that goes through MIPv4/v6-TG. MIP-ALG handles MIP-related messages
and datagrams based on the information recorded in the entry.
(4) Each entry has four entrances through which the entry can be
accessed. They are the IPv6 message entrance, the IPv6 datagram
entrance, the IPv4 message entrance and the IPv4 datagram entrance.
The IPv6 message entrance is set to IPv6 home address, the IPv6
datagram entrance is set to the destination address of the coming
datagrams, and the IPv4 message entrance and datagram entrance are
set to the destination addresses of the coming messages and datagrams,
respectively.
(5) When MIPv4/v6-TG intercepts a packet, it first judges whether it
is a MIP message. If it is a MIP message, MIPv4/v6-TG will further
judge whether it is an extended Registration Request message or an
agent request message introduced in the protocol. If it is, a new
entry is created. If not, MIPv4/v6-TG will lookup the IPv4 or IPv6
message entrances. If no entry matches the message, a new entry is
created.
(6) If MIPv4/v6-TG judges that the packet is not a message, it will
lookup the IPv4 or IPv6 datagram entrances, using the destination
address of the packet. If no entry matches the packet, MIPv4/v6-TG
will judge that the packet has nothing to do with Mobile IP and will
not deliver it to MIP-ALG for further disposal.
5. Extended Messages and New Messages
In this protocol, MIPv4 and MIPv6 are reused respectively in IPv4
network and IPv6 network. On IPv6 network side, all MIPv6 messages
are reused without any change. On IPv4 network side, MIPv4 messages
are reused without any change, except for two circumstances. When HA
is located in IPv6 network while MN moves from IPv6 network into IPv4
network, Registration Request message is extended. When HA is located
Ma Expires December 28, 2008 [Page 10]
Internet-Draft Mobility Support in IPv4/v6 June 2008
in IPv4 network, CN is located in IPv6 network, while MN moves from
IPv6 network into IPv4 network, two new messages called Agent
Request/Reply message are introduced.
5.1. Extended Registration Request Message
The Extended Registration Request message is used in two scenarios.
One is HA and CN are located in IPv6 network, while MN moves from
IPv6 network to IPv4 network and performs the first registration
process. The other is HA is located in IPv6 network, CN is located in
IPv4 network, while MN moves from IPv6 network to IPv4 network and
performs the first registration process. In both scenarios, the
registration needs some additional information that the original
Registration Request message does not supply. This additional
information should be carried in the extended Registration Request
message. Note that the extended message is used only in the first
registration process. After that, the original message is used.
IP fields:
Source Address is the interface address from which the message is
sent. Typically, it is the new Care-of Address (CoAv4) that MN wants
to register with HA. CoAv4 will be changed to CoAv6* by adding a 96-
bit NAT-PT prefix to CoAv4 when the message passes MIPv4/v6-TG.
Destination Address is the IP address of the HA (HAAv4#). HAAv4# is
acquired through DNS query. It is in fact an IPv4 address from the
NAT-PT address pool. Messages or datagrams with such kind of address
as the destination address will be routed to the NAT-PT gateway. When
passing through MIPv4/v6-TG, HAAv4# will be changed to HAAv6 by
searching the NAT table.
UDP fields:
Source Port: variable
Destination Port: 434
The UDP header is followed by the Mobile IP fields shown below:
Ma Expires December 28, 2008 [Page 11]
Internet-Draft Mobility Support in IPv4/v6 June 2008
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 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent: HAAv4# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address: CoAv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension: CNAv4(#) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension: HoAv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Extensions ...
+-+-+-+-+-+-+-+-+-+-+-
Type: 4.
S, B, D, M, G, r, T, x, and Lifetime: the meanings of these fields
are the same with those of the original Registration Request message.
Home Address: By the time when MN sends this message, it only knows
its IPv6 home address and has no idea about the IPv4 home address.
Hence, this field is set to 0.
Home Agent Address: the IPv4 Home Agent Address HAAv4#. It is the
same with the destination address of the message.
Care-of Address: the IPv4 care-of address CoAv4#. It is the same with
the source address of the message.
Identification: A 64-bit number, constructed by MN, used for matching
Registration Requests with Registration Replies, and for protecting
against replay attacks of registration messages, as defined in MIPv4.
Extensions: CNAv4/CNAv4# and HoAv6.
CNAv4/CNAv4# is the IPv4 address of CN. It is acquired through DNS
query. MIPv4/v6-TG can use this address to decide whether CN is in
IPv4 network or IPv6 network. If the address is from the NAT-PT
Ma Expires December 28, 2008 [Page 12]
Internet-Draft Mobility Support in IPv4/v6 June 2008
address pool, it means that CN is in IPv6 network. Otherwise, CN is
in IPv4 network.
HoAv6 is the IPv6 home address of MN. Here it is used as an
identification of MN. After the extended Registration Request message
is translated into a BU message, HoAv6 is carried in the BU message
so that HAv6 knows which MN is sending the message.
Other Extensions: The fixed portion of the extended Registration
Request is followed by one or more of the extensions, as defined in
MIPv4.
5.2. Agent Request Message
The Agent Request message is used in the scenario where HA is located
in IPv4 network, CN is located in IPv6 network, while MN moves from
IPv6 network to IPv4 network and performs the first registration
process. When MN is still in IPv6 network and communicating with CN,
CN keeps the cached binding of HoAv6 and CoAv6. After MN moves from
IPv6 network to IPv4 network, in addition to Registration Request
message sent to HAv4, MN has to send an Agent Request message to
MIPv4/v6-TG, requesting MIPv4/v6-TG to update the binding cache on CN
so that CN can send the packets to the right place. The format of
Agent Request message is the same with that of the Registration
Request message except for a different Type value.
IP fields:
Source Address: CoAv4, the new care-of address MN has just acquired
in IPv4 network.
Destination Address: CNAv4#. This address is acquired through DNS
query. It is in fact an IPv4 address from the NAT-PT address pool.
Messages or datagrams with such kind of address as the destination
address will be routed to the NAT-PT gateway.
UDP fields:
Source Port: variable
Destination Port: 434
The UDP header is followed by the Mobile IP fields shown below:
Ma Expires December 28, 2008 [Page 13]
Internet-Draft Mobility Support in IPv4/v6 June 2008
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 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address: HoAv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent: HAAv4# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address: CoAv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Extensions...
+-+-+-+-+-+-+-+-+-+-+-
Type: 5.
S, B, D, M, G, r, T, x, Lifetime and Identification: the meanings of
these fields are the same with those of the original Registration
Request message.
Home Address: HoAv4.
Home Agent Address: HAAv4.
Care-of Address: the new IPv4 care-of address that MN wants to
register with CN. In MIPv4/v6-TG, this address will be changed to
IPv6 form by adding a 96-bit NAT-PT prefix.
5.3. Agent Reply message
Agent Reply message is a message sent by MIPv4/v6-TG as a reply to
the Agent Request message. It informs MN of the result of the update
procedure with CN. The format of Agent Reply message is the same with
that of Registration Reply message, as shown below.
Ma Expires December 28, 2008 [Page 14]
Internet-Draft Mobility Support in IPv4/v6 June 2008
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address: HoAv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent: HAAv4# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-
IP fields:
Source Address: CNAv4#. This address can be copied directly from the
destination address field of the Agent Request message.
Destination Address: CoAv4. This address can be copied directly from
the source address field of the Agent Request message.
UDP fields:
Source Port: 434, copied from the destination port of the Agent
Request message.
Destination Port: variable, copied from the source port of the Agent
Request message.
Type: 6.
Code: indicates the result of the update procedure. So far only two
possible results are defined:
0: unfinished. This means that the procedure is not completed. MN
should try again later or try other means.
1: finished. This means that the procedure is completed. And the
Lifetime field indicates the lifetime of the new binding.
Lifetime: The number of seconds remaining before the binding is
considered expired. A value of zero indicates a request for
deregistration. A value of 0xffff indicates infinity.
Ma Expires December 28, 2008 [Page 15]
Internet-Draft Mobility Support in IPv4/v6 June 2008
Home Address: HoAv4, copied from the Agent Request message.
Home Agent Address: HAAv4, copied from the Agent Request message.
Identification: it is the same with that of the Registration Reply
message.
6. Requirements for Types of Nodes
6.1. All IPv4 Nodes
Any IPv4 node may be a correspondent node of a mobile node, no matter
whether the mobile node is in IPv4 network or IPv6 network. When an
IPv4 node acts as a correspondent node, it only needs to meet the
requirements described in MIPv4. The protocol presented in this
document places no additional requirements on such kind of nodes.
This protocol also places no additional requirements on nodes that
act as home agents. But when an IPv4 node acts as a mobile node, it
needs extending with some new features. This will be discussed later
in chapter 7.
6.2. All IPv6 Nodes
In MIPv6, communication between a mobile node and a correspondent
node may use two possible modes: bidirectional tunneling and route
optimization. This protocol suggests that in IPv6 network, route
optimization be chosen. Here, "in IPv6 network" refers not only to
the scenario where both MN and CN are located in IPv6 network, but
also to the scenarios where only MN or CN is located in IPv6 network.
Therefore, for any IPv6 node that acts as a correspondent node, it
must support route optimization. This implies that when MN changes
its location and gets a new care-of address, it must update the
binding cache on the correspondent node by some means. Specifically,
if MN is also in IPv6 network, MN will itself perform correspondent
registration. If MN is in IPv4 network, MIPv4/v6-TG will do the job
on behalf of MN.
When an IPv6 node acts as home agent, it only needs to meet the
requirements described in MIPv6. This protocol places no additional
requirements on such kind of nodes.
6.3. Mobile Nodes moving in IPv4/v6 mixed networks
Mobile nodes moving in IPv4/v6 mixed networks must meet the following
requirements.
Ma Expires December 28, 2008 [Page 16]
Internet-Draft Mobility Support in IPv4/v6 June 2008
(1) Mobile nodes should support both MIPv4 and MIPv6. They must be
able to detect whether they are in IPv4 network or IPv6 network and
work under MIPv4 or MIPv6 accordingly.
(2) Mobile nodes must support DNS. They should know the domain names
of the home agents and the correspondent nodes. When HA or CN is
located in a network whose version is different from that of MN, it
is through DNS query that MN discovers a suitable MIPv4/v6-TG located
between MN and HA or CN. MIPv4/v6-TG will return an IPv4 address from
NAT-PT address pool, or an IPv6 address with 96-bit NAT-PT prefix. MN
uses the returned address to communicate with HA or CN. MN may
periodically perform DNS query to discover a more suitable MIPv4/v6-
TG.
(3) Mobile nodes must support the MIPv4/v6 messages introduced in
this protocol, including:
o Mobile Nodes must support the extended Registration Request
message. The extended Registration Request message carries some
information about MIPv4/v6, and is used in some special
circumstances. More detail is available in section 5.1. Mobile
nodes should know when and how to use this message.
o Mobile Nodes must support the Agent Request message. Agent Request
message is one that has a similar format with the Registration
Request message. Mobile Nodes use this message to request
MIPv4/v6-TG to inform CN of new care-of addresses. More detail is
available in section 5.2. Mobile nodes should know when and how to
use this message.
o Mobile Nodes must support the Agent Reply message. Agent Reply
message is a reply sent by MIPv4/v6-TG to inform the MN of the
update result. More detail is available in section 5.3. Mobile
nodes should know when and how to use this message.
6.4. MIPv4/v6 Translation Gateway
MIPv4/v6-TG is made up of NAT-PT and MIP-ALG. MIPv4/v6-TG plays a
crucial role in MIPv4/v6. It must meet the following requirements.
(1) MIPv4/v6-TG must support all the functionalities of MIPv4 and
MIPv6 entities. That is to say, MIPv4/v6-TG will act as a MIPv4
entity on IPv4 network side and as a MIPv6 entity on IPv6 network.
(2) MIPv4/v6-TG should have an efficient mechanism to intercept MIP-
related messages and datagrams and process them correctly.
Ma Expires December 28, 2008 [Page 17]
Internet-Draft Mobility Support in IPv4/v6 June 2008
(3) NAT-PT is a fundamental function of MIPv4/v6-TG, and is
responsible for address translation and protocol translation between
IPv4 and IPv6. In this protocol, NAT-PT must be equipped with DNS-ALG.
(4) MIP-ALG maintains a MIP table, a conceptual data structure newly
introduced in this protocol. Each entry of MIP table records
necessary information for each MIP session that passes through
MIPv4/v6-TG. It is based on the information contained in the MIP
table that MIP-ALG knows how to process MIP messages and datagrams.
7. Mobile Nodes Operation
7.1. Overview
MN moving in IPv4/v6 mixed network must support both MIPv4 and MIPv6.
When MN moves within IPv4 network, its operations comply with MIPv4.
When MN moves within IPv6 network, its operations comply with MIPv6.
Besides, MN must possess the following abilities.
o When MN moves from IPv4 network to IPv6 network or from IPv6
network to IPv4 network, it must be able to detect the change of
IP versions of the network.
o If the IP version of the network in which HA or CN is located is
different from that of MN, MN must keep in mind the domain names
of HA or CN, and look for an available MIPv4/v6-TG by DNS query.
MN communicates with HA or CN through the MIPv4/v6-TG.
o When MN moves from IPv6 network to IPv4 network, MN must be able
to support the extended Registration Request message, Agent
Request message and Agent Reply message newly introduced in this
protocol.
This chapter will describe the newly introduced abilities of MN in
details. Those abilities of MN described in MIPv4 and MIPv6 will be
not repeated.
7.2. Conceptual Data Structures
In this protocol, when MN moves from IPv4 network to IPv6 network or
from IPv6 network to IPv4 network, it should support the extended
Registration Request message, Agent Request message and Registration
Reply message. Besides the conceptual data structures mentioned in
MIPv4 and MIPv6, new conceptual data structures must be introduced
for MN to keep in mind the necessary state information of these three
messages.
Ma Expires December 28, 2008 [Page 18]
Internet-Draft Mobility Support in IPv4/v6 June 2008
7.3. The Acquisition of Related Addresses
If the IP version of network in which HA or CN is located is
different from that of MN, MN must find a MIPv4/v6-TG through which
MN can communicate with HA or CN. MIPv4/v6-TG will give MN an IP
address. Packets with this IP address as destination address will be
routed to MIPv4/v6-TG, and translated and delivered to HA or CN. In
addition, if MN and HA are located in the networks of different IP
versions, the home address will be not routable in the network in
which MN is located. In this circumstance, MN must acquire an IP
address from MIPv4/v6-TG to substitute for the home address.
7.3.1. Acquiring Addresses of HA and CN through DNS Query
In this protocol, MN is required to know the domain names of HA and
CN. DNS query is not only used to get the IP address of HA or CN, but,
more importantly, used to find an available MIPv4/v6-TG when MN and
HA or CN are located in the networks of different IP versions.
When HA is located in IPv6 network and MN is located in IPv4 network,
MN can acquire the home agent address of IPv4 version through DNS
query. According to RFC2766, NAT-PT will take out an IPv4 address
HAAv4# from its address pool and create a mapping of HAAv6<-->HAAv4#
in its NAT table. When CN is located in IPv6 network and MN is
located in IPv4 network, CNAv4# can be acquired in the same way.
When HA is located in IPv4 network and MN is located in IPv6 network,
MN can acquire the home agent address of IPv6 version through DNS
query. According to RFC2766, NAT-PT will add a 96-bit NAT-PT prefix
to HAAv4 to form HAAv6*. When CN is located in IPv4 network and MN is
located in IPv6 network, CNAv6* can be acquired in the same way.
7.3.2. Acquiring Home Address
The IP version of MN home address is the same with that of home link.
When MN moves to a network whose IP version is different from that of
home link, its home address is not usable. Under this circumstance,
MN must find a way to acquire an IP address used as its home address
in the network.
If HA is located in IPv4 network and MN moves from IPv4 network to
IPv6 network, MN home address HoAv4 is not usable in the IPv6 network.
Under this circumstance, MN will add a 96-bit NAT-PT prefix to HoAv4
to form an IPv6 home address HoAv6*. The 96-bit NAT-PT prefix is
taken from HAAv6*, which can be acquired by DNS query as described in
7.3.1.
Ma Expires December 28, 2008 [Page 19]
Internet-Draft Mobility Support in IPv4/v6 June 2008
If HA is located in IPv6 network and MN moves from IPv6 network to
IPv4 network, MN home address HoAv6 is not usable in the IPv4 network.
Under this circumstance, MN will send to MIPv4/v6-TG an extended
Registration Request message, rather than a conventional Registration
Request message. In the extended Registration Request message, the
home address field is set to 0, and the extended home address field
is set to HoAv6. MIPv4/v6-TG will take an IPv4 address from NAT-PT
address pool as MN home address HoAv4#. HoAv4# will be sent to MN in
a Registration Reply message.
7.4. Movement Detection
MN can judge whether it has moved to a new link by comparing the
subnet prefix in the Router Advertisements with the prefix of its
current care-of address. As a dual stack node, MN can judge whether
it is located in IPv4 network or IPv6 network by Router
Advertisements.
MN records the Lifetime taken from Agent Advertisements. When the
Lifetime nearly expires, MN will send an Agent Solicitation message.
If MN is not sure whether it is located in IPv4 network or IPv6
network, it can send both IPv4 and IPv6 Agent Solicitation messages.
If MN receives an IPv6 reply, it knows that it is now in IPv6 network.
If MN receives an IPv4 reply, it knows that it is now in IPv4 network.
7.5. Supporting New Messages
In addition to MIPv4 and MIPv6 messages described in MIPv4 and MIPv6,
this protocol introduces three new messages for MIPv4/v6.
If HA is located in IPv6 network and MN moves from IPv6 network to
IPv4 network, MN acquires HAAv4# and CNAv4/CNAv4# by DNS query. MN
generates an extended Registration Request message, in which the
destination address is set to HAAv4#, the home address field is set
to 0, the extended home address field is set to HoAv6, and the
extended correspondent node address is set to CNAv4/CNAv4#.
If HA is located in IPv4 network, CN is located in IPv6 network, and
MN moves from IPv6 network to IPv4 network, MN acquires CNAv4# by DNS
query. MN generates an Agent Request message, in which the
destination address is set to CNAv4#, the home address field is set
to HoAv4, the home agent address field is set to HAAv4, and the care-
of address field is set to CoAv4. On receiving this Agent Request
message, MIPv4/v6-TG will update the binding cache on CNv6 on behalf
of MNv4, and return to MNv4 an Agent Reply message.
Ma Expires December 28, 2008 [Page 20]
Internet-Draft Mobility Support in IPv4/v6 June 2008
8. MIPv4/v6-TG Operation
8.1. Conceptual Data Structures
MIP table is a conceptual data structure newly introduced in this
protocol. MIP table records the information for each MIP session that
passes through MIPv4/v6-TG, such as the IP versions of HA, MN and CN,
the bindings of home address and care-of address, entrances for MIP
table entries, and so on. The function of MIP table is similar to
that of NAT table on NAT-PT. When a MIP packet passes through
MIPv4/v6-TG, MIPv4/v6-TG will lookup the MIP table for a
corresponding entry and use the information recorded in the entry to
process the packet. The creation of MIP table entry is triggered by
some special MIP messages. On IPv4 network side, only Extended
Registration Request messages and Agent Request messages can make
MIPv4/v6-TG create new MIP table entries. On IPv6 network side, those
MIP messages for which no matching entries can be found will make
MIPv4/v6-TG create new MIP table entries. Each entry should contain
the following fields.
o The IP versions of HA, MN and CN. The role that MIPv4/v6-TG plays
is determined by the combination of IP versions of the three MIP
entities. When a MIP datagram is intercepted, MIPv4/v6-TG lookups
the MIP table for the corresponding entry, and in this way, learns
the IP versions of three MIP entities. Then MIPv4/v6-TG knows how
to process the datagram.
o Bindings of home address and care-of address. The bindings of home
address and care-of address make possible the transparent routing
of packets in MIP communications. The bindings in a particular
table entry may be of IPv4 form or IPv6 form. Some of the entries
may have IPv4 bindings and IPv6 bindings at the same time. This
depends on the combination of IP versions of HA, MN and CN.
o Entry entrances. Entry entrances are fields that are particularly
set for entry lookup. Packets that MIPv4/v6-TG intercepts may come
from IPv4 network or IPv6 network. Therefore, MIP table should
support bi-directional lookup. Moreover, the intercepted MIP
packets may be messages or datagrams. Therefore, MIP table should
further support message and datagram lookup, respectively. In this
protocol, four entrances are defined: the IPv6 message entrance,
the IPv6 datagram entrance, the IPv4 message entrance and the IPv4
datagram entrance. The IPv6 message entrance is set to IPv6 home
address, the IPv6 datagram entrance is set to the destination
address of the coming datagrams, and the IPv4 message entrance and
datagram entrance are set to the destination addresses of the
coming messages and datagrams, respectively.
Ma Expires December 28, 2008 [Page 21]
Internet-Draft Mobility Support in IPv4/v6 June 2008
o Lifetime of the entry. Lifetime is a positive number indicating
how many seconds before the entry is considered expired. This
number is set to the minimal one of the lifetimes of the existing
bindings. Lifetime can be updated through registration processes.
Since MN also knows the value of lifetime, when the lifetime is
nearly expired, MN may perform a registration process in order to
update the lifetime. If the lifetime becomes zero, MIPv4/v6-TG
will delete this entry.
o State of the entry. There are two possible states for each entry:
finished and unfinished. An unfinished state indicates that the
entry is now being created or updated. Entries with an unfinished
state can not be used by the MIPv4/v6-TG as a guide to process the
packets.
8.2. Intercepting Mechanisms of MIPv4/v6-TG
MIPv4/v6-TG is made up of a NAT-PT and a MIP-ALG. Not all coming
packets are MIP-related. Therefore, MIPv4/v6-TG should develop a
effective mechanism to intercept MIP-related packets and deliver them
to MIP-ALG for further processing. In this protocol, MIPv4/v6-TG uses
the following rules to intercept MIP-related packets.
(1) MIPv4/v6-TG intercepts MIP-related messages based on message
types.
o On IPv4 network side, MIPv4/v6-TG needs to process four kinds of
MIP messages: Registration Request message, Registration Reply
message, extended Registration Request message, Agent Request
message and Agent Reply message. The first two messages are
specified in RFC3344 while the others are newly introduced in this
protocol. The registration request message, extended registration
request message, and agent request message are all sent through
UDP destination port 434. The registration reply message and agent
reply message are both sent through UDP source port 434. MIPv4/v6-
TG uses these features to distinguish them from other messages.
Furthermore, these five MIP-related messages have different type
values, and can be distinguished from one another by these type
values. The Type values of the Registration Request message and
Registration Reply message are 1 and 3, respectively. For extended
Registration Request message, Agent Request message and Agent
Reply message, 5, 6 and 7 are used, respectively.
Ma Expires December 28, 2008 [Page 22]
Internet-Draft Mobility Support in IPv4/v6 June 2008
o On IPv6 side, MIPv4/v6-TG needs to process six kinds of messages:
HoTI, CoTI, HoT, CoT, BU and BA. These messages contain a mobility
header identified by a Payload Proto number 135, and can be
distinguished by this feature from other messages. Furthermore,
MIP-ALG uses the MH type value in the mobility header to
distinguish from one another. For HoTI, CoTI, HoT, CoT, BU and BA,
the MH type values are 1, 2, 3, 4, 5 and 6, respectively.
(2) MIPv4/v6-TG intercepts MIP-related datagrams by checking their
destination addresses. When MIPv4/v6-TG receives a packet, it will
check if it is a MIP-related message, using the method described in
(1). If it is not a MIP-related message, MIPv4/v6-TG takes out its
destination address and compares it with the datagram entrance of the
existing entries. If the datagram entrance of any entry equals to the
destination address, it means that this is a MIP-related datagram.
MIPv4/v6-TG will then deliver it to MIP-ALG for further processing,
based on the information recorded in that entry.
8.3. Creating MIP Table Entries
In this protocol, there are four kinds of messages that can trigger
the creation of new MIP table entries. They are: the extended
Registration Request message, Agent Request message, BU, and HoTI or
CoTI. There are six kinds of entries in MIP table, each of which
corresponds with one possible combination of IP versions of HA, MN
and CN. Note that in the scenarios where HA, MN and CN are all
located in IPv4 network or IPv6 network, MIPv4/v6-TG needn't
participate in MIP registration and communication processes.
Therefore, no MIP table entry is needed to be created for such
scenarios.
An MIP table entry should, typically, have the following fields.
Type: A three-bit field indicating the IP versions of HA, MN and CN
respectively. For each bit, a value of 1 indicates the MIP entity is
located in IPv6 network, while a value of 0 indicates the MIP entity
is located in IPv4 network. Type value varies from 001 to 110. 000
and 111 indicate that HA, MN and CN are all located in IPv4 network
and IPv6 network, respectively, and do not need to be considered.
MIPv6 message entrance: A 128-bit field through which a particular
MIP table entry can be found and accessed when a MIPv6 message is
intercepted by MIPv4/v6-TG. Usually, this field is set to the IPv6
home address. All MIPv6 messages contain IPv6 home addresses. When a
MIPv6 message is intercepted by MIPv4/v6-TG, MIPv4/v6-TG takes out
the IPv6 home address from the intercepted message and uses it as an
index to search the MIP table. In this process, MIPv4/v6-TG compares
Ma Expires December 28, 2008 [Page 23]
Internet-Draft Mobility Support in IPv4/v6 June 2008
the IPv6 message entrance field of each entry with the IPv6 home
address. If an entry is found, MIPv4/v6-TG will use the information
recorded in the entry to process the intercepted message. If no entry
is found, MIPv4/v6-TG will create a new entry.
MIPv6 datagram entrance: A 128-bit field through which a particular
entry can be found and accessed when a MIPv6 datagram is intercepted
by MIPv4/v6-TG. If an intercepted packet is not a MIPv6 message,
MIPv4/v6-TG will take out its destination address and use the address
as an index to search the MIP table. In this process, MIPv4/v6-TG
compares the IPv6 datagram entrance filed of each entry with the
address. If an entry is found, the intercepted packet is a MIPv6
datagram, and will be processed based on the information recorded in
the entry. If no entry is found, the intercepted packet is not a
MIPv6 datagram.
MIPv4 message entrance: A 32-bit field through which a particular
entry can be found and accessed when a MIPv4 message is intercepted
by MIPv4/v6-TG. On intercepting a MIPv4 message, MIPv4/v6-TG takes
out its destination address and uses the address as an index to
search for the corresponding MIP table entry. It is based on the MIP
table entry that MIPv4/v6-TG processes the intercepted MIPv4 message.
MIPv4 datagram entrance: A 32-bit field through which a particular
entry can be found and accessed when a MIPv4 datagram is intercepted
by MIPv4/v6-TG. If an intercepted packet is not a MIPv4 message,
MIPv4/v6-TG will take out its destination address and use the address
as an index to search the MIP table. In this process, MIPv4/v6-TG
compares the IPv4 datagram entrance filed of each entry with the
address. If an entry is found, the intercepted packet is a MIPv4
datagram, and will be processed based on the information recorded in
the entry. If no entry is found, the intercepted packet is not a
MIPv4 datagram.
Cached bindings: Bindings of home address and care-of address that
are used by MIPv4/v6-TG when it acts as a particular MIP entity.
Bindings may be of IPv4 form or of IPv6 form. Entries may have no
binding, one binding, or two bindings. This depends on the types of
the entries.
Source port: A 16-bit field that records the source port value of
Registration Request message, extended Registration Request message,
or Agent Request message. All of these three messages are sent
through UDP ports. When MIPv4/v6-TG intercepts such kind of message,
it fills this field with the source port value. This field is used as
the destination port when MIPv4/v6-TG sends back a reply later.
Ma Expires December 28, 2008 [Page 24]
Internet-Draft Mobility Support in IPv4/v6 June 2008
Destination port: A 16-bit field that records the destination port
value of Registration Request message, extended Registration Request
message, or Agent Request message. It will be uses as the source port
when MIPv4/v6-TG sends back a reply later.
State: A 1-bit field indicating whether the entry is finished or not.
There are two possible states for each entry: 1 (finished) and 0
(unfinished). An unfinished state indicates that the entry is now
being created or updated. Entries with an unfinished state can not be
used by the MIPv4/v6-TG as a guide to process MIP datagrams.
Lifetime: A 16-bit field indicating entry lifetime. The meaning of
this field depends on the value of the State field. When the State is
0 (unfinished), Lifetime means the entry should be completed before
the time expires. When the State is 1 (finished), Lifetime means the
number of seconds left before the entry is considered expired. In
either case, when this filed becomes 0, MIPv4/v6-TG will delete the
entry.
8.3.1. Creating Entries triggered by Agent Request messages
Agent Request message is a new message introduced in this protocol.
Its format is available in section 5.2.
In this protocol, Agent Request message is used only when HA is
located in IPv4 network, CN is located in IPv6 network, and MN has
just moved from IPv6 network to IPv4 network. Since the IP version of
MN has changed from IPv6 to IPv4. The original entry becomes invalid
and a new entry should be created. MIPv4/v6-TG takes the following
steps to create a new entry.
(1) MIPv4/v6-TG intercepts an Agent Request message and delivers it
to MIP-ALG for further processing. Here, MIPv4/v6-TG uses the
intercepting mechanism described above to intercept and recognize the
Agent Request message.
(2) On receiving the Agent Request message, MIP-ALG can infer that HA
is located in IPv4 network, CN is located IPv6 network and MN has
just moved from IPv6 network to IPv4 network, as only in this
scenario can MIPv4/v6-TG receive an Agent Request message. Therefore,
a new entry with the Type value 001 (binary) is created.
MIP-ALG sets the field of MIPv6 Message Entrance to HoAv6*, MIPv6
Datagram Entrance to CoAv6*, MIPv4 Datagram Entrance to CNAv4#,
Cached Bindings to HoAv6*<-->CoAv6*, Source Port and Destination Port
to the source port number and destination port number of the Agent
Request message respectively. HoAv6*, CoAv6* and HAAv6* can be
Ma Expires December 28, 2008 [Page 25]
Internet-Draft Mobility Support in IPv4/v6 June 2008
acquired by adding a 96-bit NAT-PT prefix to HoAv4, CoAv4, HAAv4,
while CNAv6 can be acquired by checking the NAT table, using CNAv4#
as the index. HoAv4, CoAv4, HAAv4 and CNAv4# are carried in the Agent
Request message.
MIP-ALG sets the fields of HoTI/HoT, CoTI/CoT and State to 0, and
then sets the Lifetime to a value in which the creation of the entry
must be accomplished.
(3) MIP-ALG generates HoTI message and CoTI message. The source
address and destination address of HoTI message are HoAv6* and CNAv6,
respectively, while the source address and destination address of
CoTI message are CoAv6* and CNAv6, respectively. Both of these
messages will be routed to CNv6.
(4) MIPv4/v6-TG intercepts HoT message and CoT message replied from
CNv6, uses HoAv6* carried in these messages as an index to search MIP
table, and finds this entry.
(5) For HoT message, MIP-ALG sets the HoTI/HoT field of the entry to
1, while for CoT message, MIP-ALG sets the CoTI/CoT field of the
entry to 1. When both HoTI/HoT field and CoTI/CoT field become 1,
MIP-ALG will generate a BU message, with CoAv6* and CNAv6 as its
source address and destination address, respectively. This BU message
will be routed to CNv6.
(6) MIPv4/v6-TG intercepts BA message replied from CNv6. Then,
MIPv4/v6-TG uses HoAv6* carried in the message as an index to search
MIP table and finds this entry.
(7) MIP-ALG generates an Agent Reply message with CNAv4# and CoAv4 as
its source address and destination address, respectively. This
message is sent through UDP. The source port and destination port are
copied from the fields of Destination Port and Source Port,
respectively. This Agent Reply message will be routed to MNv4.
(8) MIP-ALG sets the State of the entry to 1 (finished), and sets the
Lifetime of the entry to the lifetime of the binding cache.
When the creation of a Type 1 entry finishes, the value of each field
is as follows.
Type: 001. HA and MN are located in IPv4 network, CN is located in
IPv6 network. On intercepting an Agent Request message, MIPv4/v6-TG
knows the IP versions of HA, MN and CN.
Ma Expires December 28, 2008 [Page 26]
Internet-Draft Mobility Support in IPv4/v6 June 2008
MIPv6 Message Entrance: HoAv6*. HoAv6* is acquired by adding a 96-bit
NAT-PT prefix to HoAv4, which is carried in the Agent Request message.
MIPv6 Datagram Entrance: CoAv6*. CoAv6* is acquired by adding a 96-
bit NAT-PT prefix to CoAv4, which is carried in the Agent Request
message.
MIPv4 Message Entrance: blank. Except for Agent Request message,
MIPv4/v6-TG will not receive any other MIPv4 messages.
MIPv4 Datagram Entrance: CNAv4#. CNAv4# is acquired from the
destination address field of the Agent Request message.
Cache Bindings: HoAv6*<-->CoAv6*. Both HoAv6* and CoAv6 can be
acquired from the Agent Request message.
HoTI/HoT: 1. HoTI/HoT has arrived.
CoT/CoTI: 1. CoTI/CoT has arrived.
Source Port: variable. The source port number of the Agent Request
message, which is variable.
Destination Port: 434. The destination port number of the Agent
request message is 434.
State: 1. Finished.
Lifetime: set to the lifetime of the entry.
8.3.2. Creating Entries triggered by BU messages
When MIPv4/v6-TG intercepts a BU message, it takes out HoAv6* from
the message and uses it as an index to search the MIP table. If no
matching entry is found, MIPv4/v6-TG will create a new entry, using
the information carried in the BU message. If a matching entry is
found, MIPv4/v6-TG will go further to see if the second bit of the
Type is equal to 1 (i.e., MN is in IPv6 network). If so, MIP-ALG will
just update the existing entry, without creating a new entry.
Otherwise, MIP-ALG will create a new entry and the following steps
will be performed.
(1) On receiving the BU message, MIP-ALG can infer that HA is located
in IPv4 network and MN is located in IPv6 network. However, MIP-ALG
does not know the IP version of CN and needs other means to learn
this information later.
Ma Expires December 28, 2008 [Page 27]
Internet-Draft Mobility Support in IPv4/v6 June 2008
MIP-ALG creates a new entry and sets the field of Cached Bindings to
HoAv6*<-->CoAv6, MIPv6 Message Entrance to HoAv6*, MIPv4 Message
Entrance to CoAv4#. CoAv4# is an IPv4 address taken from the NAT-PT
address pool and mapped with CoAv6. The fields of HoTI/HoT, CoTI/CoT
and State are all set to 0. Lifetime is set to a value in which the
creation of the entry must be accomplished.
(2) MIP-ALG translates the BU message into a Registration Request
message with CoAv4# and HAAv4 as its source address and destination
address, respectively. HoAv4 is carried in the new message. HAAv4 and
HoAv4 are acquired from HAAv6* and HoAv6*, respectively. This
Registration Request message will be routed to HAv4.
(3) MIPv4/v6-TG intercepts the Registration Reply message replied
from HAv4, takes out the destination address as an index to search
the MIP table and finds this entry.
(4) MIP-ALG translates the intercepted Registration Reply message
into a BA message with HAAv6* and CoAv6 as its source address and
destination address, respectively. HoAv6* is carried in the message.
HAAv6* and HoAv6* are acquired by adding a 96-bit NAT-PT prefix to
HAAv4 and HoAv4. CoAv6 is acquired by searching the NAT table, using
CoAv4# as the index. HAAv4, HoAv4, and CoAv6 can be all acquired from
the intercepted Registration Reply message. This BA message will be
routed to MNv6.
If CN is located in IPv4 network, the following steps will be
performed:
(1) MIPv4/v6-TG intercepts HoTI message or CoTI message, takes out
HoAv6* from the intercepted message as an index to search the MIP
table, and finds this entry. Note that HoTI arrives through tunneling.
(2) MIP-ALG can judge the IP version of CN by the destination address
of HoTI message or CoTI message. Then MIP-ALG sets the field of Type
to 010, HoTI/HoT or CoTI/CoT to 1, and then generates HoT message or
CoT message as a reply. Note that HoT is sent through tunneling.
(3) MIPv4/v6-TG intercepts a BU message, takes out HoAv6* from the
intercepted message as an index to search the MIP table and finds
this entry.
(4) MIP-ALG sets the field of MIPv4 Datagram Entrance to CoAv4#, and
MIPv6 Datagram Entrance to CNAv6*. Then MIP-ALG generates a BA
message, and its source address and destination address are copied
directly from the destination address and source address fields of
the BU message. The BA message will be routed to MNv6.
Ma Expires December 28, 2008 [Page 28]
Internet-Draft Mobility Support in IPv4/v6 June 2008
(5) MIP-ALG sets the State to 1, and then sets the Lifetime to the
lifetime of the binding.
If CN is located in IPv6 network, the following steps will be
performed:
(1) MIPv4/v6-TG intercepts HoTI message, takes out HoAv6* from the
intercepted message as an index to search the MIP table and finds
this entry. Note that HoTI arrives through tunneling.
(2) MIP-ALG can judge the IP version of CN by the destination address
of HoTI. MIP-ALG sets the field of Type to 011, and then sends HoTI
to CNv6.
(3) MIPv4/v6-TG intercepts HoT message replied from CNv6, takes out
HoAv6* from the intercepted message as an index to search the MIP
table and finds this entry.
(4) MIP-ALG sets the HoTI/HoT field to 1, and then sends HoT to MNv6.
Note that the HoT message is sent through tunneling.
(5) MIP-ALG sets the State to 1, and then sets the Lifetime to the
lifetime of the binding.
When the creation of a Type 2 entry finishes, the value of each field
is as follows.
Type: 010. HA and CN are located in IPv4 network, MN is located in
IPv6 network. On intercepting HoTI or CoTI, MIPv4/v6-TG can judge the
IP versions of HA, MN and CN.
MIPv6 Message Entrance: HoAv6*. HoAv6* is acquired from the BU
message.
MIPv6 Datagram Entrance: CNAv6*. CNAv6* is acquired from the
destination address of the BU message.
MIPv4 Message Entrance: CoAv4#. CoAv4# is a mapping of CoAv6 and can
be acquired by searching the NAT table, using CoAv6 as the index.
CoAv6 is acquired from the BU message sent to HA. If no mapping is
found, MIP-ALG takes an IPv4 address from NAT-PT address pool and
uses it as CoAv4#. Meanwhile, a binding of CoAv4# and CoAv6 will be
recorded in NAT table.
MIPv4 Datagram Entrance: CoAv4#. Ditto. The only difference is that
CoAv6 is acquired from the source address of the BU message sent to
CN.
Ma Expires December 28, 2008 [Page 29]
Internet-Draft Mobility Support in IPv4/v6 June 2008
Cache Bindings: HoAv6*<-->CoAv6. Both HoAv6* and CoAv6 are acquired
from the BU message sent to CN.
HoTI/HoT: 1. HoTI/HoT has arrived.
CoT/CoTI: 1. CoTI/CoT has arrived.
Source Port: variable. The source port number of the Registration
Request message, which is variable.
Destination Port: 434. The destination port number of the
Registration request message is 434.
State: 1. Finished.
When the creation of a Type 3 entry finishes, the value of each field
is as follows.
Type: 011. HA is located in IPv4 network, MN and CN are located in
IPv6 network. On Receiving HoTI message, the IP versions of HA, MN
and CN can be inferred.
MIPv6 Message Entrance: HoAv6*. HoAv6* is acquired from the BU
message sent to HA.
MIPv6 Datagram Entrance: blank.
MIPv4 Message Entrance: CoAv4#. CoAv4# is a mapping of CoAv6 and can
be acquired by searching the NAT table, using CoAv6 as the index.
CoAv6 is acquired from the BU message sent to HA. If no mapping is
found, MIP-ALG takes an IPv4 address from NAT-PT address pool and
uses it as CoAv4#. Meanwhile, a binding of CoAv4# and CoAv6 will be
recorded in NAT table.
MIPv4 Datagram Entrance: blank.
Cache Bindings: HoAv6*<-->CoAv6. Both HoAv6* and CoAv6 are acquired
from the BU message sent to HAv6.
HoTI/HoT: 1. HoTI/HoT has arrived.
CoT/CoTI: 1. CoTI/CoT has arrived.
Source Port: variable. The source port number of the Registration
Request message, which is variable.
Ma Expires December 28, 2008 [Page 30]
Internet-Draft Mobility Support in IPv4/v6 June 2008
Destination Port: 434. The destination port number of the
Registration request message is 434.
State: 1. Finished.
Lifetime: set to the lifetime of the entry.
8.3.3. Creating Entries triggered by Extended Registration Request
messages
The format of the Extended Registration Request message is available
in section 5.1.
In this protocol, MN sends the Extended Registration Request message
only when it moves from IPv6 network to IPv4 network and performs the
first registration. After MN's movement from IPv6 network to IPv4
network, the original entry becomes invalid. Therefore, a new entry
should be created.
(1) On receiving the Extended Registration Request message, MIP-ALG
can learn the IP versions of the three entities: HA is in IPv6
network, MN is in IPv4 network. As for CN, if the IPv4 address of CN
carried in the extension field of the message belongs to the NAT-PT
address pool, the IP version of CN is IPv6. Otherwise, the IP version
of CN is IPv4.
MIP-ALG creates a new entry and sets the fields of Source Port and
Destination Port to the source port number and destination port
number of the intercepted message, respectively, the field of State
to 0, and the field of Lifetime to a value in which the creation of
the entry must be accomplished.
o If CN is located in IPv4 network, MIP-ALG sets the field of Type
to 100, MIPv6 Message Entrance to HoAv6, MIPv4 Message Entrance to
HAAv4#, MIPv4 Datagram Entrance to HoAv4#, Cached Bindings to
HoAv4#<-->CoAv4.
o If CN is located in IPv6 network, MIP-ALG sets the field of Type
to 101, MIPv6 Message Entrance to HoAv6, MIPv6 Datagram Entrance
to CoAv6*, MIPv4 Message Entrance to HAAv4#, MIPv4 Datagram
Entrance to CNAv4#, Cached Bindings to HoAv6<-->CoAv6* and
HoAv4#<-->CoAv4, HoTI/HoT and CoTI/CoT to 0.
(2) MIP-ALG generates a BU message with CoAv6* and HAAv6 as its
source address and destination address, respectively. HoAv6 is
carried in the message. Here, HAAv6 is acquired by checking the NAT
table using HAAv4# as the index, while CoAv6* is acquired by adding a
Ma Expires December 28, 2008 [Page 31]
Internet-Draft Mobility Support in IPv4/v6 June 2008
96-bit NAT-PT prefix to CoAv4. Both HAAv4# and CoAv4 are taken from
the Extended Registration Request message. This message will be
routed to HAv6.
(3) MIPv4/v6-TG intercepts the BA message replied from HAv6, takes
out HoAv6 from the intercepted message as an index to search the MIP
table and finds this entry.
If CN is located in IPv4 network, the following steps will be
performed:
(1) MIP-ALG generate Registration Reply message, with HAAv4# and
CoAv4 as its source address and destination address, respectively.
This message is sent through UDP, with the source port number and
destination port number copied from the Destination Port field and
Source Port field. This message will be routed to MNv4.
(2) MIP-ALG sets the State field to 1, and sets the Lifetime field to
the lifetime of the binding.
If CN is located in IPv6 network, the following steps will be
performed:
(1) MIP-ALG generates a HoTI message and a CoTI message. The source
address and destination address of HoTI are HoAv6 and CNAv6,
respectively. The HoTI message is sent to HAv6 through reverse
tunneling, and then sent to CNv6. The beginning point and endpoint of
the tunnel are CoAv6* and HAAv6, respectively. The source address and
destination of CoTI are CoAv6* and CNAv6.
(2) MIPv4/v6-TG intercepts the HoT message or the CoT message, takes
out HoAv6 from the intercepted message as an index to search the MIP
table and finds this entry.
(3) MIP-ALG sets the HoTI/HoT field, or the CoTI/CoT field to 1,
indicating the arrival of the HoT message or the CoT message.
(4) When both HoTI/HoT and CoTI/CoT fields become 1, MIP-ALG
generates a BU message, with CoAv6* and CNAv6 as its source address
and destination address, respectively. HoAv6 is carried in the
message. This message will be routed to CNv6.
(5) MIPv4/v6-TG intercepts a BA message replied from CNv6, takes out
HoAv6 from the intercepted message as an index to search the MIP
table and finds this entry.
Ma Expires December 28, 2008 [Page 32]
Internet-Draft Mobility Support in IPv4/v6 June 2008
(6) MIP-ALG generate Registration Reply message, with HAAv4# and
CoAv4 as its source address and destination address, respectively.
This message is sent through UDP, with the source port number and
destination port number copied from the Destination Port field and
Source Port field. This message will be routed to MNv4.
(7) MIP-ALG sets the State field to 1, and sets the Lifetime field to
the lifetime of the binding.
When the creation of a Type 4 entry finishes, the value of each field
is as follows.
Type: 100. HA is located in IPv6 network, MN and CN are located in
IPv4 network.
MIPv6 Message Entrance: HoAv6. HoAv6 is acquired from the extension
field of the Extended Registration Request message.
MIPv6 Datagram Entrance: blank.
MIPv4 Message Entrance: HAAv4#. HAAv4# is acquired from the
destination address field of the Extended Registration Request
message.
MIPv4 Datagram Entrance: HoAv4#. HoAv4# is a mapping address of HoAv6
and can be acquired by searching the NAT table, using HoAv6 as the
index. HoAv6 is acquired from the Extended Registration Request
message. If no mapping is found, MIP-ALG takes an IPv4 address from
NAT-PT address pool and uses it as HoAv4#. Meanwhile, a mapping of
HoAv4# and HoAv6 will be recorded in NAT table.
Cache Bindings: HoAv4#<-->CoAv4. CoAv4 is acquired from the source
address field of the Extended Registration Request message.
HoTI/HoT: 1. HoTI/HoT has arrived.
CoT/CoTI: 1. CoTI/CoT has arrived.
Source Port: variable. The source port number of the Extended
Registration Request message, which is variable.
Destination Port: 434. The destination port number of the Extended
Registration Request message is 434.
Lifetime: set to the lifetime of the entry.
Ma Expires December 28, 2008 [Page 33]
Internet-Draft Mobility Support in IPv4/v6 June 2008
When the creation of a Type 5 entry finishes, the value of each field
is as follows.
Type: 101. HA and CN are located in IPv6 network, MN is located in
IPv4 network.
MIPv6 Message Entrance: HoAv6. HoAv6 is acquired from the extension
fields of extended Registration Request message.
MIPv6 Datagram Entrance: CoAv6*. CoAv6* is acquired by adding a 96-
bit NAT-PT prefix to CoAv4, which is acquired from the Extended
Registration Request message.
MIPv4 Message Entrance: HAAv4#. HAAv4# is acquired from the
destination address field of the Extended Registration Request
message.
MIPv4 Datagram Entrance: CNAv4#. CNAv4# is acquired from the
extension field of extended Registration Request message.
Cache Bindings: HoAv4#<-->CoAv4, HoAv6<-->CoAv6*. HoAv4# is a mapping
address of HoAv6 and can be acquired by searching the NAT table,
using HoAv6 as the index. HoAv6 is acquired from the Extended
Registration Request message. If no mapping is found, MIP-ALG takes
an IPv4 address from NAT-PT address pool and uses it as HoAv4#.
Meanwhile, a mapping of HoAv4# and HoAv6 will be recorded in NAT
table.
HoTI/HoT: 1. HoTI/HoT has arrived.
CoT/CoTI: 1. CoTI/CoT has arrived.
Source Port: variable. The source port number of the Extended
Registration Request message, which is variable.
Destination Port: 434. The destination port number of the Extended
Registration Request message is 434.
Lifetime: set to the lifetime of the entry.
8.3.4. Creating Entries triggered by HoTI messages or CoTI messages
When MIPv4/v6-TG intercepts a HoTI message or CoTI message, it takes
out HoAv6 from the message and uses it as an index to search the MIP
table. MIPv4/v6-TG compares the MIPv6 Message Entrance with HoAv6. If
no matching entry is found, MIPv4/v6-TG will create a new entry,
using the information carried in the HoTI or CoTI message. If a
Ma Expires December 28, 2008 [Page 34]
Internet-Draft Mobility Support in IPv4/v6 June 2008
matching entry is found, MIPv4/v6-TG will go further to see if the
second bit of the Type is equal to 1 (i.e., MN is in IPv6 network).
If so, MIP-ALG will just update the existing entry, without creating
a new entry. Otherwise, MIP-ALG will create a new entry and the
following steps will be performed.
(1) MIP-ALG infers that both HA and MN are located in IPv6 network
and CN is located in IPv4 network, since only in this scenario can
MIPv4/v6-TG receive a HoTI message or CoTI message without receiving
BU from the same MN before.
MIP-ALG sets the field of Type to 110, MIPv6 Message Entrance to
HoAv6, MIPv6 Datagram Entrance to CNAv6*, MIPv4 Datagram Entrance to
HoAv4#, State to 0, and Lifetime to a value in which the creation of
this entry must be accomplished.
(2) MIP-ALG generates a HoT message or CoT message. The HoT message
is first sent to HAv6, then to MNv6 by HAv6 through tunneling. CoT
message is sent directly to MNv6.
(3) MIPv4/v6-TG intercepts the BU message, takes out HoAv6 and uses
it as an index to search the MIP table, and finds this entry.
(4) MIP-ALG sets the field of Cached Bindings to HoAv6<-->CoAv6, and
then generates a BA message, with its source address and destination
address copied directly from the destination address and source
address of the BU message. The BA message will be routed to MNv6.
(5) MIP-ALG sets the State field to 1, and then sets the Lifetime to
the lifetime of the binding.
When the creation of a Type 6 entry finishes, the value of each field
is as follows.
Type: 110. Both HA and MN are located in IPv6 network, and CN is
located in IPv4 network. On receiving HoTI or CoTI, MIPv4/v6-TG can
judge the versions of HA, MN and CN.
MIPv6 Message Entrance: HoAv6. HoAv6 is acquired from the HoTI or
CoTI message.
MIPv6 Datagram Entrance: CNAv6*. CNAv6* is acquired from the
destination address field of the HoTI message or CoTI message.
MIPv4 Message Entrance: blank.
Ma Expires December 28, 2008 [Page 35]
Internet-Draft Mobility Support in IPv4/v6 June 2008
MIPv4 Datagram Entrance: HoAv4#. HoAv4# is a mapping address of HoAv6
and can be acquired by searching the NAT table, using HoAv6 as the
index. HoAv6 is acquired from the HoTI message or CoTI message. If no
mapping is found, MIP-ALG takes an IPv4 address from NAT-PT address
pool and uses it as HoAv4#. Meanwhile, a mapping of HoAv4# and HoAv6
will be recorded in NAT table.
Cache Bindings: HoAv6<-->CoAv6. Both HoAv6 and CoAv6 are acquired
from the BU message sent to CN.
HoTI/HoT: blank.
CoT/CoTI: blank.
Source Port: blank.
Destination Port: blank.
Lifetime: set to the lifetime of the entry.
8.4. The Usage of MIP Table
The introduction of MIP table aims to maintain MIP sessions in
IPv4/v6 mixed networks. When a datagram sent by MN or CN passes
through MIPv4/v6-TG, MIPv4/v6-TG will take out the destination
address of the datagram and uses it as an index to search the MIP
table. If a matching entry is found, MIPv4/v6-TG will process the
datagram, based on the information recorded in the entry.
8.4.1. The usage of Type 1 MIP Table Entry
The contents of Type 1 entry are available in section 8.3.1.
(1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
will take out its destination address and uses it as an index to
search the MIP table. If a Type 1 entry is found, MIPv4/v6-TG will
process the datagram as follows.
o NAT-PT, a component of MIPv4/v6-TG, translates the datagram into
IPv6 format.
o MIP-ALG inserts a Destination Option extension header into the
IPv6 datagram, and fills the header with the source address of the
IPv6 datagram. Then MIP-ALG uses the source address as an index to
search Cached Bindings field, and takes out the care-of address
bound with the source address, and replaces the source address
with the care-of address.
Ma Expires December 28, 2008 [Page 36]
Internet-Draft Mobility Support in IPv4/v6 June 2008
o MIPv4/v6-TG sends the processed IPv6 datagram.
(2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
takes out its destination address and uses it as an index to search
the MIP table. If a Type 1 entry is found, MIPv4/v6-TG will process
the datagram as follows.
o MIPv4/v6-TG replaces the destination address of the datagram with
the IPv6 home address, which is taken from the type 2 routing
header of the datagram.
o NAT-PT translates the datagram into IPv4 format.
o MIPv4/v6-TG sends the processed IPv4 datagram.
8.4.2. The usage of Type 2 MIP Table Entry
The contents of Type 2 entry are available in section 8.3.2.
(1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
will take out its destination address and uses it as an index to
search the MIP table. If a Type 2 entry is found, MIPv4/v6-TG will
process the datagram as follows.
o MIP-ALG decapsulates the IPv4 datagram and gets the inner datagram.
o NAT-PT translates the datagram into IPv6 format.
o MIP-ALG inserts a type 2 routing header into the IPv6 datagram,
and fills the header with the destination address of the IPv6
datagram. Then MIP-ALG uses the destination address as an index to
search Cached Bindings field, and takes out the care-of address
bound with the destination address, and replaces the destination
address with the care-of address.
o MIPv4/v6-TG sends the processed IPv6 datagram.
(2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
takes out its destination address and uses it as an index to search
the MIP table. If a Type 2 entry is found, MIPv4/v6-TG will process
the datagram as follows.
o MIPv4/v6-TG replaces the source address of the datagram with the
IPv6 home address, which is taken from the Destination Option
extension header of the datagram.
o NAT-PT translates the datagram into IPv4 format.
Ma Expires December 28, 2008 [Page 37]
Internet-Draft Mobility Support in IPv4/v6 June 2008
o MIPv4/v6-TG sends the processed IPv4 datagram.
8.4.3. The usage of Type 3 MIP Table Entry
A Type 3 entry corresponds to a scenario where both MN and CN are
located in IPv6 network. In this scenario, MN and CN can communicate
with each other without the participation of MIPv4/v6-TG. Therefore,
Type 3 entries will not be used in the communication processes.
8.4.4. The usage of Type 4 MIP Table Entry
The contents of Type 4 entry are available in section 8.3.3.
When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG will
take out its destination address and uses it as an index to search
the MIP table. If a Type 4 entry is found, MIPv4/v6-TG will process
the datagram as follows.
o MIP-ALG encapsulates the datagram in a new IPv4 datagram. The
source address of the outer IP header is copied from MIPv4 Message
Entrance field. Then MIP-ALG uses the destination address of the
inner IP header as an index to search Cached Bindings field, and
takes out the care-of address bound with the destination address,
and uses the care-of address as the destination address of the
outer IP header.
o MIPv4/v6-TG sends the processed IPv4 datagram.
In the scenarios related to Type 4 entries, no MIPv6 datagrams will
arrive at MIPv4/v6-TG.
8.4.5. The usage of Type 5 MIP Table Entry
The contents of Type 5 entry are available in section 8.3.3.
(1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
will take out its destination address and uses it as an index to
search the MIP table. If a Type 5 entry is found, MIPv4/v6-TG will
process the datagram as follows.
o NAT-PT translates the datagram into IPv6 format.
Ma Expires December 28, 2008 [Page 38]
Internet-Draft Mobility Support in IPv4/v6 June 2008
o MIP-ALG inserts a Destination Option extension header into the
IPv6 datagram, and fills the header with the source address of the
IPv6 datagram. Then MIP-ALG uses the source address as an index to
search Cached Bindings field, and takes out the care-of address
bound with the source address, and replaces the source address
with the care-of address.
o MIPv4/v6-TG sends the processed IPv6 datagram.
(2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
takes out its destination address and uses it as an index to search
the MIP table. If a Type 5 entry is found, MIPv4/v6-TG will process
the datagram as follows.
o MIP-ALG replaces the destination address of the datagram with the
IPv6 home address, which is taken from the type 2 routing header
of the datagram.
o NAT-PT translates the datagram into IPv4 format.
o MIP-ALG encapsulates the datagram in a new IPv4 datagram. The
source address of the outer IP header is copied from MIPv4 Message
Entrance field. Then MIP-ALG uses the destination address of the
inner IP header as an index to search Cached Bindings field, and
takes out the care-of address bound with the destination address,
and uses the care-of address as the destination address of the
outer IP header.
o MIPv4/v6-TG sends the processed IPv4 datagram.
8.4.6. The usage of Type 6 MIP Table Entry
The contents of Type 6 entry are available in section 8.3.4.
(1) When an IPv4 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
will take out its destination address and uses it as an index to
search the MIP table. If a Type 6 entry is found, MIPv4/v6-TG will
process the datagram as follows.
o NAT-PT translates the datagram into IPv6 format.
o MIP-ALG inserts a Type 2 routing header into the IPv6 datagram,
and fills the header with the destination address of the IPv6
datagram. Then MIP-ALG uses the destination address as an index to
search Cached Bindings field, and takes out the care-of address
bound with the destination address, and replaces the destination
address with the care-of address.
Ma Expires December 28, 2008 [Page 39]
Internet-Draft Mobility Support in IPv4/v6 June 2008
o MIPv4/v6-TG sends the processed IPv6 datagram.
(2) When an IPv6 datagram passes through MIPv4/v6-TG, MIPv4/v6-TG
takes out its destination address and uses it as an index to search
the MIP table. If a Type 6 entry is found, MIPv4/v6-TG will process
the datagram as follows.
o MIPv4/v6-TG replaces the source address of the datagram with the
IPv6 home address, which is taken from the Destination Option
extension header of the datagram.
o NAT-PT translates the datagram into IPv4 format.
o MIPv4/v6-TG sends the processed IPv4 datagram.
8.5. The Update of MIP Table Entries
When MN moves within network of the same IP version and acquires a
new care-of address, it will update the binding caches on HA and CN
(when CN is in IPv6 network) as well as the binding caches on the
related MIP table entry under some circumstances. Like the creation
of MIP table entries, the update of the entry is triggered by MIP
messages, such as Registration Request messages, BU messages,
HoTI/HoT messages and CoTI/CoT messages. In the creation process,
MIPv4/MIPv6 Message Entrance of the entry have been set. MIPv4/v6-TG
can access a corresponding entry through these entrances when it
intercepts a MIP message, and then updates the entry.
Note that when MN moves to a network of a different IP version, the
original entry (if any) becomes invalid and a new MIP table entry
should be created. This has been discussed in section 8.3.
8.5.1. The Update of Type 1 MIP Table Entries
The contents of Type 1 entry are available in section 8.3.1.
A Type 1 entry corresponds to a scenario where both HA and MN are
located in IPv4 network, and CN is located in IPv6 network. According
to RFC3344, MN does not register with CN. Therefore, MIPv4/v6-TG will
not receive any Registration Request message sent by MN. The contents
of the corresponding entry, except the Lifetime, do not need to be
updated.
According to RFC3775, CN also maintains a binding cache which should
be updated after MN acquires a new care-of address. In this scenario,
however, the destination address of datagrams sent by CN consists of
two parts: a 96-bit NAT-PT prefix and IPv4 care-of address. It is
Ma Expires December 28, 2008 [Page 40]
Internet-Draft Mobility Support in IPv4/v6 June 2008
only based on the 96-bit NAT-PT prefix that the datagrams are routed
to MIPv4/v6-TG. MIPv4/v6-TG will then send the datagrams to HA,
rather than MN. Therefore, as long as the binding cache on HA has
been updated, the datagrams sent by CN will be correctly delivered to
MN by HA.
8.5.2. The Update of Type 2 MIP Table Entries
The contents of a Type 2 MIP table entry are available in section
8.3.2.
A Type 2 entry corresponds to a scenario where both HA and CN are
located in IPv4 network, and MN is located in IPv6 network. The
update process of a Type 2 MIP table entry is as follows.
MIPv4/v6-TG intercepts a BU message, takes out the IPv6 home address
from the intercepted message, uses it as an index to search the MIP
table, and finds the related Type 2 entry.
If the State value is equal to 1, then the following steps will be
performed:
(1) MIP-ALG sets the fields of State to 0, and Lifetime to a value in
which the update of this entry must be accomplished.
(2) MIP-ALG takes CoAv4# from MIPv4 Message Entrance and uses it as
an index to search the NAT table. A mapping of CoAv4#<-->CoAv6 will
be found. Then MIP-ALG updates the mapping with the new CoAv6 carried
in the BU message.
(3) MIP-ALG generates a BA message. The source address and
destination address are copied from the destination address and
source address of the BU message. HoAv6* is also carried in the BA
message. This BA message will be routed to MNv6.
(4) MIPv4/v6-TG intercepts a HoTI message or a CoTI message, takes
out HoAv6* from the intercepted message as an index to search the MIP
table and finds this entry.
(5) MIP-ALG replies with a HoT message or CoT message.
(6) MIPv4/v6-TG intercepts a BU message, takes out the IPv6 home
address from the intercepted message, uses it as an index to search
the MIP table, and finds this entry.
(7) MIP-ALG updates Cached Bindings HoAv6*<-->CoAv6 with the new
CoAv6 carried in the BU message.
Ma Expires December 28, 2008 [Page 41]
Internet-Draft Mobility Support in IPv4/v6 June 2008
(8) MIP-ALG generates BA message, the source address and destination
address are copied from the destination address and source address of
the BU message. HoAv6* is also carried in the BA message. This BA
message will be routed to MNv6.
(9) MIP-ALG sets the State field to 1, and then sets the Lifetime to
the lifetime of the binding.
If the State value is equal to 0, then the following steps will be
performed:
(1) MIP-ALG updates Cached Bindings HoAv6*<-->CoAv6 with the new
CoAv6 carried in the BU message.
(2) MIP-ALG generates BA message, the source address and destination
address are copied from the destination address and source address of
the BU message. HoAv6* is also carried in the BA message. This BA
message will be routed to MNv6.
(3) MIP-ALG sets the State field to 1, and then sets the Lifetime to
the lifetime of the binding.
8.5.3. The Update of Type 3 MIP Table Entries
The contents of a Type 3 MIP table entry are available in section
8.3.2.
A Type 3 entry corresponds to a scenario where HA is located in IPv4
network, while MN and CN are located in IPv6 network. The update
process of a Type 3 MIP table entry is as follows.
(1) MIPv4/v6-TG intercepts a BU message, takes out HoAv6* and uses it
as an index to search the MIP table, and finds a related Type 3 entry.
(2) MIP-ALG sets the fields of State to 0, and Lifetime to a value in
which the update of this entry must be accomplished.
(3) MIP-ALG takes CoAv4# from MIPv4 Message Entrance and uses it as
an index to search the NAT table. A mapping of CoAv4#<-->CoAv6 will
be found. Then MIP-ALG updates the mapping with the new CoAv6 carried
in the BU message.
(4) MIP-ALG updates Cached Bindings HoAv6*<-->CoAv6 with the new
CoAv6 carried in the BU message.
(5) MIP-ALG generates a BA message. The source address and
destination address are copied from the destination address and
Ma Expires December 28, 2008 [Page 42]
Internet-Draft Mobility Support in IPv4/v6 June 2008
source address of the BU message. HoAv6* is also carried in the BA
message. This BA message will be routed to MNv6.
(6) MIPv4/v6-TG intercepts a HoTI message, takes out HoAv6* from the
intercepted message as an index to search the MIP table and finds
this entry. This HoTI message will be then delivered to CNv6.
(7) MIPv4/v6-TG intercepts a HoT message, takes out HoAv6* from the
intercepted message as an index to search the MIP table and finds
this entry. This HoT message will be routed to MNv6 through tunneling.
The beginning point and endpoint of the tunnel are HAAv6* and CoAv6.
CoAv6 can be acquired from the Cached Bindings field of the entry.
(8) MIP-ALG sets the field of State to 1, and the Lifetime to the
lifetime of the binding.
8.5.4. The Update of Type 4 MIP Table Entries
The contents of a Type 4 MIP table entry are available in section
8.3.3.
A Type 4 entry corresponds to a scenario where HA is located in IPv6
network, while MN and CN are located in IPv4 network. The update
process of a Type 4 MIP table entry is as follows.
(1) MIPv4/v6-TG intercepts a Registration Request message, takes out
destination address from the intercepted message as an index to
search the MIP table and finds a related Type 4 entry.
(2) MIP-ALG sets the fields of State to 0, Lifetime to a value in
which the update of this entry must be accomplished, and Source Port
and Destination Port to the source port number and destination port
number of the intercepted message.
(3) MIP-ALG updates Cached Bindings HoAv4#<-->CoAv4 with the new
CoAv4 carried in the Registration Request message.
(4) MIP-ALG generates a BU message based on the Registration Request
message. The source address and destination address of the BU message
are CoAv6* and HAAv6, respectively. HoAv6 is carried in the message.
CoAv6* is acquired by adding a 96-bit NAT-PT prefix to CoAv4. HAAv6
and HoAv6 are acquired by checking the NAT table, using HAAv4# and
HoAv4# as the index. This BU message will be routed to HAv6.
(5) MIPv4/v6-TG intercepts a BA message replied from HAv6, takes out
HoAv6 from the intercepted message as an index to search the MIP
table and finds this entry.
Ma Expires December 28, 2008 [Page 43]
Internet-Draft Mobility Support in IPv4/v6 June 2008
(6) MIP-ALG generates a Registration Reply message, with HAAv4# and
CoAv4 as the source address and destination address. This message is
sent through UDP. The source port number and destination port number
are copied from the Destination Port and Source Port, respectively.
This message will be routed to MNv4.
(7) MIP-ALG sets the field of State to 1, and the Lifetime to the
lifetime of the binding.
8.5.5. The Update of Type 5 MIP Table Entries
The contents of a Type 5 MIP table entry are available in section
8.3.3.
A Type 5 entry corresponds to a scenario where both HA and CN are
located in IPv6 network, and MN is located in IPv4 network. The
update process of a Type 5 MIP table entry is as follows.
(1) MIPv4/v6-TG intercepts a Registration Request message, takes out
destination address from the intercepted message as an index to
search the MIP table and finds a related Type 5 entry.
(2) MIP-ALG sets the fields of State, HoTI/HoT and CoTI/CoT to 0,
MIPv6 Datagram Entrance to CoAv6*, Lifetime to a value in which the
update of this entry must be accomplished, and Source Port and
Destination Port to the source port number and destination port
number of the message. CoAv6* is acquired by adding a 96-bit NAT-PT
prefix to CoAv4. CoAv4 can be acquired from the source address field
of the Registration Request message.
(3) MIP-ALG generates a BU message based on the Registration Request
message. The source address and destination address of the BU message
are CoAv6* and HAAv6, respectively. HoAv6 is carried in the message.
CoAv6* is acquired by adding a 96-bit NAT-PT prefix to CoAv4. HAAv6
and HoAv6 are acquired by checking the NAT table, using HAAv4# and
HoAv4# as the index. This message will be routed to HAv6.
(4) MIPv4/v6-TG intercepts a BA message, takes out HoAv6 from the
intercepted message as an index to search the MIP table and finds
this entry.
(5) MIP-ALG generates a HoTI message and a CoTI message. The source
address and destination address of the HoTI message are HoAv6 and
CNAv6, respectively. The HoTI message is first sent to HAv6 through
reverse tunneling and then to CNv6. The beginning point and endpoint
of the tunnel are CoAv6* and HAAv6, respectively. The source address
and destination address of the CoTI message are CoAv6* and CNAv6,
Ma Expires December 28, 2008 [Page 44]
Internet-Draft Mobility Support in IPv4/v6 June 2008
respectively. CNAv6 is acquired by checking the NAT table, using
CNAv4# as the index.
(6) MIPv4/v6-TG intercepts a HoT message or a CoT message, takes out
HoAv6 from the intercepted message as an index to search the MIP
table and finds this entry.
(7) MIP-ALG sets the fields of HoTI/HoT or CoTI/CoT to 1. When both
HoTI/HoT and CoTI/CoT fields become 1, MIP-ALG generates a BU message
with CoAv6* and CNAv6 as the source address and destination address.
This message will be routed to CNv6.
(8) MIPv4/v6-TG intercepts the BA message replied from CNv6, takes
out HoAv6 from the intercepted message as an index to search the MIP
table and finds this entry.
(9) MIP-ALG updates Cached Bindings HoAv4#<-->CoAv4 and HoAv6<--
>CoAv6* with the new CoAv4 and CoAv6*, respectively.
(10) MIP-ALG generates a Registration Reply message, with HAAv4# and
CoAv4 as the source address and destination address. This message is
sent through UDP. The source port number and destination port number
are copied from Destination Port and Source Port. This message will
be routed to MNv4.
(11) MIP-ALG sets the State field to 1, and then sets the Lifetime to
the lifetime of the binding.
8.5.6. The Update of Type 6 MIP Table Entries
The contents of a Type 6 MIP table entry are available in section
8.3.4.
A Type 6 entry corresponds to a scenario where both HA and MN are
located in IPv6 network, while CN is located in IPv4 network. The
update process of a Type 6 MIP table entry is as follows.
(1) MIPv4/v6-TG intercepts a HoTI message or a CoTI message, takes
out HoAv6 from the intercepted message as an index to search the MIP
table and finds a related Type 6 entry.
(2) MIP-ALG sets the State field to 0.
(3) MIP-ALG generates a HoT message or a CoT message. HoT message is
first sent to HA and then delivered to MNv6 through tunneling. CoT
message is sent directly to MNv6.
Ma Expires December 28, 2008 [Page 45]
Internet-Draft Mobility Support in IPv4/v6 June 2008
(4) MIPv4/v6-TG intercepts a BU message, takes out HoAv6 from the
intercepted message as an index to search the MIP table and finds
this entry.
(5) MIP-ALG updates the binding of HoAv6<-->CoAv6 with the new CoAv6
acquired from the BU message.
(6) MIP-ALG generates a BA message, the source address and
destination address of which are copied from the destination address
and source address of the BU message. This message will be routed
MNv6.
(7) MIP-ALG sets the State field to 1, and then sets the Lifetime to
the lifetime of the binding.
9. Protocol Constants
MAX_MIP_CREATE_TIMEOUT 30 seconds
In this protocol, the creation of MIP table entry should be
accomplished within an interval of 30 seconds after the creation
begins. If the creation is not accomplished after 30 seconds, the
unfinished MIP table entry will be deleted.
10. Security Considerations
10.1. Security policy for HA, MN and CN
This protocol places no additional requirements on HA, MN and CN.
Security policy for a particular entity depends on which network the
entity is located in. If it is located in IPv4 network, it should
meet the security requirements described in RFC3344. If it is located
in IPv6 network, it should meet the security requirements described
in RFC3775.
10.2. Security Considerations for MIPv4/v6-TG
As for MIPv4/v6-TG, the following aspects should be considered.
MIPv4/v6-TG is made up of NAT-PT and MIP-ALG. Security threats to
NAT-PT, such as DoS attacks, single point failure, are also potential
threats to MIPv4/v6-TG. There have been some methods to deal with
such threats. These methods can be applied to MIPv4/v6-TG. For
example, to avoid single point failure, a backup MIPv4/v6-TG can be
introduced.
Ma Expires December 28, 2008 [Page 46]
Internet-Draft Mobility Support in IPv4/v6 June 2008
On IPv4 network side, MIPv4/v6-TG acts as an IPv4 entity, while on
IPv6 network side, it acts as an IPv6 entity. MIPv4/v6-TG has to deal
with MIPv4 or MIPv6 messages and datagrams. When processing these
messages and datagrams, MIPv4/v6-TG also faces the same security
threats as any MIPv4 or MIPv6 entity. In RFC3344 and RFC3775, some
security policies have been introduced to protect MIPv4 registration
processes and communication processes. These security policies are
adopted in this protocol. For example, when MIPv4/v6-TG acts as a
MIPv6 entity, it should support the Return Routability Procedure.
When MIPv4/v6-TG acts as a MIPv4 entity, it should use Authentication
extension to protect the registration processes.
11. IANA Considerations
This protocol introduces three news messages: the extended
Registration Request message, the Agent Request message and the Agent
Reply message. These three messages have similar message format with
the Registration Request/Reply message in RFC3344, but with different
message Type values. In this document, the Type values of these three
messages are 4, 5 and 6, respectively. These values are to be
determined by IANA.
Ma Expires December 28, 2008 [Page 47]
Internet-Draft Mobility Support in IPv4/v6 June 2008
12. Normative References
[1] C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002
[2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
RFC 3775, June 2004
[3] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765,
February 2000.
[4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Zhengming Ma
Zhongshan University
Department of Electronics and Engineering, Zhongshan University, 135
Xingangxi Road, Guangzhou, P.R. China
Email: issmzm@mail.sysu.edu.cn
Qingyu Tan
Zhongshan University
Department of Electronics and Engineering, Zhongshan University, 135
Xingangxi Road, Guangzhou, P.R. China
Email: tqytan@163.com
Zheng Xiang
Zhongshan University
Department of Electronics and Engineering, Zhongshan University, 135
Xingangxi Road, Guangzhou, P.R. China
Email: rousseau2000@163.com
Ma Expires December 28, 2008 [Page 48]
Internet-Draft Mobility Support in IPv4/v6 June 2008
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, THE IETF TRUST 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 IETF Trust (2008).
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.
Ma Expires December 28, 2008 [Page 49]
