Subject: [RRG] IEEE EUI-64 as an Identifier format

From: RJ Atkinson <[email-masked]>
Date: Tue, 8 Jul 2008 15:55:19 -0400

Since the IPv6 specs are already using a modified EUI-64
to generate the low-order 64-bits of the IPv6 address,
it might be worth noting some properties of the EUI-64 here:

1) There is a specific unicast/multicast bit.
2) There is a scope bit, with possible values
    of "local" and "global".
3) 62 bits remain to distinguish one EUI-64 from another.

If one said that an EUI-64 that is not generated
directly from an IEEE MAC address MUST have the scope
set to "local", then those values that have global
scope would be isolated from those with local scope.

If one thought that the IPv6 Privacy extensions (RFC-3041)
provided good protection, then those could be re-used
in an EUI-64 used as an Identifier.

If one thought that deriving the Identifier from a public-key
were a good approach, then that could also be done when
using an EUI-64 as an Identifier (just make the derivation
function produce 62 bits).

If one wanted to have a group Identifier, then the "multicast"
bit of the EUI-64 could be chosen accordingly.  Otherwise,
for individual nodes the "unicast" value could be chosen.

So the EUI-64 format seems like a pretty practical one to use
for an IPv6 or IPv6-like environment.

Cheers,

Ran

IEEE Standards Association:
   <http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>

Wikipedia:
   <http://en.wikipedia.org/wiki/EUI-64>

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Tony Li" <[email-masked]>
Date: Tue, 8 Jul 2008 13:17:18 -0700

|So the EUI-64 format seems like a pretty practical one to use
|for an IPv6 or IPv6-like environment.

Agreed.  The ability escape to a crypto-generated ID seems like a sufficient
mitigation, IMHO.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Jul 2008 14:13:27 -0700

However, you get zero aggregation of ID space with EUI-64 assignments.  
Not good for a mapping database.

Dino

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 8 Jul 2008 17:43:27 -0400

Dino wrote:
% However, you get zero aggregation of ID space with EUI-64 assignments.
% Not good for a mapping database.

Yes, there is no aggregation of an EUI-64-based Identifier.

In turn, that might have implications, depending upon which
flavour of identity/location separation architecture that
one wants to use.

Some flavours really don't need a new mapping database,
and those flavours consequently don't have an issue with
non-aggregation of Identifiers.

Cheers,

Ran
[email-masked]

---

From: "Tony Li" <[email-masked]>
Date: Tue, 8 Jul 2008 14:58:32 -0700

|However, you get zero aggregation of ID space with EUI-64 
|assignments.  
|Not good for a mapping database.

Not good if you need an ID->locator mapping or ID-><anything> mapping.
However, do we have that need?

Tony

---

From: "William Herrin" <[email-masked]>
Date: Tue, 8 Jul 2008 18:49:59 -0400

> Agreed.  The ability escape to a crypto-generated ID seems like a sufficient

Disagree for reasons stated in my other post. A client-side ID which
is either constant or predictable day over day has terrible privacy
implications.

On Tue, Jul 8, 2008 at 5:13 PM, Dino Farinacci <[email-masked]> wrote:
> However, you get zero aggregation of ID space with EUI-64 assignments. Not
> good for a mapping database.

You're not supposed to be aggregating the identifier. You're not
supposed to be using the identifier in a manner where aggregation
would even be helpful. The Locater is supposed to aggregate with
topologically nearby Locaters while the identifier doesn't. That's the
whole point of the split.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: "Tony Li" <[email-masked]>
Date: Tue, 8 Jul 2008 16:33:11 -0700

Hi Bill, 

|> Agreed.  The ability escape to a crypto-generated ID seems 
|like a sufficient
|> mitigation, IMHO.
|
|Disagree for reasons stated in my other post. A client-side ID which
|is either constant or predictable day over day has terrible privacy
|implications.

Ok, but if you've got an ID that is tied to public/private key pair, it
would seem reasonable that you could change IDs as rapidly as you change
keys.  If you feel the need to do so daily (or hourly), I don't see that
that creates any architectural difficulties.

|You're not supposed to be aggregating the identifier. You're not
|supposed to be using the identifier in a manner where aggregation
|would even be helpful. The Locater is supposed to aggregate with
|topologically nearby Locaters while the identifier doesn't. That's the
|whole point of the split.

If a particular proposal chooses to use a structured, administratively
assigned identifier then there will need to be hierarchy for managerial
purposes.  Of course, that doesn't apply to CGid's.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Tue, 8 Jul 2008 20:52:38 -0400

> that creates any architectural difficulties.

Hi Tony,

Actually, there's no real reason that anything operating as a client
has to have just one identity. For privacy purposes, it's better if
the node doesn't.

Given an appropriate mapping system, the layer 7 applications could
register and release as many identities as desired on whatever
schedule desired and then provide an appropriately selected identity
to layer 4. The identities are only required to survive for the
duration of a communication session.

Also, while the identities in the mapping system have to be globally
unique, the session identities do not. A connection-oriented session
could, for example, mention the global ID's during setup, agree on a
shorter session ID at the time and then use that session ID for the
duration of that session.

> purposes.

DNS.

Regards,
Bill Herrin

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Jul 2008 13:39:35 +0800

> whole point of the split.

Hierarchy in the identifier has its meaning, for example, it will be helpful
in access control since the ACL can be based on identifier-block. On the
contrary, the flat identifier will burden the firewall with a lot of the ACL
configuration tasks.

Xiaohu XU

---

From: "Hongbin Luo" <[email-masked]>
Date: Wed, 9 Jul 2008 14:17:40 +0800

It seems that this issue always exist when end host roams?

Hongbin

--
to  unsubscribe  send  a  message  to  [email-masked]  with  the
word  'unsubscribe'  in  a  single  line  as  the  message  text  body.
archive:   <http://psg.com/lists/rrg/ >  &  ftp://psg.com/pub/lists/rrg

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Jul 2008 14:18:49 +0800

> assigned identifier then there will need to be hierarchy for managerial

That's just the intention of the hierarchical identifier in my HRA proposal.
It provides both intrinsic proofs of ownership and the organizational
affiliation.

Xiaohu XU

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Jul 2008 14:54:42 +0800

________________________________________
发件人: [email-masked] [mailto:[email-masked]] 代表 Hongbin Luo
发送时间: 2008年7月9日 14:18
收件人: Xu Xiaohu
抄送: rrg
主题: Re: re: [RRG] IEEE EUI-64 as an Identifier format

 
No, the identifier will remain unchanged during roam since it's location-independent.

Xiaohu XU

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jul 2008 17:18:12 +0300

Dino,

> Not good for a mapping database.

Yes. But I suspect that wishes about the aggregatability of the ID space 
are similar to past wishes about aggregatability of addresses. I.e., 
wishes that do not necessarily become true.

Note that aggregation of the ID space can come in two ways: ability to 
map range of IDs belonging to an organization vs. ability map an 
individual host's ID. I would suggest that we need the former. The 
latter would replace current scalability and aggregation problems with 
different scalability and aggregation problems.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Jul 2008 09:35:25 -0700

> Dino,
>
>> However, you get zero aggregation of ID space with EUI-64  
>> assignments. Not good for a mapping database.
>
> Yes. But I suspect that wishes about the aggregatability of the ID  
> space are similar to past wishes about aggregatability of addresses.  
> I.e., wishes that do not necessarily become true.
>
> Note that aggregation of the ID space can come in two ways: ability  
> to map range of IDs belonging to an organization vs. ability map an  
> latter would replace current scalability and aggregation problems  
> with different scalability and aggregation problems.

You can't have ranges because MAC addresses are not allocated that  
way. They are random by nature.

The only way to aggregate is by doing power-of-2 aggregation. That is  
you need to use the entire 128-bits of an IPv6 address as the EID.  
Then you aggregate on the high-order bits truncating off the EUI-64  
low-order bits. This is precisely an LISP IPv6 EID-prefix.

Dino

---

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Jul 2008 12:28:37 +0300

Dino,

> low-order bits. This is precisely an LISP IPv6 EID-prefix.

Yes. But point was: I see a lot of value in ID space allocation per 
organization, just like in PI space. This is workable in terms of the 
mapping system. You can go further, as you are suggesting above. But I 
do not necessarily see the value, and I do see a significant number of 
problems, starting from scalability.

Jari