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
> --------------------------------------------------------------------