This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Re: Andre's guide to fix IPv6
- Previous message (by thread): [ipv6-wg] Re: Andre's guide to fix IPv6
- Next message (by thread): [ipv6-wg] Re: Andre's guide to fix IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Florian Weimer
fw at deneb.enyo.de
Mon Nov 28 12:25:48 CET 2005
* Kurt Erik Lindqvist: >> Previous router generations couldn't process packets on the fast path >> as soon as they contained IP options (IPv4) or extension headers >> (IPv6). Has this really changed? > > Not for previous version no... What do you mean? Do ASIS exist which can skip over an arbitrary number of IPv6 extension headers, at line rate? >> (The whole issue may not be a real problem, it only shows that the >> claim that IPv6 has been designed for efficient forwarding is crap.) > Well...that argument goes both ways. You could also say that the hw > vendors didn't follow the development as IPv6 was certainly defined > when the current hw was designed. Are you sure? The extension header concept seems to stem from SIPP (1994), which predates ASIC forwarding (flow-based forwarding was state of the art back then) and layer 4 filters: | 4.2 SIPP Options | | SIPP includes an improved option mechanism over IPv4. SIPP options | are placed in separate headers that are located between the SIPP | header and the transport-layer header in a packet. Most SIPP option | headers are not examined or processed by any router along a packet's | delivery path until it arrives at its final destination. This | facilitates a major improvement in router performance for packets | containing options. [...] (RFC 1710) To locate the transport layer header, you must perform limited processing for all options. With a chained header (like the one in SIPP and IPv6) of almost arbitrary length, this task can't really be parallelized in hardware. With IPv4, you can at least skip over all IP options in a single step (violating tons of RFCs, and perhaps your peering contract). > The real issue is the upgrade costs and how willing providers are to > upgrade for _just_ ipv6 forwarding capacity. Probably not very as > the revenue margin will stay the same. OTOH they will upgrade for > faster line-rate over time anyway and the problem over time is > non-existing. I think there is also little demand for high worst-case line rate performance (aka "DoS resistance"), especially for IPv6. > Personally I don't think v6 gives as much increased forwarding > capacity as MPLS - none. But this is a pity because one of the explicit design goals was to use a simpler header format, permitting more efficient forwarding. 8-( > OTOH there are v6 claims in the marketing and press that tends to > make me more upset :-) The increased security is my favourite :-) Yes, this is a very good one, too. 8-)
- Previous message (by thread): [ipv6-wg] Re: Andre's guide to fix IPv6
- Next message (by thread): [ipv6-wg] Re: Andre's guide to fix IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]