Pekka, I do not agree with your statement that " If the non-64 prefixes had not been proscribed, we wouldn't have been able to use the existing engineering method to develop CGA/SEND specifications." The prefix length will always be available to the device, either as a configuration variable or in the router advertisements. RFC 3972 could just as easily have used the 128 - prefix length leftmost bits of a SHA-1 hash (160 bits). As a result, I would call it a weakness of CGA rather than a reason to abandon non-64 prefixes. Further, the inability to use CGA does not prevent the use of SEND. RFC 3971 specifies "RSA Signature" and "Timestamp and Nonce" as options as well.
This argument also holds for the use of EUI-64 addresses in SLAAC. There is no reason why the 128 - prefix length rightmost bits of the EUI-64, with the additional requirement that the U/L bit would have to be in the last rather than the first octet. Thoughts? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -----Original Message----- From: Pekka Savola [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 1:07 PM To: Brian Dickson Cc: Dunn, Jeffrey H.; Alexandru Petrescu; IETF IPv6 Mailing List; Ron Bonica; [EMAIL PROTECTED]; Pasi Eronen; Sherman, Kurt T.; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; V6ops Chairs; Martin, Cynthia E. Subject: Re: what problem is solved by proscribing non-64 bit prefixes? On Tue, 30 Sep 2008, Brian Dickson wrote: > Dunn, Jeffrey H. wrote: > > My basic question is: What basic engineering problem is solved by > proscribing non-64 bit prefixes? If the non-64 prefixes had not been proscribed, we wouldn't have been able to use the existing engineering method to develop CGA/SEND specifications. These are being leveraged in SHIM6 and potentially in other applications as well. Likely we couldn't even solve these engineering problems (at least without major drawbacks/other assumptions) if we couldn't have made assumptions about the widely-used prefix length. That said, I personally use non-64 bit prefixes on point-to-point links between routers, but I have done so willingly and knowing that if the IETF develops anything fancy new stuff, I might not be able to use it or I might need to renumber. > When managing such a scheme alongside an IPv6 prefix which needs to > be assigned to the same set of servers, which are all dual-stack, > the *number* of prefixes, their *relative* numbering, and the host > *addresses* within the prefixes, it is quickly apparent that use of > only /64 prefixes makes for a management nightmare, particularly if > renumbering of prefixes and/or servers occurs, e.g. re-balancing the > VLSM arrangement itself in IPv4-land. I don't understand why *relative* numbering (i.e: overlapping subnet masks) is important in IPv6, and I'm not sure if I see the case even for v4. Could you enlighten me? I assume you refer to a scenario where on the same broadcast domain there are hosts which are configured with say A.B.C.0/24 length, and some others are configured with, say, A.B.C.D/28 prefix length. -- 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
