Date: Thu, 24 Jan 2002 14:07:28 +0100
From: Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
