One document matched: draft-han-mobileip-adad-01.txt
Differences from draft-han-mobileip-adad-00.txt
IETF Mobile IP Working Group Y. Han
Internet-Draft J. Choi
Expires: December 4, 2003 H. Jang
SAMSUNG AIT
S. Park
SAMSUNG Electronics
July 2003
Advance Duplicate Address Detection
draft-han-mobileip-adad-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 4, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document proposes to automatically allocate a care-of IPv6
addresses (CoA) for the use of mobile nodes that want to be fast
handovered. Each access router maintains 'Passive Proxy Cache' of
which each address is in advance generated and tested for its
uniqueness by the access router. Also, the access router acts as
'Passive Proxy' for an address reserved in 'Passive Proxy Cache' in
order not to affect the destination cache and neighbor cache of its
neighbor nodes and not to disturb the normal CoA configuration
procedure of the nodes which do not obey this draft. During L3
Han, et al. Expires December 4, 2003 [Page 1]
Internet-Draft Advance DAD July 2003
handover, a mobile node, which obeys this draft, requests one of
the duplication-free addresses reserved by its target access router.
After successfully acquiring the address, the mobile node assigns it
on its interface which attaches to the new link, without the RFC 2461
DAD. Consequently, the proposed scheme can completely take off the
DAD procedure and hence the time involved in the exsting L3 handover
schemes
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Advance DAD Requirements . . . . . . . . . . . . . . . . . . . 6
3.1 Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Passive Proxy Requirements . . . . . . . . . . . . . . . . . . 6
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7
4.1 CoA Generation . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Passive Proxy for Duplication-free NCoAs . . . . . . . . . . . 7
4.3 MN Operation for Duplication-free NCoA Configuration . . . . . 8
4.4 NAR Operation for Duplication-free NCoA Configuration . . . . 8
5. New ICMPv6 Options Formats . . . . . . . . . . . . . . . . . . 11
5.1 Duplication-free NCoA Request Option . . . . . . . . . . . . . 11
5.2 Duplication-free NCoA Reply option . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
Han, et al. Expires December 4, 2003 [Page 2]
Internet-Draft Advance DAD July 2003
1. Introduction
To accommodate the increasing demand of mobility in the Internet,
Mobile IPv6 (MIPv6) [2] has been proposed in the IETF. According to
the proposal, a mobile node (MN) should generate a new care-of
address (CoA) using IPv6 stateless address auto-configuration
whenever it moves to new link. As described in [3], to verify the
uniqueness of this CoA, it should run "duplicate address detection
(DAD)" algorithm (in this draft, hereinafter, DAD refers to the
normal DAD as described in [3]) before assigning the address to its
interface which attaches to the new link. After successful DAD, it
registers the new CoA to its home agent (HA) and correspondent nodes
(CNs) using binding update (BU) messages.
In the current protocol, DAD takes at least 1000ms to detect there is
no duplicate address in the link (DupAddrDetectTransmits=1 and
RetransTimer=1000ms as default values in [3]). If MN detects DAD is
failed, it may generate a random interface identifier and repeatedly
run DAD algorithm using the new link-local address. At most 5
consecutive attempts should be performed to generate such addresses
and test them through DAD [2]. Obviously, DAD is a time consuming
process, particularly when MN in need of seamless handover runs it.
During DAD time, any active communications of MN are interrupted, and
this is especially unsuitable for real-time communications.
In this draft, we propose a scheme, named 'advance DAD', that
completely takes off DAD procedure/time from L3 handover procedure/
latency. This is achieved by advance configuration of new CoA, which
will be used without any concern about address collision after MN
moves to new link. To put it precisely, an access router (AR)
generates randomly many addresses in advance and tests their
uniqueness through the existing DAD procedure (these are performed as
background process). After successfully passing the DAD procedure, it
puts the addresses into 'Passive Proxy Cache'. For each address
stored in the cache, AR acts as 'Passive Proxy' in order not to
affect the destination cache and neighbor cache of its neighbor nodes
and not to disturb the RFC 2461 CoA configuration procedure of the
nodes who do not obey this draft. Addresses stored in the cache are
duplication-free.
From MN's viewpoint, such duplication-free address configuration
procedures can be divided into 'predictive' and 'non-predictive'. In
the 'predictive' case, MN can get a duplication-free address from new
target AR (via current AR) before it moves to the target AR's link.
This can be achieved with the help of handover-related messages
(exchanged between MN and current AR, and between current AR and
target AR) defined in the existing handover schemes (e.g., FBU/FBACK,
and HI/HACK in [5]). In the 'non-predictive' case, MN does not engage
Han, et al. Expires December 4, 2003 [Page 3]
Internet-Draft Advance DAD July 2003
in such message exchange before it moves to new AR's link. In this
case, MN gets a duplication-free address from new target AR,
immediately after getting connectivity with this AR. After
successfully acquiring the address, MN immediately assigns it to its
interface without DAD procedure.
Our approach is to allow duplication-free addresses to be configured
"in advance" at each AR as against [5] in which an address is
configured during handover procedure. The benefits of this scheme are
follows.
- It completely eliminates CoA configuration procedure and hence the
time involved in any seamless handover schemes.
- Address collision is completely eliminated provided there is no
packet loss.
- If an anticipation is available (in 'predictive' case) and MN
sends a prediction message with new CoA request to NAR via PAR,
NAR can immediately reply to the message with new duplication-free
CoA, without any confirmation procedure (e.g., DAD).
- In the absence of anticipation (in 'non-predictive' case), MN can
acquire new duplication-free CoA from new AR.
- As the address received by MN from new AR is duplication-free, it
can use this address as the source address of any messages without
DAD procedure immediately after it gets connectivity with new AR.
- If a handover protocol sets up a tunnel between the PAR and the
NAR (in order to forward packets to MN connected to NAR), an
additional protocol for renewing the tunnel must be supported in
preparation for late new CoA configuration. Such support is a
bothersome task on designing overall handover protocol, but it is
indispensable. If advance DAD is used, we do not have to support
the tunnel renewing protocol any more.
Han, et al. Expires December 4, 2003 [Page 4]
Internet-Draft Advance DAD July 2003
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
"silently ignore" in this document are to be interpreted as described
in RFC 2119 [1].
The following terminology and abbreviations are used in this
document.
Previous Access Router (PAR)
- The MN's default router prior to its handover.
New Access Router (NAR)
- The MN's anticipated default router subsequent to its handover.
Previous CoA (PCoA)
- The MN's Care of Address valid on PAR.
New CoA (NCoA)
- The MN's Care of Address valid on NAR.
Duplication-free NCoA
- NCoA of which uniqueness is already guaranteed.
Duplication-free NCoA Request Option
- ICMPv6 Option used by an MN to request a duplication-free NCoA
from NAR.
Duplication-free NCoA Reply Option
- ICMPv6 Option used by an NAR to deliver a duplication-free NCoA
to MN.
Han, et al. Expires December 4, 2003 [Page 5]
Internet-Draft Advance DAD July 2003
3. Advance DAD Requirements
Following subsections list the minimum set of requirements for
advance DAD protocol.
3.1 Basic Requirements
- MN SHOULD be able to request and receive a duplication-free NCoA
from new AR before it moves to the new AR's link in 'predictive'
case, or as soon as it attaches to the new AR's link in
'non-predictive' case.
- AR SHOULD act as Passive Proxy for each of the duplication-free
addresses that it has reserved.
3.2 Passive Proxy Requirements
- Passive Proxy MUST randomly create CoAs, run DAD on the addresses.
- Passive Proxy MUST reserve the addresses after performing DAD on
them.
- Passive Proxy MUST NOT influence any change of destination cache
and neighbor cache of its neighbor nodes.
- If Passive Proxy perceives that a node is trying to create and
configure one of addresses reserved by it, then it MUST abandon
that address and configure another one.
Han, et al. Expires December 4, 2003 [Page 6]
Internet-Draft Advance DAD July 2003
4. Protocol Description
This section describes our protocol in detail.
4.1 CoA Generation
If AR has an interface connected to a link where an MN can move, it
MUST manage a 'Passive Proxy Cache' associated with the interface. In
addition to the original function of packet forwarding, AR generates
globally routable addresses as background process. The number of
address generated initially is at least CAPACITY_OF_POOL. By default,
CAPACITY_OF_POOL is 100, but it SHOULD be configured based on router
capacity and expected MNs' solicitation load. The default address
generation procedure is similar with one described in RFC 3041 [4],
except that the generated interface identifier is appended to the
prefix managed by AR itself. However, a procedure, if any, can be
used for the address generation.
As specified in RFC 3041, AR MUST perform DAD on the each generated
address. If DAD indicates the address is already in use, the address
MUST NOT be reserved into 'Passive Proxy Cache'. After successful
DAD, AR reserves the address into its 'Passive Proxy Cache' and
regards the reserved address as a duplication-free NCoA. AR SHOULD
try to generate new CoA so that the number of addresses reserved in
'Passive Proxy Cache' is up to CAPACITY_OF_POOL.
4.2 Passive Proxy for Duplication-free NCoAs
As soon as a duplication-free NCoA is stored, AR begins to proxy the
address "passively". While AR is serving as Passive Proxy for an
address, it MUST NOT multicast onto its link an unsolicited Neighbor
Advertisement (NA) message with the address. This behavior is the
opposite from Home Agentí¯s behavior. The reason is because AR does
not have to intercept packets delivered to the address. Moreover,
such packets may not be created or delivered from any node until an
MN gets and uses it as its NCoA.
Also, it MUST NOT reply to a Neighbor Solicitation (NS) message with
the Target Address field set to an address stored at 'Passive Proxy
Cache'. Particularly when AR receives an NS for the purpose of DAD
executed from any node (note: in this case, the Source Address field
is the unspecified address), it MUST check if the Target Address
specified in the message matches an address stored at 'Passive Proxy
Cache'. If such an address exists in the cache, it MUST delete the
address from the cache. At any time of such deletion, AR SHOULD try
to keep the total number of addresses in the cache being
CAPACITY_OF_POOL.
Han, et al. Expires December 4, 2003 [Page 7]
Internet-Draft Advance DAD July 2003
4.3 MN Operation for Duplication-free NCoA Configuration
This draft does not minutely specify MN operation for the acquisition
and the configuration of a duplication-free NCoA. Instead of that, it
introduces 'Duplication-free NCoA Request Option' and
'Duplication-free NCoA Reply Option' used for requesting a
duplication-free NCoA from NAR, and delivering a duplication-free
NCoA to MN, respectively. There are already some fast handover
protocols using a set of handover-related messages. For example, [5]
has defined RtSolPr/RtSolPr, FBU/FBACK, HI/HACK, FNA/NAACK messages
for supporting its handover scheme. These messages can be utilized
for including the options defined newly in this draft.
From MN's viewpoint, a handover scheme can be divided into
'predictive' and 'non-predictive'. In the 'predictive' case, MN can
send 'Duplication-free NCoA Request Option' to NAR (via PAR) before
it moves to NAR's link. This option includes current CoA (PCoA in a
viewpoint of NAR), MN's link-layer address, an identifier, and 'B'
flag. 'B' flag is set when MN demands that NAR should buffer packets
tunneled from PAR. If MN can judge that it quickly moves to NAR's
link, it MAY not set 'B' flag.
When MN receives 'Duplication-free NCoA Reply Option' as a reply, it
can resides in PAR's link or NAR's link. If MN resides in NAR's link
at that time, it configures the address stored in the reply option
into its interface immediately after receiving the reply option.
Otherwise, it keeps the address in advance. And, it configures the
address into its interface immediately after it gets connectivity
with NAR's link. If MN sets 'B' flag when it sends 'Duplication-free
NCoA Request Option' to NAR, it MUST notify NAR of its presence with
the duplication-free NCoA set to the notification message's source
address as soon as it configures the address into its interface
(e.g., FNA message used in [5]). If 'B' flag was not set, MN don't
have to notify NAR of its presence.
In the 'non-predictive' case, MN adds 'Duplication-free NCoA Request
Option' to any handover-related message firstly delivered from MN to
NAR after it gets connectivity with NAR's link. In that option sent
in the 'non-predictive' case, 'B' flag MUST NOT be set. As soon as MN
receives 'Duplication-free NCoA Reply Option' as a reply, it
configures the address stored in the reply option into its interface.
4.4 NAR Operation for Duplication-free NCoA Configuration
When NAR acting as Passive Proxy finds 'Duplication-free NCoA Request
Option' in the handover-related message delivered from PAR (in
'predictive' case) or MN (in 'non-predictive' case), it selects an
address from 'Passive Proxy Cache' and deletes it from the cache. NAR
Han, et al. Expires December 4, 2003 [Page 8]
Internet-Draft Advance DAD July 2003
can use a method to select an address from the cache (e.g., using
FIFO). With the selected address, NAR generates 'Duplication-free
NCoA Reply Option'. The reply option's 'Identifier' field MUST be set
to the same value as the one in the request option.
In case NAR receives the request option from PAR (this can be judged
from the kind of message carrying the request option), it sends
'Duplication-free NCoA Reply Option' to PAR and MN at the same time.
The reply option sent to PAR is delivered with one of the
handover-related messages. In the other hand, the reply option sent
to MN is delivered using the host route entry, which can be created
with MN's PCoA and MN's link-layer address. These two addresses is
included in the request option. After the host route entry is used to
send the reply option to MN, it MUST be deleted immediately.
When NAR receives the request option from MN, it also tries to send
the reply option to MN with the help of one of the handover-related
messages. If such a message is not available, NAR MUST create the
host route entry and send the reply option to MN.
After sending 'Duplication-free NCoA Reply Option' to PAR or MN, NAR
checks if 'B' flag is set or not. If 'B' flag is set, NAR performs
the following procedure:
1) create a 'proxy neighbor cache' entry with the selected
duplication-free NCoA and NAR's link-layer address.
2) intercept and buffer the packets tunneled from PAR until
receiving a message notifying MN's presence.
3) change the 'proxy neighbor cache' entry into 'neighbor cache'
entry as soon as receiving the message. If the MN's link-layer
address is not available from any handover-related messages
(including the notification message), NAR gets it from the
request option.
4) set the 'neighbor cache' state to REACHABLE.
5) forward any buffered packets to MN.
If 'B' flag is not set, NAR performs the following procedure:
1) create a 'neighbor cache' entry with the selected
duplication-free NCoA and MN's link-layer address. If the MN's
link-layer address is not available from any handover-related
messages, NAR gets it from the request option.
Han, et al. Expires December 4, 2003 [Page 9]
Internet-Draft Advance DAD July 2003
2) set the 'neighbor cache' state to REACHABLE.
3) forward any buffered packets to MN.
After completely performing the above procedure, NAR SHOULD check if
there are other 'Duplication-free NCoA Request Option's delivered
from MNs. If such request options do not remain any more, NAR SHOULD
try to promptly generate new addresses, run DAD on the addresses, and
reserve them into 'Passive Proxy Cache' so that NAR keeps the total
number of duplication-free NCoAs being CAPACITY_OF_POOL.
Before receiving 'Duplication-free NCoA Reply Option', MN can receive
a normal Router Advertisement (RA) from an AR which does not act as
Passive Proxy. At this case, MN itself creates NCoA, and starts to
run the DAD procedure. If it receives 'Duplication-free NCoA Reply
Option' while the DAD procedure goes on, however, it ignores the DAD
process afterward.
Han, et al. Expires December 4, 2003 [Page 10]
Internet-Draft Advance DAD July 2003
5. New ICMPv6 Options Formats
5.1 Duplication-free NCoA Request Option
'Duplication-free NCoA Request Option' is a new ICMPv6 option sent
from MN to request a duplication-free NCoA from NAR.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ PCoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN's Link-Layer Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA.
Length
size of this option units of 8 octets.
Identifier
An identifier to aid in matching a 'Duplication-free NCoA
Reply Option' to a 'Duplication-free NCoA Request Option'.
'B' flag
This flag is set when MN demands that NAR should buffer
packets tunneled from PAR. If MN sets the flag, it MUST
notify NAR of its presence immediately after it gets
connectivity with NAR's link
Reserved
This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
PCoA
The MN's Care of Address valid on PAR. PCoA is reused
Han, et al. Expires December 4, 2003 [Page 11]
Internet-Draft Advance DAD July 2003
while the MN is attached to NAR until it finishes NCoA
setup.
MN's Link-Layer Address
The variable length link-layer address. The content and
format of this field (including byte and bit ordering)
is expected to be specified in specific documents that
describe how IPv6 operates over different link layers.
5.2 Duplication-free NCoA Reply option
'Duplication-free NCoA Reply Option' is a new ICMPv6 option sent from
NAR to deliver a duplication-free NCoA to MN.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Duplication-free NCoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA.
Length
size of this option units of 8 octets (i.e., 3).
Identifier
MUST be copied from 'Duplication-free NCoA Request Option'.
Reserved
This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Duplication-free NCoA
New Care of Address can be used by MN without the DAD
procedure.
Han, et al. Expires December 4, 2003 [Page 12]
Internet-Draft Advance DAD July 2003
6. Security Considerations
If someone wants to hijack correct 'Duplication-free NCoA Request/
Reply Options', they could send an handover-related message with
incorrect 'Duplication-free NCoA Request Option' to NAR repeatedly,
and NAR would reply to the request message, which is a unsafe
processing. If there is any authentication schemes in the handover
protocol which has defined the handover-related messages carrying the
options, the schemes will correctly authenticates the options, too.
There may be a security issue with the host route entry created by
the NAR upon reception of 'Duplication-free NCoA Request Option'. It
could be used to deny service to a legitimate host which is off-link
(or be a man-in-the-middle), if the host route entry is valid for
more than just sending 'Duplication-free NCoA Reply Option'.
Therefore, AR MUST create the entry only when it processes the
request option and use it for the reply packet, and then delete it
immediately.
Implementations SHOULD apply a rate-limiting method to send the
reqeust/reply options to avoid being used in a Denial-of-Service
attack.
Han, et al. Expires December 4, 2003 [Page 13]
Internet-Draft Advance DAD July 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
2003.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[4] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
Han, et al. Expires December 4, 2003 [Page 14]
Internet-Draft Advance DAD July 2003
Informative References
[5] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mobileip-fast-mipv6-06 (work in progress), March
2003.
Authors' Addresses
Youn-Hee Han
SAMSUNG Advanced Institute of Technology
i-Networking Laboratory
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9233
EMail: yh21.han@samsung.com
URI: http://myhome.personaldb.net/bluebibi
JinHyeock Choi
SAMSUNG Advanced Institute of Technology
i-Networking Laboratory
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9233
EMail: jinchoe@samsung.com
Hee-Jin Jang
SAMSUNG Advanced Institute of Technology
i-Networking Laboratory
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9615
EMail: heejin.jang@samsung.com
Han, et al. Expires December 4, 2003 [Page 15]
Internet-Draft Advance DAD July 2003
Soohong Daniel Park
SAMSUNG Electronics
Mobile Platform Laboratory
314, Maetan3-dong, Paltal-Ku
Suwon-si, Gyeonggi-do 449-743
KOREA
Phone: +82 31 200 3728
EMail: soohong.park@samsung.com
Acknowledgement
Greg Daley and Nick Moore provided valuable feedback and contributed
to this draft. Implementation experience have been provided by Hee-Jin
Jang, Doo-Jin Cha, and Sueng-Ho Lee. Other useful comments were
received from Singh Shubhranshu, Xiaoming Wang and Byoung-Jun Lee.
Han, et al. Expires December 4, 2003 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 06:51:46 |