Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]

Jeroen Massar <jeroen@unfix.org> Tue, 08 May 2007 09:37 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlM8n-0001Xa-8k; Tue, 08 May 2007 05:37:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlM8m-0001XS-2q for ipv6@ietf.org; Tue, 08 May 2007 05:37:52 -0400
Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlM8k-0006C2-G5 for ipv6@ietf.org; Tue, 08 May 2007 05:37:52 -0400
Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 792A7140C205; Tue, 8 May 2007 11:37:49 +0200 (CEST)
Message-ID: <464044EC.8040605@spaghetti.zurich.ibm.com>
Date: Tue, 08 May 2007 10:37:48 +0100
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Darren.Reed@Sun.COM
References: <463AD6C4.5070407@Sun.COM> <463DC866.7010002@spaghetti.zurich.ibm.com> <463FF7E3.2060509@Sun.COM>
In-Reply-To: <463FF7E3.2060509@Sun.COM>
X-Enigmail-Version: 0.95.0
OpenPGP: id=333E7C23
X-Virus-Scanned: ClamAV 0.90.2/3219/Tue May 8 08:50:16 2007 on purgatory.unfix.org
X-Virus-Status: Clean
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: ipv6@ietf.org
Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0509386121=="
Errors-To: ipv6-bounces@ietf.org

Darren.Reed@Sun.COM wrote:
[..]
> I think my initial email gave the wrong impression of Solaris' behavior.
> 
> Solaris 9 & 10 will drop these packets by default, whether they
> are being received as the final destination or as a stepping stone.

Cool, that sounds much better (IMHO :) Does the "DROP" imply a silent
discard of the packet or does it send an ICMP parameter problem?

Reason I am asking is more for the follow up question, which is useful
for the deprecation drafts: what do you (and others) think is a
reasonable default:

 a) Silently discard the packet (maybe a log entry somewhere)
 b) Discard packet, but send back an ICMPv6 Parameter Problem.
 c) Don't process packet, but forward it anyway

Option c) seems to be clearing off the table by most implementation from
what I have seen upto now. Most don't even have a knob to turn it on
again either.

I am in favor of, and have implemented, option a), though b) doesn't
seem to be a very bad option either as backscatter is minimal and only
to the sending host who should most likely know about it. Next to that,
as itojun mentioned, ICMPv6 errors are rate-limited anyway when
implemented according to the spec.

Greets,
 Jeroen
  (I got no Solaris boxes around to test)
  (http://www.sixxs.net/faq/connectivity/?faq=filters updated)

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------