draft-ietf-monami6-multiplecoa-12.txt   draft-ietf-monami6-multiplecoa-13.txt 
MEXT Working Group R. Wakikawa (Ed.) MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Toyota ITC/Keio Univ. Internet-Draft Toyota ITC
Intended status: Standards Track V. Devarapalli (Ed.) Intended status: Standards Track V. Devarapalli
Expires: September 7, 2009 Wichorus Expires: October 22, 2009 Wichorus
G. Tsirtsis
Qualcomm
T. Ernst T. Ernst
INRIA INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
March 6, 2009 April 20, 2009
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-12.txt draft-ietf-monami6-multiplecoa-13.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. This document may contain material provisions of BCP 78 and BCP 79.
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 September 7, 2009. This Internet-Draft will expire on October 22, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 3, line 47 skipping to change at page 3, line 47
5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19
5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20
5.5. Returning Home: Using Single Interface . . . . . . . . . . 20 5.5. Returning Home: Using Single Interface . . . . . . . . . . 20
5.5.1. Using only Interface attached to the Home Link . . . . 21 5.5.1. Using only Interface attached to the Home Link . . . . 21
5.5.2. Using only Interface attached to the Visited Link . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 Operation . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6.1. Problems of Simultaneous Home and Foreign 5.6.1. Problems of Simultaneous Home and Foreign
Attachments . . . . . . . . . . . . . . . . . . . . . 21 Attachments . . . . . . . . . . . . . . . . . . . . . 21
5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22
5.6.3. Sending Deregistration Binding Update . . . . . . . . 23 5.6.3. Home Binding Support . . . . . . . . . . . . . . . . . 23
5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 24 5.6.4. Sending Packets from the Home Link . . . . . . . . . . 23
5.6.5. Home Binding for Flow Binding Support . . . . . . . . 25 5.6.5. Leaving from the Home Link . . . . . . . . . . . . . . 24
5.6.6. Sending Packets from the Home Link . . . . . . . . . . 26 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 24
5.6.7. Leaving from the Home Link . . . . . . . . . . . . . . 27 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 25
5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 27 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 26
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 28
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 29
6. Home Agent and Correspondent Node Operation . . . . . . . . . 30 6. Home Agent and Correspondent Node Operation . . . . . . . . . 27
6.1. Searching Binding Cache with Binding Identifier . . . . . 30 6.1. Searching Binding Cache with Binding Identifier . . . . . 27
6.2. Processing Binding Update . . . . . . . . . . . . . . . . 30 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 27
6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 33 6.3. Sending Binding Acknowledgement for home link
6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 33 registration . . . . . . . . . . . . . . . . . . . . . . . 29
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 31
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 31
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 34 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32
8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 35 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 35 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33
8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 36 8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 34
9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 38 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 36
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 38 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 36
9.2. Transport Mode IPsec protected messages . . . . . . . . . 39 9.2. Transport Mode IPsec protected messages . . . . . . . . . 37
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 39 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 37
9.3.1. Tunneled Home Test Init and Home Test messages . . . . 39 9.3.1. Tunneled Home Test Init and Home Test messages . . . . 37
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 40 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 38
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
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 15, line 40 skipping to change at page 15, line 40
the sender, and SHOULD be ignored by the receiver. the sender, and SHOULD be ignored by the receiver.
Care-of Address Care-of Address
If a Binding Identifier mobility option is included in a Binding If a Binding Identifier mobility option is included in a Binding
Update for the home registration, either IPv4 or IPv6 care-of Update for the home registration, either IPv4 or IPv6 care-of
address for the corresponding BID can be stored in this field. address for the corresponding BID can be stored in this field.
For the binding registration to correspondent nodes (i.e. route For the binding registration to correspondent nodes (i.e. route
optimization), only IPv6 care-of address can be stored in this optimization), only IPv6 care-of address can be stored in this
field. If no address is specified in this field, the length of field. If no address is specified in this field, the length of
this field MUST be zero (i.e. not appeared in the option). If no this field MUST be zero (i.e. not appeared in the option). If the
address is specified in this field, a care-of address is taken option is included in any other messages than a Binding Update,
from the source address field of the IPv6 header of the Binding the length of this field MUST be also zero.
Update. If the option is included in any other messages than a
Binding Update, the length of this field MUST be also zero.
4.4. New Status Values for Binding Acknowledgement 4.4. New Status Values for Binding Acknowledgement
New status values for the status field in a Binding Acknowledgement New status values for the status field in a Binding Acknowledgement
are defined for handling the multiple Care-of Addresses registration: are defined for handling the multiple Care-of Addresses registration:
MCOA NOTCOMPLETE (TBD less than 128) MCOA NOTCOMPLETE (TBD less than 128)
In bulk registration, not all the binding identifier mobility In bulk registration, not all the binding identifier mobility
options were successfully registered. Some of them were rejected. options were successfully registered. Some of them were rejected.
The error status value of the failed mobility option is The error status value of the failed mobility option is
individually stored in the status field of the binding identifier individually stored in the status field of the binding identifier
mobility option. mobility option.
MCOA RETURNHOME WO/NDP (TBD less than 128) MCOA RETURNHOME WO/NDP (TBD less than 128)
When a mobile node returns home, it MUST NOT use Neighbor When a mobile node returns home, it MUST NOT use Neighbor
Discovery Protocol (NDP) for the home address on the home link. Discovery Protocol (NDP) for the home address on the home link.
skipping to change at page 16, line 35 skipping to change at page 16, line 32
* when the wrong length value is specified (neither 4, 8 nor 20) * when the wrong length value is specified (neither 4, 8 nor 20)
in the length field of the Binding Identifier mobility option. in the length field of the Binding Identifier mobility option.
* when a unicast routable address is not specified in the care-of * when a unicast routable address is not specified in the care-of
address field of the Binding Identifier mobility option. address field of the Binding Identifier mobility option.
* when a care-of address is not appeared in the care-of address * when a care-of address is not appeared in the care-of address
field of the Binding Identifier mobility option stored in an field of the Binding Identifier mobility option stored in an
IPsec ESP protected Binding Update. IPsec ESP protected Binding Update.
MCOA BID CONFLICT (TBD more than 128) MCOA NON-MCOA BINDING EXISTS (TBD more than 128)
The home agent cannot cache both a regular binding and a BID It indicates that a bootstrapping multiple care-of address
extended binding simultaneously. It returns this status value registration was performed without the 'O' flag set.
when the received binding conflicts with the existing binding
cache entry(ies). MCOA UNKOWN COA(TBD more than 128)
It indicates that a Binding Identifier Mobility Option did not
include a Care-of address field and the receiver has no record for
the Binding ID indicated in the same option.
MCOA PROHIBITED(TBD more than 128) MCOA PROHIBITED(TBD more than 128)
It implies the multiple care-of address registration is It implies the multiple care-of address registration is
administratively prohibited. administratively prohibited.
MCOA BULK REGISTRATION PROHIBITED(TBD more than 128) MCOA BULK REGISTRATION PROHIBITED(TBD more than 128)
Bulk binding registration is not either permitted or supported. Bulk binding registration is not either permitted or supported.
Note that the bulk registration is an optional procedure and might Note that the bulk registration is an optional procedure and might
not be available on a home agent. not be available on a home agent.
MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128) MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128)
Simultaneous home and foreign attachment is neither supported nor Simultaneous home and foreign attachment is neither supported nor
permitted. permitted.
5. Mobile Node Operation 5. Mobile Node Operation
skipping to change at page 18, line 37 skipping to change at page 18, line 37
has several addresses it can use as care-of addresses. has several addresses it can use as care-of addresses.
A mobile node assigns a BID to each care-of address when it wants to A mobile node assigns a BID to each care-of address when it wants to
register them simultaneously with its home address. The BID MUST be register them simultaneously with its home address. The BID MUST be
unique for a given home address. The value is an integer between 1 unique for a given home address. The value is an integer between 1
and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node
has only one care-of address, the assignment of a BID is not needed has only one care-of address, the assignment of a BID is not needed
until it has multiple care-of addresses to register with, at which until it has multiple care-of addresses to register with, at which
time all of the care-of addresses MUST be mapped to BIDs. time all of the care-of addresses MUST be mapped to BIDs.
When a mobile node registers a given BID for the first time it MUST
include the care of address field in the Binding Identifier mobility
option. For any subsequent registrations that either re-register or
de-register the same BID, the MN SHOULD NOT include the care of
address field in the Binding Identifier mobility option.
5.2. Binding Registration 5.2. Binding Registration
For the multiple Care-of Addresses registration, the mobile node MUST For the multiple Care-of Addresses registration, the mobile node MUST
include a Binding Identifier mobility option(s) in the Binding Update include a Binding Identifier mobility option(s) in the Binding Update
as shown in Figure 6. The BID is copied from a corresponding binding as shown in Figure 6.
update List entry to the BID field of the Binding Identifier mobility
option.
When IPsec ESP is used for protecting the Binding Update, a care-of When IPsec ESP is used for protecting the Binding Update, a care-of
address MUST be carried in an alternate care-of address mobility address MUST be carried in an alternate care-of address mobility
option as described in [RFC-4877]. However, in this specification, option as described in [RFC-4877]. However, in this specification,
the care-of address MUST be carried in the Care-of Address field of the care-of address MUST be carried in the Care-of Address field of
the Binding Identifier mobility option. In order to save bits of the the Binding Identifier mobility option. In order to save bits of the
Binding Update, the alternate care-of address option MUST NOT be Binding Update, the alternate care-of address option MUST NOT be
included. included.
For binding registration to a correspondent node, the mobile node For binding registration to a correspondent node, the mobile node
skipping to change at page 19, line 29 skipping to change at page 19, line 32
Mobility Options Mobility Options
Binding Identifier mobility option Binding Identifier mobility option
Binding Authorization mobility option+ Binding Authorization mobility option+
(*) if necessary, for home registration (*) if necessary, for home registration
(+) if necessary, for route optimization (+) if necessary, for route optimization
Figure 6: Binding Update for Binding Registration Figure 6: Binding Update for Binding Registration
If the mobile node wants to replace existing registered bindings on If the mobile node wants to replace existing registered bindings on
the home agent with the single binding in the sent Binding Update, it the home agent with the single binding in the sent Binding Update, it
sets the 'O' flag. The single binding will be registered with the sets the 'O' flag. It the 'O' flag is not set then the binding will
assigned BID. Section 6.2 describes this registration procedure in be added to existing bindings in the home agent. The single binding
detail. Note that if the mobile node wants to register a RFC-3775 will be registered with the assigned BID. Section 6.2 describes this
compliant binding (i.e. no BID assigned to that binding), it sends a registration procedure in detail.
Binding Update without any Binding Identifier mobility option.
5.3. Bulk Registration 5.3. Bulk Registration
Bulk registration is an optimization for binding multiple care-of Bulk registration is an optimization for binding multiple care-of
addresses to a home address using a single Binding Update. This is addresses to a home address using a single Binding Update. This is
very useful if the mobile node, for instance, does not want to send a very useful if the mobile node, for instance, does not want to send a
lot of signaling messages through an interface where the bandwidth is lot of signaling messages through an interface where the bandwidth is
scarce. This document specifies bulk registration only for the scarce. This document specifies bulk registration only for the
mobile node's home registration. A mobile node performing bulk mobile node's home registration. A mobile node performing bulk
registration with a correspondent node is out of scope. registration with a correspondent node is out of scope.
To use bulk registration, the mobile node includes a Binding To use bulk registration, the mobile node includes a Binding
Identifier Mobility option for each BID and Care-of address pair it Identifier Mobility option for each BID it wants to register in the
wants to register in the same Binding Update message. This is shown same Binding Update message. As with single registrations (see
in Figure 7. The rest of the fields and options in the Binding Section 5.1), the care of address field is included for BID
Update such as Lifetime, Sequence Number, and the flags in the registered for the first time. This is shown in Figure 7. The rest
Binding Update are common across all care-of addresses. of the fields and options in the Binding Update such as Lifetime,
Sequence Number, and the flags in the Binding Update are common
When IPsec ESP is used for protecting the Binding Update, a care-of across all care-of addresses.
address MUST be carried in an alternate care-of address mobility
option as described in [RFC-4877]. However, in the bulk
registration, the care-of addresses are always carried in the Care-of
Address field of the Binding Identifier mobility option. In order to
save bits of the Binding Update, the alternate care-of address option
MUST NOT be included in such Binding Update.
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 (including Care-of Address) Binding Identifier1 (including Care-of Address)
Binding Identifier2 (including Care-of Address)
Binding Identifier3 (no Care-of Address)
Binding IdentifierN (no Care-of Address)
:
Figure 7: Binding Update for Bulk Registration Figure 7: Binding Update for Bulk Registration
If the mobile node wants to replace existing registered bindings on As with regular registrations, if the mobile node wants to replace
the home agent with the multiple bindings in the sent Binding Update, existing registered bindings on the home agent with the multiple
it sets the 'O' flag in the Binding Update. bindings in the sent Binding Update, it sets the 'O' flag in the
Binding Update, otherwise the bindings are added to the existing
bindings in the home agent.
5.4. Binding De-Registration 5.4. Binding De-Registration
When a mobile node decides to delete all the bindings for its home When a mobile node decides to delete all the bindings for its home
address, it sends a regular de-registration Binding Update with address, it sends a regular de-registration Binding Update with
lifetime set to zero as defined in [RFC-3775]. The Binding lifetime set to zero as defined in [RFC-3775]. The Binding
Identifier mobility option is not required. Identifier mobility option is not required.
If a mobile node wants to delete a particular binding(s) from its If a mobile node wants to delete a particular binding(s) from its
home agent and correspondent nodes, the mobile node sends a Binding home agent and correspondent nodes, the mobile node sends a Binding
Update with lifetime set to zero and includes a Binding Identifier Update with lifetime set to zero and includes a Binding Identifier
mobility option(s) with the BID(s) it wants to de-register. The mobility option(s) with the BID(s) it wants to de-register. The
receiver will remove only the care-of address(es) that match(es) the receiver will remove only the care-of address(es) that match(es) the
specified BID(s). The care-of addresses field in each mobility specified BID(s). Since de-registration attempts to remove a BID
option SHOULD be omitted by the sender (i.e. the field does not that already exists, the care-of addresses field in each binding
appear in the option) and MUST be ignored by the receiver. This is identifier option can be omitted by the sender as defined in
because the receiver will remove the binding that matches the Section 5.1.
specified BID.
5.5. Returning Home: Using Single Interface 5.5. Returning Home: Using Single Interface
The mobile node may return to the home link, by attaching to the home The mobile node may return to the home link, by attaching to the home
link through one of its interfaces. When the mobile node wants to link through one of its interfaces. When the mobile node wants to
return home, it should be configured with information on what return home, it should be configured with information on what
interface it needs to use. interface it needs to use.
5.5.1. Using only Interface attached to the Home Link 5.5.1. Using only Interface attached to the Home Link
The mobile node returns home and de-registers all the bindings as The mobile node returns home and de-registers all the bindings as
shown in Figure 2 and as defined in [RFC-3775]. De-registering all shown in Figure 2 and as defined in [RFC-3775]. After the de-
the bindings is the same as binding de-registration from foreign link registration step, all the packets routed by the home agent are only
described in Section 5.4. After the de-registration step, all the forwarded to the interface attached to the home link, even if there
packets routed by the home agent are only forwarded to the interface are other active interfaces attached to the visited link(s). While
attached to the home link, even if there are other active interfaces the mobile node de-registers all the bindings from the home agent, it
attached to the visited link(s). While the mobile node de-registers may continue registering bindings for interface(s) attached to
all the bindings from the home agent, it may continue registering visited link(s) to the correspondent node as shown in Figure 2.
bindings for interface(s) attached to visited link(s) to the
correspondent node as shown in Figure 2.
5.5.2. Using only Interface attached to the Visited Link 5.5.2. Using only Interface attached to the Visited Link
The mobile node returns home physically but shuts down the interface The mobile node returns home physically but shuts down the interface
attached to the home link. As a result, a mobile node does not attached to the home link. As a result, a mobile node does not
return home even though it attaches to the home link by one of return home even though it attaches to the home link by one of
interfaces. Following procedures should be taken by the mobile node. interfaces. Before shutting down the interface, any binding for the
Before shutting down the interface, any binding for the care-of care-of address previously associated with the interface should be
address previously associated with the interface should be deleted. deleted as defined in .
To delete the binding cache entry, the mobile node SHOULD send a de-
registration Binding Update with the lifetime set to zero and include
the corresponding BID information. If the mobile node does not send
a de-registration Binding Update, the binding for the care-of address
previously assigned to the interface remains at the home agent until
its lifetime expires.
In this scenario, despite the fact that the mobile node is connected In this scenario, despite the fact that the mobile node is connected
to its home link, all of its traffic is sent and received via the to its home link, all of its traffic is sent and received via the
home agent and its foreign links. home agent and its foreign links.
5.6. Returning Home: Simultaneous Home and Visited Link Operation 5.6. Returning Home: Simultaneous Home and Visited Link Operation
5.6.1. Problems of Simultaneous Home and Foreign Attachments 5.6.1. Problems of Simultaneous Home and Foreign Attachments
The mobile node returns home and continues using all the interfaces The mobile node returns home and continues using all the interfaces
attached to both foreign and home links as shown in Figure 3. The attached to both foreign and home links as shown in Figure 3.
mobile node indicates this by setting the 'H' flag in the Binding
Identifier mobility option as defined below. There are additional
requirements on the Returning Home procedures for possible Neighbor
Discovery state conflicts at the home link.
In [RFC-3775], the home agent intercepts packets meant for the mobile In [RFC-3775], the home agent intercepts packets meant for the mobile
node using Proxy Neighbor Discovery [RFC-4861] while the mobile node node using Proxy Neighbor Discovery [RFC-4861] while the mobile node
is away from the home link. When the mobile node returns home, the is away from the home link. When the mobile node returns home, the
home agent deletes the binding cache and stops proxying for the home home agent deletes the binding cache and stops proxying for the home
address so that a mobile node can configure its home address on the address so that a mobile node can configure its home address on the
interface attached to the home link. In this specification, a mobile interface attached to the home link. In this specification, a mobile
node may return home, configure the home address on the interface node may return home, configure the home address on the interface
attached to the home link, but still use the interfaces attached to attached to the home link, but still use the interfaces attached to
the foreign links. In this case, a possible conflict arises when the the foreign links. In this case, a possible conflict arises when the
skipping to change at page 22, line 19 skipping to change at page 22, line 7
address. If the home agent stops proxying for the home address, the address. If the home agent stops proxying for the home address, the
packets are always routed to the interface attached to the home link packets are always routed to the interface attached to the home link
and are never routed to the interfaces attached to the visited links. and are never routed to the interfaces attached to the visited links.
It is required to avoid the conflict between the home agent and the It is required to avoid the conflict between the home agent and the
mobile node, while still allowing the simultaneous use of home and mobile node, while still allowing the simultaneous use of home and
foreign links. The following describes the mechanism for achieving foreign links. The following describes the mechanism for achieving
this. this.
5.6.2. Overview and Approach 5.6.2. Overview and Approach
In this scenario, the home agent MUST intercept all the packets meant The home agent MUST intercept all the packets meant for the mobile
for the mobile node and decide whether to send the traffic directly node whether the mobile node is attached to the home link or not and
to the home address on the link or tunnel to the care-of address. decide whether to send the traffic directly to the home address on
The home agent intercepts all the packets even when the mobile node the link or tunnel to the care-of address.
is attached to the home link through one of its interfaces. The home
agent would make this decision based on the type of flow. How to
make this decision is out of scope in this document.
Two scenarios are illustrated in Figure 3, depending on whether the Two scenarios are illustrated in Figure 3, depending on whether the
Home Agent is the only router at the home link or not. The Home Agent is the only router at the home link or not. The
difference is on who defends the home address by (Proxy) Neighbor difference is on who defends the home address by (Proxy) Neighbor
Discovery on the home link. Discovery on the home link.
1. Mobile node defends the home address by the regular Neighbor 1. Mobile node defends the home address by the regular Neighbor
Discovery Protocol (illustrated as topology-a in Figure 3). The Discovery Protocol (illustrated as topology-a in Figure 3). The
home agent is the only router on the home link. Therefore the home agent is the only router on the home link. Therefore the
home agent is capable of intercepting packets without relying on home agent is capable of intercepting packets without relying on
skipping to change at page 23, line 20 skipping to change at page 23, line 5
Likewise, the mobile node would also know the link-layer address Likewise, the mobile node would also know the link-layer address
of the default router address to send packets from the home link of the default router address to send packets from the home link
without Neighbor Discovery. The link-layer address is used to without Neighbor Discovery. The link-layer address is used to
transmit packets from and to the mobile node on the home link. transmit packets from and to the mobile node on the home link.
The packets are transmitted without the Neighbor Discovery The packets are transmitted without the Neighbor Discovery
protocol by constructing the link-layer header manually. This protocol by constructing the link-layer header manually. This
operation is similar to Mobile IPv6 [RFC-3775] when a mobile node operation is similar to Mobile IPv6 [RFC-3775] when a mobile node
sends a deregistration binding update to the home agent's link- sends a deregistration binding update to the home agent's link-
layer address in the operation for returning home. layer address in the operation for returning home.
5.6.3. Sending Deregistration Binding Update 5.6.3. Home Binding Support
o As soon as a mobile node returns home, it sends a de-registration
Binding Update to the home agent from the interface attached to
the home link. Note that if the mobile node runs the flow binding
[ID-FLOWBINDING], it MAY create its home binding and continue
registering its binding to the home agent from the home link. The
mobile node does not need to operate binding deregistration
described in this section. The detail operation can be found in
Section 5.6.5
o The mobile node MUST include the Binding Identifier mobility
option specifying the BID the mobile node had previously
associated with the interface attached to the home link. The 'H'
flag MUST be set in the Binding Identifier mobility option. For
the binding deregistration, a mobile node SHOULD NOT store a
care-of address in the Care-of Address field of the Binding
Identifier mobility option. The receiver, the home agent, can
match the removed binding with BID value in the Binding Identifier
mobility option.
o If the mobile node has to remove multiple bindings simultaneously,
it overwrites the existing binding entries by using 'O' flag and
should not send Binding Update messages for removing multiple
care-of addresses. The mobile node contains multiple Binding
Identifier mobility options for the active care-of addresses and
sets 'O' flag in the Binding Update message.
o When the 'H' flag is set, the home agent recognizes that the When the home binding is used, the mobile node MUST send a
mobile node wants to continue using interfaces attached to both registering binding update with a Binding Identifier mobility option
home and visited links. Note that H flag MUST be set for the whith H flag set. The lifetime MUST be set to a non-zero lifetime of
subsequent Binding Updates sent from the mobile node (ex. Binding the home binding, and the care-of address MUST be set to the home
Update for the interface(s) attached to the foreign link(s)). If address.
the home agent does not allow this scenario, it MUST send a
Binding Acknowledgement with the status code [MCOA SIMULTANEOUS
HOME AND FOREIGN PROHIBITED] set.
o The mobile node SHOULD include the Mobility Header Link-layer The mobile node SHOULD include the Mobility Header Link-layer Address
Address Option [RFC-5268] to notify the mobile node's link-layer Option [RFC-5268] to notify the mobile node's link-layer address to
address to the home agent, too. The option code of the Mobility the home agent, too. The option code of the Mobility Header Link-
Header Link-layer Address option MUST be set to '2' (Link-layer layer Address option MUST be set to '2' (Link-layer Address of the
Address of the mobile node). This link-layer address is required mobile node). This link-layer address is required for the home agent
for the home agent to send the Binding Acknowledgement and to to send the Binding Acknowledgement and to forward the mobile node's
forward the mobile node's packet. packet.
o According to [RFC-3775], the mobile node MUST start responding to According to [RFC-3775], the mobile node MUST start responding to
Neighbor Solicitation for its home address right after it sends Neighbor Solicitation for its home address right after it sends the
the deregistration Binding Update to the home agent. However, in deregistration Binding Update to the home agent. However, in this
this specification, the mobile node MUST NOT respond to Neighbor specification, the mobile node MUST NOT respond to Neighbor
Solicitation before receiving a Binding Acknowledgement, since the Solicitation before receiving a Binding Acknowledgement, since the
home agent may continue proxying for the home address. If the home agent may continue proxying for the home address. If the mobile
mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value node receives [MCOA RETURNHOME WO/NDP (TBD)] status value in the
in the received Binding Acknowledgment, it MUST NOT respond to received Binding Acknowledgment, it MUST NOT respond to Neighbor
Neighbor Solicitation even after the Binding Acknowledgement. Solicitation even after the Binding Acknowledgement.
5.6.4. Sending Binding Acknowledgement
The operations described in this section is for Home Agent and not
for Mobile Node. However, the Home Agent operations described in
this section are related to the returning home using simultaneous use
of home and foreign links.
o When the home agent sends the Binding Acknowledgement after
successfully processing the binding de-registration, it MUST set
the status value to either 0 [Binding Update Accepted] or to [MCOA
RETURNHOME WO/NDP (TBD)] in the Status field of the Binding
Acknowledgment depending on home agent configuration at the home
link. The new values are:
* Binding Update Accepted (0): Neighbor Discovery Protocol is
permitted for the home address at the home link. This is
regular returning home operation of [RFC-3775]
* MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is
prohibited for the home address at the home link
The respective Binding Identifier mobility options need to be
included in the Binding Acknowledgement.
o If the Binding Update is rejected, the appropriate error value
MUST be set in the status field. In this case, the home agent
operation is the same as [RFC-3775].
o Only if the home agent is certainly the only router in the home
link, it MAY turn off Neighbor Discovery for the requested home
address and responds with the [Binding Update Accepted] status
value to the mobile node. Since the mobile node will not reply to
Neighbor Solicitation for the home address before receiving the
Binding Acknowledgement, the home agent SHOULD use the link-layer
address carried by the Link Layer Address option [RFC-5268] in the
received Binding Update. After the completion of the binding
deregistration, the mobile node starts regular Neighbor Discovery
operations for the home address on the home link. The neighbor
cache entry for the home address is created by the regular
exchange of Neighbor Solicitation and Neighbor Advertisement.
o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP]
value in the Status field of the Binding Identifier mobility
option. The home agent learns the mobile node's link-layer
address by receiving the Mobility Header link-layer address option
carried by the Binding Update. It stores the link-layer address
as a neighbor cache entry for the mobile node so that it can send
the packets to the mobile node's link-layer address.
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
deployment scenarios. Therefore, even if a home agent is the only
router, it is an implementation and operational choice whether the
home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
WO/NDP].
o If BID option is not included in the Binding Acknowledgement, the
home agent might not recognize the simultaneous home and foreign
attachment. The home agent might have processed the de-
registration Binding Update as a regular de-registration as
described in [RFC-3775] and deletes all the registered binding
cache entries for the mobile node. Thus, the mobile node SHOULD
stop using the interface attached to foreign link and use only the
interface attached to the home link.
5.6.5. Home Binding for Flow Binding Support
The Flow Binding extensions [ID-FLOWBINDING] allows nodes to bind one
or more flows to a care-of address (BID). If a mobile node returns
home and deletes its binding for the interface attached to the home
link, flow bindings cannot be specified to that interface. Thus, it
is necessary to keep the BID for the interface attached to the home
link.
For this purpose, if the Flow Binding is being used, the home agent
MAY create a home binding where the care-of address is equal to the
mobile node's home address. This home binding is conceptual data
structure and can be implementation specific. The home binding is
created only when the mobile node is present at both the home and
foreign links. The home binding is created when a mobile node
requests by sending a Binding Update.
When the home binding is used, the binding de-registration operation The management of the home binding is same as the binding management
described in Section 5.6.3 is not necessary. Instead of sending a described in this specification. The home binding can be included in
deregistering binding update, the mobile node needs to send a a bulk binding registration (Section 5.3). The MN SHOULD refresh the
registering binding update with a Binding Identifier mobility option lifetime of the home binding by sending appropriate Binding Updates
which H flag is set. The lifetime is set to the requesting lifetime as with any other binding.
of the home binding. Once the home agent receives the Binding
Update, it creates a home binding as described in Section 5.2 except
for one point. The main difference of the home binding is that the
care-of address is set to the home address. The home agent needs to
treat this binding as a home binding. The management of the home
binding is same as the binding management described in this
specification. The home binding can be also created by bulk binding
registration (Section 5.3). The mobile node stores its home address
in the care-of address field of the Binding Identifier mobility
option and sets H flag to the option. It needs to refresh the
lifetime of the home binding by sending Binding Updates.
5.6.6. Sending Packets from the Home Link 5.6.4. Sending Packets from the Home Link
o When the mobile node receives the Binding Acknowledgement with the o When the mobile node receives the Binding Acknowledgement with the
status value 'Binding Update Accepted' and the BID option, it can status value 'Binding Update Accepted' and the BID option, it can
configure its home address to the interface attached to the home configure its home address to the interface attached to the home
link and start operating Neighbor Discovery for the home address link and start operating Neighbor Discovery for the home address
on the home link. Packets can be transmitted from and to the on the home link. Packets can be transmitted from and to the
mobile node as if the mobile node is a regular IPv6 node. mobile node as if the mobile node is a regular IPv6 node.
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
skipping to change at page 27, line 11 skipping to change at page 24, line 16
constructing the packet including a 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.5. Leaving from the Home Link
o When the mobile node detaches from the home link, it SHOULD
immediately send a Binding Update for one of active care-of
address with H flag unset. When the 'H' flag of BID option is
unset in any Binding Update, the home agent stop forwarding the
mobile node's packets to the home link.
5.6.7.1. Changing Behavior during the attachment to the home link
If a mobile node decides to return home completely without any active
foreign link attachment, it simply sends a deregistration Binding
Update as described in Section 5.5.1. Once the home agent receives
such de-registration Binding Update, the home agent clears all the
binding(s) and state for the mobile node.
If a mobile node decides to stop using the interface attached to the When the mobile node detaches from the home link, it SHOULD
home link, it simply sends a Binding Update from one of the active immediately send a Binding Update for one of active care-of address
care-of addresses. In the Binding Update, the mobile node should with H flag unset. When the 'H' flag of BID option is unset in any
include the BID option for the care-of address and unset the H flag Binding Update, the home agent stop forwarding the mobile node's
of the BID option. The home agent clears the state of the mobile packets to the home link.
node for the interface attached to the home link and stops forwarding
the packets to the mobile node on the home link.
5.7. Receiving Binding Acknowledgement 5.7. Receiving Binding Acknowledgement
The verification of a Binding Acknowledgement is the same as Mobile The verification of a Binding Acknowledgement is the same as Mobile
IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a
Binding Acknowledgement is described in Section 6.2. Binding Acknowledgement is described in Section 6.2.
If a mobile node includes a Binding Identifier mobility option in a If a mobile node includes a Binding Identifier mobility option in a
Binding Update with the 'A' flag set, a Binding Acknowledgement MUST Binding Update with the 'A' flag set, a Binding Acknowledgement
carry a Binding Identifier mobility option. According to [RFC-3775], SHOULD carry a Binding Identifier mobility option. According to
the receiver of the Binding Update ignores unknown mobility options [RFC-3775], the receiver of the Binding Update ignores unknown
and processes the Binding Update without the unknown mobility option. mobility options and processes the Binding Update without the unknown
Therefore, if no such mobility option is included in the Binding mobility option. Therefore, if no such mobility option is included
Acknowledgement in response to a Binding Update for multiple care-of in the Binding Acknowledgement in response to a Binding Update for
address registration, this indicates that the originating node of the multiple care-of address registration, this indicates that the
Binding Acknowledgement does not support processing the Binding originating node of the Binding Acknowledgement does not support
Identifier mobility option regardless of status value. In such case, processing the Binding Identifier mobility option regardless of
the receiver of the Binding Update may create a regular binding. The status value. In such case, the receiver of the Binding Update may
mobile node then no longer attempts multiple care-of address create a regular binding. The mobile node then SHOULD no longer
registration with that node. If this occurs with home registration attempt multiple care-of address registration with that node. If
the mobile node MAY attempt to discover another home agent supporting this occurs with home registration the mobile node MAY attempt to
Binding Identifier mobility option for the home registration. discover another home agent supporting Binding Identifier mobility
option for the home registration.
If a Binding Identifier mobility option is present in the received If a Binding Identifier mobility option is present in the received
Binding Acknowledgement, the mobile node checks the status field in Binding Acknowledgement, the mobile node checks the status field in
the option. If the status value in the Binding Identifier mobility the option. If the status value in the Binding Identifier mobility
option is zero, the mobile node uses the value in the Status field of option is zero, the mobile node uses the value in the Status field of
the Binding Acknowledgement. Otherwise, it uses the value in the the Binding Acknowledgement. Otherwise, it uses the value in the
Status field of the Binding Identifier mobility option. Status field of the Binding Identifier mobility option.
If the status code is greater than or equal to 128, the mobile node If the status code is greater than or equal to 128, the mobile node
starts relevant operations according to the error code. Otherwise, starts relevant operations according to the error code. Otherwise,
skipping to change at page 28, line 35 skipping to change at page 25, line 25
o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
mobile node needs to stop using bulk registrations with the node mobile node needs to stop using bulk registrations with the node
that sent the Binding Acknowledgement. It should assume that none that sent the Binding Acknowledgement. It should assume that none
of the attempted registrations were successful. of the attempted registrations were successful.
o If [MCOA MALFORMED] is specified, it indicates that the binding o If [MCOA MALFORMED] is specified, it indicates that the binding
identifier mobility option is formatted wrongly presumably due to identifier mobility option is formatted wrongly presumably due to
a programming error or major packet corruption. . a programming error or major packet corruption. .
o If [MCOA BID CONFLICT] is specified, the binding entry specified o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that
by the Binding Identifier mobility option is already registered as there is non-MCoA binding entry in the receiver. The mobile node
a regular binding. In such case, the mobile node needs to stop MUST set 'O' flag so that all the registered bindings are replced
sending Binding Updates with BID, or SHOULD use the 'O' flag to by an MCoA registration as described in Section 5.9.
reset all the registered bindings as described in Section 5.9.
o If [MCOA UNKNOWN COA] is specified, it means that the mobile node
sent a binding identifier mobility option without a care-off
address field but the receiver could not find an entry for the BID
indicated. If the mobile node is trying to deregister a BID, it
NEED NOT do anything further. If the mobile node is trying to
refresh a binding it SHOULD send a binding identifier mobility
option including the care-of address field.
5.8. Receiving Binding Refresh Request 5.8. Receiving Binding Refresh Request
The verification of a Binding Refresh Request is the same as in The verification of a Binding Refresh Request is the same as in
Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending
a Binding Refresh Request is described in Section 6.3. a Binding Refresh Request is described in Section 6.4.
If a mobile node receives a Binding Refresh Request with a Binding If a mobile node receives a Binding Refresh Request with a Binding
Identifier mobility option, it indicates that the node sending the Identifier mobility option, it indicates that the node sending the
Binding Refresh Request message is requesting the mobile node to send Binding Refresh Request message is requesting the mobile node to send
a new Binding Update for the BID. The mobile node SHOULD then send a a new Binding Update for the BID. The mobile node SHOULD then send a
Binding Update at least for the respective binding. The mobile node Binding Update at least for the respective binding, as described in
MUST include a Binding Identifier mobility option in the Binding Section 5.2 and Section 5.3.
Update.
5.9. Bootstrapping 5.9. Bootstrapping
When a mobile node bootstraps and registers multiple bindings for the When a mobile node bootstraps and registers multiple bindings for the
first time, it MUST set the 'O' flag in the Binding Update message. first time, it MUST set the 'O' flag in the Binding Update message.
If old bindings still exists at the home agent, the mobile node has If old bindings still exists at the home agent, the mobile node has
no knowledge of which bindings still exist at the home agent. This no knowledge of which bindings still exist at the home agent. This
scenario happens when a mobile node reboots and loses state regarding scenario happens when a mobile node reboots and loses state regarding
the registrations. If the 'O' flag is set, all the bindings are the registrations. If the 'O' flag is set, all the bindings are
replaced by the new binding(s). If the mobile node receives the replaced by the new binding(s).
Binding Acknowledgement with the status code set to 135 [Sequence
number out of window], it MUST follow the operations described in
[RFC-3775].
The 'O' flag can also be used in individual Binding Updates sent to
the correspondent nodes to override any existing binding cache
entries at the correspondent node.
6. Home Agent and Correspondent Node Operation 6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Identifier 6.1. Searching Binding Cache with Binding Identifier
If either a correspondent node or a home agent has multiple bindings If either a correspondent node or a home agent has multiple bindings
for a mobile node in their binding cache database, it can use any of for a mobile node in their binding cache database, it can use any of
the bindings to communicate with the mobile node. This section the bindings to communicate with the mobile node. This section
explains how to retrieve the desired binding for the binding explains how to retrieve the desired binding for the binding
management. This document does not provide any mechanism to select management. This document does not provide any mechanism to select
skipping to change at page 30, line 42 skipping to change at page 27, line 42
Binding Update. If the node does not know the BID, it searches for a Binding Update. If the node does not know the BID, it searches for a
binding with only the home address. In such a case, the first binding with only the home address. In such a case, the first
matched binding is found. If the node does not desire to use matched binding is found. If the node does not desire to use
multiple bindings for a mobile node, it can simply ignore the BID. multiple bindings for a mobile node, it can simply ignore the BID.
6.2. Processing Binding Update 6.2. Processing Binding Update
If a Binding Update does not contain a Binding Identifier mobility If a Binding Update does not contain a Binding Identifier mobility
option, its processing is the same as in [RFC-3775]. If the receiver option, its processing is the same as in [RFC-3775]. If the receiver
already has multiple bindings for the home address, it MUST replace already has multiple bindings for the home address, it MUST replace
all the existing bindings by the received binding. As a result, the all the existing bindings with the received binding. If the [RFC-
receiver node MUST have only one RFC-3775 compliant binding cache 3775] Binding Update is for de-registration, the receiver MUST delete
entry for the mobile node's home address. If the Binding Update is all existing bindings from its Binding Cache.
for de-registration, the receiver MUST delete all existing bindings
from its Binding Cache.
If the Binding Update contains a Binding Identifier mobility If the Binding Update contains a Binding Identifier mobility
option(s), it is first validated according to section 9.5.1 of [RFC- option(s), it is first validated according to section 9.5.1 of [RFC-
3775]. Then the receiver processes the Binding Identifier mobility 3775]. Then the receiver processes the Binding Identifier mobility
option(s) as described in the following steps. option(s) as described in the following steps.
o The length value is examined. The length value MUST be either 4, o The length value is examined. The length value MUST be either 4,
8, or 20 depending on the Care-of Address field. If the length is 8, or 20 depending on the Care-of Address field. If the length is
incorrect, the receiver MUST reject the Binding Update and returns incorrect, the receiver MUST reject the Binding Update and returns
the status value set to [MCOA MALFORMED]. the status value set to [MCOA MALFORMED].
o When the Length value is either 8 or 20, the care-of address MUST o When the Length value is either 8 or 20, the care-of address MUST
be present in the Binding Identifier mobility option. If the be present in the Binding Identifier mobility option. If the
unicast routable address [RFC-3775] is not present in the care-of unicast routable address [RFC-3775] is not present in the care-of
address field, the receiver MUST reject the Binding Identifier address field, the receiver MUST reject the Binding Identifier
mobility option and returns the status value set to [MCOA mobility option and returns the status value set to [MCOA
MALFORMED]. MALFORMED].
o If the Binding Update is protected with IPsec ESP, the care-of
address MUST be present in the Binding Identifier mobility option.
If no address is present in the care-of address field in the
Binding Identifier mobility option, the home agent MUST reject the
Binding Identifier mobility option and returns the status value
set to [MCOA MALFORMED].
o If the care-of address is present in both the alternate care-of
address mobility option and the Binding Identifier mobility option
at the same time, the home agent MUST ignore the alternate care-of
address mobility option and continue processing the Binding Update
with the care-of address from the Binding Identifier mobility
option.
o When multiple Binding Identifier mobility options are present in o When multiple Binding Identifier mobility options are present in
the Binding Update, it is treated as bulk registration. If the the Binding Update, it is treated as bulk registration. If the
receiving node is a correspondent node, it MUST reject the Binding receiving node is a correspondent node, it MUST reject the Binding
Update and returns the status value in the binding Acknowledgement Update and returns the status value in the binding Acknowledgement
set to [MCOA BULK REGISTRATION NOT SUPPORT]. set to [MCOA BULK REGISTRATION NOT SUPPORT].
o If the Lifetime field in the Binding Update is set to zero, the o If the Lifetime field in the Binding Update is set to zero, the
receiving node deletes the binding entry that corresponds to the receiving node deletes the binding entry that corresponds to the
BID in the Binding Identifier mobility option. If the receiving BID in the Binding Identifier mobility option. If the receiving
node does not have an appropriate binding for the BID, it MUST node does not have an appropriate binding for the BID, it MUST
skipping to change at page 32, line 9 skipping to change at page 28, line 41
Section 5.6. Section 5.6.
o If the Lifetime field is not set to zero, the receiving node o If the Lifetime field is not set to zero, the receiving node
registers a binding with the specified BID as a mobile node's registers a binding with the specified BID as a mobile node's
binding. The Care-of address is obtained from the Binding Update binding. The Care-of address is obtained from the Binding Update
packet as follows: packet as follows:
* If the Length value of the Binding Identifier mobility option * If the Length value of the Binding Identifier mobility option
is 20, the care-of address is copied the IPv6 address from the is 20, the care-of address is copied the IPv6 address from the
care-of address field in the Binding Identifier mobility care-of address field in the Binding Identifier mobility
option. When the Length value is 8, the address MUST be the
IPv4 valid address. Detail information can be found in
Section 8.
* If the Length value of the Binding Identifier mobility option
is 4, the care-of address is copied from the source address
field of the IPv6 header of the Binding Update.
* If the Length value of the Binding Identifier mobility option
is 4 and an alternate care-of address is present, the care-of
address is copied from the Alternate Care-of address mobility
option. option.
* When the Length value is 8, the address MUST be the IPv4 valid
address. How to obtain an IPv4 care-of address is described in
Section 8.
o Once the care-of address(es) have been retrieved from the Binding o Once the care-of address(es) have been retrieved from the Binding
Update, the receiving nodes creates new binding(s). Update, the receiving nodes creates new binding(s).
* If the 'O' flag is set in the Binding Update, the home agent * If the 'O' flag is set in the Binding Update, the home agent
removes all the existing bindings and registers the received removes all the existing bindings and registers the received
binding(s). binding(s).
* If the 'O' flag is unset in the Binding Update and the receiver * If the 'O' flag is unset in the Binding Update and the receiver
has a regular binding which does not have BID for the mobile has a regular binding which does not have BID for the mobile
node, it must not process the Binding Update. The receiver node, it must not process the Binding Update. The receiver
should sent a Binding Acknowledgement with status set to [MCOA should sent a Binding Acknowledgement with status set to [MCOA
BID CONFLICT]. NON-MCOA BINDING EXISTS].
* If the receiver already has a binding with the same BID but * If the receiver already has a binding with the same BID but
different care-of address, it MUST update the binding and different care-of address, it MUST update the binding and
respond with a Binding Acknowledgement with status set to 0 respond with a Binding Acknowledgement with status set to 0
[Binding Update accepted]. [Binding Update accepted].
* If the receiver does not have a binding entry for the BID, it * If the receiver does not have a binding entry for the BID, it
registers a new binding for the BID and responds with a Binding registers a new binding for the BID and responds with a Binding
Acknowledgement with status set to 0 [Binding Update accepted]. Acknowledgement with status set to 0 [Binding Update accepted].
skipping to change at page 33, line 23 skipping to change at page 29, line 48
or a Binding Identifier mobility option. If the status value is or a Binding Identifier mobility option. If the status value is
specific to one of bindings in the bulk registration, the status specific to one of bindings in the bulk registration, the status
value MUST be stored in the Status field in the corresponding Binding value MUST be stored in the Status field in the corresponding Binding
Identifier mobility option. In this case, the Status field of the Identifier mobility option. In this case, the Status field of the
Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that
the receiver can examine the Status field of each Binding Identifier the receiver can examine the Status field of each Binding Identifier
mobility option for further operations. Otherwise, the status field mobility option for further operations. Otherwise, the status field
of the Binding Identifier mobility option MUST be set to zero and the of the Binding Identifier mobility option MUST be set to zero and the
home agent status field of the Binding Acknowledgement is used. home agent status field of the Binding Acknowledgement is used.
6.3. Sending Binding Refresh Request 6.3. Sending Binding Acknowledgement for home link registration
The operations described in this section are related to the returning
home using simultaneous use of home and foreign links.
o When the home agent sends the Binding Acknowledgement after
successfully processing the home binding registration, it MUST set
the status value to either 0 [Binding Update Accepted] or to [MCOA
RETURNHOME WO/NDP (TBD)] in the Status field of the Binding
Acknowledgment depending on home agent configuration at the home
link. The new values are:
* Binding Update Accepted (0): Neighbor Discovery Protocol is
permitted for the home address at the home link. This is
regular returning home operation of [RFC-3775]
* MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is
prohibited for the home address at the home link
The respective Binding Identifier mobility options need to be
included in the Binding Acknowledgement.
o If the Binding Update is rejected, the appropriate error value
MUST be set in the status field. In this case, the home agent
operation is the same as [RFC-3775].
o Only if the home agent is certainly the only router in the home
link, it MAY turn off Neighbor Discovery for the requested home
address and responds with the [Binding Update Accepted] status
value to the mobile node. Since the mobile node will not reply to
Neighbor Solicitation for the home address before receiving the
Binding Acknowledgement, the home agent SHOULD use the link-layer
address carried by the Mobility Header Link-Layer Address option
[RFC-5268] in the received Binding Update. After the completion
of the home binding registration, the mobile node starts regular
Neighbor Discovery operations for the home address on the home
link. The neighbor cache entry for the home address is created by
the regular exchange of Neighbor Solicitation and Neighbor
Advertisement.
o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP]
value in the Status field of the Binding Identifier mobility
option. The home agent learns the mobile node's link-layer
address by receiving the Mobility Header link-layer address option
carried by the Binding Update. It stores the link-layer address
as a neighbor cache entry for the mobile node so that it can send
the packets to the mobile node's link-layer address.
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
deployment scenarios. Therefore, even if a home agent is the only
router, it is an implementation and operational choice whether the
home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
WO/NDP].
o If BID option is not included in the Binding Acknowledgement, the
home agent might not recognize the home registration. The home
agent might have processed the home registration Binding Update as
a regular de-registration as described in [RFC-3775] and deletes
all the registered binding cache entries for the mobile node.
Thus, the mobile node SHOULD stop using the interface attached to
foreign link and use only the interface attached to the home link.
6.4. Sending Binding Refresh Request
When a node (home agent or correspondent node) sends a Binding When a node (home agent or correspondent node) sends a Binding
Refresh Request for a particular binding created with the BID, the Refresh Request for a particular binding created with the BID, the
node SHOULD include the Binding Identifier mobility option in the node SHOULD include the Binding Identifier mobility option in the
Binding Refresh Request. The node MAY include multiple Binding Binding Refresh Request. The node MAY include multiple Binding
Identifier mobility options if there are multiple bindings that need Identifier mobility options if there are multiple bindings that need
to be refreshed. to be refreshed.
6.4. Receiving Packets from Mobile Node 6.5. Receiving Packets from Mobile Node
When a node receives packets with a Home Address destination option When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address that from a mobile node, it MUST check that the care-of address that
appears in the source address field of the IPv6 header MUST be equal appears in the source address field of the IPv6 header MUST be equal
to one of the care-of addresses in the binding cache entry. If no to one of the care-of addresses in the binding cache entry. If no
binding is found, the packets MUST be discarded. The node MUST also binding is found, the packets MUST be discarded. The node MUST also
send a Binding Error message as specified in [RFC-3775]. This send a Binding Error message as specified in [RFC-3775]. This
verification MUST NOT be done for a Binding Update. verification MUST NOT be done for a Binding Update.
7. Network Mobility Applicability 7. Network Mobility Applicability
skipping to change at page 35, line 12 skipping to change at page 33, line 12
multiple care-of addresses. [RFC-4980] is a document for an analysis multiple care-of addresses. [RFC-4980] is a document for an analysis
of NEMO multihoming. of NEMO multihoming.
8. DSMIPv6 Applicability 8. DSMIPv6 Applicability
Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to
register an IPv4 care-of address instead of the IPv6 care-of address register an IPv4 care-of address instead of the IPv6 care-of address
when the mobile node is attached to an IPv4-only access network. It when the mobile node is attached to an IPv4-only access network. It
also allows the mobile node to acquire an IPv4 home address in also allows the mobile node to acquire an IPv4 home address in
addition to an IPv6 home address for use with IPv4-only correspondent addition to an IPv6 home address for use with IPv4-only correspondent
nodes. This section describes how multiple care-of address nodes. This section describes how the multiple care-of address
registration works with IPv4 care-of and home addresses. registration works with IPv4 care-of and home addresses.
8.1. IPv4 Care-of Address Registration 8.1. IPv4 Care-of Address Registration
The mobile node can use the extensions described in the document to The mobile node can use the extensions described in the document to
register multiple care-of addresses, even if some of the care-of register multiple care-of addresses, even if some of the care-of
addresses are IPv4 address. addresses are IPv4 address.
Bulk registration MUST NOT be used for the initial binding from an Bulk registration MUST NOT be used for the initial binding
IPv4 care-of address. This is because, the Binding Update and registration from an IPv4 care-of address. This is because, the
Binding Acknowledgement exchange is used to detect NAT on the path Binding Update and Binding Acknowledgement exchange is used to detect
between the mobile node and the home agent. So the mobile node needs NAT on the path between the mobile node and the home agent. So the
to check for a NAT between each IPv4 care-of address and the home mobile node needs to check for a NAT between each IPv4 care-of
agent. address and the home agent.
The Binding Update MUST be sent to the IPv4 home agent address by The Binding Update MUST be sent to the IPv4 home agent address by
using UDP and IPv4 headers as shown in Figure 9. It is similar to using UDP and IPv4 headers as shown in Figure 9. It is similar to
[ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be
used when the BID mobility option is used. used when the BID mobility option is used.
IPv4 header (src=V4ADDR, dst=HA_V4ADDR) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header UDP Header
IPv6 header (src=V6HoA, dst=HAADDR) IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header ESP Header
skipping to change at page 36, line 10 skipping to change at page 34, line 10
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 As shown in Figure 9, IPv4 care-of address will be appeared in
Binding Identifier mobility option. The IPv4 care-of address Binding Identifier mobility option. The IPv4 care-of address
mobility option defined in [ID-DSMIP6] MUST always be omitted. The mobility option defined in [ID-DSMIP6] MUST always be omitted. The
receiver of the Binding Update message for an IPv4 care-of address receiver of the Binding Update message for an IPv4 care-of address
MUST use the IPv4 address stored in the Binding Identifier mobility MUST treat the IPv4 address stored in the Binding Identifier mobility
option instead of the IPv4 care-of address mobility option. option as the one in the IPv4 care-of address mobility option of [ID-
DSMIP6]. If the IPv4 address in the Binding Identifier mobility
option is different from one in the source address field in the IPv4
header of the Binding Update (i.e. V4ADDR in Figure 9), the source
address is used as an IPv4 care-of address. Otherwise, the IPv4
address in the Binding Identifier mobility option is used as an IPv4
care-of address.
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)
- ... - ...
skipping to change at page 39, line 15 skipping to change at page 37, line 15
address. This will also result in new IPsec security associations address. This will also result in new IPsec security associations
being setup for the home address. being setup for the home address.
9.2. Transport Mode IPsec protected messages 9.2. Transport Mode IPsec protected messages
For Mobile IPv6 signaling message protected using IPsec in transport For Mobile IPv6 signaling message protected using IPsec in transport
mode, the use of a particular care-of address among multiple care-of mode, the use of a particular care-of address among multiple care-of
addresses does not matter for IPsec processing. addresses does not matter for IPsec processing.
The home agent processes Mobile Prefix Discovery messages with the The home agent processes Mobile Prefix Discovery messages with the
same rules of data packets described in Section 6.4. same rules of data packets described in Section 6.5.
9.3. Tunnel Mode IPsec protected messages 9.3. Tunnel Mode IPsec protected messages
The use of IPsec in tunnel mode with multiple care-of address The use of IPsec in tunnel mode with multiple care-of address
introduces a few issues that require changes to how the mobile node introduces a few issues that require changes to how the mobile node
and the home agent send and receive tunneled traffic. The route and the home agent send and receive tunneled traffic. The route
optimization mechanism described in [RFC-3775] mandates the use of optimization mechanism described in [RFC-3775] mandates the use of
IPsec protection in tunnel mode for the Home Test Init and Home Test IPsec protection in tunnel mode for the Home Test Init and Home Test
messages. The mobile node and the home agent may also choose to messages. The mobile node and the home agent may also choose to
protect all reverse tunneled payload traffic with IPsec in tunnel protect all reverse tunneled payload traffic with IPsec in tunnel
skipping to change at page 40, line 13 skipping to change at page 38, line 13
agent is sufficient. agent is sufficient.
9.3.2. Tunneled Payload Traffic 9.3.2. Tunneled Payload Traffic
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, the source address used in the
which care-of address is being used. According to [RFC-4306], the outer IPv6 header is irrelevant to IPsec, since the tunnel mode
IPsec implementation on the home agent does not check the source security association is based on the addresses in the inner IPv6
address on the outer IPv6 header. However, the stack on the home header. Therefore, the same IPsec security association can be
agent MUST still be informed about the source address in order to used for payload traffic tunneled from any of the care-of
choose the most recently used care-of address, as discussed in addresses. Note that the care-of address used in the reverse
Section 3 (in the absence of a user-supplied policy) tunneld traffic can be different from the care-of address used as
the source address in the IKEv2 exchange. However, this does not
cause an issue due to the above mentioned reason.
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 will 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, based on
the tunnel end point for the IPsec tunnel. This may require tight the binding cache entries created by the mobile node, knows which
integration between the IPsec and Mobile IP implementations on the care-of address the packet belonging to a particular flow needs to
home agent. be tunneled to. The destination address for the outer IP header
must either by conveyed dynamically per packet to the IPsec stack
when it performs the encapsulation or the Mobile IPv6 stack must
get access to the packet after IPsec processing is done and modify
the destination address. The first option requires changes to the
IPsec implementation. In the second option, there is a need for
special processing in the forwarding function to replace the
destination address on the outer header with the correct care-of
address. The exact technique to achieve the above is
implementation specific.
10. Security Considerations 10. Security Considerations
The security considerations for securing the Binding Update and The security considerations for securing the Binding Update and
Binding Acknowledgement messages with multiple care-of address are Binding Acknowledgement messages with multiple care-of address are
very similar to the security considerations for securing the Binding very similar to the security considerations for securing the Binding
Update and Binding Acknowledgement. Please see [RFC-3775] for more Update and Binding Acknowledgement. Please see [RFC-3775] for more
information. The Binding Update and binding Acknowledgement messages information. The Binding Update and binding Acknowledgement messages
with multiple care-of addresses are securely exchanged as described with multiple care-of addresses are securely exchanged as described
in [RFC-3775], [RFC-4877] and Section 9. Additional security in [RFC-3775], [RFC-4877] and Section 9. Additional security
skipping to change at page 43, line 26 skipping to change at page 41, line 26
* MCOA NOTCOMPLETE (TBD) * MCOA NOTCOMPLETE (TBD)
* MCOA RETURNHOME WO/NDP (TBD) * MCOA RETURNHOME WO/NDP (TBD)
o New Unsuccessful Status of Binding Acknowledgement: These status o New Unsuccessful Status of Binding Acknowledgement: These status
codes must also be assigned from the same space as Binding codes must also be assigned from the same space as Binding
Acknowledgement status codes in [RFC-3775]. Acknowledgement status codes in [RFC-3775].
* MCOA MALFORMED (TBD) * MCOA MALFORMED (TBD)
* MCOA BID CONFLICT (TBD) * MCOA NON-MCOA BINDING EXISTS (TBD)
* MCOA PROHIBITED(TBD) * MCOA PROHIBITED(TBD)
* MCOA UNKNOWN COA(TBD)
* MCOA BULK REGISTRATION PROHIBITED (TBD) * MCOA BULK REGISTRATION PROHIBITED (TBD)
* MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD) * MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD)
12. Acknowledgements 12. Acknowledgements
The authors would like to special thank George Tsirtsis for thorough The authors would also like to thank Masafumi Aramoto, Keigo Aso,
review and suggestions. The authors would also like to thank Julien Charbon, Tero Kauppinen, Benjamin Lim, Martti Kuparinen,
Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Romain Kuntz, Heikki Mahkonen, Nicolas Montavont, Chan-Wah Ng for
Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas their discussions and inputs. Thanks to Susumu Koshiba, Hiroki
Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Uehara, Masafumi
Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Watari and Jun Murai for earlier work on this subject.
Uehara, Masafumi Watari and Jun Murai for earlier work on this
subject.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman,
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September
skipping to change at page 45, line 17 skipping to change at page 43, line 15
[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
Multihoming in Network Mobility Support", RFC 4980, October 2007. Multihoming in Network Mobility Support", RFC 4980, October 2007.
[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008.
[ID-FLOWBINDING] H. Soliman, N. Montavont, N. Fikouras, and K. [ID-FLOWBINDING] H. Soliman, N. Montavont, N. Fikouras, and K.
Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-ietf-mext-flow-binding-00 (Work in progress), May 2008. draft-ietf-mext-flow-binding-01 (Work in progress), February 2009.
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC-4306] C. Kaufman (Editor), "Internet Key Exchange (IKEv2) [RFC-4306] C. Kaufman (Editor), "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa (Editor)
Toyota ITC / Keio University TOYOTA InfoTechnology Center Co., Ltd.
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276 Email: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Vijay Devarapalli Vijay Devarapalli
Wichorus Wichorus
3590 North First St
San Jose, CA 95134
USA
Email: vijay@wichorus.com Email: vijay@wichorus.com
George Tsirtsis
Qualcomm
Email: Tsirtsis@gmail.com
Thierry Ernst Thierry Ernst
INRIA INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr Email: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry
Kenichi Nagami Kenichi Nagami
INTEC NetCore Inc. INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
Japan
Phone: +81-3-5565-5069
Fax: +81-3-5565-5094
Email: nagami@inetcore.com Email: nagami@inetcore.com
 End of changes. 73 change blocks. 
409 lines changed or deleted 294 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/