RFC3484 destination address selection rule 2 is buggy
Pekka Savola <pekkas@netcore.fi> Thu, 13 March 2008 22:29 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 9E2753A67F6; Thu, 13 Mar 2008 15:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.393
X-Spam-Level:
X-Spam-Status: No, score=-100.393 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_65=0.6, 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 auZKln0rmDG6; Thu, 13 Mar 2008 15:29:50 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C853A6939; Thu, 13 Mar 2008 15:29:50 -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 741243A687E for <ipv6@core3.amsl.com>; Thu, 13 Mar 2008 15:29:49 -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 zULYrF0rctcK for <ipv6@core3.amsl.com>; Thu, 13 Mar 2008 15:29:48 -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 14DE73A67F6 for <ipv6@ietf.org>; Thu, 13 Mar 2008 15:29:47 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2DMRQL3006900; Fri, 14 Mar 2008 00:27:26 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2DMRQbe006897; Fri, 14 Mar 2008 00:27:26 +0200
Date: Fri, 14 Mar 2008 00:27:26 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: ipv6@ietf.org
Subject: RFC3484 destination address selection rule 2 is buggy
Message-ID: <alpine.LRH.1.00.0803140026591.6318@netcore.fi>
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>
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
FYI, While the default router "persistence" is an interesting observation, the more interesting one is why the default address selection algorithm pick source,destination pair of v6:{link-local,global} which is almost certain not to work instead of v4:{site-local,global} (ietf-464nat is using private addresses). This issue was first reported about 5 years ago by Alain Durand et al and yet there is no fix yet (and no mention in the default address selection problem statement), see section 2 of: http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03 The main problem is destination address selection rule 2 which requires that source and destination address scopes must match (which in the case of v4 private and global addresses is not a very useful comparison given the prevalence of NAT). Maybe we need a more systematic approach to deal with RFC3484 issues (as in, a numbered list of all the problems noted) instead of doing a nice new features to have PPT slideshow every IETF meeting. ---------- Forwarded message ---------- Date: Thu, 13 Mar 2008 09:55:05 -0400 From: Iljitsch van Beijnum <iljitsch@muada.com> To: IETF discussion list <ietf@ietf.org> Subject: IPv6 router when switching wifi networks I think this is of interest to more people than just the 71attendees and I can't edit the wiki with Safari, so I'm sending it to this list: When I switch from the IPv6-only wifi network to the v4v6v4 NAT network, everything that has an IPv6 address in the DNS stops working. Turns out that my Mac tries to get at these destinations over IPv6, even though it doesn't have an IPv6 address. However, it DOES have an IPv6 default route: $ route get -inet6 default route to: :: destination: :: mask: default gateway: fe80::20b:bfff:fea9:7054%en1 interface: en1 flags: <UP,GATEWAY,DONE,STATIC,PRCLONING> This happens to be the same router that's on the v6only network. And it's reachable on the v4v6v4 nat network, too: $ traceroute6 www.ietf.org traceroute6 to www.ietf.org (2001:1890:1112:1::20) from fe80::21b: 63ff:fe02:3c13%en1, 30 hops max, 12 byte packets 1 fe80::20b:bfff:fea9:7054%en1 1.698 ms 1.431 ms 1.052 ms 2 * * * 3 *^C Further inspection shows it doesn't send out any router advertisements on the v4v6v4 nat network: 09:45:59.414798 IP6 nirrti.local > ff02::2: ICMP6, router solicitation, length 16 09:45:59.508252 IP6 nirrti.local > ff02::2: ICMP6, router solicitation, length 16 09:46:00.903133 IP6 nirrti.local > ff02::2: ICMP6, router solicitation, length 16 09:46:03.714192 IP6 nirrti.local > ff02::2: ICMP6, router solicitation, length 16 09:46:08.374871 IP6 nirrti.local > ff02::2: ICMP6, router solicitation, length 16 09:46:16.406312 IP6 nirrti.local > ff02::2: ICMP6, router solicitation, length 16 09:46:24.581632 IP6 nirrti.local > ff02::2: ICMP6, router solicitation, length 16 But this seems to be the culprit: 09:46:27.945222 IP6 nirrti.local > fe80::20b:bfff:fea9:7054: ICMP6, neighbor solicitation, who has fe80::20b:bfff:fea9:7054, length 32 09:46:27.946167 IP6 fe80::20b:bfff:fea9:7054 > nirrti.local: ICMP6, neighbor advertisement, tgt is fe80::20b:bfff:fea9:7054, length 24 Apparently, MacOS 10.5.2 tries to see if the router from the previous wireless network is still present, and if it is, it will keep the default route up. But because the IPv6 addresses were removed from the system when changing networks and now new prefix was advertised, it doesn't work. _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -------------------------------------------------------------------- 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