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
> -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.
, March 20, 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 lay
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 identi
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 suggest
-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-exthdr-01.txt
>> It was not my intention to
>> sp
> -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
> emendati
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
There is actually a small amount of value from this, even absent a way to
distinguish unknown extension headers and unknown upper layer headers.
Specifically, the implementation of a parser for (known) extension headers
can be simplified due to the uniform layout of at least the start of the
header
> 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 h
. Some new 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-kri
ext Header 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-kri
hanks.
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]
> 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 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
-
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
nan [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 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,
>
> -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 ex
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 ex
> 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
> -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
>
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 2
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 proc
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 n
> -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 RF
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 sect
arguments were clear enough from my original email. But let
me give it another shot.
Please see in line below between and
-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
S
ve the EH's in order.
Thanks.
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-0
;
> I will reply to Tatuya in a short while.
>
> Thanks.
>
> Hemant
>
>
> -Original Message-
> From: Vishwas Manral [mailto:[EMAIL PROTECTED]
>
> Sent: Wednesday, March 19, 2008 1:23 PM
> To: Hemant Singh (shemant)
>
> Cc: Suresh Krishnan
t Singh (shemant)
Cc: Suresh Krishnan; IETF IPv6 Mailing List
Subject: Re: Review comments for draft-krishnan-ipv6-exthdr-01.txt
Hi Hemant,
> Of 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
> tex
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 a
Hi Hemant,
> Of 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 he
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
>
> [ma
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
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 la
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 p
36 matches
Mail list logo
