draft-ietf-monami6-multiplecoa-00.txt   draft-ietf-monami6-multiplecoa-01.txt 
Monami6 Working Group R. Wakikawa Monami6 Working Group R. Wakikawa
Internet-Draft Keio University Internet-Draft Keio University
Expires: December 14, 2006 T. Ernst Expires: April 4, 2007 T. Ernst
Keio University / WIDE Keio University / WIDE
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
June 12, 2006
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-00.txt draft-ietf-monami6-multiplecoa-01.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 37 skipping to change at page 1, line 35
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 December 14, 2006. This Internet-Draft will expire on April 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 40 skipping to change at page 3, line 40
5.5. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Using Alternate Care-of Address . . . . . . . . . . . . . 17 5.6. Using Alternate Care-of Address . . . . . . . . . . . . . 17
5.7. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18 5.7. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 18 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 18
5.9. Receiving Binding Error . . . . . . . . . . . . . . . . . 19 5.9. Receiving Binding Error . . . . . . . . . . . . . . . . . 19
6. Home Agent and Correspondent Node Operation . . . . . . . . . 20 6. Home Agent and Correspondent Node Operation . . . . . . . . . 20
6.1. Searching Binding Cache with Binding Unique Identifier . . 20 6.1. Searching Binding Cache with Binding Unique Identifier . . 20
6.2. Receiving Binding Update . . . . . . . . . . . . . . . . . 20 6.2. Receiving Binding Update . . . . . . . . . . . . . . . . . 20
6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . . 22 6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . . 22
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 22 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 23
6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 23 6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 23
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 24 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 24
8. IPsec and IKE interaction . . . . . . . . . . . . . . . . . . 25 8. IPsec and IKE interaction . . . . . . . . . . . . . . . . . . 25
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 6, line 31 skipping to change at page 6, line 31
its Home Agent and Correspondent Nodes by means of a Binding Update. its Home Agent and Correspondent Nodes by means of a Binding Update.
Correspondent nodes and the Home Agent record the BID into their Correspondent nodes and the Home Agent record the BID into their
binding cache. The Home Address thus identifies a mobile node itself binding cache. The Home Address thus identifies a mobile node itself
whereas the BID identifies each binding registered by a mobile node. whereas the BID identifies each binding registered by a mobile node.
By using the BID, multiple bindings can then be distinguished. By using the BID, multiple bindings can then be distinguished.
A user of a mobile node may be able to bind some policies to a BID. A user of a mobile node may be able to bind some policies to a BID.
The policy is used to divide flows to multiple network interfaces by The policy is used to divide flows to multiple network interfaces by
flow type, port number, or destination address, etc. How to flow type, port number, or destination address, etc. How to
distribute or configure policies is not within the scope of this distribute or configure policies is not within the scope of this
document. document. There are solutions available in Monami6 WG, for example
[11].
2. Terminology 2. Terminology
Terms used in this draft are defined in [2], [5] and [6]. In Terms used in this draft are defined in [2], [5] and [6]. In
addition or in replacement of these, the following terms are defined addition or in replacement of these, the following terms are defined
or redefined: or redefined:
Binding Unique Identification number (BID) Binding Unique Identification number (BID)
The BID is an identification number used to distinguish multiple The BID is an identification number used to distinguish multiple
skipping to change at page 7, line 26 skipping to change at page 7, line 26
entries for a given Home Address. The BID is generated to entries for a given Home Address. The BID is generated to
register multiple bindings in the binding cache for a given register multiple bindings in the binding cache for a given
address in a way it cannot be duplicated with another BID. The address in a way it cannot be duplicated with another BID. The
zero value and a negative value MUST NOT be used. After being zero value and a negative value MUST NOT be used. After being
generated by the mobile node, the BID is stored in the Binding generated by the mobile node, the BID is stored in the Binding
Update List and is sent by the mobile node by means of a sub- Update List and is sent by the mobile node by means of a sub-
option of a Binding Update. A mobile node MAY change the value of option of a Binding Update. A mobile node MAY change the value of
a BID at any time according to its administrative policy, for a BID at any time according to its administrative policy, for
instance to protect its privacy. instance to protect its privacy.
The BID can be assigned to either a Care-of Address or an The BID is conceptually assigned to a binding. An implementation
interface depending on implementation choices so as to keep using must carefully assign the BID so as to keep using the same BID for
the same BID for the same binding even when the status of the the same binding even when the status of the binding is changed.
binding is changed. More details can be found in Section 5.1. More details can be found in Section 5.1.
Binding Unique Identifier sub-option Binding Unique Identifier sub-option
The Binding Unique Identifier sub-option is used to carry the BID. The Binding Unique Identifier sub-option is used to carry the BID.
Bulk Registration Bulk Registration
A mobile node can register multiple bindings by sending a binding A mobile node can register multiple bindings by sending a binding
update. Several care-of addresses can be stored in a Binding update. Several care-of addresses can be stored in a Binding
Update. The bulk registration is supported only for home Update. The bulk registration is supported only for home
skipping to change at page 9, line 49 skipping to change at page 9, line 49
When the mobile node returns home, there are two situations, since When the mobile node returns home, there are two situations, since
the Home Agent defends the mobile node's Home Address by using the the Home Agent defends the mobile node's Home Address by using the
proxy neighbor advertisement. It is impossible to utilize all the proxy neighbor advertisement. It is impossible to utilize all the
interfaces when one interface is attached to the home link and the interfaces when one interface is attached to the home link and the
others are attached to foreign links. If the proxy Neighbor others are attached to foreign links. If the proxy Neighbor
Advertisement for the Home Address is stopped, packets are always Advertisement for the Home Address is stopped, packets are always
routed to the interface attached to the home link. If proxy is not routed to the interface attached to the home link. If proxy is not
stopped, packets are never routed to the interface attached to the stopped, packets are never routed to the interface attached to the
home link. The decision whether a mobile node returns home or not is home link. The decision whether a mobile node returns home or not is
up to implementors. up to implementers.
The first situation is when a mobile node wants to return home with The first situation is when a mobile node wants to return home with
interface attached to the home link. In this case, the mobile node interface attached to the home link. In this case, the mobile node
MUST de-register all the bindings by sending a Binding Update with MUST de-register all the bindings by sending a Binding Update with
lifetime set to zero. The mobile node MAY NOT put any Binding Unique lifetime set to zero. The mobile node MAY NOT put any Binding Unique
Identifier sub-option in this packet. Then, the receiver deletes all Identifier sub-option in this packet. Then, the receiver deletes all
the bindings from its binding cache database. the bindings from its binding cache database.
The second situation is when a mobile node does not want to return The second situation is when a mobile node does not want to return
home, though one of its interfaces is attached to its home link. The home, though one of its interfaces is attached to its home link. The
mobile node disables the interface attached to the home link and mobile node disables the interface attached to the home link and
keeps using the rest of interfaces attached to foreign links. In keeps using the rest of interfaces attached to foreign links. In
this case, the mobile node sends a de-registration Binding Update for this case, the mobile node sends a de-registration Binding Update for
the interface attached to the home link with the Binding Unique the interface attached to the home link with the Binding Unique
Identifier sub-option. The receiver of the de-registration Binding Identifier sub-option. The receiver of the de-registration Binding
Update deletes only the correspondent binding entry from the binding Update deletes only the correspondent binding entry from the binding
cache database. The Home Agent does not stop proxying neighbor cache database. The Home Agent does not stop proxying neighbor
advertisement unless there are still bindings for the other advertisement as long as there are still bindings for the other
interfaces. interfaces.
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. If this is what a
mobile node wants, a home agent can set up another link other than mobile node wants, a home agent can set up another link other than
home link and uses the link for the mobile node to return virtually home link and uses the link for the mobile node to return virtually
to home network. The detail can be found in Figure 7 to home network. The detail can be found in Figure 7
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
skipping to change at page 12, line 40 skipping to change at page 12, line 40
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 Priority/Status
When the Binding Unique Identifier sub-option is included in a When the Binding Unique Identifier sub-option is included in a
Binding Update, this field indicates the priority field assigned Binding Update, this field indicates the priority field assigned
to each binding. The receiver can utilize this priority to to each binding. The receiver can utilize this priority to
determine which binding is used to deliver packets. The priority determine which binding is used to deliver packets. The priority
is 8-bit unsigned integer. A value of zero indicates No Priority. is 8-bit unsigned integer. The higher value has higher priority.
The higher value has higher priority. Values of zero and 255 are reserved for specific 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 [11]. 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 in a bulk registration mode. The correspondent to each binding in a bulk registration mode. The
mobile node can know the registration status of each binding. The mobile node can know the registration status of each binding. The
status is 8-bit unsigned integer. The possible status codes are status is 8-bit unsigned integer. The possible status codes are
listed below. If the status field is below 128, it indicates that listed below. If the status field is below 128, it indicates that
the binding registration was successful. the binding registration was successful.
ACCEPTING BID SUBOPTION (0) ACCEPTING BID SUBOPTION (0)
skipping to change at page 13, line 22 skipping to change at page 13, line 30
Registration failed because Binding Unique Identifier sub- Registration failed because Binding Unique Identifier sub-
option is not compliant. option is not compliant.
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
correspondent to BID in the Binding Unique Identifier sub-option. correspondent to BID in the Binding Unique Identifier sub-option.
This flag must be used whenever a mobile node sends multiple This flag must be used whenever a mobile node sends multiple
bindings in a single Binding Update, i.e. bulk registration. bindings in a single Binding Update, i.e. bulk registration.
Removable (R) flag: TBD Removable (R) flag
When this flag is set, a mobile node request a Home Agent to When this flag is set, a mobile node request a Home Agent to
remove the binding correspondent to BID, even if the binding remove the binding correspondent to BID, even if the binding
update is not for de-registration. This flag is valid only when update is not for de-registration. This flag is valid only when
bulk registration is used (C flag is set). This option may be bulk registration is used (C flag is set).
obsolete in the future revision.
Reserved Reserved
6 bits Reserved field. Reserved field must be set with all 0. 6 bits Reserved field. Reserved field must be set with all 0.
4.3.2. Binding Update 4.3.2. Binding Update
No modification to Binding Update. A mobile node stores a Binding No modification to Binding Update. A mobile node stores a Binding
Unique Identifier option in the Mobility Options field of a Binding Unique Identifier option in the Mobility Options field of a Binding
Update. Update.
skipping to change at page 15, line 20 skipping to change at page 15, line 20
1. A mobile node uses several physical network interfaces and 1. A mobile node uses several physical network interfaces and
acquires a Care-of Address on each of its interfaces. acquires a Care-of Address on each of its interfaces.
2. A mobile node uses a single physical network interface, but 2. A mobile node uses a single physical network interface, but
multiple prefixes are announced on the link the interface is multiple prefixes are announced on the link the interface is
attached to. Several global addresses are configured on this attached to. Several global addresses are configured on this
interface for each of the announced prefixes. interface for each of the announced prefixes.
The difference between the above two cases is only a number of The difference between the above two cases is only a number of
physical network interfaces and therefore does not matter. The physical network interfaces and therefore does not matter in this
Identification number is used to distinguish multiple bindings so document. The Identification number is used to identify a binding.
that the mobile node assigns an identification number for each To implement this, a mobile node MAY assign an identification number
Care-of Addresses. How to assign an identification number is up to for each Care-of Addresses. How to assign an identification number
implementors. is up to implementers.
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
simultaneously register with its Home Address. The value should be simultaneously register with its Home Address. The value should be
generated from a value comprised between 1 to 65535. Zero and generated from a value comprised between 1 to 65535. Zero and
negative value can not be taken as a BID. If a mobile node has only negative value MUST NOT be taken as a BID. If a mobile node has only
one Care-of Address, the assignment of a BID is not needed until it one Care-of Address, the assignment of a BID is not needed until it
has multiple Care-of Addresses to register with. has multiple Care-of Addresses to register with.
5.2. Binding Registration 5.2. 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 standard register multiple Care-of Addresses, it completely follows standard
RFC 3775 specification. RFC 3775 specification.
skipping to change at page 21, line 16 skipping to change at page 21, line 16
On the other hand, if a Binding Update contains a Binding Unique On the other hand, if a Binding Update contains a Binding Unique
Identifier sub-option(s), a receiver node MUST perform additional Identifier sub-option(s), a receiver node MUST perform additional
validations as follows: validations as follows:
o A receiver node MUST validate the Binding Update according to o A receiver node MUST validate the Binding Update according to
section 9.5.1 of RFC 3775. section 9.5.1 of RFC 3775.
o If a Binding Unique Identifier sub-option(s) is present, the o If a Binding Unique Identifier sub-option(s) is present, the
receiver node MUST process the sub-option. receiver node MUST process the sub-option.
o If the Binding Unique Identifier sub-option is with C flag set and o If the C flag is unset in a Binding Unique Identifier sub-
no care-of address is present in the sub-option, the receiver node option(s), the length field MUST be 4. Otherwise, the receiver
MUST set 128 in the Status field of the Binding Unique Identifier MUST return the error code 128 in the status field of the Binding
sub-option and send a Binding Acknowledgment with status code set Unique Identifier sub-option and send a Binding Acknowledgment
to 145 with the Binding Unique Identifier sub-option. If either a with status code set to 145 with the Binding Unique Identifier
Correspondent Node or a Home Agent not supporting bulk sub-option. When the length field is more than 4, the receiver
registration receives the Binding Unique Identifier sub-option MAY process this sub-option by ignoring the rest of field beyond
with C flag set, it MUST return the error code 146 in a Binding the 4 octets (i.e. after Reserved field).
Acknowledgment.
o If the Binding Unique Identifier sub-option is with the C flag set
and no care-of address is present in the sub-option, the receiver
node MUST set 128 in the Status field of the Binding Unique
Identifier sub-option and send a Binding Acknowledgment with
status code set to 145 with the Binding Unique Identifier sub-
option. If either a Correspondent Node or a Home Agent not
supporting bulk registration receives the Binding Unique
Identifier sub-option with C flag set, it MUST return the error
code 146 in a Binding Acknowledgment.
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 that includes the BID as a mobile node's binding. binding that includes the BID as a mobile node's binding.
* If the C flag is set in the Binding Unique Identifier sub- * If the C flag is set in the Binding Unique Identifier sub-
option, the Care-of Address must be taken from the Care-of option, the Care-of Address must be taken from the Care-of
Address in the Binding Unique Identifier sub-option. Address in the Binding Unique Identifier sub-option.
* If the C flag is not set in the Binding Unique Identifier sub- * If the C flag is not set in the Binding Unique Identifier sub-
option, the Care-of Address must be taken from the Source option, the Care-of Address must be taken from the Source
skipping to change at page 27, line 8 skipping to change at page 27, line 8
node on Mobile IPv6 and Network Mobility. A binding unique node on Mobile IPv6 and Network Mobility. A binding unique
identifier is introduced to register multiple care-of addresses to a identifier is introduced to register multiple care-of addresses to a
Home Agent and a Correspondent Node. Those care-of addresses are Home Agent and a Correspondent Node. Those care-of addresses are
bound to the same home address. A few modifications to Mobile IPv6 bound to the same home address. A few modifications to Mobile IPv6
and NEMO are required to support multiple care-of address and NEMO are required to support multiple care-of address
registration. registration.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Masafumi Aramoto (Sharp Corporation), The authors would like to thank Masafumi Aramoto (Sharp Corporation),
Julien Charbon, Susumu Koshiba, Martti Kuparinen (Ericsson), Romain Julien Charbon, Tero Kauppinen (Ericsson), Susumu Koshiba, Martti
Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki Matutani Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen
(Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji Okada (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U),
(Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) in Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U),
alphabetical order, the Jun Murai Lab. at KEIO University, and WIDE Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab.
project for their contributions. at KEIO University, and WIDE project for their contributions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", [1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",
IETF RFC 2460, December 1998. 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 28, line 12 skipping to change at page 28, line 12
[9] Ernst, T., "Motivations and Scenarios for Using Multiple [9] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-00 (work in draft-ietf-monami6-multihoming-motivation-scenario-00 (work in
progress), February 2006. progress), February 2006.
[10] Ng, C., "Analysis of Multihoming in Network Mobility Support", [10] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-05 (work in progress), draft-ietf-nemo-multihoming-issues-05 (work in progress),
February 2006. February 2006.
[11] 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. The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI.
MN has 3 different interfaces and possibly acquires Care-of Addresses MN has 3 different interfaces and possibly acquires Care-of Addresses
1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each
Care-of Addresses. Care-of Addresses.
skipping to change at page 32, line 27 skipping to change at page 32, 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 6 depicts the scenario where interfaces of MN are attached to Figure 7 depicts the scenario where interfaces of MN are attached to
the foreign links. One of foreign link is managed by the home agent. the foreign links. One of foreign link is managed by the home agent.
The HA and CN have the binding entries listed in Figure 6 in their The HA and CN have the binding entries listed in Figure 7 in their
binding cache database. The home agent advertises a prefix which is binding cache database. The home agent advertises a prefix which is
other than home prefix. The mobile node will generate a care-of other than home prefix. The mobile node will generate a care-of
address from the prefix and registers it to the home agent. Even if address from the prefix and registers it to the home agent. Even if
the mobile node attaches to a foreign link, the link is managed by 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 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 the home agent is one-hop neighbor. The cost of tunnel is
negligible. If the mobile node wants to utilize not only an negligible. If the mobile node wants to utilize not only an
interface attached to home but also interfaces attached to foreign interface attached to home but also interfaces attached to foreign
link, it can use this foreign link of the home agent to return home. link, it can use this foreign link of the home agent to return home.
This is different from the general returning home, but this enable This is different from the general returning home, but this enable
the capability of using interfaces attached to both home and foreign the capability of using interfaces attached to both home and foreign
link without any modifications to Mobile IPv6 and Nemo basic support. link without any modifications to Mobile IPv6 and NEMO basic support.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+-----+ ++-+-+ | +----+-----+ ++-+-+
CoA2| | | | Home Link CoA2| | | | Home Link
+--+--+ | ----|-+------ +--+--+ | ----|-+------
skipping to change at page 34, line 7 skipping to change at page 34, line 7
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 7: Emulating to Utilize Interfaces Attached to both Home and Figure 7: Emulating to Utilize Interfaces Attached to both Home and
Foreign Links Foreign Links
Appendix B. Changes From Previous Versions Appendix B. Changes From Previous Versions
Changes from draft-wakikawa-mobileip-multiplecoa-05.txt Changes from draft-ietf-monami6-multiplecoa-00.txt
o Updating packet formats. B flag in Binding Unique Identifier sub-
option is removed.
o Updating packet formats. C and R flags in Unique Binding
Identifier sub-option are introduced for bulk registration.
o Bulk Registration for home registration is now supported. Bulk
Registartion to Correspondent Node is not supported in this
document.
o IPsec and IKE interaction will be added shortly. o Adding a default value for the BID priority field. This default
value is used by the flow binding scheme [11].
o The DHAAD extension is removed. 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.
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. 23 change blocks. 
55 lines changed or deleted 65 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/