Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd
"Leaf Y. Yeh" <leaf.y.yeh@huawei.com> Mon, 25 October 2010 09:48 UTC
Return-Path: <leaf.y.yeh@huawei.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 D160D3A699C for <dhcwg@core3.amsl.com>; Mon, 25 Oct 2010 02:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.216
X-Spam-Level:
X-Spam-Status: No, score=0.216 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 x1aN7gs4Dt5r for <dhcwg@core3.amsl.com>; Mon, 25 Oct 2010 02:48:53 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 179A03A681E for <dhcwg@ietf.org>; Mon, 25 Oct 2010 02:48:53 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU00LFHBAZXN@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 25 Oct 2010 17:49:47 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU00DVIBAYT2@szxga04-in.huawei.com> for dhcwg@ietf.org; Mon, 25 Oct 2010 17:49:46 +0800 (CST)
Received: from y00168393 ([10.70.39.77]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAU00KXGBAVZF@szxml04-in.huawei.com> for dhcwg@ietf.org; Mon, 25 Oct 2010 17:49:46 +0800 (CST)
Date: Mon, 25 Oct 2010 17:49:43 +0800
From: "Leaf Y. Yeh" <leaf.y.yeh@huawei.com>
In-reply-to: <E158B569-804C-4CCB-A293-E5B2CE6BAE03@employees.org>
To: 'Ole Troan' <otroan@employees.org>, dhcwg@ietf.org
Message-id: <00cf01cb7429$f33e5220$d9baf660$%y.yeh@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="ISO-8859-1"
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: Act0IZ+Qcf98s9f8TuOYk+MIDXcKxQAAQlvA
References: <173C2922115645EFAD0E98234686E27A@china.huawei.com> <00b601cb741f$eeec68b0$ccc53a10$%y.yeh@huawei.com> <E158B569-804C-4CCB-A293-E5B2CE6BAE03@employees.org>
Cc: volz@cisco.com
Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd
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: Mon, 25 Oct 2010 09:48:54 -0000
Hi, Ole Ole- so it is one thing that a relay snoops DHCP traffic between client and server, Per the section 6.2 'Routing table function' of 'Broadband Network Gateway Requirements' in BBF WT-177, RA does snoop the DHCPv6 message between client and server for the adding & deleting the route entry pointing to the customer network in its routing table. Ole- but it is another when the DHCP protocol is used to provision the intermediate device. is this something we really want DHCP to do? Yes, we can. We can let DHCPv6 use for some kind of provision (or stateful configuration) for the RA besides for the clients. Right? Best Regards, Leaf -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Monday, October 25, 2010 4:48 PM To: Leaf Y. Yeh Cc: volz@cisco.com; dhcwg@ietf.org Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd so it is one thing that a relay snoops DHCP traffic between client and server, but it is another when the DHCP protocol is used to provision the intermediate device. is this something we really want DHCP to do? cheers, Ole On Oct 25, 2010, at 10:38 , Leaf Y. Yeh wrote: > Hi, Bernie > > Bernie So, if the DHCPv6 server is allocating addresses from a /40 to the CPEs (which may be getting /56), the Prefix Pool option would contain the /40 prefix so that the Relay would advertise the /40 instead of just each of the /56 prefixes actually assigned to the CPEs? > > Thats right. > > Bernie You might want to include an example such as this in the draft to make it clear. > > I got a new Fig.1 in my I.D.-01 (pls. refer to http://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-prefix-pool-opt/ ) to make a little bit more clarification on it. > > For example: > a. Binding entry @ server is : pe#1_cfi#2 < - > 3ffe:ffff:0::/40 > b. Client-facing interface @ PE implementing RA : interface_id= pe#1_cfi#2; prefix pool= 3ffe:ffff:1200::/40 > c. Prefix got through DHCPv6-PD @ CE : customer network= 3ffe:ffff:1234:5600:/56 > > Bernie This does assume that there is only one relay being allocated prefixes from this /40 pool? Thats probably why theres the text about Interface-Id option. > > The relay agent (RA) described in my I.D. is always implemented on the Provide Edge router (PE, BRAS, or BNG). If we look into the access network architecture defined in Broadband Forum (BBF) WT-177(or TR-101), one more Lightweight DHCPv6 Relay Agent (LDRA) (pls. refer to http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-ldra/ ) is always implemented in the Access Node (AN), which acts as a link-layer bridge between Customer Router (CPE, CE, or Routed-RG) and PE. The Interface ID option inserted by AN is used by the server to identified the subscriber line to which the prefix of the customer network (eg. /56) is delegated, while the Interface ID option inserted by PE implementing RA described in my I.D. is used by the server to identified to client-facing interface of PE where the prefix pool (eg. /40) is located or configured. > > > Best Regards, > Leaf Yeh > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) > Sent: Saturday, October 16, 2010 11:56 AM > To: Leaf Y. Yeh; dhcwg@ietf.org > Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd > > So, if the DHCPv6 server is allocating addresses from a /40 to the CPEs (which may be getting /56), the Prefix Pool option would contain the /40 prefix so that the Relay would advertise the /40 instead of just each of the /56 prefixes actually assigned to the CPEs? You might want to include an example such as this in the draft to make it clear. When I first read it, I thought it was similar to the RAAN option too. > > This does assume that there is only one relay being allocated prefixes from this /40 pool? Thats probably why theres the text about Interface-Id option. > > - Bernie > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Y. Yeh > Sent: Friday, October 15, 2010 5:52 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent - Sent @ 3rd > > Hi, Roberta > > The design goal & usage of RAAN (Assignment Notification) option are quite different with those of Prefix Pool option. > > l RAAN option specified in draft-ietf-dhc-dhcpv6-agentopt-delegate-04, is sent by the DHCPv6 server to inform the RA (Relay Agent) of the IPv6 prefixes & the IPv6 addresses that have been assigned to the DHCPv6 client by the server. > > Because RA can directly get the information about the address assigned & the prefixes delegated from the messages relayed through RA, it sounds not be necessary to use the Assignment Notification option to get these information. > > Is this a reason why DHC WG let the I.D.-draft-ietf-dhc-dhcpv6-agentopt-delegate-04 expire? > > l Prefix_Pool_Option defined in draft-yeh-dhc-dhcpv6-prefix-pool-opt, is sent by the DHCPv6 server to inform the RA of the IPv6 prefix pool from which the prefix of the customer network is got to delegate. > > The information about the Prefix Pools can be used to generate the aggregation (black-hole) route entries in the routing table on RA, which is regarded as a necessary (or strongly recommended) action on the PE router in the new draft. > > The information about the Prefix Pools is always maintain on the server, so we need a new mechanism of Prefix_Pool_Option to transfer these information from the server to RA. > > > Best Regards, > > Leaf Yeh > > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Maglione Roberta > Sent: Thursday, October 14, 2010 3:52 PM > To: Tina Tsou; dhcwg@ietf.org > Subject: Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent > > Hi Tina, > Whats the difference between the new option you are proposing in this draft and the RAAN option specified in > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-04 ? > > Thanks > Regards, > Roberta > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tina Tsou > Sent: mercoledì 13 ottobre 2010 23.32 > To: dhcwg@ietf.org > Subject: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent > > Hi all, > http://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-prefix-pool-opt/ > talks about Prefix Pool Option for DHCPv6 Relay Agent. > > Abstract > > The Prefix Pool option provides an automatic mechanism for the > information exchange between DHCPv6 server and DHCPv6 Relay Agent. > The information about Prefix Pools maintained on DHCPv6 server can be > transferred from server to relay agent through this DHCPv6 option to > support the necessary route aggregation on the provide edge router, > which has a huge number of routes pointing to the customer networks > before the aggregation. > > Your comments are welcome. > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > <image001.gif>Rispetta l'ambiente. Non stampare questa mail se non è necessario. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Leaf Y. Yeh
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ole Troan
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Leaf Y. Yeh
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ole Troan
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ted Lemon
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ole Troan
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ted Lemon
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ole Troan
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ted Lemon
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Bernie Volz (volz)
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Leaf Y. Yeh
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Leaf Y. Yeh
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Ted Lemon
- Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay A… Bernie Volz (volz)