On Wed, Jun 1, 2016 at 5:02 PM, Joe Touch <to...@isi.edu> wrote: > Oh, certainly if the intermediate layer's variant of fragmentation is > better than IP's, sure - SEAL has similar benefits. > > Your 4th bullet point is the one I hope we can start objecting to, > though - if IP can't allow fragments, it's not IP and we should simply > return that sort of mislabeled equipment (presuming it says "supports IP"). > It's a conundrum. The reason that fragments aren't allowed is probably that packets with IP extension headers are being dropped contrary to RFC2460. Since there is no interesting use case of extension headers, there's not much incentive for vendors to fix this (6man discussion). Even if vendors were forced by the protocol police to comply with RFC2460, packets with EH can be thrown into some ridiculously slow software path and they can claim standards compliance (like what happened with IP options)-- but that really does nothing to make them usable. Segment routing might be a compelling incentive, but I worry that might have too narrow deployment to change the overall mindset about EH.
> On your last point regarding UDP ports, that should matter only for > IPv4. For IPv6, the flow ID is a better place to coordinate path > fate-sharing. > Agreed. I've been talking with engineers at Microsoft and they are looking into getting flow labels set in the next version of Windows, so non-zero IPv6 flow labels on the Internet should become the norm fairly soon! (IOS already sends them and I believe we are waiting for next Linux rebase in Android). Tom > Joe > > On 6/1/2016 4:57 PM, Tom Herbert wrote: >> On Wed, Jun 1, 2016 at 4:36 PM, Joe Touch <to...@isi.edu> wrote: >>> >>> On 6/1/2016 3:50 PM, Templin, Fred L wrote: >>>> Any tunnel that traverses a 1280 link has to fragment, but instead of >>>> outer fragmentation >>>> it should use tunnel fragmentation which is something I have been >>>> advocating for a very >>>> long time. The tunnel egress should configure at least a 2KB reassembly >>>> buffer size. >>> If the only layer you have that fragments is the outermost IP, that's >>> where you MUST do it. >>> >>> Sure, if you can fragment at an intermediate "transport" layer inside of >>> IP, that's also an option. I'm not sure why it should be preferred >>> except for the flaws of current equipment in supporting standards, though. >>> >> We defined fragmentation option in GUE >> (draft-herbert-gue-fragmentation-02). The listed benefits are: >> >> o A 32 bit identifier can be defined to avoid issues of the 16 bit >> Identification in IPv4. >> >> o Encapsulation mechanisms for security and identification such as >> virtual network identifiers can be applied to each segment. >> >> o This allows the possibility of using alternate fragmentation and >> reassembly algorithms (e.g. fragmentation with Forward Error >> Correction). >> >> o Fragmentation is transparent to the underlying network so it is >> unlikely that fragmented packet will be unconditionally dropped >> as might happen with IP fragmentation. >> >> We should probably add that all fragments will have the same outer >> addresses and UDP ports in the encapsulation so it is likely that all >> the fragments will follow the same path. Security means that we can >> cover fragmentation information with checksum or stronger integrity >> checks. >> >> This option probably only makes use of fragmentation a little more >> palatable, but doesn't change the fact that it's better to avoid >> having to fragment in the first place if at all possible ;-). >> >> Tom >> >>> Joe >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
