: Suresh Krishnan; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
Hi Hemant,
hsOf course, firewall vendors will be biased towards inspecting an
EH that is not the HBH. But that is not what RFC 2460 says. Here is
text from RFC 2460 that clearly says
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2008 1:23 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
Hi Hemant,
hsOf course, firewall vendors will be biased towards inspecting an
EH
.
Hemant
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2008 2:14 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
At Wed, 19 Mar 2008 10:34:37 -0400
and /hs
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2008 6:47 PM
To: Hemant Singh (shemant)
Cc: IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
Hi Hemant,
Thanks for your comments. Please see
Hi Hemant,
Please find responses inline.
Hemant Singh (shemant) wrote:
Tatuya,
I understand receiver vs. sender. I am talking about the fact that RFC
2460 says no intermediate node may inspect/process any EH besides the
HBH EH. That is the reason for which I quote this para from section
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
I agree with you that a receiver may process the EH's in any order
except the HBH EH.
No. The receiver MUST process the extension headers in the order they
appear. Please see the following text from RFC2460
Hi Bert,
Manfredi, Albert E wrote:
o Extension headers must be processed in any order they appear
Why isn't the wording in RFC 2460 even clearer? Quoting:
Therefore, extension headers must
be processed strictly in the order they appear in the packet; a
receiver must not, for
Hi Markku,
Markku Savela wrote:
From: Suresh Krishnan [EMAIL PROTECTED]
Manfredi, Albert E wrote:
o Extension headers must be processed in any order they appear
Why isn't the wording in RFC 2460 even clearer? Quoting:
Therefore, extension headers must
be processed strictly in the
Hi Markku,
I totally agree with you on this.
As there is no way to distinguish between an IPv6 extension header and
an upper layer header (TCP/ UDP) there is no way to find this out.
Also the upper layer header is not be IPv6 specific, but common for
IPv4 and IPv6.
Thanks,
Vishwas
On Thu, Mar
-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),
From: Suresh Krishnan [EMAIL PROTECTED]
Manfredi, Albert E wrote:
o Extension headers must be processed in any order they appear
Why isn't the wording in RFC 2460 even clearer? Quoting:
Therefore, extension headers must
be processed strictly in the order they appear in the
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
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
20, 2008 3:52 PM
To: Hemant Singh (shemant)
Cc: [EMAIL PROTECTED]; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
Hi Hemant,
Please find responses inline.
Hemant Singh (shemant) wrote:
Tatuya,
I understand receiver vs. sender. I am talking about
Hi Bert,
Manfredi, Albert E wrote:
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
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
It was not my intention to
specify any skip/drop behavior on the nodes.
But that's exactly what IETF specs should always do,
to promote interoperability. Even if the recommended
behaviour is silent discard, that should always be
specified IMHO.
Brian
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
I do see what you mean. Is this the text you were referring
to that made
you uncomfortable?
This document proposes that all IPv6 extension headers be
encoded in
a consistent TLV format so that it is
] [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
value of zero in any header other
than an IPv6 header.]
Hemant
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Markku Savela
Sent: Thursday, March 20, 2008 4:21 PM
To: Suresh Krishnan
Cc: ipv6@ietf.org
Subject: Re: Review comments for draft-krishnan-ipv6
document needs to
update this fact in RFC 2460.
Hemant
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian E Carpenter
Sent: Thursday, March 20, 2008 4:57 PM
To: Suresh Krishnan
Cc: ipv6@ietf.org
Subject: Re: Review comments for draft-krishnan-ipv6
From: Suresh Krishnan [EMAIL PROTECTED]
If I add the word intermediate in the text in order to read
This document proposes that all IPv6 extension headers be encoded in
a consistent TLV format so that it is possible for intermediate nodes
to skip over unknown extension headers
Hi Bert,
Manfredi, Albert E wrote:
If I add the word intermediate in the text in order to read
This document proposes that all IPv6 extension headers be
encoded in
a consistent TLV format so that it is possible for
intermediate nodes
to skip over unknown extension headers and
-Original Message-
From: Markku Savela [mailto:[EMAIL PROTECTED]
The part of draft, that proposes new extension headers follow the TLV
format is OK. Although, I have always assumed that this was already
implicit or even specified. If not, the draft could be seen as an
emendation to
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian E Carpenter
Sent: Thursday, March 20, 2008 4:57 PM
To: Suresh Krishnan
Cc: ipv6@ietf.org
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
It was not my intention to
specify any skip/drop behavior on the nodes.
But that's
Hi Hemant,
Hemant Singh (shemant) wrote:
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
Hi Albert,
The 8-bit next header field, the first byte, uses the same coding as
the IPv4 Protocol field. And the next 8 bits after that provide the
length of the EH.
Why can't the intermediate node work its way down all unknown EHs until
it reaches a next header you can identify? This
, 2008 5:23 PM
To: Vishwas Manral; Markku Savela
Cc: ipv6@ietf.org; Suresh Krishnan
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
There is actually a small amount of value from this, even absent a way
to distinguish unknown extension headers and unknown upper layer
headers
-Original Message-
From: Vishwas Manral [mailto:[EMAIL PROTECTED]
How can a node know it is a new Extension Header (which follows the
format as specified in the new draft) or another upper layer protocol?
There can be two unknowns - unknown upper layer protocol and unknown
EH.
Hi Markku,
Markku Savela wrote:
From: Suresh Krishnan [EMAIL PROTECTED]
If I add the word intermediate in the text in order to read
This document proposes that all IPv6 extension headers be encoded in
a consistent TLV format so that it is possible for intermediate nodes
to skip
: IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
Hi Hemant,
Thanks for your comments. Please see responses inline.
Hemant Singh (shemant) wrote:
Suresh,
First, one simple comment.
1. In section 1 of your draft you say
[may need to look
Hi Hemant,
hsOf course, firewall vendors will be biased towards inspecting an EH
that is not the HBH. But that is not what RFC 2460 says. Here is text
from RFC 2460 that clearly says, no intermediate node will
inspect/process any EH besides the HBH.
[With one exception, extension
At Wed, 19 Mar 2008 10:34:37 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
On to more critical issues.
2. I and Wes don't agree at all with bullet 2 in section 4 (Future
work) of this draft that says:
[Extension headers must be processed in any order they appear]
[snip]
Hi,
I agree with Suresh here.
3. RFC 2460 clearly says in section 4 that EH's are not processed by
intermediate nodes unless the EH is a hop-by-hop EH. Since your draft
ignores this rule of RFC 2460, it's up to the IPv6 community to first
agree to such a change to RFC 2460 before
Hi Hemant,
Thanks for your comments. Please see responses inline.
Hemant Singh (shemant) wrote:
Suresh,
First, one simple comment.
1. In section 1 of your draft you say
[may need to look at the transport layer header fields...]
Change transport layer header to upper layer header
Suresh,
First, one simple comment.
1. In section 1 of your draft you say
[may need to look at the transport layer header fields...]
Change transport layer header to upper layer header because
(a) You must use language consistent with RFC 2460.
(b) Use of transport layer is incorrect because
On Mar 12, 2008, at 06:38, Hemant Singh (shemant) wrote:
Change transport layer header to upper layer header because
I agree with that recommendation.
2. I and Wes don't agree at all with bullet 2 in section 4 (Future
work)
of this draft that says:
[Extension headers must be processed
35 matches
Mail list logo
