Hi Suresh, You are right. Thanks for clarifying this, I didnt read the draft carefully enough.
I guess I missed the part that the types inside the header will not be the same as outside. That is why I was thinking we needed to allocate a range. That said is there a limit on the number of extension headers that can be added for each sub-type/ total number of Extension headers. How do we make sure that the TCP Header and the IP header are in the same Fragment? (otherwise the entire 5-tuple inspection requires packet reassembly which is not what we want) Thanks, Vishwas On Tue, Apr 27, 2010 at 9:59 AM, Suresh Krishnan <[email protected]> wrote: > Hi Vishwas, > > On 10-04-27 12:56 PM, Vishwas Manral wrote: >> >> 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. > > It will not be given out to anything else. See below. > >> >> 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? > > I think you are missing the part that the value (144 in my example) will be > allocated by IANA specifically for the GIEH (as per the IANA considerations > section of the draft) and will not be available for allocation to transport > protocols. > >> BTW, the diagram below the NH field of the first >> extension header does not look right to me. > > Why? It just states that there is another generic extension header that > follows. > > Thanks > Suresh > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
