IETF Logo Mail Archive

Re: RFC3484 destination address selection rule 2 is buggy

Sebastien Roy <Sebastien.Roy@Sun.COM> Tue, 18 March 2008 12:28 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ietfarch-ipv6-archive@core3.amsl.com
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57F828C575; Tue, 18 Mar 2008 05:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.582
X-Spam-Level:
X-Spam-Status: No, score=-100.582 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIrCVJSYOgZo; Tue, 18 Mar 2008 05:28:13 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27F128C59A; Tue, 18 Mar 2008 05:27:57 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C816428C301 for <ipv6@core3.amsl.com>; Tue, 18 Mar 2008 05:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfgQZ50mPqdb for <ipv6@core3.amsl.com>; Tue, 18 Mar 2008 05:27:55 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 07EC728C59A for <ipv6@ietf.org>; Tue, 18 Mar 2008 05:26:33 -0700 (PDT)
Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2ICOHTG029002 for <ipv6@ietf.org>; Tue, 18 Mar 2008 12:24:17 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXX00F01E5SWB00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for ipv6@ietf.org; Tue, 18 Mar 2008 06:24:17 -0600 (MDT)
Received: from [192.168.1.3] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXX003Y5EGGSKF0@mail-amer.sun.com>; Tue, 18 Mar 2008 06:24:17 -0600 (MDT)
Date: Tue, 18 Mar 2008 08:24:15 -0400
From: Sebastien Roy <Sebastien.Roy@Sun.COM>
Subject: Re: RFC3484 destination address selection rule 2 is buggy
In-reply-to: <alpine.LRH.1.00.0803140049440.7689@netcore.fi>
To: Pekka Savola <pekkas@netcore.fi>
Message-id: <47DFB46F.2040306@sun.com>
MIME-version: 1.0
References: <200803132244.m2DMiBxE048560@givry.fdupont.fr> <alpine.LRH.1.00.0803140049440.7689@netcore.fi>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, Francis Dupont <Francis.Dupont@fdupont.fr>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Pekka Savola wrote:
> Maybe the critical thing that has been missing in the RFC3484 
> discussions has been "have vendors already fixed this? how? which 
> approach has worked and which not?"

When we were working on 
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03, I 
prototyped the suggested solution of having a new rule 2.5 which avoids 
a non-link-local destination with link-local source address.  As the 
draft says, though, this is just one possible solution.  As Rémi 
mentioned on this thread, another interesting (and perhaps better) 
solution would be to simply treat rfc1918 addresses as global instead of 
site-local.  This makes sense to me since most of the time, they're 
being used with NAT to communicate to a global destination.

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

v2.23.0 | Report a Bug | By Email