Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt

Erik Nordmark <nordmark@acm.org> Sun, 02 March 2014 13:47 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098C01A0273 for <ipv6@ietfa.amsl.com>; Sun, 2 Mar 2014 05:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.215
X-Spam-Level: *
X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 ZwiASrHkoKe4 for <ipv6@ietfa.amsl.com>; Sun, 2 Mar 2014 05:47:16 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id A62CD1A0101 for <ipv6@ietf.org>; Sun, 2 Mar 2014 05:47:16 -0800 (PST)
Received: from [31.133.180.98] (dhcp-b462.meeting.ietf.org [31.133.180.98]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s22Dl75o011056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 2 Mar 2014 05:47:08 -0800
Message-ID: <5313365B.2090705@acm.org>
Date: Sun, 02 Mar 2014 13:47:07 +0000
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
References: <20140214235734.2509.63069.idtracker@ietfa.amsl.com> <52FF115C.30001@acm.org> <CAJE_bqdOiO2zyCvxsO4sEW+9ZMb0DoOyscNWP1=jedrBbbBkEA@mail.gmail.com> <530FA94B.3050802@acm.org> <CAJE_bqdF2-nH7GaC+j6PnRagDC0jDj0c0me6MOC6AsHNvDaedQ@mail.gmail.com>, <5311DA0F.5070106@sonic.net> <2DE1A508-AB45-4256-BBF3-A9ACD3D24051@cisco.com>
In-Reply-To: <2DE1A508-AB45-4256-BBF3-A9ACD3D24051@cisco.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Sonic-ID: C;AHtxJRGi4xG2gdKVOBdzQA== M;DonwJRGi4xG2gdKVOBdzQA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4tkkjNOo0lWexqU_0gVWElxl3yw
Cc: Erik Nordmark <nordmark@acm.org>, IETF IPv6 <ipv6@ietf.org>, 神明�_哉 <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Mar 2014 13:47:18 -0000

On 3/1/14 9:43 PM, Pascal Thubert (pthubert) wrote:
> A variation could be to add a new option in the RS with both the linklocal and the slla that the device wishes to use.
We wouldn't need a new option - in a slightly different context Samita
suggested we might want to send the ARO in the RS, which would solve the
above.

>
> A NEAR would eventually perform the DAD on behalf in case of mixed mode. It could create a temp nce and answer unicast. If success then the node could register that address.
The mixed mode support would be the same whether we register with RS or NS.

So this sounds like a reasonable approach.

Erik

>
> What do you think?
>
> Pascal
>
>> Le 1 mars 2014 ¨¤ 21:48, "Erik Nordmark" <nordmark@sonic.net> a ¨¦crit :
>>
>>> On 2/28/14 11:53 PM, ÉñÃ÷ß_ÔÕ wrote:
>>>
>>> I don't understand how it works in the bootstrap stage.  To send the
>>> NS/ARO for a link-local address (on bootstrap), the host should first
>>> know the registrar's address.  But the host can't get the information
>>> by unicast RS-RA exchange since the source address of the RS would
>>> need to be the link-local address to prove unique.  Or am I
>>> misunderstanding your intent?
>> That part isn't fully fleshed out in the draft.
>>
>> To have a unicast RA prior to having registered the link-local address, the router needs to use the SLLA option in the RS - this would be the same mechanism as in the draft for sending errors to NS/AROs.
>>
>> Thus the RS can have an unspecified source address while containing a SLLAO; something which isn't allowed in 4861 AFAICT. So need to look at mixed mode issues here.
>>
>>   Erik
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------