Subject: [mobile-ip] RE: RFC 2462 DAD optimization

From: "Richard Draves" <[email-masked]>
Date: Fri, 31 May 2002 10:48:30 -0700

You are basically arguing for DIID (duplicate interface-id detection)
instead of DAD (duplicate address detection), by using DAD on the
link-local address to perform DIID.

It seems strange to me to perform DAD on a link-local address that is
not actually being used. For better or worse, it's not the architecture
that we have today and I'm not inclined to change it.

Rich

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Friday, May 31, 2002 10:45 AM
> To: Richard Draves
> Cc: [email-masked]; IPng Working Group
> Subject: Re: RFC 2462 DAD optimization
> 
> 
> 
> Hello Richard,
> 
> Even manually configured global addresses should be required
> to acquire rights to the corresponding link-local address.  Why not?
> 
> Regards,
> Charlie P.
> 
> 
> Richard Draves wrote:
> > 
> > I disagree. I think the problem is in the RFC 2462 
> optimization. The 
> > RFC 2462 optimization also can fail with 
> manually-configured addresses 
> > - it's not just a problem with RFC 3041 temporary addresses.
> > 
> > I'm curious about the implementation status. I know the Windows 
> > implementation does not implement the RFC 2462 optimization - it 
> > performs DAD on every address independently. What about other 
> > implementations?
> > 
> > Rich
> > 
> > > -----Original Message-----
> > > From: Charles E. Perkins [mailto:[email-masked]]
> > > Sent: Friday, May 31, 2002 10:03 AM
> > > To: Hesham Soliman (ERA)
> > > Cc: [email-masked] '; 'IPng Working Group '
> > > Subject: Re: [mobile-ip] Issue #23 and Issue #30
> > >
> > >
> > >
> > > Hello Hesham,
> > >
> > > "Hesham Soliman (ERA)" wrote:
> > >
> > > > => RFC 2462 makes an optimisation (not a good
> > > > one IMHO) that if a node does DAD on link-local addresses, it 
> > > > 'owns the interface id' for any other address with any scope.
> > >
> > > I think this is a good idea.
> > >
> > > > RFC3041 says that a node can generate a new iid
> > > > and does DAD for _that_ address which uses the
> > > > new iid. Since this is typically not a link local address, you 
> > > > could get a conflict if the HA does not defend all addresses.
> > >
> > > The problem is that RFC 3041 should require any
> > > such node to first acquire rights to the link-local 
> address.  I hope 
> > > that is viewed as an omission, and one which can be quickly 
> > > repaired.
> > >
> > > Regards,
> > > Charlie P.
>

---

From: "Dave Thaler" <[email-masked]>
Date: Fri, 31 May 2002 10:58:44 -0700

As mentioned in email I sent a week or two back, this is 
related to the issue of whether a link-local address has to be 
unique across an entire subnet, not just a link.  Today it's 
defined as a "link-local" not a "subnet-local" address.  This 
means that it is not guaranteed to be unique across a subnet.

Manually configured global addresses don't need to require
rights to the corresponding link-local address since
a) it's not necessary as they don't use the link-local address,
b) it's not sufficient since they need to be unique across the
   subnet, not just the link.

So unless you're proposing we redefine "link-local" addresses
as "subnet-local" addresses (which would at least be a
consistent argument, albeit a change to the architecture),
then what you suggest does not seem to me to be the right solution.

-Dave

> > I disagree. I think the problem is in the RFC 2462 optimization. The
RFC
> > 2462 optimization also can fail with manually-configured addresses -
> > it's not just a problem with RFC 3041 temporary addresses.
> >
> > > > one IMHO) that if a node does DAD on link-local
> > > > addresses, it 'owns the interface id' for any other
> > > > address with any scope.
> > >
> > > > new iid. Since this is typically not a link local
> > > > address, you could get a conflict if the HA
> > > > does not defend all addresses.
> > >
> > > address.  I hope that is viewed as an omission, and
> > > one which can be quickly repaired.
> > >
> > > 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-masked]
> --------------------------------------------------------------------