Subject: Re: IPv6 Addr/Prefix clarification

From: Robert Elz <[email-masked]>
Date: Fri, 01 Feb 2002 14:44:11 +0700

Date:        Thu, 31 Jan 2002 08:16:48 -0800
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | do we say:
  | 
  | 1. It is ok to use a /64 for loopbacks and point to point links in the
  | sake of simplicity.
  | 
  | 2. It is a waste to use a /64 for a loopback or a point-to-point link
  | and therefore we should subnet the IID.
  | 
  | My vote goes to 1.

Given those two questions, so would mine.   But those weren't the question,
which was more like

  | 3. Is it ok to use longer than a /64 for links ?

That is, the suggestion isn't to pressure people to use /126 or something
(as your #2 would do), nor to tell people that it isn't OK to use a /64
for that purpose, which denying your #1 would do.   But just to tell them that
it is OK to use a longer netmask if they want to (and in the appropriate
circumstances).

I'm going to ignore all the IPX analogies, I don't know enough about its
global hierarchically routed network to make any comments about how its
32 bits of network number are/were actually managed.

But:

  | There is nothing that forbids subneting into the IID

Good.  This is all I want to achieve.   Just keep it possible.   As long as
we don't start making it impossible, then all kinds of things remain as
options for the future (perhaps far future).

  | (although it would be difficult to subnet smaller than /80),

I find it almost impossible to work out where /80 comes from (unless you
mean to find a need to do so, in which case, then yes, I'd find that
pretty difficult too, though I prefer more often to have constant 0 bits
in higher order positions than lower ones, so I'd tend to make the mask
longer, and put 0's in the subnet section rather than shorter with 0's
in the host part - but that's just aesthetics).   But if there's something
supposedly magic about the last 48 bits (48 now is 100% irrelevant to
autoconf, so it cannot be that) it has escaped me.

  | but don't you think that, in the time being,
  | it would be wise to stick to /64 unless we have a hell of a
  | good reason?

If you mean for numbering my own net, then no, I will explicitly use longer
masks than that wherever it makes sense, just to push the technology and make
sure that it remains possible.

For giving advice to the population at large, I'd probably suggest using /64
for almost all nets, to lower the chances of running into limits in the
technology that shouldn't be there (but bugs exist everywhere).

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

---

From: Tomas Lund <[email-masked]>
Date: Fri, 1 Feb 2002 17:02:42 +0100 (CET)

> (as your #2 would do), nor to tell people that it isn't OK to use a /64

/127 seems alot better? Why waste 50%?

//tlund

---

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Feb 2002 18:50:26 +0200 (EET)

> /127 seems alot better? Why waste 50%?

/127 is wrong.  There was discussion on this last November.  I'll be 
sending short I-D on this to internet-drafts before Monday.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 1 Feb 2002 09:44:42 -0800

Robert Elz wrote:
> I find it almost impossible to work out where /80 comes from 
 
> ... But if there's something

EUI-48

Tony

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Feb 2002 16:05:41 +0700

Date:        Thu, 7 Feb 2002 17:14:50 -0800
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220806b888d5e04332@[171.71.118.51]>

  | There is yet another factor that limits the interface ID field to be no
  | less than 8 bits wide (i.e., no longer than a /120): RFC 2526 specifies
  | that the highest 127 interface ID values on each subnet are reserved for
  | well-known anycast addresses (as is the interface ID value zero).  You
  | need at least 8 bits to hold those 127+1 anycast addresses, in addition
  | to the minimum of 2 IDs needed for the two ends of a point-to-point link.

Yes, but just as with the subnet router anycast address, all these well
known anycast addresses are meaningless on a point to point link.

If the node sending the packet would bind one of those anycast addresses
to itself, then it doesn't need to use anycast to find the server, it is
the server, and no well known address is required.   Otherwise, the remote
node must be the server if there is one, and the remote node's unicast
address might just as well be used instead of an anycast address.

Since we're postulating a link with a subnet mask of indeterminate size
(perhaps no more than /120 - but certainly with the possibility of it
being longer than /64) there's no way for a remote node - one not
connected to the link - to calculate the anycast addresses, it would have
to be configured with the subnet mask (prefix length) for that to be
possible (since it isn't on the link, it cannot be seeing RAs to announce it).
If it is going to be configured (or look up in any kind of directory, DNS
included) with anything at all related to a specific link, must better to
just configure it with the unicast address to use, rather than a prefix /
prefix-length combination for it to use in building an anycast address.

Point to point links are just different than shared links - much of what is
required on a shared link for it to operate (especially without specific
configuration) simply isn't meaningful for a point to point link.   Defining
in an RFC that this should not be so doesn't make all that much tangible
difference...

Having said all that, and while retaining the firm belief that nothing we
do should prohibit anyone from using /127 on a p2p if that's their desire,
I'd also point out that /112 is an entirely sensible prefix length to
use for such purposes.   The 48 bits of address space between /64 and /112
is plenty for any conceivable purpose I can imagine (it is as much as we are
allocating for numbering, hierarchically, all the organisations that will ever
be connected) - so there shouldn't really be much in the way of rational demand
for using longer prefixes than /112.   And /112 has the nice property that
in the textual format, the node numbed is the value after the final ':',
so we get to use nnnn:1 and nnnn:2 for the two ends (or even nnnn:1111 and
nnnn:2222 or something).

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Feb 2002 16:05:41 +0700

kre

---

From: Steve Deering <[email-masked]>
Date: Thu, 7 Feb 2002 17:14:50 -0800

>/127 seems alot better? Why waste 50%?

There is yet another factor that limits the interface ID field to be no
less than 8 bits wide (i.e., no longer than a /120): RFC 2526 specifies
that the highest 127 interface ID values on each subnet are reserved for
well-known anycast addresses (as is the interface ID value zero).  You
need at least 8 bits to hold those 127+1 anycast addresses, in addition
to the minimum of 2 IDs needed for the two ends of a point-to-point link.

Steve