Hi:

More comments in-lined.

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Andreas Maier
> Sent: Monday, February 21, 2005 11:44 AM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] IPv6 prefix delegation extension
> 
> 
> Dear Bernie,
> 
> please find comments in-lined.
> 
> On 02/17/05 23:02:20, Bernie Volz wrote:
> > Actually, I think there are implementations that support this.
> Do you have an URL ready to hand?
> 
> > There is however another model and that is to have the intermediate 
> > router act as a relay agent and send the request further upstream
> > (such as even to a DHCPv6 server that is NOT a router).
> I think these are two different things at once:
> 1) PD and router: As of RFC-3633 the PD is between two 
> routers. You are  removing this requirement by allowing the 
> delegating router to no be  a DHCPv6 server.

No, I'm not changing RFC 3633, I quote from RFC 3633:

14.  Relay agent behavior

   A relay agent forwards messages containing Prefix Delegation options
   in the same way as described in section 20, "Relay Agent Behavior" of
   RFC 3315.

   If a delegating router communicates with a requesting router through
   a relay agent, the delegating router may need a protocol or other
   out-of-band communication to add routing information for delegated
   prefixes into the provider edge router.
 

> 2) Hierarchical PD: With the use of relay agents it may 
> become possible  to support meshed network architectures too 
> and not being bound to  tree like structures.
> 
> > The main issue with this approach is that there is no good way for 
> > that device (or the intermediate router) to begin advertising the
> > routes. The server could perhaps do this by running routing  
> > protocols, but that may not be practical or desireable.
> Are you suggesting that the DHCPv6-PD server should inject 
> the routes of all the delegated prefixes into the routing 
> protocol? I do not see how this can work to the PD network 
> but only to announce the internal
> prefix(es) to the outside world.

I don't see this being practical either. I'm just stating the possibilities.
Some device must do the route injection - it can be the PD server, the PD
client, or a Relay Agent between the two.

> 
> > One solution would be for the relay agent to look inside 
> the client's 
> > message and determine the prefixes (and lifetimes) being added or 
> > removed. However, this isn't very desirable in my opinion. It also
> > requires state on the relay as REPLY messages don't carry 
> sufficient  
> > information to know what the client requested (as in the case of a  
> > RELEASE).
> > 
> > So, I'm actually planning on writing a draft to address this by
> > adding a relay agent option that allows the server to 
> communicate to  
> > the intermediate relay (likely the one closest to the client) what  
> > prefixes to begin, continue, or stop advertising in the routing  
> > system for the client. It likely would be a relatively 
> simple option  
> > which would communicate the prefix, prefix-length, and 
> lifetimes (0  
> > lifetimes are used to terminate the delegation). These options are  
> > set in normal relayed traffic going back to the client; no new  
> > messages are sent.
> Are relay agents able to operate in a hierarchical manner so 
> that an agent can automatically find its upstream counterpart 
> which may also be a relay agent? The necessity to configure a 
> DHCP server address at each relay agent should be avoided.

There may be self discovery techniques that can be used or it requires some
type of configuration. Even in the "classical" PD case, you still need to
configure the PD Server. So, what is the difference? Relay agents can use
the "All DHCP Servers" multicast address if they don't have explicit DHCP
server addresses.

> 
> > This model would have the server which receives the relayed PD
> > request respond as normal to the client but include this 
> new option  
> > (or options if one per delegated prefix) in the relay's portion of  
> > the message and the relay would then add the prefixes, update the  
> > lifetimes, or remove the prefixes from its routing tables. 
> The router  
> > would know which interface as it is the interface on which it  
> > forwards on the client's message.
> Can the upstream path be automatically detected or need it be 
> assigned manually to an interface?
> 
> > This then would allow both types of operation - either relayed or 
> > where the relay is both a client and server.
> The use of a central DHCP server reveals the internal 
> structure of the PD network to this server which may or may 
> not be desirable.

Correct. There are pros and cons with any configuration model. However, what
is nice about the "central" one is that it is centralized.

> 
> Thank you for your input. Best regards,

Ditto!

> -andi
> 
> > > -----Original Message-----
> > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On 
> > > Behalf Of Andreas Maier
> > > Sent: Thursday, February 17, 2005 8:13 AM
> > > To: dhcwg
> > > Subject: Re: [dhcwg] IPv6 prefix delegation extension
> > >
> > >
> > > Dear Changming,
> > >
> > > I also think that the current DHCP-PD spec is sufficient 
> and that a
> > 
> > > hybrid mode DHCPv6 server/client implementation may do the trick. 
> > > Unfortunately no such implementation seems to exist so I can not 
> > > test it immediately.
> > >
> > > Before starting to code it myself many points are unresolved:
> > > -) Does a "hierarchical" prefix delegation make sense?
> > > -) Are there conflicts with the existing prefix delegation?
> > > -) Is a tree-like network structure a valid assumption?
> > > -) Is work already done in this field? Are there references?
> > > -) Are there obvious pitfalls that I do not see?
> > > -) Is it useful to standardize the operation of the hybrid mode 
> > > DHCPv6 server?
> > >
> > > I think that the idea of automatically configuring routers in a 
> > > hierarchical network is valid. Thanks for conforming that 
> it should 
> > > be possible to implement it on top of the existing DHCP-PD without
> > > modifications to the current DHCP-PD specification. In addition  
> > very
> > 
> > > much appreciated would be pointers to research performed 
> in the same 
> > > or a similar area.
> > >
> > > Thank you very much. Best regards,
> > > -andi
> > >
> > > PS: Security is also a major concern but I would like to 
> deal with 
> > > it later.
> > >
> > > _______________________________________________
> > > dhcwg mailing list
> > > dhcwg@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dhcwg
> > >
> 
> -- 
> | Andreas Maier               Paris-Lodron University of Salzburg   |
> | (andi@cosy.sbg.ac.at)       Department of Scientific Computing    |
> | Tel. +43/662/8044-6339      Jakob Haringerstr. 2                  |
> | Fax. +43/662/8044-172       5020 Salzburg / Austria, Europe       |
> 
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg