Hi Manav,
On 10-09-27 12:19 PM, Bhatia, Manav (Manav) wrote:
Hi Suresh,
Your understanding above is correct, but your conclusion does not
follow. The problem is that a new extension header may decide to have
the Header length at another location than the second byte or
not have
one at all. The goal of the GIEH is to force all new
extension headers
to have the Header length at a KNOWN location in order to
skip over them
I had posted a draft yesterday and is temporarily available here (should get
announced in a day or two):
http://www.ietf.org/staging/draft-bhatia-6man-update-ipv6-ext-hdr-00.txt
This proposes a standard format for all IPv6 extension headers so that there is
no such ambiguity.
This is nothing new. That is what draft-ietf-6man-exthdr has also been
proposing. The original draft draft-krishnan-ipv6-exthdr has been around
for more than 4 years.
The very first revision published in July 2006 proposed a standard
format for IPv6 extension headers.
http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-00
It has evolved into the current version because the WG felt that we
needed to conserve IP protocol number space and to differentiate between
new transport protocols and new IPv6 extension headers.
Also, I don't think it's a good idea to let new extensions define the Header
length in some arbitrary location as it would become really messy for the HW to
parse such packets.
Right. That is the reason we proposed the GIEH.
The reason I said this solution is incomplete is because it
still doesn't solve the problem of an end node receiving an
IPv6 packet with some extension header that it does not
understand. What should it do with the packet? Discard it and
send an ICMP error back to the original source? If so, then
how do you incrementally deploy new extension headers in a network.
Yes. This (discard+ICMP) would be the expected behavior. I do
not think
that extension headers should require any other behavior (please see
below). I see incremental deployment as requiring two consenting
end-points talking over an unaware network.
Not all the time.
You can look http://tools.ietf.org/id/draft-bhatia-karp-non-ipsec-ospfv3-auth-00.txt for an example of why this may not necessarily be true.
Also, I think we should have a generalized solution that works for all the
cases.
It is not clear to me what the problem is. Please state the problem you
are trying to solve and why draft-ietf-6man-exthdr does not meet the
purpose. We can then work together to get the issue(s) fixed. The draft
is in its current state because it solves the following problems
*) Need for a standardized format for new extension headers (for
efficient parsing and for middlebox skipping)
*) Need to conserve protocol number space (1 allocation for all new
extension headers vs. 1 allocation per new extension header)
*) Need to differentiate new extension headers from new transport
protocols (non-GIEH next header value==>New transport protocol)
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
