Hi Suresh, > 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 11:18 AM, Suresh Krishnan <suresh.krish...@ericsson.com> wrote: > Hi Vishwas, > The idea is that all new IPv6 extension headers will use the same Next > Header value (allocated in this draft). Anything else will be a > payload/upper layer protocol. > > 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. > > Thanks > Suresh > > On 10-04-26 02:20 PM, Vishwas Manral wrote: >> >> Hi Suresh, >> >> This brings the interesting issue, how do I know if the unknown inner >> header is payload vs Extension header? >> >> Thanks, >> Vishwas >> >> On Mon, Apr 26, 2010 at 10:57 AM, Suresh Krishnan >> <suresh.krish...@ericsson.com> wrote: >>> >>> Hi Alex, >>> >>> On 10-04-26 11:02 AM, Alexandru Petrescu wrote: >>>> >>>> Le 26/04/2010 14:17, Brian Haberman a écrit : >>>>> >>>>> All, >>>>> The 6MAN chairs would like feedback from the working group on adopting >>>>> draft-krishnan-ipv6-exthdr as a WG item. Please send your >>>>> comments/opinions to the mailing list (or the chairs) by May 7, 2010. >>>> >>>> Comments... >>>>> >>>>> 3. Backward Compatibility >>>>> >>>>> >>>>> The scheme proposed in this document is not backward compatible with >>>>> all the currently defined IPv6 extension headers. It only applies to >>>>> newly defined extension headers. Specifically, the following >>>>> extension headers predate this document and do not follow the format >>>>> proposed in this document. >>>>> >>>>> o IPv6 Hop-by-Hop Options Header >>>>> o IPv6 Routing Header >>>>> o IPv6 Fragment Header >>>>> o IPv6 Destination Options Header >>>> >>>> And AH and ESP? >>> >>> AH & ESP are not considered as IPv6 extension headers and they are >>> considered as payload as far as IPv6 is concerned. >>> >>> Thanks >>> Suresh >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
