Re: [nbs] NBS and TCP connection identification

Christian Vogt <christian.vogt@ericsson.com> Wed, 13 October 2010 18:19 UTC

Return-Path: <christian.vogt@ericsson.com>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81303A6B1D for <nbs@core3.amsl.com>; Wed, 13 Oct 2010 11:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.884
X-Spam-Level:
X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 oCRo843cnuF9 for <nbs@core3.amsl.com>; Wed, 13 Oct 2010 11:19:09 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 7AB463A6A11 for <nbs@ietf.org>; Wed, 13 Oct 2010 11:19:09 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o9DIbRdL027415; Wed, 13 Oct 2010 13:37:29 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 13 Oct 2010 14:19:58 -0400
From: Christian Vogt <christian.vogt@ericsson.com>
To: Jan M <jmgm@iki.fi>
Date: Wed, 13 Oct 2010 14:19:58 -0400
Thread-Topic: [nbs] NBS and TCP connection identification
Thread-Index: ActrAz45ALXgHtgWRFaAKqj84DyeeQ==
Message-ID: <7C1C5C58-BE14-48E7-AFAA-9ECEDE3B2441@ericsson.com>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com> <1285067950.2068.59.camel@bit> <4C98D525.1030808@oracle.com> <DC2EB1A1-B9BE-49B0-B443-B513873B9AF2@ericsson.com> <EBB53DE6-2EEB-43C2-9451-0A38EBD10BAA@free.fr> <CD376A37-C756-47E5-BBC7-205595F523AB@ericsson.com> <C3056CB3-DDD3-4B13-A80F-552350031FEF@free.fr> <C0F28CE9-B47D-416A-907D-394AC2FAF487@ericsson.com> <383DC7DE-389D-471E-8402-3B5816880F55@iki.fi>
In-Reply-To: <383DC7DE-389D-471E-8402-3B5816880F55@iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] NBS and TCP connection identification
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2010 18:19:11 -0000

> First of all I'm new to the list so maybe this has been asked already but hopefully somebody could clarify also to me.

Welcome to the list, Jan.

> How will a host with a RFC1918 address be able to synthesize its name or will all RFC1918 hosts have the same name? How will NBS separate these hosts or is it assumed that server will always sees the same name? Or do the end hosts see different names e.g. server sees the synthesized name of NAT and client sees the name of RFC1918?

Yes, synthesized names are derived from the IP address seen by the recipient.  Therefore, if multiple legacy hosts are behind a NAT, their synthetic names will be the same.

An alternative could be to also encode the initiator's port number into a synthesized name, in addition to the initiator's IP address.  In this case, the synthetic names of multiple legacy hosts are behind a NAT would differ.  I am yet unconvinced whether this would be useful, though.  Thoughts?

> If there was a host at certain IP A (obtained via DHCP) with synthesized name A when the next host (different) gets the same IP A from DHCP will it have the same name A?  What should the peer be able to determine from this name and how will it know that it is different or same instance as the previous?

Yes, if DHCP hands out the same IP address to different hosts sequentially, and if those hosts are both legacy, the hosts' synthesized names will look the same.  But this is in line with the semantics of a synthesized name:  A synthesized name refers to the host that used the encoded IP address at the time of session initiation.  By implication, synthesized names are good only throughout a session -- for session identification across address changes.  Synthesized names cannot be used to re-identify a host across sessions.

Does this make sense?

- Christian