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

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

Pekka,

My comments are inline.

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: Thursday, October 02, 2008 3:48 AM
To: Dunn, Jeffrey H.
Cc: Brian Dickson; Brian E Carpenter; 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 Wed, 1 Oct 2008, Dunn, Jeffrey H. wrote:
>> 1. It seems rather wasteful to assign 2^64 addresses to each link.
>> This assignment corresponds to. 1.8x10^19 individual end systems.
Even
>> if this number of systems could be attached to a link, each speaker
>> would only be able to transmit an octet every 4679 YEARS to the
router
v> on a gigabit link.  I see no possible application for such an
>> arrangement.

>The point is not to able able to put 2^64 hosts on a link, it's being 
>able to put *enough* nodes on the link, with *near-zero* address 
>collision probability, so that you'll never need to renumber the link 
>to have more address space if the address space was not sufficient 
>after the number of connected hosts grow.  An added bonus is an 
>ability to design new protocols and mechanisms that are able to 
>leverage those bits in the address with reasonable expectation of said

>technology being usable in the wild.

While I agree with your assertions concerning flexibility and
robustness, I do not agree that 2^64 is the minimum number of nodes
that should be supported on a link.  Consider current IPv4 deployments.
I doubt anyone have configured a single router interface with any
prefix shorter than /8 (24 bits for hosts).  As a result, it would seem
to me to be a reasonable and conservative to assume that one might want
to use an IPv6 /96 (32 bits for hosts).  Regardless of that, I see no
reason to constraint folks from using other numbers of bits, both more
and less than 64.  The bottom line is that I do not understand why
folks feel the need to constrain network architects and administrators
to use only 64 bit prefixes.

>> 2.  Since each VLAN is a link, i.e., a separate Ethernet broadcast
>> domain, each VLAN on a physical interface must have its own prefix.
As
>> a result, to support the use of all possible VLAN identifiers (2^12
>> possibilities) each router interface with a VLAN module must be
>> assigned at least a /52.  For routers with multiple VLAN modules, 16
>> for example, this corresponds to the individual router requiring a
/48.
>> Although this is a worst case scenario, it illustrates the
possibility
>> of an enormous waste of address space.

>You're not reserving a block of 2^12 IPv4 prefixes (or addresses in 
>degenerate case) for each VLAN-capable router interface today, so I 
>fail to see how this argument would apply to IPv6.

That is because you did not read the initial paragraph, which points
out that SLAAC requires a one-to-one mapping of prefixes to links,
e.g., Ethernet broadcast domains.  In addition, OSPFv3 also forbids
prefixes from spanning interfaces.  As a result, 2^13 prefixes could be
required if one wanted to be sure that all 2^13 VLAN identifiers were
available to a given physical interface.  This fits in with your
statement about the ability to design new protocols and mechanisms to
leverage address bits.

-- 
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
--------------------------------------------------------------------