Subject: [mobile-ip] I-D ACTION:draft-hoon-mobileip-undad-00.txt

From: [email-masked]
Date: Mon, 20 Oct 2003 15:44:53 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Using Neighbor Caceh Entry for Duplicate Address 
			  Detection
	Author(s)	: J. Kim, et. al.
	Filename	: draft-hoon-mobileip-undad-00.txt
	Pages		: 14
	Date		: 2003-10-20
	
The Duplicate Address Detection (DAD) procedure detailed by Neighbor
Discovery Protocol (NDP) requires nodes to wait for a quantified time
interval during which the configured address is checked for
duplication in the connected link. This delay affects normal
communication in a Mobile Node (MN) during the DAD time interval
thereby hampering Fast Handoff. The expected use of Mobile IP on a
wide scale and the need for a minimal time delay during the handoff
process require alternate mechanisms for overcoming the DAD time
interval. This draft presents a mechanism wherein the Access Router's
(AR) Neighbor Cache Entry (NCE) is used to minimize the delay
associated with the DAD procedure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoon-mobileip-undad-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hoon-mobileip-undad-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hoon-mobileip-undad-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Greg Daley <[email-masked]>
Date: Tue, 21 Oct 2003 09:45:14 +1000

Hi Jae-Hoon and Youn-Hee,

The draft has Youn-Hee's email addres under
Jae-Hoon's name, so I thought I'd respond
to Youn-Hee anyway, and hope the message
is passed on.

The idea of using Neighbor Discovery for DAD
is a good one, if it can be made to work.
Alper Yegin tried very hard to do this a while
ago (I talked to him about it before IETF55),
and there's one fatal flaw which cannot be
recovered using ND.

While the router knows about all of the hosts on the
link, it can indicate whether an address is unused.
This is the same principle used for MLD-DAD
(which has since expired... if you need the reference
contact me).

The issue is when a router fails or comes up on a link
for the first time, it cannot build a list of which hosts
are already on the link.
There is no ND message where all hosts (or even large
groups of hosts) must respond, which can be used to rebuild
ND state.

This means that the router may incorrectly allocate existing
addresses if there is a host that doesn't receive off-link
unicast packets at an address.

In MLD-DAD, state can be rebuilt using query messages, which
have no equivalent in ND.

If you wish to discuss this further, please
feel free to discuss this either here or on the DNA
list.

Greg Daley

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 20 Oct 2003 17:11:55 -0700

> groups of hosts) must respond, which can be used to rebuild

What about having the router ping ff02::1 (the link-local scope all
nodes multicast address) from its link-local scope unicast address? That
should cause each host on the link to send a NS to the router's
link-local scope unicast address to resolve its MAC address, so that
they can respond to the ping.

- Ed

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003

---

From: Greg Daley <[email-masked]>
Date: Tue, 21 Oct 2003 11:03:42 +1000

Hi Ed,

Thanks for the question,

> they can respond to the ping.

While it may be possible for the router to send
ICMP Echo Requests to hosts, some of the hosts
may not respond, due to firewalling for example.

The system described in the document needs to be able
to guarantee that it knows that an address is not in use
before it gives it away.

This means that the mechanism has to be tied to a
system required for all hosts to do (for example,
because they have an interest in doing it),
where responses are guaranteed even from hosts that
do not want to participate in the optimization.

ND is one of these systems, but doesn't work when
there's no initial state.
MLD is one of these systems, but is not yet fully
deployed (but that's getting better).

For either of these mechanisms to work, _every_ host
has to provide state information.

If the address isn't guaranteed unique,
then we may as well use Optimistic DAD :)

Greg

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 21 Oct 2003 09:00:13 -0700

Jae-Hoon and Youn-Hee,

I think there is another problem with this draft... the router doesn't
know when a host leaves the link (i.e. due to link movement), therefore
if the MN leaves link A to move to a new link B and then in some short
time (i.e. 20 seconds or so) returns back to link A, the router will
think that the MN never left link A, when the MN queries the router if
its care-of address is already in use the router will respond that it
is. This would cause the MN to fail to configure the care-of address it
used before on link A.

Thanks.
- Ed

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Greg Daley
> Sent: Monday, October 20, 2003 4:45 PM
> Cc: [email-masked]; 'Youn-Hee Han'
> Subject: Re: [mobile-ip] I-D ACTION:draft-hoon-mobileip-undad-00.txt
> 
> 
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username "anonymous" and a password of your e-mail address. After 
> > logging in, type "cd internet-drafts" and then
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> Incoming mail is certified Virus Free.

---

---

From: "jaehoon.kim" <[email-masked]>
Date: Wed, 22 Oct 2003 11:42:56 +0900

> is. This would cause the MN to fail to configure the care-of address it
Thank for your good comment.

In this case, router have a NCE for CoA. So, router never reply to MN.
Refer to my draft.

   3.2 AR's requirement
   -  Access router should reply to the sender which has sent NS message
      with the 'A' bit set in the 4th reserved field in NA if access
      router has no entry corresponding to the target address.
      =====================================
   4.1 Mobile node's operation

---

From: Greg Daley <[email-masked]>
Date: Wed, 22 Oct 2003 14:49:16 +1000

Hi Jaehoon and Ed,

>       router has no entry corresponding to the target address.

The time which was mentioned by Ed may be the relevant
criteria (30 seconds is still within normal
ND cache timeouts).

If the router had an active neighbor cache entry
for the host (perhaps because of NUD or Higher
layer confirmation - it was sending packets to
the MN), then the cache entry would indeed be valid.

Leaving ND cache entries in the router for an arbitrary
period of time is problematic though.  For example,
I get off the same bus each morning to arrive at the
same desk, possibly using a different path on the way.

Assuming that address state still exists in the router
when I return, my Tuesday and Wednesday networking
experience is likely to be worse than my Monday one.
Even returning from getting a coffee may be frustrating.

If the NC entries aren't long term I can currently
see two solutions to keeping them in the cache
(and keeping state valid):

* Make address lifetimes sufficiently short that the addresses
   have a short lifetime, and must be reconfigured.

* Actively poll devices using NUD even if they are not
   receiving packets (maybe at longer than normal intervals).

The second solution may have significant battery life issues
in wireless computing environments (as MLD group membership
does anyway).

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Oct 2003 11:59:18 +0200 (CEST)

>       router has no entry corresponding to the target address.

So the effect is that the first time a node appears on the link
the AR helps it to provide faster DAD, but when it returns
after having visited some other link (or "returns" after being out of
reach) it will need to wait for the 1 second DAD delay?

And since NCE entries don't have any explicit timeout (per RFC 2461
they are only removed if the node runs low on memory or if NUD fails
when trying to communicate with the neighbor) the NCE might be there
when the node returns after being gone for a day or longer.

Note that with this proposed modification to DAD behavior the AR can never
garbage collect the NCE entries since that might cause it
to send a "no duplicates" response when there might be a duplicate.
So how could the NCE entries ever be safely removed from the AR?

  Erik

---

From: Praveen Rajendran <[email-masked]>
Date: Wed, 22 Oct 2003 21:02:25 +0530

Hi

Thanks for your valuable feedback. At the onset let me clarify that the
intention behind releasing this draft was to propose the usage of the
Neighbour Cache (NC)for DAD related purposes. We believe that this approach
of maintaining the entire list of nodes in the link can help optimize DAD as
well as provide for future administrative and statistical purposes. I do
agree that the finer aspects of the proposal require much more work and I
hope that this working group will help us resolve some of the issues.

I hope to present some of my viewpoints below and I apologize if clubbing
them together has caused any inconvenience.

Ed had pointed out that the draft does not discuss any deregistration
mechanism for the Neighbour Cache Entry (NCE). There are different ways of
solving this issue I think.
- In cases where L2 triggers are available NUD can be performed to determine
if the NCE has to be removed on receiving a L2 trigger.This would however
require some form of mapping between the NCE and the L2 module.
- In cases where RA beaconing is used a periodic delay in RA message
transmission ( like 1 in 10 RAs sent can be delayed )can be used to receive
RS messages from the mobile nodes still connected to the link. NUD can be
performed for mobile nodes with a NCE in the access router and which do not
send RS messages. Partitioning the NC into static entries ( for non mobile
nodes ) and mobile entries would help minimize the overhead with NUD being
performed only on the mobile entries.
- Another option would be to inform the previous access router of its change
in attachment after the completion of the Binding process in order to remove
the NCE.

Greg  had pointed out problems with populating the NCE in cases where the
router boots after some of the nodes or when the router goes down and comes
up. Ed had suggested using a multicast ping for the purpose ... some
topological features can hamper its efficacy .. but the same can equally
apply to the normal DAD process. As RFC 2462 claims "Note that the method
for detecting duplicates is not completely reliable, and it is possible that
duplicate addresses will still exist." and the Optimistic DAD draft
reinforces in section 4.4 - the DAD procedure only provides a very good and
not a complete assurance that duplicates are absent.
In my opinion using the Ping process would not lead to a unacceptable risk
causing the DAD procedure to fail.

Another solution can be the partitioning of the NCE  into static entries and
mobile entries as I had stated earlier and having the static entries
administratively configured. That would overcome the problems when the
router boots up after some of the static nodes boot. Mobile nodes perform
DAD after the receipt of RA messages only and the router can handle those
cases. That would still leave the case where the router goes down and comes
up .... carrying forward the state information cannot be enforced in such
cases ... perhaps reconfiguring the addresses in the mobile nodes can be
used in such cases?

Eric and Greg had pointed out that when a node oscillates between networks
it will have to wait the mandatory 1000 ms before it can resume normal
communication and the draft does not offer any solution to it. In cases
where a L2 trigger is available to deregister the NCE this should not pose
any problems I think. Also in cases where a mechanism of informing the
previous router of its change in attachment is used the problem would not
exist. However when some periodic mechanism is used it can be problematic
when the oscillating time is less than deregistration time interval.

I hope the next version of the draft would discuss these issues in more
detail and I hope to hear from you about the viewpoints expressed above.

thanks and regards
Praveen

Optimistic DAD in section 4.4
----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "jaehoon.kim" <[email-masked]>
Cc: "Ed Remmell" <[email-masked]>; <[email-masked]>;
"'Youn-Hee Han'" <[email-masked]>
Sent: Wednesday, October 22, 2003 10:19 AM
Subject: Re: [mobile-ip] I-D ACTION:draft-hoon-mobileip-undad-00.txt

---

From: Greg Daley <[email-masked]>
Date: Thu, 23 Oct 2003 10:19:29 +1000

Hi Praveen,

You may have misunderstood what I meant.
I will discuss this below.

> causing the DAD procedure to fail.

It is true that DAD itself is not currently completely
reliable. This is based on the issue of packet loss on
DAD attempts or defense.

One obvious way to improve this issue is to do more
DAD NS attempts in order to improve the chance of
detection.  This would mean that the tentative time
would in effect, be longer.

If we have to check anyway, because we have got an
unreliable DAD indication, then it's fairly important
to ensure that this check doesn't interfere with
packet reception, or harm others in the collision case.

This is what optimistic DAD does.   If we need to do
a DAD, then why go to extra effort in maintaining state
unless it contains authoritative information?

Conversely, if we can't build state for the network,
and then we shouldn't give away an address in a way which
considered 'authoritative'.  By this I mean one that
doesn't need to be DAD'ed by hosts.

The key to authoritative statements about the
availability of arbitrary addresses is that
state building has to be based on requirements
for existing IPv6 hosts.
These hosts may also be on the network with the
fast-DAD node and stateful router and must be made to
volunteer state if an authoritative DAD replacement
is to be provided.

The ping ff02::1 won't work.
Existing hosts don't have to respond to the message.

So we have three approaches to DAD optimization:

* (Authoritative) Network Stateful DAD.
   These systems contain sufficient information
   to allocate an arbitrary address on the
   network to a reuqesting host.

* Address Set Stateful DAD.
   Maintains state about a router defined set
   of addresses which are guaranteed to be
   collision free. (this is Advance-DAD)

* Stateless DAD.
   Achieves DAD by direct query of potentially
   conflicting hosts.  This can be
   heuristically determined if no responses
   are received to a DAD request.  In the
   probing interval, a configuring host must not
   cause harm to neighbors which cannot be repaired
   by DAD defense in the collision case.

Non Authoritative responses will have to fall back
to a stateless mechanism, to guarantee safety.

> cases ... perhaps reconfiguring the addresses in the mobile nodes can be

Indeed, sending a new prefix (one with a short lifetime)
would work (but not for link-local).

Partitioning the NCE doesn't help though, because
keeping manual state about hosts on a network
is prohibitive.  You'd need to have complete state
about addresses used on the link.  Even DHCP doesn't
have this (DHCP addresses need to be DAD'ed).

If you didn't have that state (for example because
the router went down and there were still mobile devices
connected at L2) then it would lead to the same issue as
before: lack of authority in the address allocation.

Greg

---

From: Ron Lee <[email-masked]>
Date: Thu, 23 Oct 2003 10:06:29 +0900

Sorry for posting a basic question.
I know that in the RFC 3344 (IP Mobility Support for IPv4) there is no
consideration of route optimization, which was once an I-D in this WG.
Is it forgotten now, or is someone undergoing an effort to improve it?
Thanks in advance.

Ron

---

From: "Youn-Hee Han" <[email-masked]>
Date: Thu, 23 Oct 2003 14:36:29 +0900

Hi all,

This draft's idea is one of 'stateful DAD optimization'.
'Stateful DAD optimization' has been defined in the 
'IPv6 DAD Optimization Goals and Requirements' draft.
http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requirement-01.txt.

Basically, I believe that the use of NCE locking
can be a good research item for the stateful DAD optimization.
, along with 'Advance DAD'.

In fact, this NCE locking idea was originally shown up at 
the old draft 'Improving the architectural alignment for FMIPv6'
, which was written by James Kempf.

However, at the current state, I generally agree with Eric and Greg's opinions.

> require some form of mapping between the NCE and the L2 module.

Firstly, what L2 trigger can help the deregistration?
So the NCE management seems to be complicated and be a scheme 
depending on the L2 technology.
I think that many people maybe feel uneasy about the combination
IPv6 core protocol and L2 module.

> performed only on the mobile entries.

Although RA beaconing is used, we cannot assure that *ALL* nodes 
in the network will sends RS message in case the delay of RA.
And... how to decide that a node is static or mobile? It will be very 
questionable in the future.

> in attachment after the completion of the Binding process in order to remove

I rather like it than the aboves. In fact, 802.11 IAPP requires 
this kind of thing. And, in the basic MIPv6 spec, the behavior 
of notifying the PAR of its movement is also mentioned. 
If this behavior prevails in the upcoming deployment, the method
will help the deregistration of NCE.

> causing the DAD procedure to fail.

The original RFC 2462 DAD is very strong and reliable.
Just packet losses cause it to be unreliable. But, the all protocols
are affected by the packet losses.

I think that 'Advance DAD (aDAD)' can escape these problems
(of course, except the packet losses). In aDAD, the address pool
has some duplication-free addresses and uses 'Passive-proxy function'
in order to keep them unique. This scheme does not require
any deregistration and relinquishment processes about the reserved 
addresses.

Anyway, the more research seems to be required for the DAD optimization.
But, the study of this issue was already started in the DNA BoF.

- Youn-Hee Han

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 23 Oct 2003 14:51:08 +0200

Hello Ron,

	Route optimization is not on the charter for the Mobile IP v4
working group (mip4).  To my knowledge, it is not being worked on
outside the working group, either.

If you want to follow mip4 issues, you should participate on the mip4
mailing list (You can subscribe here: https://www.ietf.org/mailman/listinfo/mip4).

This list ([email-masked]) will be shut down soon.

	Henrik

---

From: "jaehoon.kim" <[email-masked]>
Date: Fri, 24 Oct 2003 09:54:33 +0900

Hi, Greg

Thanks a lot for your interest in our draft.

I have a question about following sentence.
> Existing hosts don't have to respond to the message.

FF02::1 is already reserved in RFC.
And futhermore, I could not find that some host may not respond to ff02::1
in any RFC due to firewall.
Let me know reliable reference.
I usally used ff02::1 or ff02::2 in our lab and ETSI test event.
I just have been confused in what you mentioned.

Thanks
Jaehoon Kim.

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 24 Oct 2003 10:37:26 +0900

> I just have been confused in what you mentioned.

Such ping request/response can be blocked 
not based on address filtering but service filtering.

- Youn-Hee

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 24 Oct 2003 12:57:01 +1000

> But, the study of this issue was already started in the DNA BoF.

I tend to feel that it's pretty well covered by the 
Optimistic DAD draft (now up to -03, still only 13 pages!) ...
if stateless DAD is sufficient, why worry about stateful DAD?

Of course I'm a little biased, as author, but on the other hand
Opti-DAD has evolved through a couple of rounds of debate 
on mobileip and ipv6 mailing lists, and has a couple of 
independant working implementations.  I'd like to see Opti-DAD
adopted as a DNA WG draft, so we can develop an issues list
and put it up for standardization ASAP.

I feel that this is a matter for Engineering, not Research.

-----Nick
<http://ietf.org/internet-drafts/draft-moore-ipv6-optimistic-dad-03.txt>

---

From: Greg Daley <[email-masked]>
Date: Fri, 24 Oct 2003 12:16:39 +1000

Hi Jaehoon,

> FF02::1 is already reserved in RFC.

Yes.

> Let me know reliable reference.

Page 13, RFC-2463. Third paragraph.

"...An Echo Reply SHOULD be sent in response to an
   Echo Request message sent to an IPv6 multicast address."

SHOULD is not mandatory like MUST (as per RFC 2119).
It is approximately equal to RECOMMENDED.

Firewalling is just one reason not to send the response.

If the response was mandatory, firewalling (for example)
would not be applicable, and the response would always be
received.

I haven't seen any system which requires responses from
all hosts (or all groups of hosts) on a link except for
MLD Queries.

> I just have been confused in what you mentioned.

The issue is that if a node refuses to respond to
ICMP echo requests, then it will not be in your
list of hosts if you have not received unicast packets
from it recently.

This means you may allocate the address to another, not
knowing that it is already is present on the link.
I think that's what DAD was trying to avoid.

The way your system works now, the router may
incorrectly allocate an address to a new device
(because its state was incomplete). The router
may respond first (This is likely to because the router
response is configured for speed and the host which
owns the address may be powersaving).

In this case, both devices have the address configured
as non-tentative when the DAD defense comes (up to a
second later).

The alternative of keeping the addresses on the configuring
host tentative is already defined in
draft-moore-ipv6-optimistic-dad-03.txt.
This requires no state server.

I'll try to get a draft of MLD-DAD back onto the server
for comparison, so that I can illustrate some of the
issues in state maintenance.

Greg