Date: Thu, 7 Feb 2002 17:14:50 -0800
From: Steve Deering <[EMAIL PROTECTED]>
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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
