Re: [nbs] NBS and TCP connection identification

Javier Ubillos <> Thu, 14 October 2010 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C63213A6997 for <>; Thu, 14 Oct 2010 08:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_23=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hv483yU1L0Q5 for <>; Thu, 14 Oct 2010 08:27:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 274603A63D2 for <>; Thu, 14 Oct 2010 08:27:36 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id EAC1E400E2; Thu, 14 Oct 2010 17:28:52 +0200 (CEST)
From: Javier Ubillos <>
To: Jan M <>
In-Reply-To: <>
References: <> <> <> <1285067950.2068.59.camel@bit> <> <> <> <> <> <> <> <> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Zu/1//t1jJ9D+yklL4x1"
Date: Thu, 14 Oct 2010 17:28:51 +0200
Message-ID: <1287070131.2253.92.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: Christian Vogt <>, "" <>
Subject: Re: [nbs] NBS and TCP connection identification
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Oct 2010 15:27:37 -0000

On Thu, 2010-10-14 at 08:45 +0300, Jan M wrote:
> Hi Christian,
> On Oct 13, 2010, at 9:19 PM, Christian Vogt wrote:
> >> 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?
> Actually I don't see how this could work for either session identification. If the host initiates the session with RFC1918 address behind the NAT then the peer sees synthesized name and client thinks it is Now it tries to use this name on the other interface it has and it sends to the peer "Hi, I'm I would like to add V.X.Y.Z. address to the existing session" but the peer has only session so it wont be able to identify the session or am I missing something? So I guess you need some network support to resolve that the name of the session is actually not
> Additionally the session identification comes even more complex when you have multiple hosts behind the as not all can identify themselves as or how do you plan to avoid situation where multiple hosts are saying that "Hi I'm and I would like to add address to address on port 80" so how would the peer know which session to associate new address as the source port is probably not usable as you can't count on it to be same all session to be added?
>    Regards,
>     Jan
> _______________________________________________
> nbs mailing list

Consider the synthesized name an arbitrary label. Completely irrelevant
for the communication.

Assume that host A is behind a NAT,
and assume that we're talking TCP.

Host A has  |  Host B has
IP(A)       |  IP(B)
Port(A)     |  Port(B)
Name(A)     |  Name(B)

When Host A sends a packet to B, and only receives Bs address in a
literal manner, the packet on the network is still sent to
IP(B):TcpPort(B). The names Name(A) & Name(B) are added in an extension
header, but for the network, it is considered payload only.

When it arrives at Host B, Name(A) will be used as a sessionlabel with
no particular semantics. The label will never be derived to an IP, hence
there is no risk that the IP changes owner. This is all managed by
name-based sockets (e.g. by the shim6 extension).

Conversely, when the reply from Host B to A is sent, it follows normal
IP+NAT protocol. The names are, from a network perspective, just

What _could_ be an issue to be solved, is what happens when labels
collide. But I don't think this will be a major problem, as long as each
socket is well isolated from other sockets.

// Javier