draft-ietf-monami6-multiplecoa-08.txt   draft-ietf-monami6-multiplecoa-09.txt 
MEXT Working Group R. Wakikawa (Ed.) MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Toyota ITC/Keio Univ. Internet-Draft Toyota ITC/Keio Univ.
Intended status: Standards Track V. Devarapalli (Ed.) Intended status: Standards Track V. Devarapalli (Ed.)
Expires: December 1, 2008 Wichorus Expires: March 1, 2009 Wichorus
T. Ernst T. Ernst
INRIA INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
May 30, 2008 August 28, 2008
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-08.txt draft-ietf-monami6-multiplecoa-09.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 December 1, 2008. This Internet-Draft will expire on March 1, 2009.
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 7, line 43 skipping to change at page 7, line 43
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 Figure 1 illustrates the configuration where the mobile node obtains
multiple care-of addresses at foreign links. The mobile node can multiple care-of addresses at foreign links. The mobile node can
utilize all the care-of addresses. In Figure 1, the home address of utilize all the care-of addresses. In Figure 1, the home address of
the mobile node (MN) is a:b:c:d::EUI. The mobile node has 3 the mobile node (MN) is 2001:db8::EUI. The mobile node has 3
different interfaces and possibly acquires care-of addresses 1-3 different interfaces and possibly acquires care-of addresses 1-3
(CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to
each care-of address. each care-of address.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+---+-+ +--+-+ | +----+---+-+ +--+-+
CoA2| | | | Home Link CoA2| | | | Home Link
+--+--+ | | ------+------ +--+--+ | | ------+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 | +--+--+ CoA1 |
CoA3| | CoA3| |
+---------------+ +---------------+
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active) home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1] binding [2001:db8::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [2001:db8::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [2001:db8::EUI care-of address3 BID3]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [2001:db8::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [2001:db8::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [2001:db8::EUI care-of address3 BID3]
Figure 1: Multiple Care-of Address Registration 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 if a BID is available. This is different from RFC 3775,
address is used for binding cache lookup. The binding cache lookup where only the home address is used for binding cache lookup.
may also involve policy or flow filters in cases where some policy or Binding cache lookup is operated for either protocol signaling and
flow filters are used to direct certain packets or flows to a data packets. For the protocol signaling such as a binding update,
particular care-of address. The binding cache lookup using policy or BID should be always carried by a BID sub-option in a protocol
flow filters is out of scope for this document. In case the binding signaling. Therefore, a correspondent binding cache that matches the
cache lookup, using the combination of home address and BID, does not specified BID MUST be found from the binding cache database. On the
return a valid binding cache entry, the home agent MAY perform other hand, for the data packets, no BID information is carried in a
another lookup based on only the home address. This is packet. The binding cache lookup may involve policy or flow filters
implementation dependent and configurable on the home agent. to retrieve a correspondent BID per packet in cases where some policy
or flow filters are used to direct a certain packet or flow to a
particular care-of address. However, the binding cache lookup using
policy or flow filters is out of scope for this document. If no such
mechanism is available and no BID is found for a packet, a node can
lookup based on only the home address. It uses the first matched
binding or a binding in a round robin fashion. This is
implementation dependent and configurable on a node. In case the
binding cache lookup for data packets, using the combination of home
address and BID, does not return a valid binding cache entry, the
home agent MAY perform another lookup based on only the home address.
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 two options possible for the mobile node when
when its returns home. Section 5.6 describes the returning home its returns home. Section 5.6 describes the returning home
procedures in more detail. 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. This is illustrated in Figure 2. It de-registers the home link. This is illustrated in Figure 2. It de-registers
all bindings with the home agent related to all care-of all bindings with the home agent related to all care-of
addresses. The interfaces still attached to the visited link(s) addresses. The interfaces still attached to the visited link(s)
are no longer going to be receiving any encapsulated traffic from are no longer going to be receiving any encapsulated traffic from
the home agent. On the other hand, the mobile node can continue the home agent. On the other hand, the mobile node can continue
communicating with the correspondent node from the other communicating with the correspondent node from the other
interfaces attached to foreign links by using route optimization. interfaces attached to foreign links by using route optimization.
skipping to change at page 9, line 39 skipping to change at page 9, line 49
+--+--+ | --+---+------ +--+--+ | --+---+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 | +--+--+ CoA1 |
| | | |
+---------------------------+ +---------------------------+
Binding Cache Database: Binding Cache Database:
home agent's binding home agent's binding
none none
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [2001:db8::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [2001:db8::EUI care-of address2 BID2]
Figure 2: Using only Interface Attached to Home Link 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 may simultaneously use both the interface
visited link(s) as shown in Figure 3. The interface with which
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
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) as shown in Figure 4. There are two possible the visited link(s) as shown in Figure 3. There are two possible
topologies depending on whether the home agent is only router on topologies depending on whether the home agent is only router on
the home link or not. The operation of Neighbor Discovery [RFC- the home link or not. The operation of Neighbor Discovery [RFC-
2461] is different in the two topologies. The home agent and the 4861] is different in the two topologies. More details can be
correspondent node have the binding entries listed in Figure 4 in found in Section 5.6.3. The home agent and the correspondent
their binding cache database in both topologies. The home agent node have the binding entries listed in Figure 3 in their binding
also knows that the mobile node has attached to the home link. cache database in both topologies. The home agent also knows
All the traffic from the Internet is intercepted by the home that the mobile node is attached to the home link. All the
agent first and routed to either the interface attached to the traffic from the Internet is intercepted by the home agent first
home link or the one of the foreign links. How the home agent and routed to either the interface attached to the home link or
decides to route a particular flow to the interface attached to the one of the foreign links. How the home agent decides to
the home link or foreign link is out of scope in this document. route a particular flow to the interface attached to the home
link or foreign link is out of scope in this document.
Topology-a) Topology-a)
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+-----+ +--+-+ | +----+-----+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
skipping to change at page 11, line 37 skipping to change at page 11, line 37
| +----+-----+ | +--+-+ | +----+-----+ | +--+-+
CoA2| | | | Home Link CoA2| | | | Home Link
+--+--+ | --+-+-------+------ +--+--+ | --+-+-------+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 | +--+--+ CoA1 |
| | | |
+---------------------------+ +---------------------------+
Binding Cache Database: Binding Cache Database:
home agent's binding home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [2001:db8::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [2001:db8::EUI care-of address2 BID2]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [2001:db8::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [2001:db8::EUI care-of address2 BID2]
Figure 4: Simultaneous Home and Visited Link Operation Figure 3: 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.
skipping to change at page 12, line 38 skipping to change at page 12, line 38
MUST NOT use the bulk registration for the binding whose sequence MUST NOT use the bulk registration for the binding whose sequence
number is out of window. A separate Binding Update should be sent number is out of window. A separate Binding Update should be sent
for the binding. 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. The Binding Identifier Mobility Test Init and Care-of Test message. The Binding Identifier Mobility
Option has an alignment requirement of 2n if the Care-of Address Option has an alignment requirement of 2n if the Care-of Address
field is not presented. Otherwise, it has the alignment requirement field is not present. Otherwise, it has the alignment requirement of
of 8n + 2. 8n + 2.
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 |O|H| Reserved | | Binding ID (BID) | Status |O|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
: IPv4 or IPv6 care-of address (CoA) : : IPv4 or IPv6 care-of address (CoA) :
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 5: BID Mobility Option Figure 4: 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. It MUST be set to either 4, excluding the Type and Length fields. It MUST be set to either 4,
12, or 20 depending on the care-of address field. When the 12, or 20 depending on the care-of address field. When the
skipping to change at page 13, line 44 skipping to change at page 13, line 44
stored in the Binding Acknowledgement message. The receiver MUST stored in the Binding Acknowledgement message. The receiver MUST
ignore this field if the Binding Identifier mobility option is not ignore this field if the Binding Identifier mobility option is not
carried within either the Binding Acknowledgement or the Care-of carried within either the Binding Acknowledgement or the Care-of
Test messages. The possible status codes are the same as the Test messages. The possible status codes are the same as the
status codes of Binding Acknowledgement. This Status field is status codes of Binding Acknowledgement. This Status field is
also used to carry error information related to the care-of also used to carry error information related to the care-of
address test in the Care-of Test message. address test in the Care-of Test message.
Overwrite (O) flag Overwrite (O) flag
When this flag is set, a mobile node requests the recipient to When this flag is set, all the binding cache entries for a mobile
replace all the bindings to binding entries stored in a Binding node are replaced by new entries registering with this binding
Update. update message.
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.
Reserved Reserved
5 bits Reserved field. The value MUST be initialized to zero by 5 bits Reserved field. The value MUST be initialized to zero by
skipping to change at page 15, line 16 skipping to change at page 15, line 16
when the received binding conflicts with the existing binding when the received binding conflicts with the existing binding
cache entry(ies). cache entry(ies).
MCOA PROHIBITED(TBD more than 128) MCOA PROHIBITED(TBD more than 128)
It implies the multiple care-of address registration is It implies the multiple care-of address registration is
administratively prohibited. administratively prohibited.
MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128)
Bulk binding registration is not supported. Bulk binding registration is not supported. Note that the bulk
registration is optional procedure and might not be available on a
home agent.
5. Mobile Node Operation 5. Mobile Node Operation
5.1. Management of Care-of Address(es) and Binding Identifier(s) 5.1. Management of Care-of Address(es) and Binding Identifier(s)
There are two cases when a mobile node might acquire several care-of There are two cases when a mobile node might acquire several care-of
addresses. Note that a mixture of the two cases is also possible. addresses. Note that a mixture of the two cases is also possible.
1. A mobile node may be using several physical network interfaces 1. A mobile node may be using several physical network interfaces
and acquires a care-of address on each of its interfaces. and acquires a care-of address on each of its interfaces.
skipping to change at page 17, 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 6. The BID is copied from a corresponding Binding as shown in Figure 5. 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.
skipping to change at page 17, line 40 skipping to change at page 17, line 40
IPv6 Home Address Option IPv6 Home Address Option
ESP Header* ESP Header*
Mobility header Mobility header
Binding Update Binding Update
Mobility Options Mobility Options
Binding Identifier mobility option Binding Identifier mobility option
Binding Authorization mobility option+ Binding Authorization mobility option+
(*) if necessary, for home registration (*) if necessary, for home registration
(+) if necessary, for route optimization (+) if necessary, for route optimization
Figure 6: Binding Update for Binding Registration Figure 5: 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. This document specifies bulk registration only for the scarce. This document specifies bulk registration only for the
mobile node's home registration. A mobile node performing bulk mobile node's home registration. A mobile node performing bulk
registration with a correspondent node is out of scope. registration with a correspondent node is out of scope.
To use bulk registration, the mobile node includes a Binding To use bulk registration, the mobile node includes a Binding
Identifier Mobility option for each BID and Care-of address pair it Identifier Mobility option for each BID 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 7. The rest of the fields and options in the Binding in Figure 6. The rest of the fields and options in the Binding
Update such as Lifetime, Sequence Number, and the flags in the Update such as Lifetime, Sequence Number, and the flags in the
Binding Update are common across all care-of addresses. The Binding Update are common across all care-of addresses. The
alternate care-of address option MUST NOT be used. alternate care-of address option MUST NOT be used.
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
Binding Update Binding Update
Mobility Options Mobility Options
Binding Identifier mobility options (CoA) Binding Identifier mobility options (CoA)
Figure 7: Binding Update for Bulk Registration Figure 6: 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 19, line 23 skipping to change at page 19, line 23
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(s). While the mobile node de-registers attached to the visited link(s). While the mobile node de-registers
all the bindings from the home agent, it may continue registering all the bindings from the home agent, it may continue registering
bindings for interface(s) attached to visited link(s) to the bindings for interface(s) attached to visited link(s) to the
correspondent node as shown in Figure 2. 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 in physically and shuts down the
the home link as shown in Figure 3. Before shutting down the interface attached to the home link. As a result, a mobile node does
interface, any binding for the care-of address previously associated not return home even though it attaches to the home link by one of
with the interface should be deleted. To delete the binding cache interfaces. Following procedures should be taken by the mobile node.
entry, the mobile node SHOULD send a de-registration Binding Update Before shutting down the interface, any binding for the care-of
with the lifetime set to zero and include the corresponding BID address previously associated with the interface should be deleted.
information. If the mobile node does not send a de-registration To delete the binding cache entry, the mobile node SHOULD send a de-
Binding Update, the binding for the care-of address previously registration Binding Update with the lifetime set to zero and include
assigned to the interface remains at the home agent until its the corresponding BID information. If the mobile node does not send
lifetime expires. a de-registration Binding Update, the binding for the care-of address
previously assigned to the interface remains at the home agent until
its lifetime expires.
In this scenario, despite the fact that the mobile node is connected In this scenario, despite the fact that the mobile node is connected
to its home link, all of its traffic is sent and received via the to its home link, all of its traffic is sent and received via the
home agent and its foreign links. home agent and its foreign links.
5.6.3. Simultaneous Home and Visited Link Operation 5.6.3. Simultaneous Home and Visited Link Operation
[Problems of Simultaneous Home and Foreign Attachments] [Problems of Simultaneous Home and Foreign Attachments]
The mobile node returns home and continues using all the interfaces The mobile node returns home and continues using all the interfaces
attached to both foreign and home links as shown in Figure 4. The attached to both foreign and home links as shown in Figure 3. The
mobile node indicates this by setting the 'H' flag in the BID mobile node indicates this by setting the 'H' flag in the BID
mobility option as defined below. There are additional requirements mobility option as defined below. There are additional requirements
on the Returning Home procedures for possible Neighbor Discovery on the Returning Home procedures for possible Neighbor Discovery
states conflicts at the home link. 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 the Proxy Neighbor Discovery [RFC-2461] while the mobile node using the Proxy Neighbor Discovery [RFC-4861] while the mobile
node is away from the home link. When the mobile node returns home, node is away from the home link. When the mobile node returns home,
the home agent deletes the binding cache and stops proxying for the the home agent deletes the binding cache and stops proxying for the
home address so that a mobile node can configure its home address on home address so that a mobile node can configure its home address on
the interface attached to the home link. In this specification, a the interface attached to the home link. In this specification, a
mobile node may return home, configure the home address on the mobile node may return home, configure the home address on the
interface attached to the home link, but still use the interfaces interface attached to the home link, but still use the interfaces
attached to the foreign links. In this case, a possible conflict attached to the foreign links. In this case, a possible conflict
arises when the both the home agent and the mobile node try to defend arises when the both the home agent and the mobile node try to defend
the home address. If the home agent stops proxying for the home the home address. If the home agent stops proxying for the home
address, the packets are always routed to the interface attached to address, the packets are always routed to the interface attached to
skipping to change at page 20, line 31 skipping to change at page 20, line 34
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 flow. How to make this decision is out of scope in this type of flow. How to make this decision is out of scope in this
document. document.
Two scenarios are illustrated in Figure 4, depending on whether the Two scenarios are illustrated in Figure 3, depending on whether the
Home Agent is the only router at the home link or not. The Home Agent is the only router at the home link or not. The
difference is on who defends the home address by (Proxy) Neighbor difference is on who defends the home address by (Proxy) Neighbor
Discovery on the home link. Discovery on the home link.
1. Mobile node defends the home address by the regular Neighbor 1. Mobile node defends the home address by the regular Neighbor
Discovery Protocol (illustrated as topology-a in Figure 4). The Discovery Protocol (illustrated as topology-a in Figure 3). The
home agent is the only router on the home link. Therefore the home agent is the only router on the home link. Therefore the
home agent is capable of intercepting packets without relying on home agent is capable of intercepting packets without relying on
the proxy Neighbor Discovery protocol and the mobile node can the proxy Neighbor Discovery protocol and the mobile node can
manage the Neighbor Cache entry of the home address on the home manage the Neighbor Cache entry of the home address on the home
link as a regular IPv6 node. link as a regular IPv6 node.
2. If there are other routers on the home link apart from the home 2. If there are other routers on the home link apart from the home
agent, then it cannot be guaranteed that all packets meant for agent, then it cannot be guaranteed that all packets meant for
the mobile node are routed to the home agent. In this case, the the mobile node are routed to the home agent. In this case, the
mobile node MUST NOT operate Neighbor Discovery protocol for the mobile node MUST NOT operate Neighbor Discovery protocol for the
home address on the home link. This allows the home agent to home address on the home link. This allows the home agent to
keep using proxy neighbor discovery and thus it keeps receiving keep using proxy neighbor discovery and thus it keeps receiving
all the packets sent to the mobile node's home address. If the all the packets sent to the mobile node's home address. If the
home agent, according to its local policy, needs to deliver home agent, according to its local policy, needs to deliver
packets to the mobile node over the home link, an issue arises packets to the mobile node over the home link, an issue arises
with respect to how the home agent discovers the mobile node's with respect to how the home agent discovers the mobile node's
link local address. This specification uses Link-layer Address link local address. This specification uses Link-layer Address
(LLA) Option defined in [RFC-4068bis] in order to carry the (LLA) Option defined in [RFC-5268] in order to carry the mobile
mobile node's link-layer address in the Binding Update. node's link-layer address in the Binding Update. Likewise, the
Likewise, the mobile node would also know the link-layer address mobile node would also know the link-layer address of the default
of the default router address to send packets from the home link router address to send packets from the home link without
without Neighbor Discovery. The link-layer address is used to Neighbor Discovery. The link-layer address is used to transmit
transmit packets from and to the mobile node on the home link. packets from and to the mobile node on the home link. The
The packets are transmitted without the Neighbor Discovery packets are transmitted without the Neighbor Discovery protocol
protocol by constructing the link-layer header manually. This by constructing the link-layer header manually. This operation
operation is similar to Mobile IPv6 [RFC-3775] when a mobile node is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a
sends a deregistration binding update to the home agent's link- deregistration binding update to the home agent's link-layer
layer address in returning home operation. address in returning home operation.
[Sending Deregistration Binding Update] [Sending Deregistration Binding Update]
o As soon as a mobile node returns home, it sends a de-registration 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 Binding Update to the home agent from the interface attached to
the home link. the home link.
o The mobile node MUST include the BID mobility option specifying o The mobile node MUST include the BID mobility option specifying
the BID the mobile node had previously associated with the the BID the mobile node had previously associated with the
interface attached to the home link. The 'H' flag MUST be set in 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 the BID mobility option. None of the care-of address MUST be sent
Care-of Address field in the BID mobility option. When the 'H' in the Care-of Address field of the BID mobility option. When the
flag is set, the home agent recognizes that the mobile node wants 'H' flag is set, the home agent recognizes that the mobile node
to continue using interfaces attached to both home and visited wants to continue using interfaces attached to both home and
links. Note that H flag MUST be set for all the binding updates visited links. Note that H flag MUST be set for all the binding
sent from the mobile node (ex. Binding Update for the updates sent from the mobile node (ex. Binding Update for the
interface(s) attached to the foreign link(s)). interface(s) attached to the foreign link(s)).
o The mobile node SHOULD include the Link-layer Address (LLA) Option o The mobile node SHOULD include the Link-layer Address (LLA) Option
[RFC-4068bis] to notify the mobile node's link-layer address to [RFC-5268] to notify the mobile node's link-layer address to the
the home agent, too. The option code of the Link-layer Address home agent, too. The option code of the Link-layer Address (LLA)
(LLA) option MUST be set to '2' (Link-layer Address of the mobile option MUST be set to '2' (Link-layer Address of the mobile node).
node). This link-layer address is required for the home agent to This link-layer address is required for the home agent to send the
send the Binding Acknowledgement and to forward the mobile node's Binding Acknowledgement and to forward the mobile node's packet.
packet.
o According to [RFC-3775], the mobile node MUST start responding to o According to [RFC-3775], the mobile node MUST start responding to
Neighbor Solicitation for its home address right after it sends Neighbor Solicitation for its home address right after it sends
the deregistration Binding Update to the home agent. However, in the deregistration Binding Update to the home agent. However, in
this specification, the mobile node MUST NOT respond to Neighbor this specification, the mobile node MUST NOT respond to Neighbor
Solicitation before receiving a Binding Acknowledgement, since the Solicitation before receiving a Binding Acknowledgement, since the
home agent may continue proxying for the home address. If the home agent may continue proxying for the home address. If the
mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value
in the received Binding Acknowledgment, it MUST NOT respond to in the received Binding Acknowledgment, it MUST NOT respond to
Neighbor Solicitation even after the Binding Acknowledgement. Neighbor Solicitation even after the Binding Acknowledgement.
skipping to change at page 22, line 28 skipping to change at page 22, line 29
address at the home link. This is regular returning home address at the home link. This is regular returning home
operation of [RFC-3775] operation of [RFC-3775]
* MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
address at the home link address at the home link
If the binding update is rejected, the appropriate error value If the binding update is rejected, the appropriate error value
MUST be set to the status field. In this case, the home agent MUST be set to the status field. In this case, the home agent
operation is same as [RFC-3775]. operation is same as [RFC-3775].
o If the home agent is the only router at the home link, it stops o Only if the home agent is certainly the only router in the home
proxy Neighbor Discover for the requested home address and link, it MAY turn off Neighbor Discovery for the requested home
responds with the [Binding Update Accepted] status value to the address and responds with the [Binding Update Accepted] status
mobile node. Since the mobile node will not reply to Neighbor value to the mobile node. Since the mobile node will not reply to
Solicitation for the home address before receiving the Binding Neighbor Solicitation for the home address before receiving the
Acknowledgement, the home agent SHOULD use the link-layer address Binding Acknowledgement, the home agent SHOULD use the link-layer
carried by the Link Layer Address option [RFC-4068bis] in the address carried by the Link Layer Address option [RFC-5268] in the
received Binding Update. After the completion of the binding received Binding Update. After the completion of the binding
deregistration, the mobile node starts regular Neighbor Discovery deregistration, the mobile node starts regular Neighbor Discovery
operations for the home address on the home link. The neighbor operations for the home address on the home link. The neighbor
cache entry for the home address is created by the regular cache entry for the home address is created by the regular
exchange of Neighbor Solicitation and Neighbor Advertisement. exchange of Neighbor Solicitation and Neighbor Advertisement.
o On the other hand, if the home agent is not the only router on the o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP]
home link, it returns [MCOA RETURNHOME WO/NDP] value in the Status value in the Status field of the BID mobility option. The home
field of the BID mobility option. The home agent learns the agent learns the mobile node's link-layer address by receiving the
mobile node's link-layer address by receiving the link-layer link-layer address option carried by the Binding Update. It
address option carried by the Binding Update. It stores the link- stores the link-layer address as a neighbor cache entry for the
layer address as a neighbor cache entry for the mobile node so mobile node so that it can send the packets to the mobile node's
that it can send the packets to the mobile node's link-layer link-layer address.
address.
o Note that the use of proxy Neighbor Discovery is easier way to o Note that the use of proxy Neighbor Discovery is easier way to
intercept the mobile nodes' packets instead of IP routing in some intercept the mobile nodes' packets instead of IP routing in some
deployment scenarios. Therefore, even if a home agent is the only deployment scenarios. Therefore, even if a home agent is the only
router, it is an implementation and operational choice whether the router, it is an implementation and operational choice whether the
home agent returns [Binding Update Accepted] or [MCOA RETURNHOME home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
WO/NDP]. WO/NDP].
o If BID option is not included in the Binding Acknowledgement, the o If BID option is not included in the Binding Acknowledgement, the
home agent might not recognize the simultaneous home and foreign home agent might not recognize the simultaneous home and foreign
skipping to change at page 23, line 44 skipping to change at page 23, line 44
learn the link-layer address of the next hop (i.e. default router learn the link-layer address of the next hop (i.e. default router
of the mobile node). A mobile node learns the default router's of the mobile node). A mobile node learns the default router's
link-layer address from a Source Link-Layer Address option in link-layer address from a Source Link-Layer Address option in
Router Advertisements. The mobile node sends packets directly to Router Advertisements. The mobile node sends packets directly to
the default router's link-layer address. This is done by the default router's link-layer address. This is done by
constructing the packet including link-layer header with the constructing the packet including link-layer header with the
learned link-layer address of the default router. The home agent learned link-layer address of the default router. The home agent
also forwards the packet to the mobile node on the home link by also forwards the packet to the mobile node on the home link by
using the mobile node's link-layer address. The link-layer using the mobile node's link-layer address. The link-layer
address SHOULD be cached when the home agent received the address SHOULD be cached when the home agent received the
deregistration Binding Update message. deregistration Binding Update message. Note that the default
router MUST NOT cache the mobile node's link-layer address as a
neighbor cache when it forwards the packet from the mobile node to
the home agent.
[Leaving from the Home Link] [Leaving from the Home Link]
o When the mobile node detaches from the home link, it SHOULD o When the mobile node detaches from the home link, it SHOULD
immediately send a binding update for one of active care-of immediately send a binding update for one of active care-of
address with H flag unset. When the 'H' flag of BID option is address with H flag unset. When the 'H' flag of BID option is
unset in any Binding Update, the home agent stop forwarding the unset in any Binding Update, the home agent stop forwarding the
mobile node's packet to the home link. mobile node's packet to the home link.
o On the other hand, if the mobile node does not have any active 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 care-of address to send a Binding Update and leaves the home link
(i.e. the mobile node is completely disconnected), the home agent (i.e. the mobile node is completely disconnected), the home agent
continues forwarding packets to the mobile node until the continues forwarding packets to the mobile node until the
skipping to change at page 27, line 23 skipping to change at page 27, line 23
management. This document does not provide any mechanism 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 node which is either a correspondent node or a home agent SHOULD A node which is either a correspondent node or a home agent SHOULD
use both the home address and the BID as the search key of the use both the home address and the BID as the search key of the
binding cache if it knows the corresponding BID (ex. when processing binding cache if it knows the corresponding BID (ex. when processing
signaling messages). In the example below, if a node searches the signaling messages). In the example below, if a node searches the
binding with the home address and BID2, it gets binding2 for this binding with the home address and BID2, it gets binding2 for this
mobile node. mobile node.
binding1 [a:b:c:d::EUI, care-of address1, BID1] binding1 [2001:db8::EUI, care-of address1, BID1]
binding2 [a:b:c:d::EUI, care-of address2, BID2] binding2 [2001:db8::EUI, care-of address2, BID2]
binding3 [a:b:c:d::EUI, care-of address3, BID3] binding3 [2001:db8::EUI, care-of address3, BID3]
Figure 8: Searching the Binding Cache Figure 7: Searching the Binding Cache
The node learns the BID when it receives a Binding Identifier The node learns the BID when it receives a Binding Identifier
mobility option. At that time, the node MUST look up its binding mobility option. At that time, the node MUST look up its binding
cache database with the home address and the BID retrieved from the cache database with the home address and the BID retrieved from the
Binding Update. If the node does not know the BID, it searches for a Binding Update. If the node does not know the BID, it searches for a
binding with only the home address. In such a case, the first binding with only the home address. In such a case, the first
matched binding is found. If the node does not desire to use matched binding is found. If the node does not desire to use
multiple bindings for a mobile node, it can simply ignore the BID. multiple bindings for a mobile node, it can simply ignore the BID.
6.2. Receiving CoTI and Sending CoT 6.2. Receiving CoTI and Sending CoT
skipping to change at page 32, line 11 skipping to change at page 32, line 11
binding is found, the packets MUST be discarded. The node MUST also binding is found, the packets MUST be discarded. The node MUST also
send a Binding Error message as specified in [RFC-3775]. This send a Binding Error message as specified in [RFC-3775]. This
verification MUST NOT be done for a Binding Update. verification MUST NOT be done for a Binding Update.
7. Network Mobility Applicability 7. Network Mobility Applicability
The binding management mechanisms are the same for a mobile host that The binding management mechanisms are the same for a mobile host that
uses Mobile IPv6 and for a mobile router that is using the NEMO Basic uses Mobile IPv6 and for a mobile router that is using the NEMO Basic
Support protocol [RFC-3963]. Therefore the extensions described in Support protocol [RFC-3963]. Therefore the extensions described in
this document can also be used to support a mobile router with this document can also be used to support a mobile router with
multiple care-of addresses. multiple care-of addresses. [RFC-4980] is a document for an analysis
of NEMO multihoming.
8. DSMIPv6 Applicability 8. DSMIPv6 Applicability
Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to
register an IPv4 care-of address instead of the IPv6 care-of address register an IPv4 care-of address instead of the IPv6 care-of address
when the mobile node is attached to an IPv4-only access network. It when the mobile node is attached to an IPv4-only access network. It
also allows the mobile node to acquire an IPv4 home address in also allows the mobile node to acquire an IPv4 home address in
addition to an IPv6 home address for use with IPv4-only correspondent addition to an IPv6 home address for use with IPv4-only correspondent
nodes. This section describes how multiple care-of address nodes. This section describes how multiple care-of address
registration works with IPv4 care-of and home addresses. registration works with IPv4 care-of and home addresses.
skipping to change at page 33, 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 9. It is similar to using UDP and IPv4 headers as shown in Figure 8. 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
-Binding Update -Binding Update
Mobility Options Mobility Options
- Binding Identifier (IPv4 CoA) - Binding Identifier (IPv4 CoA)
Figure 9: Initial Binding Update for IPv4 Care-of Address Figure 8: 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 10 shows the Binding Update format when the mobile addresses. Figure 9 shows the Binding Update format when the mobile
node sends a Binding Update from one of its IPv6 care-of addresses. node sends a Binding Update from one of its IPv6 care-of addresses.
If the mobile node sends a Binding Update from IPv4 care-of address, If the mobile node sends a Binding Update from IPv4 care-of address,
it MUST follow the format described in Figure 9. Note that the IPv4 it MUST follow the format described in Figure 8. Note that the IPv4
Care-of Address must be registered by non bulk Binding registration, Care-of Address must be registered by non bulk Binding registration,
whenever it is changed. whenever it is changed.
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
-Binding Update -Binding Update
Mobility Options Mobility Options
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- ... - ...
Figure 10: Binding Bulk Registration for IPv4 care-of address Figure 9: 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 41, line 23 skipping to change at page 41, line 23
Uehara, Masafumi Watari and Jun Murai for earlier work on this Uehara, Masafumi Watari and Jun Murai for earlier work on this
subject. subject.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman,
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September
2007..
[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-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.
skipping to change at page 42, line 14 skipping to change at page 42, line 12
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008.
[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-mext-nemo-v4traversal-03 (work in and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in
progress), May 2008. progress), July 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-02 (work in progress), July 2008.
2008.
[RFC-4068bis] R. Koodli, "Mobile IPv6 Fast Handovers", [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June
draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt (work in progress), April
2008. 2008.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC / Keio University Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku 6-6-20 Akasaka, Minato-ku
Tokyo 107-0052 Tokyo 107-0052
Japan Japan
 End of changes. 48 change blocks. 
157 lines changed or deleted 139 lines changed or added

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