RE: what problem is solved by proscribing non-64 bit prefixes?

["Dunn, Jeffrey H." <jdunn at mitre.org>]

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:pekkas at netcore.fi] 
Sent: Tuesday, September 30, 2008 1:07 PM
To: Brian Dickson
Cc: Dunn, Jeffrey H.; Alexandru Petrescu; IETF IPv6 Mailing List; Ron
Bonica; Steve_Eiserman at ao.uscourts.gov; Pasi Eronen; Sherman, Kurt T.;
draft-ietf-v6ops-addcon at tools.ietf.org; ralph.liguori at disa.mil;
night at nist.gov; dougm at nist.gov; 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 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------