Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations

Alexandru Petrescu <> Tue, 21 July 2015 16:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 27CCC1A88B8 for <>; Tue, 21 Jul 2015 09:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z0mtRl6kxGC5 for <>; Tue, 21 Jul 2015 09:23:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE9801B2FB1 for <>; Tue, 21 Jul 2015 09:23:23 -0700 (PDT)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LGNLHo007859; Tue, 21 Jul 2015 18:23:21 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id AEDF9202532; Tue, 21 Jul 2015 18:26:55 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id A366320251D; Tue, 21 Jul 2015 18:26:55 +0200 (CEST)
Received: from [] ([]) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LGNJXl006371; Tue, 21 Jul 2015 18:23:21 +0200
To: Brian E Carpenter <>,
References: <> <> <>
From: Alexandru Petrescu <>
Message-ID: <>
Date: Tue, 21 Jul 2015 18:23:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jul 2015 16:23:30 -0000

Le 21/07/2015 16:53, Brian E Carpenter a écrit :
> On 22/07/2015 02:18, Alexandru Petrescu wrote:
>> 1. Brian suggested to recommend that globals should be there on
>> the machines having ULAs as well, if I understand correctly.
>> But I think so only on some Hosts, mainly the Hosts of end users.
> All hosts that need external communication.

I agree, all hosts that need external communication.

>> 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC
>> address.  That sixxs implementation does it.  Except it takes it
>> too serious: it does not accept a MAC address which is not a real
>> MAC address - in that oui.txt.  And random MAC addresses (for
>> privacy) certainly are not in that oui.txt.
>> I think this is an undesirable situation to be in: unable to
>> generate ULAs because the only tool out there (sixxs) can't refuses
>> a copy paste a MAC address from the widely used windows 7 laptops.
> That isn't a standards issue, but I agree that operationally, there
> needs to be a viable way for anyone to generate a random number. Wait
> a minute, that doesn't seem hard.

It's easily done centrally, but in a distributed manner it's harder -
how am I sure the network I connect to has ULAs generated such that they
dont clash with mine?

>> I am not sure what the problem is, but it's very good to have a
>> very easy way to generate ULAs.
>> 3. in an enterprise deployment there was a problem of ULAs deployed
>> in a intra-network and another ULA space in another intra-network,
>> of the same enterprise.  So we wanted to make sure two things: the
>> two ULA spaces are distinct, or otherwise make sure the gateway
>> router does not route between the two intranets' ULAs (but yes,
>> route between their respective GUAs).
> Why not? ULA to ULA routing on a private link might be desired (e.g.
> after two networks merge without renumbering). From a routing PoV
> there is nothing special about a ULA prefix; we just need to
> configure carefully where it is routed and where it is not routed.

Yes, private routing should be ok, but only if these ULAs are unique.
If people on different networks use different generation methods then
it's dubious to be sure of the uniqueness.  Maybe I choose fd00:1::/64
being sure that no random generator will make it, and it happens my
neighbors does the same.  That leads to conflict on fd00:1::/64 and we
dont want routing enabled between the two.

> Anyway - I'd like to see the draft progress. Has it already had a

I agree, it already has advice in it worth progressing.


> Brian
>> I am not sure how to translate that into advice, because I am not
>> sure how it will unfold in the near future.
>> Alex
>> Le 21/07/2015 16:02, Fred Baker (fred) a écrit :
"Considerations For Using Unique Local Addresses", Bing Liu, Sheng
>>> Jiang, 2015-05-03
>>> This draft came up from the floor this afternoon. I think we
>>> need some concentrated constructive conversation regarding it -
>>> we have had a lot of the other kind.
>>> What issues do we need to address to complete it. and what
>>> specific recommendations would that include?
>>> _______________________________________________ v6ops mailing
>>> list
>> _______________________________________________ v6ops mailing list