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

Christopher Palmer <> Tue, 05 November 2013 03:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C401921E809F for <>; Mon, 4 Nov 2013 19:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TDewZ25RYAva for <>; Mon, 4 Nov 2013 19:10:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C55FB11E80F8 for <>; Mon, 4 Nov 2013 19:10:47 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 5 Nov 2013 03:10:46 +0000
Received: from ([]) by ([]) with mapi id 15.00.0785.001; Tue, 5 Nov 2013 03:10:46 +0000
From: Christopher Palmer <>
To: Tim Chown <>, "" <>
Thread-Topic: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis
Thread-Index: Ac7Z0GgDwAaANnZ8RHGaVb7M0I7XYwAAov4AAAAfT7A=
Date: Tue, 5 Nov 2013 03:10:45 +0000
Message-ID: <>
References: <> <> <EMEW3|c7700e679335ec63fa8cc5ca34b52656pA42wx03tjc||>
In-Reply-To: <EMEW3|c7700e679335ec63fa8cc5ca34b52656pA42wx03tjc||>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:67c:370:160:7cd1:2b3:3a66:1b31]
x-forefront-prvs: 0021920B5A
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199002)(24454002)(76786001)(76796001)(76576001)(77096001)(56816003)(4396001)(47736001)(47976001)(54356001)(81342001)(15202345003)(49866001)(50986001)(87266001)(74316001)(51856001)(69226001)(53806001)(46102001)(33646001)(83072001)(19300405004)(74876001)(31966008)(79102001)(59766001)(47446002)(77982001)(74662001)(74502001)(65816001)(85306002)(83322001)(15975445006)(81686001)(19580405001)(81816001)(19580395003)(81542001)(76482001)(80976001)(74706001)(74366001)(56776001)(16236675002)(80022001)(63696002)(54316002)(2656002)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB171;; CLIP:2001:67c:370:160:7cd1:2b3:3a66:1b31; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_fbfd317f606e47fb8666f45cfe8ce7dfBN1PR03MB171namprd03pro_"
MIME-Version: 1.0
Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Nov 2013 03:10:56 -0000

The majority of in-the-wild hosts are running 3484, so as an operational document I think it's reasonable to discuss the issue as it exists with those machines.

Even with 6724 - hosts configured as described in 3.3 may still attempt a ULA -> Native IPv6 connection. That connection will just not be preferred over IPv4 -> IPv4.

I'd argue that's still non-ideal. If the enterprise hosts in question do not have access to the IPv6 Internet, they should not be configured with a default route - thus they would *never* attempt connectivity.

Overprovisioning effective IPv6 connectivity is a painful topic.
From: [] On Behalf Of Tim Chown
Sent: Monday, November 4, 2013 6:59 PM
Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis

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


On 5 Nov 2013, at 02:50, Christopher Palmer <<>> wrote:

Section 3.3 of the draft:

"  As described in section 2.2.2 of [RFC5220]<>.2>, 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<>]4>]. 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<>