IETF Logo Mail Archive

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

Andrew đź‘˝ Yourtchenko <ayourtch@gmail.com> Tue, 17 February 2015 16:51 UTC

Return-Path: <ayourtch@gmail.com>
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 DE0D91A88E2 for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 08:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 YooAVvGGYgsD for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 08:51:57 -0800 (PST)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDBC1A8AEE for <v6ops@ietf.org>; Tue, 17 Feb 2015 08:51:53 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id i13so27036762qae.10 for <v6ops@ietf.org>; Tue, 17 Feb 2015 08:51:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mdXIHNs5ug9hMh4mSk+lJeBhXHzt5kWB3vWQBAV03YE=; b=QvKsAWfHzn9tPWQXSFA1Hd4+u7R9DHrh6PjN6+4d8kzt5BaURu3bzJKshANsTg59Mc w2aDBTt/sa6kF9atebwzNcpYoUPwcFzUMR3IB87FxWjYxsSyr33HCXHuXo2uNHXszhUX kRAG/sIty2ACNy/3cJvGNpxuGHuquqY8ulWsfTrnDo5yBq6SDqVNOGb9+PjwBScz+lMV Y5+YrzhLHa0YcUmkflCrqAQJ76imgjyIz/tZFXDiT8+yVL2LSN3hz2FBN4c93YjDWUSt WJzxY+fctgOTcKT9USKPYagMki1254iaAQqNfWt3MSBVspQ0fZziIEE0wuRDoQuAWT2N N6og==
MIME-Version: 1.0
X-Received: by 10.140.38.197 with SMTP id t63mr422755qgt.61.1424191912243; Tue, 17 Feb 2015 08:51:52 -0800 (PST)
Received: by 10.140.84.133 with HTTP; Tue, 17 Feb 2015 08:51:52 -0800 (PST)
In-Reply-To: <CAAedzxo3hP2FqDvdW9MNVTBKtpdbONa0ZDjURvk5oihr=-bWUA@mail.gmail.com>
References: <DED2296C-010C-4B75-94DC-028C0FA19E6F@virtualized.org> <806685785.8046861.1424132596458.JavaMail.yahoo@mail.yahoo.com> <CAAedzxo3hP2FqDvdW9MNVTBKtpdbONa0ZDjURvk5oihr=-bWUA@mail.gmail.com>
Date: Tue, 17 Feb 2015 17:51:52 +0100
Message-ID: <CAPi140OKb-uF1sf9EZGGeoSsLwePf-BzxNRM2jU3=op+p+ZmCQ@mail.gmail.com>
From: Andrew đź‘˝ Yourtchenko <ayourtch@gmail.com>
To: Erik Kline <ek@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/jH7jcq7e-1HKyNsWPbsyF1McIHo>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] 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 16:52:00 -0000

On 2/17/15, Erik Kline <ek@google.com> wrote:
> I was wondering about maybe an update/doc that merged this use case?
>
> I was in favor of your loopback prefix, as I recall (it would be
> especially handy if any application should implicitly bind to
> 1::${RAND96} /without/ any special permissions), but I can't recall
> the opposition at the time.
>
> /me re-reads/
>
> Ah, yeah it turns out the use cases I wanted it for are exactly the
> ones that were opposed by others at the time (the implicit delivery of
> all packets to destinations in this prefix is /technically/ new
> behaviour).  Sad panda.

Would borrowing a /64 out of fe80::/10 work ?

fe80:dead:dead:dead::/64 ?

Given the special status of fe80::/10 at least there is a high chance
that the packets would not randomly leak into the wire from the
"legacy" hosts. And most of the unmodified stacks will even reject
attempts to assign an address from such prefix, which will take care
of potential overlap.

--a







>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

v2.23.0 | Report a Bug | By Email