draft-ietf-mip6-nemo-v4traversal-02.txt   draft-ietf-mip6-nemo-v4traversal-03.txt 
MIP6 Working Group Hesham Soliman (Ed.) MIP6 Working Group Hesham Soliman (Ed.)
INTERNET-DRAFT George Tsirtsis INTERNET-DRAFT Qualcomm
Expires: December 2006 Qualcomm October, 2006
Vijay Deverapalli
Azaire Networks
James Kempf
Docomo Labs
Henrik Levkowetz
Ericsson
Pascal Thubert
Cisco
Ryuji Wakikawa
Keio University
June, 2006
Mobile IPv6 support for dual stack Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6) Hosts and Routers (DSMIPv6)
draft-ietf-mip6-nemo-v4traversal-02.txt draft-ietf-mip6-nemo-v4traversal-03.txt
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a submission of the IETF MIP6 WG. Comments should be This document is a submission of the IETF MIP6 WG. Comments should be
directed to the MIP6 WG mailing list, mip6@ietf.org. directed to the IPv6 WG mailing list, mip6@ietf.org.
Abstract Abstract
The current Mobile IPv6 and NEMO specification support only IPv6. The current Mobile IPv6 and NEMO specification support only IPv6.
Hence, this specification extends those standards to allow the Hence, this specification extends those standards to allow the
registration of IPv4 addresses and prefixes, respectively, and the registration of IPv4 addresses and prefixes, respectively, and the
transport of both IPv4 and IPv6 packets over the tunnel to the HA. transport of both IPv4 and IPv6 packets over the tunnel to the HA.
This specification allows also the Mobile Node to roam over both IPv6 This specification allows also the Mobile Node to roam over both IPv6
and IPv4, including the case where Network Address Translation is and IPv4, including the case where Network Address Translation is
present on the path. present on the path.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................2
skipping to change at page 2, line 22 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................2
1.1 Motivation for using Mobile IPv6 only...........................3 1.1 Motivation for using Mobile IPv6 only...........................3
1.2 Scenarios considered by this specification...................4 1.2 Scenarios considered by this specification...................4
2. Solution overview................................................5 2. Solution overview................................................5
2.1. Home Agent Address Discovery...................................5 2.1. Home Agent Address Discovery...................................5
2.2. Mobile Prefix Solicitations and Advertisements..............6 2.2. Mobile Prefix Solicitations and Advertisements..............6
2.3. Binding management.............................................6 2.3. Binding management.............................................6
2.3.1 Foreign network supports IPv6.................................7 2.3.1 Foreign network supports IPv6.................................7
2.3.2 Foreign network supports IPv4 only............................8 2.3.2 Foreign network supports IPv4 only............................7
2.3.2.1 Visited network supports IPv4 only (private addresses)......9 2.3.2.1 Visited network supports IPv4 only (private addresses)......8
2.4. Route optimization.............................................9 2.4. Route optimization.............................................9
2.5. Dynamic IPv4 home address allocation..........................10 2.5. Dynamic IPv4 home address allocation..........................10
3. Extensions and modifications to Mobile IPv6.....................10 3. Extensions and modifications to Mobile IPv6.....................10
3.1. Binding update extensions.....................................10 3.1. Binding update extensions.....................................10
3.1.1 IPv4 home address option.....................................10 3.1.1 IPv4 home address option.....................................10
3.2. Binding acknowledgement extensions............................11 3.2. Binding acknowledgement extensions............................11
3.2.1 IPv4 address acknowledgement option..........................11 3.2.1 IPv4 address acknowledgement option..........................11
3.2.2 The NAT detection option...............................12 3.2.2 The NAT detection option...............................12
4. Protocol operation..............................................13 4. Protocol operation..............................................13
4.1. NAT detection and traversal................................13 4.1. NAT detection and traversal................................13
skipping to change at page 10, line 37 skipping to change at page 10, line 32
This section highlights the protocol and implementation additions This section highlights the protocol and implementation additions
required to support this specification. required to support this specification.
3.1. Binding update extensions 3.1. Binding update extensions
3.1.1 IPv4 home address option 3.1.1 IPv4 home address option
This option is included in the Mobility Header including the binding This option is included in the Mobility Header including the binding
update message sent from the mobile node to a home agent or Mobility update message sent from the mobile node to a home agent or Mobility
Anchor Point. Anchor Point. The alignment requirement for this option is 4n.
0 1 2 3 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 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 |Pref |P|Res| | Type | Length |Pref |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 1 Length 6
Pref The length of the prefix allocated to the mobile Pref The length of the prefix allocated to the mobile
node. If only a single address is allocated, node. If only a single address is allocated,
this field MUST be set to 32. In the first this field MUST be set to 32. In the first
binding update requesting a prefix, the field binding update requesting a prefix, the field
contains the prefix length requested. However, contains the prefix length requested. However,
in the following binding updates, this field in the following binding updates, this field
must contain the length of the prefix allocated. must contain the length of the prefix allocated.
skipping to change at page 11, line 45 skipping to change at page 11, line 39
3.2. Binding acknowledgement extensions 3.2. Binding acknowledgement extensions
3.2.1 IPv4 address acknowledgement option 3.2.1 IPv4 address acknowledgement option
This option is included in the Mobility Header including the binding This option is included in the Mobility Header including the binding
acknowledgement message sent from the home agent or Mobility Anchor acknowledgement message sent from the home agent or Mobility Anchor
Point to the mobile node. This option indicates whether a binding Point to the mobile node. This option indicates whether a binding
cache entry was created for the mobile node's IPv4 address. cache entry was created for the mobile node's IPv4 address.
Additionally, this option can include an IPv4 home address in the Additionally, this option can include an IPv4 home address in the
case of Dynamic IPv4 home address configuration (i.e. if the case of Dynamic IPv4 home address configuration (i.e. if the
unspecified IPv4 address was included in the binding update). unspecified IPv4 address was included in the binding update). The
alignment requirement for this option is 4n.
0 1 2 3 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 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 | Status | Pref | Res | | Type | Length | Status | Pref | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 1 Length 6
Status Indicates success or failure for the IPv4 home Status Indicates success or failure for the IPv4 home
address binding. Values from 0 to 127 indicate address binding. Values from 0 to 127 indicate
success. Higher values indicate failure. The success. Higher values indicate failure. The
following values are reserved: following values are reserved:
0 Success 0 Success
128 Failure, reason unspecified 128 Failure, reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Incorrect IPv4 home address 130 Incorrect IPv4 home address
131 Invalid IPv4 address 131 Invalid IPv4 address
skipping to change at page 12, line 47 skipping to change at page 12, line 42
home agent will add the address to inform the home agent will add the address to inform the
mobile node. Otherwise, if the address were mobile node. Otherwise, if the address were
statically allocated to the mobile node, the statically allocated to the mobile node, the
home agent will copy it from the binding update home agent will copy it from the binding update
message. message.
3.2.2 The NAT detection option 3.2.2 The NAT detection option
This option is sent from the home agent to the mobile node to This option is sent from the home agent to the mobile node to
indicate whether a NAT was in the path. This option MAY also include indicate whether a NAT was in the path. This option MAY also include
a suggested NAT binding refresh time for the mobile node. a suggested NAT binding refresh time for the mobile node. The
alignment requirement for this option is 4n.
0 1 2 3 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 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 |F| Reserved | | Type | Length |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh time | | Refresh time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 6
Length 1
F This flag indicates to the mobile node that UDP F This flag indicates to the mobile node that UDP
encapsulation is required. When set, this flag encapsulation is required. When set, this flag
indicates that the mobile node MUST use UDP indicates that the mobile node MUST use UDP
encapsulation even if a NAT is not located encapsulation even if a NAT is not located
between the mobile node and home agent. between the mobile node and home agent.
Reserved This field is reserved for future use. It MUST Reserved This field is reserved for future use. It MUST
be set to zero by the sender and ignored by the be set to zero by the sender and ignored by the
receiver. receiver.
skipping to change at page 18, line 48 skipping to change at page 18, line 44
- If the IPv4 home address option contained the unspecified IPv4 - If the IPv4 home address option contained the unspecified IPv4
address, the home agent SHOULD dynamically allocate an IPv4 home address, the home agent SHOULD dynamically allocate an IPv4 home
address to the mobile node. If none is available, the home agent address to the mobile node. If none is available, the home agent
MUST return an appropriate error code in the status field of the MUST return an appropriate error code in the status field of the
IPv4 address acknowledgement option. If a prefix were requested, IPv4 address acknowledgement option. If a prefix were requested,
the home agent MUST allocate a prefix with the requested length; the home agent MUST allocate a prefix with the requested length;
otherwise the home agent MUST indicate failure of the operation otherwise the home agent MUST indicate failure of the operation
with the appropriate error code. with the appropriate error code.
- If the binding update is accepted for the IPv4 home address, the - If the binding update is accepted for the IPv4 home address, the
home agent MUST create a binding cache entry for the IPv4 home home agent creates a binding cache entry for the IPv4 home
address/prefix. If a single IPv4 home address were requested, it address/prefix. If a single IPv4 home address were requested, it
MAY be stored in the IPv4-mapped IPv6 address format. The home MAY be stored in the IPv4-mapped IPv6 address format. The home
agent MUST include an IPv4 acknowledgement option in the mobility agent MUST include an IPv4 acknowledgement option in the mobility
header containing the binding acknowledgement. header containing the binding acknowledgement.
If the binding update is accepted for both IPv4 and IPv6 home If the binding update is accepted for both IPv4 and IPv6 home
addresses, the home agent MUST create two separate binding cache addresses, the home agent creates separate binding cache entries, one
entries, one for each home address. The care-of address is the one for each home address. The care-of address is the one included in the
included in the binding update. If the care-of address is an IPv4- binding update. If the care-of address is an IPv4-mapped IPv6
mapped IPv6 address, the home agent MUST setup a tunnel to the IPv4 address, the home agent MUST setup a tunnel to the IPv4 care-of
care-of address of the mobile node. address of the mobile node.
When sending a binding acknowledgement to the mobile node, the home When sending a binding acknowledgement to the mobile node, the home
agent would construct the message according to [MIPv6] and [NEMO]. agent would construct the message according to [MIPv6] and [NEMO].
Note that the routing header MUST always contain the IPv6 home Note that the routing header MUST always contain the IPv6 home
address as specified in [MIPv6]. address as specified in [MIPv6].
If the care-of address of the mobile node were an IPv4 address, the If the care-of address of the mobile node were an IPv4 address, the
home agent MUST include this address in the destination address in home agent MUST include this address in the destination address in
the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were
detected, the home agent MUST then encapsulate the packet in UDP and detected, the home agent MUST then encapsulate the packet in UDP and
skipping to change at page 21, line 47 skipping to change at page 21, line 44
January 2005. January 2005.
[SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protoect Mobile IPv6 Signaling between Mobile Nodes and Home Protoect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6
in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops-
mip-scenarios-01.txt, February 2004. mip-scenarios-01.txt, February 2004.
Authors' Addresses Author's Address
Hesham Soliman Hesham Soliman
Qualcomm-Flarion Technologies Qualcomm-Flarion Technologies
E-mail: Hesham@Qualcomm.com E-mail: Hesham@Qualcomm.com
Additional Authors
George Tsirtsis George Tsirtsis
Qualcomm-Flarion Technologies Qualcomm-Flarion Technologies
Phone: +1 908 947 7059 Phone: +1 908 947 7059
E-mail1: G.Tsirtsis@Qualcomm.com E-mail1: G.Tsirtsis@Qualcomm.com
E-mail2: tsirtsisg@yahoo.com E-mail2: tsirtsisg@yahoo.com
Vijay Devarapalli Vijay Devarapalli
E-mail: vijay.devarapalli@nokia.com E-mail: vijay.devarapalli@nokia.com
James Kempf James Kempf
skipping to change at page 23, line 42 skipping to change at page 23, line 42
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires December, 2006. This Internet-Draft expires April, 2006.
 End of changes. 19 change blocks. 
37 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/