Date: Wed, 07 Aug 2002 09:37:33 -0400
From: Margaret Wasserman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
