Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

sthaug@nethelp.no Wed, 15 February 2017 11:14 UTC

Return-Path: <sthaug@nethelp.no>
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 A26A012952F; Wed, 15 Feb 2017 03:14:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 R5IAOD9B002s; Wed, 15 Feb 2017 03:14:19 -0800 (PST)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id A92A0129446; Wed, 15 Feb 2017 03:14:19 -0800 (PST)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 4A06AE6065; Wed, 15 Feb 2017 12:14:17 +0100 (CET)
Date: Wed, 15 Feb 2017 12:14:17 +0100
Message-Id: <20170215.121417.74676483.sthaug@nethelp.no>
To: lorenzo@google.com
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
From: sthaug@nethelp.no
In-Reply-To: <CAKD1Yr3M8n7a5uFTiHmqv5TZj-7ShChRSSseHwYyjwC0X-hREA@mail.gmail.com>
References: <CAKD1Yr3Bt34A0uhujKgfBwf9BHw=nNgnm1DR9o80qrNdvWJ9Mw@mail.gmail.com> <CAN-Dau1Z+_nYJMi_pNSRzpXRO8H8qV5rZApTK6m0_Eg5yCReFA@mail.gmail.com> <CAKD1Yr3M8n7a5uFTiHmqv5TZj-7ShChRSSseHwYyjwC0X-hREA@mail.gmail.com>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5JkI4ivaFW-vY2rdvozyROGyKy4>
Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 15 Feb 2017 11:14:22 -0000

> > I conceded that is probably true for most of the IPv4-Embedded IPv6
> > Address Formats in section 2.2 of RFC6052, but the /96 format seems
> > indistinguishable from other IPv6 addresses with embedded IPv4 addresses
> > described in Section 2.4.5 of this draft.
> >
> 
> Could we say that the IID is 64 bits long "for all addresses except those
> that start with binary 000, and those that embed IPv4 addresses [RFC 6052]"?

This is demonstrably false (there are lots of IPv6 interfaces with for
instance /124 or /126 masks, among others). I don't expect all of these
IPv6 interfaces to be changed to /64 even if an RFC says so.

So the question is, what do you gain by stating this in an RFC?

(I know, the discussion is old and I don't expect any views to change.
It stills seems wrong to publish an RFC with such an obviously wrong
statement.)

Steinar Haug, AS2116