On Jan 21, 2014, at 02:52 , Frank Habicht wrote:
> Hi Owen,
>
> On 1/21/2014 12:13 PM, Owen DeLong wrote:
>> On Jan 18, 2014, at 23:19 , Frank Habicht wrote:
>>> c) v6 with a few extension headers
>> In this case, it will be at 40+o+n octets into the packet where o is the
>> number of octets c
Hi Owen,
On 1/21/2014 12:13 PM, Owen DeLong wrote:
> On Jan 18, 2014, at 23:19 , Frank Habicht wrote:
>> c) v6 with a few extension headers
> In this case, it will be at 40+o+n octets into the packet where o is the
> number of octets contained in headers prior to the TCP header and n is
> defined
On Jan 18, 2014, at 23:19 , Frank Habicht wrote:
> 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 tro
On Sun, 19 Jan 2014 08:58:12 +0100, sth...@nethelp.no said:
> 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.
Given the incredible market penetration of IPsec on the v4 side of
the fen
On Sunday, January 19, 2014 07:52:38 PM joel jaeggli wrote:
> It doesn't make a lot of sense to have device that has a
> nominal capacity of several Tb/s attempt to punt packets
> up to a control-plane processor that's gig-e connected.
Not that the control plane would forward said traffic at
Gig
On (2014-01-19 08:08 +0400), Mukom Akong T. wrote:
> 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.
I have no data on prevalency. But just t
On Sun, Jan 19, 2014 at 8:15 PM, Nick Hilliard wrote:
> 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 exhaustio
On (2014-01-19 09:52 -0800), joel jaeggli wrote:
> It doesn't make a lot of sense to have device that has a nominal
> capacity of several Tb/s attempt to punt packets up to a control-plane
> processor that's gig-e connected.
You already punt IP options, vast majority of deployments won't see
sign
On 1/19/14, 9:05 AM, Saku Ytti wrote:
> On (2014-01-19 16:11 +), Nick Hilliard wrote:
>
>> attacks for hardware-forwarded routers, so generally the only sensible
>> option is to drop packets with long EH chains.
>
> I think sensible is to handle HW when possible and punt rate-limited when
> m
On (2014-01-19 16:11 +), Nick Hilliard wrote:
> attacks for hardware-forwarded routers, so generally the only sensible
> option is to drop packets with long EH chains.
I think sensible is to handle HW when possible and punt rate-limited when
must. Dropping standard compliant data seems dubiou
On 19/01/2014 04:00, Mukom Akong T. wrote:
> Have you found them to be more troublesome to process than IPv4 options
> are/were?
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
On 19/01/2014 04:08, Mukom Akong T. wrote:
> 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.
no, it's a problem with the nu
On Sunday, January 19, 2014 12:10:47 PM Saku Ytti wrote:
> 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 n
On (2014-01-19 09:10 +), John van Oppen wrote:
> 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 un
, 2014 10:56 AM
To: John van Oppen; 'mark.ti...@seacom.mu'; nanog@nanog.org
Subject: 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 v
On Sun, Jan 19, 2014 at 1:58 AM, wrote:
>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.
Asi
> 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 m
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
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 o
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
>
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
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
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
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 digi
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? -
> fix
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,
>
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 no
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
> - Extens
28 matches
Mail list logo
