Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

Gert Doering <gert@space.net> Thu, 23 February 2017 19:07 UTC

Return-Path: <gert@space.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD37D1297E7 for <ietf@ietfa.amsl.com>; Thu, 23 Feb 2017 11:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 eP5lWikNIB04 for <ietf@ietfa.amsl.com>; Thu, 23 Feb 2017 11:07:34 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E6D12987B for <ietf@ietf.org>; Thu, 23 Feb 2017 11:07:33 -0800 (PST)
X-Original-To: ietf@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0FDA4617B1 for <ietf@ietf.org>; Thu, 23 Feb 2017 20:07:31 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 84BF6602C7; Thu, 23 Feb 2017 20:07:30 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 7780170D93; Thu, 23 Feb 2017 20:07:30 +0100 (CET)
Date: Thu, 23 Feb 2017 20:07:30 +0100
From: Gert Doering <gert@space.net>
To: Nick Hilliard <nick@foobar.org>
Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets
Message-ID: <20170223190730.GL2367@Space.Net>
References: <58AF313D.3020905@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <58AF313D.3020905@foobar.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fSaekTarchElvPVJCPsThzwONXU>
Cc: IPv6 Operations <v6ops@ietf.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 19:07:36 -0000

Hi,

On Thu, Feb 23, 2017 at 07:00:13PM +0000, Nick Hilliard wrote:
> as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit
> the implementation of any interface netmask != /64:
> 
> >                                           However, the Interface ID of
> >    all unicast addresses, except those that start with the binary value
> >    000, is required to be 64 bits long.
> 
> This has substantial operational consequences in the ipv6 world because
> if it's implemented as stated, it will cause production ipv6 networks to
> break.

Unless I'm totally mistaken this wording has been in "the appropriate
RFC" (4291?) since the beginning of time.

Well, 4291 only mentions this in passing, and points to 3587 [GLOBAL], 
which points to [ARCH] with this sentence

   [ARCH] also requires that all unicast addresses, except those that
   start with binary value 000, have Interface IDs that are 64 bits long
   and to be constructed in Modified EUI-64 format.

[ARCH] is 3513, and states

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

which very much sounds like the sentence above.


> The ipv6 operational community may have opinions on the wisdom of
> mandating new behaviour which would cause their networks to fall over,
> so it would probably be a good idea to notify v6ops@ietf about the
> existence of this draft so that the folks over there get a look-in
> before a consensus call is made. As far as I can tell, this notification
> never happened.

It's not a new mandate - but doing this document, a discussion might
be in order on whether it should still be worded as strictly.

But since nobody seemed to care for the last 14 years (3513 is 
standard track, published April 2003), why should people or vendors
bother to follow RFC mandates now...?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279