Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt

Arifumi Matsumoto <arifumi@nttv6.net> Wed, 21 March 2007 18:16 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5MY-0000SE-LZ; Wed, 21 Mar 2007 14:16:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5MX-0000S6-Bk for tcpm@ietf.org; Wed, 21 Mar 2007 14:16:41 -0400
Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5MS-0004N3-PL for tcpm@ietf.org; Wed, 21 Mar 2007 14:16:41 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.nttv6.net (8.14.0/8.13.8) with ESMTP id l2LIG1R4059477; Thu, 22 Mar 2007 03:16:02 +0900 (JST) (envelope-from arifumi@nttv6.net)
Message-ID: <46017660.6060704@nttv6.net>
Date: Thu, 22 Mar 2007 03:16:00 +0900
From: Arifumi Matsumoto <arifumi@nttv6.net>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt
References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> <200703191935.l2JJZL2i013753@venus.xmundo.net> <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.com> <200703201831.l2KIVkl8012269@venus.xmundo.net> <4600FB7E.7030700@nttv6.net> <200703211749.l2LHnmls014912@venus.xmundo.net>
In-Reply-To: <200703211749.l2LHnmls014912@venus.xmundo.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Fernando Gont wrote:
> At 06:31 a.m. 21/03/2007, Arifumi Matsumoto wrote:
> 
>> Anyway, it doesn't matter which specific ICMPv6 code falls into hard
>> or soft here.
> 
> Exactly. That's why it doesn't make sense to do the mapping from ICMPv6 
> to ICMPv4. The point is that there's no clear definition of what is a 
> hard error or a soft error. There's no such thing as soft or hard by 
> itself. It depends *when* you receive the error message. Defining ICMP 
> admin prohibited as soft or hard is IMHO pointless.

No. I mean it doesn't matter in this example admin prohibit is hard
or soft as far as there is hard error.

>> This is my opinion about RFC1122-revision and soft-error RFC
>> relationship. As soft-error RFC will be informational in the immediate
>> future, IMO all the vendors that implements RFC1122 may not even
>> notice or take a look at it.
> 
> We have had this discussion of Informational vs. Std track for one or 
> two *years*, more than one year ago. And the WG agreed on Informational.
> 
> As for vendors not looking at Informational docs.... I don't buy that at 
> all. Let's be clear: Any vendor with a clue will (or what's the purpose 
> of Informational docs, after all?). As a matter of fact, many vendors 
> already look at internet drafts.
> 
> The ICMP attacks draft is aiming at Informational, too. Yet virtually 
> all vendors have implemented most of it. Nobody ever bothered whether it 
> was Std track or Informational.

IMO, ICMP attack draft addresses a security problem, so it may be easier
to make people move.

> If your specific problem arises from use of IPv6, then you can send the 
> vendor (Microsoft?) the soft errors draft, and even direct them to the 
> v6fix site. If that's not enough, I guess the only thing left is to have 
> their clients tell them that it really sucks to have to wait dozens of 
> seconds to browse a web page.

It may work for my specific problem. For the benefit of every
people using the Internet, which way should we take ?

I'd like to know everybody's opnion in this wg. I'm glad if you
could drop me a line on-list or off-list.

Kindest regards.



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm