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

Lorenzo Colitti <> Wed, 22 February 2017 03:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 044C9129531 for <>; Tue, 21 Feb 2017 19:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HEw6HBhgtSpI for <>; Tue, 21 Feb 2017 19:00:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15F2C129518 for <>; Tue, 21 Feb 2017 19:00:41 -0800 (PST)
Received: by with SMTP id k127so90867198vke.0 for <>; Tue, 21 Feb 2017 19:00:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vaJdM2IoGtbKS1URHOZYaWinu9P3MfvfUFXo5gvu4IE=; b=EgasqFjiVkJgGH+EOLh70Rav44yhJvwNV/vjQFgdRXNdRhWV8CkV7ZlZuoqjDPyrey CYRtdK18dPSQMT5gVXdkT8Gc+Hg5aj5mPump9y+LhTEx8A30FdsBPIJOkD9Q0lcV5f/O ZiWWZZwiABBYHV7trcT+qJk7nAbTPuawovEsl1X8WNzt4CCTAy3osxl60hurGHluT9ac or0lyCZX1Ris5jc2E02IBJxgxx36wKnkI8XwHrY3WxrbRR6FNRHGQrTPQIETn1WfKQM5 j6UWJbSQwfNf/yDYRMkDrLly31cF8SpVpKoUsYwzMTtEhIA9swMDSx9MXD7cgHsd3Nly jSmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vaJdM2IoGtbKS1URHOZYaWinu9P3MfvfUFXo5gvu4IE=; b=SXvpJXV/VAckgRfWruGWT6kyrnKr3q79aPkIK4YY24NA/RzVMmwaByA/zdLJ0XJZFz HBAqjsG2zSPXkAnonNsu2hxRv0DqAu1BxsmTzfrLQ2Y0uDX9atiZb6pYS2sfbOnOdJcH eahT5PuiIxollUu6jp1xR+kJVbscA5m8+poY3MorH+o4jOSSpGPJjDt5LZ5XI3Lw2jaS W19lYZSIv8ztXII1EU9hI7uuv1cjH1oswwXSqH8bbfzWcwGBNxfEH58ZYz+mdPXJzH/2 7XeJ0J0PD5G/xhFw7W3t0wT6ZXtT4Vx3CMyXxyJXgOUFacQ61PEdLeVow9P3D1beAgnw u0xA==
X-Gm-Message-State: AMke39lG18lk34kWtr7uPrLkaELtWyhfyZ90u/uY3etFRVL8nXXV+CImL6CMhvnOl6ilMP6Ce2/1D33WQ1409RR8
X-Received: by with SMTP id t15mr12832578vke.6.1487732439988; Tue, 21 Feb 2017 19:00:39 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Feb 2017 19:00:18 -0800 (PST)
In-Reply-To: <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark>
References: <> <> <> <> <> <> <> <> <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark>
From: Lorenzo Colitti <>
Date: Wed, 22 Feb 2017 12:00:18 +0900
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Job Snijders <>
Content-Type: multipart/alternative; boundary=001a114322509ba963054915b3a9
Archived-At: <>
Cc:,, 6man WG <>, IETF-Discussion Discussion <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Feb 2017 03:00:43 -0000

On Wed, Feb 22, 2017 at 10:50 AM, Job Snijders <> wrote:

> Those "thousands of interconnections" facilitate the communication between
> millions of those hosts.

But the configuration cost and management overhead is not proportional to
the hosts that are served by those interconnections, it is proportional to
the number of interconnections. A 10x100G peering interconnection that
serves X million hosts is one interface that has to be managed.

Have you considered that not all interconnections are equal? The type of
> interconnection I am mainly (but not exclusively) referring to is the
> interconnection between Autonomous Systems to facilitate the exchange of
> routing information using BGP-4. Autoconfiguration plays no role here,
> everything is configured explicitly. I'd argue that the use case is hardly
> comparable with a residential or mobile connection.

Those use cases are very well served by /127 for PNIs and /64s for Internet
exchanges. What's left?

As pointed out in this thread, real networks use all kinds of prefix
> lengths. Also, one doesn't renumber everything every time a new document
> comes out - you stick to things that work for you.

As discussed above, most links use /64.

Some vendors in this thread have admitted to strive to make things work
> with any prefix length, why is there then still a discussion that people
> must use /64 - when both vendors and users are not always doing so, for
> good reasons?

You're forgetting about host operating system developers and host users,
both of which benefit substantially to having a subnet size that is always
the same and never runs out of addresses.

I'm confident this discussion will eventually resolve itself and conclude
> that /64 is not the only valid prefix length, rigid positions rarely are
> attainable. Water can flow or it can crash.

Even if you're right, the place to have that discussion is not on this