Re: [shim6] Problems with ULID (IP) over longer sessions.

Javier Ubillos <jav@sics.se> Mon, 03 May 2010 10:06 UTC

Return-Path: <jav@sics.se>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9723A6BBC for <shim6@core3.amsl.com>; Mon, 3 May 2010 03:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.426
X-Spam-Level:
X-Spam-Status: No, score=0.426 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, HELO_EQ_SE=0.35]
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 5YfqKrTrUuWG for <shim6@core3.amsl.com>; Mon, 3 May 2010 03:06:26 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id C52FE3A68A5 for <shim6@ietf.org>; Mon, 3 May 2010 03:06:26 -0700 (PDT)
Received: from [10.0.255.253] (h206n3-haes-a12.ias.bredband.telia.com [78.72.156.206]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 3F66140313; Mon, 3 May 2010 12:06:12 +0200 (CEST)
From: Javier Ubillos <jav@sics.se>
To: Erik Nordmark <erik.nordmark@oracle.com>
In-Reply-To: <4BDA9C91.6060705@oracle.com>
References: <1272457259.4126.63.camel@bit> <4BDA9C91.6060705@oracle.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5jMyPbkz7E2eKLajTZPz"
Date: Mon, 03 May 2010 12:06:11 +0200
Message-ID: <1272881171.4126.85.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
Cc: shim6@ietf.org
Subject: Re: [shim6] Problems with ULID (IP) over longer sessions.
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2010 10:06:27 -0000

On Fri, 2010-04-30 at 02:02 -0700, Erik Nordmark wrote:
> On 04/28/10 05:20 AM, Javier Ubillos wrote:
> > Hi folks.
> >
> > Some time ago I heard a discussion about a potential issue with shim6.
> > That the Upper Layer Identifier (ULID), chosen as the first pair of
> > locators used in the communication, could cause
> > problems/confusion/somethingelse when those locators where no longer
> > used by the hosts. I.e not in the locator lists.
> >
> > I'm unsure about the details of what would cause the problem or what the
> > consequences could be.
> >
> > My own first reaction is that if a software believes it's communicating
> > with an IP (a shim6 ULID), it might try to spawn more sockets/flows to
> > that IP.
> >
> > Have this kind of issues been discussed previously on this list? ( I
> > couldn't find any discussions about it).
> > Have any one on this list some more detailed thoughts/experience about
> > what could cause issues?
> 
> Section 1.5 in RFC 5533 says that the communication must be terminated 
> should the ULID become invalid. That handles the case of a ULID 
> potentially being assigned to a different host.
> 
> Note that a ULID might be unreachable and hence unusable as a locator 
> without being invalid.
> 

It looks as if 1.5 was what I was unknowingly referring to.

However, if not when the locator becomes unreachable, when is an ULID
declared invalid?

When that locator _does_ respond, but with invalid context (or some
other expected 'error' behavior)?
When it becomes un-routable? (prefix change)


> > I'm asking this because a couple of colleges and I are looking at using
> > alternative ULIDs which hopefully would be more of a match with session
> > identifiers/FQDNs or similar.
> 
> It is possible to extend SHIM6 to handle 128-bit ULIDs that are never 
> usable as locators. It has performance impact because one would need to 
> do a ID->locator lookup before sending the first packet. A possible way 
> to do this was written up in draft-nordmark-shim6-esd.
> 

Thank you for that tip. I'll make sure I read up!


Thank you
// Javier