Subject: Reserving bits in RFC 2473 Interface IDs?

From: Erik Nordmark <[email-masked]>
Date: Mon, 4 Mar 2002 23:15:09 +0100 (CET)

RFC 2373 defines two kinds of interface IDs: Those with the "u"-bit
set to 1 (i.e, globally unique), and those set with the "u"-bit set to
0 (i.e., not globally unique).  Prompted by some discussion in the
Mobile IP working group I realized that RFC 2373 does not have any way
to introduce or identify new types of interface IDs that can be
identified syntactically by just looking at the interface ID. It
might be useful in the future to be able to define a new type of
interface id that has some new properties, similar in nature
to the current ability to identify globally unique interface IDs, and
making it possible to determine whether the interface ID has this property
by merely inspecting the interface ID. Hence this note.

This note is not about any particular use - it is merely an attempt
at reserving some space in the interface ID to be prepared for potential
future ideas. Any discussion about using a part of the reserved space,
whether for Mobile IP or some other idea in the next 5 or 10 years,
will need to be a separate standards track document that will need to
be separately discussed.

[Those wanting background information of potential future use of IID bits
contemplated by the MIP WG can read
	http://playground.sun.com/mobile-ip/WG-archive/msg05351.html
	http://playground.sun.com/mobile-ip/WG-archive/msg05357.html
Those proposals are not the subject of this note, but merely serve as
an example of a possible use of reserved bits in the future.]

The observation is that, at least on paper, we've given up all of the 64
bit IID space. Half of this space, with the universal bit set to 1,
is given to IEEE EUI-64 identifiers. The other half (universal = 0)
is used for IIDs that are not globally unique including
 - manually assigned,
 - assigned by DHCPv6 (but DHCPv6 can assign globally unique ones as well)
 - random IIDs that is used in RFC 3041 and RFC 2472 section 4.1.

Those documents specifying random IIDs talk about generating a 64-bit 
random number and setting the universal bit to zero to form the IID.

There are two possible ways to reserve some space for future use.

Reserve one quarter of the IID space
------------------------------------

The first one does not have any implementation impact and is based on
the observation that EUI-64 identifiers that are assigned to interfaces
never have the 'group' bit set. (Such EUI-64 addresses are used for
sending multicast packets.)

Thus it is possible to reserve the IID that have 
	universal = 1, group = 1
for future use. This would result in the IID space being divided as follows:
	universal = 0			Manual, DHCP, and random numbers.
	universal = 1, group = 0	EUI-64
	universal = 1, group = 1	Reserved for future use

This change has no impact on implementations. It can be 
captured in the specification by adding text to draft-ietf-addr-arch-v3
to point out that the group bit must be zero when the universal bit is 
set to one.

Reserve half of the IID space
-----------------------------

By modifying RFC 3041 and RFC 2472 to say that the random number generated
must have both the universal *and* the group bit set to zero.
This impacts implementations of those specifications; for RFC 2472 it only
impacts the implementations that fall back to generating a random number
as a last resort.

If this option is selected it would result in the IID space being divided
as follows:
	universal = 0, group = 0	Manual, DHCP, and random numbers.
	universal = 0, group = 1	Reserved for future use
	universal = 1, group = 0	EUI-64
	universal = 1, group = 1	Reserved for future use

draft-ietf-ipngwg-addr-arch-v3 needs to be updated if we take this path.

Compared to the "quarter" proposal this would carve off a larger part of 
the IID space for future use but it comes with the disadvantage of needing to
modify RFC 3041, RFC 2472, and implementations thereof.
Note that an update to RFC 3041 with protocol clarifications is already in 
progress.

Similar restrictions should be noted wherever we talk about manual
configuration or DHCP assignment of addresses, which seems to just
be in Appendix A in draft-ietf-ipngwg-addr-arch-v3.
[As an aside the DHCPv6 specification should presumably mention what
types of interface IDs should be used when a DHCP server allocates addresses.]

Impact
------

Reserving these Interface IDs MUST NOT have any impact on implementations
other than how addresses are auto-configured. In particular, implementations
MUST NOT reject packets that have a source address from the reserved space
and MUST NOT prevent sending packets to destination addresses from the reserved
space. In effect the IID, just like the whole 128 bit addresses, should be
treated as an opaque set of bits.

Thus the effect of reserving this space is merely to say that IIDs must
not be allocated in the reserved space.

Any future *use* of these reserved portion(s) i.e. documents specifying
semantics for bit the and/or suggesting that addresses be allocated with
these reserved parts of the IID, require a standards
track RFC i.e. any such use would require IETF wide rough consensus
as normal for standards track documents.
Thus the purpose of this is just to reserve the space should there be
some utility of doing sub-allocations of IID space in the future.
This seems consistent with the path that was taken when universal=1
was assigned to IIDs that are globally unique.

  Erik

--------------------------------------------------------------------
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: Wed, 06 Mar 2002 09:29:33 +0100

Have you read draft-dupont-ipv6-imei-00.txt?

Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 6 Mar 2002 10:56:50 +0100 (CET)

> Have you read draft-dupont-ipv6-imei-00.txt?

Now I have.

   Erik

---

From: Alexandru Petrescu<[email-masked]>
Date: 12 Mar 2002 11:47:05 +0100

> Have you read draft-dupont-ipv6-imei-00.txt?

Hi Francis, thanks for putting the IMEI idea on paper, it's been long
expected by many circles.  I have a remark below, please correct me if
I misunderstood the conversion.

> The IMEI 330001 53 007826 gives the 0333:0001:5300:7826 (usually
> written 333:1:5300:7826) interface identifier.

Since IMEI is represented in decimal and addresses in hexa, by doing
the above it effectively leads to impossibility of use of parts of
address space.  I mean, all IMEI's can be represented into an IPv6
Interface ID, but certain IPv6 Interface ID's will never have a
correspondent IMEI.  Maybe better can be done.

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Mar 2002 14:49:52 +0100

> correspondent IMEI.  Maybe better can be done.

...I would suggest re-phrasing the following:

   "The IMEI 330001 53 007826 gives the 0333:0001:5300:7826 (usually
    written 333:1:5300:7826) interface identifier."

into:

   "For example, the IMEI 330001 53 007826 gives the Interface ID
    300:6072:9ed2.  The maximum IMEI 999999 99 999999 is Interface ID
    5af3:107a:3fff.  The space in the Interface ID starting at
    5af3:107a:4000 inclusive and up to ffff:ffff:ffff inclusive can
    not represent an Interface ID derived from an IMEI."

Alex

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Wed, 13 Mar 2002 15:54:57 +0100 (CET)

As part of the IMEI the first two digits include the country of approval
(33 for France for example) or the manufacturer. I will like to see
alternatives that protect possible personal identifiable information.

A message digest of the (IMEI, Nonce) will theoretically make use of all
parts of space and will provide unlinkability between IPv6 global
addresses and certain devices, what imho is highly recommendable.

/aep

1.2

-- 
--------------------------------------------------------------------------
That you are not paranoid, it doesn't mean that they are not watching you!
http://www.it.kth.se/~aep

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Mar 2002 16:21:42 +0100

Alberto Escudero-Pascual <[email-masked]> writes:
> (33 for France for example) or the manufacturer.

Aha, that's bad.  This 33 looks a lot like France's prefix, so I
suppose US has 1, Luxembourg has 352.  The question is: is the IMEI
length variable?

Adding new countries or manufacturers will exceed the IMEI one day?
It's certainly not desirable to have this exceed the Interface ID
derived from IMEIs.

> I will like to see alternatives that protect possible personal
> identifiable information.

Let's come up with a first derivation that gives a fixed-length
Interface ID from IMEI and then randomize it for those who desire
privacy, what do you think?

> A message digest of the (IMEI, Nonce) will theoretically make use of
> all parts of space and will provide unlinkability between IPv6
> global addresses and certain devices, what imho is highly
> recommendable.

I think that what you propose does not give privacy.  The hash you
propose will stay un-changed and someone can identify that the same
person that bought a CD yesterday, bought an MD today.  So what.

What do you think?

Alex

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 13 Mar 2002 16:31:37 +0100

> person that bought a CD yesterday, bought an MD today.  So what.

you should probably change your address periodically (as suggested in
RFC3041)
by using a different nonce....

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Mar 2002 16:54:01 +0100

Claude Castelluccia <[email-masked]> writes:
> you should probably change your address periodically (as suggested
> in RFC3041) by using a different nonce....

Right, I missed the nonce meaning.  I guess Alberto meant just that.

Alex