Subject: [mobile-ip] Announcement of a new DAD optimization draft

From: "Youn-Hee Han" <[email-masked]>
Date: Thu, 5 Jun 2003 08:47:43 +0900

Dear mobile-ip WG members,

We have submitted a new individual draft that describes a possible
DAD optimization scheme for IPv6 MN"s seamless handover.

In the draft, we proposes to automatically allocate a globally unique
CoA for the use of MNs that want to be fast handovered. Each 
AR manages a 'CoA Pool' of which each address is in advance 
generated and tested for its uniqueness by the AR. 

Also, the AR acts as *Passive Proxy*  for the stored addresses 
in order not to affect the destination cache and neighbor cache of 
its neighbor and not to disturb the normal CoA configuration procedure
of the nodes who do not obey this draft. 

As soon as an MN, which obeys this draft, gains connectivity on 
a new link, it inquires one of CoAs stored by its AR. After receiving a reply
with the one, the MN uses it as its new CoA without the normal DAD.

This document has not yet reached the ID WWW site, but is available 
at the following URL:

http://myhome.personaldb.net/bluebibi/adad/draft-han-mobileip-adad-00.txt

We are looking forward to you feedback.

Regards,

Youn-Hee Han.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 5 Jun 2003 08:21:00 -0700

> generated and tested for its uniqueness by the AR.

Just how, precisely, do you intend to assure that the CoA is globally
unique?

            jak

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 06 Jun 2003 07:50:23 +0100

Hello Youn,

We have proposed this as a feature of our Proactive Mobile IP protocol
some two years ago..

http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proactivev6-00.ps
http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proactivev6-00.txt

we even have data to show it works...

BTW, the identifier will be globally unique...but sure as hell not
globally routable; remember you must go by prefix for unicast
routing...unless...unless it is IP multicast during the handoff!
Actually we are not ashamed to say it anymore..since intra-domain it
works quite well during an IP handoff! We are aligning the
inter-domain...and fast :)

people may want to have a look at the spec again..

regs
theo
UCL/Mobile Systems Group

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 06 Jun 2003 08:15:19 +0100

Theo Pagtzis wrote:

>globally routable; 

I did not finish my sentence there what I meant was...a single
preallocated CoA will not be globally routable for all subsequent IP
handoffs. An new one must be obtained at the new point of
attachement..hence the idea of global uniqueness is only good till the
next IP handoff.

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 9 Jun 2003 10:56:59 +0900

> Just how, precisely, do you intend to assure that the CoA is globally

Ok. We admit that the global uniqueness of address have 
not been so much considered while developing our idea.
However, we think that the topic does not go to the heart
of a matter about our draft.

In our draft, AR generates interface identifier using a 
random number generation (e.g., one described in RFC3041). 
And, it makes an address while appending the identifier to
the prefix managed by the AR itself. Also, AR performs DAD
for the address before storing it in the 'CoA pool'.

We think that, in terms of global uniqueness, an address
stored in the 'CoA pool' is in the same position as one
auto-configured by MN itself using method proposed in 
current IPv6 RFCs (or MIPv6 draft). 

If we cannot say that a CoA auto-configured by MN is globally 
unique, it is wrong for me to say that an address in the pool 
is globally unique.

If you think that I am missing some points, please let me know.

Regards,
Youn-Hee Han

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 9 Jun 2003 11:33:15 +0900

> we even have data to show it works...

We already read your draft one year ago, and thought that
it well handled many problems related to seamless handover.
Theo! In our draft, however, we *did not* try to solve 
the all problems handled in your draft.

At San Francisco IETF meeting, non-predictive and modular 
techniques were introduced. Each technique addresses one 
source of delay among movement detection delay, router 
advertisement delay, DAD delay, and BU RTT.
   
Our draft is focused only at the DAD delay, so it seems 
simple and robust. I think this modular approach would
benefit the MIPv6 optimization, directly and indirectly.
IMHO, your draft must be weighed against the existing
well-known fast handover scheme, not against our modular
scheme.

And, your scheme requires a discovery scheme for geographically
adjacent ARs (GAARs). Prospective (or proactive) CoA configuration
and its DAD check are conducted with the help of the auxiliary
messages exchanged with the GAARs. Our scheme requires no GAARs 
discovery scheme and auxiliary messages in order to configure
prospective CoA in advance. The points of our scheme are
*CoA Pool* and *Passive Proxy*.

Please don't say that you already proposed our scheme in your
former draft.

> inter-domain...and fast :)

In our draft, we did not try to solve the packet-loss problems
during handover, either. I know the problems can be solved 
with several techniques, such as multicasting, bicasting, 
packet-forwarding, and so on.

---

From: jaehoon <[email-masked]>
Date: Mon, 09 Jun 2003 12:34:40 +0900

Hi, 
I need to read the draft, but I have one question:
If AR has a 'CoA pool' for mobile IPv6 node, AR MUST process proxy DAD
for unique CoA guarantee.
If AR does proxy DAD for all stored CoAs, it is big burden to the AR.
What is your idea for CoA guarantee in your 'CoA pool'?
Regards

---

From: Theo Pagtzis <[email-masked]>
Date: Mon, 09 Jun 2003 05:32:58 +0100

Hi Youn,

>well-known fast handover scheme, not against our modular
What I was talking about in my draft was the fact that DAD was
statefully resolved since the IP addresses were proactively allocated by
the routers belonging to the same Routing neighbourhood.

If an AR is maintaining a CoA pool this AR _must_ be able to maintain it
for all router neighbours, not just for itself otherwise how is it going
to reduce DAD latency, given the fact that you are moving to your
ignorance to a new point of attachment??? By using the Passive Proxy
idea one simply IMHO reinvents the wheel since the whole point about
proactive allocation of state is the delegation of the task to others
(what I consider as Routing Neighbours) this or other drafts call it 'X'
Proxying...

Anyway I am trying to see where the difference is for that matter. I am
not even considering the idea about GAAR which came after what I spoke
about the mapping of the Mobility Neighbourhood to the Routing
Neighbourhood, which is well explained on both draft and our
publications. That (and I mean the concept - not the format of the
signal which can well be different) was then named GAARs scheme. ;-)

>Please don't say that you already proposed our scheme in your
Apologies if this sounded bad, this is not the intention. All I was
trying to convey is that the idea has been there. But perhaps you would
like to show how _really_ it is different, since I may well be missing
something here.

>packet-forwarding, and so on. 
True for the second part of the statement. AFAIK latency is tackled
primarily to render the IP handoff process seamless. If seamlessness
does not translate to you as packet loss, then may I ask what does it
translate to? What is the point of saving delays from DAD hits if you
don't care about lost packets???

cheers

Theo
UCL/MobiSys Group

---

From: Theo Pagtzis <[email-masked]>
Date: Mon, 09 Jun 2003 05:39:40 +0100

Jaehoon,

This is dead simple and as I said two years ago. One can simply go for 
statefull address allocation of the Routing Neighbour AR give the MAC 
address, let the neighbour do a statefull proactive allocation of the 
tendative IP CoA, by means of doing the DAD check which is simply an 
address resolution-wait a bit-no claim for the allocated address as per 
rfc2461, and come back with a UNIQUE address that has been proactively 
allocated and is ready for use by the MN upon reaching that point of 
attachment.

To me a CoA pool sounds like one AR also has reserves of CoAs for the 
SAME AR neighbour which is a waste of resource mapping to a single. I 
believe the term CoA pool is not accurate.

my two pence
Theo
UCL/MobiSys Group

---

From: Greg Daley <[email-masked]>
Date: Mon, 09 Jun 2003 16:31:07 +1000

Hi Theo,

I think that the issue is not about whether there is stateful
tracking of DAD'ed addresses (which has been proposed before),
but who tracks them, and how they are used and allocated.

I'll detail some of my ideas below.

> signal which can well be different) was then named GAARs scheme. ;-)

I believe that the presence of a pool of addresses is not based
upon request/response from peer neighbors.

There are still several issues to be worked out in configuring
ralationships between routers (although your system proposed a
mechanism previously).  If there is no need to establish relationships
with peers, a significant complexity is removed from the stateful
DAD scheme.

I think that the elegance of aDAD is that the only state which
is kept is an address. This is kept for no MN or neighbor in
particular, but is given out to a device which can prove that it
is ready to use it: it is already on link.

There doesn't need to be any pre-establishment of security
association or relationships, no delegation of authority.
The Router is looking after a pool of addresses available
on its own link.

> like to show how _really_ it is different, since I may well be missing

I agree that there is a relationship with your proposal
(both are stateful address allocation schemes).

The aDAD system is very simple, and different in that
there's no signalling until the node arrives, no prediction
or locality knowledge required and no overhead caused by
nodes which do not arrive on the network.

Obviously a stateful address allocation scheme will
have to keep state (my own kludge idea MLD-DAD does the same),
but this is not essentially reinventing the wheel, it's
a quest to find out if stateful DAD optimization schemes are
deployable  with the same utility a stateless/optimistic ones.
There are significant differences in the management of
simple requests on link, and neighboring router communications
though (maybe this is done at the cost of coupling to a context
transfer, but these are tradeoffs).

> don't care about lost packets???

I think that there is a small trend toward breaking the movement
process down into several movement optimizations which can be
applied piecemeal to the handover process.  In this case, reducing
overall handover latency helps to minimise packet loss.
Whether the handover is seamless or not depends on the definition of
seamless... :)

Address configuration (or preconfig) is only one mechanism which
is aimed at reducing latency.  If handover prediction is available,
this may be used to buffer or tunnel packets to a new location.
Advance DAD is relatively orthogonal to this though.

Greg

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 9 Jun 2003 16:29:16 +0900

> What is your idea for CoA guarantee in your 'CoA pool'?

The AR does not proxy but *passively proxy* for 
all addresses stored in the pool. So, it does not 
advertise them at its link, and does not reply to 
a neighbor solicitation with an address stored 
in its CoA pool as value of the target field. This 
behavior is different with home agent's behavior.

Thanks,
Youn-Hee Han

---

From: "James Kempf" <[email-masked]>
Date: Mon, 9 Jun 2003 08:53:13 -0700

So how is this different from having a DHCP server that is preloaded
with CoAs that have been generated using such an algorithm?

            jak

----- Original Message -----
From: "Youn-Hee Han" <[email-masked]>
To: "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Sunday, June 08, 2003 6:56 PM
Subject: Re: [mobile-ip] Announcement of a new DAD optimization draft

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 10 Jun 2003 10:23:42 +0900

> with CoAs that have been generated using such an algorithm?

One of some reasons to conceive 'Pool of DAD-free CoAs' is come 
from the following words in Page 2 of RFC 2462.

   "The Duplicate Address Detection algorithm is performed 
    on all addresses, independent of whether they are obtained
    via stateless or stateful autoconfiguration."

Although an MN requires its CoA from a DHCP server, it runs DAD 
for the address, thereby causing 1000ms latency in L3 handover.

AFAIK, DHCP server doesn't defend the addresses allocated 
to the sever. In my draft, however, the AR acts as a passive
proxy for the addresses stored in the pool. After obtaining 
one of them from the AR, therefore, an MN can immediately 
assign it to its interface without running DAD.

Youn-Hee.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 09 Jun 2003 19:08:05 -0700

Hello Youn-Hee,

What if some other network node on the same link autoconfigured
the address that the DHCP server wanted to allocate?

Regards,
Charlie P.

Youn-Hee Han wrote:

>>>>>In the draft, we proposes to automatically allocate a globally
>>>>>          
>>>>>
>>>>unique
>>>>        
>>>>
>>>>Just how, precisely, do you intend to assure that the CoA is
>>>>        
>>>>
>>globally
>>    
>>
>>>>unique?
>>>>
>>>>        
>>>>

---

From: Greg Daley <[email-masked]>
Date: Tue, 10 Jun 2003 12:39:45 +1000

Hi James and Youn-Hee:

> assign it to its interface without running DAD.

I think James' question is a good one, in that an appropriately
configured DHCP server could undertake the same task, but
typically they don't now because of the clause Youn-Hee mentioned.

I think that the DHCP server could indicate that the
address is previously DAD'ed upon reception of a request
for a temporary address (IA_TA).
Of course this would only be used could be used by nodes
which understand this message.  Other nodes would proceed to
DAD the address, which wouldn't hurt too much.

I think that the strongest part of aDAD is the availability
and management of the address pool, rather than the signalling
used to assign addresses.

Greg

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 10 Jun 2003 15:38:37 +0900

> the address that the DHCP server wanted to allocate?

That's an Interesting situation... IMO, I think that the node 
can use the address, which the DHCP server is keeping, 
with auto-configuration method.

I think that it's better that DHCP server can block up such 
unjustified use of the addresses kept by DHCP server. 

Regards,
Youn-Hee.