Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

Owen DeLong <owen@delong.com> Wed, 14 August 2013 20:26 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4E21F9B26 for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 13:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.349
X-Spam-Level:
X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_BACKHAIR_23=1, J_BACKHAIR_32=1]
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 jPj3yScrSyU0 for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 13:26:48 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1221F9A14 for <v6ops@ietf.org>; Wed, 14 Aug 2013 13:26:47 -0700 (PDT)
Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7EKO8nG016251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Aug 2013 13:24:08 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7EKO8nG016251
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376511848; bh=8g1Bb1zhm9kzO/SWcyl9Xq4Skq0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hOoEOPYc2f6kn0aRx8yfAcaNuThpU2H222kMAqOo4te4kaAcmSiOCcrNNZ0CAPsd8 rUB1iAFsB+2OoX4ey0EAGYm+Jhx5torChl2POQLOR+N0jd7hlNthHxPhN45olj0+SI ES84mX4D5EXv724e7wo+B61+PXACi3RJ4hnqhYps=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20130814011433.7A75C3851DE2@drugs.dv.isc.org>
Date: Wed, 14 Aug 2013 13:24:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F1F1D79-8AEE-440A-BFDF-2F08CC6FB100@delong.com>
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <B66D2D0C-DE6D-49CC-A87A-7C65B5360DB4@delong.com> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> <20130813025336.918353846F7A@drugs.dv.isc.org> <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com> <20130813070157.6D9D5384B2C5@drugs.dv.isc.org> <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com> <20130814011433.7A75C3851DE2@drugs.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 14 Aug 2013 13:24:08 -0700 (PDT)
Cc: Alejandro Acosta <aacosta@rocketmail.com>, v6ops@ietf.org
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 14 Aug 2013 20:26:49 -0000

On Aug 13, 2013, at 18:14 , Mark Andrews <marka@isc.org> wrote:

> 
> In message <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com>om>, Owen DeLong write
> s:
>>> 
>>> With ULA you end up with:
>>> 
>>> 	site1: P1, P2 announce P2 to site2
>>> 	site2: P1, P3 announce P3 to site1
>>> 
>>> When you have two sites colliding on P1.  (P1, P2 and P3 are different
>>> ULA prefixes).
>> 
>> No, with ULA, the average IT group is going to start with:
>> 
>> site 1: P1
>> site 2: P1
>> 
>> They're going to not want to roll out a whole new addressing plan to both
>> sites, so, instead, they will do what they did in IPv4.
>> 
>> P1<->NAT<->P2<->NAT<->P1
>> 
>> You need to come down out of whatever ivory tower you live in and look
>> at how things happen in the real world.
> 
> Really how is what I am saying different to moving providers with
> PA addresses?  We expect renumbering event to occur then.  We expect
> ipv6 vendors to support this sort of renumbering.

Large enterprises will likely implement IPv6 either with PI space or with NPTv6. So in that regard, it's not different and the consequences are also similar.

As a result, I make sure that as many of my consulting clients as possible (all that qualify under RIR policy) are aware of these things. So far, I have nearly 100% opt-in on going with BGP and PI rather than facing the potential to renumber in the future.

> You bring up the new prefix along side the old prefix.  You
> decommission the old prefix.  The only difference is delaying
> decommissioning the old prefix longer if not forever.

You say this as if that will actually happen at scale.

In reality, what will happen at scale if these scenarios start occurring is that people will fall back to what they know. It's much easier to deploy a couple of extra NAT boxes than it is to renumber an entire enterprise. You know how vitriolic my opinion of NAT is, so the fact that I'm conceding that NAT is what will happen here should be a bit of a wakeup call for you.

>>> You have IP stacks that are designed to deal with multiple prefixes
>>> and to choose particular source addresses for particular destination
>>> addresses.
>>> 
>>> You have applications that are designed to deal with multiple
>>> addresses.
>>> 
>>> IPv4 only stacks don't have all of these features which forces one
>>> to use NAT.
>> 
>> None of that overcomes the realities if modern corporate IT staffing.
>> 
>>> With IPv6 they are there so you can depend on them and take advantage
>>> of them.  If P2 and P3 differ only in the 48th bit longest match
>>> will select the right source address.
>> 
>> If you know about them.
>> If you're willing to put in the effort to use them.
>> If you completely understand them.
>> IF and only IF all of your applications are actually that savvy.
>> etc.
> 
> If you are using ULA along side GUA then yes the applications and
> stacks will do the right thing already which is almost certainly
> what you will be doing if you are using ULA in the first place.

Except when they don't... Which in my experience has turned out to not be an insignificant fraction of time.

I notice you addressed only one of the 4 conditions above.

Owen