One document matched: draft-wakikawa-nemo-v4tunnel-01.txt
Differences from draft-wakikawa-nemo-v4tunnel-00.txt
NEMO Working Group Ryuji Wakikawa
INTERNET DRAFT Keio Univ./WIDE
21 Feb 2005 Vijay Devarapalli
Nokia Research Center
Carl E. Williams
KDDI Labs USA
IPv4 Care-of Address Registration
draft-wakikawa-nemo-v4tunnel-01.txt
Status of This Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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.
Abstract
The NEMO Basic support protocol [1] specifies the operation of a
Mobile Router. The Mobile Router has a bi-directional tunnel to
its Home Agent through which it reverse tunnels all traffic. When
the Mobile Router roams and connects to an access network that only
implements IPv4, it needs to use IPv6 transition tunneling mechanisms
to reach its Home Agent. This will result in a NEMO tunnel inside a
transition tunnel. This document describes protocol extensions to
the NEMO Basic support protocol to maintain IPv6 connectivity for the
Mobile Router via its Home Agent with IPv6-over-IPv4 encapsulation
with no special boxes to be deployed anywhere in the network.
R. Wakikawa et.al. [Page 1]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
Contents
Status of This Memo 1
Abstract 1
1. Introduction 3
2. Terminology 4
3. Protocol Overview 4
4. Mobile IPv6 Extensions 5
4.1. IPv4 Care-of Address option . . . . . . . . . . . . . . . 5
4.2. Binding Update . . . . . . . . . . . . . . . . . . . . . 6
4.3. Binding Acknowledgment . . . . . . . . . . . . . . . . . 7
5. Securing the tunnel between the Mobile Router and the Home Agent 7
5.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Binding Update and Binding Acknowledgement . . . 8
5.1.2. Mobile Prefix Discovery . . . . . . . . . . . . . 8
5.1.3. Mobile Network Traffic . . . . . . . . . . . . . 9
5.2. IPsec Configuration . . . . . . . . . . . . . . . . . . . 9
5.2.1. Binding Update and Acknowledgement . . . . . . . 9
5.2.2. Mobile Prefix Discovery . . . . . . . . . . . . . 10
5.2.3. Mobile Network Traffic . . . . . . . . . . . . . 11
6. Home Agent IPv4 Address Discovery 12
7. IPv4 Care-of Address Registration 12
7.1. Sending Binding Update . . . . . . . . . . . . . . . . . 12
7.2. Receiving Binding Update . . . . . . . . . . . . . . . . 13
7.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 13
7.4. Receiving Binding Acknowledgment . . . . . . . . . . . . 14
7.5. IPv4 forwarding Setup . . . . . . . . . . . . . . . . . . 14
8. Applicability to Mobile IPv6 15
9. NAT Traversal 15
10. IANA Considerations 15
11. Security Considerations 16
12. Acknowledgements 16
R. Wakikawa et.al. [Page 2]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
1. Introduction
The Network Mobility basic support protocol (NEMO) [1] describes
the operation of Mobile Routers to enable session continuity for
all nodes in the Mobile Network. This protocol is specified only
for IPv6. There is some interest in deploying the NEMO protocol.
However, the current Internet is based on both IPv4 and IPv6
protocols and we cannot assume that IPv6 will be deployed everywhere
in the near future. To provide roaming for the Mobile Network, IPv6
support is required in wireless access networks. This is because
the Mobile IPv6 [2] and the NEMO Basic Support protocols are not IP
protocol independent. IPv6 was designed with integrated support for
Mobile IP as a native IPv6 feature. Also, the Mobile IPv6 and the
NEMO protocols are designed to use the rich feature set of IPv6;
hence, there exists a tight coupling of mobility signaling and IPv6
used in the media plane.
When a Mobile Router roams and connects to an IPv4 only access
network, it needs to be able to reach its Home Agent through the IPv4
network. The Mobile Router could use IPv6 transition mechanisms
[17] to reach the Home Agent. But this will result in a NEMO
bi-directional tunnel inside a transition tunnel. In the current
NEMO protocol all traffic from the Mobile Network is sent through the
bi-directional tunnel between the Mobile Router and the Home Agent.
This results in a high per-packet overhead.
If the Home Agent can support transition tunneling mechanisms in
addition to the Mobile IPv6 and NEMO functionality, then the tunnel
overhead can be reduced. The bi-directional tunnel between the
Mobile Router will serve as a transition tunnel in addition to
providing mobility for the Mobile Network. This document describes
extensions to the NEMO protocol to allow the Mobile Router and the
Home Agent to use an IPv6-over-IPv6 tunneling for the bi-directional
tunnel.
There is some earlier work related to IPv6 Mobile Nodes and Mobile
Routers roaming onto IPv4 access networks, "Dual Stack Mobile IPv6"
[10] and "Doors" [11].
The protocol extensions described in this document have the following
features.
- The ability to use a variety of tunnels between Mobile Router
and Home Agent. Possible tunnel types are IPv6-over-IPv4,
and IPv6-over-UDP-in-IPv4 for NAT traversal, ESP protected
IPv6-over-IPv4 tunnels, GRE tunneling, and UDP encapsulated ESP
protected IPv6-over-IPv4 tunnels.
R. Wakikawa et.al. [Page 3]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
- Reduced packet overhead because of the transition tunnel and the
NEMO bi-directional tunnel being the same.
- IPsec protection for the tunnels
- NAT Traversal
2. Terminology
Home Agent IPv4 Address
The global IPv4 address of the Home Agent. This
address should be reachable from the Mobile Router's IPv4
access network.
IPv4 Care-of Address
The Care-of address acquired by the Mobile Router,
through an address configuration mechanism such as DHCP,
when it attaches to an IPv4 access network.
IPv4 Forwarding
IPv4 forwarding for all Mobile Network Prefixes of
the basic NEMO protocol. The IPv4 forwarding is enabled
to reduce the tunnel overhead due to IPv6-in-IPv6 [4]
encapsulation of packets meant for the Mobile Network.
3. Protocol Overview
A Mobile Router, that implements the NEMO Basic Support protocol
[1] could roam and attach to different access networks. When the
Mobile Router attaches to an access link that implements only IPv4,
it acquires an IPv4 address for use on the link. It uses the IPv4
address as a Care-of address and sends a Binding Update to its Home
Agent. This binds the IPv4 Care-of address to the Mobile Router's
IPv6 Home Address. This operation is called IPv4 Care-of Address
Registration.
The Mobile Router needs to configured with the IPv4 address of the
Home Agent in addition to the IPv6 address of the Home Agent. In
this document we describe some extensions to the Dynamic Home Agent
Address Discovery messages, described in section 6, to carry the IPv4
address of the Home Agent in addition to the IPv6 address.
Whenever the Mobile Router moves into an IPv4 only access network,
it configures an IPv4 Care-of Address and sends an Binding Update
R. Wakikawa et.al. [Page 4]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
to the Home Agent to bind the IPv4 Care-of address to the IPv6 home
address. The IPv4 Care-of address is carried in the Binding Update
using a new mobility option, the IPv4 Care-of Address option (section
4.1). The Mobile Routers uses with IPv6-over-IPv4 encapsulation to
send the Binding Update to the Home Agent. The outer IP header is
an IPv4 header with the source address set to the Mobile Router's
IPv4 Care-of address and the destination address set to the Home
Agent IPv4 address. The inner IP header is an IPv6 header with
source address set to the Mobile Router's IPv6 home address and the
destination address set to the Home Agent's address. If the Home
Agent has an existing binding cache entry for the Mobile Router, it
updates the binding cache entry with the new IPv4 Care-of Address
instead of the IPv6 address. The Home Agent updates the forwarding
entries for the Mobile Network prefix to reflect the use of an with
IPv6-over-IPv4 tunnel instead of the IPv6-in-IPv6 tunnel.
This draft supports various kinds of tunneling methods such
as Generic IP-in-IP tunneling [12], GRE tunneling [13], IPsec
tunneling [14] [15], and IPv6 in UDP over IPv4 tunneling for private
IPv4 addresses. The Mobile Router indicates to the Home Agent which
tunneling method it wants to use through a flag in IPv4 Care-of
Address option. The Home Agent MUST include the IPv4 Care-of Address
option in the Binding Acknowledgement. If the Home Agent does not
support the tunneling method the Mobile Router requested, it sets
the Binding Acknowledgement status value to 144 (Tunneling method
not supported) and indicate through a flag which tunneling method it
supports.
Once the Mobile Router gets a success Binding Acknowledgement, it
starts using the with IPv6-over-IPv4 tunnel with its Home Agent to
tunnel all traffic from the Mobile Network to the Internet.
With using the protocol extensions described above, we avoid using a
NEMO tunnel inside a transition tunnel. The Home Agent itself serves
as a transition router.
4. Mobile IPv6 Extensions
4.1. IPv4 Care-of Address option
The IPv4 Care-of Address option is included in Binding Update and
Binding Acknowledgment.
R. Wakikawa et.al. [Page 5]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
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 | Length |
+-+-+-+-+-----------------------+-------------------------------+
|I|R|S|U| Reserved | Port Number |
+-+-+-+-+-----------------------+-------------------------------+
| IPv4 Care-of Address |
+---------------------------------------------------------------+
Type
TBA
Length
Eight-bit unsigned integer indicating the length of the
option in octets, excluding the type and length fields.
Set to 8.
Flags
Generic IP in IP Encapsulation tunnel (I) Flag
GRE tunnel (R) Flag
IPsec tunnel (S) Flag
UDP tunnel (U) Flag
Reserved
Set to 0 and ignored by the receiver.
Port Number
Sixteen-bit field to carry the port number used for UDP-IP
tunnel to traverse NAPT.
IPv4 Care-of Address
The IPv4 Care-of Address field contains the IPv4 Care-of
address of the mobile router.
4.2. Binding Update
If a mobile node wants to bind an IPv4 Care-of addresses to its
Home Address it includes the IPv4 Care-of Address Option in the
Binding Update. The source and destination address of the inner IPv6
header are set to the Home Address of the Mobile Router and the IPv6
R. Wakikawa et.al. [Page 6]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
address of the Home Agent respectively. The Binding Update is always
encapsulated in an IPv4 header with destination set to the Home Agent
IPv4 address. The lifetime in the Binding Update should be set to a
valid lifetime.
4.3. Binding Acknowledgment
If a Binding Update had contained the IPv4 Care-of address option,
the Home Agent MUST include the IPv4 Care-of address option in the
Binding Acknowledgement. If the requesting tunnel method is not
supported by a Home Agent, the Home Agent should reply with the
status code "Tunnel Method not supported". In such a case, the Home
Agent should set the flags that correspond to the tunneling methods
it supports in the IPv4 Care-of address option.
If the Home Agent that receives the Binding Update is a legacy Mobile
IPv6 Home Agent and does not understand the new IPv4 Care-of Address
option, it ignores the Binding Update. Some implementations treat
the Binding Update as a de-registration Binding Update since the
Binding Update appears as if it was sent from the home link. But
the Home Agent will not be able to send the Binding Acknowledgement
because the Mobile Router is not at home. In both cases, the
Mobile Router does not receive a Binding Acknowledgement from the
Home Agent. If the Mobile Router does not receive any Binding
Acknowledgements even after sending multiple Binding Updates, it
MUST consider the Home Agent as one that does not support transition
mechanisms and should stop sending Binding Updates with IPv4 Care-of
Address Option. Note that, if the Mobile Router uses the extended
DHAAD mechanism, described in section 6, it would be configured with
Home Agents that support the IPv4 Care-of Address option.
5. Securing the tunnel between the Mobile Router and the Home Agent
5.1. Packet Formats
This section assumes that the Mobile Router and the Home Agent are
using IPv6-over-IPv4 tunneling for the bi-directional tunnel between
them. The IPv6-over-IPv4 tunnel can be protected by ESP in tunnel
mode if required. The following packet formats must be supported by
the Mobile Router and the Home Agent.
For brevity, packet formats for other encapsulation methods are not
described here.
R. Wakikawa et.al. [Page 7]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
5.1.1. Binding Update and Binding Acknowledgement
When the Mobile Router sends a Binding Update from an visited link
that supports only IPv4, it should use the following packet format.
IPv4 header (source = IPv4 care-of address,
destination = IPv4 home agent address)
ESP header in tunnel mode
IPv6 header (source = IPv6 home address,
destination = IPv6 home agent address)
Mobility header
Binding Update
IPv4 Care-of Address option (IPv4 care-of address)
When the Home Agent sends a Binding Acknowledgement to the Mobile
Router, it should the following packet format.
IPv4 header (source = IPv4 home agent address,
destination = IPv4 care-of address)
ESP header in tunnel mode
IPv6 header (source = IPv6 home agent address,
destination = IPv6 home address)
Mobility header
Binding Acknowledgement
IPv4 Care-of Address option (IPv4 care-of address)
5.1.2. Mobile Prefix Discovery
When the Mobile Router sends a Mobile Prefix Solicitation message
from the IPv4 visited network, it should use the following packet
format.
IPv4 header (source = IPv4 care-of address,
destination = IPv4 home agent address)
ESP header in tunnel mode
IPv6 header (source = IPv6 home address,
destination = IPv6 home agent address)
ICMPv6 header
Mobile Prefix Solicitation
When the Home Agent sends a Mobile Prefix Advertisement to the Mobile
Router, it should use the following packet format.
IPv4 header (source = IPv4 home agent address,
destination = IPv4 care-of address)
ESP header in tunnel mode
IPv6 header (source = IPv6 home agent address,
destination = IPv6 home address)
R. Wakikawa et.al. [Page 8]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
ICMPv6 header
Mobile Prefix Advertisement
5.1.3. Mobile Network Traffic
The Mobile Router should use the following packet format to tunnel
all traffic from the Mobile Network to the Correspondent Nodes
through the Home Agent.
IPv4 header (source = IPv4 care-of address,
destination = IPv4 home agent address)
ESP header in tunnel mode
IPv6 header (source = IPv6 MNN,
destination = IPv6 CN)
Any payload
The Home Agent should use the following packet format to tunnel all
traffic meant for the Mobile Network to the Mobile Router's IPv4
Care-of Address.
IPv4 header (source = IPv4 home agent address,
destination = IPv4 care-of address)
ESP header in tunnel mode
IPv6 header (source = IPv6 CN,
destination = IPv6 MNN)
Any Payload
If ESP protection is not required, the Mobile Router and the Home
Agent should omit the ESP header.
5.2. IPsec Configuration
This section describes the security policy entries on the Mobile
Router and the Home Agent, assuming a dynamic key exchange protocol
like IKEv2 is used. This section assumes ESP in tunnel mode
protection is used for Binding Updates and Acknowledgements, Mobile
Prefix Discovery messages and the payload traffic between the nodes
in the Mobile Network and their CNs.
5.2.1. Binding Update and Acknowledgement
Mobile Router SPD OUT
- IF source = mr_hoa & destination = ha_ipv6
& proto = mh & mhtype = BU
Then use SA ESP Tunnel mode
R. Wakikawa et.al. [Page 9]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
outer src addr = mr_ipv4_coA
outer dst addr = ha_ipv4
Mobile Router SPD IN
- IF source = ha_ipv6 & destination = mr_hoa
& proto = mh & mhtype = BACK
Then use SA ESP Tunnel mode
outer src addr = ha_ipv4
outer dst addr = mr_ipv4_coa
Home Agent SPD OUT
- IF source = ha_ipv6 & destination = mr_hoa
& proto = mh & mhtype = BACK
Then use SA ESP Tunnel mode
outer src addr = ha_ipv4
outer dst addr = mr_ipv4_coa
Home Agent SPD IN
- IF source = mr_hoa & destination = ha_ipv6
& proto = mh & mhtype = BU
Then use SA ESP Tunnel mode
outer src addr = mr_ipv4_coa
outer dst addr = ha_ipv4
5.2.2. Mobile Prefix Discovery
Mobile Router SPD OUT
- IF source = mr_hoa & destination = ha_ipv6
& proto = icmpv6 & icmp_type = mps
Then use SA ESP Tunnel mode
outer src addr = mr_ipv4_coA
outer dst addr = ha_ipv4
Mobile Router SPD IN
- IF source = ha_ipv6 & destination = mr_hoa
& proto = icmpv6 & icmp_type = mpa
Then use SA ESP Tunnel mode
outer src addr = ha_ipv4
outer dst addr = mr_ipv4_coa
Home Agent SPD OUT
- IF source = ha_ipv6 & destination = mr_hoa
R. Wakikawa et.al. [Page 10]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
& proto = icmpv6 & icmp_type = mps
Then use SA ESP Tunnel mode
outer src addr = ha_ipv4
outer dst addr = mr_ipv4_coa
Home Agent SPD IN
- IF source = mr_hoa & destination = ha_ipv6
& proto = icmpv6 & icmp_type = mpa
Then use SA ESP Tunnel mode
outer src addr = mr_ipv4_coa
outer dst addr = ha_ipv4
5.2.3. Mobile Network Traffic
Mobile Router SPD OUT
- IF source = mnn & destination = cn_ipv6
& proto = any
Then use SA ESP Tunnel mode
outer src addr = mr_ipv4_coA
outer dst addr = ha_ipv4
Mobile Router SPD IN
- IF source = cn_ipv6 & destination = mnn
& proto = any
Then use SA ESP Tunnel mode
outer src addr = ha_ipv4
outer dst addr = mr_ipv4_coa
Home Agent SPD OUT
- IF source = mnn & destination = cn_ipv6
& proto = any
Then use SA ESP Tunnel mode
outer src addr = ha_ipv4
outer dst addr = mr_ipv4_coa
Home Agent SPD IN
- IF source = cn_ipv6 & destination = mnn
& proto = any
Then use SA ESP Tunnel mode
outer src addr = mr_ipv4_coa
outer dst addr = ha_ipv4
R. Wakikawa et.al. [Page 11]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
6. Home Agent IPv4 Address Discovery
A Mobile Router must acquire the Home Agent's IPv4 address in
addition to the IPv6 address. We extend the Dynamic Home Agent
Address Discovery (DHAAD) messages for the Mobile Router to acquire
the Home Agent's IPv4 address. A new flag 'I' in introduced in the
DHAAD request and reply messages. The Mobile Router sets the 'I'
flag in the DHAAD request if it wants to acquire the IPv4 address of
the Home Agent.
The Home Agent that processes the request must send a DHAAD reply.
The 'I' flag MUST be set and the IPv4 addresses of the Home Agents
must be present in the reply. Home Agents that do not have an IPv4
address configured do not reply to the DHAAD requests that have the
'I' flag set.
It is important for the Mobile Router to acquire Home Agents IPv4
addresses from IPv6 network, since the DHAAD mechanism relies on IPv6
anycast routing.
The Mobile Router maintains a list of Home Agents IPv4 addresses,
similar to the Home Agents IPv6 address list.
7. IPv4 Care-of Address Registration
7.1. Sending Binding Update
When a Mobile Router roams and attaches to an IPv4 only access
network, it does not have a valid IPv6 Care-of Address to bind to its
Home Address. It configures an IPv4 address from the visited network
and registers the address as the IPv4 Care-of address with the Home
Agent.
From the view of the Basic NEMO Protocol, this Binding Update is
treated as de-registration Binding Update. A Mobile Router include
an IPv4 Care-of Address option in the Binding Update and tunnels the
Binding Update to a Home Agent IPv4 address. Although the Mobile
Router sets its Home Address as the Source Address field of the
inner IPv6 header, it MUST set appropriate lifetime value to the
Lifetime filed of Binding Update. The Mobile Router MUST NOT set
zero lifetime for the IPv4 Care-of Address Binding Update.
The following options are required for IPv4 Care-of Address
registration
- IPv4 Care-of Address option
- Mobile Network Prefix option
R. Wakikawa et.al. [Page 12]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
7.2. Receiving Binding Update
If a Home Agent receives a Binding Update that does not contain an
IPv4 Care-of Address option, the processing of the Binding Update
is same as in [7] and [1]. If the Home Agent currently has setup
forwarding for the Mobile Network through an IPv4 tunnel, it must
delete that state and create a regular binding cache entry for the
Mobile Router. It must also setup forwarding for the Mobile Network
as described in [1].
If the Binding Update contains an IPv4 Care-of Address option, the
Home Agent should perform the following additional checks.
- If the Binding Update contains an IPv4 Care-of address option,
it should not contain an IPv6 Alt-CoA address option. If the
IPv6 Alt CoA option is present, the Home Agent must reject the
Binding Update and send a Binding Acknowledgement with status
'145' (Invalid Care-of Address).
- If the lifetime field of the Binding Update is set to zero, the
receiver MUST ignore the Binding Update. When the IPv4 Care-of
Address option is present, the lifetime field indicates the
lifetime value for IPv4 Care-of Address.
- If the requested tunnel type is not supported by the
receiver node, the Binding Update is discarded and a Binding
Acknowledgment with status 144 (Tunneling method not supported)
is sent to the Mobile Router.
Once the Binding Update is processed successfully, the Home Agent
sets up IPv4 forwarding for the Mobile Router's Home Address and
the Mobile Network Prefixes. The Home Agent also sends a Binding
Acknowledgment with the correspondent IPv4 Care-of Address option to
the Mobile Router.
7.3. Sending Binding Acknowledgment
Whenever a Home Agent sends a Binding Acknowledgment for IPv4 Care-of
Address registration, it MUST include the received IPv4 Care-of
Address option.
If the Home Agent does not support the tunneling method proposed
by the Mobile Router, it must set the status in the Binding
Aknowledgement to 144 (Tunneling method not supported) and set the
flags in the IPv4 Care-of Address option according to the tunneling
methods it supports. After receiving the Binding Acknowledgment, the
Mobile Router MAY again try to setup IPv4 forwarding according to
supported tunnel method.
R. Wakikawa et.al. [Page 13]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
7.4. Receiving Binding Acknowledgment
When the Mobile Router receives the Binding Acknowledgment, it
verifies whether it contains the IPv4 Care-of Address option. If the
option is not present, it can retry sending a Binding Update with
an IPv4 Care-of Address option. However, the Mobile Router SHOULD
stop sending the Binding Update at some point, because the Home Agent
might be a legacy Home Agent that does not support IPv4 Care-of
Address Registration.
Once a Mobile Router receives Binding Acknowledgment with a
successful status code, it creates an IPv6-over-IPv4 tunnel with its
Home Agent IPv4 address. The tunnel source address is a IPv4 Care-of
Address of Mobile Router and the tunnel destination address is a Home
Agent IPv4 address. All traffic originating in the Mobile Network is
routed to the tunnel with the Home Agent.
If a Mobile Router receives the status code 144 (Tunneling method not
supported), it should select a different tunneling mechanism based
on the flags in the received IPv4 Care-of address option and attempt
registering its IPv4 Care-of Address to the Home Agent again. If
the Mobile Router does not implement any of the tunneling mechanisms
the Home Agent supports, then the Mobile Router must stop trying to
register with the Home Agent.
7.5. IPv4 forwarding Setup
When a Home Agent processes a Binding Update successfully, it sets
up IPv4 forwarding according to the Flag field in the IPv4 Care-of
Address option.
There are several types of tunnel such as GRE tunnel, Generic
Encapsulation (IPv4-IPv4) tunnel, IPsec tunnel, UDP-IPv4 tunnel for
NAPT.
When IPsec tunnel is selected, the Home Agent MUST establish Security
Association with the Mobile Router. When UDP tunnel flag is set, the
Home Agent creates UDP-IPv4 tunnel with the specified port number in
the IPv4 Care-of Address option.
The Mobile Router also sets up IPv4 forwarding after accepting a
Binding Acknowledgment with success status code. The procedure to
setup IPv4 forwarding is same as Home Agent.
R. Wakikawa et.al. [Page 14]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
8. Applicability to Mobile IPv6
This mechanism can be applied to Mobile IPv6 as well. However,
Mobile IPv6 uses Proxy Neighbor Discovery for the Home Agents to
intercept packets meant for the mobile node. Therefore, after
de-registering the regular binding cache entry, the Home Agent still
defends the Home Address and intercepts packets meant for the Home
Address using Proxy Neighbor Discovery. The Home Agent then forwards
packets to Mobile Node's IPv4 Care-of Address by IPv4 forwarding.
For the Correspondent Node, the Mobile Node MUST de-register its
binding cache by sending a Binding Update via Home Agent. The Mobile
Node tunnels the CN Binding Update to Home Agent IPv4 address by
IPv4 forwarding and the Home Agent forwards the Binding Update to
the Correspondent Node. This means route optimization can not be
used while the Mobile Node is located on an IPv4 access network.
Future extensions to the Correspondent Node behavior and the Return
Routability mechanism can enable the Mobile Node to register an IPv4
Care-of address with the Correspondent Node directly.
9. NAT Traversal
If ESP tunnel mode is used to protect all traffic sent between
the Mobile Router and the Home Agent, through the bi-directional
IPv6-over-IPv4 tunnel, then UDP encapsulation of IPsec protected [16]
packets can be used to traverse a NAT box. No additional mechanism
needs to be defined in this document.
The Mobile IPv6 signaling messages, including Binding Updates,
Binding Acknowledgements, Mobile Prefix Discovery and Return
Routability signaling require IPsec protection. Using ESP tunnel
mode to protect this traffic when the traffic is sent through
the IPv6-in-IPv4 tunnel along with UDP encapsulation of the IPsec
protected traffic automatically provides NAT traversal.
If ESP tunnel mode protection is not used to protect the payload
traffic between the Mobile Network and the Correspondent Nodes, then
traffic must be sent by encapsulating the IPv6 packets in UDP over
IPv4.
10. IANA Considerations
This document defines a new Mobility Header option, the IPv4 Care-of
Address Option as described in section 4.1. The type value for this
option needs to be assigned from the same space used for the mobility
options defined in [2].
R. Wakikawa et.al. [Page 15]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
Two new Binding Acknowledgement status values need to assigned.
- 144 Tunneling method not supported
- 145 Invalid Care-of Address
11. Security Considerations
This document does not introduce any additional security
considerations from what is mentioned in NEMO Basic support [1] and
the Mobile IPv6 [2] specifications.
12. Acknowledgements
The authors would like to thank Keisuke Uehara and the members of the
WIDE project.
The authors would also like to thank Jari.T.Malinen, T.J.Kniveton,
Teemu Savolainen, Mika Joutsenvirta, and Rajeev Koodli for
interesting discussions on this topic.
Normative References
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"NEMO Basic Support Protocol", RFC 3963, January 2005.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the
revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-01.txt
(work in progress), February 2004.
[4] Conta, A., and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17.txt (work in progress), September
2004.
R. Wakikawa et.al. [Page 16]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
Informative References
[7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[8] Manner, J., and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[9] Ernst, T., and H.-Y. Lach. "Network Mobility Support
Terminology" draft-ietf-nemo-terminology-02.txt (work in
progress), October 2004.
[10] Soliman, H., and G. Tsirtsis, "Dual Stack Mobile IPv64",
draft-soliman-v4-v6-mipv4-01.txt (work in progress), October
2004.
[11] Thubert, P., et. al., "IPv4 traversal for MIPv6 based Mobile
Routers"", draft-thubert-nemo-ipv4-traversal-01.txt (work in
progress), May 2003.
[12] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[13] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[14] Kent, S., and K Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-05.txt (work in
progress), December 2004.
[15] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-09.txt (work in progress), September
2004.
[16] Huttunen, A., et. al., "UDP Encapsulation of IPsec Packets", RFC
3948, January 2005.
[17] Nordmark, E., and R. E. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt
(work in progress), September 2004.
R. Wakikawa et.al. [Page 17]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
Authors' Addresses
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252 JAPAN
EMail: ryuji@sfc.wide.ad.jp
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: vijay.devarapalli@nokia.com
Carl E. Williams
KDDI Labs USA
Palo Alto, CA 94301
USA
EMail: carlw@kddilabs.com
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.
R. Wakikawa et.al. [Page 18]
Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
R. Wakikawa et.al. [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 13:34:11 |