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.
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
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.
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
> 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
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.
It could (as a function of raw traffic).
What's the concern, unless we misunderstand?
Mark.
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
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?
Thank you all for your insightful responses (please keep them coming).
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.
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?
Thank you for your responses Saku,
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.
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
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, sthaug@nethelp.no
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.
The claim of more secure would really be wrong, even if all IPv6 equipment
supported IPsec.
Aside from: Encrypting the transport between all the LAN hosts does not
assure security in general ----- not against common attacks.
Aside from: Encrypting the transport between hosts on a LAN can mask
malicious activity from Intrusion Detection Systems, that would otherwise
capture packets between hosts, and check against a signature database;
showing possible signs of compromise, or possible attempts to exploit a
vulnerability.
The problem is; most users don't have any understanding of IPsec, AND it
requires manual configuration ---- IPv6 and IPsec standards don't provide
any method of automatic configuration interoperable between various hosts,
AND users are unlikely to take the steps to manually configure IPsec.
>
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.
I believe this is correct; The important thing is that specific
pre-defined bit positions in the header correspond to specific items,
and therefore, as few bits as possible need to be inspected, before the
decision is made -- which buffer to copy the packet into.
And.... the removal of some headers to extensions are more like a minor
reduction in bandwidth overhead, in exchange for a large amount of extra
work, processing any packets that use the extension headers.
On the other hand; Given Moore's law, and the much quicker rate that CPU
power is expanding at cost $X than network bandwidth ----- it could
actually make a great deal of sense though to take on the extra complexity
and sacrifice router CPU efficiency, in exchange, for lower header
overhead sizes.
"Problems" are due to vendors with buggy implementations.
The extension headers add complexity., but it could still be a lot better
than the alternative -- larger total header size, resulting in fewer bytes
of useful data payload per IP packet.
Fewer bytes of payload per packet = Fewer user databits per second that
can be sent over a link of a particular bitrate, before the link is
congested.
.
We ended up with 6PE to make the v6 support on our cisco based network behave the same way as v4, IE use TE tunnels, etc. Given the v4 MPLS this was the only real way to make it the same.
Fully agreed. I have no problem being in 6PE until fork-lift in some future to
IPv6 core and 4PE.
Signalling AFI in core and AFI sold to customer have little codependency.
People have too sentimental view on this, if you label your IPv4 it is silly
not to run 6PE, you're just creating complexity and removing functionality.
Fully agreed. I have no problem being in 6PE until
fork-lift in some future to IPv6 core and 4PE.
Assuming your addressing will continue to grow on IPv6, and
remain reasonably static on IPv4, your forklift should allow
you to remain native on both (on the basis that at that
time, we do have native control planes both for MPLSv4 and
MPLSv6, of course).
So "4|6PE" would not be necessary. Personally, I think it's
unnecessary labor to remove IPv4 in the future, especially
when it's not expanding. One is welcome to do this, of
course, if they are really bored :-).
Removing native IPv4 in the future only to replace it with
4PE seems quite complex, to me.
People have too sentimental view on this, if you label
your IPv4 it is silly not to run 6PE, you're just
creating complexity and removing functionality.
Turning on native IPv6 in your core is not adding
complexity, I think. Yes, agree that you may lose parity
between MPLS-TEv4 and TEv6 as of today, but some would say
that MPLS-TE adds quite a bit complexity today, especially
if used on a long-term basis.
Mark.
The problem is that you can have long EH chains, with one after another.
Generally speaking, most hardware forwarding engines will perform a lookup
based on the first N bytes of a packet.
If arbitrary length EHs are not supported by the hardware, then you have 3
options: forward the packets unilaterally, drop the packets unilaterally or
punt to a cpu/npu. Punting and forwarding both open up denial of service
attacks for hardware-forwarded routers, so generally the only sensible
option is to drop packets with long EH chains.
Nick
no, it's a problem with the number of addresses available on the LAN;
nothing to do with shoddy network design.
Each device on the LAN will have a certain amount of capacity for caching
neighbour addressing details. If some third party decides to send packets
to a massive number of addresses on that LAN, then the router which is
forwarding these packets will attempt to perform ND for these addresses.
This can trivially be used as a cache exhaustion attack, which can cause
regular connectivity on that LAN to be trashed.
Nick
I think sensible is to handle HW when possible and punt rate-limited when
must. Dropping standard compliant data seems dubious at best.
Now should it be standard complaint?
http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-09 is
looking to restrict EH more, I contacted authors, hoping even more limitation
than what it currently suggests, they thought 6man would never accept as
strict limits as I suggested.
My suggestion is that IP + EH (not L4) SHOULD NOT span over 128B and
implementation MAY drop frames with larger headers.