draft-ietf-monami6-multiplecoa-06.txt   draft-ietf-monami6-multiplecoa-07.txt 
MEXT Working Group R. Wakikawa (Ed.) MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Keio University Internet-Draft Toyota ITC/Keio Univ.
Intended status: Standards Track T. Ernst Intended status: Standards Track T. Ernst
Expires: August 27, 2008 INRIA Expires: November 1, 2008 INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli (Ed.) V. Devarapalli (Ed.)
Azaire Networks Wichorus
February 24, 2008 April 30, 2008
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-06.txt draft-ietf-monami6-multiplecoa-07.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 August 27, 2008. This Internet-Draft will expire on November 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
According to the current Mobile IPv6 specification, a mobile node may According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, called the primary have several care-of addresses, but only one, called the primary
care-of address, that can be registered with its home agent and the care-of address, that can be registered with its home agent and the
skipping to change at page 3, line 13 skipping to change at page 3, line 13
Mobility) Basic Support protocol as well. Mobility) Basic Support protocol as well.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 9 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 12
4.1. Binding Cache Structure and Binding Update List . . . . . 9 4.1. Binding Cache Structure and Binding Update List . . . . . 12
4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 9 4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 12
4.3. New Status Values for Binding Acknowledgement . . . . . . 11 4.3. New Status Values for Binding Acknowledgement . . . . . . 14
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 16
5.1. Management of Care-of Address(es) and Binding 5.1. Management of Care-of Address(es) and Binding
Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 13 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 16
5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 17
5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 14 5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 17
5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 15 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 18
5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 16 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 18
5.6.1. Using only Interface attached to the Home Link . . . . 16 5.6.1. Using only Interface attached to the Home Link . . . . 19
5.6.2. Using only Interface attached to the Visited Link . . 16 5.6.2. Using only Interface attached to the Visited Link . . 19
5.6.3. Simultaneous Home and Visited Link Operation . . . . . 17 5.6.3. Simultaneous Home and Visited Link Operation . . . . . 19
5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 19 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 24
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 20 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 25
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 25
6. Home Agent and Correspondent Node Operation . . . . . . . . . 21
6.1. Searching Binding Cache with Binding Identifier . . . . . 21
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 24
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 24
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 25 6. Home Agent and Correspondent Node Operation . . . . . . . . . 27
6.1. Searching Binding Cache with Binding Identifier . . . . . 27
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 27
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 28
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 30
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 30
8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 26 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 26
8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 27
9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 28 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 28 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33
9.2. Transport Mode IPsec protected messages . . . . . . . . . 29 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 34
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 29
9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 29
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35
9.2. Transport Mode IPsec protected messages . . . . . . . . . 36
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 36
9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 36
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Example Configurations . . . . . . . . . . . . . . . 36 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 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 is increasingly durable and wide area network connectivity. This is 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 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for
and benefits of using multiple points of attachment are discussed in and benefits of using multiple points of attachment are discussed in
[ID-MOTIVATION]. When a mobile node with multiple interfaces uses [ID-MOTIVATION]. When a mobile node with multiple interfaces uses
Mobile IPv6 [RFC-3775] for mobility management, it cannot use its Mobile IPv6 [RFC-3775] for mobility management, it cannot use its
skipping to change at page 6, line 43 skipping to change at page 6, line 43
The Binding Identifier mobility option is used to carry the BID The Binding Identifier mobility option is used to carry the BID
information. information.
Bulk Registration Bulk Registration
A mobile node can register multiple bindings at once by sending a A mobile node can register multiple bindings at once by sending a
single Binding Update. A mobile node can also replace some or all single Binding Update. A mobile node can also replace some or all
the bindings available at the home agent with the new bindings by the bindings available at the home agent with the new bindings by
using the bulk registration. Bulk registration is supported only using the bulk registration. Bulk registration is supported only
with the home agent as explained in Section 5.5. A mobile node for home registration (i.e. with the home agent) as explained in
MUST NOT perform bulk registration with a correspondent node. Section 5.4. A mobile node MUST NOT perform bulk registration
with a correspondent node.
3. Protocol Overview 3. Protocol Overview
A new extension called the Binding identification number (BID) is A new extension called the Binding identification number (BID) is
introduced to distinguish between multiple bindings pertaining to the introduced to distinguish between multiple bindings pertaining to the
same home address. If a mobile node configures several IPv6 global same home address. If a mobile node configures several IPv6 global
addresses on one or more of its interfaces, it can register these addresses on one or more of its interfaces, it can register these
addresses with its home agent as care-of addresses. If the mobile addresses with its home agent as care-of addresses. If the mobile
node wants to register multiple bindings, it MUST generate a BID for node wants to register multiple bindings, it MUST generate a BID for
each care-of address and store the BID in the binding update list. A each care-of address and store the BID in the binding update list. A
skipping to change at page 7, line 40 skipping to change at page 7, line 40
correspondent node, it must perform return routability operations. correspondent node, it must perform return routability operations.
This includes managing a Care-of Keygen token per care-of address and This includes managing a Care-of Keygen token per care-of address and
exchanging CoTi and CoT message with the correspondent node for each exchanging CoTi and CoT message with the correspondent node for each
care-of address. The mobile node MAY use the same BID that it used care-of address. The mobile node MAY use the same BID that it used
with the home agent for a particular care-of address. For protocol with the home agent for a particular care-of address. For protocol
simplicity, bulk registration to correspondent nodes is not supported simplicity, bulk registration to correspondent nodes is not supported
in this document. This is because the Return Routability mechanism in this document. This is because the Return Routability mechanism
introduced in [RFC-3775] cannot be easily extended to verify multiple introduced in [RFC-3775] cannot be easily extended to verify multiple
care-of addresses stored in a single Binding Update. care-of addresses stored in a single Binding Update.
Figure 1 illustrates the configuration where the mobile node obtains
multiple care-of addresses at foreign links. The mobile node can
utilize all the care-of address. In Figure 1, the home address of
the mobile node (MN) is a:b:c:d::EUI. The mobile node has 3
different interfaces and possibly acquires care-of addresses 1-3
(CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to
each care-of address.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
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 1: Multiple Care-of Address Registration
If the mobile node decides to act as a regular mobile node compliant If the mobile node decides to act as a regular mobile node compliant
with [RFC-3775], it sends a Binding Update without any Binding with [RFC-3775], it sends a Binding Update without any Binding
Identifier mobility options. The receiver of the Binding Update Identifier mobility options. The receiver of the Binding Update
deletes all the bindings registering with a BID and registers only a deletes all the bindings registering with a BID and registers only a
single binding for the mobile node. Note that the mobile node can single binding for the mobile node. Note that the mobile node can
continue using the BID even if it has only a single binding that is continue using the BID even if it has only a single binding that is
active. active.
Binding cache lookup is done based on the home address and BID Binding cache lookup is done based on the home address and BID
information. This is different from RFC 3775, where only the home information. This is different from RFC 3775, where only the home
skipping to change at page 8, line 13 skipping to change at page 9, line 4
flow filters are used to direct certain packets or flows to a flow filters are used to direct certain packets or flows to a
particular care-of address. The binding cache lookup using policy or particular care-of address. The binding cache lookup using policy or
flow filters is out of scope for this document. In case the binding flow filters is out of scope for this document. In case the binding
cache lookup, using the combination of home address and BID, does not cache lookup, using the combination of home address and BID, does not
return a valid binding cache entry, the home agent MAY perform return a valid binding cache entry, the home agent MAY perform
another lookup based on only the home address. This is another lookup based on only the home address. This is
implementation dependent and configurable on the home agent. implementation dependent and configurable on the home agent.
The mobile node may return to the home link through one of its The mobile node may return to the home link through one of its
interfaces. There are three options possible for the mobile node interfaces. There are three options possible for the mobile node
when its returns home. when its returns home. Section 5.6 describes the returning home
procedures in more detail.
1. The mobile node uses only the interface with which it attaches to 1. The mobile node uses only the interface with which it attaches to
the home link. It de-registers all bindings related to all the home link. This is illustrated in Figure 2. It de-registers
care-of addresses. The interfaces still attached to the visited all bindings with the home agent related to all care-of
link(s) are no longer going to be receiving any encapsulated addresses. The interfaces still attached to the visited link(s)
traffic from the home agent. are no longer going to be receiving any encapsulated traffic from
the home agent. On the other hand, the mobile node can continue
communicating with the correspondent node from the other
interfaces attached to foreign links by using route optimization.
Even if the mobile node is attached to the home link, it can
still send Binding Updates for other active care-of addresses
(CoA1 and CoA2) to correspondent nodes. Since the correspondent
node has bindings, packets are routed to each Care-of Addresses
directly.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
none
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 2: Using only Interface Attached to Home Link
2. The mobile node uses only the interfaces still attached to the 2. The mobile node uses only the interfaces still attached to the
visited link(s). The interface with which the mobile node visited link(s) as shown in Figure 3. The interface with which
attaches to the home link is not used. the mobile node attaches to the home link is not used.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
(Disable interface)
Binding Cache Database:
home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 3: Using only interface attached to the visited link
3. The mobile node may simultaneously use both the interface 3. The mobile node may simultaneously use both the interface
attached to the home link and the interfaces still attached to attached to the home link and the interfaces still attached to
the visited link(s). the visited link(s) as shown in Figure 4. There are two possible
topologies depending on whether the home agent is only router on
the home link or not. The operation of Neighbor Discovery [RFC-
2461] is different in the two topologies. The home agent and the
correspondent node have the binding entries listed in Figure 4 in
their binding cache database in both topologies. The home agent
also knows that the mobile node has attached to the home link.
All the traffic from the Internet is intercepted by the home
agent first and routed to either the interface attached to the
home link or the one of the foreign links. How the home agent
decides to route a particular flow to the interface attached to
the home link or foreign link is out of scope in this document.
Section 5.6 describes the returning home procedures in more detail. Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 4: Simultaneous Home and Visited Link Operation
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
This section summarizes the extensions to Mobile IPv6 necessary for This section summarizes the extensions to Mobile IPv6 necessary for
manage multiple bindings. manage multiple bindings.
4.1. Binding Cache Structure and Binding Update List 4.1. Binding Cache Structure and Binding Update List
The BID is required to be stored in the binding cache and binding The BID is required to be stored in the binding cache and binding
update list structure. update list structure.
The sequence number value SHOULD be shared among all the binding
update list entries related to binding updates sent to a particular
home agent or correspondent node. Whenever a mobile node sends
either individual or bulk binding update, the sequence number is
incremented. On the other hand, if a mobile node manages an
individual sequence value per binding update list, a mobile node
SHOULD carefully select the sequence number value for the bulk
binding update. This is because all the bulk-registered bindings use
the same Sequence Number specified in the Binding Update. If each
binding uses different sequence number, a mobile node MUST use the
largest sequence number from the Binding Update list entries used for
the bulk registration. If the mobile node cannot select a sequence
number for all the bindings due to sequence number out of window, it
MUST NOT use the bulk registration for the binding whose sequence
number is out of window. A separate Binding Update should be sent
for the binding.
4.2. Binding Identifier Mobility Option 4.2. Binding Identifier Mobility Option
The Binding Identifier mobility option is included in the Binding The Binding Identifier mobility option is included in the Binding
Update, Binding Acknowledgement, Binding Refresh Request, and Care-of Update, Binding Acknowledgement, 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 ID (BID) | Status |C|O|H|D|Resrvd | | Binding ID (BID) | Status |O|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
: IPv4 or IPv6 care-of address (CoA) : : IPv4 or IPv6 care-of address (CoA) :
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: BID Mobility Option Figure 5: BID Mobility Option
Type Type
Type value for Binding Identifier is TBD Type value for Binding Identifier is TBD
Length Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Type and Length fields. MUST be set to 4 when the excluding the Type and Length fields. It MUST be set to either 4,
'C' flag is unset. Otherwise, the Length value MUST be set to 12, or 20 depending on the care-of address field. When the
either 8 or 20 depending on the 'D' (DSMIPv6) flag. care-of address is not carried by this option, the length value
MUST be set to 4. If the IPv4 care-of address is stored in the
care-of address field, the length MUST be 12. Otherwise, the
Length value MUST be set to 20 for IPv6 care-of address.
Binding ID (BID) Binding ID (BID)
The BID which is assigned to the binding indicated by the care-of The BID which is assigned to the binding indicated by the care-of
address in the Binding Update or the BID mobility option. The BID address in the Binding Update or the BID mobility option. The BID
is a 16-bit unsigned integer. The value of zero is reserved and is a 16-bit unsigned integer. The value of zero is reserved and
MUST NOT be used. MUST NOT be used.
Status Status
When the Binding Identifier mobility option is included in a When the Binding Identifier mobility option is included in a
Binding Acknowledgement, this field overwrites the status field in Binding Acknowledgement, this field overwrites the status field in
the Binding Acknowledgement. If this field is zero, the receiver the Binding Acknowledgement. If this field is zero, the receiver
MUST use the registration status stored in the Binding MUST use the registration status stored in the Binding
Acknowledgement message. This Status field is also used to carry Acknowledgement message. This Status field is also used to carry
error information related to the care-of address test in the error information related to the care-of address test in the
Care-of Test message. The status is 8-bit unsigned integer. The Care-of Test message. The status is 8-bit unsigned integer. The
possible status codes are the same as the status codes of Binding possible status codes are the same as the status codes of Binding
Acknowledgement. Acknowledgement.
Care-of address (C) flag
When this flag is set, it indicates that a valid care-of address
is present in the care-of address field in the BID mobility
option. This flag MUST be set whenever the mobile node sends
multiple care-of addresses in a single Binding Update, i.e., bulk
registration. It MAY also used as a substitute for alternate
care-of address option even for Binding Updates that are sent only
for one care-of address. This flag is valid only for Binding
Update sent to the home agent.
Overwrite (O) flag Overwrite (O) flag
When this flag is set, a mobile node requests the recipient to When this flag is set, a mobile node requests the recipient to
replace all the bindings to binding entries stored in a Binding replace all the bindings to binding entries stored in a Binding
Update. Update.
Simultaneous Home and Foreign Binding (H) flag Simultaneous Home and Foreign Binding (H) flag
This flag indicates that the mobile node registers multiple This flag indicates that the mobile node registers multiple
bindings to the home agent while is attached to the home link. bindings to the home agent while is attached to the home link.
This flag is valid only for a Binding Update sent to the home This flag is valid only for a Binding Update sent to the home
agent. agent.
DSMIPv6 (D) flag
This flag indicates that the care-of address is an IPv4 address.
When this flag is set, the care-of address field MUST contain an
IPv4 address.
Reserved Reserved
5 bits Reserved field. The reserved field MUST be zero. 5 bits Reserved field. The reserved field MUST be zero.
Care-of Address Care-of Address
This field has the variable length depending on the specified This field has the variable length depending on the specified
flags. When the 'C' flag is set and the 'D' flag is not, an IPv6 flags. Either IPv4 or IPv6 care-of address for the corresponding
care-of address for the corresponding BID is stored in this field. BID can be stored in this field. This field MUST NOT be used if a
If both 'C' and 'D' flags are set, an IPv4 Care-of Address is Binding Identifier mobility option is included in any other
carried in this field. This field MUST NOT be used if a Binding message other than a Binding Update.
Identifier mobility option is included in any other message other
than a Binding Update or if the 'C' flag is not set.
4.3. New Status Values for Binding Acknowledgement 4.3. 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 < 128) MCOA NOTCOMPLETE (TBD < 128)
In bulk registration, not all the binding identifier mobility In bulk registration, not all the binding identifier mobility
option are successfully registered. Some of them are rejected. option are successfully registered. Some of them are rejected.
skipping to change at page 14, line 14 skipping to change at page 17, line 14
registration. Thus, the mobile node MUST NOT use a Binding registration. Thus, the mobile node MUST NOT use a Binding
Identifier mobility option in any future Binding Updates to that Identifier mobility option in any future Binding Updates to that
correspondent node. The mobile node MAY skip re-sending regular CoTI correspondent node. The mobile node MAY skip re-sending regular CoTI
message and keep the received care-of Keygen token for the regular message and keep the received care-of Keygen token for the regular
Binding Update. Binding Update.
5.3. Binding Registration 5.3. 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 2. The BID is copied from a corresponding Binding as shown in Figure 6. The BID is copied from a corresponding Binding
Update List entry to the BID field of the Binding Identifier mobility Update List entry to the BID field of the Binding Identifier mobility
option. When IPsec ESP is used for protecting the Binding Update, option. When IPsec ESP is used for protecting the Binding Update,
the care-of address can be carried in the Care-of Address field of the care-of address can be carried in the Care-of Address field of
the Binding Identifier mobility option. If this is done, the the Binding Identifier mobility option. If this is done, the
alternate care-of address option MUST NOT be included in the Binding alternate care-of address option MUST NOT be included in the Binding
Update. For binding registration to a correspondent node, the mobile Update. For binding registration to a correspondent node, the mobile
node MUST have both active Home and Care-of Keygen tokens for Kbm node MUST have both active Home and Care-of Keygen tokens for Kbm
(see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update.
The care-of Keygen tokens MUST be maintained for each care-of address The care-of Keygen tokens MUST be maintained for each care-of address
that the mobile node wants to register to the correspondent node. that the mobile node wants to register to the correspondent node.
The Binding Update to the correspondent node is protected by the The Binding Update to the correspondent node is protected by the
Binding Authorization Data mobility option that is placed after the Binding Authorization Data mobility option that is placed after the
Binding Identifier mobility option. Binding Identifier mobility option.
IPv6 header (src=CoA, dst=HA) IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header (for home registration) ESP Header (for home registration)
Mobility header Mobility header
-BU -Binding Update
Mobility Options Mobility Options
- Binding Identifier mobility option - Binding Identifier mobility option
- Binding Authorization mobility option - Binding Authorization mobility option
(for Route Optimization) (for Route Optimization)
Figure 2: Binding Update for Binding Registration Figure 6: Binding Update for Binding Registration
5.4. Bulk Registration 5.4. 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. scarce. This document specifies bulk registration only for the
mobile node's home registration. A mobile node performing bulk
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 and Care-of address pair it
wants to register in the same Binding Update message. This is shown wants to register in the same Binding Update message. This is shown
in Figure 3. The rest of the fields and options in the Binding in Figure 7. The rest of the fields and options in the Binding
Update such as Lifetime, Sequence Number, the flags in the Binding Update such as Lifetime, Sequence Number, and the flags in the
Update are common across all care-of addresses. The alternate Binding Update are common across all care-of addresses. The
care-of address option MUST NOT be used. alternate care-of address option MUST NOT be used.
In the bulk registration, the Sequence Number field of a Binding
Update SHOULD be carefully configured. This is because all the bulk-
registered bindings use the same Sequence Number specified in the
Binding Update. If each binding uses different sequence number, a
mobile node MUST use the largest sequence number from the Binding
Update list entries used for the bulk registration. If the mobile
node cannot select a sequence number for all the bindings due to
sequence number out of window, it MUST NOT use the bulk registration
for the binding whose sequence number is out of window. A separate
Binding Update should be sent for the binding.
IPv6 header (src=CoA, dst=HA) IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header ESP Header
Mobility header Mobility header
-BU -Binding Update
Mobility Options Mobility Options
- Binding Identifier mobility options - Binding Identifier mobility options (CoA)
(C flag is set, O flag is optional,
BID and CoA are stored)
Figure 3: Binding Update for Bulk Registration Figure 7: Binding Update for Bulk 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 bindings in the sent Binding Update, it sets the home agent with the bindings in the sent Binding Update, it sets
the 'O' flag. Section 6.3 describes this registration procedure in the 'O' flag. Section 6.3 describes this registration procedure in
detail. detail.
5.5. Binding De-Registration 5.5. 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
skipping to change at page 16, line 13 skipping to change at page 18, line 50
receiver. This is because the receiver will remove the binding that receiver. This is because the receiver will remove the binding that
matches the specified BID. matches the specified BID.
5.6. Returning Home 5.6. Returning Home
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. The mobile node may use only the interface it needs to use. The mobile node may use only the
interface with which it is attached to the home link, only the interface with which it is attached to the home link, only the
interfaces still attached to the visited link or use both interfaces interfaces still attached to the visited link(s) or use both
attached to the home link and visited link simultaneously. The interfaces attached to the home link and visited link(s)
following describes each option in more detail. simultaneously. The following describes each option in more detail.
5.6.1. Using only Interface attached to the Home Link 5.6.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 8 and as defined in [RFC-3775]. De-registering all shown in Figure 2 and as defined in [RFC-3775]. De-registering all
the bindings is the same as binding de-registration from foreign link the bindings is the same as binding de-registration from foreign link
described in Section 5.5. After the de-registration step, all the described in Section 5.5. After the de-registration step, all the
packets routed by the home agent are only forwarded to the interface packets routed by the home agent are only forwarded to the interface
attached to the home link, even if there are other active interfaces attached to the home link, even if there are other active interfaces
attached to the visited link. While the mobile node de-registers all attached to the visited link(s). While the mobile node de-registers
the bindings from the home agent, it may continue registering all the bindings from the home agent, it may continue registering
bindings for interface attached to visited link to the correspondent bindings for interface(s) attached to visited link(s) to the
node as shown in Figure 8. correspondent node as shown in Figure 2.
5.6.2. Using only Interface attached to the Visited Link 5.6.2. Using only Interface attached to the Visited Link
The mobile node returns home and shuts down the interface attached to The mobile node returns home and shuts down the interface attached to
the home link as shown in Figure 9. Before shutting down the the home link as shown in Figure 3. Before shutting down the
interface, any binding for the care-of address previously associated interface, any binding for the care-of address previously associated
with the interface should be deleted. To delete the binding cache with the interface should be deleted. To delete the binding cache
entry, the mobile node SHOULD send a de-registration Binding Update entry, the mobile node SHOULD send a de-registration Binding Update
with the lifetime set to zero and include the corresponding BID with the lifetime set to zero and include the corresponding BID
information. If the mobile node does not send a de-registration information. If the mobile node does not send a de-registration
Binding Update, the binding for the care-of address previously Binding Update, the binding for the care-of address previously
assigned to the interface remains at the home agent. This binding is assigned to the interface remains at the home agent until its
deleted only when it expires. In order to avoid this, the mobile lifetime expires.
node SHOULD send a de-registration binding update for the interface
attached to the home link.
This scenario is not the most efficient because all the traffic to In this scenario, despite the fact that the mobile node is connected
and from the mobile node is going through the bi-directional tunnel, to its home link, all of its traffic is sent and received via the
whereas the mobile node is now accessible at one hop on the home link home agent and its foreign links.
from its home agent.
5.6.3. Simultaneous Home and Visited Link Operation 5.6.3. Simultaneous Home and Visited Link Operation
In this case, the mobile node returns home and continues using all [Problems of Simultaneous Home and Foreign Attachments]
the interfaces attached to both foreign and home links as shown in
Figure 10. The mobile node indicates this by setting the 'H' flag in The mobile node returns home and continues using all the interfaces
the BID mobility option as defined below. There are additional attached to both foreign and home links as shown in Figure 4. The
requirements on the Returning Home procedures for possible ND mobile node indicates this by setting the 'H' flag in the BID
conflicts at the home link described below. mobility option as defined below. There are additional requirements
on the Returning Home procedures for possible Neighbor Discovery
states 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 while the mobile node is away node using the Proxy Neighbor Discovery [RFC-2461] while the mobile
from the home link. When the mobile node returns home, the home node is away from the home link. When the mobile node returns home,
agent deletes the binding cache and stops proxying for the home the home agent deletes the binding cache and stops proxying for the
address so that a mobile node can configure its home address on the home address so that a mobile node can configure its home address on
interface attached to the home link. In this specification, a mobile the interface attached to the home link. In this specification, a
node may return home, configure the home address on the interface mobile node may return home, configure the home address on the
attached to the home link, but still use the interfaces attached to interface attached to the home link, but still use the interfaces
the foreign links. In this case, a possible conflict arises when the attached to the foreign links. In this case, a possible conflict
both the home agent and the mobile node try to defend the home arises when the both the home agent and the mobile node try to defend
address. If the home agent stops proxying for the home address, the the home address. If the home agent stops proxying for the home
packets are always routed to the interface attached to the home link address, the packets are always routed to the interface attached to
and are never routed to the interfaces attached to the visited links. the home link and are never routed to the interfaces attached to the
It is required to avoid the conflict between the home agent and the visited links. It is required to avoid the conflict between the home
mobile node, while still allowing the simultaneous use of home and agent and the mobile node, while still allowing the simultaneous use
foreign links. The following describes the mechanism for achieving of home and foreign links. The following describes the mechanism for
this. achieving this.
[Overview and Approach]
In this specification, the home agent MUST intercept all the packets In this specification, the home agent MUST intercept all the packets
meant for the mobile node and decide whether to send the traffic meant for the mobile node and decide whether to send the traffic
directly to the home address on the link or tunnel to the care-of directly to the home address on the link or tunnel to the care-of
address. The home agent intercepts all the packets even when the address. The home agent intercepts all the packets even when the
mobile node is attached to the home link through one of its mobile node is attached to the home link through one of its
interfaces. The home agent would make this decision based on the interfaces. The home agent would make this decision based on the
type of packets and flows. How to make this decision is out of scope type of flow. How to make this decision is out of scope in this
in this document. The critical part would be to create a neighbor document.
cache entry for the mobile node so that the home agent can deliver
the packets on-link. The home agent would need to know the Layer-2
address of the interface with which the mobile node is attached to
the home link. In order to create the neighbor cache entry for the
mobile node, following operations are required.
The mobile node sends a de-registration Binding Update to the home Two scenarios are illustrated in Figure 4, depending on whether the
agent from the interface attached to the home link. In the Binding Home Agent is the only router at the home link or not. The
Update, the BID mobility option must include the BID the mobile node difference is on who defends the home address by (Proxy) Neighbor
had previously associated with the interface attached to the home Discovery on the home link.
link. The 'H' flag MUST be set in the BID mobility option. The 'C'
flag MUST NOT be set and the care-of address field MUST NOT be
included. When the 'H' flag is set, the home agent recognizes that
the mobile node wants to continue using interfaces attached to both
home and visited links. If the 'H' flag is unset, the home agent
deletes either all the bindings or the binding corresponding to the
BID included in the Binding Identifier mobility option.
When the home agent sends the Binding Acknowledgement, it MUST set 1. Mobile node defends the home address by the regular Neighbor
the status value to either 0 [Binding Update Accepted] or to Discovery Protocol (illustrated as topology-a in Figure 4). The
[MCOARETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home agent is the only router on the home link. Therefore the
home agent configuration at the home link. The new values are: home agent is capable of intercepting packets without relying on
the proxy Neighbor Discovery protocol and the mobile node can
manage the Neighbor Cache entry of the home address on the home
link as a regular IPv6 node.
o Binding Update Accepted (0): NDP is permitted for the home address 2. If there are other routers on the home link apart from the home
at the home link. This is regular returning home operation of agent, then it cannot be guaranteed that all packets meant for
[RFC-3775] the mobile node are routed to the home agent. In this case, the
mobile node MUST NOT operate Neighbor Discovery protocol for the
home address on the home link. This allows the home agent to
keep using proxy neighbor discovery and thus it keeps receiving
all the packets sent to the mobile node's home address. If the
home agent, according to its local policy, needs to deliver
packets to the mobile node over the home link, an issue arises
with respect to how the home agent discovers the mobile node's
link local address. This specification uses Link-layer Address
(LLA) Option defined in [RFC-4068bis] in order to carry the
mobile node's link-layer address in the Binding Update.
Likewise, the mobile node would also know the link-layer address
of the default router address to send packets from the home link
without Neighbor Discovery. The link-layer address is used to
transmit packets from and to the mobile node on the home link.
The packets are transmitted without the Neighbor Discovery
protocol by constructing the link-layer header manually. This
operation is similar to Mobile IPv6 [RFC-3775] when a mobile node
sends a deregistration binding update to the home agent's link-
layer address in returning home operation.
o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home [Sending Deregistration Binding Update]
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.
o The mobile node MUST include the BID 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 BID mobility option. Any address MUST NOT be set in the
Care-of Address field in the BID mobility option. When the 'H'
flag is set, the home agent recognizes that the mobile node wants
to continue using interfaces attached to both home and visited
links. Note that H flag MUST be set for all the binding updates
sent from the mobile node (ex. Binding Update for the
interface(s) attached to the foreign link(s)).
o The mobile node SHOULD include the Link-layer Address (LLA) Option
[RFC-4068bis] to notify the mobile node's link-layer address to
the home agent, too. The option code of the Link-layer Address
(LLA) option MUST be set to '2' (Link-layer Address of the mobile
node). This link-layer address is required for the home agent to
send the Binding Acknowledgement and to forward the mobile node's
packet.
o According to [RFC-3775], the mobile node MUST start responding to
Neighbor Solicitation for its home address right after it sends
the deregistration Binding Update to the home agent. However, in
this specification, the mobile node MUST NOT respond to Neighbor
Solicitation before receiving a Binding Acknowledgement, since the
home agent may continue proxying for the home address. If the
mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value
in the received Binding Acknowledgment, it MUST NOT respond to
Neighbor Solicitation even after the Binding Acknowledgement.
[Sending Binding Acknowledgement]
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): NDP is permitted for the home
address at the home link. This is regular returning home
operation of [RFC-3775]
* MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
address at the home link address at the home link
When the home agent is the only router at the home link, it can If the binding update is rejected, the appropriate error value
intercept all the packets by normal IP routing without using proxying MUST be set to the status field. In this case, the home agent
for the home address. It stops proxy ND for the requested home operation is same as [RFC-3775].
address and responds with the [Binding Update Accepted] status value
to the mobile node. The neighbor cache entry for the mobile node is
created by the regular exchange of Neighbor Solicitation and Neighbor
Advertisement. If the home agent is not the only router on the home
link, it MUST continue defending the home address by proxy neighbor
discovery in order to intercept the mobile node's traffic. The home
agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status
field of the BID mobility option. The home agent also learns the
mobile node's layer-2 address (i.e., MAC address) during this binding
de-registration. It stores the learnt layer-2 address in a neighbor
cache entry for the mobile node so that it can construct the layer-2
header for the packets meant for the mobile node and forwards them
directly to the mobile node's interface attached to the home link.
According to [RFC-3775], the mobile node MUST NOT assign the home o If the home agent is the only router at the home link, it stops
address to the interface attached to the home link and MUST NOT proxy Neighbor Discover for the requested home address and
attempt NDP operations for the home address before the completion of responds with the [Binding Update Accepted] status value to the
binding de-registration. It MUST NOT send and reply to Neighbor mobile node. Since the mobile node will not reply to Neighbor
Solicitation for the home address. The home address MUST be Solicitation for the home address before receiving the Binding
tentative address at this moment until it receives Binding Acknowledgement, the home agent SHOULD use the link-layer address
Acknowledgement with success status value. carried by the Link Layer Address option [RFC-4068bis] 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.
When the mobile node receives the Binding Acknowledgement and BID o On the other hand, if the home agent is not the only router on the
mobility option, it assigns home address to the interface attached to home link, it returns [MCOA RETURNHOME WO/NDP] value in the Status
the home link according to the status field of the BID. If the value field of the BID mobility option. The home agent learns the
is [Binding Update Accepted], the mobile node can start defending the mobile node's link-layer address by receiving the link-layer
home address using regular Neighbor Discovery. 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.
If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST NOT o Note that the use of proxy Neighbor Discovery is easier way to
defend its home address on the home link. When the mobile node sends intercept the mobile nodes' packets instead of IP routing in some
packets from the interface attached to the home link, it MUST learn deployment scenarios. Therefore, even if a home agent is the only
the layer 2 address (i.e., MAC address) of the next hop (i.e. default router, it is an implementation and operational choice whether the
router, it can be home agent) during the binding de- registration and home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
construct the packet including layer 2 header with the learnt layer-2 WO/NDP].
address of the default router or the home agent.
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.
[Sending Packets from the Home Link]
o When the mobile node receives the Binding Acknowledgement with the
status value 'Binding Update Accepted' and the BID option, it can
configure its home address to the interface attached to the home
link and start operating Neighbor Discovery for the home address
on the home link. Packets can be transmitted from and to the
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
the Binding Acknowledgement, it MUST NOT operate Neighbor
Discovery for the home address. When the mobile node sends
packets from the interface attached to the home link, it MUST
learn the link-layer address of the next hop (i.e. default router
of the mobile node). A mobile node learns the default router's
link-layer address from a Source Link-Layer Address option in
Router Advertisements. The mobile node sends packets directly to
the default router's link-layer address. This is done by
constructing the packet including link-layer header with the
learned link-layer address of the default router. The home agent
also forwards the packet to the mobile node on the home link by
using the mobile node's link-layer address. The link-layer
address SHOULD be cached when the home agent received the
deregistration Binding Update message.
[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 packet to the home link.
o On the other hand, if the mobile node does not have any active
care-of address to send a Binding Update and leaves the home link
(i.e. the mobile node is completely disconnected), the home agent
continues forwarding packets to the mobile node until the
expiration of all the binding cache entries for the home address.
Once all the bindings are expired, the mobile node is assumed to
be disconnected completely from networks.
[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.6.1. Once the home agent receives
such de-registration binding update, the home agent clears all the
binding and states for the mobile node.
If a mobile node decides to stop using the interface attached to the
home link, it simply sends a binding update from the one of active
care-of address. In the Binding Update, the mobile node should
include the BID option for the care-of address and unset the H flag
of BID option. The home agent clears the states of the mobile node
for the interface attached to the home link and stop 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.3. Binding Acknowledgement is described in Section 6.3.
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 MUST
carry a Binding Identifier mobility option. If no such mobility carry a Binding Identifier mobility option. If no such mobility
skipping to change at page 20, line 24 skipping to change at page 25, line 41
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 Section 6.4. a Binding Refresh Request is described in section 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 only for the respective binding. The mobile node MUST Binding Update only for the respective binding. The mobile node MUST
include a Binding Identifier mobility option in the Binding Update. include a Binding Identifier mobility option in the Binding Update.
If no Binding Identifier mobility option is present in a Binding
Refresh Request, the mobile node sends a Binding Update according to
its Binding Update List. On the other hand, if the mobile node does
not have any Binding Update List entry for the requesting node, the
mobile node needs to register either a single binding or multiple
bindings depending on its binding management policy.
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 Identifier first time, it MUST set the 'O' flag in the Binding Identifier
mobility option. If old bindings still exists at the home agent, the mobility option. If old bindings still exists at the home agent, the
mobile node has no knowledge of which bindings still exist at the mobile node has no knowledge of which bindings still exist at the
home agent. This scenario happens when a mobile node reboots and home agent. This scenario happens when a mobile node reboots and
looses state regarding the registrations. If the 'O' flag is set, looses state regarding the registrations. If the 'O' flag is set,
all the bindings are replaced by the new binding(s). If the mobile all the bindings are replaced by the new binding(s). If the mobile
node receives the Binding Acknowledgement with the status code set to node receives the Binding Acknowledgement with the status code set to
skipping to change at page 21, line 13 skipping to change at page 27, line 13
entries at the correspondent node. 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 mechnaism to select management. This document does not provide any mechanism to select
the suitable binding for forwarding data packets. the suitable binding for forwarding data packets.
A correspondent node SHOULD use both the home address and the BID as A correspondent node SHOULD use both the home address and the BID as
the search key of the binding cache if it knows the corresponding BID the search key of the binding cache if it knows the corresponding BID
(ex. when processing signaling messages). In the example below, if a (ex. when processing signaling messages). In the example below, if a
correspondent node searches the binding with the home address and correspondent node searches the binding with the home address and
BID2, it gets binding2 for this mobile node. 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 4: Searching the Binding Cache Figure 8: Searching the Binding Cache
A correspondent node learns the BID when it receives a Binding A correspondent node learns the BID when it receives a Binding
Identifier mobility option. At that time, the correspondent node Identifier mobility option. At that time, the correspondent node
MUST look up its binding cache database with the home address and the MUST look up its binding cache database with the home address and the
BID retrieved from the Binding Update. If the correspondent node BID retrieved from the Binding Update. If the correspondent node
does not know the BID, it searches for a binding with only the home does not know the BID, it searches for a binding with only the home
address. In such a case, the first matched binding is found. If the address. In such a case, the first matched binding is found. If the
correspondent node does not desire to use multiple bindings for a correspondent node does not desire to use multiple bindings for a
mobile node, it can simply ignore the BID. mobile node, it can simply ignore the BID.
skipping to change at page 22, line 35 skipping to change at page 28, line 35
receiver node MUST have only one binding cache entry for the mobile receiver node MUST have only one binding cache entry for the mobile
node. If the Binding Update is for de-registration, the receiver node. If the Binding Update is for de-registration, the receiver
MUST delete all existing bindings from its Binding Cache. 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 'C' and 'D' flags. 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 'C' flag is set, the care-of address MUST be present in o When the Length value is either 12 or 20, the care-of address MUST
the Binding Identifier mobility option. If the care-of address is be present in the Binding Identifier mobility option. If the
not present, the receiver MUST reject the Binding Identifier care-of address is not present, the receiver MUST reject the
mobility option and returns the status value set to [MCOA Binding Identifier mobility option and returns the status value
MALFORMED]. The operation of 'D' flag is described in Section 8 set to [MCOA MALFORMED]. If the Length value is 12, an IPv4 valid
address MUST be present. Otherwise, an IPv6 address MUST be
stored in 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
reject the Binding Update and send a Binding Acknowledgement with reject the Binding Update and send a Binding Acknowledgement with
status set to 133 [not home agent for this mobile node]. status set to 133 [not home agent for this mobile node].
o If the 'O' flag is set in the de-registering Binding Update, it is o If the 'O' flag is set in the de-registering Binding Update, it is
ignored. If the 'H' flag is set, the home agent stores a home ignored. If the 'H' flag is set, the home agent stores a home
address in the Care-of Address field of the binding cache entry. address in the Care-of Address field of the binding cache entry.
skipping to change at page 23, line 20 skipping to change at page 29, line 22
ignored. If the 'H' flag is set, the home agent stores a home ignored. If the 'H' flag is set, the home agent stores a home
address in the Care-of Address field of the binding cache entry. address in the Care-of Address field of the binding cache entry.
The home agent also stops performing proxy ND for the mobile The home agent also stops performing proxy ND for the mobile
node's home address. node's home address.
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 'C' flag is set in the Binding Identifier mobility * If the Length value of the Binding Identifier mobility option
option, the care-of address is copied from the care-of address is 20, the care-of address is copied the IPv6 address from the
field in the Binding Identifier mobility option. care-of address field in the Binding Identifier mobility
option. When the Length value is 12, the address MUST be the
IPv4 valid address. Detail information can be found in
Section 8.
* If the 'C' flag is not set in the Binding Identifier mobility * If the Length value of the Binding Identifier mobility option
option, the care-of address is copied from the source address is 4, the care-of address is copied from the source address
field of the IPv6 header. field of the IPv6 header.
* If the 'C' flag is not set and an alternate care-of address is * If the Length value of the Binding Identifier mobility option
present, the care-of address is copied from the Alternate is 4 and an alternate care-of address is present, the care-of
Care-of address mobility option. address is copied from the Alternate Care-of address mobility
option.
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 only the 'O' flag is set in the Binding Identifier mobility * If only the 'O' flag is set in the Binding Identifier mobility
option, the home agent removes all the existing bindings and option, the home agent removes all the existing bindings and
registers the received bindings. registers the received bindings.
* If the receiver has a regular binding which does not have BID * If the receiver has a regular binding which does not have BID
for the mobile node, it must not process the binding update. for the mobile node, it must not process the binding update.
skipping to change at page 26, line 29 skipping to change at page 33, line 29
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 from an
IPv4 care-of address. This is because, the Binding Update and IPv4 care-of address. This is because, the Binding Update and
binding acknowledgement exchange is used to detect NAT on the path binding acknowledgement exchange is used to detect NAT on the path
between the mobile node and the home agent. So the mobile node needs between the mobile node and the home agent. So the mobile node needs
to check for a NAT between each IPv4 care-of address and the home to check for a NAT between each IPv4 care-of address and the home
agent. 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 5. 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
Mobility header Mobility header
-BU -Binding Update
Mobility Options Mobility Options
- Binding Identifier (IPv4 CoA) - Binding Identifier (IPv4 CoA)
Figure 5: Initial Binding Update for IPv4 Care-of Address Figure 9: Initial Binding Update for IPv4 Care-of Address
If a NAT is not detected, the mobile node can update the IPv4 care-of If a NAT is not detected, the mobile node can update the IPv4 care-of
address by using bulk registration. The mobile node can register the address by using bulk registration. The mobile node can register the
IPv4 care-of address along with other IPv4 and IPv6 care-of IPv4 care-of address along with other IPv4 and IPv6 care-of
addresses. Figure 6 shows the Binding Update format when the mobile addresses. Figure 10 shows the Binding Update format when the mobile
node sends a Binding Update from one of its IPv6 care-of addresses. node sends a Binding Update from one of its IPv6 care-of addresses.
If the mobile node sends a BU from IPv4 care-of address, it MUST If the mobile node sends a Binding Update from IPv4 care-of address,
follow the format described in Figure 5. Note that the IPv4 Care-of it MUST follow the format described in Figure 9. Note that the IPv4
Address must be registered by non bulk Binding registration, whenever Care-of Address must be registered by non bulk Binding registration,
it is changed. whenever it is changed.
IPv6 header (src=V6CoA, dst=HAADDR) IPv6 header (src=V6CoA, dst=HAADDR)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header ESP Header
Mobility header Mobility header
-BU -Binding Update
Mobility Options Mobility Options
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- ... - ...
Figure 6: Binding Bulk Registration for IPv4 care-of address Figure 10: Binding Bulk Registration for IPv4 care-of address
If the home agent rejects the IPv4 care-of address, it MUST store the If the home agent rejects the IPv4 care-of address, it MUST store the
error code value in the Status field of the BID mobility option. error code value in the Status field of the BID mobility option.
8.2. IPv4 HoA Management 8.2. IPv4 HoA Management
When the mobile node wants to configure an IPv4 home address in When the mobile node wants to configure an IPv4 home address in
addition to the IPv6 home address, it can request for one using the addition to the IPv6 home address, it can request for one using the
IPv4 Home Address option in the Binding Update. If the home agent IPv4 Home Address option in the Binding Update. If the home agent
accepts the Binding Update, the mobile node can now register multiple accepts the Binding Update, the mobile node can now register multiple
skipping to change at page 33, line 18 skipping to change at page 40, line 18
o Binding Identifier mobility option type: This must be assigned o Binding Identifier mobility option type: This must be assigned
from the same space as mobility option in [RFC-3775]. from the same space as mobility option in [RFC-3775].
o New Successful Status of Binding Acknowledgement: This status code o New Successful Status of Binding Acknowledgement: This status code
must be assigned from the same space as binding acknowledgement must be assigned from the same space as binding acknowledgement
status codes in [RFC-3775]. status codes in [RFC-3775].
* MCOA NOTCOMPLETE (TBD) * MCOA NOTCOMPLETE (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 BID CONFLICT (TBD)
* MCOA PROHIBITED(TBD) * MCOA PROHIBITED(TBD)
* MCOA BULK REGISTRATION NOT SUPPORTED (TBD) * MCOA BULK REGISTRATION NOT SUPPORTED (TBD)
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Masafumi Aramoto, George Tsirtsis, The authors would like to special thank George Tsirtsis for thorough
Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Lim, Susumu review and suggestions. The authors would also like to thank
Koshiba, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Hiroki Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin
Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada, Keisuke Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas
Uehara, Masafumi Watari in alphabetical order, and the Jun Murai Montavont for their discussions and inputs. Thanks to Susumu
Laboratory at the KEIO University. Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke
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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
13.2. Informative References 13.2. Informative References
[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
K. Kuladinithi, "Motivations and Scenarios for Using Multiple K. Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-02 (work in draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
skipping to change at page 35, line 7 skipping to change at page 42, line 15
draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver
2007. 2007.
[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-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.
[ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in and Routers (DSMIPv6)", draft-ietf-mext-v4traversal-01 (work in
progress), November 2007. progress), February 2008.
[ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of [ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of
Addresses in Multiple Bindings Registration", Addresses in Multiple Bindings Registration",
draft-lim-mext-multiple-coa-verify-01 (work in progress), February draft-lim-mext-multiple-coa-verify-01 (work in progress), February
2008. 2008.
Appendix A. Example Configurations [RFC-4068bis] R. Koodli, "Mobile IPv6 Fast Handovers",
draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt (work in progress), April
In this section, we describe typical scenarios when a mobile node has 2008.
multiple network interfaces and acquires multiple Care-of Addresses
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
acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns
BID1, BID2 and BID3 to each care-of address.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
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: Multiple Interfaces Attached to a Foreign Link
Figure 7 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 |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +--------+-+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ | |
+--+--+ | | |
CoA3| +---|-----------+
+---------------+
Binding Cache Database:
home agent's binding
none
correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 8: One of Interface Attached to Home Link and Returning Home
Figure 8 depicts the scenario where MN returns home with one of its
interfaces. After the successful de-registration of the binding to
HA, HA and CN have the binding entries listed in their binding cache
database of Figure 8. After de-registration, the ND state of the
home address is managed by the MN. MN can communicate with the HA
through only the interface attached to the home link. On the other
hand, the mobile node can communicate with CN from the other
interfaces attached to foreign links (i.e. route optimization). Even
if MN is attached to the home link, it can still send Binding Updates
for other active care-of addresses (CoA2 and CoA3) to CNs. If CN has
bindings, packets are routed to each Care-of Addresses directly. Any
packet arrived at HA are routed to the interface attached to the home
link.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
(Disable interface)
Binding Cache Database:
home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 9: One of Interface Attached to Home Link and Not Returning
Home
Figure 9 depicts the scenario where MN disables the interface
attached to the home link and communicates with the interfaces
attached to foreign links. HA continues managing the ND state of the
home address by Proxy neighbor advertisement. The HA and the CN have
the binding entries listed in their binding cache database. 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.
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
CoA3 | |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3 | |
+---------------------------+
Binding Cache Database:
home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
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 10: Utilize Interfaces Attached to both Home and Foreign Links
Figure 10 depicts the scenario where interfaces of MN are attached to
both the home and foreign links. There are two possible topologies
whether the HA is single router at the home link or not. The
operation of ND is different in two topologies. The HA and CN have
the binding entries listed in Figure 10 in their binding cache
database regardless of topologies. The HA also knows that the MN has
attached to the home link. All the traffic from the Internet are
intercepted by the HA and routed to either the interface attached to
the home link or the interfaces attached to the foreign links. How
to make the decision is out of scope in this document.
There are two different treatments of the ND state of the home
address.
o MN defends the home address by regular ND (topology-a)
o HA defends the home address by Proxy ND (topology-b)
The first case is required that the HA is the single exit router to
the Internet and is capable of intercepting packets without relying
on proxy ND. The MN can manage the ND of the home address on the
home link. In the second case, the HA is not only router at the home
link and cannot intercept all the packets meant for the MN by IP
routing. The HA needs to run Proxy ND to intercept all the packets
at the home link. Since the MN cannot operate the ND of its home
address at the home link, HA cannot resolve the layer-2 address of
the MN at the home link. The HA MUST learn and record the layer-2
address (MAC address) of the MN's interface attached to the home link
to forward packets. The packets forwarding is achieved without ND
cache. The MN is also required to learn and record the layer-2
address of the HA's interface to send packets from the home link.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa (Editor) Ryuji Wakikawa
Faculty of Environment and Information Studies, Keio University Toyota ITC / Keio University
5322 Endo 6-6-20 Akasaka, Minato-ku
Fujisawa, Kanagawa 252-8520 Tokyo 107-0052
Japan Japan
Phone: +81-466-49-1100 Phone: +81-3-5561-8276
Fax: +81-466-49-1395 Fax: +81-3-5561-8292
Email: ryuji@sfc.wide.ad.jp Email: ryuji@jp.toyota-itc.com
URI: http://www.wakikawa.org/
Thierry Ernst Thierry Ernst
INRIA INRIA
INRIA Rocquencourt INRIA Rocquencourt
Domaine de Voluceau B.P. 105 Domaine de Voluceau B.P. 105
Le Chesnay, 78153 Le Chesnay, 78153
France France
Phone: +33-1-39-63-59-30 Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91 Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr Email: thierry.ernst@inria.fr
skipping to change at page 41, line 27 skipping to change at page 43, line 40
INTEC NetCore Inc. INTEC NetCore Inc.
1-3-3, Shin-suna 1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075 Koto-ku, Tokyo 135-0075
Japan Japan
Phone: +81-3-5565-5069 Phone: +81-3-5565-5069
Fax: +81-3-5565-5094 Fax: +81-3-5565-5094
Email: nagami@inetcore.com Email: nagami@inetcore.com
Vijay Devarapalli Vijay Devarapalli
Azaire Networks Wichorus
3121 Jay Street 3590 North First St
Santa Clara, CA 95054 San Jose, CA 95134
USA USA
Email: vijay.devarapalli@azairenet.com Email: vijay@wichorus.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 81 change blocks. 
455 lines changed or deleted 528 lines changed or added

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