Hi Suresh, Yes I see a big problem with this. Am I missing the point altogather?
As we have no defined ranges for Extension Headers, what if the value 144 is given to a new transport/ other protocol header. As we do not know if 144 is a new tranport header or IPv6 extension header, we do not know how to parse the Extension header. If we parsed it as an Extension Header how would we know that we are not parsing it wrongly. This is perfect remedy for crashes and havoc in the system. What am I missing? BTW, the diagram below the NH field of the first extension header does not look right to me. Thanks, Vishwas On Tue, Apr 27, 2010 at 9:38 AM, Suresh Krishnan <suresh.krish...@ericsson.com> wrote: > Hi Vishwas, > Maybe I am misunderstanding you, but I do not see the problem here. I will > try to explain how two different extension headers can be defined without > conflicting with a payload protocol type. > > Imagine the GIEH has been allocated the IP protocol value of 144. Let's also > imagine that two new extension headers are defined using the GIEH. The first > header is allocated the specific type 6 and the second is allocated the > specific type 21. A TCP packet containing both these headers will look like > this > > V= Version > NH= Next Header > HEL= Hdr Ext Len > ST= Specific Type > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | V=6 | Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | NH=144 | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NH=144 | HEL=5 | ST=8 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > . . > . 45 bytes of type 6 extension header specific data . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NH=6 | HEL=3 | ST=21 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > . . > . 29 bytes of type 21 extension header specific data . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TCP Header | > . . > . . > > Do you see any problems with this? > > Cheers > Suresh > > On 10-04-26 07:51 PM, Vishwas Manral wrote: >> >> Hi Suresh, >> >> If you read the mail below (which I sent earlier in the day) this is >> what I had said too. Just reserving values will not do, we need to >> also define the structure otherwise it will not work. >> >>> i.e. An unknown extension header will have a known "Next Header" value >>> but >>> an unknown "Specific Type" inside the GIEH and an unknown upper layer >>> protocol will have an unknown "Next Header" value. >> >> >> This need not be the case. What if two new headers are defined. Also >> if it is a payload how do we make sure the payload first byte does not >> match a known "Next header" field. >> >> I think the first case you need to define is some values of extension >> headers (x to y). That will solve all your issues. >> >> Thanks, >> Vishwas >> On Mon, Apr 26, 2010 at 4:24 PM, Suresh Krishnan >> <suresh.krish...@ericsson.com> wrote: >>> >>> Hi Vishwas, >>> >>> On 10-04-26 05:13 PM, Vishwas Manral wrote: >>>> >>>> Hi Stig, >>>> >>>>> I can agree that it's good to check demand, but I think it is good to >>>>> do the "future proofing" anyway. Things can then be implemented today >>>>> and work correctly (as in ignoring unknown headers and still finding >>>>> the transport) if new headers are introduced later. >>>>> >>>>> An alternative approach could perhaps be to set aside a small range of >>>>> protocol values for future extension headers? >>>> >>>> I do not think it is an alternative approach. The values tell its an >>>> extension header (and are required look at my previous mail) and >>>> follows the format defined, but the structure still needs to be >>>> defined. >>> >>> I think Stig means reserving a few IP protocol values for extension >>> headers. >>> It is certainly an alternative approach (the scheme proposed in the draft >>> uses only one protocol number and demultiplexes extension headers based >>> on >>> the "Specific Type" field) >>> >>> Thanks >>> Suresh >>> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
