All,
>
> 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.
>
I am agreement with all the points that Thomas makes. The point above
needs further emphasis. 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. 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. If there are implementations
which "hard-code" the /64 boundary then so be it. The marketplace will sort
out whether that is a good or bad thing.
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.
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.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
