Subject: RE: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: FBU tr ansmission text)

From: Soliman Hesham <[email-masked]>
Date: Thu, 19 Jun 2003 23:37:10 -0400

> 
 > Come on now, you're undermining our world view here :)

=> Sorry ;)

 > 
 > > - On an unreliable link layer (no L2 retransmissions), 
 > >   it is much more likely that the DAD messages will get
 > >   lost than address duplication taking place. 
 > 
 > I think that if we're talking about optimistic DAD,
 > there may not be any major harm in extending the
 > tentative time to incorporate more retransmssions
 > (obviously, we wouldn't like to hammer the link though).
 > 
 > Maybe you've just described a valid reason for stateful
 > DAD/address allocation systems?

=> No, it's a valid reason to use our Engineering skills
to design a solution that will solve 99.999% of the problem
and making solving the 0.0001% optional. 

Stateful can always be used at the price of additional
delay and more inter-AR signalling. 

Hesham

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 20 Jun 2003 13:10:00 +0900

Hello folks, 

I have some opinion (in fact, my proposal) about the current discussion
(FMIPv6: FBU transmission text). Frankly speaking, I would like to 
express that our new draft ('advance DAD') can make FMIPv6 simple 
and robust. 

With new text in this discussion, next version of FMIPv6
seems to be longer and more complicated than the previous one. 
What I would like to stress is that the NCoA confirmation itself makes 
FMIPv6 complicated. If the NCoA is not guaranteed to be unique, 
the corresponding and complementary measures must be required 
(regardless of the likelihood of collision). The most parts of new text
handle the measure and, for the measure, the additional 'M' message
 is newly introduced. I don't know why people have been generous to 
introduce the new ICMPv6 message *only in FMIPv6*.

IMO, NCoA doen't need to be configured from MN's link-layer address,
because it is tentative address valid only during MN resides at a foreign link.
And, I feel uneasy from the fact that the NCoA configuration is done 
*expeditiously* using MN's link-layer address during L3 handover. 

If NAR can have a pool of duplication-free global addresses (NAR's prefix
 + randomly generated IID) and it can deliver one of the addresses to MN 
just before moving to NAR's link, the current FMIPv6 can be very short and
clear. In even non-predicted case, the address can be also delivered to MN 
through new option, which can be carried by RS/RA message, as soon as it 
connects to new link

Another benefit of dup-free address pool management and allocation scheme is 
to make the tunnel renewing protocol needless. In current version of FMIPv6, 
it should be supported in preparation for late NCoA configuration. Such support
is a bothersome task on designing overall protocol, but it is indispensable.

I would like to know people's opinion about this proposal. Some people may 
say that the dup-free address pool management can be burden on router, particular 
since the likelihood of collision is very low. I already wrote justification for it in our
draft (http://www.ietf.org/internet-drafts/draft-han-mobileip-adad-00.txt).

Regards,

Youn-Hee Han

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 20 Jun 2003 13:34:14 +0900

> delay and more inter-AR signalling. 

I think that stateful can be implemented without additional 
delay and inter-AR signalling, if it is valid that NCoA's IID
is created randomly.

Youn-Hee Han

---

From: "Seok Joo Koh" <[email-masked]>
Date: Fri, 20 Jun 2003 13:44:25 +0900

I would like to definitely agree with the opinion below.

In fact, I think the handover scheme could not be *Fast* any more,
without the help of DAD optimization such as optiDAD or advance DAD whatever.

My suggestion is that the FMIPv6 is designed by considering such requirement.
At least, FMIPv6 needs to subsume the stateful NCoA configuration scheme (or oDAD, aDAD)
as well as the stateless configuration scheme.

Yours faithfully,

Seok J. Koh

---

From: Greg Daley <[email-masked]>
Date: Fri, 20 Jun 2003 15:25:31 +1000

Hello Seok,

> without the help of DAD optimization such as optiDAD or advance DAD whatever.

The existence of bidirectional edge tunneling makes
this FMIPv6 able to be used quickly even with
significant configuration delays for DAD or Return
Routability.

This has been shown to be effective (though I
have previously thought it was complicated).

> as well as the stateless configuration scheme.

I think subsume (incoprporate into oneself)
is too strong a word.  This just makes
FMIPv6 more complicated (something which
doesn't need to be done).

Certainly allowing FMIPv6 to work in conjunction
with these technologies is worthwhile, though.

Greg

---

From: "Seok Joo Koh" <[email-masked]>
Date: Fri, 20 Jun 2003 15:28:17 +0900

Hi Greg,

> have previously thought it was complicated).

Agreed in part, but,
more messages and procedural steps may possibly induce a longer delay for handover,
and hence the AR's overhead for buffering and for tunnel maintenance could get larger as much ??

Instead, IMO the stateful or managed scheme for CoAs is helpful
to remove some of the normal HO steps (or messages such as HI and HACK), doesn't it ?

> doesn't need to be done).

I guess, the incorporation of a stateful scheme in FMIPv6 could simply be handled
by introducing a flag option that indicate "the statefull address configuration is supported or
not", and
by describing which procedures could be omitted in this case.

A complicate specification would still be okay, if it could be helpful for making the protocol
operations simpler.
The problem is in the complicate behaviors, which tends to make the protocol vulnerable to an
abnormal error.

> with these technologies is worthwhile, though.

It would be nice only to allow for using a stateful scheme optionally in FMIPv6.
The detailed implementation or choice of such scheme may be up to the operators.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Jun 2003 08:24:23 -0700

So, repeating my question to you from a previous thread, how is having the
router manage a pool of nonduplicted addresses any different from having a
DHCP server manage a pool of nonduplicated addresses?

Note: suppose the text in 2462 that says DHCP addresses must be DADed can be
waived for FMIP if we want.

            jak

----- Original Message ----- 
From: "Youn-Hee Han" <[email-masked]>
To: <[email-masked]>
Cc: "'Rajeev Koodli'" <[email-masked]>; "Soliman Hesham"
<[email-masked]>; "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Thursday, June 19, 2003 9:10 PM
Subject: Re: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: FBU
transmission text)

> draft
(http://www.ietf.org/internet-drafts/draft-han-mobileip-adad-00.txt).

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Jun 2003 09:49:26 -0700

> with these technologies is worthwhile, though.

This should be emphasized here. FMIPv6 is not
trying to incorporate all the alternatives to improving
DAD.

Please move stateful versus stateless DAD discussion
to another place and time. It is interesting, but not
the focus here.

The text I sent is a summary of FMIPv6 as it has
progressed over the last three years. It is not
proposing anything new per se, except for allowing
carrying FBU within 'M'. It is trying to
clarify the protocol operation.
So, before commenting that protocol is _more_
complicated now, I suggest you please read the text
and the draft again.

Thanks,

-Rajeev

---

From: "Youn-Hee Han" <[email-masked]>
Date: Sat, 21 Jun 2003 02:10:12 +0900

> waived for FMIP if we want.

Current DHCP server manages a pool of addresses which is *neither DADed 
nor depended*, doesn't it? So, I introduced a small version of stateful server
(which is implemented within an access router) managing a pool of addresses 
which is *both DADed and depended*. Such server can be implemented 
easily and the depense technology is simple.

If DHCP addresses can be used without DAD, as mentioned by your note,
that is also optimistic approach. I do not deny the value of optiDAD. It has
many merits. However, I feel uneasy if a seamless handover protocol 
(e.g., FMIP) becomes complicated in order to take complementary 
measures in case address collision occurs. Although we let FMIP use 
DHCP addresses without normal DAD, putting the additional measures into 
FMIP cannot be avoid. 

Youn-Hee Han

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Jun 2003 10:27:10 -0700

Youn-Hee Han,

some comments below regarding your response
to FMIPv6 text.

> seems to be longer and more complicated than the previous one.

I strongly disagree. The proposed text by no means should be
seen as "additional" text that gets appended and hence the draft
looks longer! If anything, it is a protocol summary.

> FMIPv6 complicated. If the NCoA is not guaranteed to be unique,

The "address confirmation" is trivial. As the text says, if the NAR finds
an existing ND cache entry, don't over-write it. This almost sounds like
implementation issue.

> (regardless of the likelihood of collision). The most parts of new text

What are these ? Dropping FBU is matter of memory freeing.

> introduce the new ICMPv6 message *only in FMIPv6*.

Please note that 'M' is not a new message. At the end of the text I sent,
'M' is stated to be a reformatted version of FNA. It would be helpful to
have a look at the text and the draft again!

> *expeditiously* using MN's link-layer address during L3 handover.

Could you clarify this ?

Thanks,

-Rajeev

---

From: "Youn-Hee Han" <[email-masked]>
Date: Sat, 21 Jun 2003 05:39:53 +0900

Rajeev,

In fact, from two years ago, I have been deeply impressed with
your efforts to make your seamless handover protocol completely.
Please don't think that I am trying to disturb your good working.
I have already investigated your draft repeatedly. Also, I made
a nice (colorful and minute) presentation material with animation effect, 
and explained the protocol to our colleague in our seminar serveral times. 
I can send the material to you right now :-)

What I would like to express is just to suggest my opinion. I will not 
interfere if you don't think it is not helpful. However, I believe that 
many proposals from new and different viewpoints can make the 
protocol more robust in the end.

Some answers are below regarding your response.

> looks longer! If anything, it is a protocol summary.

Ok. I accept the proposed text is a summary including a little updated 
behavior and message. However, it is obvious fact that FMIP has an 
experience of many changes and updates done from the first version.

> an existing ND cache entry, don't over-write it. This almost sounds like

Although "address confirmation" itself is trivial, its effect on handover latency 
is significant if non-anticipated mode is performed. If MN can get a duplication-free 
address from its access router by RS/RA exchange (through new options included 
in RS/RA), it can setup the tunnel between PAR and NAR in the fastest time without 
any concern about address conflict. How to get such a duplication-free address? 
aDAD proposes a method for it.

> What are these ? Dropping FBU is matter of memory freeing.

The measures include the scan of ND cache, same address' existence check,
and dropping FBU (also include packet buffering when DHCP address is used). 
Also, although its possibility is low, there is the penalty if NAR incorrectly
creates an entry. It is obvious that the scan of ND cache improves the chances
of expeditiously detecting duplicates. However, if so many MNs connect to the AR
at the same time, the above behaviours seem to be burden on the AR and 
time (or memory)-consuming process. Say again, if MN can get a duplication-free 
address from a new option included in RA, the above behaviours are needless.

> have a look at the text and the draft again!

Sorry for my fault. I misunderstood the 'M' message.

> > *expeditiously* using MN's link-layer address during L3 handover.

What I mean is that.... how about splitting NCoA confirmation process 
from L3 handover process? If that is possible and one of the confirmed addresses 
can be delivered to MN as soon as possible (in the previous link if anticipation is 
supported, otherwise when it receives new RA from NAR), FMIP can be simple
and robust.

Thanks

Youn-Hee Han.

ps. Please don't think I am just trying to introduce my new DAD optimization scheme.
      I am one of impassioned people hoping make their cellular phone equipped with 
      robust seamless L3 handover technology :-).

---

From: "Youn-Hee Han" <[email-masked]>
Date: Sat, 21 Jun 2003 05:52:18 +0900

Oops.. I miswrote a word. Please read the followings while replacing 
'depended' with 'defended'. Sorry for my carelessness.

Youn-Hee Han.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Jun 2003 14:51:07 -0700

The DHCP server can also DAD the addresses itself, if it is on link.

My point is that there is no reason to introduce yet another address
configuration mechanism when DHCP will provide the same kind of stateful
address configuration as your proposal.

            jak

----- Original Message ----- 
From: "Youn-Hee Han" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 20, 2003 1:52 PM
Subject: Re: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: FBU
transmission text)

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Jun 2003 14:45:57 -0700

> your efforts to make your seamless handover protocol completely.

Correction: the protocol is the WG's protocol, not Rajeev's. Rajeev is the
document editor.

            jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 23 Jun 2003 09:57:25 +1000

G'Day Rajeev,

> to another place and time. It is interesting, but not

I think that there are questions being asked mainly
because people have strong hopes pinned on FMIPv6.
You are right though, the discussion is not critical
for the publication of FMIPv6.

> complicated now, I suggest you please read the text

I said I thought that the draft was previously
complex, not that the draft is more complicated
now.  Your descriptions of the changes
seem to indicate that the reverse is true.

Discussing DAD optimizations (like optiDAD/aDAD)
in FMIPv6 is unlikely to make the draft
shorter or simpler IMHO.

You have caught me though.  One of my TO DO's
of the last couple of months has been re-reading
FMIPv6.

I'm (fairly) sure I will have done this before IETF.

Greg

---

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

As Greg said, I begin think that discussion about a separate 
DAD optimization doesn't help the publication of FMIPv6.
But, I don't agree with James Kempf's opinion. So, please 
give me a chance to answer it.

> address configuration as your proposal.

I don't think so. Please refer the following text in 'draft-ietf-dhc-dhcpv6-28.txt'

   18.1.7. Creation and Transmission of Decline Messages
       If a client detects that one or more addresses assigned to it by a
       server are already in use by another node, the client sends a Decline
       message to the server to inform it that the address is suspect.....

   18.1.8. Receipt of Reply Messages
       ...
       The client SHOULD perform duplicate address detection [21] on each
       of the addresses in any IAs it receives in the Reply message before
       using that address for traffic.  If any of the addresses are found
       to be in use on the link, the client sends a Decline message to the
       server as described in section 18.1.7.
       ...

Although DHCP server can DAD the address itself
when it is trying to keep it, it will not defend it afterwards. 
Actually, IMO, the probability of address conflict becomes
higher when a node tries to configure a DHCP address into
its interface than when it tries to auto-configure it. 
A guy can *manually* configure and freely use the address
received by DHCP in old times. DHCP cannot defend it 
without some sophisticated methods.

Another thing which I would like to tell is that DHCP servers
are deployed scatteredly. The following scenario is what I proposed 
in non-anticipated mode.

   1) Every AR keeps a small duplication-free CoA pool.
   2) Every AR defends the addresses in the pool (It acts as 
       a passive proxy for the addresses).
   3) MN moves and receives L2-UP trigger. 
   4) MN requests a duplication-free CoA with new option
       included in RS message.
   5) NAR sends one in its pool with new option included in
       RA message.
   6) MN sends FBU using the duplication-free CoA to NAR
       without any concerns about address-conflict.

I don't think that the existing DHCP and its deployment can 
support the above scenario. 

Anyway, I agree with Basavaraj and Greg's opinion that 
it would be fine to go ahead and build the solution on the
enhanced FNA scheme ('M' message). And once FMIPv6
is more widely deployed, we will see if FMIPv6 has 
benefits over other proposed DAD optimizations.

Youn-Hee Han.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Jun 2003 08:27:40 -0700

What you describe is how DHCP works now.

One possibility is some WG (not this one and not associated with FMIPv6)
could come up with an extension that:

1) Specified that a probabilistic algorithm be used to minimize collision.

2) Have a DHCP server or relay on each link.

3) Require the DHCP server or relay to defend its addresses.

Though, strictly speaking, 3) should not be required if every host obtained
its address from DHCP, since no other source of addresses would be on the
link.

The requirement that a host perform DAD on a DHCP assigned address was
originally made, I believe, because hand address assignment could lead to
inadvertent duplication at the server, and occasionally did in IPv4. 1)
takes care of that case.

The point I have been trying to make is that if stateful address
configuration is going to be done, it makes more sense architecturally to
use an existing stateful address configuration mechanism and modify it
appropriately to meet the requirements than to invent a new one. The PPPEXT
and IPSEC working groups have recently moved in this direction, specifying
how DHCP can be used with PPP and inside an IKE transaction to obtain
addresses, rather than specifying new mechanisms.

            jak

----- Original Message ----- 
From: "Youn-Hee Han" <[email-masked]>
To: "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Sunday, June 22, 2003 7:29 PM
Subject: Re: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: FBU
transmission text)

> > > > > So, repeating my question to you from a previous thread, how is
having
> > the
> > > > > Note: suppose the text in 2462 that says DHCP addresses must be
DADed
> > can be
> > > > nor depended*, doesn't it? So, I introduced a small version of
stateful
> > server
> > > > that is also optimistic approach. I do not deny the value of
optiDAD. It
> > has

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 23 Jun 2003 09:39:50 -0700

Hello Jim,

I don't think this is right, because DHCP is modeled as some
centralized, administrated thing, and the trivial address pool
allocation suggested is presumably purely local to a subnet.
No relay is needed.  I doubt seriously whether dhc working
group would entertain something so alien as that.

Regards,
Charlie P.

James Kempf wrote:

>>I don't think so. Please refer the following text in
>>    
>>
>'draft-ietf-dhc-dhcpv6-28.txt'
>  
>
>>       server are already in use by another node, the client sends a
>>    
>>
>Decline
>  
>
>>>>>>router manage a pool of nonduplicted addresses any different from
>>>>>>            
>>>>>>
>>>having a
>>>      
>>>
>>>>>Current DHCP server manages a pool of addresses which is *neither
>>>>>          
>>>>>
>DADed
>  
>
>>>>>(which is implemented within an access router) managing a pool of
>>>>>          
>>>>>
>>>addresses
>>>      
>>>
>>>>>If DHCP addresses can be used without DAD, as mentioned by your
>>>>>          
>>>>>
>note,
>  
>
>>>>>DHCP addresses without normal DAD, putting the additional measures
>>>>>          
>>>>>
>into
>  
>
>>>>>FMIP cannot be avoid.
>>>>>
>>>>>Youn-Hee Han
>>>>>
>>>>>          
>>>>>
>>>>
>>>>        
>>>>
>>>      
>>>
>>    
>>
>
>  
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Jun 2003 10:14:56 -0700

Charlie,

I see the intent of my email was not clear.

I was not proposing that this work be done in DHC or that it be done at all.
Perhaps, the specific design suggestions I made are completely useless and
others would be more appropriate upon careful consideration. And I don't
want to get into a long thread here discussing the technical merits or
demerits of various proposals.

The point I was trying to make is that DHCP is a protocol for stateful
address configuration, and if MIP wants to do something involving speeding
up stateful address configuration or making it more amiable to a distributed
approach, then the right thing is to look at how to speed up or distribute
DHC and use DHCP as the protocol. That is the direction being taken by
PPPEXT and IPSEC. Not to try to do stateful address configuration with
RS/RA. And not in the MIPSHOP WG.

As a side note, as my email exchange with Rajeev should have indicated, I am
completely supportive of his design suggestion for piggybacking (I prefer
this word to "encapsulation") "M" and FBU. I view this as an optimization,
like the piggybacking normal BU to CN on traffic, which fits into the FMIP
optimization framework. I don't see any need to involve DHCP in that
process.

            jak

----- Original Message ----- 
From: "Charlie Perkins" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 23, 2003 9:39 AM
Subject: Re: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: FBU
transmission text)

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Jun 2003 10:32:17 -0700

Hi Greg,

> because people have strong hopes pinned on FMIPv6.

That's what I want as well!

> for the publication of FMIPv6.

Ok.

> complex, not that the draft is more complicated

I was not referring to any specific statement by you. I was
reacting to some references in the thread as a whole. I felt
that your comment on how on-going work, especially on
DAD, can complement FMIPv6 was a good one and hence
tried to include it as part of the discussion :-)

> seem to indicate that the reverse is true.

I think the draft will be simpler, yet comprehensive.

> in FMIPv6 is unlikely to make the draft

I agree with you.

> I'm (fairly) sure I will have done this before IETF.

Good.

-Rajeev

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 23 Jun 2003 13:54:21 -0700

Hello again Jim,

I would like to be responsive to your point, without
getting into design specifics.  My suggestion was that
DHCP is constructed according to a model of operation
that is incompatible with the needs of address
allocation/assignment during fast handover.  As a
consequence, in my opinion, the attempt to make DHCP
perform the right dance steps is likely doomed to
failure.

But I might be wrong!  Am I missing something obvious?

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Jun 2003 14:28:52 -0700

> But I might be wrong!  Am I missing something obvious?

What do you propose a network operator should do if they have a policy that
requires use of stateful address configuration?

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 23 Jun 2003 15:24:15 -0700

Hello Jim,

> requires use of stateful address configuration?

I'll give one possible answer.  I don't know if it will
fit the assumptions you prefer, though...  And, to be
fair, there are likely some details that I would miss
at this level of discussion.

If they're running DHCPv6, and they want to have some local
address allocation pool at the access router, then the
DHCP database should be chosen to be disjoint from the
local address pool at the access router.

And, I reckon that the DHCPv6 specification, that each
client should run DAD, should actually be carried out on
those networks, just for robustness in case the pool
allocation is done "wrong".

None of this changes the point that DHCPv6, with its
relays and reliance on centralized administration, is
the wrong model for the sort of address assignment
needed for fast handover.  I can imagine some hacks,
but the hacks are more complicated.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Jun 2003 15:55:05 -0700

> local address pool at the access router.

What do you mean by "local address pool at the access router"? For what
would this be used?

> but the hacks are more complicated.

I guess the upshot is that if you want to do fast handover, don't use
stateful address configuration, of any form, for CoA assignment unless you
want to use hacks.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 23 Jun 2003 16:07:04 -0700

James Kempf wrote:

> What do you mean by "local address pool at the access router"?

Some addresses that can be assigned as care-of addresses
by the access router.

> For what would this be used?

For mobile nodes migrating into the jurisdiction of the
new access router.

> stateful address configuration, of any form, for CoA assignment unless you

I didn't say that, and it's not my intention to see it
used as a guideline.

Regards,
Charlie P.

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 Jun 2003 09:56:21 +1000

Hi James,

Sorry about this post, I had missed your message
to Youn-Hee with 3 points.

Greg

Greg Daley wrote:
> Hi James,
> 
> I may have a misplaced foot with regard to the architecture,
> but an idea is below.
> 
> James Kempf wrote:
> 
> I think that the essential goal here is to ensure that
> MN's receive their addresses from the DHCP subsystem
> on the access-router.
> 
> The access router is often only a bootp/DHCP Relay for
> to another centralized server, which is not on link and
> may not know what silliness SAA nodes have undertaken.
> 
> One mechanism which allows duplicate address state
> to be used for a DHCP system is for the AR to request
> each of a set of addresses from the DHCP server,
> marking them as "placeholders".
> 
> The AR then DAD's each address (maybe using a token bucket
> to feed DAD rights to placeholder pool addresses, in order
> to limit bandwidth utilization) to create a set of addresses
> which may be immediately allocated to MNs upon reception
> of a DHCP Request message, the AR can immediately
> Reply with a validated IP address.
> 
> This eliminates both the DAD and the DHCP RELAY-FORW/RELAY-REPL
> exchange to the remote server from the critical path.
> The AR could then hand over its lease to the MN by
> updating the DHCP server, but this need not be done
> before the MN can use the address.
> 
> Things get even easier when the AR is the DHCP server,
> rather than a relay, since it has the final word about
> the availability of addresses.
> 
> 
>>
> I think that while there are some very elegant ideas
> in IPv6 and IP mobility, a well-aimed hack can be
> almost as elegant.
> 
> Greg.
> 
>

---

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

Hello Charles and James,

My original intent was not to introduce a new stateful address 
configuration mechanism, but to introduce a new method that
an MN can receive a duplication-free address from its new AR,
and immediately assign it to its interface without the RFC 2462
DAD procedure. This method is quite useless for a fixed node.
Only MN in need of seamless handover will require it

In order to actualize the method, 'local address pool at AR' was
introduced in the proposal. Actually, I am not sure whether the 
local address pool is a kind of stateful manner. After AR assigns
an address to MN, it dosen't have to keep any information, just 
deletes the assigned address from the pool. The pool can be 
implemented as a small linked-list structure, just like destination
cache or neighbor cache, within AR's memory. 

I don't see any need to compare the local address pool with DHCP.
As Charles pointed out, DHCP is incompatible with the needs of
fast address allocation. 

Regards,
Youn-Hee

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Jun 2003 08:13:21 -0700

> For mobile nodes migrating into the jurisdiction of the

So maybe you can explain to me why modifying DHCP, a protocol that is
currently used for stateful address configuration, to be more lightweight
and distributed is more of a hack than putting stateful address
configuration into router discovery, which is not currently used for address
configuration?

            jak