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