Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt

From: Tim Hartrick <[email-masked]>
Date: Mon, 12 Aug 2002 13:12:50 -0700 (PDT)

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-masked]
--------------------------------------------------------------------

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 13 Aug 2002 00:54:52 +0200

> > fraction of the total number of addressable end nodes. Thus, in
<SNIP>
> 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.

The only reason that we use a /127 at IPng.nl is because those tunnels
aren't going to be native links ever.
For links that could once be turned over to native links one should use
a /64, and using /64 for these people
is simply a waste of space even if there is enough.
Same that we give out /60's, most people behind cable modems don't even
have more than 1 subnet and
the project is for learning. On a side note we picked /127 & /60's
before the other drafts where there ;)
Also the SixXS project is going to advise /64's on tunnels and /48's as
subnet blocks, though that all depends
on the TLA's policy ofcourse.. it's their space in that case ;)

As for my opinion on /64's per link and maybe making them smaller....
why should one.. this works perfectly.
Ofcourse one could also opt for a:
 - pick random hostprefix of n bits (eg.. if you get a /100 from the RA,
one picks ::123)
 - check with ND if it is in use
 - use it.

But this is ugly, and if you once have a /80 and then go to a /100 you
will have problems renumbering.
As addresses will change in that case, now one can trust to have a /64
for each link.
And how one picks a hostprefix... EUI-64 works great, so why change it ?

Greets,
 Jeroen

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 21:37:28 +0700

Date:        Mon, 12 Aug 2002 13:12:50 -0700 (PDT)
    From:        Tim Hartrick <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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