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

Mark Andrews <marka@isc.org> Tue, 21 July 2015 16:28 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F099E1B2F8B for <v6ops@ietfa.amsl.com>; Tue, 21 Jul 2015 09:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj7tZ9aLQm0R for <v6ops@ietfa.amsl.com>; Tue, 21 Jul 2015 09:28:44 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCE71B2F6A for <v6ops@ietf.org>; Tue, 21 Jul 2015 09:28:44 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 988BB3493CD; Tue, 21 Jul 2015 16:28:41 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EF96E160052; Tue, 21 Jul 2015 16:29:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CA6E0160079; Tue, 21 Jul 2015 16:29:37 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lf8ynbw-udtz; Tue, 21 Jul 2015 16:29:37 +0000 (UTC)
Received: from rock.dv.isc.org (89.100.broadband6.iol.cz [88.101.100.89]) by zmx1.isc.org (Postfix) with ESMTPSA id 31CB9160052; Tue, 21 Jul 2015 16:29:37 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 26A9F338B4ED; Wed, 22 Jul 2015 02:28:35 +1000 (EST)
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com>
In-reply-to: Your message of "Tue, 21 Jul 2015 18:23:19 +0200." <55AE71F7.8000107@gmail.com>
Date: Wed, 22 Jul 2015 02:28:35 +1000
Message-Id: <20150721162835.26A9F338B4ED@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/zdE9b40o4Z_liBpl0JespHXfHzM>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jul 2015 16:28:46 -0000

In message <55AE71F7.8000107@gmail.com>;, Alexandru Petrescu writes:
> 
> 
> 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?

*YOU* generate you ULA properly.
 
> >> 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.

Generate.  Don't choose.  If you generate then you should be ok.
 
> > Anyway - I'd like to see the draft progress. Has it already had a
> > WGLC?
> 
> I agree, it already has advice in it worth progressing.
> 
> Alex
> 
> >
> > 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 :
> >>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations
> >>>
> >>>
> >>
> >>>
> "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@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>
> >> _______________________________________________ v6ops mailing list
> >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
> >
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org