Subject: Re: Autconfiguration RFC

From: Thomas Narten <[email-masked]>
Date: Fri, 18 Feb 2000 06:59:06 -0500

> But if you look at my answer to Thomas, this is feasable in enviroments
> where you generate your link-identifier temporary (which you do in
> wireless)...

Ahh... I was assuming the interface token was derived from the IEEE
identifier.

But isn't it the case with wireless devices that you *DO* have an
identifier from which to generate an interface token that is likely to
be globally unique?  Also, which type of devices are you talking
about, and shouldn't they have an "IPv6 over foobar wireless devices"
in which this stuff gets nailed down?

> But the question is how do we configure the interface with the same mac with
> different ipaddresses?

First, it need to be established that this is even useful. If two
devices share the same MAC, won't (in general) bad things happen that
one wants to avoid?

> But this could be summarized in a draft "User-token in IPv6"

Indeed!

Thomas
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: Thomas Eklund <[email-masked]>
Date: Fri, 18 Feb 2000 11:13:31 +0100

> -----Original Message-----
> From: Richard Draves [mailto:[email-masked]]
> Sent: Thursday, February 17, 2000 10:57 PM
> To: 'Thomas Narten'; Thomas Eklund
> Cc: 'IPng List'
> Subject: RE: Autconfiguration RFC 
> 
> 
> > ... Also, DHCP
> > uses the MAC address to identify itself to the DHCP server. If there
> > are duplicate addresses, there would appear to be significant risk
> > that the DHCP server would now get requests from different 
> nodes, but
> > for the same identifier. Again, this is likely to cause 
> problems. How
> > does your DHCP approach deal with this problem?
> 
> I thought DCHPv6 uses the client link-local address to 
> identify the client,
> not the MAC address. (Strictly speaking, the identity is a 
> pair - client
> link-local address and DHCPv6 relay address if there is a 
> relay involved.)
And in most case these two are exactly the same...

> 
> So DHCPv6 can't be used to assign a link-local address.

Another thing you can do to solve the problem is to send it to the
link-local broadcast address  and with right ipaddress. Then would both
conflicting interfaces receive that packet but the one with right IP address
would get it and the other would not.

In other words in ethernet in case of a conflict during DAD:
- request an IP address from the DHCP server
- the server sends out the response on the link local broadcast address with
a new option which includes a usertoken...
- the right host hear it and autoconfigures the stateful address.

The usertoken is 64 bit long and is assigned in the home-network on the
format simliar to IMSI or NAI but optimized for IPv6's EUI-64.

This means that you would always have a uniqueue identfier (l3 identifier)
on the link...

If people think that its worth continuing with?

/Thomas
> Rich