Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On Jun 10, 2013 8:56 PM, "Brian E Carpenter" wrote: > > On 11/06/2013 15:44, cb.list6 wrote: > > On Jun 10, 2013 8:34 PM, "Brian E Carpenter" < brian.e.carpen...@gmail.com> > > wrote: > >> On 11/06/2013 15:21, cb.list6 wrote: > >>> On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: > Folks, > >

Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 11/06/2013 15:44, cb.list6 wrote: > On Jun 10, 2013 8:34 PM, "Brian E Carpenter" > wrote: >> On 11/06/2013 15:21, cb.list6 wrote: >>> On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: Folks, We're currently editing the aforementioned I-D. So far, the I-D just required that th

Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On Jun 10, 2013 8:34 PM, "Brian E Carpenter" wrote: > > On 11/06/2013 15:21, cb.list6 wrote: > > On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: > >> Folks, > >> > >> We're currently editing the aforementioned I-D. So far, the I-D just > >> required that the entire IPv6 header chain be present in

Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 11/06/2013 15:21, cb.list6 wrote: > On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: >> Folks, >> >> We're currently editing the aforementioned I-D. So far, the I-D just >> required that the entire IPv6 header chain be present in the first > fragment. >> Based on recent/ongoing discussions on th

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02

On 11/06/2013 08:42, sth...@nethelp.no wrote: >> Why wouldn't we add a sentence in -oversized-header-chain >> following this: >> >>> 6. Updating RFC 2460 >>> >>>If an IPv6 packet is fragmented, the first fragment of that IPv6 >>>packet (i.e., the fragment having a Fragment Offset of 0) MUS

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 11/06/2013 08:59, Warren Kumari wrote: > On Jun 10, 2013, at 4:12 PM, Brian E Carpenter > wrote: > >> Why wouldn't we add a sentence in -oversized-header-chain >> following this: >> >>> 6. Updating RFC 2460 >>> >>> If an IPv6 packet is fragmented, the first fragment of that IPv6 >>> pack

Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: > > Folks, > > We're currently editing the aforementioned I-D. So far, the I-D just > required that the entire IPv6 header chain be present in the first fragment. > > Based on recent/ongoing discussions on the 6man and v6ops lists, there > seems to b

Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

Folks, We're currently editing the aforementioned I-D. So far, the I-D just required that the entire IPv6 header chain be present in the first fragment. Based on recent/ongoing discussions on the 6man and v6ops lists, there seems to be quite a few folks pushing the idea of limiting the size f the

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

Hi, Brian, On 06/10/2013 10:12 PM, Brian E Carpenter wrote: > Why wouldn't we add a sentence in -oversized-header-chain > following this: > >> 6. Updating RFC 2460 >> >>If an IPv6 packet is fragmented, the first fragment of that IPv6 >>packet (i.e., the fragment having a Fragment Offset

RE: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

>> 6. Updating RFC 2460 >> >> If an IPv6 packet is fragmented, the first fragment of that IPv6 >> packet (i.e., the fragment having a Fragment Offset of 0) MUST >> contain the entire IPv6 header chain. > > > The entire IPv6 header including the header chain SHOULD NOT exceed > 256 octets.

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

Warren Kumari -- Please excuse typing, etc -- This was sent from a device with a tiny keyboard. On Jun 10, 2013, at 4:59 PM, Warren Kumari wrote: > > On Jun 10, 2013, at 4:12 PM, Brian E Carpenter > wrote: > >> Why wouldn't we add a sentence in -oversized-header-chain >> following this

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

> joel jaeggli > 10 June 2013 22:04 > On 6/10/13 9:35 PM, Ray Hunter wrote: >>> Christopher Morrow >>> 10 June 2013 20:59 >>> On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: > Christopher Morrow

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On Jun 10, 2013, at 4:12 PM, Brian E Carpenter wrote: > Why wouldn't we add a sentence in -oversized-header-chain > following this: > >> 6. Updating RFC 2460 >> >> If an IPv6 packet is fragmented, the first fragment of that IPv6 >> packet (i.e., the fragment having a Fragment Offset of 0

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02

> Why wouldn't we add a sentence in -oversized-header-chain > following this: > > > 6. Updating RFC 2460 > > > >If an IPv6 packet is fragmented, the first fragment of that IPv6 > >packet (i.e., the fragment having a Fragment Offset of 0) MUST > >contain the entire IPv6 header chain.

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

Why wouldn't we add a sentence in -oversized-header-chain following this: > 6. Updating RFC 2460 > >If an IPv6 packet is fragmented, the first fragment of that IPv6 >packet (i.e., the fragment having a Fragment Offset of 0) MUST >contain the entire IPv6 header chain. The entire IP

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 6/10/13 9:35 PM, Ray Hunter wrote: Christopher Morrow 10 June 2013 20:59 On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: Christopher Morrow 10 June 2013 17:22 On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins Some

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

> Christopher Morrow > 10 June 2013 20:59 > On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: >>> Christopher Morrow >>> 10 June 2013 17:22 >>> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins >>> >>> Some of the discussio

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: >> Christopher Morrow >> 10 June 2013 17:22 >> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins >> >> Some of the discussion already had talks about ordering and optimum >> method to find X in the header chain.

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

> Christopher Morrow > 10 June 2013 17:22 > On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins > > Some of the discussion already had talks about ordering and optimum > method to find X in the header chain. What happens in these situations > when someone sends 'lo

Re: draft-ietf-6man-oversized-header-chain-02

> > 53 = not good. Just because some people are re-using old hardware cards > > they had hanging around does not mean everyone has to go along with it. > > define old. > define 'hanging around' > define the location from which capex can be drawn to replace 'old' and > 'hanging around' modules whi

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins wrote: > If there is consensus that EH's are valuable - then, maybe the way forward > should be to: > > 1. Decide how to get to the L4 header best. > > 2. Maybe a recommendation on how much of the header should be read into > ASIC. Is that out of

Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On Jun 10, 2013, at 12:31 AM, Brian E Carpenter wrote: > On 10/06/2013 04:49, Tom Taylor wrote: >> On 09/06/2013 9:42 AM, Fernando Gont wrote: > > ... >>> I guess having a L4-pointer would have helped quite a lot. >>> >>> Cheers, >>> >> Would it be practical to define a HBH option that has a

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

> 53 = not good.  Just because some people are re-using old hardware > cards they had hanging around does not mean everyone has to go along > with it. you are completely correct. you are welcome to send 10gb of headers. just do not be surprised when they do not make it to the destination. welcome

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

 > >The lower bound is probably 53. There's a lowest common denominator> >problem if you expect to be able to find an l4 header as part of your > >forwarding decision >  > Guys, >  > 53 = not good.  Just because some people are re-using old hardware cards they > had hanging around does not mean

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 06/10/2013 04:09 PM, Nalini Elkins wrote: > >>The lower bound is probably 53. There's a lowest common denominator >>problem if you expect to be able to find an l4 header as part of your >>forwarding decision > > Guys, > > 53 = not good. Just because some people are re-using old hardware ca

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On 6/10/13 4:09 PM, Nalini Elkins wrote: >The lower bound is probably 53. There's a lowest common denominator >problem if you expect to be able to find an l4 header as part of your >forwarding decision Guys, 53 = not good. Just because some people are re-using old hardware cards they had han

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

On Mon, Jun 10, 2013 at 10:09 AM, Nalini Elkins wrote: > 53 = not good. Just because some people are re-using old hardware cards > they had hanging around does not mean everyone has to go along with it. define old. define 'hanging around' define the location from which capex can be drawn to rep

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

>The lower bound is probably 53. There's a lowest common denominator  >problem if you expect to be able to find an l4 header as part of your  >forwarding decision Guys, 53 = not good.  Just because some people are re-using old hardware cards they had hanging around does not mean everyone has t

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

Joel My mistake, you are right. And thanks for the reference, that is exactly what I needed to clear some doubts. Nevertheless, shouldn't we see the problem of long headers chains as operational and security instead of two separate issues as we have now? Regards, as On

Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)

i think of it as a somewhat arbitrary operational (not protocol, i.e. does not belong in this wg) best common practice. just as i warn my customer that they can announce a /64 to me, and can pay me to announce it to my peers, that my peers will not listen to it or propagate it. similarly, you mig