Suresh, Introduction para of your draft says "However, some intermediate nodes such a firewalls, may need to look at the transport layer header fields in order to make a decision to allow or deny the packet."
Well, isn't the sentence suggesting that the firewall drops the packet? Also, seeing the term "intermediate", I had to check RFC 2460 and hence questioned if even an intermediate node was legal to inspect and process an EH that was not HBH. It may make sense to clarify RFC 2460 is this regard. Also, in response to your latest email that suggested new text, I don't like the "all IPv6 extension headers". I would rather have it as "all the new IPv6 extension headers". Anyhow, didn't you hear in the 6man at IETF 71 that there has been no EH defined in the past 10 years (or maybe one), so why does one need this draft? Thanks. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Suresh Krishnan Sent: Thursday, March 20, 2008 4:47 PM To: Manfredi, Albert E Cc: ipv6@ietf.org Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt Hi Bert, Manfredi, Albert E wrote: >> -----Original Message----- >> From: Suresh Krishnan [mailto:[EMAIL PROTECTED] >> Sent: Thursday, March 20, 2008 4:30 PM >> To: Markku Savela > >>> And, if you hit unknown header, there is *NO WAY* to skip >> over it. You >>> have no idea whether it is an extension header (following >> the standard >>> format), or something totally different. >> And hence this text in the future work section of the draft about >> remaining issues to be resolved. >> >> o Unknown extension headers cannot be differentiated from unknown >> upper layer protocols >> >> We had discussed this in the 6man meeting and there is no consensus >> on the way forward. A common extension header format is ONLY ONE STEP >> in the direction of the solution. It is certainly not the complete >> answer and there is no claim in the draft that says otherwise. > > I think the wording I quoted previously from RFC 2460 is intended to > keep the receiver of the packet, the one identified in the IP DA, from > skipping over unknown EHs. Which seems like the right thing to do. An > unknown EH at the receiver should generate and ICMP error, I think. I agree with you on this. > > If this draft wants to bypass that rule: The goal of the draft is not to make any recommendations to either receiving end nodes or intermediate nodes. The goal of the draft is to propose a standard extension header format. That's it. Period. If you found any text in the draft that suggests some action on the nodes, I can remove it (Please point it out to me). It was not my intention to specify any skip/drop behavior on the nodes. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
