draft-ietf-monami6-multiplecoa-11.txt   draft-ietf-monami6-multiplecoa-12.txt 
MEXT Working Group R. Wakikawa (Ed.) MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Toyota ITC/Keio Univ. Internet-Draft Toyota ITC/Keio Univ.
Intended status: Standards Track V. Devarapalli (Ed.) Intended status: Standards Track V. Devarapalli (Ed.)
Expires: July 17, 2009 Wichorus Expires: September 7, 2009 Wichorus
T. Ernst T. Ernst
INRIA INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
January 13, 2009 March 6, 2009
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-11.txt draft-ietf-monami6-multiplecoa-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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 to cite them other than as "work in progress." material or to 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/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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 Internet-Draft will expire on July 17, 2009. This Internet-Draft will expire on September 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
According to the current Mobile IPv6 specification, a mobile node may According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, called the primary have several care-of addresses, but only one, called the primary
care-of address, that can be registered with its home agent and the care-of address, that can be registered with its home agent and the
correspondent nodes. However, for matters of cost, bandwidth, delay, correspondent nodes. However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through etc, it is useful for the mobile node to get Internet access through
multiple accesses simultaneously, in which case the mobile node would multiple accesses simultaneously, in which case the mobile node would
be configured with multiple active IPv6 care-of addresses. This be configured with multiple active IPv6 care-of addresses. This
document proposes extensions to the Mobile IPv6 protocol to register document proposes extensions to the Mobile IPv6 protocol to register
and use multiple care-of addresses. The extensions proposed in this and use multiple care-of addresses. The extensions proposed in this
document can be used by Mobile Routers using the NEMO (Network document can be used by Mobile Routers using the NEMO (Network
Mobility) Basic Support protocol as well. Mobility) Basic Support protocol as well.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 12 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 13
4.1. Binding Cache Structure and Binding Update List . . . . . 12 4.1. Binding Cache Structure and Binding Update List . . . . . 13
4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 12 4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 13
4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 13 4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 14
4.4. New Status Values for Binding Acknowledgement . . . . . . 14 4.4. New Status Values for Binding Acknowledgement . . . . . . 15
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 17 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 18
5.1. Management of Care-of Address(es) and Binding 5.1. Management of Care-of Address(es) and Binding
Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 17 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 17 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 18
5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 18 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19
5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 19 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20
5.5. Returning Home: Using Single Interface . . . . . . . . . . 19 5.5. Returning Home: Using Single Interface . . . . . . . . . . 20
5.5.1. Using only Interface attached to the Home Link . . . . 20 5.5.1. Using only Interface attached to the Home Link . . . . 21
5.5.2. Using only Interface attached to the Visited Link . . 20 5.5.2. Using only Interface attached to the Visited Link . . 21
5.6. Returning Home: Simultaneous Home and Visited Link 5.6. Returning Home: Simultaneous Home and Visited Link
Operation . . . . . . . . . . . . . . . . . . . . . . . . 20 Operation . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6.1. Problems of Simultaneous Home and Foreign 5.6.1. Problems of Simultaneous Home and Foreign
Attachments . . . . . . . . . . . . . . . . . . . . . 20 Attachments . . . . . . . . . . . . . . . . . . . . . 21
5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 21 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22
5.6.3. Sending Deregistration Binding Update . . . . . . . . 22 5.6.3. Sending Deregistration Binding Update . . . . . . . . 23
5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 23 5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 24
5.6.5. Home Binding for Flow Binding Support . . . . . . . . 24 5.6.5. Home Binding for Flow Binding Support . . . . . . . . 25
5.6.6. Sending Packets from the Home Link . . . . . . . . . . 25 5.6.6. Sending Packets from the Home Link . . . . . . . . . . 26
5.6.7. Leaving from the Home Link . . . . . . . . . . . . . . 26 5.6.7. Leaving from the Home Link . . . . . . . . . . . . . . 27
5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 26 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 27
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 27 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 28
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 28 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 29
6. Home Agent and Correspondent Node Operation . . . . . . . . . 29 6. Home Agent and Correspondent Node Operation . . . . . . . . . 30
6.1. Searching Binding Cache with Binding Identifier . . . . . 29 6.1. Searching Binding Cache with Binding Identifier . . . . . 30
6.2. Processing Binding Update . . . . . . . . . . . . . . . . 29 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 30
6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 32 6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 33
6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 32 6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 33
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 33 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 34
8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 34 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 35
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 34 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 35
8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 35 8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 36
9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 36 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 38
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 36 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 38
9.2. Transport Mode IPsec protected messages . . . . . . . . . 37 9.2. Transport Mode IPsec protected messages . . . . . . . . . 39
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 37 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 39
9.3.1. Tunneled Home Test Init and Home Test messages . . . . 37 9.3.1. Tunneled Home Test Init and Home Test messages . . . . 39
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 38 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
A mobile node may use various types of network interfaces to obtain A mobile node may use various types of network interfaces to obtain
durable and wide area network connectivity. This has increasingly durable and wide area network connectivity. This has increasingly
become true with mobile nodes having multiple interfaces such as become true with mobile nodes having multiple interfaces such as
802.2, 802.11, 802.16, cellular radios, etc. The motivations for and 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and
benefits of using multiple points of attachment are discussed in [ID- benefits of using multiple points of attachment are discussed in [ID-
MOTIVATION]. When a mobile node with multiple interfaces uses Mobile MOTIVATION]. When a mobile node with multiple interfaces uses Mobile
IPv6 [RFC-3775] for mobility management, it cannot use its multiple IPv6 [RFC-3775] for mobility management, it cannot use its multiple
skipping to change at page 24, line 25 skipping to change at page 25, line 25
address carried by the Link Layer Address option [RFC-5268] in the address carried by the Link Layer Address option [RFC-5268] in the
received Binding Update. After the completion of the binding received Binding Update. After the completion of the binding
deregistration, the mobile node starts regular Neighbor Discovery deregistration, the mobile node starts regular Neighbor Discovery
operations for the home address on the home link. The neighbor operations for the home address on the home link. The neighbor
cache entry for the home address is created by the regular cache entry for the home address is created by the regular
exchange of Neighbor Solicitation and Neighbor Advertisement. exchange of Neighbor Solicitation and Neighbor Advertisement.
o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP]
value in the Status field of the Binding Identifier mobility value in the Status field of the Binding Identifier mobility
option. The home agent learns the mobile node's link-layer option. The home agent learns the mobile node's link-layer
address by receiving the link-layer address option carried by the address by receiving the Mobility Header link-layer address option
Binding Update. It stores the link-layer address as a neighbor carried by the Binding Update. It stores the link-layer address
cache entry for the mobile node so that it can send the packets to as a neighbor cache entry for the mobile node so that it can send
the mobile node's link-layer address. the packets to the mobile node's link-layer address.
o Note that the use of proxy Neighbor Discovery is an easier way to o Note that the use of proxy Neighbor Discovery is an easier way to
intercept the mobile nodes' packets instead of IP routing in some intercept the mobile nodes' packets instead of IP routing in some
deployment scenarios. Therefore, even if a home agent is the only deployment scenarios. Therefore, even if a home agent is the only
router, it is an implementation and operational choice whether the router, it is an implementation and operational choice whether the
home agent returns [Binding Update Accepted] or [MCOA RETURNHOME home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
WO/NDP]. WO/NDP].
o If BID option is not included in the Binding Acknowledgement, the o If BID option is not included in the Binding Acknowledgement, the
home agent might not recognize the simultaneous home and foreign home agent might not recognize the simultaneous home and foreign
skipping to change at page 25, line 49 skipping to change at page 26, line 49
o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in
the Binding Acknowledgement, it MUST NOT operate Neighbor the Binding Acknowledgement, it MUST NOT operate Neighbor
Discovery for the home address. When the mobile node sends Discovery for the home address. When the mobile node sends
packets from the interface attached to the home link, it MUST packets from the interface attached to the home link, it MUST
learn the link-layer address of the next hop (i.e. default router learn the link-layer address of the next hop (i.e. default router
of the mobile node). A mobile node learns the default router's of the mobile node). A mobile node learns the default router's
link-layer address from a Source Link-Layer Address option in link-layer address from a Source Link-Layer Address option in
Router Advertisements. The mobile node sends packets directly to Router Advertisements. The mobile node sends packets directly to
the default router's link-layer address. This is done by the default router's link-layer address. This is done by
constructing the packet including link-layer header with the constructing the packet including a link-layer header with the
learned link-layer address of the default router. The home agent learned link-layer address of the default router. The home agent
also forwards the packet to the mobile node on the home link by also forwards the packet to the mobile node on the home link by
using the mobile node's link-layer address. The link-layer using the mobile node's link-layer address. The link-layer
address SHOULD be cached when the home agent received the address SHOULD be cached when the home agent received the
deregistration Binding Update message. Note that the default deregistration Binding Update message. Note that the default
router MUST NOT cache the mobile node's link-layer address in the router MUST NOT cache the mobile node's link-layer address in the
neighbor cache when it forwards the packet from the mobile node to neighbor cache when it forwards the packet from the mobile node to
the home agent. the home agent.
5.6.7. Leaving from the Home Link 5.6.7. Leaving from the Home Link
skipping to change at page 35, line 6 skipping to change at page 36, line 6
If a NAT is not detected, the mobile node can update the IPv4 care-of If a NAT is not detected, the mobile node can update the IPv4 care-of
address by using bulk registration. The mobile node can register the address by using bulk registration. The mobile node can register the
IPv4 care-of address along with other IPv4 and IPv6 care-of IPv4 care-of address along with other IPv4 and IPv6 care-of
addresses. Figure 10 shows the Binding Update format when the mobile addresses. Figure 10 shows the Binding Update format when the mobile
node sends a Binding Update from one of its IPv6 care-of addresses. node sends a Binding Update from one of its IPv6 care-of addresses.
If the mobile node sends a Binding Update from IPv4 care-of address, If the mobile node sends a Binding Update from IPv4 care-of address,
it MUST follow the format described in Figure 9. Note that the IPv4 it MUST follow the format described in Figure 9. Note that the IPv4
Care-of Address must be registered by non bulk Binding registration, Care-of Address must be registered by non bulk Binding registration,
whenever it is changed. whenever it is changed.
As shown in Figure 9, IPv4 care-of address will be appeared in
Binding Identifier mobility option. The IPv4 care-of address
mobility option defined in [ID-DSMIP6] MUST always be omitted. The
receiver of the Binding Update message for an IPv4 care-of address
MUST use the IPv4 address stored in the Binding Identifier mobility
option instead of the IPv4 care-of address mobility option.
IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header ESP Header
Mobility header Mobility header
-Binding Update -Binding Update
Mobility Options Mobility Options
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- ... - ...
Figure 10: Binding Bulk Registration for IPv4 care-of address Figure 10: Binding Bulk Registration for IPv4 care-of address
If the home agent rejects the IPv4 care-of address, it MUST store the When the home agent returns a Binding Acknowledgement for the IPv4
error code value in the Status field of the BID mobility option. care-of address registration, it SHOULD NOT use the IPv4 address
Acknowledgement mobility option and SHOULD use only the Binding
Identifier mobility option. The registration status for the IPv4
Care-of address is stored in the Status field of the Binding
Identifier mobility option. However, if the home agent needs to
store the status value specially defined for the IPv4 address
Acknowledgement mobility option, it MUST store the status value in
the IPv4 address Acknowledgement mobility option and MUST NOT store
it in Binding Identifier mobility option. In such case, the home
agent MUST include both the IPv4 address Acknowledgement mobility
option and Binding Identifier mobility option.
8.2. IPv4 Home Address Management 8.2. IPv4 Home Address Management
When the mobile node wants to configure an IPv4 home address in When the mobile node wants to configure an IPv4 home address in
addition to the IPv6 home address, it can request for one using the addition to the IPv6 home address, it can request for one using the
IPv4 Home Address option in the Binding Update. If the home agent IPv4 Home Address option in the Binding Update. If the home agent
accepts the Binding Update, the mobile node can now register multiple accepts the Binding Update, the mobile node can now register multiple
care-of addresses for the IPv4 home address in addition to the IPv6 care-of addresses for the IPv4 home address in addition to the IPv6
home address. The same set of care-of addresses will be registered home address. The mobile node MUST always use the IPv4 home address
for both IPv6 and IPv4 home addresses. The mobile node cannot bind a mobility option for any purposes of the IPv4 home address management.
different set of care-of addresses to each home address. The same set of care-of addresses will be registered for both IPv6
and IPv4 home addresses. The mobile node cannot bind a different set
of care-of addresses to each home address.
According to [ID-DSMIPv6], the home agent includes the IPv4 address According to [ID-DSMIPv6], the home agent includes the IPv4 address
Acknowledgement option in the Binding Acknowledgement only if the Acknowledgement option in the Binding Acknowledgement only if the
mobile node had requested for an IPv4 home address in the mobile node had requested for an IPv4 home address in the
corresponding Binding Update. The IPv4 address Acknowledgement corresponding Binding Update. The IPv4 address Acknowledgement
option MUST be present before any BID option. The status field of option MUST be present before any Binding Identifier mobility option.
the IPv4 address Acknowledgement option contains only the error code The status field of the IPv4 address Acknowledgement option contains
corresponding to the IPv4 home address management. The error values only the error code defined in Section 4.2.1 of [ID-DSMIP6]. The
related to the IPv4 care-of address registration MUST be stored in home agent MUST always include the IPv4 address Acknowledgement
the Binding Identifier mobility option. mobility option in the Binding Acknowledgement for the IPv4 home
address registration.
9. IPsec and IKEv2 interaction 9. IPsec and IKEv2 interaction
Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
use of IPsec to protect signaling messages including Binding Updates, use of IPsec to protect signaling messages including Binding Updates,
Binding Acknowledgement and return routability messages. IPsec may Binding Acknowledgement and return routability messages. IPsec may
also be used protect all tunneled data traffic. The Mobile IPv6- also be used protect all tunneled data traffic. The Mobile IPv6-
IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to
setup the required IPsec security associations. The following setup the required IPsec security associations. The following
assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with
skipping to change at page 38, line 16 skipping to change at page 40, line 16
When the mobile sends and receives multiple traffic flows protected When the mobile sends and receives multiple traffic flows protected
by IPsec to different care-of addresses, the use of the correct by IPsec to different care-of addresses, the use of the correct
care-of address for each flow becomes important. Support for this care-of address for each flow becomes important. Support for this
requires the following two considerations on the home agent. requires the following two considerations on the home agent.
o When the home agent receives a reverse tunneled payload message o When the home agent receives a reverse tunneled payload message
protected by IPsec in tunnel mode, it still needs to be aware of protected by IPsec in tunnel mode, it still needs to be aware of
which care-of address is being used. According to [RFC-4306], the which care-of address is being used. According to [RFC-4306], the
IPsec implementation on the home agent does not check the source IPsec implementation on the home agent does not check the source
address on the outer IPv6 header. However, the Mobile IPv6 stack address on the outer IPv6 header. However, the stack on the home
on the home agent MUST still be informed about the source address agent MUST still be informed about the source address in order to
in order to choose the most recently used care-of address, as choose the most recently used care-of address, as discussed in
discussed in Section 3 (in the absence of a user-supplied policy). Section 3 (in the absence of a user-supplied policy)
o For tunneled IPsec traffic from the home agent to the mobile node, o For tunneled IPsec traffic from the home agent to the mobile node,
The IPsec implementation on the home agent may not be aware of The IPsec implementation on the home agent may not be aware of
which care-of address to use when performing IPsec tunnel which care-of address to use when performing IPsec tunnel
encapsulation. The Mobile IP stack on the home agent must specify encapsulation. The Mobile IP stack on the home agent must specify
the tunnel end point for the IPsec tunnel. This may require tight the tunnel end point for the IPsec tunnel. This may require tight
integration between the IPsec and Mobile IP implementations on the integration between the IPsec and Mobile IP implementations on the
home agent. home agent.
10. Security Considerations 10. Security Considerations
 End of changes. 31 change blocks. 
79 lines changed or deleted 107 lines changed or added

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