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

Erik Nordmark <erik.nordmark@oracle.com> Mon, 03 May 2010 16:20 UTC

Return-Path: <erik.nordmark@oracle.com>
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 E99453A6864 for <shim6@core3.amsl.com>; Mon, 3 May 2010 09:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level:
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=-1.632, BAYES_50=0.001]
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 NKdcvIUrWWze for <shim6@core3.amsl.com>; Mon, 3 May 2010 09:20:12 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 12DB43A67B3 for <shim6@ietf.org>; Mon, 3 May 2010 09:20:11 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o43GJsCn028054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 May 2010 16:19:56 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o437WirF025139; Mon, 3 May 2010 16:19:52 GMT
Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 231508931272903578; Mon, 03 May 2010 09:19:38 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 May 2010 09:19:37 -0700
Message-ID: <4BDEF791.1020507@oracle.com>
Date: Mon, 03 May 2010 09:19:29 -0700
From: Erik Nordmark <erik.nordmark@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2
MIME-Version: 1.0
To: Javier Ubillos <jav@sics.se>
References: <1272457259.4126.63.camel@bit> <4BDA9C91.6060705@oracle.com> <1272881171.4126.85.camel@bit>
In-Reply-To: <1272881171.4126.85.camel@bit>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090208.4BDEF7AC.011E:SCFMA922111,ss=1,fgs=0
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 16:20:13 -0000

On 05/ 3/10 03:06 AM, Javier Ubillos wrote:

> 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?

I think you are asking about the definition of "invalid", which is 
specified in RFC 4862. (It is when the address allocation is withdrawn, 
whether using stateless address allocation or DHCPv6.) In an 
implementation that typically corresponds to the address no longer being 
configured e.g., doesn't show up in ifconfig -a.

This is completely unrelated to an address being unreachable.

Note that the address allocation needs to be withdrawn before the 
address can possibly be reassigned to some other node.

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

I don't know what an "invalid context" means. Please explain.

A shim6 host can loose state, which can result in one end having context 
state and the other end not having it. RFC 5533 specifies how the 
protocol recovers from context state loss.

    Erik