Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
Mark Smith <markzzzsmith@gmail.com> Sun, 04 June 2017 03:51 UTC
Return-Path: <markzzzsmith@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 2FA491294B8; Sat, 3 Jun 2017 20:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 gId7hSDYsHyz; Sat, 3 Jun 2017 20:51:26 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 4DD55129482; Sat, 3 Jun 2017 20:51:26 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id h39so7246520uaa.3; Sat, 03 Jun 2017 20:51:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3+JceK5EaXLcVC+LzGZAV8OWGwzjglus8V60iYAlRxM=; b=ns/SxZvFj2YxnQYMddna+vH+WjpZZHr3/gh7rq5rszlqnzEdSCsSwsi4FWTHZ7FrEz 0roVnftR2taMKn8SskzTpwUwJYvSbQjeRfs7i+SIt6olpLBn3psLlMdqWohiaTUofhz+ u6MOE7k96ML9ipw59mm4fuHdQzhTxwpd1g8av4dNvmxk5b1sc3NYgkHmgjc8xYlPNhUG NBSDcTJgmfGOlK29yyaj9aMxPF3hqXrCrsXrX+D+V3hO0VTJIXngvIK++xrHSqq1Dc8T I3eVSjtejT62Qi5X1urVC7YylXw/eBS70yDulsfLy+iQxeelCcBGq66Nh2FfJwOPKjCW sENg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3+JceK5EaXLcVC+LzGZAV8OWGwzjglus8V60iYAlRxM=; b=Xo4rjn7pw3LtBpwYUvMJob+AEopAJOh+hkwHRS3w4BegHOzvkVAH4VJus5Kzh3nqzc ghQsQWS2nhUxbTCqIFma5vNsVnfwTy9XQqJTZ6z90u43BioZZNqFDg/ch6jLbX6r4sMD oJRD1DpgVbsVaFV/G6BxNg1S/KWsioZT0eNru6ZO6tKxmcAwMB7FDh6GHbsJPxZzvCUK gaU6z+GDcc/jqyEhVjopFUSDtVkfdC01jTh5reoFXWO4JjU+cg+7tvMInfXzq7W8sAl7 4xqRxu1/8KkLTscx57fVtOQXxQo2AIQIhARtRcUIycAgqh0Wwm/bBh1aFobL68DGk33Q aa6w==
X-Gm-Message-State: AODbwcBkv6yZNiJGjGQ0ezwYybibi7od8bDQLFhgzJsBAIRoPjPNYoC5 U15PxXPHDOX6UI2yEfrAhcDXD07Wwg==
X-Received: by 10.176.27.84 with SMTP id n20mr8029510uai.125.1496548285306; Sat, 03 Jun 2017 20:51:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.86.29 with HTTP; Sat, 3 Jun 2017 20:50:54 -0700 (PDT)
In-Reply-To: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com>
References: <CAO42Z2wp72j-yOsR8C=iqS+dX14wLwthAtOTvD5ugj_NQ=NQag@mail.gmail.com> <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 04 Jun 2017 13:50:54 +1000
Message-ID: <CAO42Z2ypf-4bJ1q1eqo9NOfWzEs2VFkwxvUj+u+GqSbatvyHmw@mail.gmail.com>
Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man <ipv6@ietf.org>, draft-bourbaki-6man-classless-ipv6@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ba0Z8fgxfIaFiwIkfStl8J2_KMg>
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: Sun, 04 Jun 2017 03:51:28 -0000
Hi Brian, On 4 June 2017 at 06:43, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > On 03/06/2017 15:23, Mark Smith wrote: > ... >> If this proposal is accepted, then I think /120s will become the >> defacto subnet size, despite what the draft says about /64s being the >> recommended default. > > Predicting the future of complex systems is hard, but I think this > prediction is wrong. Thinking about it more, I'll lessen that - I think this draft increases the likelihood of it occurring. If you know IPv4, and you don't want to or don't have time to properly learn IPv6 (which seems to be one of the motivations for this draft), then here is the easiest way to deploy IPv6 without understanding IPv6: 1. Take your IPv4 address in IPv4 format, leveraging your existing IPv4 addressing plan 2. Prepend it with the IPv6 GUA or ULA 96 bit prefix 3. Subtract the IPv4 host bits from 128 and append e.g., the resulting IPv6 addresses for 1.2.3.4/24 would be 2001:db8::1.2.3.4/120 That format address is accepted on loopback when I use the Linux 'ip' and 'ifconfig' utilities and I can ping it, so it has passed the first "can I even configure it" test. If it works on other IPv6 implementations, this way of deploying IPv6 while avoiding learning IPv6 could easily become popular because of its simplicity. > There are some very strong arguments against > prefixes that long, and it is the IPv6-over-foo specs that prevent > such long prefixes being used. > I agree, however I don't think this draft is discussing and emphasising them enough. For example, here is how I interpret a piece of the text in the Recommendations section (which is going to be the section people in a hurry will jump to) "For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended [RFC7136]." "For historical reasons" implies the only reason to continue with /64s is tradition, as though the situation has changed so much such that all of the past reasons for having /64s/64 bit IIDs now don't apply. "barring other considerations" That might seem to be the warning to make sure you understand the decision you're making, however there is no brief description or reference to those considerations. Initially I thought RFC7136 was the "why-64" RFC you and others put together, which does outline those sorts of considerations in a 64 bit IID context, however that is RFC7421. RFC7421 isn't referenced by this proposal anywhere, yet it is the key document that describes many things about 64 bit IIDs and their benefits as well as mentioning some of their drawbacks. The next paragraph text is further narrowing the scope of advice to just SLAAC. What about address assignment via stateful DHCPv6? Do general privacy and security concerns about IPv6 addresses go away entirely if stateful DHCPv6 is used? (Actually, stateful DHCPv6 can introduce them - OpenWRT supports it and uses the same sized IID range for DHCPv6 as it does for DHCPv4 addresses. Until I recently worked out how to turn it off (because that isn't obvious either), my Fedora hosts with wonderful RFC4941 and EUi-64 global addresses via SLAAC also had global IPv6 stateful DHCPv6 addresses from within a range of 100 addresses.) Another example is in the Security Considerations section: "Assuming that nodes employ unpredictable interface identifiers [RFC7721], the subnet size may have an impact on some security and privacy properties of a network. Namely, the smaller the subnet size, the more feasible it becomes to perform IPv6 address scans [RFC7707] [RFC7721]. For some specific subnets, such as point to point links, this may be less of an issue." This paragraph leads with a broad statement about security and privacy concerns, of which there are more than one as detailed in RFC7421, and then dismisses them all ("Namely,") to only describe the one threat of unsolicited inbound address probes. What about host or end-user security and privacy impacts when RFC4941 temporary address and RFC7217 stable opaque addresses operate with much smaller IIDs, or a caution against using IIDs smaller than e.g., 48 bits if end-users are to have RFC4941 addresses? These issues now need to be addressed because of they're all based on assumption of 64 bit IIDs. I think I can summarise the situation, and this draft and my view on it: - RFC4291, although not using RFC2119 capitalised words, is saying that IIDs MUST be 64 bits other than addresses that start with 000. Some people are objecting to the MUST. - This draft is commonly leading with text that reads or can easily be interpreted that this 64 bit MUST is being turned into a MAY on nearly equal terms with any other prefix length e.g., the Recommendations text above. I find further following advice in the text to understand the consequences of doing so is somewhat casual, and doesn't spend much time explaining and doesn't reference what those consequences and considerations are. - I don't think the "default" recommendation is strong enough. I read the default recommendation (in the Recommendations section) here to be saying something close to, "If you've read the text and don't already have chosen size, use a /64", because of use of soft expressions such as "For historical reasons". It reads like the fallback advice if you reach a point where you don't already have a preferred or chosen answer you're happy with (like,"I'll use that simple IPv4 to IPv6 scheme Mark Smith wrote about that saves me properly learning IPv6."). - If the /64 isn't going to be a MUST, I think /64 needs to be a universal SHOULD level and better emphasised at that level because of the code, privacy, security, etc. reasons that are well known and described in RFC7421. The text is currently reading more that its perspective and position is that a /64 is a MAY with some minor cautions due to either casual text or omission. Regards, Mark. > The IPv6 routing architecture has always been CIDRised. Please > remember that "ID" in CIDR stands for "inter-domain". So there > is nothing new there; even BCP198 was nothing new. > > IMNSHO we made a basic mistake by including the value of n in the addressing > architecture. > > That's the n in >> | n bits | 128-n bits | >> +-------------------------------+---------------------------------+ >> | subnet prefix | interface ID | >> +-------------------------------+---------------------------------+ > > All this draft really does is observe that n is a parameter. It could > be said in many fewer words, I suppose. > > If we'd been able to agree on simply removing n=64 from 4291bis, > I wouldn't have put my name on this draft. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Deprecating IPv6 (Re: draft-bourbaki-6man-classle… Mark Smith
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Chris Morrow
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… David Conrad
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Simon Hobson
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Carsten Bormann
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Job Snijders
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Roger Jørgensen
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Brian E Carpenter
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Brian E Carpenter
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Mark Smith
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Brian E Carpenter
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Matthew Petach
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Mikael Abrahamsson
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Randy Bush
- Re: Deprecating IPv6 Havard Eidnes
- Re: Deprecating IPv6 Randy Bush
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… james woodyatt
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Erik Kline
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Alexandre Petrescu
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… james woodyatt
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… otroan
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Leddy, John
- The waist diameter (was: Deprecating IPv6 (Re: dr… otroan
- Re: The waist diameter (was: Deprecating IPv6 (Re… Tom Herbert
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… james woodyatt
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Fred Baker
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… james woodyatt
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… james woodyatt
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Ca By
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… james woodyatt
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Don Sturek
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Brian E Carpenter
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Fred Baker
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Simon Hobson
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Mikael Abrahamsson
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… james woodyatt
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Mark Andrews
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Lorenzo Colitti
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Simon Hobson
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Leddy, John
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Mark Andrews
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Fernando Gont
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Simon Hobson
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Carsten Bormann
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Mark Andrews
- Re: Deprecating IPv6 (Re: draft-bourbaki-6man-cla… Simon Hobson