Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

sthaug@nethelp.no Tue, 24 June 2014 11:28 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 016171A03B5 for <v6ops@ietfa.amsl.com>; Tue, 24 Jun 2014 04:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 hTzeAbeTOzA8 for <v6ops@ietfa.amsl.com>; Tue, 24 Jun 2014 04:28:32 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 88FC71B27E6 for <v6ops@ietf.org>; Tue, 24 Jun 2014 04:28:31 -0700 (PDT)
Received: (qmail 4676 invoked from network); 24 Jun 2014 11:28:29 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Jun 2014 11:28:29 -0000
Date: Tue, 24 Jun 2014 13:27:14 +0200
Message-Id: <20140624.132714.41725023.sthaug@nethelp.no>
To: nick@foobar.org
From: sthaug@nethelp.no
In-Reply-To: <53A94E88.6070101@foobar.org>
References: <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org>
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/5OOvX3X7obYL8WkprQR4D_PNNjs
Cc: v6ops@ietf.org
Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]
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, 24 Jun 2014 11:28:35 -0000

> > It's certainly possible, but you will never see an IPv4 host do it
> > automatically.  It has to be configured manually, and rarely makes much
> > sense other than for servers that simply need an additional public
> > identifier, or routers that need to do network address translation and
> > hence need an IP address on both the public and private subnets.
> 
> ...or any of the situations where it might make sense in the same way that
> it might make sense for ipv6, which is why all major operating systems have
> GUI access to make it easy to add secondary ipv4 addresses on any
> interface.  Secondary ipv4 addresses are completely mainstream, even if we
> all used them before they were cool.

Absolutely agreed. We tend to put each service on its own IP address -
makes it much easier to move the service later without affecting other
services on the same server.

Steinar Haug, AS 2116