Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

sthaug@nethelp.no Tue, 10 March 2015 05:24 UTC

Return-Path: <sthaug@nethelp.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A9E1A0111 for <v6ops@ietfa.amsl.com>; Mon, 9 Mar 2015 22:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 c6L2b7ggEq_F for <v6ops@ietfa.amsl.com>; Mon, 9 Mar 2015 22:24:00 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 6BE231A1AE8 for <v6ops@ietf.org>; Mon, 9 Mar 2015 22:23:59 -0700 (PDT)
Received: (qmail 62239 invoked from network); 10 Mar 2015 05:23:57 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Mar 2015 05:23:57 -0000
Date: Tue, 10 Mar 2015 06:23:57 +0100 (CET)
Message-Id: <20150310.062357.74690098.sthaug@nethelp.no>
To: markzzzsmith@yahoo.com.au
From: sthaug@nethelp.no
In-Reply-To: <475150044.2076231.1425944878901.JavaMail.yahoo@mail.yahoo.com>
References: <22EBC28F-43DA-4C26-99EB-584E436EFF70@magma.ca> <475150044.2076231.1425944878901.JavaMail.yahoo@mail.yahoo.com>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/NN6j6oCwhM-xunLO-HSqp_tKnz4>
Cc: v6ops@ietf.org, philip_matthews@magma.ca
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt
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: Tue, 10 Mar 2015 05:24:05 -0000

> / The concern I have with continuing to use an incorrect term, even though it might be fairly commonly used, is that the longer it is used, the longer it can cause confusion or error, and the longer it encourages the use of the inaccurate term.

"Unnumbered interface" is well established in the IPv4 world, and I
see no reason to believe that this document will change that fact.

> / Another point of confusion would be that in IPv4, unnumbered links are usually only serial point-to-point links between routers, meaning that hosts can't physically be attached to the link, where as any type of link can be an IPv6 "unnumbered" link, so hosts may be physically attached to the link if the link-layer is multi-access.

Strongly disagree about the IPv4 part. There is *large* deployment
of unnumbered links for end hosts in service provider environments -
for instance DHCP scenarios with one large DHCP pool being used for
thousands of unnumbered subinterfaces. I work for one such service
provider.

Steinar Haug, AS 2116.