Re: RFC3484 destination address selection rule 2 is buggy

Gabi Nakibly <gnakibly@yahoo.com> Tue, 18 March 2008 14:13 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 7C9EE28C5F2; Tue, 18 Mar 2008 07:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100
X-Spam-Level:
X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, 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 sOJD1sXMpHaB; Tue, 18 Mar 2008 07:13:29 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9970C28C654; Tue, 18 Mar 2008 07:12:54 -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 AAE2628C651 for <ipv6@core3.amsl.com>; Tue, 18 Mar 2008 07:12:52 -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 SSvnS-GZOFdb for <ipv6@core3.amsl.com>; Tue, 18 Mar 2008 07:12:46 -0700 (PDT)
Received: from n55.bullet.mail.sp1.yahoo.com (n55.bullet.mail.sp1.yahoo.com [98.136.44.188]) by core3.amsl.com (Postfix) with SMTP id 0885628C5EC for <ipv6@ietf.org>; Tue, 18 Mar 2008 07:11:02 -0700 (PDT)
Received: from [216.252.122.219] by n55.bullet.mail.sp1.yahoo.com with NNFMP; 18 Mar 2008 14:08:46 -0000
Received: from [69.147.65.167] by t4.bullet.sp1.yahoo.com with NNFMP; 18 Mar 2008 14:08:46 -0000
Received: from [127.0.0.1] by omp502.mail.sp1.yahoo.com with NNFMP; 18 Mar 2008 14:08:46 -0000
X-Yahoo-Newman-Property: ymail-5
X-Yahoo-Newman-Id: 3246.25644.bm@omp502.mail.sp1.yahoo.com
Received: (qmail 96277 invoked by uid 60001); 18 Mar 2008 14:08:45 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=AQq/tDiSyZSGrOKkOrIzJk3pfYNYqzgF7askugi1F+sCbUzptsRlx7+IMGuyBqy4Lxf7mriSaj02F0zaWuq9so1T9RNO+Ol6xOP5zRrn5ZfBY6lJBev7m3ZoHeHF4HRe9NTFiMsAjIYXJhk7j/45EqKemwllzxtYlQr6xK1JPGY=;
Received: from [217.132.233.71] by web45511.mail.sp1.yahoo.com via HTTP; Tue, 18 Mar 2008 07:08:45 PDT
X-Mailer: YahooMailRC/902.38 YahooMailWebService/0.7.162
Date: Tue, 18 Mar 2008 07:08:45 -0700
From: Gabi Nakibly <gnakibly@yahoo.com>
Subject: Re: RFC3484 destination address selection rule 2 is buggy
To: Fred Baker <fred@cisco.com>
MIME-Version: 1.0
Message-ID: <895840.93599.qm@web45511.mail.sp1.yahoo.com>
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, ipv6@ietf.org, Pekka Savola <pekkas@netcore.fi>
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: multipart/mixed; boundary="===============0496086192=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

I certainly agree that the benefit of the simplicity of this rule is very desirable. However, this rule may be too restrictive. I am worried that there might be cases where it is desirable to send a packet to a (on-link) global address using a link-local address or ULA. Straight off the top of my head, I can think of a solicited RA. This message must use as a source address the router's link-local address and as a destination address the address of the node that sent the RS, that may very well be global.

 
----- Original Message ----
From: Fred Baker <fred@cisco.com>
To: Gabi Nakibly <gnakibly@yahoo.com>
Cc: Pekka Savola <pekkas@netcore.fi>; ipv6@ietf.org; Iljitsch van Beijnum <iljitsch@muada.com>
Sent: Tuesday, March 18, 2008 2:33:15 PM
Subject: Re: RFC3484 destination address selection rule 2 is buggy


On Mar 18, 2008, at 5:10 AM, Gabi Nakibly wrote:

> Determining whether the destination address is in the zone of a  
> source address can be tricky. However, it is fairly easy in the  
> common case where the source address is link-local and the  
> destination address is global. If the latter is not on-link, than  
> it is not in the zone of the link-local source address and this  
> source address should not be included in the candidate set. If the  
> above rule will be applied in the scenario of http://tools.ietf.org/ 
> html/draft-ietf-v6ops-v6onbydefault-03, the candidate set of the v6  
> address will be empty and therefore it will be avoided by  
> destination address selection rule 1.

Speaking for myself, there is a simpler rule in that special case  
that imght be instructive in the ULA case.

There is no sense in using a link-local address as a source address  
unless one is sending to someone on the same LAN. Hence, there is no  
sense in suing a link-local address as the source if one cannot also  
use one in the destination.

Similarly, there is no sense using a ULA source address unless the  
destination is in the same ULA. If the destination is a global  
address it might or might not be able to reply, but the sender can't  
tell.

Hence, in sender address choice:
  - use a link-local source address if and only if the destination  
is a link-local address
  - use a ULA source address if and only if the destination is a ULA  
in the same prefix
  - otherwise, use a global address


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------