Re: Using IPv6 with prefixes shorter than a /64 on a LAN
well... you are correct - he did say shorter. me - i'd hollar for my good friends Fred and Radia (helped w/ the old vitalink mess) on the best way to manage an arp storm and/or cam table of a /64 of MAC addresses. :) It was hard enough to manage a "lan"/single broadcast domain that was global in scope and had 300,000 devices on it. "route when you can, bridge when you must" --bill On Mon, Jan 24, 2011 at 08:58:25AM -0800, Owen DeLong wrote:
Bill... Last I looked, /120 was longer than /64, not shorter.
What I'm not understanding would be why anyone would want to use something shorter than /64 on a LAN.
Owen
On Jan 24, 2011, at 5:28 AM, bmanning@vacation.karoshi.com wrote:
as a test case, i built a small home network out of /120. works just fine. my home network has been native IPv6 for about 5 years now, using a /96 and IVI.
some thoughts. disable RD/RA/ND. none of the DHCPv6 code works like DHCP, so I re-wrote client and server code so that it does. static address assignment is a good thing for services like DNS/HTTP secure dynmaic update is your friend
summary - its not easy, vendors don't want to help. but it can be done.
--bill
On Mon, Jan 24, 2011 at 10:59:59AM -0200, Carlos Martinez-Cagnazzo wrote:
The subject says it all... anyone with experience with a setup like this ?
I am particularly wondering about possible NDP breakage.
cheers!
Carlos
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
On 1/24/11 11:04 AM, bmanning@vacation.karoshi.com wrote:
well... you are correct - he did say shorter. me - i'd hollar for my good friends Fred and Radia (helped w/ the old vitalink mess) on the best way to manage an arp storm and/or cam table of a /64 of MAC addresses. :) It was hard enough to manage a "lan"/single broadcast domain that was global in scope and had 300,000 devices on it.
"route when you can, bridge when you must" Bill,
It seems efforts related to IP address specific policies are likely doomed by the sheer size of the address space, and to be pedantic, ARP has been replaced with multicast neighbor discovery which dramatically reduces the overall traffic involved. Secondly, doesn't Secure Neighbor Discovery implemented at layer 2 fully mitigate these issues? I too would be interested in hearing from Radia and Fred. -Doug
On 24/01/2011 08:42 p.m., Douglas Otis wrote:
It seems efforts related to IP address specific policies are likely doomed by the sheer size of the address space, and to be pedantic, ARP has been replaced with multicast neighbor discovery which dramatically reduces the overall traffic involved.
This has nothing to do with the number of entries required in the Neighbor Cache.
Secondly, doesn't Secure Neighbor Discovery implemented at layer 2 fully mitigate these issues? I too would be interested in hearing from Radia and Fred.
It need not. Also, think about actual deployment of SEND: for instance, last time I checked Windows Vista didn't support it. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
On 24/01/2011 08:42 p.m., Douglas Otis wrote:
It seems efforts related to IP address specific policies are likely doomed by the sheer size of the address space, and to be pedantic, ARP has been replaced with multicast neighbor discovery which dramatically reduces the overall traffic involved. This has nothing to do with the number of entries required in the Neighbor Cache. Secondly, doesn't Secure Neighbor Discovery implemented at layer 2 fully mitigate these issues? I too would be interested in hearing from Radia and Fred. It need not. Also, think about actual deployment of SEND: for instance, last time I checked Windows Vista didn't support it. First, it should be noted ND over ARP offers ~16M to 2 reduction in
On 1/25/11 6:00 PM, Fernando Gont wrote: traffic. Secondly, services offered within a facility can implement Secure Neighbor Discovery, since a local network's data link layer, by definition, is isolated from the rest of the Internet. While ICMPv6 supports ND and SeND using standard IPv6 headers, only stateful ICMPv6 Packets Too Big messages should be permitted. Nor is Vista, ISATAP, or Teredo wise choices for offering Internet services. At least there are Java implementations of Secure Neighbor Discovery. When one considers what is needed to defend a facility's resources, Secure Neighbor Discovery seems desirable since it offers hardware supported defenses from a wide range of threats. While it is easy to understand a desire to keep specific IP addresses organized into small segments, such an approach seems at greater risk and more fragile in the face of frequent renumbering. In other words, it seems best to use IPv6 secure automation whenever possible. The make before break feature of IPv6 should also remove most impediments related to renumbering. In other words, fears expressed about poorly considered address block assignments also seem misplaced. -Doug
On 26/01/2011 11:36 p.m., Douglas Otis wrote:
Discovery implemented at layer 2 fully mitigate these issues? I too would be interested in hearing from Radia and Fred. It need not. Also, think about actual deployment of SEND: for instance, last time I checked Windows Vista didn't support it. First, it should be noted ND over ARP offers ~16M to 2 reduction in traffic.
Does this really make a difference in a typical LAN?
Secondly, services offered within a facility can implement Secure Neighbor Discovery, since a local network's data link layer, by definition, is isolated from the rest of the Internet.
How many implementations are there of SEND? e.g., Is there SEND support for Windows?
While ICMPv6 supports ND and SeND using standard IPv6 headers, only stateful ICMPv6 Packets Too Big messages should be permitted.
Not sure what you mean.
Nor is Vista, ISATAP, or Teredo wise choices for offering Internet services. At least there are Java implementations of Secure Neighbor Discovery.
C'mon. That's great for "proof of concept". But would you raun a real network with that? Would you deploy e.g., 200+ Windows boxes with Java-based SEND support? What about all the PKI burden?
When one considers what is needed to defend a facility's resources, Secure Neighbor Discovery seems desirable since it offers hardware supported defenses from a wide range of threats.
Without DNSsec fully deployed, is it worth the effort?
While it is easy to understand a desire to keep specific IP addresses organized into small segments, such an approach seems at greater risk and more fragile in the face of frequent renumbering. In other words, it seems best to use IPv6 secure automation whenever possible.
??
The make before break feature of IPv6 should also remove most impediments related to renumbering.
One of the most important impediments on renumbering is the IP addresses hardcoded in configuration files, ACLs, etc. And IPv6 does nothing (and cannot do anything) to help with that. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
participants (3)
-
bmanning＠vacation.karoshi.com -
Douglas Otis -
Fernando Gont