Date: Wed, 7 Aug 2002 22:48:44 -0700
From: "Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| To be honest, I think it was about time that this issue came to a head.
| Because the issue is not about /127 prefixes, but it is about the
| reading of [addrarch] that says (or does not) that a prefix longer than
| /64 is not to be used for anycast addresses.
You mean unicast.
| Back to Pekka's draft: I think it would be fair to say that Pekka's
| draft is valid if [addrarch] is _not_ to be modified, and needs to be
| dumped if [addrarch] is to be modified.
Not dumped. Modified probably. That is, that we allow prefixes of
any length does not by itself mean that using /127 (which is what the
draft is arguing against) is rational. I'm not convinced it is
irrational (not as convinced as Pekka anyway) but on the other hand
I find it very hard to come up with any convincing reason for actually
using /127's. /112 allows me plenty of address space...
| In other words: I personally don't care about the 'u' bit, but now is
| not the time to close doors as long that big unknown about multihoming
| is not settled.
OK, since you're the first person (I have seen anyway) willing to actually
claim that this just potentially might be useful, please explain how
it can ever work.
Forget the multihoming use of the thing, just explain how your implementation
would ever set the 'u' bit in a way that you're able to guarantee (enough)
global uniqueness that multi-homing (or anything else) would ever be able
to rely upon it.
Knowing that it is possible to use the thing as proposed this way would
go a long way toward justifying retaining the 'u' bit as defined (and if
'u' is to be retained, then we need /64 as well, because of where the 'u'
bit is positioned - if we were doing this rationally, we'd have reordered
the bytes in the addresses, and made 'u' appear in the least significant
octet of addresses, rather than splat in the middle).
At least then we could have a reasoned cost benefit analysis. At the
minute I don't believe it is even possible to use the 'u' bit for this
kind of purpose, regardless of how attractive it might be to be able to
do it for some application or other.
| I hope you don't mind my bluntness, but you don't know yet; nobody does.
| Now is not the time to close doors.
Perhaps not (though this WG has been entirely willing to rule out all kinds
of other things for which an immediate application hasn't been shown).
But before we argue for leaving the door open, can we perhaps determine
whether or not it has already closed? (slammed and double locked...)
| Note about this: My reading is that there still is a semi-hard boundary
| at /48, (site) and I think this is good.
Please keep in mind what the boundaries are for. The /48 is an allocation
size (there are also /32 and /16 and /3 that apply in that realm).
That's all OK, those numbers can always be changed, almost without thought,
as nothing, other than the allocation system depends upon them.
We just tell the registries to allocate /32 instead of /35, and they
do that (maybe they argue a bit, or something, but this is all just
politics etc).
This is totally different from any boundaries in addresses that can be
observed or predicted by other nodes. That's the one we need to do
away with.
We're always going to have all kinds of allocation boundaries, we should
never have any boundaries that can be observed in someone else's addresses.
| Among many others, kre and I have debated over and over the issue. None
| of us is wrong, and none of us is right. Let's put an end to this and
| settle it. We have more important things to do.
That would be nice. Unfortunately, I dont think this is just a coin
toss issue - that is, one where a decision is needed, but any decision
will do. There actually is right and wrong here.
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]
--------------------------------------------------------------------
