Re: [dhcwg] Relaxing text in RFC3633 [recap]

Ted Lemon <Ted.Lemon@nominum.com> Tue, 17 August 2010 03:15 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389D93A683C for <dhcwg@core3.amsl.com>; Mon, 16 Aug 2010 20:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.319
X-Spam-Level:
X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Anv2aqQjBpbH for <dhcwg@core3.amsl.com>; Mon, 16 Aug 2010 20:15:05 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 42A353A67F8 for <dhcwg@ietf.org>; Mon, 16 Aug 2010 20:15:05 -0700 (PDT)
Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTGn+2GCJiFstO/JeDWl5SWQOWC/kNWFR@postini.com; Mon, 16 Aug 2010 20:15:41 PDT
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A7B931B82CB; Mon, 16 Aug 2010 20:15:36 -0700 (PDT)
Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 16 Aug 2010 20:15:36 -0700
MIME-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <3FA26C12-8703-429E-878A-87C7D627DC3D@gmail.com>
Date: Mon, 16 Aug 2010 23:15:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <98EF5A8E-3C71-4D86-8A75-672213B013ED@nominum.com>
References: <4FD1E7CD248BF84F86BD4814EDDDBCC150AD8FDE9F@EUSAACMS0703.eamcs.ericsson.se> <alpine.DEB.1.10.1008041546330.19930@uplift.swm.pp.se> <4C597E80.1000403@ericsson.com> <alpine.DEB.1.10.1008042036380.19930@uplift.swm.pp.se> <4C59B720.4040200@ericsson.com> <alpine.DEB.1.10.1008042105370.19930@uplift.swm.pp.se> <A90ADD6B-04F2-4897-865D-A2C065BC0358@gmail.com> <alpine.DEB.1.10.1008050608011.19930@uplift.swm.pp.se> <4FD1E7CD248BF84F86BD4814EDDDBCC150AD9E2849@EUSAACMS0703.eamcs.ericsson.se> <alpine.DEB.1.10.1008050724120.19930@uplift.swm.pp.se> <33842498-D36C-4A0F-9C8D-8476B276817F@gmail.com> <alpine.DEB.1.10.1008051259170.19930@uplift.swm.pp.se> <4073260D-FB58-4D72-82D3-C62A205B9688@employees.org> <alpine.DEB.1.10.100 8051309390.19930@uplift.swm.pp.se> <BB0E5CD4-30DC-4D22-A2D1-C6D845A8A568@gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F5F0044A43E@NOK-EUMSG-01.mgdnok.nokia.com> <640958F6-56CB-434B-850F-66607CEA8D85@nominum.com> <EEEFC08F-6AF4-4F3A-A811-2C8C5DD9DB9D@employees.o! rg> <4C698480.3070400@ericsson.com> <3FA26C12-8703-429E-878A-87C7D627DC3D@gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: DHC Group Working <dhcwg@ietf.org>, "alexandru.petrescu@gmail.com" <alexandru.petrescu@gmail.com>
Subject: Re: [dhcwg] Relaxing text in RFC3633 [recap]
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 17 Aug 2010 03:15:06 -0000

On Aug 16, 2010, at 6:34 PM, Ralph Droms wrote:
>  with the following exception: the requesting router MUST
>  NOT assign any delegated prefixes or subnets from the delegated
>  prefix(es) to the link through which it received the DHCP message
>  from the delegating router.

When I read this text, the way it first appeared to me was that it was saying the RR should not do PD on the link on which it got the prefix, but it's not saying that, so I guess my main objection to changing this text goes away.

However, if we add the ability to knock out a /64 from a delegated prefix, the need to relax this restriction goes away--it makes much more sense for the DR to assign the RR an address out of the /64 than it does for the DR to *delegate* the /64 to the RR.

What's the scenario where the RR would get a *delegation* of a /64 and then assign it to the interface on which it received the delegation?   How would that even work?   I think this change is simply unnecessary.