Subject: well-known Interface IDs

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Dec 2001 10:49:18 +0100

There are more and more well-known Interface IDs for uni/anycast
addresses, for instance in DNS discovery and HIP.
To use well-known IIDs seems to be a good idea but IMHO we should
organize the IID space ASAP... Any comments?

[email-masked]
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Wed, 19 Dec 2001 18:28:49 +0700

Date:        Wed, 19 Dec 2001 10:49:18 +0100
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | To use well-known IIDs seems to be a good idea but IMHO we should
  | organize the IID space ASAP... Any comments?

I don't think it is a good idea at all.   In fact it is a terrible idea.
If we need anything well known, they should be addresses (of the
appropriate scope), not just interface IDs, which then must be assuming
some particular size for of interface ID space for all nets, forever, which
is another terrible idea (the 64 built into whichever RFC it is is
just bogus ... note I don't mean the IPv6 over foobar specs, there it
makes sense).

kre

---

From: Brian Haberman <[email-masked]>
Date: Wed, 19 Dec 2001 08:57:54 -0500

Francis,
     draft-ietf-malloc-ipv6-guide-04 Section 4.2 describes this for
IPv6 multicast.  The same thing could be done for anycast and/or
unicast.

Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Dec 2001 19:39:59 +0100

In your previous mail you wrote:

=> this is exactly what I'd like to get with a little difference:
IMHO we should not reserve space (other than all zeros) and rely
on probability to avoid collisions with RFC 3041 (an alternative is
to set the group/7th bit for private/temporary addresses but this seems
to be overkilling because the issue already exists with manual IIDs).
I believe something like this should be fine:
 - :: reserved for router subnet anycast
 - ::1-::FFFF free for manual & lazzy numbering
 - ::1:1-::1:FFFF for well known services (DNS discovery, etc)
 - ::2:1-::2:FFFF for local services
 - ::FDFF:FFFF:FFFF:FF80-::FDFF:FFFF:FFFF:FFFF for anycasts (RFC 2526)

Regards

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 19 Dec 2001 13:48:31 -0800

I don't agree that we need to organize the space, but if everyone
insists on going down this rat-hole then at least use the IANA allocated
OUI 00-00-5E like ISATAP is doing. This will avoid the collision
problems, plus make it clear who does the allocation and tracking if it
wasn't already.

Tony

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Francis Dupont
> Sent: Wednesday, December 19, 2001 10:40 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: well-known Interface IDs
>
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 11:36:23 +0100

=> so I propose to split the thread into two basic questions:
 - predefined IIDs or not (authors of draft-ietf-ipngwg-dns-discovery-03.txt,
   please answer)
 - if yes how to organize the space?

About your proposal, if we set the globally unique bit on, you get IIDs
which are no more globally unique. If it is off, this won't avoid
collision... The only advantage is the clarity, i.e. last argument.

Regards

PS: I'll send the feedback to the HIP mailing-list when we'll reach
a consensus.

---

From: Matt Crawford <[email-masked]>
Date: Thu, 20 Dec 2001 10:00:19 -0600

> insists on going down this rat-hole then at least use the IANA
> allocated OUI 00-00-5E like ISATAP is doing. This will avoid the
> collision problems, plus make it clear who does the allocation and
> tracking if it wasn't already.

Which would be <prefix>:0200:5eXX:XXYY:YYYY in IPv6 interface id
form.  The XXXX portion need not be equal to fffe (but should not be
ffff).
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 08:52:20 -0800

> collision... The only advantage is the clarity, i.e. last argument.

The state of the bit is not the determining value in uniqueness, so I
believe the bit should be set to local like it is for ISATAP. They would
still be as unique as any other IANA registered value.

> form.  The XXXX portion need not be equal to fffe (but should not be

I agree it should not be ffff or fffe, but would set the u/l bit off. If
they need to exist we should stick them in 0000:53ff:fdyy:yyyy. Again, I
have not been convinced there is any value in defining well known host
addresses (anycast prefixes yes, hosts no).

Tony

---

From: Matt Crawford <[email-masked]>
Date: Thu, 20 Dec 2001 11:35:53 -0600

When the Universal/Local bit is set to the "Local" value, the other
bits of the OUI are irrelevant.  You cannot reserve or claim an EUI64
which is "Local".  At least, not in any IEEE sense.
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 09:54:50 +0100

=> I object: these IIDs are globally unique and in the same time
there are known to be *not* unique at all if there are no constraint
on XXXXYYYYYY (and such a constraint shall defeat the "well-known"
purpose).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 14:28:29 +0100

> collision... The only advantage is the clarity, i.e. last argument.
   
   The state of the bit is not the determining value in uniqueness,

=> hum, the bit is global/local scope and last address architecture
draft speaks about uniqueness...

   so I believe the bit should be set to local like it is for ISATAP.

=> I agree but in this case collisions won't be avoided by construction.

   They would still be as unique as any other IANA registered value.

=> I don't understand your argument... or do you say that they'd still
be as unique as the ::1 address for instance?

   I agree it should not be ffff or fffe, but would set the u/l bit off. If
   they need to exist we should stick them in 0000:5eff:fdyy:yyyy. Again, I
   have not been convinced there is any value in defining well known host
   addresses (anycast prefixes yes, hosts no).
   
=> this is another argument... I'd like to get the answer from DNS/SLP
discovery people (with DNS or SLP all other services can be discovered
so well-known addresses are not needed, i.e. the problem stands only
for the very first step).

Regards

PS: can I say in the HIP mailing list that DNS/SLP should be used in place
of a reserved/pre-allocated/well-known set of IIDs? It seems we can reach
a consensus about this specific question, i.e. send objections to me or
(better) the mailing list ASAP.
--------------------------------------------------------------------
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: Matt Crawford <[email-masked]>
Date: Fri, 21 Dec 2001 09:31:49 -0600

I have just one last thing to say on the matter:

		3041.