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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 25 February 2014 07:39 UTC

Return-Path: <pthubert@cisco.com>
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 757111A053B for <ipv6@ietfa.amsl.com>; Mon, 24 Feb 2014 23:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level:
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 65wT_TtMZsl4 for <ipv6@ietfa.amsl.com>; Mon, 24 Feb 2014 23:39:34 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 587A21A0346 for <ipv6@ietf.org>; Mon, 24 Feb 2014 23:39:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3349; q=dns/txt; s=iport; t=1393313974; x=1394523574; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9/Mujw/WAPwGzmad5vaUnd40q4ojn9Yz5CGmAovV6PI=; b=Y8CwxREr5n8QAFIQPcxxJdk5Y5WW36EsSySfNrqbMI3gOczmBfDvhL/z sV0Boc52MszQWBQOxONM9tgUYwKMPAy3BfaAanInr1Ke5idQXjKcbcjIw YqY0LSVJKR0kBXKqQ+Xu0KjDVYnnNkQuc+66GOMGSB5l1N5pwIo3JCv05 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAERIDFOtJXHA/2dsb2JhbABZgwg4vh2BFxYBdIN9AQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FG4dhCA2+VhMEjl8zB4MjgRMEiQuPC5IUgyuBaCQ
X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="303263405"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 25 Feb 2014 07:39:33 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1P7dXUH029768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 07:39:33 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.84]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 01:39:33 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Erik Nordmark <nordmark@acm.org>
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
Thread-Index: AQHPLg20SjVxfDziP0SiLTMeBLFIcJrFDYrPgACPzGs=
Date: Tue, 25 Feb 2014 07:39:32 +0000
Message-ID: <C43B8408-5249-423E-8361-E8619C280E25@cisco.com>
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org>, <530BCF83.4090500@acm.org>
In-Reply-To: <530BCF83.4090500@acm.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4p0IJIgM2NNNOVaj2asr5y7sxDM
Cc: Erik Nordmark <nordmark@acm.org>, "Andrew Yourtchenko (ayourtch)" <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: Tue, 25 Feb 2014 07:39:36 -0000

And we need to remember that the assignment is just one component of the lifecycle of an address. 

When the client stops using an address, or moves the address somewhere else in the fabric, there is a need to update the network support that defends the address and proxies.

Cheers,
Pascal

> Le 25 févr. 2014 à 00:04, "Erik Nordmark" <nordmark@acm.org> a écrit :
> 
>> On 2/20/14 6:43 AM, Ole Troan wrote:
>> <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.
> DHCP supports RFC 4941 temporary addresses, but it doesn't support others like CGA and stable-privacy-addresses. With IA_TA the DHCP server creates the temporary address, and that approach doesn't work with other addresses that need to be client-generated for security or privacy reasons.
> 
> One could envision changing DHCP to have a separate "please register this address" message and/or option, which would check against duplicates (of assigned and registered addresses) and then add it to the registered addresses in the server. But that would seem like a fair bit of new functionality in DHCP.
> 
> Currently RFC 3315 separates address assignment and DAD - the client SHOULD perform DAD on an address that is assigned by the DHCP server. This separation goes back to DHCPv4 where there was a similar check (I think using ICMP echo) which I believe is there for the reason that the DHCP servers list of assigned addresses could get out of sync with the hosts. (If DAD fails the host declines the address hence will get a different one.)
> 
> I don't see how we can do this without host changes even for the case of IA_NA and IA_TA DHCP assigned addresses; the hosts would need to remove the code which does the DAD check for DHCP. (And there would be additional DHCP protocol changes needed to support CGA and stable-privacy-addresses and any future address assignment scheme.)
> 
>   Erik
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------