Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

Lorenzo Colitti <> Wed, 12 March 2014 11:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2D8CC1A093E for <>; Wed, 12 Mar 2014 04:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.925
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bITstNDlU_zs for <>; Wed, 12 Mar 2014 04:24:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22b]) by (Postfix) with ESMTP id 4C4611A0937 for <>; Wed, 12 Mar 2014 04:24:00 -0700 (PDT)
Received: by with SMTP id hl1so14017036igb.4 for <>; Wed, 12 Mar 2014 04:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C3XjHm4+krCZlCa8yjsWwMdyNOizI5qcyp4f3g3XoMs=; b=inW0SIyUyhkiHf8t7Y7C9f0+xE9AQdfTtXoRmRE4BPJvIyPuvRZVTpc9VCeiEwWmEg DsgUxQEBli+AcuQuimbA+lxno2zI96eRFH0zq45pHcNsbIXmSS9A9Yn+9cELs4ckuagk dOuCcFll9tmmNpuQOSTPh6iOKlLZCS1Le77CWkIew3oQDnvTQO0quJ3uc6gJJzcehCdr /0At3U2wQw9ItsyIb98dcXBVTJnyFc/Cx86hHREv8uwxFl2B/eo9zfP743qAHmODJp0H LAW2f6akuRWUaKSPyzm3WTZkidbpUyJXqt03ElYbS2/b0H+xxNYWvI8qWHebmo7nugzy Ru7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=C3XjHm4+krCZlCa8yjsWwMdyNOizI5qcyp4f3g3XoMs=; b=kkxE6r6YAw68HCRnRLzNmY9PeWx5s3FecX0iuA3huE7xkdiGn0y3m9PB51+RXg9kpS rzS5BLXhH/KsQPaeYA8bH8e3Iynqr3NCc7r0xYn/UDUeqUc94WZ5nghqZygJGP73FMqe 5P+4EopOxsNxQDburQ48ZC8kcrsJu5JrArbXjhoRAN2k5yjx7+ljrHf6BeiZnWiTevrd YOecBaB4lNxQI304ERGF/r58+kuqjs/g0R6TiNNIzYUzAO5sXeoNqYxKXGX3XFX0tSgI 3MU7Lv9gjuMexLYhxOtpr/IZWajmzAc4eudLvZu5C4Oj5XqlJMMWRAe1kLCwUCGVB5mV 1o3w==
X-Gm-Message-State: ALoCoQnDwGKClgE6ybxCnjnxqV5a1FOVFvf06vpIHKrPEXASYc1qNNflOClkfJuBSDmIuJUzBeVkW1sQ59ggCdbj5EQkINQt/qjr08JDg2jS0dXB7NFRlCs+EhqXspLazoD4K+KsL+m5QdJ4Hj2AvRAdgyzFDDKKNiiEDS0VIoJgdBKMIF7FM5gAhvDMKZ54UmL/XGnzKVLn
X-Received: by with SMTP id e6mr35674178icb.29.1394623433609; Wed, 12 Mar 2014 04:23:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 12 Mar 2014 04:23:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Wed, 12 Mar 2014 20:23:33 +0900
Message-ID: <>
Subject: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64
To: David Farmer <>
Content-Type: multipart/alternative; boundary="f46d04190e625b450e04f467126b"
Cc: 6man WG <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Mar 2014 11:24:02 -0000

On Wed, Mar 12, 2014 at 4:39 AM, David Farmer <> wrote:

> However, if we agree that the IPv6 architecture is designed to be VLSM;
> combined with the fact that ND has a prefix length field; then while IIDs
> are currently specified to only be 64 bits, it seems implicit that other
> IID lengths are anticipated by the architecture.
> Therefore, unless the conclusion proposed is that there should never be
> IIDs other than 64 bits, which I believe would also be beyond the scope of
> an informational RFC as well, I would like to suggest we consider the
> conclusion of the draft as a problem statement in that most implementations
> seem to ignore any IIDs other than 64 and this will be a serious forward
> compatibility issue if other IID lengths are ever specified in the future

Well, but people might not agree that that's a problem. For example, I
happen to think it's acceptable and perhaps even desirable to not allow
IPv6 addresses to have prefix lengths between /65 and /126.

If others agree with me, then it's possible we won't be able to get
consensus on that problem statement, and therefore we should just maintain
the current content of this draft as "this is the current state of affairs,
and here's why it was designed this way".

Note: I happen to think that there are good reasons for this split, and I
would love to see the draft say "we believe /64 is the right way to go
because...", but realistically, I'm not sure such a statement would gain
consensus either :-)