Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis

Tim Chown <tjc@ecs.soton.ac.uk> Tue, 05 November 2013 02:59 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CBF21E80F1 for <v6ops@ietfa.amsl.com>; Mon, 4 Nov 2013 18:59:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y+NtLxhxvuV for <v6ops@ietfa.amsl.com>; Mon, 4 Nov 2013 18:59:05 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1B221E83B9 for <v6ops@ietf.org>; Mon, 4 Nov 2013 18:59:01 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52wx9B029561 for <v6ops@ietf.org>; Tue, 5 Nov 2013 02:58:59 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA52wx9B029561
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383620339; bh=C2Ql9YNSCbjp6iBouOIeBm3Oo6k=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=VOacLp21v2spr1RyY2ub2MZ/vmWuJ7yERk6XxE/o3zOt5tcgeWwLT5BTVzUWEVeK6 AkHGbSnAwhBTOlsmwbea4K+Yrz+wziQjAOndKMsOOMYCX+cFMDcLkpioR/8AV4wZ2F syet0CCYaGWteG0uOfpKA/BNpKFq8h9zsUJ8VaHQ=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id pA42wx0959635252jn ret-id none; Tue, 05 Nov 2013 02:58:59 +0000
Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:6865:dd3f:9c57:76dd] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA52woUZ003922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <v6ops@ietf.org>; Tue, 5 Nov 2013 02:58:52 GMT
From: Tim Chown <tjc@ecs.soton.ac.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F549B443-736E-4706-A4BD-C08A09EDE32E"
Message-ID: <EMEW3|c7700e679335ec63fa8cc5ca34b52656pA42wx03tjc|ecs.soton.ac.uk|F5022E7E-5969-4961-8C1F-03A8FD6C8069@ecs.soton.ac.uk>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Date: Tue, 5 Nov 2013 02:58:50 +0000
References: <a2dc12c28a1d4eb28e7da36c959e2e9b@BN1PR03MB171.namprd03.prod.outlook.com> <F5022E7E-5969-4961-8C1F-03A8FD6C8069@ecs.soton.ac.uk>
To: "v6ops@ietf.org" <v6ops@ietf.org>
In-Reply-To: <a2dc12c28a1d4eb28e7da36c959e2e9b@BN1PR03MB171.namprd03.prod.outlook.com>
X-Mailer: Apple Mail (2.1816)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=pA42wx095963525200; tid=pA42wx0959635252jn; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: rA52wx9B029561
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 02:59:06 -0000

The 3484’s in that chunk of text should be 6724’s.

Tim

On 5 Nov 2013, at 02:50, Christopher Palmer <Christopher.Palmer@microsoft.com> wrote:

> Section 3.3 of the draft:
>  
> “  As described in section 2.2.2 of [RFC5220], when an enterprise has
>    IPv4 Internet connectivity but does not yet have IPv6 Internet
>    connectivity, then the enterprise chose ULA for site-local IPv6
>    connectivity. Each employee host will have both an IPv4 global or
>    private address and a ULA. Here, when this host tries to connect to
>    an outside node that has registered both A and AAAA records in the
>  
>    DNS, the host will choose AAAA as the destination address and the ULA
>    for the source address according to the IPv6 preference of the
>    default address selection policy [RFC3484]. This will clearly result
>    in a connection failure.”
>  
> This is only true if the ULA is configured on a host that also has a default route The enterprise can avoid any issues by simply configuring a scoped route on hosts (say, only for the ULA prefix). If a network does not provide connectivity to the IPv6 Internet, it should not advertise ::/0.
>  
> I think it’s useful to discuss that configuration route, which is possible today with a vast majority of hosts and just works.
>  
> Modifying the prefix policy table is not suitable at scale. And the DNS preference logic alluded to in section 3.3 is highly ambiguous.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops