Re: [shara] Shara scope

Olaf Maennel <omaennel@net.t-labs.tu-berlin.de> Wed, 28 January 2009 22:39 UTC

Return-Path: <shara-bounces@ietf.org>
X-Original-To: shara-archive@ietf.org
Delivered-To: ietfarch-shara-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4F328C1AD; Wed, 28 Jan 2009 14:39:29 -0800 (PST)
X-Original-To: shara@core3.amsl.com
Delivered-To: shara@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C15528C1AD for <shara@core3.amsl.com>; Wed, 28 Jan 2009 14:39:28 -0800 (PST)
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 Si-BVMnxZJbA for <shara@core3.amsl.com>; Wed, 28 Jan 2009 14:39:27 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 396F228C17E for <shara@ietf.org>; Wed, 28 Jan 2009 14:39:26 -0800 (PST)
Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <omaennel@net.t-labs.tu-berlin.de>) id 1LSJ3n-000Gw4-Do; Wed, 28 Jan 2009 22:39:06 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 29 Jan 2009 00:38:58 +0200
From: Olaf Maennel <omaennel@net.t-labs.tu-berlin.de>
To: <teemu.savolainen@nokia.com>
Message-ID: <C5A6AB22.1450D%omaennel@net.t-labs.tu-berlin.de>
Thread-Topic: [shara] Shara scope
Thread-Index: Acl/s+fQbqY5EJjFQASUaGt+lEYm/wAmWk0wAAN3HX0ASZBrsAAF8YZl
In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E85E1E9D@NOK-EUMSG-01.mgdnok.nokia.com>
Mime-version: 1.0
Cc: shara@ietf.org
Subject: Re: [shara] Shara scope
X-BeenThere: shara@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Sharing of an IPv4 Address discussion list <shara.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/shara>
List-Post: <mailto:shara@ietf.org>
List-Help: <mailto:shara-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: shara-bounces@ietf.org
Errors-To: shara-bounces@ietf.org

Hi, 

On 28/01/09 10:03 PM, "teemu.savolainen@nokia.com"
<teemu.savolainen@nokia.com> wrote:
> Hi,
> 
> I ment that there's no need to work here about how NATs work (or how those are
> traversed) in general, but indeed the coexistence with NATs and placement of
> NAT are of interest.
> 
> While new phones could be containing support for this feature, the old ones
> definitely would not. Thus the gateway serving large number of terminals would
> need to provide public IPv4 address or NAT for some while letting others use
> shared addresses. And this distribution would likely change as legacy devices
> would go away and new ones come in, and even more so when IPv6 becomes common.

if i recall correctly, Alain said something very similar... just he wasn't
talking about phones. :)
 
> About the signaling. On the DHCP-based solutions, I think (at least in our
> proposal solution) the signaling could work by node sending in DHCPDISCOVER
> indication of its support for shared addresses, and with that it would
> implicitly indicate no need for NATting by the delegating host (if it indeed
> delegates shared addresses).

just an initial list of bullet-points what needs to be signaled. (I think
its identical with what you said...):

- a set of public IPv4 addresses,
- for each IPv4 address the allocated port-range,
- the tunneling technology to be used
  (e.g., "in-IPv6-encapsulation", or in your case that you have layer-2)
- addresses of the tunnel endpoints (e.g., IPv6 address of tunnel endpoints)
- whether or not NAT functionality is provided by the gateway

anything missing besides a version number and some reserved bits for future
use? :)

> On the chain of delegating nodes the first node
> that does not indicate support for shared addresses in its DHCPDISCOVER
> essentially indicates to the node above to provide private IPv4 address and
> instantiate NAT.

agreed. 

    olaf


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