IETF Logo Mail Archive

Re: [Anima] Addressing-interface addressing

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 05 May 2015 18:56 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA34E1B2F9A for <anima@ietfa.amsl.com>; Tue, 5 May 2015 11:56:10 -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 rTf5Gy1E9JaH for <anima@ietfa.amsl.com>; Tue, 5 May 2015 11:56:08 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED171A873E for <anima@ietf.org>; Tue, 5 May 2015 11:56:08 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0485920098 for <anima@ietf.org>; Tue, 5 May 2015 15:08:26 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id B7EA063B86; Tue, 5 May 2015 14:56:07 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A6A2B63731 for <anima@ietf.org>; Tue, 5 May 2015 14:56:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima@ietf.org" <anima@ietf.org>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> <553A9E3F.1020008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F72FAD@xmb-rcd-x14.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 05 May 2015 14:56:07 -0400
Message-ID: <22959.1430852167@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/8Agb2PYZ_Ti0JV6SF5GGIjpAl9k>
Subject: Re: [Anima] Addressing-interface addressing
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2015 18:56:10 -0000

Michael Behringer (mbehring) <mbehring@cisco.com> wrote:
    mcr> (and I
    mcr> have said I favour a ULA-C approach) on a loopback interface.

    brian> IMHO we don't need -C. That would imply yet another external
    brian> dependency (on a non-existent registry that has no funding model
    brian> anyway). Vanilla ULA  works fine.

    mb> Slightly confused. I think on the loopback interfaces we agree we
    mb> need something routable, and that ULA (ignore the flavour for a
    mb> second) is the right thing here. And on the interfaces to other nodes
    mb> we use link local. Are we saying the same thing?

I think we all agree that ULA is the way to number the autonomic control
plane.   Current ULA-Random has the disadvantage that, when there are routing
leaks, where they come from.  We see this today with RFC1918 address spaces,
and the AS112 project exists to deal with the resulting reverse DNS lookup
impact of those leaks.

A ULA-C had the advantage that while they are seperate from an ISP or
enterprise's GUA allocation, they are still trackable when they leak.
I think it very important that the ACP be numbered in a different space than
production.  With ULA-C, one would get reverse DNS delegated to you, etc.
cf: https://tools.ietf.org/html/draft-ietf-ipv6-ula-central-02
which is from 2007, but could be revived, I think.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email