Re: Fwd: Interesting problems with using IPv6
--- fergdawgster@mykolab.com wrote: From: Paul Ferguson <fergdawgster@mykolab.com> There's been a lot of on-and-off discussion about v6, especially about security and operational concerns about some aspects of IPv6 deployment, specifically regarding neighbor discovery (although there are other operational security concerns, as well). I'd like to provide this as an example of those concerns, without any additional commentary. :-) See also: http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html -------------------------------------------------- I read the article and Tim Warnock on ipv6.org.au gave a pretty good and very brief summary. Pasted here for those that don't have time to read it. :-) "large L2 domain + ipv6 windows privacy extensions + some intel card bug + some mention of igmp snooping = multicast flood w/ high switch/router cpu..." Of course it's worth reading and there is a lot more to the post... scott
Thus spake Scott Weeks (surfer@mauigateway.com) on Sun, Sep 07, 2014 at 12:17:18PM -0700:
--- fergdawgster@mykolab.com wrote: From: Paul Ferguson <fergdawgster@mykolab.com>
There's been a lot of on-and-off discussion about v6, especially about security and operational concerns about some aspects of IPv6 deployment, specifically regarding neighbor discovery (although there are other operational security concerns, as well).
I'd like to provide this as an example of those concerns, without any additional commentary. :-)
See also:
http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html --------------------------------------------------
I read the article and Tim Warnock on ipv6.org.au gave a pretty good and very brief summary. Pasted here for those that don't have time to read it. :-)
"large L2 domain + ipv6 windows privacy extensions + some intel card bug + some mention of igmp snooping = multicast flood w/ high switch/router cpu..."
This is well known. see: draft-pashby-magma-simplify-mld-snooping-01 About 4-5 years ago there was CSCtl51859. Vendor implementations that treat v6 neighbor discovery like it's IGMPv2 are doomed to fail. Dale
Reading the article what occurs to me is: IPv4 requires a certain amount of administrative personnel overhead. It's relatively low which is certainly one reason for the success of IPv4. People are expensive so any new, pervasive technology will be judged at least in part on its personnel requirements. I'd go so far as to say that administering large IPv4 networks grows in personnel roughly as the log of the number of nodes. If what this is telling us, or warning us, is that IPv6 networks require higher personnel costs then that could become a big issue. Particularly among management where they've become used to a few to several people in a team running the heart of quite large networks. What if IPv6 deployment doubles or triples that personnel requirement for the same quality of administration? Does anyone know of any studies along these lines? My guess is that there isn't enough data yet. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Mon, Sep 8, 2014 at 1:28 PM, Barry Shein <bzs@world.std.com> wrote:
Reading the article what occurs to me is:
IPv4 requires a certain amount of administrative personnel overhead.
It's relatively low which is certainly one reason for the success of IPv4. People are expensive so any new, pervasive technology will be judged at least in part on its personnel requirements.
I'd go so far as to say that administering large IPv4 networks grows in personnel roughly as the log of the number of nodes.
surely this depends a LOT on the quality of the folk doing this job and their foresight in automating as much as possible, no? (probably this point isn't for debate, but the point is any network can be run badly)
If what this is telling us, or warning us, is that IPv6 networks require higher personnel costs then that could become a big issue.
is this a reflection of 'new technology' to the users (network folk) in question? What in ipv6 networking is inherently 'more people required' than ipv4 networking?
Particularly among management where they've become used to a few to several people in a team running the heart of quite large networks.
What if IPv6 deployment doubles or triples that personnel requirement for the same quality of administration?
this sounds, to me, like: "People need training or comfort with : instead of . in 'ip address' stuff..." (and other similar differences between how v4 and v6 operate at scale)
Does anyone know of any studies along these lines? My guess is that there isn't enough data yet.
that sounds reasonable.
Slightly off topic, but has there ever been a proposed protocol where hosts can register their L2/L3 binding with their connected switch (which could then propagate the binding to other switches in the Layer 2 domain)? Further discovery requests (e.g. ARP, ND) from other attached hosts could then all be directly replied, eliminating broadcast gratuitous arps. If the switches don't support the protocol they would default to flooding the discovery requests. It seems to me that so many network are caused because of the inability to change the host mechanisms. Sam On Mon, Sep 8, 2014 at 7:30 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Sep 8, 2014 at 1:28 PM, Barry Shein <bzs@world.std.com> wrote:
Reading the article what occurs to me is:
IPv4 requires a certain amount of administrative personnel overhead.
It's relatively low which is certainly one reason for the success of IPv4. People are expensive so any new, pervasive technology will be judged at least in part on its personnel requirements.
I'd go so far as to say that administering large IPv4 networks grows in personnel roughly as the log of the number of nodes.
surely this depends a LOT on the quality of the folk doing this job and their foresight in automating as much as possible, no? (probably this point isn't for debate, but the point is any network can be run badly)
If what this is telling us, or warning us, is that IPv6 networks require higher personnel costs then that could become a big issue.
is this a reflection of 'new technology' to the users (network folk) in question? What in ipv6 networking is inherently 'more people required' than ipv4 networking?
Particularly among management where they've become used to a few to several people in a team running the heart of quite large networks.
What if IPv6 deployment doubles or triples that personnel requirement for the same quality of administration?
this sounds, to me, like: "People need training or comfort with : instead of . in 'ip address' stuff..." (and other similar differences between how v4 and v6 operate at scale)
Does anyone know of any studies along these lines? My guess is that there isn't enough data yet.
that sounds reasonable.
On Sun, Sep 14, 2014 at 10:45 AM, Sam Stickland <sam@spacething.org> wrote:
Slightly off topic, but has there ever been a proposed protocol where hosts can register their L2/L3 binding with their connected switch (which could then propagate the binding to other switches in the Layer 2 domain)? Further discovery requests (e.g. ARP, ND) from other attached hosts could then all be directly replied, eliminating broadcast gratuitous arps. If the switches don't support the protocol they would default to flooding the discovery requests.
It seems to me that so many network are caused because of the inability to change the host mechanisms.
Sam
It looks like in 2011 Cisco proposed a technology called "OTV" that would do just that, according to this page: http://network-101.blogspot.com/2011/03/otv-vs-vpls.html Granted, it was aimed for wide-area networking, rather than control within a datacenter; but as everyone who has started doing BGP to their top of rack switches has learned, there's often good value in adopting techniques and protocols used in the wide area network within the datacenter as well. However, I haven't heard recent mention of it, so I'm guessing it failed to make a big enough splash to get any widespread adoption. Matt
On 9/14/2014 11:20 AM, Matthew Petach wrote:
On Sun, Sep 14, 2014 at 10:45 AM, Sam Stickland <sam@spacething.org> wrote:
Slightly off topic, but has there ever been a proposed protocol where hosts can register their L2/L3 binding with their connected switch (which could then propagate the binding to other switches in the Layer 2 domain)? Further discovery requests (e.g. ARP, ND) from other attached hosts could then all be directly replied, eliminating broadcast gratuitous arps. If the switches don't support the protocol they would default to flooding the discovery requests.
It seems to me that so many network are caused because of the inability to change the host mechanisms.
Sam
It looks like in 2011 Cisco proposed a technology called "OTV" that would do just that, according to this page: http://network-101.blogspot.com/2011/03/otv-vs-vpls.html Granted, it was aimed for wide-area networking, rather than control within a datacenter; but as everyone who has started doing BGP to their top of rack switches has learned, there's often good value in adopting techniques and protocols used in the wide area network within the datacenter as well.
However, I haven't heard recent mention of it, so I'm guessing it failed to make a big enough splash to get any widespread adoption.
Also consider the emergence of eVPN and PBB-eVPN. https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=5998&tclass=popup -- ========= bep
participants (7)
-
Barry Shein -
Bruce Pinsky -
Christopher Morrow -
Dale W. Carder -
Matthew Petach -
Sam Stickland -
Scott Weeks