Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt

Paul Vixie <paul@vix.com> Thu, 05 July 2007 02:20 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6GxN-0001A3-Ly; Wed, 04 Jul 2007 22:20:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6GxL-00017l-OO for ipv6@ietf.org; Wed, 04 Jul 2007 22:20:31 -0400
Received: from sa.vix.com ([2001:4f8:3:bb::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6GxL-0002ym-9g for ipv6@ietf.org; Wed, 04 Jul 2007 22:20:31 -0400
Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D846A1142F for <ipv6@ietf.org>; Thu, 5 Jul 2007 02:20:30 +0000 (UTC) (envelope-from vixie@sa.vix.com)
From: Paul Vixie <paul@vix.com>
To: ipv6@ietf.org
In-Reply-To: Your message of "Wed, 04 Jul 2007 10:49:06 +0200." <468B5F02.7000600@gmail.com>
References: <E1I0NEg-000884-8o@stiedprstage1.ietf.org> <13846.1183003509@sa.vix.com> <46834717.3090102@internap.com> <4683712F.1010602@gmail.com> <14556.1183042057@sa.vix.com> <4684DB4A.2060703@gmail.com> <27414.1183131210@sa.vix.com> <4688C2CA.5050302@gmail.com> <43704.1183395211@sa.vix.com> <468A02EC.3080509@gmail.com> <20140.1183474407@sa.vix.com> <468B5F02.7000600@gmail.com>
X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1
Date: Thu, 05 Jul 2007 02:20:30 +0000
Message-ID: <65666.1183602030@sa.vix.com>
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

[vixie]
> > so, we share a supposition that the DFZ
> > is now a minority of "the Internet".

[carpenter]
> Or possibly that we don't know what
> "the Internet" is any more...

indeed, we don't.  one of the reasons i was dragging seth breidbart's
definition out and re-airing it here a few weeks back is that these
discussions are an indirect attack on the idea of a "largest closure".

that is, someone with access to a large set of private routes and also
to the "public internet" is part of a larger symmetric closure than
someone who is only connected to the "public internet".  i think the
closure has become nonsymmetric, and nobody noticed until this moment.

> > in the DFZ today are many competitors and thin margins.  for a "leak" to
> > be successful, one provider has to want to emit a ULA-G route, and
> > virtually all other providers have to be willing to accept it.  this is so
> > unlikely that i can't imagine it.  it's not equivilent to the RFC1918 or
> > non-BGP38 emissions problems, since every "leak" in this case means a
> > competitor signs recurring revenue for a customer who was in play.  "that
> > is sooooo not going to happen."
> 
> I have to say that sounds convincing.  I suppose there will be exceptions,
> but not enough to matter.  (An exception is where BigBadCorporation insists
> on being accessible only via its junk /48, but every customer of every ISP
> wants to reach www.BigBadCorporation.com.  Then the incentive exists to
> route that /48.)

the concept of "incentive" presupposes a value system and "incentee", and in
the DFZ, there is not a value system in common among enough potential
incentees to make what you're talking about feasible except through error
or accident.

[carpenter]
> >> As an aside, that's why the normal model in IPv6 is for a user site to
> >> run several PA prefixes simultaneously, and that's why we designed shim6.

> > ... the shim6 idea makes it more interesting -- how's that working out in
> > the field?  any significant deployment experiences to report?  (i'm not
> > just still bitter about the A6/DNAME debacle -- i really want to know.)

> No. It's really too soon. The shim6 documents are in WG Last Call right now.

so, it's been designed, but noone knows whether it will have any effect on
this problem space.  let's leave it out of the discussion, then.

> > the benefit of ULA-G away from the DFZ is so much greater than the risk of
> > ULA-G to the DFZ that i can't even consider them simultaneously long
> > enough to let them compete.  from what you're saying, i don't know if you
> > can either.
> 
> Agree

that's good to hear confirmed.

> > ...  every device needs a unique identifier for any number of reasons.  if
> > the DFZ is intolerant of these identifiers, then they'll show up in other
> > ways, like non-DFZ routing, 1:1 NATv6, ad-hoc IPSEC tunnel innards,
> > software key/serial numbers, and things we've not imagined.  the DFZ is
> > one way to internet.  only one way.  and it's not the only reason one
> > might need a registered unique addresses.
> 
> Here we do get into the ID/Loc split discussion that's going on over
> in RAM and RRG.  *If* that concludes that
>   a) a split is needed
>   b) the IDs should be in IPv6 address format
>   c) they don't need to be cryptographically generated
>   and d) they do need to be registered and DNS-able
> then ULA-G would clearly be a candidate, and ULA-C wouldn't.

code first, then spec.  let's allocate a couple ten million ULA-G prefixes and
see how the field develops it.  should be way more interesting than waiting to
see if this year's iteration of the ivory tower "do we need an id/loc split?"
debate ends any more remarkably than previous ones.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------