Date: Mon, 12 Aug 2002 13:12:50 -0700 (PDT)
From: Tim Hartrick <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Simply because some operators use a /(n>64) for
| point to point links does not mean that all operators will or should do the
| same.
Nor is anyone suggesting that. The question isn't whether it
must be done that way, but whether anyone is to be permitted to.
| I believe, that it is a good thing that implementations allow this
| type of flexability but the existence of that flexability in implementations
| doesn't require that the specifications change in order to bless the
| assignment of /(n>64) prefixes to point to point links.
Actually, that's exactly what 2026 requires, when all of the implementations
are flexible.
| If there are implementations
| which "hard-code" the /64 boundary then so be it.
"If" yes, but I kind of suspect that if anyone had one, or had seen one,
they'd have spoken up by now.
| We have implementations of specifications which clearly work. Let's stop
| messing around with them and work on the things that are really critical to
| making IPv6 deployment possible. This isn't one of those things.
A better solution would be to stop discussing the change, and just do it.
| Aside: When the GSE discussion was going on N years ago, I was fore square
| against the /64 boundary for all the reasons that others have brought up in
| this latest thread. That is, the dubious basis for assuming that a globally
| unique identifier is possible, the address space waste. etc. I lost the
| argument. I can live with it. It sure would be nice if decisions made in
| this WG had a half-life of longer than four years.
I'd tend to agree with you - but we've just had Thomas claim that the reason
all this remains is so GSE can be revived, sometime in the future...
In this case however, this doc is being advanced to DS. That's when in the
process we're supposed to go back and review the doc, and make sure it
contains no rubbish that people are ignoring universally. That is, this
particular review is one we're supposed to make.
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]
--------------------------------------------------------------------
