Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

Ole Troan <otroan@employees.org> Thu, 20 February 2014 15:03 UTC

Return-Path: <otroan@employees.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 75DB71A01BE for <ipv6@ietfa.amsl.com>; Thu, 20 Feb 2014 07:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
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 ZivLzBRgyD82 for <ipv6@ietfa.amsl.com>; Thu, 20 Feb 2014 07:03:28 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2E1A0183 for <ipv6@ietf.org>; Thu, 20 Feb 2014 07:03:28 -0800 (PST)
Received: from dhcp-10-61-103-42.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 38591670A; Thu, 20 Feb 2014 06:43:18 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F702BDC9-3511-45AC-AB81-1AA73E3A6906"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
From: Ole Troan <otroan@employees.org>
In-Reply-To: <5305AF13.5060201@acm.org>
Date: Thu, 20 Feb 2014 15:43:15 +0100
Message-Id: <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org>
References: <5305AF13.5060201@acm.org>
To: Erik Nordmark <nordmark@acm.org>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/n2Lifj_JLP-NBLcMpyLC2PKBABU
Cc: Andrew Yourtchenko <ayourtch@cisco.com>, 6man WG <ipv6@ietf.org>
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: Thu, 20 Feb 2014 15:03:30 -0000

<nochair>

> 4.8 seems to conflate the address assignment with DAD. Just because we might want to centralize the DAD checks doesn't imply that we want to remove the ability for the host to pick its own privacy enhanced interface-IDs to form its addresses.
> From a deployment perspective DHCPv6 is available for address assignment, but don't think we want to require that for WiFi or other links which have packet loss. (Packet loss occurs on wired networks as well, but the drop distribution is different - might happen during spanning tree reconvergence etc.)
> Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses received from the DHCP server - needed since the server could be confused.

I'd like to explore the difference between DHCP address assignment and ND address registration a little more.
the state that is required in the network for "efficient ND", why cannot that be created and maintained by DHCP?

there are multiple ways of dealing with DAD in this scenario, including solutions that don't require host changes.
DHCP also supports temporary addresses btw.

cheers,
Ole

</nochair>