Date: Tue, 06 Nov 2001 08:10:54 -0800
From: "Charles E. Perkins" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Why isn't it sensible to declare that 120 bits is the
| longest possible subnet prefix, so that point-to-point
| links can conform to RFC 2526 "Reserved IPv6 Subnet
| Anycast Addresses"?
That is a much more relevant concern - though I think the magic number
would need to be 119 bits - otherwise those reserved IPv6 Subnet
Anycast Addresses would use the entire remaining space - there'd be
nothing left to use to number the two end-points.
That is, unless we could reserve a couple of values from the reserved
space, or something...
If we went down that road we'd start arguing about just how many bits
should be the longest possible - anything from Christian's /64 (which
then presses very hard against the one small number that is in IPv6
addresses - the 16 bit number of subnets field) and up.
As I understand 2526, the idea is that some addresses should be reserved
for some particular purposes (and as usual, most of them have yet to be
invented). Unlike 2373 (which really should have been mentioned in 2526,
it defines a reserved anycast address that doesn't fit the 2526 pattern)
which requires the subnet anycast address - nothing in 2526 actually
requires that the addresses exist on any particular subnet, right?
That is, if I choose to allocate lots of addresses (subnet or otherwise)
from some subnet number, then clearly the prefix length for that subnet
must be short enough to handle that. On the other hand, if I'm not going
to be doing that, then I don't need to allow space for them, and we
can avoid the "how many is enough" arguments.
Note that there's no way for a remote application to simply decide that
they want to use an anycast address on my subnet, and calculate it based
upon some specification - they have to have more information than that.
Even 2526 sets out two different bit patterns for the bits between the
prefix and the reserved bits, depending upon the nature of the subnet
under consideration. There's no way a random remote node can possibly
know which is to apply.
The one anycast address already allocated in 2526 meets that property,
a roaming mobile node can be assumed to know the prefix length of the
subnet, and whether it is an EUI-64 subnet or not (after all, sometimes
it lives there) - so it can calculate the anycast address for when it
needs to use it. There are unlikely to be many more applications
where those conditions apply though (only if you can find some more in
MobileIP).
All this leads me to conclude that this isn't something that we need
to worry about either - we can safely allow /127's for p2p links if
that's what the net operators want to use. Those /127's won't be able
to support any of the 2526 anycast addresses, but that's OK, without
knowledge that they would be supported (and how) no-one could use them
anyway.
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]
--------------------------------------------------------------------
