Subject: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt

From: Margaret Wasserman <[email-masked]>
Date: Sun, 04 Aug 2002 20:40:32 -0400

As mentioned on this list previously, the IPv6 WG has been asked
to review draft-savola-ipv6-127-prefixlen-04.txt, which has been
submitted to the RFC editor for publication as an Informational
RFC.

The draft discusses several operational issues with the use of /127
prefixes on point-to-point links between routers.

Reviewing this draft raised several interesting questions, in my
mind, about our current addressing architecture... 

First, I wondered why this would be an issue when all recent versions
of the Addressing Architecture, including the most recent update 
(draft-ietf-ipngwg-addr-arch-v3-08.txt) specify a maximum length 
prefix of /64 for all addresses that don't start with '000'.  At 
least, this is clearly implied by the following wording:

"For all unicast addresses, except those that start with binary 
value 000, Interface IDs are required to be 64 bits long and to be 
constructed in Modified EUI-64 format."

Unfortunately, operators seem to be ignoring this restriction in
numbering point-to-point links between routers.  I have spoken to 
a few IPv6 operators, and it is common practice to use /125, /126
or even /127 prefixes for these links.

What does this mean for us?  Well, in my opinion, we don't want
to standardize a restriction that we _know_ will be ignored by
the folks who are deploying the software.
   
We want/need to use EUI-64-based addresses for address 
autoconfiguration.  But, is this inherently incompatible with
the folks using longer prefixes on point-to-point links?  Why
do all IIDs need to be in modified EUI-64 format?  Do we
want to remove this restriction from the addressing architecture?
Or can we show good reasons why it shouldn't be ignored?

We also may want to be cautious about standardizing mechanisms 
that rely on a hard /64 boundary between the prefix and IID.
For example, what is the minimum number of IID bits I must 
have to use privacy addresses?

The addressing architecture also imparts special meaning to two 
bits in the middle of the IID.  Bits 70 and 71 of an IPv6 address 
are called the 'u' bit and the 'g' bit, and their semantics are 
based on the meanings of the corresponding bits in EUI-64 
identifiers (with the sense of the 'u' bit reversed).  The
'u' bit is supposed to indicate whether the IID is a globally
unique EUI-64-based identifier (1=yes, 0=no), and the 'g' bit
is reserved (must be 0).  When longer prefixes are used, though, 
these bits end-up in the prefix, instead of in the IID.

Can we really expect operators to reserve these two bits for
this use?  Or will they allocate their longer prefixes without
worrying about the meaning of these two bits?

If we think that, in practice, operators will ignore the meaning
of these two bits, does the 'u' bit really have any meaning at all?

Do I have any answers to all of the questions I keep asking? :-)
Well, maybe...

In my opinion, we should not standardize a hard boundary between
the prefix and the IID, especially if we know it will be ignored
by operators.

We can make it clear that a 64-bit boundary is required in order
to use EUI-64-based addresses for address autoconfiguration.  And,
it might make sense to document a maximum prefix length that is
consistent with privacy addresses.

I also think that we should drop the 'u' and 'g' bit semantics
from the addressing architecture.  It is pretty clear, at this
point, that we won't ever be certain that an address with the 
'u'-bit set has a globally unique IID, so there really isn't
any reason to clutter up the addressing architecture with these
strange bits.

What do the rest of you think?

Margaret

--------------------------------------------------------------------
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: Bill Manning <[email-masked]>
Date: Sun, 4 Aug 2002 20:25:21 -0700 (PDT)

% Unfortunately, operators seem to be ignoring this restriction in
% numbering point-to-point links between routers.  I have spoken to 
% a few IPv6 operators, and it is common practice to use /125, /126
% or even /127 prefixes for these links.

	/64s are a waste of space.  their use can be confusing
	when things are p2p.

% We want/need to use EUI-64-based addresses for address 
% autoconfiguration.  But, is this inherently incompatible with
% the folks using longer prefixes on point-to-point links?  Why
% do all IIDs need to be in modified EUI-64 format?  Do we
% want to remove this restriction from the addressing architecture?
% Or can we show good reasons why it shouldn't be ignored?

	Yes please.  It would be highly desirable to 
	locally use subnets in the, say  70-110 bit range.
	
% We also may want to be cautious about standardizing mechanisms 
% that rely on a hard /64 boundary between the prefix and IID.
% For example, what is the minimum number of IID bits I must 
% have to use privacy addresses?

	Well, the real problem is mixing transport locators
	with node identifiers, as is done with the current 
	architecture.  Hard-coding the split @ 64 bits will
	encourage vendors to hardcode these restrictions
	in silicon.  Avoiding this was an early design consideration
	that seems to have been lost.  Ideally we should lose
	the node identifer from the addressing architecture.
	(I know, if wishes were horses...)

% Can we really expect operators to reserve these two bits for
% this use?  Or will they allocate their longer prefixes without
% worrying about the meaning of these two bits?

	We will allocate, ignoring implied meaning in these bits.

% In my opinion, we should not standardize a hard boundary between
% the prefix and the IID, especially if we know it will be ignored
% by operators.

	Amen (and for other reasons as well)

% We can make it clear that a 64-bit boundary is required in order
% to use EUI-64-based addresses for address autoconfiguration.  And,
% it might make sense to document a maximum prefix length that is
% consistent with privacy addresses.

	EUI-64 based numbers really have no place in IPv6
	addresses, except as a local optimization. Use of 
	EUI-64 addresses introduces privacy concerns that
	require the invention of grevious hacks to address
	mgmt.

% I also think that we should drop the 'u' and 'g' bit semantics
% from the addressing architecture.  It is pretty clear, at this
% point, that we won't ever be certain that an address with the 
% 'u'-bit set has a globally unique IID, so there really isn't
% any reason to clutter up the addressing architecture with these
% strange bits.

	Amen to this as well.

% What do the rest of you think?

	Well, here is one set of opinions.

% 
% Margaret
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% 
% --------------------------------------------------------------------
% 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]
% --------------------------------------------------------------------
% 

-- 
--bill

---

From: Robert Elz <[email-masked]>
Date: Mon, 05 Aug 2002 20:34:56 +0700

Date:        Sun, 4 Aug 2002 20:25:21 -0700 (PDT)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

I agree with everything you say except this ...

  | 	EUI-64 based numbers really have no place in IPv6
  | 	addresses, except as a local optimization. Use of 
  | 	EUI-64 addresses introduces privacy concerns that
  | 	require the invention of grevious hacks to address
  | 	mgmt.

There are two different privacy concerns - one is that people can tell
which brand of LAN cards I am using (or the manufacturer of some other
equipment).   For the vast majority of people, "big deal".   There may
be a few organisations that actually care about this, but they can simply
assign addresses 1 2 3 4 ... if they want to, and completely avoid that
concern.

The other is "user tracing" and what matters there is whether there is
a unique addr that comes at least fairly close to identifying a user.
For this it doesn't matter in the slightest if the address is based upon
an EUI or not, all that matters is that it is stable.   People have been
used to hiding behind NATs which conceal their real addresses, and make
them be just "one of many" using anything from the same addr block.
Now global addresses are becoming available again, this concern is
becoming more prevalent (it never used to bother anyone, as in the
early days there was essentially no-one on the net who would collect this
kind of info and misuse it - besides the fact that most systems (and
addresses) were home for large numbers of individuals anyway).

The "grevious hacks" are only needed to cope with the 2nd of those, the
first has a much more trivial solution.   And the 2nd is completely unrelated
to the use of EUI's.   So, I don't think it is correct to blame privacy
problems in any way on the use of EUI's for autoconfig.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 05 Aug 2002 20:34:43 +0700

Date:        Sun, 04 Aug 2002 20:40:32 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | What does this mean for us?  Well, in my opinion, we don't want
  | to standardize a restriction that we _know_ will be ignored by
  | the folks who are deploying the software.

I agree.   This is a point I have been trying to make for ages.
But there is more than that, even if we didn't know that it was
going to be ignored (is being ignored), we'd want to be asking
ourselves why we'd want to be standardising something for which
we have no use at all.

  | We want/need to use EUI-64-based addresses for address 
  | autoconfiguration.  But, is this inherently incompatible with
  | the folks using longer prefixes on point-to-point links?

No, not in the least, we do it every day.

  | Why do all IIDs need to be in modified EUI-64 format?

They don't.   And if we look back at the earliest addressing discussions
there was always the assumption that they wouldn't (all) be.

It was only when 8+8 started being considered that this suddenly started
seeming important to people - 8+8 has been long abandoned as a possibility,
but this remnant of it is hanging on.  Perhaps there are some people out
there hoping that it can be reincarnated?   It cannot - that's the kind of
thing that would have to be introduced at the start of deployment, as it
depends upon addressing assignments, it would be too late now, even if it
had been possible, once.

  | Do we want to remove this restriction from the addressing architecture?

Yes.

  | Or can we show good reasons why it shouldn't be ignored?

I certainly can't - and I have been asking why anyone cares about this
for ages now.   The only answer I have ever received is "because the
addressing architecture says so", which is just crazy.

It is the same whenever someone asks about using a prefix longer than 64
on p2p links - several people tend to say "you can't do that because the
addressing architecture says you can't, it is illegal" - but never with
any sign of anything that will fail to work because of this.   Simply
"it is illegal therefore you cannot" - which some people believe, and
others simply ignore, and find that they have no problems at all.

  | We also may want to be cautious about standardizing mechanisms 
  | that rely on a hard /64 boundary between the prefix and IID.

It depends upon where we're looking from.   Autoconfig (which relies
upon this) is just fine, because it is a local choice - sites can choose
to use 64 bit IIDs in which case autoconfig works, or they can choose to
use smaller ones, and give up the possibility of autoconfig.

Anything else similar would also be just fine (including 3041).

But we don't want to be doing anything that assumes that anyone outside
the site is able to make assumptions about the way the site is using the
address space.

  | Can we really expect operators to reserve these two bits for this use?

no.

  | Or will they allocate their longer prefixes without
  | worrying about the meaning of these two bits?

Yes.   It is already done.

  | If we think that, in practice, operators will ignore the meaning
  | of these two bits, does the 'u' bit really have any meaning at all?

Yes, in the context of nets with mixed autoconfig & statically assigned
addresses, it is just fine.   It allows addresses to be assigned with the
knowledge that autoconfig isn't going to break on some node (essentially
the 64 bit address space is divided into half reserved for autoconfig, and
half for other forms of config).

But it isn't something that should be observed from outside.

  | I also think that we should drop the 'u' and 'g' bit semantics
  | from the addressing architecture.

Does 'g' actually have semantics, I didn't think we had gone that far...

  | It is pretty clear, at this
  | point, that we won't ever be certain that an address with the 
  | 'u'-bit set has a globally unique IID,

That's true regardless of anything else we do here - that is, even if
we could assume that 'u' being set means that an address has been built
out of an EUI-64 built from its MAC addr.

One obvious case is where a node wants to retain its address, after the
MAC addr from which it was built has been removed.   Eg: a pretty common
case, you have a major server, it has the current state of the art in
net connectivity plugged into it, and it assigns itself its IPv6 addr.
Then the state of the art advances (100Mbit ethernet becomes a household
commodity, and servers all start using GBit instead).   So, the 100Mbit
card is yanked, and a GBit card is inserted.   The node now gets statically
configured with its previous address, as it is quite widely known, and
there's no need to change it.   The 'u' bit has to remain set for this to
work of course.

That's all fine - but now I have this spare 100Mbit card lying around, and
100Mbit now being a household commodity, and not really adequate anywhere
else, I take it home, and plug it into one of my systems there, where the
10Mbit that used to be adequate is now just wet string...   The system there
isn't well known anywhere, so it doesn't need to keep its old address, and
just uses autoconf based upon the mac addr of the card that has just been
plugged in.

Now, we have two nodes with exactly the same IID.   IPv6 has no problem
with this (the two nodes live on completely different nets, with completely
different prefixes).   Nor does TCP, UDP, or anything else.

Some people here would say that the rules were broken when a card that's
mac addr was still in use as an IID was allowed to be used elsewhere - but
you can be sure that if I can get a free working card, I'm not going to
let that kind of nicety bother me much (nor is just about anyone else).

What I might be able to do of course, and what lots of people with old suns
do all the time, is reprogram the MAC addr to something different (old suns
are starting to need this, as their batteries are dying, and the nvram
that stored their mac addresses is all losing its memory).   When I do this,
there's no way I cm going to go to IEEE and get myself an OID to make
my own unique EUI's - for one card?   No, I am just going to invent something
that looks good to me.  As long as it is unique on my LAN, it will work.

But now we have the IPv6 stack, looking at the programmed (unique appearing)
MAC addr on the card (or in the sun's nvram) and about to autoconfigure itself
an address.   How is it supposed to determine that the MAC addr it is
seeing isn't one that was programmed by the manufacturer, but is instead one
that I just decided it should have?   Is there any implementation around that
isn't going to set the 'u' bit in such a case - even though the address
very likely isn't globally unique?

We simply need to end the pretence.

  | so there really isn't
  | any reason to clutter up the addressing architecture with these
  | strange bits.

I'm not sure about the architecture, but the use of 'u' for autoconfig
needs to be somewhere, that's just fine as it is now.

The rest of all of this should simply be deleted from everywhere (the hard
part is to get people to stop thinking about the IID as being unique, which
they persist in doing, regardless of how much evidence that it isn't is
thrown their way).

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 05 Aug 2002 09:59:13 -0400

>needs to be somewhere, that's just fine as it is now.

When you say that we need the 'u'-bit for autoconfig, do you just mean
that we should continue to reverse this bit in the EUI-64 identifier 
before we use it, to remain consistent with current practice?

Or are you saying that the semantics of the 'u'-bit (that it indicates
an IID is globally unique) has some importance for autoconfig?

>they persist in doing, regardless of how much evidence that it isn't is

In the Yokohama meeting, Steve Deering lead a discussion on the
uniqueness of IIDs, and there was a pretty big majority of people
in the room who thought that we shouldn't even require IIDs to 
be unique on a link.  Addresses need to be unique (obviously), but
not necessarily the IIDs from which they are created.  The discussion
will be documented in the minutes, and we'll offer a chance for people
on the list to comment before we make any final decision, of course.

Margaret

---

From: Bill Manning <[email-masked]>
Date: Mon, 5 Aug 2002 11:32:34 -0700 (PDT)

%     Date:        Sun, 4 Aug 2002 20:25:21 -0700 (PDT)
%     From:        Bill Manning <[email-masked]>
%     Message-ID:  <[email-masked]>
% 
% 
% I agree with everything you say except this ...
% 
%   | 	EUI-64 based numbers really have no place in IPv6
%   | 	addresses, except as a local optimization. Use of 
%   | 	EUI-64 addresses introduces privacy concerns that
%   | 	require the invention of grevious hacks to address
%   | 	mgmt.
% 
% There are two different privacy concerns - one is that people can tell
% which brand of LAN cards I am using (or the manufacturer of some other
% equipment).   For the vast majority of people, "big deal".   There may
% be a few organisations that actually care about this, but they can simply
% assign addresses 1 2 3 4 ... if they want to, and completely avoid that
% concern.

	Yes.

% The other is "user tracing" and what matters there is whether there is
% a unique addr that comes at least fairly close to identifying a user.
% For this it doesn't matter in the slightest if the address is based upon
% an EUI or not, all that matters is that it is stable.   People have been
% used to hiding behind NATs which conceal their real addresses, and make
% them be just "one of many" using anything from the same addr block.
% Now global addresses are becoming available again, this concern is
% becoming more prevalent (it never used to bother anyone, as in the
% early days there was essentially no-one on the net who would collect this
% kind of info and misuse it - besides the fact that most systems (and
% addresses) were home for large numbers of individuals anyway).
% 
% The "grevious hacks" are only needed to cope with the 2nd of those, the
% first has a much more trivial solution.   And the 2nd is completely unrelated
% to the use of EUI's.   So, I don't think it is correct to blame privacy
% problems in any way on the use of EUI's for autoconfig.

	Well... there was a whole privacy issue raised and to such
	a degree that the IAB felt compelled to make a public statement
	about it.  And there is the goofy DNS abomination that attempts
	to randomize the lower 64 bits on a regular basis... to provide
	anonymity.                   

	In any case, the whole issue "goes away" if/when we rethink
	placing node identity information in a topological address.
	To the extent that EUI-64 numbers represent node identity
	and not topological information, it is, IMHO, a bad thing
	and should be excised from an addressing architecture, except
	as a foot-note for some special case events.

% 
% kre
% 
% 
%

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 16:55:10 +0700

Date:        Mon, 05 Aug 2002 09:59:13 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | >I'm not sure about the architecture, but the use of 'u' for autoconfig
  | >needs to be somewhere, that's just fine as it is now.
  | 
  | When you say that we need the 'u'-bit for autoconfig, do you just mean
  | that we should continue to reverse this bit in the EUI-64 identifier 
  | before we use it, to remain consistent with current practice?

No, not just that, though that should remain of course.

  | Or are you saying that the semantics of the 'u'-bit (that it indicates
  | an IID is globally unique) has some importance for autoconfig?

Not for autoconfig itself, but for manual config.   Or perhaps for manual
config to be able to cooperate with autoconfig.  It is nice to be
able to manually config some nodes on a link, and autoconfig others,
and not need to worry whether the manually assigned address just might
possibly conflict with some node's (perhaps node yet to be acquired)
ability to autoconfig its natural address.

Dividing the available space into two pieces, one for autoconf to use, and
one for the various other assignment types (manual config, dhcp, etc) avoids
this, so this use of the 'u' bit should be retained.

When we encounter some new media type, for which we don't yet have an
"IPv6 over foo" spec, we could pick a different bit to serve this purpose
though, if we wanted to make it quite clear that nodes off the link simply
cannot attempt to interpret this bit (which they should not be doing).

Side note: this looks as if autoconfig is being given a special status not
available to the other config methods, in that it has a reserved part of
the iid space, and all the rest get to share what is left over.   But that's
not the case.  What matters here is where the address assignments are done.
For autoconfig, that's in every node, using manufacturer code alone,
following the procedures of the rfc (and usually nothing else).   All other
assignments follow some site addressing plan, if some site wants to use
the 'g' bit (or any other bit) to distinguish between dhcp assigned addresses
and manually configured addresses, they can do that - all that's needed is
for their dhcp server to co-operate.  Nothing is required that touches more
than the internal config of that site, so there is nothing we need to
standardise here.

  | In the Yokohama meeting, Steve Deering lead a discussion on the
  | uniqueness of IIDs, and there was a pretty big majority of people
  | in the room who thought that we shouldn't even require IIDs to 
  | be unique on a link.  Addresses need to be unique (obviously), but
  | not necessarily the IIDs from which they are created.  The discussion
  | will be documented in the minutes, and we'll offer a chance for people
  | on the list to comment before we make any final decision, of course.

I know that was directed at the rest of the list (I was there, and absolutely
agree with this decision).  It has been discussed a bit on the list since
the WG meeting (it is the one topic from the meeting which really has).

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 16:59:09 +0700

Date:        Mon, 5 Aug 2002 11:32:34 -0700 (PDT)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	In any case, the whole issue "goes away" if/when we rethink
  | 	placing node identity information in a topological address.
  | 	To the extent that EUI-64 numbers represent node identity
  | 	and not topological information, it is, IMHO, a bad thing
  | 	and should be excised from an addressing architecture, except
  | 	as a foot-note for some special case events.

No, this is wrong.   The privacy concern comes with having anything
stable in the address which identifies the user - including the whole
address.   EUI-64's in there are just one way of achieving that
(which would perhaps be a little more stable than 128 bit addresses,
given that renumbering is supposed to happen - or perhaps not, as we're
already seeing people who have decided that renumbering is simply impossible
for them, and will never happen, no matter what...)

The numbers 1 2 3 represent node identity in exactly the same way as
EUI-64's do, putting the EUI there instead of '1' changes just about
nothing at all wrt this concern.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 16:55:10 +0700

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 07 Aug 2002 09:37:33 -0400

Having made the mistake of jumping into this swamp, I guess I'll keep
swimming...

But, first let me point out, as a WG chair, that the addressing architecture
is a WG document with a long history of compromise and consensus.  No significant
changes will (or should) be made to the addressing architecture based on my 
personal opinions, even if a few other people agree with me.  It would require 
a consensus of the WG to change the addressing architecture in the ways that 
I have suggested.  We have discussed these things before (on the mailing list 
and in person) and, so far, there has been no WG consensus to make these sorts
of changes.

Now, back to my individual thoughts...

>ability to autoconfig its natural address.

But, the semantics of the 'u' bit don't provide this...

The 'u' bit indicates that a particular IID has been generated from a
globally unique EUI-64 identifier.  Addresses that are generated from
other sources -- non-globally unique EUI-64s, serial numbers, random
numbers, etc. will not have the 'u' bit set.  So, it can't really be
used to distinguish autoconfigured addresses from manually configured
addresses -- it is used to distinguish IIDs that are (or should be)
globally unique from IIDs that may not be globally unique.

This is a holdover from the 8+8/GRE discussions that we had a few
years back involving the potential benefits of separating identification
information (the IID) from topological routing information (the prefix).
Currently, IP addresses are overloaded to contain both types of 
information.  

For a large number of documented reasons, we chose not to pursue the
8+8/GRE mechanism.  But there were a substantial number of people
(I was one of them) who thought that it was important to maintain the 
global uniqueness of the IID, so that we might later be able to pursue 
such a mechanism.  So, we decided that the lower 64-bits of an IPv6 should 
always be a globally unique EUI-64 identifier.  Not much later, due to 
the fact that not all systems have EUI-64 identifiers and rising concerns 
about privacy issues, we backed off of this position and decided to use 
the 'u' bit to distinguish between globally unique IIDs and non-globally-
unique IIDs.  And, there we stand today...

Personally, I think that it is highly unlikely that there will be any
benefits to being able to separate the identification and topological
routing information for _some_ hosts.  So, I believe that we eliminated
the ability to implement 8+8/GRE-like mechanisms altogether when we decided 
to use the 'u' bit to distinguish between the IIDs that were globally 
unique and those that were not.  I argued this at the time, but there
was clear WG consensus to use the 'u' bit.

I have been told, though, that there are still a significant number of 
people who believe that the 'u' bit should be maintained for later use
in a system that separates ID and routing goop (as it was called in
GRE).  These people were reportedly willing to accept the compromise
of splitting the address space into two portions (via the 'u' bit),
one that would have unique IIDs and one that would not.  If there are
folks who still believe that this is a valuable property, could you
please speak up in support of it, and explain why?

At that time, it didn't seem like a big issue to add a hard /64 
boundary into the IPv6 address, because we already had several 
hard boundaries in our addresses to provide separate fields for
aggregation (the TLA/SLA stuff).  Since then, we have removed the
other hard boundaries and moved to a CIDR-like address structure,
but we have maintained the hard /64 boundary, and required Modfied
EUI-64 IIDs for all global unicast addresses.

There are some major advantages to retaining this hard /64 boundary:

         - It makes autoconfiguration simpler, since all prefixes are
                 /64s and all IIDs are 64-bits long.  It would require
                 major, and inadvisable, changes to autoconfiguration to
                 allow autoconfiguration using prefixes longer than /64.

         - Memory systems and processors are much better at dealing with
                 64-bit values than they are at dealing with longer 
                 values.  So, the fact that most prefixes in the routing
                 system will be 64-bits or shorter should allow IPv6
                 routers to perform better than they could if longer
                 prefixes were commonly used.

But, what I think this WG needs to think about and understand is _why_
operators are using longer prefixes on their router-to-router links.
Is this just because that's how it has always been done?  Or are there
real technical reasons for preferring to use longer prefixes in that
case?  There are two reasons sited in the /127 draft (see subject):

         - A router can easily know the address of the router
                 on the other end of the link...  What is this
                 used for?  How valuable is this?

         - /127 prefixes ping-pong attacks that were possible with
                 older versions of ICMP.  These problems were 
                 fixed in ICMPv3, though, so is this really likely
                 to be a problem for deployed IPv6 routers?

If there are sound reasons to use longer prefixes in some cases, we 
may not want to have an addressing architecture that forbids it.  But,
I haven't seen anyone speak up with those reasons.

Going once...

Margaret

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 7 Aug 2002 08:51:37 -0500

The year is 2002, are you up to date on how 2002 addressing and 128-bit DNS works ?

Feel free to stop by .MARS, if you need an update....
http://www.ActiveWorlds.com

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
4:11 MARS

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Aug 2002 08:58:58 -0700

> ability to autoconfig its natural address.

the subject of this draft is point to point links

randy

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 07 Aug 2002 13:19:44 -0400

>the subject of this draft is point to point links

Exactly.  So, let me re-iterate something from my last message,
in case folks didn't read that far:

"But, what I think this WG needs to think about and understand is _why_

If there are sound reasons to use longer prefixes in some cases, we 
may not want to have an addressing architecture that forbids it."

Would folks who are using these longer links speak up and explain
why?  Are there significant problems caused by using /64 prefixes
that are solved by using longer prefixes?

Thanks,
Margaret

---

From: Bill Manning <[email-masked]>
Date: Wed, 7 Aug 2002 10:29:23 -0700 (PDT)

% There are some major advantages to retaining this hard /64 boundary:
% 
%          - It makes autoconfiguration simpler, since all prefixes are
%                  /64s and all IIDs are 64-bits long.  It would require
%                  major, and inadvisable, changes to autoconfiguration to
%                  allow autoconfiguration using prefixes longer than /64.
% 
%          - Memory systems and processors are much better at dealing with
%                  64-bit values than they are at dealing with longer 
%                  values.  So, the fact that most prefixes in the routing
%                  system will be 64-bits or shorter should allow IPv6
%                  routers to perform better than they could if longer
%                  prefixes were commonly used.

	If these arguments were not valid when selecting 128bit addresses
	then -WHY- would they be valid now?  Why did IPv6 not select 64bit
	addresses?

% If there are sound reasons to use longer prefixes in some cases, we 
% may not want to have an addressing architecture that forbids it.  But,
% I haven't seen anyone speak up with those reasons.

	CIDR.  address conservation.   Just because it looks like
	an in-exaustable greenfield, does not make it so. We -WILL-
	run out at some point.  

--bill
	(who is tilting at windmills at this point)

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 7 Aug 2002 10:50:18 -1000 (HST)

> that are solved by using longer prefixes?

- At any particular site, it makes it easy to notice that an address is a
link address if they're confined to a single pre-selected subnet.

- Simple conservation principle - ie. why is it necessary to use a whole
/64 just for a single point to point link?  What specific advantage or
capability do you gain on a point to point link by using something longer
than a /127 or /126?  And if that capability isn't needed or deemed
important, why waste?

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 11 Aug 2002 00:14:33 -0500

From: "Robert Elz" <[email-masked]>
> Now however, we know how much benefit there is to claim lots of address
> space as early as possible, and then to dig in

Is that like claiming TLDs ?....and not giving them up ?

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 10, 2002 6:18 AM
Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt 

>     Date:        Wed, 07 Aug 2002 09:37:33 -0400
>     Message-ID:  <[email-masked]>
> 
>   | No significant changes will (or should) be made to the addressing
>   | architecture based on my personal opinions, even if a few other people
>   | agree with me.
> 
> Of course not.    But it would be interesting to actually hear something
> from those who don't, with some kind of reasoning, rather than just
> assuming that they exist, which seems to be the current state of affairs.
> 
>   | It would require a consensus of the WG to change the addressing
>   | architecture in the ways that I have suggested.
> 
> Of course.   But no greater consensus than that required to make the
> other two changes that Bob Hinden just proposed (based upon the Yokohama
> discussions).   There's nothing magic about this draft, we can change it.
> 
>   | We have discussed these things before (on the mailing list and in person)
>   | and, so far, there has been no WG consensus to make these sorts
>   | of changes.
> 
> No, but so far I have also failed to see any convincing (or even arguable)
> reasons why the change should not be made.   To me, it is looking a lot
> like "I don't want to change it because I don't want to change it, but
> I won't say any more why not than that".   This isn't the way to technical
> excellence (and here, it isn't even if if a change is being proposed which
> would require changes to implementations, if anything, exactly the opposite,
> the change would align the doc with what is actually implemented and used).
> 
>   | But, the semantics of the 'u' bit don't provide this...
> 
> This is the theory, yes.   It isn't the practice however.
> 
>   | The 'u' bit indicates that a particular IID has been generated from a
>   | globally unique EUI-64 identifier.
> 
> And from where does a node determine that it has a globally unique EUI-64 ?
> 
>   | Addresses that are generated from
>   | other sources -- non-globally unique EUI-64s, serial numbers, random
>   | numbers, etc. will not have the 'u' bit set.
> 
> Not in practice.   In practice, any address generated from a MAC addr
> that has the 'u' bit clear will result in an IPv6 address with the 'u'
> bit set.
> 
> So, unless you're able to convince yourself somehow that a MAC address with
> the 'u' bit clear is necessarily globally unique, practice doesn't fit with
> the theory.
> 
>   | So, it can't really be used to distinguish autoconfigured addresses
>   | from manually configured addresses
> 
> No, and if you look, that's never what I said it was good for.   No-one
> should ever look at an address and attempt to interpret the 'u' bit to
> mean anything at all.
> 
> What it is useful for, is when I am autoconfiguring an address on a link,
> based upon the MAC address I am using on that link (which needs to be
> unique on the link for the link level to operate properly, on most of
> the links we're concerned with) then I set the 'u' bit, and when I am
> generating an address another way, I don't.   Then the autoconfigured
> address is much less likely to fail DAD any time when the link level is
> correctly functional.
> 
>   | -- it is used to distinguish IIDs that are (or should be)
>   | globally unique from IIDs that may not be globally unique.
> 
> That's the theory.   And it is unworkable.
> 
>   | This is a holdover from the 8+8/GRE discussions that we had a few
>   | years back
> 
> Yes, I know (or I surmised).   8+8 was discussed at some length,
> investigated, and discarded as unworkable.   But we kept this remnant...
> 
>   | But there were a substantial number of people
>   | (I was one of them) who thought that it was important to maintain the 
>   | global uniqueness of the IID, so that we might later be able to pursue 
>   | such a mechanism.
> 
> Then, if you're one of them (or even if you no longer are, perhaps you
> can recall your thinking at the time) perhaps you could explain how this
> could ever work?    That is, how any node could ever know when it should
> set the 'u' bit such that this other mechanism, if it is later invented,
> could actually rely upon it?
> 
> And is this more or less important than the ability to remain address
> stability when a MAC address changes (change of technology, replacement
> of broken hardware, etc) ?
> 
>   | So, we decided that the lower 64-bits of an IPv6 should 
>   | always be a globally unique EUI-64 identifier.
> 
> I don't think we ever decided that, or certainly not any time I was
> watching, as that never had a chance so ...
> 
>   | Not much later, due to the fact that [...]
> 
> I suspect this "not much" must have been measurable in milliseconds
> or smaller... (probably without overflowing a 16 bit counter).
> 
>   | not all systems have EUI-64 identifiers and rising concerns 
>   | about privacy issues, we backed off of this position and decided to use 
>   | the 'u' bit to distinguish between globally unique IIDs and non-globally-
>   | unique IIDs.  And, there we stand today...
> 
> Yes, this is the history as I remembered it as well (other than there
> ever being a time, the 8+8 proposal excepted, when we ever believed that
> we could have all addresses contain globally unique EUI-64's - but that
> detail doesn't matter at all now).
> 
> What you have described however is how we got ourselves into a messy state,
> but without any justification at all for keeping us there.
> 
> Probably it is unfair to expect you to do that, as you started this thread,
> this time, by proposing that all the mess be thrown away, which is something
> I totally agree with.
> 
> But perhaps someone should be able to get to the keyboard and give some
> kind of justification, other than history, for keeping it?
> 
> Or even, to explain what we have today that would break if we make the
> change?
> 
>   | Personally, I think that it is highly unlikely that there will be any
>   | benefits to being able to separate the identification and topological
>   | routing information for _some_ hosts.
> 
> I agree.   But even if there were, I can't see how we can ever, under
> any circumstances, actually implement the 'u' bit as it is currently
> defined, regardless of whether or not doing so would ever be useful.
> 
>   | So, I believe that we eliminated
>   | the ability to implement 8+8/GRE-like mechanisms altogether when we decided 
>   | to use the 'u' bit to distinguish between the IIDs that were globally 
>   | unique and those that were not.  I argued this at the time, but there
>   | was clear WG consensus to use the 'u' bit.
> 
> I recall agreeing that we should keep the 'u' bit for autoconfig
> purposes, so when we autoconfig things work easier.   That's just fine.
> I don't ever recall agreeing (or ever actually hearing any WG consensus)
> to treating the 'u' bit as meaning that one can assume the address
> contains a globally unique IID.   Perhaps this is a case where there
> was some confusion about what was actually being asked?
> 
> Perhaps someone who believes that the WG actually reached that consensus
> can point out where in the EG list archives it happened, so I can go back
> and review the issue?   It is kind of hard for me to do that alone, as
> I don't think it actually exists anywhere, in this particular form.  But
> it is very very hard to show that something doesn't exist, and quite easy
> to show that it does.
> 
>   | I have been told, though, that there are still a significant number of 
>   | people who believe that the 'u' bit should be maintained for later use
>   | in a system that separates ID and routing goop (as it was called in
>   | GRE).  These people were reportedly willing to accept the compromise
>   | of splitting the address space into two portions (via the 'u' bit),
>   | one that would have unique IIDs and one that would not.  If there are
>   | folks who still believe that this is a valuable property, could you
>   | please speak up in support of it, and explain why?
> 
> Yes, please, and also explain how it works!   (Not the as yet undefined
> mechanism, we can punt on that for now, just how the "I know when to set
> the 'u' bit" works for this purpose).
> 
>   | At that time, it didn't seem like a big issue to add a hard /64 
>   | boundary into the IPv6 address, because we already had several 
>   | hard boundaries in our addresses to provide separate fields for
>   | aggregation (the TLA/SLA stuff).
> 
> Well, some people thought that we did.   It was always quite clear
> though that all of the other boundaries were not going to last.
> Those ones had even less immediate relevance to anything than this
> one does, relating only to how addresses are assigned.
> 
> This one needs to go as well.    Which isn't to say that most links
> won't get 64 bit prefixes, we want to use autoconfig, and (for the
> links currently defined anyway) autoconfig requires 64 bits, which
> is just fine.   But no-one outside the link should be able to tell
> whether an address is one that was autoconfigured on an ethernet
> or whether it is one that was manually assigned on a p2p, or even if
> the same address is one thing one day, and the other the next.
> 
>   | There are some major advantages to retaining this hard /64 boundary:
>   | 
>   |          - It makes autoconfiguration simpler, since all prefixes are
>   |                  /64s and all IIDs are 64-bits long.
> 
> No, that's irrelevant.   We can keep the /64 for autoconfig purposes
> (which is what I have been proposing) while not requiring it as any
> kind of fundamental part of the architecture.
> 
>   | It would require
>   |                  major, and inadvisable, changes to autoconfiguration to
>   |                  allow autoconfiguration using prefixes longer than /64.
> 
> Not to autoconfig itself, it doesn't care - just to the currently defined
> mechanisms for autoconfig over X, for all the IEEE type links (and anything
> else we want to be compatible, so bridging can happen).   And no, there is
> no need at all to change that.
> 
> But for autoconfig to work on an ethernet (fddi, ...) doesn't require me
> to use a /64 for my p2p links (if you don't believe it, I can show you
> my configurations, where this stuff all works just fine).
> 
>   |          - Memory systems and processors are much better at dealing with
>   |                  64-bit values than they are at dealing with longer 
>   |                  values.
> 
> This is totally bogus.   Go back a few years and you'd put in "32"
> there just as accurately.
> 
> Routers need to be able to deal with 128 bit addresses in all instances,
> as they have to be able to cope with addresses on their directly attached
> links.  Those need /128's ...   A router that routed real fast when the
> destination is a long way away, and real slow, when it is nearby, would
> perhaps find some market share in the network backbones, but it is never
> going to be sold in the mass market.
> 
> Routers can and perhaps should optimise their routing tables so they
> only carry the required prefix lengths (though I suspect some of the
> ASIC people will now be jumping up and down and saying that is too
> hard, there's no need to reply, I understand) - but they cannot afford
> to assume that only the first 64 bits of addresses matter.  Ever.
> 
> But even if some router was to assume that, and actually find a market,
> all that would mean is that that router would need to be deployed in
> an environment where longer prefixes aren't visible.   Since I certainly
> don't expect any of you to ever see explicit routes to m /112 p2p links,
> you can deploy such routers if you want to, quite safely.   You just
> need to number your own p2p links using /64's and assume that aggregation
> will take care of everything else.
> 
>   | But, what I think this WG needs to think about and understand is _why_
>   | operators are using longer prefixes on their router-to-router links.
> 
> That might be reasonable.   But at the same time, operators might want to
> understand just why this WG thinks it needs to specify that all links be
> /64 ?
> 
> Part of the reason that any restriction gets ignored is when the people
> supposed to obey it don't understand why it is there, and see it as just
> an unnecessary interference with them doing what they want.
> 
>   | Is this just because that's how it has always been done?
> 
> I don't think so, but even if it were, surely we should require some
> kind of reasonable justification in order to change people's current
> operating methods?   We're not just making changes to make people have
> to change their ways, for our amusement, right?
> 
>   | Or are there
>   | real technical reasons for preferring to use longer prefixes in that
>   | case?  There are two reasons sited in the /127 draft (see subject):
>   | 
>   |          - A router can easily know the address of the router
>   |                  on the other end of the link...  What is this
>   |                  used for?  How valuable is this?
> 
> Not at all, that's nonsense.   If you know it is a /127 (or even probably
> a /126) then you can most probably predict the address of the other end,
> but there's essentially no point in that (very little benefit) and what
> benefit there is is mostly for the human operator (easier to work out the
> ping address).   That's just as easy using /64's (or /112's) and using a
> consistent numbering scheme though (<whatever>::1 and <whatever>::2 or
> something).
> 
> This might explain why some people do it, but it isn't a rational reason.
> 
>   |          - /127 prefixes ping-pong attacks that were possible with
>   |                  older versions of ICMP.  These problems were 
>   |                  fixed in ICMPv3, though, so is this really likely
>   |                  to be a problem for deployed IPv6 routers?
> 
> I doubt it.
> 
>   | If there are sound reasons to use longer prefixes in some cases, we 
>   | may not want to have an addressing architecture that forbids it.  But,
>   | I haven't seen anyone speak up with those reasons.
> 
> There isn't enough address space.
> 
> The University of Melbourne has an IPv6 address plan (or a preliminary
> one anyway, given that I'm the only user there I know of at the minute,
> and I'm no-where near there just now, but anyway...).  My dept (Comp
> Sci & Software Eng) has been allocated 192 SLAs to use.   That's
> generous compared with out allocation of IPv4 addresses of course (we
> have about 16 /24's, that we use mostly as /26's).
> 
> [Aside, 3 blocks of 64 /64's, with usage of nets in each
> block constrained to particular purposes, so the people who
> insist on filtering can apply consistent rules to whole large
> blocks of address space throughout the campus, rather than
> having to know the purpose of every individual net - that is,
> nets that serve open student labs get different access than
> nets that serve staff workstations, and those are different again
> from infrastructure nets (servers, and such)].
> 
> But if I have to number all my p2p links out of that space, and I have
> to allocate /64's to every P2P, then those 192 are all gone long before
> I start numbering anything other than P2P links (we have about 300 p2p
> links to number I think - those fit in the IPv4 space real easily, as
> they're almost all /32's (a few /29's), and fit easily in 2 of the /24's
> that we have, leaving the other 14 /24's to number 56 ethernets and such,
> which is just about what we need.
> 
> Perhaps this is because we're one of those organisations that is in some
> ways like an ISP (and on the 6bone list I think it was, ISP types were just
> saying "allocate a /48 to use for all your P2P links" ... if I could do that
> there would be no issue, but I cannot).   Personally I don't think that's
> rational address conservation for ISPs either - just because they get a /32
> of which a /48 is just a small piece, doesn't mean that the /48 should
> be thrown away on a few dozen (or hundred) links, with 2 nodes on each.
> 
> Of course, in other ways we're not an ISP, we have no customers (or not
> for networking services anyway) just lots of users who connect in all kinds
> of ways.
> 
> Please, everyone, remember that when ever anything is exhaustible, the
> time to conserve it is when it is plentiful, or appears that way.   Then
> conservation is usually quite easy.   Once a shortage starts to manifest
> itself (in anything from whales, to rain forests, to IP addresses) attempting
> to rebuild the resource gets very very hard (and also tends to get very
> unfair, as there's usually no way to reclaim what has already been wasted,
> only to limit further consumption - which means those who get in early
> and waste as much as they can, can end up having major advantages forever
> over those who do not).
> 
> Just look at IPv4 if evidence is needed.  And remember that we're looking
> back at that with the benefit of hindsight.  At the time people using class A
> address spaces for (relatively) small organisations didn't think they were
> wasting addresses, or getting some benefit over those who came later, it
> was just the way things were done.
> 
> Now however, we know how much benefit there is to claim lots of address
> space as early as possible, and then to dig in and claim "we can never give
> this back or renumber, it has to be ours forever" (as one IPv6 operator
> has already started doing - this isn't imagination).
> 
> Let's not be overawed by the size of 2^128 and assume it can never run out.
> It can, and will, if not managed sensibly.   On the other hand, it is a
> very big number, and even with H ratios, or H factors, or whatever they're
> called this week, there should be plenty of address space there forever.
> Provided that we don't start wasting it.
> 
> Requiring (not just permitting, but actually requiring) that a link that
> can never have more than 2 attachment points be allocated 2^64 addresses
> is sending a pretty big sign to everyone that address conservation is
> irrelevant.   That's a very very poor message to send.
> 
> kre
> 
> ps: apologies for the lengths of these two messages, comes from having had
> a few days away from the net, and coming back to see this issue still being
> discussed, but not advanced at all - that is, all the arguments given are
> going one way, but there is apparently still no consensus, because there's
> either off list discussion (which should count for nothing at all), or
> people are just assuming that there is some disagreement, where none is
> actually being stated.
>

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Aug 2002 18:18:39 +0700

| It would require

  | Or are there

I doubt it.

kre

---

From: Thomas Narten <[email-masked]>
Date: Mon, 12 Aug 2002 15:32:56 -0400

Personally, I am not in favor of taking out the /64 boundary. The main
reason is that I do not see signficant benefits from doing so, but I
do see negative consequences from revisiting the boundary. At a
minimum, the discussion leading to this kind of change is likely to be
divisive, and I don't see that as being particularly good way to focus
this WG's cycles.

Personally, I believe it is potentially useful to have 64-bit
interface identifiers in all addresses.  They *could* have properties
associated with them, but that is mostly future work. No need to close
the door prematurely.  (Note: the reason the current requirement for
IIDs on all addresses except those with prefix 000 has to do with that
000 addresses are reserved for things that might well conflict with
interface identifiers, such as IPv4-compatable addresses).

Regarding kre's argument that globally-unique IIDs are useless and
should therefore be abolished, my feeling is different.  First, no one
can (or is) credibly arguing that if the u bit is set a certain way,
the interface ID is *guaranteed* to be globally unique. (Kre seems to
assume this argument as a strawman.) However, if the u bit is set a
certain way, implementations could take that as a hint that the IID is
*probably* unique (or supposed to be unique), and in the case that it
really cares, it could take additional steps to verify uniqueness and
then use addresses with that property in a possibly different way. No
one is doing that today (and I'm not advocating that they do either).
However, it *might* be useful to be able to do so in the
future. Whether it would be worth the effort to do the check, or what
the check would be, is future work that would be done in conjunction
with a proposal for how to take advantage of unique IIDs.

Now, normally, I tend to resist putting in hooks that *might* be used
in the future, because our track record of predicting what hooks will
be needed (and getting them right) is generally rather poor. In this
case, however, I believe a *lot* of people (and in particular, people
mostly not in the IPv6 WG) feel pretty strongly that something like
8+8/GSE should be pursued. The current Interface ID we have leaves
that door somewhat open, should a proposal come forward that the
community believes can be made to work. Closing that door would likely
be viewed as a slap-in-the face to those who want the door left open,
and will do little to build support for IPv6 among those folk. I don't
see what would be gained by doing this (rather, I see only
negatives). 

More recently, there has been a proposal (though not particularly well
received by this list) to perhaps allow other different types of
indentifiers. For example, there is promising work going in with
regards to embedding (parts of) public keys (or the signature of a
public key) into an interface identifier in order to allow a node to
"prove" it "owns" a particlar address/identifier. I'm not sure how (or
if) that work will gain much traction, but again, I think it would be
a mistake to close that door prematurely, because it *might* be a
useful approach to solving a rather hard problem for which few options
seem to be available.

Getting back to the observation that some in the community are
assigning /127s to the p2p links, this by itself does not imply that
the interface identifier concept is inherently broken and should be
removed from addrarch. Even if many operators turn out in fact to
number all their p2p links this way, this will be an extremely small
fraction of the total number of addressable end nodes. Thus, in
practice, enough end nodes may be using  64-bit IIDs in order for the
uniquness properties (as described above) to be useful enough to take
advatange of. Obviously, those nodes that don't follow  the scheme
wouldn't be able to take advatange, but that may not  matter. Future
work can figure that out. 

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 12 Aug 2002 15:34:04 -0400

>                  allow autoconfiguration using prefixes longer than /64.

It's more than just autoconfig. Right now, End sites can expect to get
a /48, and they get use the 16 bits between a /48 and /64 anyway they
care. If a site switches providers, it knows it will get 16 bits
again, and it konws that it needs to (only) renumber the upper 48
bits. This is both simple and powerful.

This comes in large part from the uniform /64 boundary between the
adddress and the IID. If that were removed, it would potentially
reopen discussion about which bits and end site should get for subnet
addressing, with different people possibly being given different
ranges and (even worse) different amounts. I think this would be a bad
direction for us to go in. I don't see what the benefit would be, but
I can surely see a number of non-productive areas we'd surely rathole
on.

> operators are using longer prefixes on their router-to-router links.

This is a key question. Just because operators are doing this, doesn't
mean they should or that we should just give in and say "I guess we
should give in to reality". There is a cost/benefit of sticking with
the /64 boundary. Before moving away from it, we really need to
understand the cost/benefit of the alternative.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 12 Aug 2002 15:43:06 -0400

> 	an in-exaustable greenfield, does not make it so. We -WILL-

Presumably you have read RFC 3177. Nobody disputes that we will
someday run out even of IPv6 addresses. But most believe that we have
enough addresses that even if we give out lots of /48s and /64s, we
aren't going to run out of addresses quickly enough to worry about
this. So the idea that we need to number p2p links with longer
prefixes in order to conserve addresses seems pretty silly to
me. There will be very few p2p links in practice compared to end sites
(which will need at least a /64 in order to do stateless addrconf).

Thus, my read of your comment is that your real disagreement is with
the overall /64 boundary and that you would like us to revisit a
number of basic decisions with the ultimate goal of giving end sites
not a /48 or /64, but something much longer.

Or am I misreading your words?

Thomas

---

From: Bill Manning <[email-masked]>
Date: Mon, 12 Aug 2002 13:14:07 -0700 (PDT)

% Thus, my read of your comment is that your real disagreement is with
% the overall /64 boundary and that you would like us to revisit a
% number of basic decisions with the ultimate goal of giving end sites
% not a /48 or /64, but something much longer.
% 
% Or am I misreading your words?

	I am in favor of delegating -only- the space needed.
	I am more concerned with a hard boundary being set,
	perpetuating the fiction that the address identifies 
	the node, not where it is in the topology.  Mixing
	these two properties has been a problem for some time.
	IPv6 was a chance to divorce the two.  I am afraid that
	this is a lost opportunity.

% Thomas

--bill

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 12 Aug 2002 14:39:29 -0700

Margaret Wasserman wrote:
> ...
> In the Yokohama meeting, Steve Deering lead a discussion on 
> the uniqueness of IIDs, and there was a pretty big majority 
> of people in the room who thought that we shouldn't even 
> require IIDs to 
> be unique on a link.  

But nobody asked how many of that majority had any clue about actually
operating a network. The question was should we allow flexibility, and
completely ignored the confusion that will be caused trying to explain
to first line operators that on subnet A all addresses with the same IID
map to a single node, but on subnet B they don't. They are going to have
a hard enough time with multiple addresses per node, we should not be
making it more complex by allowing shared IIDs on a link.

Tony

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 20:48:44 +0700

Date:        Mon, 12 Aug 2002 15:32:56 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | Personally, I am not in favor of taking out the /64 boundary. The main
  | reason is that I do not see signficant benefits from doing so, but I
  | do see negative consequences from revisiting the boundary. At a
  | minimum, the discussion leading to this kind of change is likely to be
  | divisive, and I don't see that as being particularly good way to focus
  | this WG's cycles.

It would be nice to see any technical arguments at all.  If we ever end
up starting something that looks like a long drawn out argument, with
people making technical points in different directions, then I'll gladly
go away, and the status quo can remain.   The problem is that I am seeing
none of them.

  | Personally, I believe it is potentially useful to have 64-bit
  | interface identifiers in all addresses.

Can you even hint at something where that potential could be realised?

  | They *could* have properties associated with them,
  | but that is mostly future work.

And mostly this WG has tended to refuse to allow anything which is
just for future potential benefit.  The only major one that has been
allowed has been the flow id header field - and apart from the fact that
there the possible uses can be seen (though no-one is yet sure they'll
be realised) - and in any case, I suspect that no-one is really sure what
would be done with those 20 bits should the field be removed, they can't
just vanish.

I have never agreed with eliminating all that is just potential,
but I would like to see at least a suggestion of what it might be
useful for.   I mean, how do we know now that we don't really need 72
bit interface identifiers if they're to have some other purpose?

  | No need to close the door prematurely.

I believe the door is already closed.   That is, this part of the spec
isn't obeyed at all, anywhere.   Even if you could find a use, it is
simply too late now.

  | (Note: the reason the current requirement for
  | IIDs on all addresses except those with prefix 000 has to do with that
  | 000 addresses are reserved for things that might well conflict with
  | interface identifiers, such as IPv4-compatable addresses).

Yes, of course.   But one might wonder if those can manage to survive
without this feature (as do multicast addresses) then how important is
it ever going to be, how important can it ever be?

  | Regarding kre's argument that globally-unique IIDs are useless and
  | should therefore be abolished,

That was never my argument.   If we could have the things, I'd love it.
The argument is that they're unimplementable, not that they wouldn't be
useful if they existed.

  | First, no one
  | can (or is) credibly arguing that if the u bit is set a certain way,
  | the interface ID is *guaranteed* to be globally unique.

That's OK - the question is how one uses an ID which we know might not
be unique?

  | (Kre seems to assume this argument as a strawman.)

Not quite.   I assume that any user of the ID is either going to assume
that, or that they're going to have to be able to deal with ID's that
aren't unique.   If the former, then I agree with you, that's not credible.
If the latter, then why should we care about the 'u' bit for this purpose?
All IDs would be potentially non-unique, the user has to deal.

Personally, I think it is simply wrong to try and extract the ID out
of the address and do anything with it at all - keep the prefix and then
you do have something unique.   Seems a much simpler solution to me.

  | However, if the u bit is set a
  | certain way, implementations could take that as a hint that the IID is
  | *probably* unique (or supposed to be unique), and in the case that it
  | really cares, it could take additional steps to verify uniqueness

Oh good.  What are those steps?   This is really the crux of the matter.
If there's some way you can actually discover that it is unique, then
the whole thing might have some point.   But please do explain the magic
by which this is accomplished.

  | Now, normally, I tend to resist putting in hooks that *might* be used
  | in the future, because our track record of predicting what hooks will
  | be needed (and getting them right) is generally rather poor.

yes, lots of people seem to agree, and that has been the general WG
approach, most of the time.   It is ironic, that we appear to disagree
on that in general (I am more open to star gazing than many, if the
cost is small, and there's a plausible potential use, then why not?)
but on this issue we're each adopting the opposite (me, because I
don't believe there's even a remote sniff of a chance this can ever
be useful).

  | In this
  | case, however, I believe a *lot* of people (and in particular, people
  | mostly not in the IPv6 WG) feel pretty strongly that something like
  | 8+8/GSE should be pursued.

Hmm ... on this same topic, I'm being told "we had that argument, it was
lost, give up and accept it", get apparently for 8+8 it is OK to keep
things in preparation for it to resurface in the future, even though it
has been analysed into total obscurity.

It is an idea that sounds great, but without some way to actually guarantee
the uniqueness, fails completely.

Why are we leaving open the possibility of revisiting that, but not
wanting to revisit anything else?

  | The current Interface ID we have leaves
  | that door somewhat open, should a proposal come forward that the
  | community believes can be made to work. Closing that door would likely
  | be viewed as a slap-in-the face to those who want the door left open,

Huh?   You mean we're ignoring the technical arguments, and making decisions
in order to allow people to keep on dreaming?

  | and will do little to build support for IPv6 among those folk.

Does it matter?    Perhaps there was a time when IPv6 needed support
building, but hasn't it become evident to you yet that time passed?
Maybe in the US where address shortages have never been as severe, it
is taking longer than everywhere else, I don't know - but really now,
it is too late to deny IPv6 any more, it has already happened.

  | More recently, there has been a proposal (though not particularly well
  | received by this list) to perhaps allow other different types of
  | indentifiers. For example, there is promising work going in with
  | regards to embedding (parts of) public keys (or the signature of a
  | public key) into an interface identifier in order to allow a node to
  | "prove" it "owns" a particlar address/identifier. I'm not sure how (or
  | if) that work will gain much traction, but again, I think it would be
  | a mistake to close that door prematurely, because it *might* be a
  | useful approach to solving a rather hard problem for which few options
  | seem to be available.

What exactly do you thing is being proposed that would prevent any of that?
If anything, removing 'u' can only help, as the way we have things now, we
have one bit an an unusual position in the IID that has supposed fixed
semantics, anyone else proposing new kinds of IID has to work around that.
If we simply had 64 bits of IID available, then all of that should be
easier, right?

  | Getting back to the observation that some in the community are
  | assigning /127s to the p2p links, this by itself does not imply that
  | the interface identifier concept is inherently broken and should be
  | removed from addrarch.

It, by itself, means that the restriction that addrarch makes that all
IIDs (0::/3 excepted) are 64 bits is not implemented.   Combine that
with the words in 2026, and you see why it has to be removed.

  | Even if many operators turn out in fact to
  | number all their p2p links this way, this will be an extremely small
  | fraction of the total number of addressable end nodes. Thus, in
  | practice, enough end nodes may be using  64-bit IIDs in order for the
  | uniquness properties (as described above) to be useful enough to take
  | advatange of.

Only if you can actually define them.   You also neglect dhcp - it isn't
yet clear in (larger) ipv6 nets whether autoconfig will be used mostly,
or whether dhcp will be (partly because dhcpv6 is only just finishing, so
there have been no users to date).    There's nothing here beyond speculation.

  | Obviously, those nodes that don't follow  the scheme
  | wouldn't be able to take advatange, but that may not  matter. Future
  | work can figure that out. 

It isn't the nodes that follow, or don't, the scheme that matter,  It is
what all the other nodes which assume u==1 means globally unique do,
when they start getting lots of addresses with u==1 which don't have
globally unique iids.   That's what you have to work out how to deal with
before you can think about any potential use of all of this.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 20:58:26 +0700

Date:        Mon, 12 Aug 2002 15:34:04 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | It's more than just autoconfig. Right now, End sites can expect to get
  | a /48, and they get use the 16 bits between a /48 and /64 anyway they
  | care. If a site switches providers, it knows it will get 16 bits
  | again, and it konws that it needs to (only) renumber the upper 48
  | bits. This is both simple and powerful.

Yes, it is.   But it is the /48 which is the crucial number there.
Not /64 - that one is irrelevant.

  | This comes in large part from the uniform /64 boundary between the
  | adddress and the IID.

no it doesn't.   The only influence that had was on the value "48".
The need for some nice fixed boundary for the purpose you elucidate
is the driver for the fixed "48".   If it weren't for that (and the
way the earlier argument went) we'd be allocating /56's to small
organisations - not because the /64 could be moved, but because 8
bits of subnet (an old class B remember) is enough for many organisations.

  | If that were removed, it would potentially
  | reopen discussion about which bits and end site should get for subnet
  | addressing, with different people possibly being given different
  | ranges and (even worse) different amounts.

no it wouldn't.   No-one is even contemplating removing the /64 from
being required for autoconfig on an ethernet (and other LANs).   That
means that all a site is ever going to need to do is say "I want to
use 802.x" (for any x > 2) and then they need /64 for that.   Then,
nothing here is influencing the expectation of 16 bit SLA space.  So,
there's no way that argument could happen again.

  | I think this would be a bad
  | direction for us to go in. I don't see what the benefit would be, but
  | I can surely see a number of non-productive areas we'd surely rathole
  | on.

Sure, but no-one is suggesting that, so why waste time arguing against it?

  | This is a key question. Just because operators are doing this, doesn't
  | mean they should or that we should just give in and say "I guess we
  | should give in to reality".

No.   But unless you're planning on rewriting 2026 before this gets
advanced to DS, don't you think you could at least pretend that you're
going to do what it requires?

Features that aren't implemented must be removed from the spec.

It really is very simple.

If you (the whole WG) like, that can get put in some other doc as a
new PS, that can just sit in PS status, until you can actually find
implementations of it ...

  | There is a cost/benefit of sticking with
  | the /64 boundary. Before moving away from it, we really need to
  | understand the cost/benefit of the alternative.

The major benefit is that we avoid people pretending they're able to
look inside my addresses and deduce meaning there - and then complain
that I'm not obeying some standard when they're wrong.   The cost?
Well, I'm having a hard time finding one at all, or a measurable one
anyway.

kre