Hi Joe, It occurred to me that the SEAL header has an available byte that could be used as an offset to branch to the end of the extension header chain without having to parse all other extension headers in between. If that's not good enough then I don't know what else to say, because we have already established that some form of fragmentation is necessary.
Please don't answer if it is uncomfortable to do so, Joe, but are you against seeing IPv6 move forward? Thanks - Fred [email protected] > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, July 01, 2013 4:54 PM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt > > Hi, Fred, > > On 7/1/2013 4:30 PM, Templin, Fred L wrote: > > Hi Joe, > > > >... > >>>>> Either way, DPI has to follow the chain step-by-step, vs. in a > >> single leap as with IPv4. > >>> > >>> Right, but how long can those chains be and still be considered > >>> a "realistic" IPv6 packet? > >> > >> Although I agree it's important to have the header you want to > examine > >> in the first fragment, > > > > Good. That means we need to set an upper bound on the maximum > > length of an IPv6 header chain, right? > > That is only part of the solution. The other part is a way to jump to > the place you want to quickly, but that makes it hard to modify the > chain. > > >> you still need to parse the chain. > > > > That is by design of the IPv6 protocol, > > Yes. > > > and not something that > > can be changed now regardless of the encapsulation, right? > > Well, some are trying to "change" it by deprecating IPv6 options > completely - including fragmentation. That would mean that > non-encapsulated packets would have a zero-length chain. > > It doesn't help packets with encapsulation - for SEAL, IP-in-IP, etc. > > >> With IPv4 that's one opcode - jump based on the offset in a memory. > > > > Right. > > > >> With IPv6, you need to run that opcode as many times as there are > >> headers. That's the problem. Not whether you have the header you > want > >> to > >> examine, but whether you can access it in a single hardware > operation. > >> > >> That's a problem with or without SEAL, and it's the problem that the > >> current discussion on intarea is trying to address. > > > > Have there been any proposals? As in, is there any way to approach > > this without a major redesign of IPv6? I also thought that the IPv6 > > "quadword-aligned" requirement addressed performance. Is that not > > helpful? > > The primary proposal is to deprecate all IP options. > > Alignment addresses one part of the problem - how fine-grained the > jumps > are - but not the chain. > > -- > > My point is that SEAL is not a solution to the problem driving the > desire to get rid of IP fragmentation. That desire isn't because > fragmentation is incomplete or suboptimal, it's because it's *there*. > > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
