Re: Experiences with IPv6 and Routing Efficiency
> Was just trying to get more info from large networks about whether how some > of the things that make theoretical logical sense actually work out in > practice that way e.g. whether fixed header size and the fewer headers > required to decode to read an IPv6 packet (with respect to IPv4) really may > provide some signifiant performance advantages. So far, all indications are that the fixed header size means nothing, in terms of speed, but the *extension* headers are a significant complication and source of problems. Some of the other claims (e.g. more secure because IPsec is always available) are simply wrong - there is plenty of IPv6 equipment that doesn't offer IPsec. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Experiences with IPv6 and Routing Efficiency
On 1/19/2014 7:00 AM, Mukom Akong T. wrote: > On Sat, Jan 18, 2014 at 4:22 PM, Nick Hilliard wrote: >> extension headers are a poor idea because it's troublesome to process them >> on cheap hardware. > > Have you found them to be more troublesome to process than IPv4 options > are/were? at what position in the packet is the tcp port? a) in v4 b) in v6 c) v6 with a few extension headers now program a chip to filter based on this port number... Frank
Re: Experiences with IPv6 and Routing Efficiency
Thank you for your responses Saku, On Sat, Jan 18, 2014 at 5:00 PM, Saku Ytti wrote: > > > 2. lack of checksum >- in some instances packet corruption maybe impossible to detect in > network > How prevalent is this problem? There might be not point fixing a problem with a 0.2% probability of occurring, especially as it might be cheaper to detect and fix the errors at the application layer. > > 3. solicited-node multicast in LAN >- replaces broadcast 'problem' with vastly harder problem >- likely most practical deployments will just use traditional flooding > Could you please explain how broadcast is better than solicited node multicast. In any case we aren't getting round that for now and it is deeply imbedded in NDP. I am interested in your negative experiences with solicited node multicasts. > > 4. large lans >- no really ipv6's fault, but addressing policy's fault >- due to vast scale, large lan adds hard to solve dos vectors > Just because you can have 2^64 possible hosts on a LAN still doesn't mean we through principles of good LAN design out the door. :-) So I'd say it's rather the fault of shoddy network design rather than address policy. > > -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent -- “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ---
Re: Experiences with IPv6 and Routing Efficiency
On Sat, Jan 18, 2014 at 4:22 PM, Nick Hilliard wrote: > extension headers are a poor idea because it's troublesome to process them > on cheap hardware. > Have you found them to be more troublesome to process than IPv4 options are/were? > Because of this, packets with any sort of extension > headers are routinely dropped by a large percentage of organisations. Flow > labels are generally unused (i.e. set to zero by many host stacks). > -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent -- “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ---
Re: Experiences with IPv6 and Routing Efficiency
Thank you all for your insightful responses (please keep them coming). On Sat, Jan 18, 2014 at 9:51 PM, Mark Tinka wrote: > It could (as a function of raw traffic). > > What's the concern, unless we misunderstand? > Was just trying to get more info from large networks about whether how some of the things that make theoretical logical sense actually work out in practice that way e.g. whether fixed header size and the fewer headers required to decode to read an IPv6 packet (with respect to IPv4) really may provide some signifiant performance advantages. I do realise that question might be difficult to prove on a real network that runs dual stack. Since the existence of IPv4 on both control and data planes may have consequences that we don't immediately understand. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent -- “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ---
Re: best practice for advertising peering fabric routes
Hello Leo, On Wed, 15 Jan 2014 08:18:13 -0600 Leo Bicknell wrote: > This whole problem smacks to me of exchange points that are "too big to > fail". Since some of these exchanges are so big, everyone else must bend to > their needs. I think the world would be a better place if some of these were > broken up into smaller exchanges and they imposed less restrictions on their > participants. You forgot to add "and would break down on a weekly basis". The restrictions that IXPs impose on their customers have nothing to do with the size of their peering LAN, but everything with offering a reliable service to these same customers. Kind regards, Martin signature.asc Description: PGP signature
Re: Experiences with IPv6 and Routing Efficiency
On 1/18/14, 10:30 AM, John van Oppen wrote: > This is exactly what pushed us into 6PE... it was the only way to make > performance similar to v4 from a routing standpoint. This statement is a bit facile... What platform are you referring to? > John @ AS11404 > > signature.asc Description: OpenPGP digital signature
RE: Experiences with IPv6 and Routing Efficiency
This is exactly what pushed us into 6PE... it was the only way to make performance similar to v4 from a routing standpoint. John @ AS11404
Re: Experiences with IPv6 and Routing Efficiency
On Saturday, January 18, 2014 06:07:59 PM Mukom Akong T. wrote: > Would a routing device process (while forwarding for > example) more IPv6 packets than IPv4? It could (as a function of raw traffic). What's the concern, unless we misunderstand? Mark. signature.asc Description: This is a digitally signed message part.
Re: Experiences with IPv6 and Routing Efficiency
On Saturday, January 18, 2014 06:09:58 AM Mukom Akong T. wrote: > Does anyone have any experiences or insights to share on > how more (or less) efficient routing is with IPv6? Any > specific thoughts with respect to how the following > characteristics help or not with routing efficiency? - > fixed header size > - Extension header chain > - flow labels in header > - no intermediate fragmentation > - no checksums One thing to think about is routing efficiency. At this time, networks that employ MPLS-TE for IPv4, and run native IPv6, have challenges doing the same for IPv6, mostly because it's not possible to point IPv6 traffic into MPLS-TE tunnels built over an IPv4 control plane. If you are doing 6PE, this could be possible, but most vendors can't do the former. More native IPv6 control planes for MPLS (and by extension, MPLS-TE) will mean that IPv6 traffic will travel the same path as IPv4 traffic in MPLS-TE'd networks. When that will be remains to be seen. Until then, the most we can do for native IPv6 traffic is fiddle around with IGP metrics, to obtain some kind of reasonable TE. Mark. signature.asc Description: This is a digitally signed message part.
Re: Experiences with IPv6 and Routing Efficiency
On 18 Jan 2014 09:42, wrote: > > > please define "efficient" in this context. Would a routing device process (while forwarding for example) more IPv6 packets than IPv4? Not a dictionary definition > > /bill > > On Sat, Jan 18, 2014 at 08:09:58AM +0400, Mukom Akong T. wrote: > > Hello folks, > > > > Does anyone have any experiences or insights to share on how more (or > > less) efficient routing is with IPv6? Any specific thoughts with respect to > > how the following characteristics help or not with routing efficiency? > > - fixed header size > > - Extension header chain > > - flow labels in header > > - no intermediate fragmentation > > - no checksums > > > > Thanks in advance. > > > > -- > > > > Mukom Akong T. > > > > http://about.me/perfexcellence | twitter: @perfexcellent > > -- > > “When you work, you are the FLUTE through whose lungs the whispering of the > > hours turns to MUSIC" - Kahlil Gibran > > ---
Re: Experiences with IPv6 and Routing Efficiency
On (2014-01-18 12:22 +), Nick Hilliard wrote: > On 18/01/2014 04:09, Mukom Akong T. wrote: > > Does anyone have any experiences or insights to share on how more (or > > less) efficient routing is with IPv6? Any specific thoughts with respect to > > how the following characteristics help or not with routing efficiency? > > - fixed header size > > - Extension header chain > > - flow labels in header > > - no intermediate fragmentation > > - no checksums > > extension headers are a poor idea because it's troublesome to process them > on cheap hardware. Because of this, packets with any sort of extension > headers are routinely dropped by a large percentage of organisations. Flow > labels are generally unused (i.e. set to zero by many host stacks). Fully agreed. Main issues in IPv6 in my POV 1. EH - allows by passing L4 ACL matches in practical devices - EH could be packet long, 64k, i.e. L4 might be in fragments - some HW simply silently drops packet with more EH than it can parse - some HW punt packets with EH they can't parse 2. lack of checksum - in some instances packet corruption maybe impossible to detect in network 3. solicited-node multicast in LAN - replaces broadcast 'problem' with vastly harder problem - likely most practical deployments will just use traditional flooding 4. large lans - no really ipv6's fault, but addressing policy's fault - due to vast scale, large lan adds hard to solve dos vectors I think IPv6 was probably designed in somewhat unfortunate time, when L2 was already all ASIC, but maybe not everyone/most saw that L3 would be too, perhaps it could have used more interdisciplinary cooperation. But none of those are really show-stoppers, and perfect is enemy of done. And hindsight is 20/20. Maybe instead of attempting to packet IPSEC as mandatory on it (now dropped), it should have done new mandatory PKI based L4, it could have been the selling point which pushes adoptation. -- ++ytti
Re: Experiences with IPv6 and Routing Efficiency
On 18/01/2014 04:09, Mukom Akong T. wrote: > Does anyone have any experiences or insights to share on how more (or > less) efficient routing is with IPv6? Any specific thoughts with respect to > how the following characteristics help or not with routing efficiency? > - fixed header size > - Extension header chain > - flow labels in header > - no intermediate fragmentation > - no checksums extension headers are a poor idea because it's troublesome to process them on cheap hardware. Because of this, packets with any sort of extension headers are routinely dropped by a large percentage of organisations. Flow labels are generally unused (i.e. set to zero by many host stacks). Nick
Re: best practice for advertising peering fabric routes
* Patrick W. Gilmore: > NEVER EVER EVER put an IX prefix into BGP, IGP, or even static > route. An IXP LAN should not be reachable from any device not > directly attached to that LAN. Period. > > Doing so endangers your peers & the IX itself. It is on the order of > not implementing BCP38, except no one has the (lame, ridiculous, > idiotic, and pure cost-shifting BS) excuse that they "can't" do > this. Any ideas why DE-CIX doesn't enforce this? One advantage is that IXP participants can perform emergency maintenance if they have isolated their IXP router from their own network.
