Subject: Comments on draft-ietf-6man-exthdr-01.txt (was: Some comments questions on draft-krishnan-ipv6-exthdr-08)

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Dec 2010 20:53:45 -0300

Folks,

FWIW, I never got a response to these comments I sent a while ago....

Thanks!

Kind regards,
Fernando

-------- Original Message --------
Subject: Some comments questions on draft-krishnan-ipv6-exthdr-08
Date: Wed, 17 Nov 2010 11:50:40 -0300
From: Fernando Gont <[email-masked]>
To: [email-masked] <[email-masked]>,  Suresh Krishnan
<[email-masked]>, [email-masked], [email-masked],
[email-masked] <[email-masked]>

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Dec 2010 00:01:52 -0500

Hi Fernando,

> FWIW, I never got a response to these comments I sent a while ago....

I understood your comments as agreeing with Ran's (and they have not 
been resolved either). The points you, Ran and Tony raised about the 
scope of the draft being larger than it should be are all valid, but all 
the additional features (other than just the common format) have been 
added due to feedback from the working group (mailing list and face 2 
face meetings). We will discuss with the chairs and see what is an 
acceptable way forward.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Dec 2010 19:21:44 -0300

Hi, Suresh,

I think some of the points/questions that I asked in my e-mail were had
not raised before.

And I think that even if the document were to continue in its current
form, those questions should be answered -- and possibly the answers
should be incorporated in the document.

So I look forward to the aswers...  :-)

Thanks!

Kind regards,
Fernando