Re: Why /64

Jeroen Massar <jeroen@massar.ch> Mon, 28 October 2013 09:11 UTC

Return-Path: <jeroen@massar.ch>
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 3488121F9FF3 for <ipv6@ietfa.amsl.com>; Mon, 28 Oct 2013 02:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.523
X-Spam-Level:
X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNVwkSElasud for <ipv6@ietfa.amsl.com>; Mon, 28 Oct 2013 02:11:22 -0700 (PDT)
Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 03F7B21F9D5E for <ipv6@ietf.org>; Mon, 28 Oct 2013 02:11:13 -0700 (PDT)
Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 35DAA801C2A2; Mon, 28 Oct 2013 10:11:05 +0100 (CET)
Message-ID: <526E2A2E.7030206@massar.ch>
Date: Mon, 28 Oct 2013 10:11:10 +0100
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: Wuyts Carl <Carl.Wuyts@technicolor.com>
Subject: Re: Why /64
References: <20131021224346.32495.64932.idtracker@ietfa.amsl.com> <52695DDE.70909@gont.com.ar> <526AA24F.6010609@gmail.com> <526AACA5.7090604@si6networks.com> <E0F0D3DE-D31B-4CC2-9384-DFEBCCB8F557@ecs.soton.ac.uk> <EMEW3|9f43bef2fe7433173858819bd0eeee2dp9OKUJ03tjc|ecs.soton.ac.uk|E0F0D3DE-D31B-4CC2-9384-DFEBCCB8F557@ecs.soton.ac.uk> <526AC8AF.4060608@si6networks.com> <8C48B86A895913448548E6D15DA7553BA7B978@xmb-rcd-x09.cisco.com> <CAKD1Yr0q2dY041CMarFfTZZx6=qHC-eJ+74qgiHP-dt7+ga7yg@mail.gmail.com> <526CDC59.4070204@massar.ch> <526D3706.5070409@alvarezp.ods.org> <526E1F5A.2070901@massar.ch> <3135C2851EB6764BACEF35D8B495596806FAC25D4E@MOPESMBX01.eu.thmulti.com> <526E244B.1030103@massar.ch> <3135C2851EB6764BACEF35D8B495596806FAC25DCA@MOPESMBX01.eu.thmulti.com>
In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FAC25DCA@MOPESMBX01.eu.thmulti.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "<ipv6@ietf.org>" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 28 Oct 2013 09:11:30 -0000

On 2013-10-28 09:53, Wuyts Carl wrote:
> Ok, thx for the update. I don't think that you're the "default/avg"
> user here :-), hence I don't believe they will use your setup as an
> example to set for a specific ia_pd prefix length. I agree there's
> plenty of space, but lots of ISPs claim people said the same in IPv4
> era, hence are cautious to set it "too big".

We can't teach people to learn math nor can we teach them to think of
routing slots and the fact that aggregation makes things so much easier.

We also cannot teach people who are in the networking business and who
request the prefix they get from their RIR to request a large enough
block, and then are 'we are running out of space' or funnier, make
comments about other ISPs getting large blocks as they did fill in the
paperwork. The allocation lists show clearly that several ISPs have
upgraded their prefixes to much larger sizes than the default /32 over
time though; thus hopefully this happens before there becomes a need to
do multiple disjunct /32s per ISP, though several have already gone for
that model to 'cover the world' or 'being able to deaggregate per
continent'.

Like in IPv4 there are also already several ISPs again who are limiting
the amount of time that a IPv6 delegation is routed to a single user,
and they cycle it on regular basis; hence the user not receiving a
static prefix and thus having to renumber all the time and thus it being
quite annoying.

These primarily are all business decisions though, little the IETF can
do about unfortunately. There is enough documentation out there, the
people in charge will go their own way without heeding the advice of
their fellow networkers...

> Anyway, I must say to see lots of /56s, so looks ok in lots of
> occasion, but for sure no global consensus / approach on this, I see
> anything between 64 and /48 for the home being used today.

In the ARIN region ISPs are supposed to do at minimum /56, as this is in
the allocation guidelines. Similar allocation guidelines exist for the
other RIRs.

Unfortunately there is no 'forced' requirement from the RIR and ISPs
thus end up picking whatever they deem good for them.

Greets,
 Jeroen