[Hipsec] RFC5206-bis (mobility) status
Tom Henderson <tomh@tomh.org> Mon, 12 January 2015 18:33 UTC
Return-Path: <tomh@tomh.org>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E551A802F for <hipsec@ietfa.amsl.com>; Mon, 12 Jan 2015 10:33:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.232
X-Spam-Level:
X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQwUxtGgFnCm for <hipsec@ietfa.amsl.com>; Mon, 12 Jan 2015 10:33:44 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 6EE2C1ACD32 for <hipsec@ietf.org>; Mon, 12 Jan 2015 10:33:42 -0800 (PST)
Received: (qmail 11915 invoked by uid 0); 12 Jan 2015 18:33:42 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 12 Jan 2015 18:33:42 -0000
Received: from box528.bluehost.com ([74.220.219.128]) by cmgw2 with id f6Zd1p00B2molgS016ZgDw; Mon, 12 Jan 2015 11:33:41 -0700
X-Authority-Analysis: v=2.1 cv=eOCA0hZ1 c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=vP6ySPhpAh4A:10 a=IkcTkHD0fZMA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=Frq4C2WgjfYA:10 a=YNv0rlydsVwA:10 a=48vgC7mUAAAA:8 a=6pwFDpWVorT279n8kVIA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=+acCP/c00EAqwzrHjnD/CpmhC0i5XkXYgdOMfEaxk+k=; b=xAi3lQSj5pdbNkTj/95UaLU4E7lJjo3JXNVYKCYJb4m+Ln6xPoGsZQc6f4jpI3P3ravI31G4nLSNk3OsuNSFB/dkALUdiChZ3udMj1uugb27TH8r+7uJeKiBlqEbIiDm;
Received: from [69.91.156.29] (port=53776) by box528.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <tomh@tomh.org>) id 1YAjo1-0000fs-5A for hipsec@ietf.org; Mon, 12 Jan 2015 11:33:37 -0700
Message-ID: <54B4137E.1040709@tomh.org>
Date: Mon, 12 Jan 2015 10:33:34 -0800
From: Tom Henderson <tomh@tomh.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: HIP <hipsec@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 69.91.156.29 authed with tomh@tomh.org}
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/9SpfZvx0JiuF4Kvl8VyswGIFfqc>
Subject: [Hipsec] RFC5206-bis (mobility) status
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 18:33:45 -0000
I just published version 8 of RFC5206-bis (mobility), and version 5 of the multihoming draft. These updates make the changes that were discussed on the list in December; in summary, the updates were mainly about moving additional material related to multihoming from the RFC5206-bis draft to the multihoming draft. The next update I plan to make is to add a description of how UPDATEs may be forwarded through rendezvous servers, to handle the double jump mobility scenario. There isn't any discussion about what to do when UPDATEs are not acknowledged, so I propose to suggest that, upon failure of obtaining an ACK to an UPDATE from a peer, the host should try any other addresses that it knows about, and if those also fail, try to send the UPDATE to the peer's rendezvous server (if known). There were 13 open issues in the tracker against RFC5206-bis, but upon review, many of them are multihoming questions, so I reassigned several of them to the multihoming draft. Here are the issues against RFC5206-bis that I see remaining. Issue 8: decouple locator announcement from SA creation http://trac.tools.ietf.org/wg/hip/trac/ticket/8 Issue 9: some implementations lack some of the compulsory UPDATE features, so maybe they should not be mandatory http://trac.tools.ietf.org/wg/hip/trac/ticket/9 Issue 12: sending UPDATE via rendezvous server (discussed above) http://trac.tools.ietf.org/wg/hip/trac/ticket/12 Issue 15: suggestion for naming UPDATE packets http://trac.tools.ietf.org/wg/hip/trac/ticket/15 Issue 21: UPDATE signature and HI inclusion http://trac.tools.ietf.org/wg/hip/trac/ticket/21 Issue 23: Allow Locator fields to have flow bindings http://trac.tools.ietf.org/wg/hip/trac/ticket/23
- [Hipsec] RFC5206-bis (mobility) status Tom Henderson
- Re: [Hipsec] RFC5206-bis (mobility) status Miika Komu