Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

["Fred Baker (fred)" <[e-mail]>]

On Mar 17, 2016, at 2:48 PM, Nick Hilliard <[e-mail]> wrote:
> It's not ok for the IETF to sit on its hands and pretend that this isn't
> a protocol problem.  The EH mechanism as it stands is unworkable which
> is causing breakage on production networks.  This needs attention from
> the IETF because EHs provide core ipv6 functionality and without this
> functionality, IPv6 is crippled as a protocol.

</chair>

I'm scratching my head on both of those statements. Help me out, if you would.

In there first statement, you assert that we're looking at a protocol problem. We may be, but that's not obvious to me. There is an issue with HBH headers, or at least with their implementation, which we are looking at in draft-ietf-6man-hbh-header-handling. Nalini Elkins has a problem with the lack of a counterpart to the IPv4 ident field, which she wants to address with a Destination Option in draft-ietf-ippm-6man-pdm-option. Several folks have issues with fragmentation and reassembly (draft-bonica-6man-frag-deprecate), but that is more about security policy and perceived application designer laziness than about issues with the header; it in fact fragments and reassembles if used for that purpose, and AFAIK is widely implemented.

You go on to say that IPv6 Extension Headers implement core functionality. I'll agree that the Security Header is core; I go to work using one of a couple of VPN technologies, and packet layer encryption is central to both. I'm hard pressed to say that the other headers are core; we don't use options in IPv4, and we don't seem to need these headers to make it work. Speaking wearing my protocol-droid hat, if I walk through a list of extension headers (HBH, Routing, Fragment, Destination Options, Security) I haven't heard anyone say "the protocol is incorrect; we need to move these bits over there and add these other bits somewhere else, or define some different processing algorithm". The only one we have deprecated is RH0, and even there, the issue isn't that RH0 can't be used to implement what in IPv4 we would call a Loose Source Route and Record; it's that even in IPv4 we decided that having that option was a security nightmare.

If we're looking at a protocol problem, we should be able to describe proposed changes to the protocol to fix it. I'm not hearing such things described, apart from draft-wkumari-long-headers.

Is the issue addressed in draft-wkumari-long-headers what we're talking about? If so, can we discard the bluster in tone and say that? Is there another issue? Can we describe it?