Some comments questions on draft-krishnan-ipv6-exthdr-08

Fernando Gont <fernando@gont.com.ar> Wed, 17 November 2010 14:50 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=tygw0wXZFtCQwBSXqueTl+ldJnXFMsweMG3IwIukmFLekN/ZJGjDQ5ESdoXloYCvH1 78+eMZypaObVUq0jbZ0IM8Y0C6+HEH2arDbhqRiffE5OVmIxZKqk+sX+lsIWC6E/YOnO 635PFuWFmP+xRV4g272OzZ8l7toVZAoT1B6Xg=
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4CE3EBC0.4070400@gont.com.ar>
Date: Wed, 17 Nov 2010 11:50:40 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "ipv6@ietf.org" <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, jhw@apple.com, ek@google.com, "Jim_Hoagland@symantec.com" <Jim_Hoagland@symantec.com>
Subject: Some comments questions on draft-krishnan-ipv6-exthdr-08
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: list

Folks,

Some comments/questions regarding the aforementioned I-D:

* Meta:
As noted by Ran Atkinson, I think you should clearly state what sort of
options that would not fit in the Hop-by-Hop or the Destination Options
headers you think could be specified (that would warrant yet another
extension header)  -- Existence of this would be the motivation (or lack
of) to pursue the proposal in this document.

Specific comments:

* Section 2 states:

> The intention of the base IPv6 Specification [RFC2460] that
> destination hosts not be permitted to skip unknown extension headers
> continues to apply.

Isn't this I-D all about allowing nodes to skip unknown headers??


* Section 2 states:

> Another one is that this generic extension header conserves values in
> the IPv4 protocol numbers registry.

Of the top of my head, less than 25% of that space is used. And this is
not going to change much (at least in the IPv4 world), as it is
virtually impossible to use such packets across unmanaged NATs.


* Setion 2 (2.  Generic IPv6 Extension Header (GIEH) format).

Why not simply enforce a TLV format? (i.e., no "Specific Type" at all)



* Section 4

> 4.  Exceptions
> 
> The the Generic IPv6 extension header is generic enough that it is 
> suitable to use for most applications.  However, it is possible that 
> the GIEH does not satisfy the requirements in all cases where new 
> extension headers are required.  Hence, the existence of this
> generic header does not necessarily preclude the definition of new 
> independent IPv6 extension headers.

If this not going to be enforced for all new headers, is this worth the
effort?


* Section 5 (Future work)

>From the PoV of a firewall, this is simple: either the traffic complies
with my policy, or I block it.

Put another way: if the extension header is unknown, this is the reason
(other than the unknown syntax) for the firewall to block it.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Some comments questions on draft-krishnan-ipv6-ex… Fernando Gont