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

Owen DeLong <owen@delong.com> Tue, 13 August 2013 18:05 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 4EE5511E81A0 for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 11:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_23=1, J_BACKHAIR_32=1, NO_RELAYS=-0.001]
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 EgbappS6PJ2Q for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 11:05:50 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0311821F91B7 for <v6ops@ietf.org>; Tue, 13 Aug 2013 11:05:49 -0700 (PDT)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7DI5L9N016757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Aug 2013 11:05:21 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7DI5L9N016757
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376417122; bh=vTCu22TlWKxMOnOUmjggdie3LFM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3g4BzDpyeIcHGhOZg9WifvRyU8OM6uS2/rPUlzs1IW6jaJzlFzr+cHLHa4dpK21OC DvY2jPBobPqD0p1266NWAR+mPu3dWlX8PIHX6tfDYYV/Crwb0JUahKkhem329rY4ML qTlrLSLCCCvQ2TWsEOTOGZbRNNHFMat+x7Bwqgds=
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: <20130813070157.6D9D5384B2C5@drugs.dv.isc.org>
Date: Tue, 13 Aug 2013 11:05:22 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <4B2E191C-B8BE-4B71-91D9-CD0995296F32@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>
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 [IPv6:2620:0:930::200:2]); Tue, 13 Aug 2013 11:05:22 -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: Tue, 13 Aug 2013 18:05:51 -0000

> 
> 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.

> 
> 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.

For most enterprises, the answer to at least one of those IFs will fail.

Owen