Re: [dna] DNA and DHCPv6
Ralph Droms <rdroms@cisco.com> Fri, 20 November 2009 17:14 UTC
Return-Path: <rdroms@cisco.com>
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC603A6946; Fri, 20 Nov 2009 09:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv13Ago31PhD; Fri, 20 Nov 2009 09:14:04 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1CCFA3A6358; Fri, 20 Nov 2009 09:14:04 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAGJdBktAZnwN/2dsb2JhbAC9O5dihDwEgW8
X-IronPort-AV: E=Sophos;i="4.44,778,1249257600"; d="scan'208";a="69165349"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2009 17:14:00 +0000
Received: from bxb-rdroms-8712.cisco.com (bxb-rdroms-8712.cisco.com [10.98.10.83]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAKHDx1I003968; Fri, 20 Nov 2009 17:13:59 GMT
Message-Id: <CC929A72-A7A9-4046-B2C2-5E26D47191C6@cisco.com>
From: Ralph Droms <rdroms@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
In-Reply-To: <BLU137-DS1D82CF3CD90846438826393A10@phx.gbl>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 20 Nov 2009 12:13:59 -0500
References: <4B0655CB.2040309@piuha.net> <BLU137-DS32F4D6442FA52382BD73893A10@phx.gbl> <A75B573B-CABA-4E5E-AFFC-A26DD7F1168C@cisco.com> <BLU137-DS1D82CF3CD90846438826393A10@phx.gbl>
X-Mailer: Apple Mail (2.936)
Cc: DNA <dna@eng.monash.edu.au>, dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, IESG IESG <iesg@ietf.org>, dhc WG <dhcwg@ietf.org>
Subject: Re: [dna] DNA and DHCPv6
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2009 17:14:06 -0000
So, would this be an accurate description of Simple DNA: * Send NS for each candidate link to the default router for that link * Initiate RS/RA exchange as specified in RFC 4861 * Initiate DHCPv6 exchange as specified in RFC 3315 * If an NA is received, used cached info for corresponding link from SDAT * Process any received RAs as specified in RFC 4861 * Use info from DHCPv6 exchange as specified in RFC 3315 * Info from RA and/or DHCPv6 overrides any reused cached info based on NA - Ralph On Nov 20, 2009, at 11:39 AM 11/20/09, Bernard Aboba wrote: >> I believe that many of Ralph's issues below are the result of poor >> wording in the document. >> >> The draft specifically says that it does not change the DHCPv6 >> protocol, state machine or timers, so that any situation in which >> there is an implied DHCPv6 change represents an error. > > "It makes sense to me that DHCPv6 would not be changed by this > document. DHCPv6 already has a mechanism through which a host can > determine, in one DHCPv6 message exchange, if it has reattached to its > most recently attached link. If the host has moved to a new link, an > additional 4 message exchange (possibly optimized to 2 messages) is > necessary to get configuration information for the new link." > > [BA] Right. That mechanism should be used as is, with no changes. > > "In addition to the text that may imply skipping an initial delay when > sending an initial DHCPv6 message, the third paragraph of section 4.6 > of this document changes the DHCPv6 protocol by specifying that a host > always send a Solicit message first, possibly including addresses from > previously visited links as hints. I think the text about this step > is a little fuzzy about which addresses should be sent and how they > should be sent." > > [BA] The contents of DHCPv6 packets shouldn't be dependent on any > aspect of > DNA. > For example, DNA shouldn't influence whether a Solicit message is > sent first > nor > what addresses are used as hints. Whatever any implementation already > does should be left alone. After all, DNA is just an optimization. > > "I could imagine an argument for a change to DHCPv6 that requires the > host to send a Confirm message for each of its currently valid > addresses and a Solicit message, all in a burst, to probe all possible > links in parallel, rather than just checking for reattachment to the > most recently attached link. However, it would be a significant > change to DHCPv6 that has the potential for significant load on the > DHCPv6 service." > > [BA] I don't see a need to change DHCPv6, particularly if this would > create potential problems. > > "Another link between Simple DNA and DHCPv6 comes to mind at this > point. Here is the second paragraph of section 4.7: > > On reception of a Router Advertisement or advertising DHCPv6 > message > (a REPLY or ADVERTISE) which contains prefixes that intersect with > those previously advertised by a known router, the host utilizes > the > configuration associated with the detected network. > > What, exactly, does "utilize the configuration" mean, in relation to > DHCPv6? Does the host use any DHCPv6-assigned addresses without > sending a Confirm message to the DHCPv6 service? If the host has not > reattached to its most recently attached link, presumably the host > will have received a NAK from the DHCPv6 service from its initial > Confirm (which checked just the most recently attached link). > Depending on the timing, the host may have already initiated a DHCPv6 > message exchange for the current link." > > [BA] I have no idea what this paragraph means (or even why it is > necessary). > > Shouldn't a host just do what it would normally do in response to > these > messages? After all, DNA is only really about use of neighbor > discovery, > not RS/RA or DHCPv6. > > "Also, this paragraph specifies "prefixes that intersect with those > previously advertised by a known router". Suppose the set of prefixes > intersects but is not identical to those previously advertised? I > assume the host uses the newly received configuration. But, by now > the host has all the current configuration information from its local > router, so what's the point?" > > [BA] As far as I can see, the only case worth additional discussion is > the one in which there are prefixes that don't intersect. > > "As I mentioned above, I don't think the behavior you describe here is > currently described in the document." > > [BA] Right. My take is that this (and other DHCPv6 changes you > mention) > are unnecessary and should be removed. >
- [dna] next steps on draft-ietf-dna-simple Jari Arkko
- Re: [dna] next steps on draft-ietf-dna-simple Bernard Aboba
- [dna] DNA and DHCPv6 Bernard Aboba
- Re: [dna] DNA and DHCPv6 Ralph Droms
- Re: [dna] DNA and DHCPv6 Bernard Aboba
- Re: [dna] DNA and DHCPv6 Ralph Droms
- Re: [dna] DNA and DHCPv6 Bernard Aboba
- Re: [dna] next steps on draft-ietf-dna-simple Suresh Krishnan
- Re: [dna] [DNA] RE: DNA and DHCPv6 Bernard Aboba
- Re: [dna] next steps on draft-ietf-dna-simple Bernard Aboba
- Re: [dna] next steps on draft-ietf-dna-simple Jari Arkko
- Re: [dna] next steps on draft-ietf-dna-simple Bernard Aboba
- Re: [dna] next steps on draft-ietf-dna-simple Jari Arkko
- Re: [dna] next steps on draft-ietf-dna-simple Ted Lemon
- Re: [dna] next steps on draft-ietf-dna-simple Jari Arkko
- Re: [dna] next steps on draft-ietf-dna-simple Suresh Krishnan
- Re: [dna] next steps on draft-ietf-dna-simple Jari Arkko