Experiences with IPv6 and Routing Efficiency

Sat Jan 18 13:00:18 UTC 2014

On (2014-01-18 12:22 +0000), 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