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
- [tcpm] ICMPv6 Error Handling at TCP draft-fujisak… Arifumi Matsumoto
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Fernando Gont
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏 )
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Fernando Gont
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Arifumi Matsumoto
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Fernando Gont
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Arifumi Matsumoto
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Fernando Gont
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Arifumi Matsumoto
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏 )
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Fernando Gont
- Re: [tcpm] ICMPv6 Error Handling at TCP draft-fuj… Fernando Gont