Re: [v4v6interim] "IPv4->IPv6 is hard"

marcelo bagnulo braun <marcelo@it.uc3m.es> Mon, 20 October 2008 07:22 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FE23A6988; Mon, 20 Oct 2008 00:22:06 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28B43A6988 for <v4v6interim@core3.amsl.com>; Mon, 20 Oct 2008 00:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.847
X-Spam-Level:
X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTJZB19oFDxB for <v4v6interim@core3.amsl.com>; Mon, 20 Oct 2008 00:22:04 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 0180B3A6833 for <v4v6interim@ietf.org>; Mon, 20 Oct 2008 00:22:04 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.133.67])by smtp01.uc3m.es (Postfix) with ESMTP id 59B8EAC275C;Mon, 20 Oct 2008 09:23:13 +0200 (CEST)
Message-ID: <48FC31E0.5060902@it.uc3m.es>
Date: Mon, 20 Oct 2008 09:23:12 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <B4A9FAB9-F39D-42AA-BE3B-AF6A3C48CC93@cisco.com> <4391DDA1-6432- 4DCD-8A38-F351C68058B5@muada.com><0F551636-8059-4C93-81F6-AB5421CD4F3F@ci s co.com> <48FBC96D.5020207@cernet.edu.cn> <48FC2AFC.60405@it.uc3m.es> <F2C58F5B-4A97-4F86-8987-832F41424D6E@cisco.com>
In-Reply-To: <F2C58F5B-4A97-4F86-8987-832F41424D6E@cisco.com>
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-17.5655 TC:1F TRN:47 TV:5.5.1026(16228.005)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Cc: v4v6interim@ietf.org
Subject: Re: [v4v6interim] "IPv4->IPv6 is hard"
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

Fred Baker escribió:
>
> On Oct 20, 2008, at 2:53 PM, marcelo bagnulo braun wrote:
>>> (2) As the ISP, we price IVI addresses (1:1 mapping of IPv4 address, 
>>> scarce resource) and non-IVI addresses (non-scarce resource) 
>>> differently. So it is also economically reasonable.
>> Right, this is exactly what i would like to prevent, that ISPs have 
>> control on whether their clients are able or not to publish content 
>> from their sites
>
> Excuse me?
>
> Trust me, given that you attach to someone's network, they are in 
> control of what services they offer you, and they are in a position to 
> filter-or-whatever if they want. 
No, that does have legal implications (at least in some countries)


> Given that you have a choice of offerings, they are not in control of 
> the choices you make, but they can prevent you from making certain 
> choices in their network by not offering you the choice.
>

that depends on how you define the underlying technology. Some 
technologies allows some players to do some operations and some 
technologies don't, and by enabling some functions you allow some 
parties to have some power.
See Clark's design for tussle paper for more discussion about this for 
instance.
> What Xing Li proposes - and what I propose - is not as onerous as you 
> appear to believe. He gives you the option of paying for a directly 
> (1:1) translatable address and he doesn't tell you what you may do 
> with it.Given that, you have the option of paying for the service he 
> is offering or paying for a different one, perhaps one from a 
> different ISP - the same choice you have with any ISP. Given that you 
> choose to pay for a 1:1 translatable address (just as you would with 
> the NAT64 model), you can put any content behind that address that you 
> want to.
>
> And in any event, I would really hope that we could avoid political 
> agendas here.
I don't think it is a political agenda to understand what the technology 
allows to do each stakeholder

Unfortunately, in this case that we are disucssing, i don't think we can 
define a reasonable technology for enabling any v4 node to contact any 
v6 node, so as i said, 1:1 mappings are the best we can do, even if we 
don't like what that implies to the end sites

Regards, marcelo


> Last I checked, we're technologists and we are describing technology. 
> Pretending that we are preventing ISPs from doing one thing or forcing 
> them to do another is a pipe dream. Once it is deployed, they're in 
> control.
>
> Let's work on the technology.
>

_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim