Re: A Plea for Architectural & Specification Stability with IPv6

Lorenzo Colitti <lorenzo@google.com> Thu, 13 March 2014 14:28 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3691A09E6 for <ipv6@ietfa.amsl.com>; Thu, 13 Mar 2014 07:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 V8UP9vlACZli for <ipv6@ietfa.amsl.com>; Thu, 13 Mar 2014 07:28:24 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ED2401A09DA for <ipv6@ietf.org>; Thu, 13 Mar 2014 07:28:18 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id rp18so1028023iec.19 for <ipv6@ietf.org>; Thu, 13 Mar 2014 07:28:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cLYqoGg9sgc8YMFeiyBRqNnDxrOwj6AU0mrbXopDsug=; b=NRXv37MHULqaFlNcYNQCGq0Gj+px9gNOD11wRxz8lkS6jrEtNCe26H4yVqTIcgrTrX usFGMG2/d0OxJ/76ubgufR1V56YEL4YZ4GSzgn/67dn4HNRnIUPjpUnA3SBaSmnRqCXc 7/wAwT4JVNPsISR4cHlQ4pkBGgEFZGh8rnGxjpFiGYfnJbJhjgYcx39cjw561CacFSNk L5wyAtGKGV+pDdMTzZJ/uTnZJ/POiYVJdMqQVQhv8XyBULyY5qL+nB8tDFNXrPcv09ca crDzFpcz+hRlCgg3FwEE5Pjwi4pMdxOscMef95Hm+phtNjL1SVDiLkQO/21ibGq/rWNv tf/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cLYqoGg9sgc8YMFeiyBRqNnDxrOwj6AU0mrbXopDsug=; b=EwwottcrsIPi7V7AJo5CD5f5VoENuOuiWB4SPjqVAmYZAXu4kY6HlxG8KnBrmwXN3m i7xAS0i/zbEYcEoW1XIxAxV3s445X/R6yz6LQGho2j9NuD/j2FTYroOqhJhqG+nL9ElL FZB0c60osfJPtHQo/Z20/jhj2UnYv/j9GJBrHaOHLPczaKEhMAUr4QWApFeaNpkhp18j RoJihc66UGzF0fTp/LYfLuKG9I1sr2PUoyJ9cGkOjB9VpFrbeSbRXuPN7xsHPEwKXR1f 1E0uGZN+vF8fnUCD1J4hysN3XgazN2Icv7Hy2LqAXBqWDBLr0OvQTG8elN9udLfFZXh/ LSbw==
X-Gm-Message-State: ALoCoQlsZkY4Dbfdj1HNkCwNacR+NUx1id+MXnX5yeixp37ohwpOYWsTliBmUE/98mOWY8ii7gTcsRYn7W8F6MqN87KdVsdtVhw4tRCfCIJgKhNgb0LSD1GtSDN4auSr1Xg14L/ExlDkvj4yb7ZStfLYGj95w6t8ETbsQTw5wuI9VQpIpDBnQb6vj45mD9ZrUnKzTTQnSnXu
X-Received: by 10.50.225.134 with SMTP id rk6mr2130814igc.31.1394720892405; Thu, 13 Mar 2014 07:28:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.18.136 with HTTP; Thu, 13 Mar 2014 07:27:52 -0700 (PDT)
In-Reply-To: <E2C06D73-99FF-42B5-A3BE-337C307BCB0E@gmail.com>
References: <E2C06D73-99FF-42B5-A3BE-337C307BCB0E@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 13 Mar 2014 23:27:52 +0900
Message-ID: <CAKD1Yr0fjSWfPDkvc9Z53xBKxMGzYcVGzH3tLUGbjCKmgR_Duw@mail.gmail.com>
Subject: Re: A Plea for Architectural & Specification Stability with IPv6
To: RJ Atkinson <rja.lists@gmail.com>
Content-Type: multipart/alternative; boundary=f46d042ac0f45a6f4004f47dc35e
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/q_rgjGpuLX7SXcEw6s8G35_8LeA
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 13 Mar 2014 14:28:27 -0000

On Thu, Mar 13, 2014 at 9:49 PM, RJ Atkinson <rja.lists@gmail.com> wrote:

>   If folks in the IETF IPv6 WG want IPv6 to be more widely deployed,
> more rapidly deployed, and its capabilities to be more widely used,
> then WE NEED TO STOP CHANGING THE IPv6 SPECIFICATIONS.
>

Hear, hear.

For a long time I've believed that int the IETF we think that IPv6 is "not
being deployed" because something is wrong with it. And so we keep changing
it. But that's not the problem. IPv6 *is* being deployed, it will just take
time. At current S-curve growth, we'll be done in 10 years.

The original IPv6 architecture is sound, and the core protocols are
perfectly deployable. They are a solid (though admittedly minor)
improvement over IPv4. There is *nothing wrong* with the IPv6 architecture.
Deploying IPv6 *as it is today* will, after a minor speed bump, lead to
simplification, cost reduction, and increased transparency of a network
that today is cluttered with brittle and expensive middleboxes (expensive
both because they cost money and because they cost developer time for apps
to work around).

It's true that those that want IPv6 to be exactly like IPv4 are
disappointed, because IPv6 is not IPv4. No, you can't do routing without
RAs. No, you can't "save addresses" by making host subnets /120s (at least
not easily). No, there is no RFC1918. No, ULAs are not the same as RFC1918.
No, there is no NAT. But I think that in a lot of scenarios those are
advantages, not disadvantages.

When people say that IPv6 can't be deployed in ISPs, in enterprise
networks, in content providers, in home networks, or in mobile networks
because it lacks feature X, we'd do well to remember that there are large
deployments of IPv6 in all these areas. I know, because I've personally
been involved in all of the above. In my experience, excuses for not
deploying IPv6 are, to a great extent, just that: excuses. They have no
relationship to the actual reason for not deploying it, which is, and has
always been, "we see no benefit" (or, to a lesser extent, "our code doesn't
support it", and "our code has bugs" -- both of which are temporary). These
excuses mislead the IETF into thinking that the lack of IPv6 deployment
means that there is somehow something wrong with the protocol. This in turn
causes hand-wringing and standards-writing, but in my experience, that
doesn't help: when we remove an excuse, people move on to another excuse --
because the excuse wasn't the real reason anyway.

Continued tinkering with IPv6 - especially tinkering with it to make it
look more and more like IPv4 in order to reduce imagined "barriers to
adoption" - will just erode IPv6's long-term advantages by eliminating the
simplification, robustness, and benefits that IPv6 as it is today *does*
provide -- and it won't lead to adoption anyway, because lack of adoption
is not a technical issue.

What we need to do now is stick to the protocols as designed and wait until
the combination of ever-increasing pain caused by IPv4 exhaustion, and
exponentially-increasing IPv6 deployment in the Internet at large (or at
least in the consumer space), change the "there's no benefit" equation.
That *does* have the power to cause deployment in a way which changing the
standards will never have -- and as you put it, the more we change now, the
more we *delay* deployment, by causing vendors to write code that then
needs to be waited for, tested, and debugged before operators can deploy.

Personally, I think 6man has the duty to ensure that no radical changes go
into the core protocols until *real deployment experience* -- not of the "I
can't deploy because..." kind, but only of the "I deployed *and it didn't
work because...*" kind -- shows that there is really a gap in
functionality, and even then, to think extremely carefully whether the
long-term effects will be beneficial or not. We're hoping that this IPv6
thing is going to last us for the next 30 years. Let's not get too hung up
on the next 3.


Cheers,
Lorenzo