Re: A problem with RFC 6465's Uniform Format for Extension Headers

[RJ Atkinson <[e-mail]>]

On 10  Feb 2014, at 14:06 , Brian E Carpenter wrote:
> Not to dispute the facts of life as Thomas and Ran present them,
> but let me point out that this argument recurses.
> 
> If we forbid additional Extension Headers (i.e. freeze things
> as they are listed in RFC 7045) but allow new Options,
> in a few years somebody will write
> 
>   Today's reality is that the Internet is very unlikely to deploy
>   any new IPv6 Destination Options, because firewalls block
>   unknown options.

(I am not sure, but I think Fernando might have posted this,
or words like this, within the past week. :-)


> Guess what? This argument has been used against new IPv4 options
> since 1994 to my personal knowledge.


Many ISPs have long declined to carry IPv4 transit packets that
contain IPv4 options because all IPv4 options create interrupts
to transit routers (i.e. easily exploited DDOS attack vector on
the ISP and its routers).  That reality creates a large barrier 
to deployment of anything in the global Internet.

A key difference for IPv6, compared with IPv4 options, is that any 
options inside an IPv6 Destination Options header do NOT have the 
hop-by-hop behaviour (from the router's perspective), so they
are not automatic easily-exploited DDOS attack vectors on the ISP
or its routers.

So there is a meaningful technical difference between the 
IPv4 history and the case of options in an IPv6 Destination
Options header.

As to firewalls, the IPv6 firewalls seem (on average) to be more
configurable (e.g. often ICMPv6 has selective filters whereas, 
in the same box, ICMPv4 only has "drop all/accept all" filtering).

Some sites deliberately will configure their firewalls to drop
nearly everything optional (headers, transport protocols, flying
geese, whatever).  Nothing here will change that for such sites.

Other sites configure their firewalls more selectively.  What we
do here might have an impact on those deployments and sites.


> (Hop-by-hop options are pretty much a dead duck anyway.)

Agreed.  Many ISPs long ago decided that they will drop all
IPv6 packets with the IPv6 Hop-by-Hop Header at their ingress
border router.  The "hop-by-hop" behaviour creates an easily
exploited DDOS attack vector on the deployed infrastructure.
Bad actors found that out years ago, and the ISPs responded
shortly thereafter.

BOTTOM LINE:

I don't think that draft-gont-6man-ipv6-universal-extension-header
is worth any time investment, because it can't change the deployed 
operational behaviour.

If we bother to do anything, we ought to just acknowledge reality
and say that no more IPv6 extension *headers* are allowed.  Instead,
options must be used.  We also should note that options with hop-by-hop
behaviour likely cannot be deployed reliably across the global public
Internet.  That would mean that any "new" NextHeader value would
denote a transport-layer protocol (which I think also would be 
very difficult to deploy - I have never seen SCTP on-the-wire).


Yours,

Ran