Re: draft-bourbaki-6man-classless-ipv6-00

Nick Hilliard <nick@foobar.org> Sat, 03 June 2017 15:47 UTC

Return-Path: <nick@foobar.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB697129BBF for <ipv6@ietfa.amsl.com>; Sat, 3 Jun 2017 08:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AMRhSzj3fzWy for <ipv6@ietfa.amsl.com>; Sat, 3 Jun 2017 08:47:43 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEA8129535 for <ipv6@ietf.org>; Sat, 3 Jun 2017 08:47:41 -0700 (PDT)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v53FlZY5064936 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jun 2017 16:47:36 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5932DA16.9040008@foobar.org>
Date: Sat, 03 Jun 2017 16:47:34 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.14 (Macintosh/20170515)
MIME-Version: 1.0
To: Tom Herbert <tom@herbertland.com>
CC: Job Snijders <job@ntt.net>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <CALx6S34y1ZS95dD6Qv5A90RnKwh2NqC=VDaZ2vSq+zpo5+NpUg@mail.gmail.com>
In-Reply-To: <CALx6S34y1ZS95dD6Qv5A90RnKwh2NqC=VDaZ2vSq+zpo5+NpUg@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PrA5RQ0ilrs3O5X3N9H8UEgVPn4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jun 2017 15:47:45 -0000

Tom Herbert wrote:
> Thanks for the draft. I think the case will be bolstered with some
> real examples as to how fixed /64 interface addressing has proven to
> be problematic. Using identifier/locator split in addresses as I
> mentioned is one example. I suspect there are more that could be
> documented.

Tom,

let's say your device is assigned a /64, e.g. either on a mobile network
or via PD.  Your device sits between upstream and downstream devices and
passes traffic between upstream and downstream.

Forcing /64 means that your device is limited to bridging mode, because
downstream devices would not be permitted to assign a netmask of longer
than /64.  This could seriously adversely impact on network connectivity
options for downstream devices.  E.g. multiple networks sitting on some
homenet.

Would this fall into the category of examples that you're talking about
here?

Nick