Hi Fernando,
On 10-12-21 06:53 PM, Fernando Gont wrote:
Folks,
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
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 protected]>
To: [email protected] <[email protected]>, Suresh Krishnan
<[email protected]>, [email protected], [email protected],
[email protected] <[email protected]>
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,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
