Re: draft-krishnan-ipv6-exthdr, notes from Beijing

2010-11-16 Thread Hing-Kam (Kam) Lam
>> a >> unknown Extension header will stop the processing chain. > > This does not address Ran's comment: why would we ever need a new > extension header?  Why aren't the Hop-by-Hop Options and Destination > Options extension headers sufficient?  Neither of the drafts above motivate > this need. R

Re: draft-krishnan-ipv6-exthdr, notes from Beijing

2010-11-16 Thread Steven Blake
On Wed, 17 Nov 2010 01:45:27 +0100, Hagen Paul Pfeifer wrote: > * Hing-Kam (Kam) Lam | 2010-11-17 05:23:47 [+0530]: > >>The draft does not do that. I dont know which version you have been >>reading. You should read draft-ietf-6man-exthdr and >>draft-bhatia-6man-update-ipv6-ext-hdr to get an idea

Re: draft-krishnan-ipv6-exthdr, notes from Beijing

2010-11-16 Thread Hagen Paul Pfeifer
One final note: GIEH will provide a transparent extension header container. The kernel must know the GIEH extension header, the inner extension header can be everything. If the Stack know GIEH he can skip it - including the (possible unknown) encapsulated header. No new extension header types must

Re: draft-krishnan-ipv6-exthdr, notes from Beijing

2010-11-16 Thread Hagen Paul Pfeifer
* Hing-Kam (Kam) Lam | 2010-11-17 05:23:47 [+0530]: >The draft does not do that. I dont know which version you have been >reading. You should read draft-ietf-6man-exthdr and >draft-bhatia-6man-update-ipv6-ext-hdr to get an idea of the problem >that this draft is attempting to solve. Hing is absol

Re: draft-krishnan-ipv6-exthdr, notes from Beijing

2010-11-16 Thread Hing-Kam (Kam) Lam
On Tue, Nov 16, 2010 at 12:32 AM, RJ Atkinson wrote: > > I do NOT support this draft, for one quite simple reason: > > ** The assumption of this draft is that there exists some >   IP option type that is NEITHER (a) hop-by-hop nor >   (b) end-to-end in nature. > > I have never heard of such an opt

RE: 6MAN WG Last Call:draft-ietf-6man-rpl-option

2010-11-16 Thread Pascal Thubert (pthubert)
Hi again Brian: I'm taking one thing back though. Unless I miss something, there's probably no need to recomputed any checksum even in transport mode, since the next header is that of the ULP... Pascal http://www.xtranormal.com/watch/7011357/ > -Original Message- > From: ipv6-boun...@ie

draft-krishnan-ipv6-exthdr, notes from Beijing

2010-11-16 Thread RJ Atkinson
I do NOT support this draft, for one quite simple reason: ** The assumption of this draft is that there exists some IP option type that is NEITHER (a) hop-by-hop nor (b) end-to-end in nature. I have never heard of such an option, but if someone can provide a concrete example I'm eager to