Re: [dhcwg] DHCPv6 Stateful Issues

"Bernie Volz (volz)" <volz@cisco.com> Thu, 06 February 2014 21:23 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A161A0133 for <dhcwg@ietfa.amsl.com>; Thu, 6 Feb 2014 13:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.035
X-Spam-Level:
X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 xN3ZbmGeEq_G for <dhcwg@ietfa.amsl.com>; Thu, 6 Feb 2014 13:23:41 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 588D01A017A for <dhcwg@ietf.org>; Thu, 6 Feb 2014 13:23:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12886; q=dns/txt; s=iport; t=1391721820; x=1392931420; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E4RYiFWB7vpXqBErupTgUOpWmDHcHjbnpdy/shmIOxs=; b=NDArDsCoqHOPjCp9feDxqNmlV2jcDbLbd3s21phv4X81dlm1akTOh8OG CqgHjoKFedweeFFDexQ7yK1K9kgOM8mA1tUyknn3KpUHwqr38da59cj0A 3+oSt80aaw84oa0ahEhtBfSosmuyfvqqLBkFOHqawVDNb8JbNnPEaDWJC A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjwFAID881KtJXG8/2dsb2JhbABZDoI6RDhXvnSBDhZ0giUBAQEDAQEBASpBCwUHBAIBCA4DBAEBCx0HJwsUCQgCBA4FCId1CA3NAhMEjkkmBwQGAQaDHoEUBKpMgm4/gio
X-IronPort-AV: E=Sophos; i="4.95,795,1384300800"; d="scan'208,217,223"; a="302425992"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 06 Feb 2014 21:23:39 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s16LNdpR014050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 21:23:39 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 15:23:39 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Timothy Winters <twinters@iol.unh.edu>
Thread-Topic: [dhcwg] DHCPv6 Stateful Issues
Thread-Index: AQHPIQJmiQAo8HL4V0q/V8TsAiMQoJqlFU9AgAIntICAAAX6YA==
Date: Thu, 06 Feb 2014 21:23:39 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AE5BE93@xmb-rcd-x04.cisco.com>
References: <44F7934F-540F-4B41-B37D-08B0C0453D72@iol.unh.edu> <489D13FBFA9B3E41812EA89F188F018E1AE5502E@xmb-rcd-x04.cisco.com> <ADFC9318-2019-4E30-836C-595EC7AB5D9F@iol.unh.edu>
In-Reply-To: <ADFC9318-2019-4E30-836C-595EC7AB5D9F@iol.unh.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.246.35]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AE5BE93xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] DHCPv6 Stateful Issues
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 21:23:44 -0000

>From the packet capture it sends a Decline for the address and a Release for the prefix. While I would consider this acceptable, the Release  isn't optimum (and likely creates unnecessary overhead for both client and server). I would expect the client will Solicit and will get (another different) address and possibly the same or a different prefix. Would likely have been better for client to keep the prefix ... it can go back to Solicit asking for both, as prefix will be given to client again or based on the Stateful Issues, do a Request - but that is not presently allowed per RFC 3315.


-          Bernie

From: Timothy Winters [mailto:twinters@iol.unh.edu]
Sent: Wednesday, February 05, 2014 11:14 AM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] DHCPv6 Stateful Issues

Hi Bernie,
        I've enclosed a capture of the behavior.   This particular device did send two separate Release messages.  Let me know if you have other questions.

Regards,
Tim


On Feb 4, 2014, at 8:25 AM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote:

> Hi Tim:
>
> I too would have expected just the IA_NA (IAADDR) to be declined. You don't mention what the clients are doing in this case (sending a Decline with both the IA_NA and IA_PD or sending a Release with both - or sending a Decline for the IA_NA and Release for the IA_PD)?
>
> A DAD conflict should result in a Decline. So, it would seem to me that the added step of sending a Release for the IA_PD (IAPREFIX) is extra effort and not necessary/warranted. And I would hope these clients aren't sending a Decline for the IA_PD (IAPREFIX).
>
> Also, did the routers doing the IA_PD Release earlier request the IA_NA and IA_PD in the same packet (transaction) or different ones?
>
> Be nice if you had a packet trace available to see what the interaction here is?
>
> This does sound like a candidate for discussion in the draft, but we need a bit more information before considering to add it.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Timothy Winters
> Sent: Monday, February 03, 2014 12:07 PM
> To: dhcwg@ietf.org<mailto:dhcwg@ietf.org> WG
> Subject: [dhcwg] DHCPv6 Stateful Issues
>
> Hi Bernie,
>        While testing some IPv6 CE Router I've noticed an issue that this draft might want to address.  When a DHCP Client receives both the IA_NA and IA_PD in the reply, the Client performs DAD on the IA_NA.   If DAD fails some implementations keep the IA_PD and try for a different IA_NA.   Other IPv6 CE Routers will Release the IA_PD in this scenario.
>
>         I would think the proper thing to do would be to keep the IA_PD so your LAN as addressing.   Is something that we can talk about in this document?
>
> ~Tim
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org<mailto:dhcwg@ietf.org>
> https://www.ietf.org/mailman/listinfo/dhcwg