Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt

Falcon Darkstar Momot <falcon@iridiumlinux.org> Tue, 17 February 2015 02:33 UTC

Return-Path: <falcon@iridiumlinux.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 4C55C1A802C for <v6ops@ietfa.amsl.com>; Mon, 16 Feb 2015 18:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 35soMJOuNRqX for <v6ops@ietfa.amsl.com>; Mon, 16 Feb 2015 18:33:30 -0800 (PST)
Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0F81A8029 for <v6ops@ietf.org>; Mon, 16 Feb 2015 18:33:30 -0800 (PST)
Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 0D9E313F41AE; Mon, 16 Feb 2015 19:33:29 -0700 (MST)
X-Spam-ASN:
Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id A30B614FA039; Mon, 16 Feb 2015 19:33:28 -0700 (MST)
Message-ID: <54E2A879.2010201@iridiumlinux.org>
Date: Mon, 16 Feb 2015 19:33:29 -0700
From: Falcon Darkstar Momot <falcon@iridiumlinux.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <D1076758.8F7D%edward.lewis@icann.org> <419285087.7936915.1424128613951.JavaMail.yahoo@mail.yahoo.com> <54E2A454.3080908@iridiumlinux.org> <CAKD1Yr0oR78UWubp4ZfWQgua5SEw1cFiKJbidDbCqxKWquKGew@mail.gmail.com> <54E2A721.7010106@iridiumlinux.org> <CAKD1Yr0JZ735RWO=yvrQ9PRHkfnX4juMgugQ1XODgU7+K9Cm4g@mail.gmail.com>
In-Reply-To: <CAKD1Yr0JZ735RWO=yvrQ9PRHkfnX4juMgugQ1XODgU7+K9Cm4g@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020200050901010604070702"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/hmkMoff3qe7YlXfNYG6I7xD4BAY>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt
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: <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, 17 Feb 2015 02:33:32 -0000

On 16/02/2015 19:30, Lorenzo Colitti wrote:
> On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot
> <falcon@iridiumlinux.org <mailto:falcon@iridiumlinux.org>> wrote:
>
>>     That doesn't make sense. A /64 *is* a large swath of IPv6 address
>>     space. And there are lots of them.
>
>     The point is that they're addresses, not tags.  Why would you
>     allocate addresses that have absolutely no purpose in relation to
>     routing?
>
>
> That's what we did in IPv4 with 127.0.0.0/8 <http://127.0.0.0/8>. As a
> proportion to the size of the IPv4 address pool, that's way more space
> than we're talking about here.
>  
>
>     If a use case (involving routing) for multiple loopback addresses
>     is evident, I'd say this makes sense, but I just don't see it. 
>     DNS RBL tagging is not such a use case.
>
>
> Pointing network  at addresses inside 127.0.0.0/8 <http://127.0.0.0/8>
> is a very reliable way to cause said applications to fail fast without
> emitting any packets. We don't have a way to do that in IPv6 except
> pointing them at ::1.

How about discard, 0100::/64 as per RFC6666?  This seems rather more
explicit than using loopback as discard.