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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 24 February 2017 08:16 UTC

Return-Path: <prvs=1228d0687a=jordi.palet@consulintel.es>
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 4DF5C12957E for <ietf@ietfa.amsl.com>; Fri, 24 Feb 2017 00:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 vg9qqGi7fBpc for <ietf@ietfa.amsl.com>; Fri, 24 Feb 2017 00:16:09 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487EF1293F9 for <ietf@ietf.org>; Fri, 24 Feb 2017 00:16:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1487923967; x=1488528767; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=z6tVewotDTpHumkSMjftf5FjL 4K8e8oMpUJ1pC8/l0E=; b=TGSuBv4iemK42GHaVoSTAAhv3YXJ5ew76+hEQvEr3 LjQUR2w40vZCPnZ59MdiSE9zwsNQ6CJhbwCqa8Y1fGrCGpn6rdrqNc/2esIin0Ca M3ZQKUzwkpFrvVfLSc8k/b5qTTiKQ38YKrch1gQyYhNbXRJ05ITOcgON0dJJDWW1 LA=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=f/RWR1bMrqMJjWUDI/PoaeZ43DOmvn7AA9VoZy+hCBpOsKU0KNQggaxxa0id pplF6avUJZCsi6bFN8PR3623X815vP4QwmOSWInKs70WDX+1SGPZ1ley9 WoZ6mbLzfUQz9Iv1nsa9230efZCi5XozxVUoFKZsOuv9PeVsdNTmYI=;
X-MDAV-Processed: mail.consulintel.es, Fri, 24 Feb 2017 09:12:47 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 24 Feb 2017 09:12:47 +0100
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005373437.msg for <ietf@ietf.org>; Fri, 24 Feb 2017 09:12:46 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170224:md50005373437::ELeEBc8fXQBnK+Vs:000026QP
X-Return-Path: prvs=1228d0687a=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
User-Agent: Microsoft-MacOutlook/f.1f.0.170216
Date: Fri, 24 Feb 2017 09:12:45 +0100
Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 Operations <v6ops@ietf.org>, IETF <ietf@ietf.org>
Message-ID: <4BC61E42-0A36-44E9-8FB9-2062547D939F@consulintel.es>
Thread-Topic: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets
References: <58AF313D.3020905@foobar.org> <CAO42Z2ymnLm9dUNL3doU9+vR0eMzGbr71HQybbibXq9rCObP3A@mail.gmail.com> <21A9AEAE-330D-47F3-88CA-FC845C71AED0@darou.fr> <20170224075940.GW2367@Space.Net>
In-Reply-To: <20170224075940.GW2367@Space.Net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/z3lEyC7PMn4kP0GEnRSJQGKEDAI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
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: Fri, 24 Feb 2017 08:16:11 -0000

I wonder if anyone knows (or if there is an easy way to check, I doubt), if other STD documents have similar situations.

I mean, we define STDs, it takes long time to do so and meanwhile is still an RFC or even after a document is already an STD, there may be text sections that don’t reflect market reality, or some very specific exceptions (such as in this case /126-/127), that make sense (or not), but in any case, the STD is not being modified again and again.

I’m sure this happens in any kind of documents in other business and life fields, for example, there may be generic laws, and afterwards, the generic law is not modified for many many many years, but “exception rules” are created for those laws.

So, are we spending too much time in this and is not really necessary?

Can we live with the actual text with has been in the market, and working well, for “x” years?

Can we make too many (or few very important) changes in an RFC in the way to STD, or we need first to have those changes in an RFC for “x” years and “n” verified implementations, before we move to STD? If the answer is no, is the balance between living with the current text but moving to STD a better option than waiting for “x” years again?

Regards,
Jordi
 

-----Mensaje original-----
De: ietf <ietf-bounces@ietf.org> en nombre de Gert Doering <gert@space.net>
Responder a: <gert@space.net>
Fecha: viernes, 24 de febrero de 2017, 8:59
Para: Pierre Pfister <pierre.pfister@darou.fr>
CC: IPv6 Operations <v6ops@ietf.org>, Mark Smith <markzzzsmith@gmail.com>, IETF <ietf@ietf.org>
Asunto: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

    Hi,
    
    On Thu, Feb 23, 2017 at 11:43:52PM +0100, Pierre Pfister wrote:
    > >>>                                          However, the Interface ID of
    > >>>   all unicast addresses, except those that start with the binary value
    > >>>   000, is required to be 64 bits long.
    > >> 
    > > 
    > > The thing is this is not new text, it has been in RFC4291 for 11
    > > years. c.f., 2.5.1.
    > 
    > And during those 11 years. Nobody implemented this rule specific to ::/3.
    
    The point is not "specific rule for ::/3".  The point is that this is a
    explicit rule for all that is *not* ::/3, with an exception(!) for ::/3.
    
    ... and still there are other RFCs that permit /126 and /127, so this
    definitely needs rewording to match current reality.
    
    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
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.