draft-ietf-monami6-multiplecoa-02.txt   draft-ietf-monami6-multiplecoa-03.txt 
Monami6 Working Group R. Wakikawa Monami6 Working Group R. Wakikawa
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track T. Ernst Intended status: Standards Track T. Ernst
Expires: September 6, 2007 INRIA Expires: January 10, 2008 INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli V. Devarapalli
Azaire Networks Azaire Networks
March 5, 2007 July 9, 2007
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-02.txt draft-ietf-monami6-multiplecoa-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 6, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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, termed the primary have several care-of addresses, but only one, termed the primary
care-of address, can be registered with its home agent and the care-of address, can be registered with its home agent and the
skipping to change at page 3, line 20 skipping to change at page 3, line 20
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Multiple Care-of Addresses Registration . . . . . . . . . 7 3.1. Multiple Care-of Addresses Registration . . . . . . . . . 7
3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 7 3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 7
3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 8
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10
4.1. Binding Cache Structure and Binding Update List . . . . . 10 4.1. Binding Cache Structure and Binding Update List . . . . . 10
4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10
4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10 4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10
4.2.2. Binding Acknowledgment . . . . . . . . . . . . . . . . 13 4.2.2. Binding Acknowledgment . . . . . . . . . . . . . . . . 12
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14
5.1. Management of Care-of Addresses and Binding Unique 5.1. Management of Care-of Addresses and Binding Unique
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 14 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 14
5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 15 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 15
5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 16 5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 16
5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16
5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Using Alternate care-of address . . . . . . . . . . . . . 18 5.7. Using Alternate care-of address . . . . . . . . . . . . . 18
5.8. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18 5.8. Receiving Binding Acknowledgment . . . . . . . . . . . . . 19
5.9. Receiving Binding Refresh Request . . . . . . . . . . . . 19 5.9. Receiving Binding Refresh Request . . . . . . . . . . . . 20
5.10. Sending Packets to Home Agent . . . . . . . . . . . . . . 20 5.10. Sending Packets to Home Agent . . . . . . . . . . . . . . 20
5.11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20 5.11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21
6. Home Agent and Correspondent Node Operation . . . . . . . . . 21 6. Home Agent and Correspondent Node Operation . . . . . . . . . 22
6.1. Searching Binding Cache with Binding Unique Identifier . . 21 6.1. Searching Binding Cache with Binding Unique Identifier . . 22
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 22
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 23
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 26
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 26
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 27
8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27 8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 28
8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27 8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 28
8.2. Transport Mode IPsec protected messages . . . . . . . . . 28 8.2. Transport Mode IPsec protected messages . . . . . . . . . 29
8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28 8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 29
8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28 8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 29
8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29 8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Example Configurations . . . . . . . . . . . . . . . 33 Appendix A. Example Configurations . . . . . . . . . . . . . . . 34
Appendix B. Changes From Previous Versions . . . . . . . . . . . 39 Appendix B. Changes From Previous Versions . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 40
1. Introduction 1. Introduction
A mobile node should use various type of network interfaces to obtain A mobile node should use various type of network interfaces to obtain
durable and wide area network connectivity. Assumed scenarios and durable and wide area network connectivity. Assumed scenarios and
motivations for multiple points of attachment, and benefits for doing motivations for multiple points of attachment, and benefits for doing
it are discussed at large in [10]. it are discussed at large in [10].
IPv6 [1] conceptually allows a node to have several addresses on a IPv6 [1] conceptually allows a node to have several addresses on a
given interface. Consequently, Mobile IPv6 [2] has mechanisms to given interface. Consequently, Mobile IPv6 [2] has mechanisms to
skipping to change at page 9, line 17 skipping to change at page 9, line 17
Identifier sub-option. The receiver of the de-registration Binding Identifier sub-option. The receiver of the de-registration Binding
Update deletes only the relative binding entry from the binding cache Update deletes only the relative binding entry from the binding cache
database. The home agent does not stop proxying neighbor database. The home agent does not stop proxying neighbor
advertisement as long as there are still bindings for the other advertisement as long as there are still bindings for the other
interfaces. It is important to understand that this scenario is not interfaces. It is important to understand that this scenario is not
the most efficient because all the traffic from and to the mobile the most efficient because all the traffic from and to the mobile
node is going through the bi-directional tunnel, whereas the mobile node is going through the bi-directional tunnel, whereas the mobile
node is now accessible at one hop from its HA. node is now accessible at one hop from its HA.
In the above two cases, a mobile node cannot use interfaces attached In the above two cases, a mobile node cannot use interfaces attached
to both home and foreign links simultaneously. If this is what a to both home and foreign links simultaneously. This restriction is
mobile node wants, a home agent can set up another link other than related to the Proxy NDP operation on a Home Agent. The Home Agent
home link and uses the link for the mobile node to return virtually needs to defend a mobile node's home address by the proxy NDP for
to home network. Even though packets from and to the mobile node are packet interception, while the mobile node defends its home address
routed via the home agent, the hop count is kept in one. The by regular NDP to send and receive packets at the interface attached
overhead should be negligible since it is only for an additional IPv6 to the home link. Two nodes, Home Agent and Mobile Node, compete ND
header and processing tunnel (encapsulation and decapsulation) per state. This will causes address duplication problem at the end.
packets. The detail can be found in Figure 7 This document recommends not to use the Proxy NDP for this scenario.
When one of the Mobile Node's interface is attached to the home link
and the other is attached to the foreign link and it decides to
utilize both interfaces, it notifies the Home Agent using the H flag
which means the Mobile Node is attached to the home link. If the
proxy NDP is disabled, the main problem can be solved. In the
Multiple Care-of Address Registration case, the elimination of Proxy
NDP enable that Mobile Node and Home Agent maintain multiple
bindings, one of the Mobile Node's interface is attached to the home
link and the other is attached to the foreign link.
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
In this section are described the changes to Mobile IPv6 necessary to In this section are described the changes to Mobile IPv6 necessary to
manage multiple bindings bound to a same Home Address. manage multiple bindings bound to a same Home Address.
4.1. Binding Cache Structure and Binding Update List 4.1. Binding Cache Structure and Binding Update List
The following additional items are required in the binding cache and The following additional items are required in the binding cache and
binding update list structure. binding update list structure.
BID BID
The value MUST be zero if the Binding Unique identifier does not The value MUST be zero if the Binding Unique identifier does not
appear in a Binding Update. appear in a Binding Update.
Priority of the Binding Cache Entry
A value of zero indicates No Priority. A value of 255 indicates
that the binding corresponding to this BID is a default of this
mobile node. The detail can be found in Figure 1. This
information is used by [12].
4.2. Message Format Changes 4.2. Message Format Changes
4.2.1. Binding Unique Identifier sub-option 4.2.1. Binding Unique Identifier sub-option
The Binding Unique Identifier sub-option is included in the Binding The Binding Unique Identifier sub-option is included in the Binding
Update, Binding Acknowledgment, Binding Refresh Request, and Care-of Update, Binding Acknowledgment, Binding Refresh Request, and Care-of
Test Init and Care-of Test message. Test Init and Care-of Test message.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) |Priority/Status|C|O| Reserved | | Binding Unique ID (BID) | Status |C|O|H|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
+ care-of address (CoA) + + care-of address (CoA) +
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: BID Sub-Option Figure 1: BID Sub-Option
Type Type
Type value for Binding Unique Identifier will be assigned later. Type value for Binding Unique Identifier will be assigned later.
Length Length
Length value MUST be 4 when C flag is unset. On the other hand if Length value MUST be 4 when C flag is unset. On the other hand if
C flag is set, Length value MUST be set to 20. C flag is set, Length value MUST be set to 20.
Binding Unique ID (BID) Binding Unique ID (BID)
The BID which is assigned to the binding carried in the Binding The BID which is assigned to the binding carried in the Binding
Update with this sub-option. BID is 16-bit unsigned integer. A Update with this sub-option. BID is 16-bit unsigned integer. A
value of zero is reserved. value of zero is reserved.
Priority/Status Status
When the Binding Unique Identifier sub-option is included in a
Binding Update, this field indicates the priority field assigned
to each binding. The receiver can utilize this priority to
determine which binding is used to deliver packets. The priority
is 8-bit unsigned integer. The higher value has higher priority.
Values of zero and 255 are reserved for special meaning.
A value of zero indicates No Priority. A value of 255 indicates
that the binding corresponding to this BID is a default of this
mobile node. This default binding is used by the flow binding
scheme [12]. If the receiver cannot recognize 255, it MUST ignore
this field.
When the Binding Unique Identifier sub-option is included in a When the Binding Unique Identifier sub-option is included in a
Binding Acknowledgment, this field indicates the status Binding Acknowledgment, this field indicates the status
correspondent to each binding. The mobile node knows the correspondent to each binding. The mobile node knows the
registration status of each binding. The status is 8-bit unsigned registration status of each binding. The status is 8-bit unsigned
integer. The possible status codes are listed below. If the integer. The possible status codes are listed below. If the
status field is below 128, it indicates that the binding status field is below 128, it indicates that the binding
registration was successful. registration was successful.
MCOA ACCEPTING BID (0) MCOA ACCEPTING BID (0)
skipping to change at page 12, line 17 skipping to change at page 11, line 43
Registration failed because Binding Unique Identifier sub- Registration failed because Binding Unique Identifier sub-
option is not compliant. option is not compliant.
MCOA BID CONFLICT (130) MCOA BID CONFLICT (130)
It indicates that a regular binding (ie without the BID set) is It indicates that a regular binding (ie without the BID set) is
already registered for the home address, and is conflicting already registered for the home address, and is conflicting
with a received Binding Update which BID was set. with a received Binding Update which BID was set.
MCOA BULK REGISTRATION PROHIBITED (131)
The C flag can be set only if a Binding Unique Identifier sub-
option is presented only in a Binding Update or a Binding
Acknowledgment.
care-of address (C) flag care-of address (C) flag
When this flag is set, a mobile node can store a Care-of Address When this flag is set, a mobile node can store a Care-of Address
corresponding to the BID in the Binding Unique Identifier sub- corresponding to the BID in the Binding Unique Identifier sub-
option. This flag must be used whenever a mobile node sends option. This flag must be used whenever a mobile node sends
multiple bindings in a single Binding Update, i.e. bulk multiple bindings in a single Binding Update, i.e. bulk
registration. registration.
Overwrite (O) flag Overwrite (O) flag
When this flag is set, a mobile node requests a home agent to When this flag is set, a mobile node requests a home agent to
replace all the bindings to binding entries stored in a Binding replace all the bindings to binding entries stored in a Binding
Update. This flag is valid for Home Registration and Update. This flag is valid for Home Registration and
Deregistration. Deregistration.
Home Binding (H) flag
This flag indicates that the mobile node is attached to the home
link. This flag is valid for Home Registration, Deregistration
and bulk registration.
Reserved Reserved
6 bits Reserved field. Reserved field must be set with all 0. 5 bits Reserved field. Reserved field must be set with all 0.
Care-of Address Care-of Address
Only when C flag is set, only a single Care-of Address matched to Only when C flag is set, only a single Care-of Address matched to
the BID is stored. This field is valid only if a Binding Unique the BID is stored. This field is valid only if a Binding Unique
Identifier sub-option is stored in Binding Update message. Identifier sub-option is stored in Binding Update message.
Otherwise, this field can be omitted. The receiver SHOULD ignore Otherwise, this field can be omitted. The receiver SHOULD ignore
this field if the sub-option is presented in other than Binding this field if the sub-option is presented in other than Binding
Update. Update.
skipping to change at page 14, line 43 skipping to change at page 14, line 43
5.2. Return Routability: Sending CoTI and Receiving CoT 5.2. Return Routability: Sending CoTI and Receiving CoT
When a mobile node wants to register bindings to a Correspondent When a mobile node wants to register bindings to a Correspondent
Node, it MUST send a CoTI per care-of address, while the HoTI and HoT Node, it MUST send a CoTI per care-of address, while the HoTI and HoT
can be exchanged only once for a Home Address. If the Mobile Node can be exchanged only once for a Home Address. If the Mobile Node
manages bindings with BID, it MUST include a Binding Unique manages bindings with BID, it MUST include a Binding Unique
Identifier sub-option in a Care-of Test Init message. It MUST NOT Identifier sub-option in a Care-of Test Init message. It MUST NOT
set the C and O flag in the sub-option. set the C and O flag in the sub-option.
The receiver (i.e. correspondent node) will calculate a care-of The receiver (i.e. correspondent node) will calculate a care-of
keygen token with the received BID and reply a Care-of Test message keygen token as specified in [2] and reply a Care-of Test message
which contains a Binding Unique Identifier sub-option as described in which contains a Binding Unique Identifier sub-option as described in
Section 6.2. When the mobile node receives the Care-of Test message, Section 6.2. When the mobile node receives the Care-of Test message,
the Care-of Test message is verified as same as in [2] and the the Care-of Test message is verified as same as in [2] and the
Binding Unique Identifier sub-option in the Care-of Test MUST be Binding Unique Identifier sub-option in the Care-of Test MUST be
processed as follows: processed as follows:
o If a Binding Unique Identifier sub-option is not presented in CoT o If a Binding Unique Identifier sub-option is not presented in CoT
in reply to the CoTI containing the Binding Unique Identifier sub- in reply to the CoTI containing the Binding Unique Identifier sub-
option, a correspondent node does not support the Multiple Care-of option, a correspondent node does not support the Multiple Care-of
Address registration. Thus, the mobile node MUST NOT use a Address registration. Thus, the mobile node MUST NOT use a
Binding Unique Identifier sub-option in the Binding Update. It Binding Unique Identifier sub-option in the Binding Update. It
MUST send a regular Binding Update (i.e. no BID) to the MUST send a regular Binding Update (i.e. no BID) to the
correspondent node [2]. The Mobile Node MAY skip resending correspondent node [2]. The Mobile Node MAY skip resending
regular CoTI message and use the received care-of keygen token for regular CoTI message and use the received care-of keygen token for
the regular Binding Update, because the correspondent node just the regular Binding Update, because the correspondent node just
ignores and skip the Binding Unique Identifier sub-option and ignores and skip the Binding Unique Identifier sub-option and
calculates the care-of keygen token as [2] specified. calculates the care-of keygen token as [2] specified.
o If the status field of a Binding Unique Identifier sub-option is o If the status field of a Binding Unique Identifier sub-option is
set to [MCOA BULK REGISTRATION PROHIBITED], the care-of keygen set to [MCOA INCOMPLIANT], the received care-of keygen token MUST
token MUST NOT be used for a Binding Update. It MUST re-send a NOT be used for sending a Binding Update. It MUST re-send a
Care-of Test Init message again with a corrected Binding Unique Care-of Test Init message again with a corrected Binding Unique
Identifier sub-option (i.e. C flag MUST be unset). Identifier sub-option which C flag MUST be unset.
o If the status field is set to less than 128, it sends a Binding o If the status field is set to less than 128, it sends a Binding
Update through Return Routability procedure. Update through Return Routability procedure.
The computation of MAC is the same as the one in [2] except for
calculation of a care-of keygen token. The calculation of a care-of
keygen token is modified as follows. BID is used to generate the
care-of keygen token.
care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address |
nonce | BID | 1)))
5.3. Binding Registration 5.3. Binding Registration
When a mobile node sends a Binding Update, it MUST decide whether it When a mobile node sends a Binding Update, it MUST decide whether it
registers multiple care-of addresses or not. However, this decision registers multiple care-of addresses or not. However, this decision
is out-of scope in this document. If a mobile node decides not to is out-of scope in this document. If a mobile node decides not to
register multiple care-of addresses, it completely follows the register multiple care-of addresses, it completely follows the
standard RFC 3775 specification. standard RFC 3775 specification.
If a mobile node needs to register multiple Care-of Addresses, it If a mobile node needs to register multiple Care-of Addresses, it
MUST use BID to identify a care-of address. The mobile node includes MUST use BID to identify a care-of address. The mobile node includes
skipping to change at page 18, line 8 skipping to change at page 17, line 50
proxy neighbor advertisement and the mobile node also enables the proxy neighbor advertisement and the mobile node also enables the
same Home Address on the home link. After disabling the interface same Home Address on the home link. After disabling the interface
attached to the home link, the mobile node MUST delete the binding attached to the home link, the mobile node MUST delete the binding
for the interface by sending a de-registration binding update. The for the interface by sending a de-registration binding update. The
de-registration binding update must be sent from one of active de-registration binding update must be sent from one of active
interfaces attached to foreign links. As a result, the mobile node interfaces attached to foreign links. As a result, the mobile node
no longer receives packets at the interface attached to the home no longer receives packets at the interface attached to the home
link. All packets are routed to other interfaces attached to a link. All packets are routed to other interfaces attached to a
foreign link. foreign link.
Alternatively, the Mobile Node may choose to activate both the
interfaces attached to the home link and the foreign link, and
communicates with all of the interfaces. The Mobile Node notifies
the Home Agent using the H flag which means the Mobile Node is
attached to the home link. The Mobile Node may notify the care-of
address of the interface(s) attached to the foreign link(s) in the
same message using bulk registration. The Home Agent then no longer
uses Proxy Neighbor Advertisement to intercept packets and the Mobile
Node can utilize both of interfaces attached to the home link and the
foreign link simultaneously. The Home Agent can intercept packets by
IP routing, but not by proxy Neighbor Discovery.
When the Mobile Node returns home, it de-registers a binding for the
interface. While the bindings for the interfaces attached to the
foreign link are still active. Intercepting packets, the Home Agent
can decide whether it tunnels to the foreign interface or routes to
the home interface of the Mobile Node. To do so, the Home Agent must
know that the Mobile Node is back to the home link. However, if the
binding is deleted according to [2], there is no way for the Home
Agent to know that the Mobile Node is at the home, too. The Home
Agent SHOULD invalidate the binding for the interface attached to the
home link and MAY NOT delete it. It can alternatively mark that the
Mobile Node is at the home link, too. As an example, the Home Agent
inserts the Home Address of the Mobile Node in the Care-of Address
field of the Mobile Node. The binding is named "Home Binding" in
this doc. The Home Agent MAY manage this home binding as same as the
other binding entry in terms of lifetime validation, etc. The Mobile
Node MAY send multiple binding de- registration to keep this home
binding active. Alternatively, the Home Agent can use infinity
lifetime for the lifetime of the home binding. When the Mobile Node
leaves the Home Link, it can update the home binding to the normal
binding. Before that, the Home Agent believes the Mobile Node is at
the home and may route packets for the Mobile Node to the Home Link.
5.7. Using Alternate care-of address 5.7. Using Alternate care-of address
A mobile node can use an alternate care-of address in a following A mobile node can use an alternate care-of address in a following
situation. One care-of address becomes invalid (e.g because the link situation. One care-of address becomes invalid (e.g because the link
where it is attached to is no longer available) and MUST be deleted. where it is attached to is no longer available) and MUST be deleted.
In such case, the mobile node can not send a Binding Update from the In such case, the mobile node can not send a Binding Update from the
care-of address because the interface's link is lost. The mobile care-of address because the interface's link is lost. The mobile
node needs to de-register the remote binding of the care-of address node needs to de-register the remote binding of the care-of address
through one of its active care-of addresses. through one of its active care-of addresses.
skipping to change at page 21, line 17 skipping to change at page 22, line 17
6.1. Searching Binding Cache with Binding Unique Identifier 6.1. Searching Binding Cache with Binding Unique 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. How to select the the bindings to communicate with the mobile node. How to select the
most suitable binding from the binding cache database is out of scope most suitable binding from the binding cache database is out of scope
in this document. in this document.
Whenever a correspondent node searches a binding cache for a home Whenever a correspondent node searches a binding cache for a home
address, it SHOULD uses both the Home Address and the BID as the address, it SHOULD uses both the Home Address and the BID as the
search key if it knows the corresponding BID. If the priority is search key if it knows the corresponding BID. In the example below,
available for a binding cache entry, the priority can be used as if a correspondent node searches the binding with the Home Address
additional key to search a binding. In the example below, if a and BID2, it gets binding2 for this mobile node.
correspondent node searches the binding with the Home Address and
BID2, it gets binding2 for this mobile node.
binding1 [a:b:c:d::EUI, care-of address1, BID1] binding1 [a:b:c:d::EUI, care-of address1, BID1]
binding2 [a:b:c:d::EUI, care-of address2, BID2] binding2 [a:b:c:d::EUI, care-of address2, BID2]
binding3 [a:b:c:d::EUI, care-of address3, BID3] binding3 [a:b:c:d::EUI, care-of address3, BID3]
Figure 2: Searching the Binding Cache Figure 2: Searching the Binding Cache
A correspondent node basically learns the BID when it receives a A correspondent node basically learns the BID when it receives a
Binding Unique Identifier sub-option. At the time, the correspondent Binding Unique Identifier sub-option. At the time, the correspondent
node MUST look up its binding cache database with the Home Address node MUST look up its binding cache database with the Home Address
skipping to change at page 22, line 17 skipping to change at page 23, line 17
calculation of a care-of keygen token will thus be done without a calculation of a care-of keygen token will thus be done without a
BID value. After regular processing of HoTI message according to BID value. After regular processing of HoTI message according to
[2], it will return a Care-of Test message without use of a [2], it will return a Care-of Test message without use of a
Binding Unique Identifier sub-option. The mobile node can thus Binding Unique Identifier sub-option. The mobile node can thus
know whether its correspondent can process or not the Binding know whether its correspondent can process or not the Binding
Unique Identifier sub-option by checking if such option is present Unique Identifier sub-option by checking if such option is present
in the Care-of Test message. in the Care-of Test message.
o If C flag is set in the sub-option, the Correspondent Node SHOULD o If C flag is set in the sub-option, the Correspondent Node SHOULD
NOT calculate a care-of keygen token and MUST include a Binding NOT calculate a care-of keygen token and MUST include a Binding
Unique Identifier sub-option which status value set to [MCOA BULK Unique Identifier sub-option which status value set to [MCOA
REGISTRATION PROHIBITED] in the returned Care-of Test message. INCOMPLIANT] in the returned Care-of Test message. All the fields
All the fields of the Care-of Test message MUST be set to zero. of the Care-of Test message MUST be set to zero. All the Binding
All the Binding Unique Identifier sub-options SHOULD be copied Unique Identifier sub-options SHOULD be copied from the received
from the received one except for the Status Field and the Care-of one except for the Status Field and the Care-of Address field.
Address field.
o If O flag is set in the sub-option, the Correspondent Node can o If O flag is set in the sub-option, the Correspondent Node can
ignore this flag and can process it as described in the next ignore this flag and can process it as described in the next
bullet. bullet.
o Otherwise, the correspondent node MUST include a Binding Unique o Otherwise, the correspondent node MUST include a Binding Unique
Identifier sub-option which status value MUST be set to [MCOA Identifier sub-option which status value MUST be set to [MCOA
ACCEPTING BID] in the returning a Care-of Test message. The ACCEPTING BID] in the returning a Care-of Test message. The
Binding Unique Identifier sub-option SHOULD be copied from the Binding Unique Identifier sub-option SHOULD be copied from the
received one except for the Status Field and the Care-of address received one except for the Status Field and the Care-of address
Field. Field.
The calculation of a care-of keygen token is modified as follows.
The BID is used to generate the care-of keygen token.
care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address |
nonce | BID | 1)))
6.3. Processing Binding Update 6.3. Processing Binding Update
If a Binding Update does not contain a Binding Unique Identifier sub- If a Binding Update does not contain a Binding Unique Identifier sub-
option, its processing is same as in RFC 3775. But if the receiver option, its processing is same as in RFC 3775. But 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 existing bindings by the received binding. As a result, the all existing bindings by the received binding. As a result, the
receiver node MUST have only a binding for the mobile node. If the receiver node MUST have only a binding for the mobile node. If the
Binding Update is for de-registration, the receiver MUST delete all Binding Update is for de-registration, the receiver MUST delete all
existing bindings from its Binding Cache. existing bindings from its Binding Cache.
skipping to change at page 24, line 4 skipping to change at page 24, line 46
o If the Lifetime field of the Binding Update is zero, the receiver o If the Lifetime field of the Binding Update is zero, the receiver
node deletes the binding entry which BID is same as BID sent by node deletes the binding entry which BID is same as BID sent by
the Binding Unique Identifier sub-option. If the receiver node the Binding Unique Identifier sub-option. If the receiver node
does not have appropriate binding which BID is matched with the does not have appropriate binding which BID is matched with the
Binding Update, it MUST reject this de-registration Binding Binding Update, it MUST reject this de-registration Binding
Update. If the receiver is a Home Agent, it SHOULD also return a Update. If the receiver is a Home Agent, it SHOULD also return a
Binding Acknowledgment to the mobile node, in which the Status Binding Acknowledgment to the mobile node, in which the Status
field is set to [not Home Agent for this mobile node, 133]. If O field is set to [not Home Agent for this mobile node, 133]. If O
flag is set in the deregistering Binding Update, the receiver can flag is set in the deregistering Binding Update, the receiver can
ignore this flag for deregistration. ignore this flag for deregistration. If the H flag is set, the
home agent stores a Home Address in the Care-of Address field of
the binding cache entry. The home agent no longer performs proxy
NDP for this mobile node until this entry is deleted.
o If the Lifetime field is not zero, the receiver node registers a o If the Lifetime field is not zero, the receiver node registers a
binding with the specified BID as a mobile node's binding. The binding with the specified BID as a mobile node's binding. The
Care-of address is picked from the Binding Update packet as Care-of address is picked from the Binding Update packet as
follows: follows:
* If C flag is set in the Binding Unique Identifier sub-option, * If C flag is set in the Binding Unique Identifier sub-option,
the care-of address must be taken from the care-of address the care-of address must be taken from the care-of address
field in each Binding Unique Identifier sub-option. field in each Binding Unique Identifier sub-option.
skipping to change at page 30, line 7 skipping to change at page 31, line 7
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.
9. Security Considerations 9. Security Considerations
TBD As shown in Section 8, the Multiple Care-of Addresses Registration
requires IPsec protected all the signalings between a mobile node and
its home agent.
10. IANA Considerations 10. IANA Considerations
TBD The following Extension Types MUST be assigned by IANA:
1. Binding Unique Identifier sub-option type
2. New Status of Binding Acknowledgement
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Masafumi Aramoto (Sharp Corporation), The authors would like to thank Masafumi Aramoto (Sharp Corporation),
Julien Charbon, Tero Kauppinen (Ericsson), Susumu Koshiba, Martti Keigo Aso (Panasonic), Julien Charbon, Tero Kauppinen (Ericsson),
Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen Benjamin Koh (Panasonic), Susumu Koshiba, Martti Kuparinen
(Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki
Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U), Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji
Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab. Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D)
at KEIO University, and WIDE project for their contributions. in alphabetical order, the Jun Murai Lab. at KEIO University.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Deering, S. and R. Hinden, "Internet Protocol Version 6 [1] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6)", IETF RFC 2460, December 1998. (IPv6)", IETF RFC 2460, December 1998.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
skipping to change at page 33, line 18 skipping to change at page 34, line 18
Kuladinithi, "Motivations and Scenarios for Using Multiple Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-01 (work in draft-ietf-monami6-multihoming-motivation-scenario-01 (work in
progress), October 2006. progress), October 2006.
[11] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming [11] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming
in Network Mobility Support", in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-06 (work in progress), draft-ietf-nemo-multihoming-issues-06 (work in progress),
June 2006. June 2006.
[12] Soliman, H., "Flow Bindings in Mobile IPv6",
draft-soliman-monami6-flow-binding-02 (work in progress),
September 2006.
Appendix A. Example Configurations Appendix A. Example Configurations
In this section, we describe typical scenarios when a mobile node has In this section, we describe typical scenarios when a mobile node has
multiple network interfaces and acquires multiple Care-of Addresses multiple network interfaces and acquires multiple Care-of Addresses
bound to a Home Address. bound to a Home Address. The Home Address of the mobile node (MN in
figures) is a:b:c:d::EUI. MN has 3 different interfaces and possibly
The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI. acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns
MN has 3 different interfaces and possibly acquires care-of addresses BID1, BID2 and BID3 to each care-of address.
1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each
care-of address.
Figure 3 depicts the scenario where all interfaces of the mobile node
are attached to foreign links. After binding registrations, the home
agent (HA) and the Correspondent Node (CN) have the binding entries
listed in their binding cache database. The mobile node can utilize
all the interfaces.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+---+-+ +--+-+ | +----+---+-+ +--+-+
CoA2| | | | Home Link CoA2| | | | Home Link
+--+--+ | | ------+------ +--+--+ | | ------+------
skipping to change at page 34, line 28 skipping to change at page 35, line 4
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active) home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 3: Multiple Interfaces Attached to a Foreign Link Figure 3: Multiple Interfaces Attached to a Foreign Link
Figure 4 depicts the scenario where MN returns home with one of its Figure 3 depicts the scenario where all interfaces of the mobile node
interfaces. After the successful de-registration of the binding to are attached to foreign links. After binding registrations, the home
HA, HA and CN have the binding entries listed in their binding cache agent (HA) and the Correspondent Node (CN) have the binding entries
database of Figure 4. MN can communicate with the HA through only listed in their binding cache database. The mobile node can utilize
the interface attached to the home link. On the other hand, the all the interfaces.
mobile node can communicate with CN from the other interfaces
attached to foreign links (i.e. route optimization). Even when MN is
attached to the home link, it can still send Binding Updates for
other active care-of addresses (CoA2 and CoA3). If CN has bindings,
packets are routed to each Care-of Addresses directly. Any packet
arrived at HA are routed to the primary interface.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +--------+-+ +--+-+ | +--------+-+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
+--+--+ | --+---+------ +--+--+ | --+---+------
skipping to change at page 35, line 28 skipping to change at page 35, line 35
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is inactive) home agent's binding (Proxy neighbor advertisement is inactive)
none none
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 4: One of Interface Attached to Home Link and Returning Home Figure 4: One of Interface Attached to Home Link and Returning Home
Figure 5 depicts the scenario where MN disables the interface Figure 4 depicts the scenario where MN returns home with one of its
attached to the home link and communicates with the interfaces interfaces. After the successful de-registration of the binding to
attached to foreign links. The HA and the CN have the binding HA, HA and CN have the binding entries listed in their binding cache
entries listed in their binding cache database. MN disable the database of Figure 4. MN can communicate with the HA through only
interface attached to the home link, because the HA still defends the the interface attached to the home link. On the other hand, the
home address of the MN by proxy neighbor advertisements. All packets mobile node can communicate with CN from the other interfaces
routed to the home link are intercepted by the HA and tunneled to the attached to foreign links (i.e. route optimization). Even when MN is
other interfaces attached to the foreign link according to the attached to the home link, it can still send Binding Updates for
binding entries. other active care-of addresses (CoA2 and CoA3). If CN has bindings,
packets are routed to each Care-of Addresses directly. Any packet
arrived at HA are routed to the primary interface.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+-----+ +--+-+ | +----+-----+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
+--+--+ | --+---+------ +--+--+ | --+---+------
skipping to change at page 36, line 31 skipping to change at page 36, line 31
home agent's binding (Proxy neighbor advertisement is active) home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
Figure 5: One of Interface Attached to Home Link and Not Returning Figure 5: One of Interface Attached to Home Link and Not Returning
Home Home
Figure 6 depicts the scenario where multiple interfaces of MN are Figure 5 depicts the scenario where MN disables the interface
attached to the home link. The HA and CN have the binding entries attached to the home link and communicates with the interfaces
listed in Figure 6 in their binding cache database. The MN can not attached to foreign links. The HA and the CN have the binding
use the interface attached to a foreign link unless a CN has a entries listed in their binding cache database. MN disable the
binding for the interface. All packets which arrive at the HA are interface attached to the home link, because the HA still defends the
routed to one of the MN's interfaces attached to the home link. home address of the MN by proxy neighbor advertisements. All packets
routed to the home link are intercepted by the HA and tunneled to the
other interfaces attached to the foreign link according to the
binding entries.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----------+ +--+-+ | +----------+ +--+-+
CoA2| | Home Link CoA2| | Home Link
+--+--+ --+----+---+------ +--+--+ --+----+---+------
skipping to change at page 37, line 27 skipping to change at page 37, line 27
+---------------------------+ +---------------------------+
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is inactive) home agent's binding (Proxy neighbor advertisement is inactive)
none none
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
Figure 6: Several Interfaces Attached to Home Link and Returning Home Figure 6: Several Interfaces Attached to Home Link and Returning Home
Figure 7 depicts the scenario where interfaces of MN are attached to Figure 6 depicts the scenario where multiple interfaces of MN are
the foreign links. One of foreign link is managed by the home agent. attached to the home link. The HA and CN have the binding entries
The HA and CN have the binding entries listed in Figure 7 in their listed in Figure 6 in their binding cache database. The MN can not
binding cache database. The home agent advertises a prefix which is use the interface attached to a foreign link unless a CN has a
other than home prefix. The mobile node will generate a care-of binding for the interface. All packets which arrive at the HA are
address from the prefix and registers it to the home agent. Even if routed to one of the MN's interfaces attached to the home link.
the mobile node attaches to a foreign link, the link is managed by
its home agent. It will tunnel the packets to the home agent, but
the home agent is one-hop neighbor. The cost of tunnel is
negligible. If the mobile node wants to utilize not only an
interface attached to home but also interfaces attached to foreign
link, it can use this foreign link of the home agent to return a one
hop foreign link on behalf of a home link. This is different from
the general returning home, but this enable the capability of using
interfaces attached to both home and foreign link without any
modifications to Mobile IPv6 and NEMO basic support.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ ++-+-+
CoA2| | | | Home Link
+--+--+ | ----|-+------
| MN +========+ |
+--+--+ CoA1 ---+-+------
CoA3 | | Foreign Link
+---------------------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 7: Emulating to Utilize Interfaces Attached to both Home and
Foreign Links
Appendix B. Changes From Previous Versions Appendix B. Changes From Previous Versions
Changes from draft-ietf-monami6-multiplecoa-01.txt Changes from draft-ietf-monami6-multiplecoa-02.txt
o Updating the text of BID definition. The older text was unclear
whether a BID is assigned to a binding or a interface. It is now
clearly defined that BID is assigned to each binding.
o Removing R flag according to complexity.
o Introducing O (Overwrite) flag. This flag is useful when a MN
sends all the active CoAs to HA or CN all at once. It also useful
when a MN reboots and sends a first BU to HA and CN. see
Section 5.11 in detail.
o Removing the Binding Error texts, since there is no way to know
BID when BE is sent by CN.
o Clearing up the Status code of Binding Unique Identifier sub-
option and Binding Acknowledgment. Renewing the texts in
Section 6.3.
o Adding new section "Sending Packets to HA" and "Receiving Packets
from MN".
o adding how to handle correspondent nodes which do not support MCoA
extension in Section 5.2.
o Return routability is now extended to carry and use BID to o Add Security Considerations
generate Authenticator. Section 6.2 and Section 5.2 are added.
o Adding a new section: IPsec and IKEv2 interaction. o Add IANA Considerations
o Shortening Introduction. We also remove several useless texts in o Add H flag for BID option and Modify Returning Home.
this doc.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Keio University Keio University
Department of Environmental Information, Keio University. Department of Environmental Information, Keio University.
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
 End of changes. 48 change blocks. 
223 lines changed or deleted 161 lines changed or added

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