Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt

From: RJ Atkinson <[email-masked]>
Date: Tue, 4 Jan 2011 13:42:32 -0500

Earlier, Remi Depres wrote:
> 1. let's assume a new routing extension is found useful.
>    Without a skippable extension format, it won't ever be deployable:
>      - All FWs will have no option but rejecting all packets having it.

In reality, such an extension would use the existing
IPv6 Routing Header (RFC-2460, Section 4.4), and
would define a new "Routing Type" value.  

The IPv6 Routing Header already begins with these 3 fields:
	- Next Header
	- Length of this Routing Header
	- Routing Type

So the IPv6 Routing Header *already* can be skipped if desired.  

More importantly, several existing deployed routers (from multiple 
vendors) that are deployed in the operational public Internet can
already parse past the Routing Header (if desired), for example 
in order to examine the transport-layer protocol and transport-layer 
port-number information -- and can do this today *at wire-speed for
high-speed backbone links*.

>      With this extension format, FWs can first be upgraded to support it, 
>      i.e. so that they ignore unknown extensions marked as "to be ignored if unknown".
>      Then it becomes realistic to create, for example, a new routing option.

As Fernando Gont and others have observed repeatedly, firewalls 
are intentionally designed to drop packets containing unrecognised
options/extensions -- regardless of what "action bits" might suggest.  

In short, your assumption that significant numbers of deployed
IPv6-capable firewalls would in fact "ignore unknown extensions/options" 
is not a valid assumption.

If one wants to create a new routing option, the BEST chance of
that new routing idea being deployable is to re-use the existing 
IPv6 Routing Header and define a new Routing Type value.

(I consider it unlikely that anyone would create such a routing
enhancement proposal, but if someone did, then reusing the 
existing IPv6 Routing Header would be the BEST chance for deployment.)

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 5 Jan 2011 09:50:08 -0500

Earlier, Manav wrote:
> Assume you are the end host that wants to prioritize certain packets 
> or wants to implement Access control lists (ACLs). In the absence 
> of this extension a router cannot apply ACLs as it will never know how 
> to parse the packet in case it comes across an unknown extension header. 

Banning new extension headers and instead requiring use of existing
*already supported by multiple routers* IPv6 headers is a much better,
much more complete solution to the situation postulated above.

It is practical to use the existing IPv6 headers.  The existing headers 
are well designed and widely supported in deployed nodes today.  
I've specified enhancements using the existing headers twice so far.  
RFC-5570 is one example, while draft-rja-ilnp-nonce is another example.

By contrast, specifying this new extension header both encourages
new extensions (which is undesirable, as Joel H keeps observing)
and more importantly *breaks* existing IPv6 deployments that use 
commercial routers that already can parse past the existing IPv6 
extension headers to view transport-layer information (e.g. protocol 
and port numbers).

Yours,

Ran