Hello itojun,

[EMAIL PROTECTED] wrote:

> >>         we never know what the future operators will do, so it is safer
> >>         not to make assumptions.
> >In that case, I think we have to do something to avoid doing DAD
> >for all those prefixes.  One solution would be to just do it for
> >link-local prefixes, which according to Dave Thaler's argument
> >then become subnet-local prefixes.
> 
>         i don't think it necessary to do anything about DAD.  we perform DAD
>         (not DIIDD) for all addresses assigned, and we will be fine.

Do you still think that is true if the mobile node has to send
out 10, or some unbounded number, of Binding Updates each time it
changes its care-of address?

The discussion in the mobile-ip group is whether a single
Binding Update can suffice for all home addresses of a mobile
node that share the same interface ID.  This led to discussion
about DAD.  The subjects are not inseparably intertwined, but
there is a relationship.

It has been my understanding that a home agent, charged with
the protocol responsibility for defending the addresses of 4,095
mobile nodes (or, say, 500,000 for some cellular plans), would
effectively disable the ability of mobile nodes to use multiple
prefixes, because equipment vendors would just "say no" if they
thought only a few mobile nodes would use this feature.

Thus, I thought that it would be a lot better to have a very
simple scaling mechanism that would still allow for a large
number of prefixes.  This is simple, if the home agent can just
defend the link-local prefix.  It's not so simple if any
increase in the number of advertised prefixes requires a
linear increase in storage or performance requirements at
the home agent.  It's really quite bad if the communication
requirement at the mobile node experiences a linear increase
in capacity requirement at handover time.

My guess is that it will just effectively mean people will not
use multiple prefixes for mobile nodes.

Regards,
Charlie P.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to