Robert Elz wrote: > | 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.
The reserved space for anycast addresses is 7 bits long, and then there is the all-zeros identifier, which would leave over 100 addresses with a 120-bit prefix -- isn't that right? > That is, unless we could reserve a couple of values from the reserved > space, or something... :-) > 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). Here, I am arguing to improve the chances that they will at some point be better able to be invented, by now avoiding problems for their future existence. > 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? Citing 2373, I assume you mean the "Subnet Routers" anycast address. Deciding whether or not 2526 mandates the existence of those addresses is the point of this discussion. I think it would "typically" be read to place the requirement, but we can certainly decide otherwise. I favor mandating the addresses, and I don't see any downside. > 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. We can decide whether the address space is always there, or whether it has to be configured to be there, or whether applications have to negotiate to figure out whether it's there, or probe it, or "whatever". I think it is simplest to just decide that it's there. Then applications can be written more easily, both in the cases of successful connection and failure condtions. > 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. Can you say more about why this is impossible? > 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. If the remote node knows that the prefix has more than 64 bits, it can form the anycast address. For shorter prefixes, it seems to me that this problem is as hard as passing a flag to a subroutine that says whether or not the subnet is EUI-64 conformant. I agree with you that this is unfortunate. Or else the application could try twice :-). > 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). I don't really believe your statement here. I think that anycast is more appropriate for service discovery than multicast, which is already being used for that purpose. But I am curious to find out what is the downside on making this restriction on longest-possible prefix length? Regards, Charlie P -------------------------------------------------------------------- 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] --------------------------------------------------------------------
