[v6ops] Idea about updating RFC3849

"Jens Ott - Opteamax GmbH" <jo@opteamax.de> Thu, 14 May 2015 08:02 UTC

Return-Path: <jo@opteamax.de>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 53FEA1B34FC for <v6ops@ietfa.amsl.com>; Thu, 14 May 2015 01:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.14
X-Spam-Level: *
X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZCfitv2HCGZk for <v6ops@ietfa.amsl.com>; Thu, 14 May 2015 01:02:17 -0700 (PDT)
Received: from mail.opteamax.de (mail.opteamax.de []) (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 7819D1B34F5 for <v6ops@ietf.org>; Thu, 14 May 2015 01:02:17 -0700 (PDT)
Received: (qmail 28281 invoked from network); 14 May 2015 08:26:45 -0000
Received: from unknown (HELO berck.opteamax.de) (jo@opteamax.de@2001:67c:64:49:6257:18ff:fe64:b1b2) by mail.opteamax.de with ESMTPA; 14 May 2015 08:26:45 -0000
Message-ID: <55545683.6070202@opteamax.de>
Date: Thu, 14 May 2015 10:02:11 +0200
From: "Jens Ott - Opteamax GmbH" <jo@opteamax.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: v6ops@ietf.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/l8QaH4tvBKODmkZk4-j44w9jmOk>
Subject: [v6ops] Idea about updating RFC3849
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 08:02:19 -0000

Hash: SHA256

Hi Mailinglist-Members,

I am pretty new on this list, so I first wave a "Hello" into the
round... and immediately continue to ask the question, which led me to
subscribing to this list. Apologies if I chose the wrong list, please
advise me, where to put my question in this case.

I work as consultant and already accompanied several IPv6 roll-outs
from the first idea "we want V6" until production. While
enterprise-setups are mostly /32 or less IPs, I see more and more
rollouts which need much bigger space.

At least in RIPE-Region, each LIR can receive a /29 without any
justification. And here is where my problem starts. While writing
documentation and addressing-plans before requesting the actual prefix
at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in
RFC3849. But what to do for bigger nets (lower bitmasks)?

Before starting to push the ball on the field by writing a proposal,
I'd be happy to hear if there is support in the community for updating
this rfc and officially define a bigger prefix for documentation.

As said, if I chose the wrong mailinglist or simply started bringing
my idea into the community in a wrong way, any advise and comment is
appreciated. I have no experience with the processes at ietf yet.

Best regards and thanks
- -- 
Jens Ott

Opteamax GmbH

Simrockstr. 4b
53619 Rheinbreitbach

Tel.:  +49 2224 969500
Fax:   +49 2224 97691059
Email: jo@opteamax.de

HRB: 23144, Amtsgericht Montabaur
Geschäftsführer: Jens Ott
Umsatzsteuer-ID.: DE264133989
Version: GnuPG v2