On Tue, 25 May 2004, Barany, Pete wrote: > I also brought this issue up several months ago and received no > follow-up. I agree that it is shortsighted.
For what it's worth, I think most ISPs use longer than 64 bit subnet prefixes in numbering their loopback or point-to-point addresses, and are quite happy about it. On the other hand, there are a number of features like SEND and RFC3041 which do use these features. We don't want to get into the situation where people would start complaining that RFC3041/SEND would have to be forward-ported to arbitrary prefixlengths because folks later figured they'd prefer to use SEND/RFC3041 or something like that in the future. In other words, I think using non-64 bit prefix lengths is just fine in the scenarios where you *know* that you won't be needing the possible fancy new features that could be provided only for 64 bit prefixes. A comment below on your forwarded mail.. > More generally, I still don't see why there is a restriction on the > prefix length for all IPv6 unicast addresses where the first 3 MSBs are > other than 000. I could understand the wording in RFC 3513 (and RFC > 3513bis) if the restriction was intended for "unicast addresses that are > configured via stateless address autoconfiguration" (thus my initial > comment about the need to update RFC 2462bis). But some operators may > want to use DHCPv6 (stateful address autoconfiguration) where there is > no concept of prefixes per se (just 128 bit addresses). [...] Actually, /64 makes some sense for DHCPv6 address assignment as well, because you want to aggregate the routing table entries at the first hop ISPs, assuming that you have multiple users on a subnet. Of course, the length would not need to be exactly /64, but why not to make it consistent for DHCPv6 and non-DHCPv6 alike.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------