IETF Logo Mail Archive

Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Ted Lemon <Ted.Lemon@nominum.com> Tue, 04 September 2012 20:23 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683421E8043 for <dhcwg@ietfa.amsl.com>; Tue, 4 Sep 2012 13:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.448
X-Spam-Level:
X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz+USejM-yGD for <dhcwg@ietfa.amsl.com>; Tue, 4 Sep 2012 13:23:41 -0700 (PDT)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2A21E803F for <dhcwg@ietf.org>; Tue, 4 Sep 2012 13:23:41 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUEZjTIlPzQKxUN4z2pRzUml/RVmTT3Hk@postini.com; Tue, 04 Sep 2012 13:23:41 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AF6011B8314 for <dhcwg@ietf.org>; Tue, 4 Sep 2012 13:23:19 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A0DC319005C; Tue, 4 Sep 2012 13:23:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 4 Sep 2012 13:23:21 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
Thread-Index: AQHNiseG0gBB4UDEXUCV9TC7KIiRUpd7B/YAgAALBQCAAAMLAA==
Date: Tue, 04 Sep 2012 20:23:18 +0000
Message-ID: <673BFDC7-AEC2-4944-BECA-828F9DC06206@nominum.com>
References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <E666D4CA7557D04DB6B9B2BA6DC28F3D285C2A36F8@INBANSXCHMBSA3.in.alcatel-lucent.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <FDF07965-FE45-4A36-8563-EFD748351A39@nominum.com> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> <BF63E815-FFCF-48E6-A146-B9C7030C9FAD@gmail.com>
In-Reply-To: <BF63E815-FFCF-48E6-A146-B9C7030C9FAD@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_673BFDC7AEC24944BECA828F9DC06206nominumcom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 04 Sep 2012 20:23:42 -0000

On Sep 4, 2012, at 4:12 PM, Ralph Droms <rdroms.ietf@gmail.com<mailto:rdroms.ietf@gmail.com>>
 wrote:
One issue that comes to mind for me is that the DHCPv6 server may not, in fact, have complete information about the routing and prefix aggregation information.  The DHCPv6 server would be inferring aggregation information from the pools of prefixes it has to delegate.  Looked at another way, there is likely an oracle of network configuration somewhere from which the delegated prefix pools and prefix aggregation for routing is derived.  The DHCPv6 server might be able to make an educated guess but it doesn't have necessarily authoritative information.

I don't think you'd want to configure this option if you didn't think the DHCP server had accurate information about the network configuration.

Another issue with piggybacking is that the routing information may change independent of any specific DHCPv6 message exchanges (someone else raised this issue), so that there would be noway to send updates if there was no DHCPv6 traffic to send through the router.

Can you describe an actual use case where this would happen?   It seems to me that in a situation like the one you describe, you'd have chaos and wreckage, because all the CPE devices would still be configured with prefixes that were no longer valid.

Why would this aggregation information not be provided through whatever configuration mechanism is used to manage the router?

Because it might change dynamically whereas the rest of the router configuration is static?

v2.23.0 | Report a Bug | By Email