< draft-ietf-mip6-nemo-v4traversal-05.txt   draft-ietf-mip6-nemo-v4traversal-06.txt >
MIP6 Working Group Hesham Soliman (Ed.) MIP6 Working Group Hesham Soliman (Ed.)
INTERNET-DRAFT Elevate Technologies INTERNET-DRAFT Elevate Technologies
Expires: January 2008 Expires: May 2008
July, 2007 November, 2007
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-05.txt draft-ietf-mip6-nemo-v4traversal-06.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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.3.2.2 Visited network supports IPv4 only (private addresses)......9 2.3.2.2 Visited network supports IPv4 only (private addresses)......9
2.4. Route optimization............................................10 2.4. Route optimization............................................10
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.1.2 The IPv4 Care-of Address option........................11 3.1.2 The IPv4 Care-of Address option........................11
3.1.3 The Binding Update Message extensions..................12 3.1.3 The Binding Update Message extensions..................12
3.2. Binding Acknowledgement extensions............................12 3.2. Binding Acknowledgement extensions............................12
3.2.1 IPv4 address acknowledgement option..........................12 3.2.1 IPv4 address acknowledgement option..........................12
3.2.2 The NAT detection option...............................13 3.2.2 The NAT detection option...............................14
3.2.3 Extensions to the Binding Acknowledgement message......14 3.2.3 Extensions to the Binding Acknowledgement message......14
4. Protocol operation..............................................14 4. Protocol operation..............................................15
4.1. Tunnelling formats.........................................15 4.1. Tunnelling formats.........................................15
4.2. NAT detection and traversal................................16 4.2. NAT detection and traversal................................16
4.3. NAT Keepalives.............................................18 4.3. NAT Keepalives.............................................18
4.4. Mobile node operation.........................................18 4.4. Mobile node operation.........................................19
4.4.1 Sending packets from a visited network.................20 4.4.1 Sending packets from a visited network.................20
4.4.2 Movement detection in IPv4-only networks...............20 4.4.2 Movement detection in IPv4-only networks...............21
4.5. Home agent operations.........................................21 4.5. Home agent operations.........................................21
4.5.1 Sending packets to the mobile node.....................22 4.5.1 Sending packets to the mobile node.....................23
4.6. Correspondent node operations.................................23 4.6. Correspondent node operations.................................23
5. Security considerations.........................................23 5. Security considerations.........................................23
6. Protocol constants..............................................24 5.1 Handover interactions for IPsec and IKE.....................24
7. Acknowledgements................................................24 6. Protocol constants..............................................25
8. IANA considerations.............................................24 7. Acknowledgements................................................25
9. References......................................................24 8. IANA considerations.............................................26
10. Contributors...................................................25 9. References......................................................26
Author's Address...................................................26 10. Contributors...................................................27
Author's Address...................................................27
1. Introduction 1. Introduction
Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the
Internet while maintaining reachability and ongoing sessions, using Internet while maintaining reachability and ongoing sessions, using
an IPv6 home address or prefix. However, since IPv6 is not widely an IPv6 home address or prefix. However, since IPv6 is not widely
deployed, it is unlikely that mobile nodes will use IPv6 addresses deployed, it is unlikely that mobile nodes will use IPv6 addresses
only for their connections. It is reasonable to assume that mobile only for their connections. It is reasonable to assume that mobile
nodes will, for a long time, need an IPv4 home address that can be nodes will, for a long time, need an IPv4 home address that can be
used by upper layers. It is also reasonable to assume that mobile used by upper layers. It is also reasonable to assume that mobile
nodes will move to networks that might not support IPv6 and would nodes will move to networks that might not support IPv6 and would
therefore need the capability to support an IPv4 Care-of Address. therefore need the capability to support an IPv4 Care-of Address.
Hence, this specification extends Mobile IPv6 capabilities to allow Hence, this specification extends Mobile IPv6 capabilities to allow
dual stack mobile nodes to request that their home agent (also dual dual stack mobile nodes to request that their home agent (also dual
stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, stacked) tunnel IPv4/IPv6 packets addressed to their home addresses,
to their IPv4/IPv6 care-of address(es). as well as IPv4/IPv6 care-of address(es).
Using this specification, mobile nodes would only need Mobile IPv6 Using this specification, mobile nodes would only need Mobile IPv6
and [NEMO] to manage mobility while moving within the Internet; hence and [NEMO] to manage mobility while moving within the Internet; hence
eliminating the need to run two mobility management protocols eliminating the need to run two mobility management protocols
simultaneously. This specification provides the extensions needed in simultaneously. This specification provides the extensions needed in
order to allow Mobile IPv6 only to be used by dual sack mobile nodes. order to allow IPv6 mobility only to be used by dual stack mobile
nodes.
This specification will also consider cases where a mobile node moves This specification will also consider cases where a mobile node moves
into a private IPv4 network and gets configured with a private IPv4 into a private IPv4 network and gets configured with a private IPv4
Care-of Address. In those scenarios, the mobile node needs to be able Care-of Address. In those scenarios, the mobile node needs to be able
to traverse the IPv4 NAT in order to communicate with the Home Agent. to traverse the IPv4 NAT in order to communicate with the Home Agent.
IPv4 NAT traversal for Mobile IPv6 is presented in this IPv4 NAT traversal for Mobile IPv6 is presented in this
specification. specification.
In this specification, the term mobile node refers to both a mobile In this specification, the term mobile node refers to both a mobile
host and mobile router unless the discussion is specific to either host and mobile router unless the discussion is specific to either
skipping to change at page 9, line 10 skipping to change at page 9, line 14
mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in
an IPv4 header that includes the home agent's IPv4 address in the an IPv4 header that includes the home agent's IPv4 address in the
source address field and the mobile node's IPv4 care-of address in source address field and the mobile node's IPv4 care-of address in
the destination address field. the destination address field.
After accepting the binding updates and creating the corresponding After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as entries, the home agent MUST send a binding acknowledgement as
specified in [MIPv6]. In addition, if the binding update included an specified in [MIPv6]. In addition, if the binding update included an
IPv4 home address option, the binding acknowledgement MUST include IPv4 home address option, the binding acknowledgement MUST include
the IPv4 address acknowledgment option as described later in this the IPv4 address acknowledgment option as described later in this
specification. The binding update is encapsulated to the IPv4 care-of specification. The binding acknowledgement is encapsulated to the
address (represented as an IPv4-mapped IPv6 address in the binding IPv4 care-of address.
update).
2.3.2.2 Visited network supports IPv4 only (private addresses) 2.3.2.2 Visited network supports IPv4 only (private addresses)
In this scenario the mobile node will need to tunnel IPv6 packets In this scenario the mobile node will need to tunnel IPv6 packets
containing the binding update to the home agent's IPv4 address. In containing the binding update to the home agent's IPv4 address. In
order to traverse the NAT device, IPv6 packets are tunneled UDP and order to traverse the NAT device, IPv6 packets are tunneled UDP and
IPv4. The UDP port allocated for the home agent is TBD. IPv4. The UDP port allocated for the home agent is TBD.
The mobile node uses the IPv4 address it gets from the visited The mobile node uses the IPv4 address it gets from the visited
network as a source address in the IPv4 header. The binding update network as a source address in the IPv4 header. The binding update
will contain the mobile node's IPv6 home address. will contain the mobile node's IPv6 home address.
After accepting the binding update, the home agent MUST create a new After accepting the binding update, the home agent MUST create a new
binding cache entry for the mobile node's IPv6 home address. If an binding cache entry for the mobile node's IPv6 home address. If an
IPv4 home address option were included, the home agent MUST create IPv4 home address option were included, the home agent MUST create
another entry for that address. All entries MUST point to the mobile another entry for that address. All entries MUST point to the mobile
node's IPv4 care-of address included in the source address of the node's IPv4 care-of address included in the binding update message.
IPv6 packet and represented as an IPv4-mapped IPv6 address. In In addition, the tunnel used MUST indicate UDP encapsulation for NAT
addition, the tunnel used MUST indicate UDP encapsulation for NAT
traversal. Hence, all packets addressed to the mobile node's home traversal. Hence, all packets addressed to the mobile node's home
address(es) (IPv4 or IPv6) will be encapsulated in UDP then address(es) (IPv4 or IPv6) will be encapsulated in UDP then
encapsulated in an IPv4 header that includes the home agent's IPv4 encapsulated in an IPv4 header that includes the home agent's IPv4
address in the source address field and the mobile node's IPv4 care- address in the source address field and the mobile node's IPv4 care-
of address in the destination address field. of address in the destination address field.
After accepting the binding updates and creating the corresponding After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as entries, the home agent MUST send a binding acknowledgement as
specified in [MIPv6]. In addition, if the binding update included an specified in [MIPv6]. In addition, if the binding update included an
IPv4 home address option, the binding acknowledgement MUST include IPv4 home address option, the binding acknowledgement MUST include
skipping to change at page 11, line 4 skipping to change at page 11, line 8
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| Reserved | | Type | Length |Pref |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 6 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.
A value of zero is invalid and MUST be
considered an error.
P A flag indicating, when set, that the mobile P A flag indicating, when set, that the mobile
node requests a mobile network prefix. This flag node requests a mobile network prefix. This flag
is only relevant for new requests, and must be is only relevant for new requests, and must be
ignored for binding refreshes. ignored for binding refreshes.
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 13, line 51 skipping to change at page 14, line 12
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. The a suggested NAT binding refresh time for the mobile node. The
alignment requirement for this option is 4n. alignment requirement for this option is 4n. If a NAT is detected,
this option MUST be sent by the home agent.
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
skipping to change at page 18, line 14 skipping to change at page 18, line 20
Where V4ADDR is either the IPv4 care-of address or the address Where V4ADDR is either the IPv4 care-of address or the address
provided by the NAT device. V6HOA is the IPv6 home address of the provided by the NAT device. V6HOA is the IPv6 home address of the
mobile node. The binding update MAY also contain the IPv4 home mobile node. The binding update MAY also contain the IPv4 home
address option IPv4 HAO. address option IPv4 HAO.
B. Binding acknowledgement sent by the home agent: B. Binding acknowledgement sent by the home agent:
IPv4 header (src= HA_V4ADDR, dst=V4ADDR) IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
UDP header UDP header
IPv6 header (src=HAADDR, dst=V6HOA) IPv6 header (src=HAADDR, dst=V6HOA)
Route HDR Type 2
V6HOA (IPv6 home address) V6HOA (IPv6 home address)
Mobility header Mobility header
BA ([IPv4 ACK], NAT DET) BA ([IPv4 ACK], NAT DET)
Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is
the IPv4 address acknowledgement option, which is only included if the IPv4 address acknowledgement option, which is only included if
the IPv4 home address option were present in the BU. The NAT DET is the IPv4 home address option were present in the BU. The NAT DET is
the NAT detection option, which MUST be present in the binding the NAT detection option, which MUST be present in the binding
acknowledgement message if the binding update was encapsulated in acknowledgement message if the binding update was encapsulated in
UDP. UDP.
skipping to change at page 21, line 49 skipping to change at page 22, line 5
- If the IPv4 care-of address in the IPv4 CoA option is not the same - If the IPv4 care-of address in the IPv4 CoA option is not the same
as the IPv4 address in the source address in the IPv4 header then as the IPv4 address in the source address in the IPv4 header then
a NAT was in the path. This information should be flagged for the a NAT was in the path. This information should be flagged for the
binding acknowledgement. binding acknowledgement.
- If the F flag in the binding update were set, the home agent needs - If the F flag in the binding update were set, the home agent needs
to determine whether it accepts forcing UDP encapsulation. If it to determine whether it accepts forcing UDP encapsulation. If it
does not, the binding acknowledgement is sent with error code 144. does not, the binding acknowledgement is sent with error code 144.
UDP encapsulation MUST NOT be used when the mobile node is located
in an IPv6-enabled link.
- If the T flag was set in the binding update, the home agent needs - If the T flag was set in the binding update, the home agent needs
to determine whether it can accept the TLV-header encapsulation to determine whether it can accept the TLV-header encapsulation
format. If it does, it should set the T flag in the binding format. If it does, it should set the T flag in the binding
acknowledgement. Otherwise, the home agent MUST NOT set the T flag acknowledgement. Otherwise, the home agent MUST NOT set the T flag
in the binding acknowledgement. in the binding acknowledgement.
- If the IPv4 home address option contains a valid unicast IPv4 - If the IPv4 home address option contains a valid unicast IPv4
address, the home agent MUST check that this address is allocated address, the home agent MUST check that this address is allocated
to the mobile node that has the IPv6 home address included in the to the mobile node that has the IPv6 home address included in the
home address option. The same MUST be done for an IPv4 prefix. home address option. The same MUST be done for an IPv4 prefix.
skipping to change at page 23, line 13 skipping to change at page 23, line 22
IPv6 packets to mobile nodes located in IPv6 networks. When sending IPv6 packets to mobile nodes located in IPv6 networks. When sending
IPv4 packets to When mobile nodes in an IPv6 network, the home agent IPv4 packets to When mobile nodes in an IPv6 network, the home agent
must encapsulate the IPv4 packets in IPv6. must encapsulate the IPv4 packets in IPv6.
When sending IPv6 packets to a mobile node located in an IPv4 When sending IPv6 packets to a mobile node located in an IPv4
network, the home agent must follow the format negotiated in the network, the home agent must follow the format negotiated in the
binding update/acknowledgement exchange. In the absence of a binding update/acknowledgement exchange. In the absence of a
negotiated format, the default format that MUST be supported by all negotiated format, the default format that MUST be supported by all
implementations is: implementations is:
IPv4 header (src= HA_V4ADDR, dst= V4CoA) IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
[UDP header] [UDP header]
IPv6 header (src=CN, dst= V6HoA) IPv6 header (src=CN, dst= V6HoA)
Upper layer protocols Upper layer protocols
Where the UDP header is only included if a NAT were detected between Where the UDP header is only included if a NAT were detected between
the mobile node and the home agent, or if the home agent forced UDP the mobile node and the home agent, or if the home agent forced UDP
encapsulation. encapsulation. V4ADDR is the IPv4 address received in the source
address field of the IPv4 packet containing the binding update.
When sending IPv4 packets to a mobile node located in an IPv4 When sending IPv4 packets to a mobile node located in an IPv4
network, the home agent must follow the format negotiated in the network, the home agent must follow the format negotiated in the
binding update/acknowledgement exchange. In the absence of a binding update/acknowledgement exchange. In the absence of a
negotiated format, the default format that MUST be supported by all negotiated format, the default format that MUST be supported by all
implementations is: implementations is:
IPv4 header (src= HA_V4ADDR, dst= V4CoA) IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
[UDP header] [UDP header]
IPv4 header (src=V4CN, dst= V4HoA) IPv4 header (src=V4CN, dst= V4HoA)
Upper layer protocols Upper layer protocols
Where the UDP header is only included if a NAT were detected between Where the UDP header is only included if a NAT were detected between
the mobile node and home agent, or if the home agent forced UDP the mobile node and home agent, or if the home agent forced UDP
encapsulation. encapsulation.
4.6. Correspondent node operations 4.6. Correspondent node operations
skipping to change at page 24, line 24 skipping to change at page 24, line 34
important to note that it has the same UNSAF vulnerabilities important to note that it has the same UNSAF vulnerabilities
associated with RFC 3519. An attacker is able to hijack the mobile associated with RFC 3519. An attacker is able to hijack the mobile
node's session with the home agent if it can modify the contents of node's session with the home agent if it can modify the contents of
the outer IPv4 header. The contents of the header are not the outer IPv4 header. The contents of the header are not
authenticated and there is no way for the home agent to verify their authenticated and there is no way for the home agent to verify their
validity. Hence, a man in the middle attack where a change in the validity. Hence, a man in the middle attack where a change in the
contents of the IPv4 header can cause a legitimate mobile node's contents of the IPv4 header can cause a legitimate mobile node's
traffic to be diverted to an illegitimate receiver independently of traffic to be diverted to an illegitimate receiver independently of
the authenticity of the binding update message. the authenticity of the binding update message.
In this specification the binding update message MUST be protected
using ESP transport mode. When the mobile node is located in an IPv4-
only network, the binding update message is encapsulated in UDP as
described earlier. However, UDP MUST NOT be used to encapsulate the
binding update message when the mobile node is located in an IPv6-
enabled network. If protection of payload traffic is needed when the
mobile node is located in an IPv4-only network, encapsulation is done
using tunnel mode ESP over port 4500 as described in [TUNSEC].
Handovers within private IPv4 networks or from IPv6 to IPv4 networks
will have impacts on the security association between the mobile node
and the home agent. The following section presents the expected
behaviour of the mobile node and home agent in those situations.
5.1 Handover interactions for IPsec and IKE
After the mobile node detects movement it updates its tunnel
information depending on the network capability. If the new link is
IPv4-only then the mobile node updates its tunnel to UDP using the
DSMIPv6 port and the local IPv4 address. Furthermore, the mobile node
updates its local Security Association information to include its
local IPv4 address and with the remote address being the home agent's
IPv4 address. The mobile node also removes binding update list
entries for correspondent nodes since route optimisation cannot be
supported while the mobile node is in an IPv4-only network. This may
cause inbound packet losses as remote correspondent node are unaware
of such movement. Following this, the mobile node sends the binding
update message to the home agent.
Upon receiving the binding update message, the home agent updates it
security association locally to include the mobile node's remote
address as the IP address received in the outer header. When the
mobile node is located in a private IPv4 network (which is detected
as described above), this address is the public address allocated by
the NAT. Based on the setting of the K flag in the binding update,
the home agent updates its IKE security association to include the
remote address as that received in the outer header of the binding
update message. If the mobile node were located in a private IPv4
network this address is likely to be wrong as the NAT would likely
allocate a different address to the IKE messages. Hence, the mobile
node MUST update the IKE SA in one of two ways as follows. The mobile
node SHOULD send an empty informational message, which results in the
IKE module in the home agent to dynamically update the SA
information. Alternatively, the IKE SA should be re-negotiated. Note
that updating the IKE SA MUST take place after the mobile node has
sent the binding update and received the acknowledgement from the
home agent.
The mobile node MAY use [MOBIKE] to update its IKE SA with the home
agent. Using MOBIKE requires negotiating this capability with the
home agent when establishing the SA. In this case, the mobile node
and the home agent need not update their IPsec SAs locally as this
step is performed by MOBIKE. Furthermore, the use of MOBIKE allows
the mobile node to update the SA independently of the binding update
exchange. Hence, there is no need for the mobile node to wait for a
binding acknowledgement before performing MOBIKE. The use of MOBIKE
is OPTIONAL in this specification.
6. Protocol constants 6. Protocol constants
NATKATIMEOUT 110 seconds NATKATIMEOUT 110 seconds
7. Acknowledgements 7. Acknowledgements
Thanks to the following members (in alphabetical order) of the MIP6 Thanks to the following members (in alphabetical order) of the MIP6
and NEMO Working Groups for their contributions, discussion, and and NEMO Working Groups for their contributions, discussion, and
review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson,
Ahmad Muhanna, Vidya Narayanan, Karen Neilsen and Keiichi Shima. Ahmad Muhanna, Vidya Narayanan, Karen Neilsen and Keiichi Shima.
Thanks to Karen Neilsen, Pasi Eronen and Christian Kaas-Petersen for
raising the issue of IKEv2 interactions and proposing the solution
included in this document.
8. IANA considerations 8. IANA considerations
The specification requires the following allocations from IANA: The specification requires the following allocations from IANA:
- A UDP port is needed for the NAT traversal mechanism described in - A UDP port is needed for the NAT traversal mechanism described in
section 4.1. section 4.1.
- The IPv4 home address option described in section 3.1.1 requires an - The IPv4 home address option described in section 3.1.1 requires an
option type. This option is included in the Mobility header option type. This option is included in the Mobility header
described in [MIPv6]. described in [MIPv6].
- The IPv4 address acknowledgement option described in section 3.2.1 - The IPv4 address acknowledgement option described in section 3.2.1
skipping to change at page 25, line 5 skipping to change at page 26, line 25
header described in [MIPv6]. header described in [MIPv6].
- The NAT detection option described in section 3.2.2 requires a new - The NAT detection option described in section 3.2.2 requires a new
option type. This option is included in the Mobility header option type. This option is included in the Mobility header
described in [MIPv6]. described in [MIPv6].
- The IPv4 Care-of address option described in section 3.1.2 requires - The IPv4 Care-of address option described in section 3.1.2 requires
an option type. This option is included in the Mobility header an option type. This option is included in the Mobility header
described in [MIPv6]. described in [MIPv6].
9. References 9. References
NORMATIVE
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6)
specification", RFC 2460
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support protocol", RFC 3963,
January 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[TUNSEC] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M.
Stenberg, "UPD Encapsulation for IPsec ESP Packets", RFC
3948, January 2005.
INFORMATIVE
[BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile
IPv6 bootstrapping in split scenario", draft-ietf-mip6- IPv6 bootstrapping in split scenario", draft-ietf-mip6-
bootstrapping-split, June 2005, work in progress. bootstrapping-split, June 2005, work in progress.
[HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
RFC 4140, August 2005. Draftietf-mipshop-4140bis-04 November 2007.
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6)
specification", RFC 2460
[INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the [INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", draft-ietf-mip6-bootstrapping- Integrated Scenario", draft-ietf-mip6-bootstrapping-
integrated-dhc-02, Work in Progress. integrated-dhc-02, Work in Progress.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for
Dual stack mobile nodes, A Problem Statement", Dual stack mobile nodes, A Problem Statement",
draft-ietf-mip6-dsmip-problem-01.txt, July 2005. RFC 4977, August 2007.
[MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in [MOBIKE] P. Eronen,"IKEv2 Mobility and Multihoming Protocol (MOBIKE)"
IPv6", RFC 3775, June 2004. , RFC 4555, June 2006.
[NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support protocol", RFC 3963,
January 2005.
[SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protoect Mobile IPv6 Signaling between Mobile Nodes and Home
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.
10. Contributors 10. Contributors
This document reflects discussions and contributions from several This document reflects discussions and contributions from several
people including (in alphabetical order): people including (in alphabetical order):
skipping to change at page 27, line 4 skipping to change at page 28, line 36
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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 January, 2008. This Internet-Draft expires May, 2008.
 End of changes. 30 change blocks. 
46 lines changed or deleted 125 lines changed or added

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