Re: [dhcwg] Prefix Pool Option for DHCPv6 Relay Agent

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?
>  
> That’s 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? That’s probably why there’s 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? That’s probably why there’s 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,
> What’s 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