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

Fred Baker <fredbaker.ietf@gmail.com> Sat, 10 June 2017 20:44 UTC

Return-Path: <fredbaker.ietf@gmail.com>
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 5E1CB12944B for <ipv6@ietfa.amsl.com>; Sat, 10 Jun 2017 13:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wxDQ1eWv8Bfh for <ipv6@ietfa.amsl.com>; Sat, 10 Jun 2017 13:44:36 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 CC264129431 for <ipv6@ietf.org>; Sat, 10 Jun 2017 13:44:36 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id a70so35132487pge.3 for <ipv6@ietf.org>; Sat, 10 Jun 2017 13:44:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nghmeaon2qNNHIOXTb0z9FZ450jazrnx/QzI76eH6k4=; b=RxFgkNJpArW6IkvNyMR13EvQXNxoGaCP6aQazv8dG/3kF7iIPpvU56/gmtzMRChEmo uo2CLtXSZzeQOeCTt70BYJcYbxNVRyTrLHBHN7rj6Rx5GzfzK8T7II1REkI9UyjkxG3W 20Ns6ClOup30aQalUqofQkyirNbwSJWg8zcw/0GULkvnOinxl70ttMGPi8uLVDyoxlkw oYt5panQ+TO33roR2EsSfuYCGbtb+U0UIhEie429dZlr4gdvUCZh6AAvK4rm8SXD0p43 cIjiTHC5JMtgclO/HLBaTTWuDPxDGxyJfHOuw04NqoWKZzhDJ+H2jBdwiR/lWm4SR6dw w8RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nghmeaon2qNNHIOXTb0z9FZ450jazrnx/QzI76eH6k4=; b=HJHAQ4HmZJnRPbT37JLcbNBTvMzQI66XbYYEiSVhPa87pw0KAww9fPq14gRpms0lSm rrBhacKMrNx7AJ0g5u0NjgOf/GV/mwXUsOhM0b1Rs7EnKVVjyGDqIG1zK5dW1fGqIEBr 37YO3O0I9p0rM2LnRCQFm1WSRY+QPlyMpBsQaHC4mld7U84dhjwuldaCYxSJzWP22WPj QRaAGlvQvEZJmAml/vFdl6GVwyA418MLcYoWCN/BD5WXL3Y8haBS6r3oxAEFXl0xD6nW bTBxrGkGFIAu5c9HJcKd3Gp7TWRPpN/FhO36PoOSnyjQ4Q/CyI3ovuJF1xC5kc7/d9MV 0WZQ==
X-Gm-Message-State: AODbwcBcd/UWqbGkCJP1Tf3ZCwen3zZpdETPm1fHrq77qNdiJMpESMaf tU/8U5d8WrF36rwEzAc=
X-Received: by 10.99.158.18 with SMTP id s18mr40564377pgd.113.1497127476490; Sat, 10 Jun 2017 13:44:36 -0700 (PDT)
Received: from [192.168.1.12] (ip184-189-217-181.sb.sd.cox.net. [184.189.217.181]) by smtp.gmail.com with ESMTPSA id o2sm9210404pgq.44.2017.06.10.13.44.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 13:44:35 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <CAN-Dau38xD0oZ-0xe3K=VYgwAU25z6ySp7BgMj8HQ2iG96AoRA@mail.gmail.com>
Date: Sat, 10 Jun 2017 13:44:34 -0700
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD7E7E11-7561-466E-91A1-787B72230B3D@gmail.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <CAKD1Yr0DtQYvCYLQexhXe_nhb5rjeyhnB4bCveqyO5Xbuwdg1A@mail.gmail.com> <CAKFn1SEdjhsQ3tKPZdbdfF4ArDzw-FZfjQT68gV55Fc-5vzBvw@mail.gmail.com> <CAKD1Yr3ppM0UF8HoN8PgS7F0iEmK26ebiuJK=tkAdZnuLWpkZg@mail.gmail.com> <CAKFn1SHASt34ihJmGN0iRFQQzLTMspZfxXHgBjBatXXcRYF4cw@mail.gmail.com> <20170604093119.nt733rb3ymmjssww@Vurt.local> <m1dHTLx-0000DcC@stereo.hq.phicoh.net> <CAKD1Yr0ZZwRar6D-2bkXBKPYehqqW99+BMtDOjyovR8WDXKzxw@mail.gmail.com> <CAD6AjGTjikAWutcenW8qn7OW8kPM9c_x_yDUy5vQxJmXKL85dg@mail.gmail.com> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <CAKD1Yr0_WR_TB+OC0U1Qt2h6WzUp9EGvrqC1ZKW2mwFeBd3bCQ@mail.gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <CAKD1Yr1wmY3O9Uxe=KRxzCidpyhn3e0zSnikY0K6LK9ue4OzwA@mail.gmail.com> <71c7286c-0e86-5dbe-f9c2-7d473d1de728@gmail.com> <CAKD1Yr3SUOPd+5H66WPc2ikxauVWVG2ZBjFTHoFOQPCEYTBdiA@mail.gmail.com> <4B891D4C-96E7-42F4-9A38-EBA7B3466BE0@employees.org> <CAN-Dau38xD0oZ-0xe3K=VYgwAU25z6ySp7BgMj8HQ2iG96AoRA@mail.gmail.com>
To: David Farmer <farmer@umn.edu>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sGL0mfZ8NDMj5P8HHbAzuclq11Q>
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, 10 Jun 2017 20:44:38 -0000

> On Jun 10, 2017, at 1:34 PM, David Farmer <farmer@umn.edu> wrote:
> 
> I've been thinking about this for a while and I think the only way to resolve this conflict is to stop using "subnet prefix" in reference to IPv6 and only use it in reference to IPv4. 

Very much agree. That's the reason RFC 7608 calls it a "prefix length". Prefixes, of course, are a routing concept, and where you are in the network affects your perception of the prefix length immensely. RIRs are allocated prefixes by the IANA and in turn sub-allocate them to ISPs and PI prefix holders. ISPs in turn allocate prefixes to customers, and those customers and PI prefix holders end up at some point with LAN subnet prefixes or prefixes on p2p links, and hosts think in terms of /128. There may be other prefix lengths along the way.

The only place it makes sense to me to talk about a specific length for an IID is with SLAAC; if a network is allocating addresses manually or using DHCP, they are in control and can do whatever they like - I dare you to stop them. But the IID is the part that is never a prefix - the last N bits of a /128, and by convention 64 bits.