Re: RFC3484 destination address selection rule 2 is buggy
Pekka Savola <pekkas@netcore.fi> Thu, 13 March 2008 22:58 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 E885928C8E4; Thu, 13 Mar 2008 15:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.201
X-Spam-Level:
X-Spam-Status: No, score=-100.201 tagged_above=-999 required=5 tests=[AWL=0.236, 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 5CSvnWI20Ojt; Thu, 13 Mar 2008 15:58:57 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C5428C8DD; Thu, 13 Mar 2008 15:58:56 -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 57F0128C8D8 for <ipv6@core3.amsl.com>; Thu, 13 Mar 2008 15:58:55 -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 LF+QgbBw66HE for <ipv6@core3.amsl.com>; Thu, 13 Mar 2008 15:58:54 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id E57C428C1EE for <ipv6@ietf.org>; Thu, 13 Mar 2008 15:58:53 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2DMuTFV007841; Fri, 14 Mar 2008 00:56:29 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2DMuTQQ007838; Fri, 14 Mar 2008 00:56:29 +0200
Date: Fri, 14 Mar 2008 00:56:29 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Francis Dupont <Francis.Dupont@fdupont.fr>
Subject: Re: RFC3484 destination address selection rule 2 is buggy
In-Reply-To: <200803132244.m2DMiBxE048560@givry.fdupont.fr>
Message-ID: <alpine.LRH.1.00.0803140049440.7689@netcore.fi>
References: <200803132244.m2DMiBxE048560@givry.fdupont.fr>
User-Agent: Alpine 1.00 (LRH 882 2007-12-20)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.92.1/6220/Thu Mar 13 00:33:03 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
On Thu, 13 Mar 2008, Francis Dupont wrote: > Perhaps some of us didn't remember but: > - I predicted the RFC 3484 will be always at least a phase back from > what we want. > - I predicted too it would take a not reasonable amount of time to > get the document published or updated. > Unfortunately both predictions were right so again I propose to make > this a BCP and *not* a standard track document. Francis, I don't think BCP status would change this; that's still a IETF consensus document. Maybe some implementations could fix their implementations with local hacks without as easily becoming (on paper) incompliant but they can already do this in any case. However the goal of the IETF is to "make the Internet work better" (BCP95); I see significant value in finding out what works best and specifying that and revising that specification as necessary. Instead of leaving each vendor in the dark and invariably doing lots of corner cases wrong. 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?" -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- RFC3484 destination address selection rule 2 is b… Pekka Savola
- Re: RFC3484 destination address selection rule 2 … Francis Dupont
- Re: RFC3484 destination address selection rule 2 … Alain Durand
- Re: RFC3484 destination address selection rule 2 … Rémi Denis-Courmont
- Re: RFC3484 destination address selection rule 2 … Pekka Savola
- Re: RFC3484 destination address selection rule 2 … Francis Dupont
- Re: RFC3484 destination address selection rule 2 … Mohacsi Janos
- Re: RFC3484 destination address selection rule 2 … Rémi Denis-Courmont
- Re: RFC3484 destination address selection rule 2 … Sebastien Roy
- Re: RFC3484 destination address selection rule 2 … Gabi Nakibly
- Re: RFC3484 destination address selection rule 2 … Sebastien Roy
- Re: RFC3484 destination address selection rule 2 … Fred Baker
- Re: RFC3484 destination address selection rule 2 … Sebastien Roy
- Re: RFC3484 destination address selection rule 2 … Gabi Nakibly
- Re: RFC3484 destination address selection rule 2 … Sebastien Roy
- Re: RFC3484 destination address selection rule 2 … Brian E Carpenter
- Re: RFC3484 destination address selection rule 2 … JINMEI Tatuya / 神明達哉
- Re: RFC3484 destination address selection rule 2 … JINMEI Tatuya / 神明達哉
- Re: RFC3484 destination address selection rule 2 … Pekka Savola
- RE: RFC3484 destination address selection rule 2 … Hemant Singh (shemant)
- Re: RFC3484 destination address selection rule 2 … Pekka Savola
- Re: RFC3484 destination address selection rule 2 … Fred Baker
- Re: RFC3484 destination address selection rule 2 … Bob Hinden
- RE: RFC3484 destination address selection rule 2 … Hemant Singh (shemant)
- Re: RFC3484 destination address selection rule 2 … Fred Baker
- Re: RFC3484 destination address selection rule 2 … Brian E Carpenter
- Re: RFC3484 destination address selection rule 2 … Bob Hinden
- Re: RFC3484 destination address selection rule 2 … Fred Baker