Dunn, Jeffrey H. wrote:
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:[EMAIL PROTECTED] 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;
[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 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).
I think along the same lines.
I doubt any Ethernet subnet can support anywhere up to 2^64 hosts in the
same subnet. Ethernet subnet is the scope of a Ethernet-broadcasted MAC
message.
Even considering a rack of 10 64port Hubs, all in the same subnet, each
port connected to 1000 endnodes it's still a much smaller number than 2^64.
Just a note,
Alex
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.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
