Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

[Joe Touch <[e-mail]>]

On 6/1/2016 5:34 PM, Tom Herbert wrote:
> On Wed, Jun 1, 2016 at 5:02 PM, Joe Touch <[e-mail]> 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.

Several reasons:
1) IPv6 extension headers are more expensive to parse, and why build
hardware to parse them when you can simply drop them instead?
2) DPI devices tend to want to drop them too, because otherwise they
would need to reassemble first
        Reassembly at the DPI device is expensive (see #1).
        Reassembly at the DPI device is mistaken as violating the spec
(i.e., intermediate devices must not reassemble - but, by analogy, they
must not peek beyond the network layer too)
        DPI devices otherwise don't know how to handle fragments for
ECMP (but they could have a default for non-initial frags).
3) Both IPv4 and IPv6 fragments can be used as an endpoint DOS attack
(overload the reassembly buffer)

>  Since there is no interesting use case of extension headers,
> there's not much incentive for vendors to fix this (6man discussion).
IPsec?
IP routing headers?

In the past, the discussion on 6man and v6ops centered around
effectively deprecating extension headers. That tide has started to
turn, and now the view is to require support for at least a reasonable
chain.

> 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.
Again (and again and again), we REALLY need a compliance arm of the
ISOC. If vendors had a "truth in advertising" requirement, they wouldn't
be able to claim 40Gbps line-rate forwarding without EH support.
>> 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).

Yup - the better solution in all these cases is to fix broken stuff
first - the protocol only when the protocol is the thing that's broken.

Joe