Subject: RE: IPv6 Addr/Prefix clarification

From: "Michel Py" <[email-masked]>
Date: Wed, 23 Jan 2002 14:39:06 -0800

> JJ Behrens wrote:
> Please forgive me for being a newbie, but it seems wise to
> allow subnetting of the lower 64 bits. Afterall, it would
>  be terrible if my dialup ISP assigned a /64 to me, and I
>  had to rely on some IPv6 mythical NAT to do subnetting!

I don't think this will happen. IPv6 ISPs currently assign
/48 prefixes (see www.freenet6.net for example) which gives
you 65536 subnets to play. Besides, doing subnets on a dial-up
connection looks rather overkill to me.

Michel.

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jan 2002 14:07:28 +0100

Nevertheless, it is not architecturally forbidden to subnet at /124
if you really want to - but doing so at /48 is more likely to be
supported by all products. If I was an implementor, I certainly
wouldn't worry if a /124 prefix kicked me onto a slow path, as long
as prefixes from /3 to /64 were handled optimally.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 25 Jan 2002 18:04:46 +0700

Date:        Thu, 24 Jan 2002 14:07:28 +0100
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Nevertheless, it is not architecturally forbidden to subnet at /124
  | if you really want to

No, and it can be a good thing to do - if I have a lot of P2P links
that I am going to number as 1 and 2 at the two ends (for lots of reasons
I don't want unnumbered most times) then they're going to be 1 and 2
(a /126) whatever the length of the prefix - just a different number of
padding 0's.   If I have just a couple of dozen of them, then sure, burning
numbers out of the subnet number space between /48 and /64 should be fine.
But if I have hundreds, or perhaps even tens of thousands, then using some
of those 62 padding 0's to number all of these P2P's, and consuming just
one subnet number for the lot of them makes a lot of sense.

  | - but doing so at /48 is more likely to be
  | supported by all products.

All lengths should be supported in some sense by all products.

  | If I was an implementor, I certainly
  | wouldn't worry if a /124 prefix kicked me onto a slow path,

That would depend upon who I expected to be selling to.  If the product
is aimed at backbone providers, then sure - but if it is aimed at dialup
access providers, who want a uniquely numbered P2P for each customer (even
if only a subset are connected at once - and separate from the number
actually allocated for the customer's internal use) then I think I'd be
supporting long prefixes well (such things don't need to be nearly as fast as
forwarding in backbones, but they shouldn't be absurdly slow either).

  | as long as prefixes from /3 to /64 were handled optimally.

Forget that /3 as well, between /0 and /64 probably.   While we
currently assume that /3 is the format designator, who knows what it
will be in the future - routers should not know it exists.

They shouldn't actually know anything other than 128 as an address
counter (other than for auto-conf, which routers will rarely do, and
except as they are configured, of course).

The answer to the original question is that nothing should assume anything
about the internal structure of the 128 bits, except where actually
required by some standard (such as auto-conf).

kre