Date: Mon, 12 Aug 2002 15:32:56 -0400
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
