Re: [v4v6interim] Doesn't HIP solve this problem?

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 29 October 2008 00:52 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 13C573A6A0C; Tue, 28 Oct 2008 17:52:36 -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 27E8D3A68E6 for <v4v6interim@core3.amsl.com>; Tue, 28 Oct 2008 17:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 TJXqxjZid9tl for <v4v6interim@core3.amsl.com>; Tue, 28 Oct 2008 17:52:33 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id D5C693A6A0C for <v4v6interim@ietf.org>; Tue, 28 Oct 2008 17:52:33 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so3173952wfd.31 for <v4v6interim@ietf.org>; Tue, 28 Oct 2008 17:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=B8vuPAsF+0XFKyksyii5z5LfktwiaESkBGyWJNSTy6Q=; b=p4gsMS4ZjOIDhjbiQ4AvSwFnIgQRLkMuHhJwOpgtKIakcQLHg1Lb0kOsnNYIbFN83i jeJQQTVUc5JeFYMl6ZBaqxBIls5zpeWYXA7iDma/v0cD7zo4DylXuQv/bkaZOwEBzO7G 7C9zW+U1bSKVrlr0G/LlX1MC1qJJhrZ4UbXzs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=weoBdFI/Bp6RyxZu4e46xlc6NQRnUr2/Iqdu2xjziULTeGvtr17PJq/JyMK0r0VpXN 6eJyDEtyLUcMCT6sNjcRtwEbk1APuEnDZSa5b9WeSQ7Bi8j9ng0FQPdA47GiYBx2kAh6 yp3LYcUA6WzhfSxzSVfLtEDJIM6N4K9fP8tEE=
Received: by 10.142.223.4 with SMTP id v4mr3692533wfg.48.1225241551152; Tue, 28 Oct 2008 17:52:31 -0700 (PDT)
Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 9sm5149227wfc.19.2008.10.28.17.52.29 (version=SSLv3 cipher=RC4-MD5); Tue, 28 Oct 2008 17:52:30 -0700 (PDT)
Message-ID: <4907B3CB.8040304@gmail.com>
Date: Wed, 29 Oct 2008 13:52:27 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <48F8539D.90608@ericsson.com> <200810201358.29295.remi.denis-courmont@nokia.com> <48FC663E.1070902@it.uc3m.es> <200810201426.33336.remi.denis-courmont@nokia.com> <48FCF87B.8060609@gmail.com> <49037562.5050708@acm.org> <5665336F-F111-48F2-AFC4-0CB6587A844F@cisco.com>
In-Reply-To: <5665336F-F111-48F2-AFC4-0CB6587A844F@cisco.com>
Cc: Marc Petit-Huguenin <petithug@acm.org>, v4v6interim@ietf.org, 46translation@employees.org, 'Behave WG' <behave@ietf.org>
Subject: Re: [v4v6interim] Doesn't HIP solve this problem?
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-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

Fred,

I think you are spot on. A new session layer identifier namespace would
solve a lot of problems, but would require a new identifier mapping
system to link it back to the network layer and the routing system.
That's missing in HIP today (which is why we get a mishmash like
RFC 4843).

I suggest this line of discussion is closer to the RRG charter
than to BEHAVE.

    Brian

On 2008-10-26 10:15, Fred Baker wrote:
> no, at least I don't think so.
> 
> HIP tries to provide what RFC 1498 and 1753 call an "endpoint ID", but
> provides no way to associate locators with it. Hence, while from an
> application perspective it enables the application to ensure that the
> system or service it is talking with is the one it intends to, it
> doesn't enable the transport to select an address pair to use in routing
> - and yes, the choice of a source and a destination address has the
> effect of routing a session, as it determines important points that the
> datagram will transit.
> 
> Read all of RFCs 1483, 1753, 1992,
> http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt, and
> http://tools.ietf.org/html/draft-irtf-nsrg-report for a complete
> discussion of the problem. Getting network folks and application folks
> to describe the problem is a little like describing the elephant - each
> only describes part.
> 
> On Oct 26, 2008, at 3:37 AM, Marc Petit-Huguenin wrote:
> 
>> Brian E Carpenter wrote:
>>> On 2008-10-21 00:26, Rémi Denis-Courmont wrote:
>>> ...
>>>>>> 4/ prefix delegation "bypass"
>>>>>>
>>>>>> (1) is a non-issue for IPv6. (2) is solved with stateful
>>>>>> firewalling and
>>>>>> does not require NAT. 1:1 NAT fails to solve (3) as it does hide the
>>>>>> subnetting scheme, but fails to hide individual hosts. This leaves
>>>>>> only
>>>>>> (4). Did I miss anything?
>>>>> I think one main reason would be provider independence (ie. no need to
>>>>> renumber)  for small sites that cannot afford to have thier own PI
>>>>> address block allocated
>>>> That's prefix delegation/routing bypass.
>>>
>>> Yes. It avoids renumbering, and allows multihoming. It's very hard
>>> to stop this unless the RRG comes up with a miracle solution
>>> in the near future.
>>
>> Doesn't HIP solve this problem?
>>
>> -- 
>> Marc Petit-Huguenin           [                                 ]
>> Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ]
>> Work: marc@8x8.com            [                                 ]
>> [                                                               ]
>> _______________________________________________
>> 46translation mailing list
>> 46translation@employees.org
>> https://www.employees.org/mailman/listinfo/46translation
> 
> 

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