Subject: RE: [dhcwg] IPv6 prefix delegation extension

From: "Changming Liu" <[email-masked]>
Date: Tue, 15 Feb 2005 13:50:17 -0800

Andreas,

Thanks for the detailed explanation. I guess we are talking about the
same thing. To me it seems that the hybrid mode of immediate routers is
an implementation issue. There will be no interoperability issue and
thus the current DHCP-PD spec should be sufficient. Is this correct?

Changming 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andreas Maier
Sent: Tuesday, February 15, 2005 7:55 AM
To: dhcwg
Subject: Re: [dhcwg] IPv6 prefix delegation extension

Dear Changming,
dear Mark,

thank you for your replies.

On 02/15/05 14:04:43, Mark Thompson wrote:
> 
> On Feb 14, 2005, at 17:53, Changming Liu wrote:
> 
>> Will this make the PD more complicated, hard to implement and hard  
>> to configure as well? Is it possible to run DHCP PD at each hop down

>> the tree?

More complicated? No. The mechanism for DHCPv6 PD as of RFC-3633 does  
not need to change. Small additions may be helpful to increase  
resistance against misconfiguration or to enable corner cases.

Hard to implement? Yes. Each intermediate router acts as a DHCP PD  
client and a DHCP PD server at the same time. Additionally it has to  
perform sub-network splitting, aggregation and more.

Hard to configure? No. The configuration of the "root" routers stays  
the same and all other routers need not configuration because they are  
automatically configured through the proposed mechanism.

A requirement would be that each router runs DHCP DP. Intermediate  
routers are hybrid in that they are clients up the tree and servers  
down the tree. Each intermediate router should make subdividing  
decisions on its own and should hide subtree details.

> What would the signalling look like for R2 to announce (renumber?) to

> its downstream (R3) when R1 delegates to R2?
> 
> +---------------+
> |    R1 (ISP)   |
> +-------+-------+      |
>         |              |   2001:db8::/48
>         |              |
>         |              V
> +-------+-------+
> |   R2 (Ent.)   |
> +-------+-------+
>         |              |
>         |              |   2001:db8:babe::/52
>         |              |
> +-------+-------+      V
> |   R3 (Site)   |
> +---------------+
>

I think that delegations are polled upstream and not pushed downstream.

In this case R3 would ask R2 for a delegation which in turn may need to

ask R1 for more prefixes if its pool is exhausted. The prefix pool can  
be managed with a buddy system.

Renumbering should be possible at times where DHCP PD renewals are due.

Announcements without renumbering seems to be a corner case where R1  
carries independent prefixes from a number of ISPs which should all be  
usable by the sites. For subdividing and aggregation R2 and R3 need to  
know if prefixes are part of the same "master"-prefix or not. This may  
be handled by a DHCP PD extension.

Background information: The scenario that should be handled is the  
following. R1 is controlled by one or more ISPs. R2 is in fact a number

of hops (routers) in the field so that various R3s at user sites can be

reached. It should be possible to add or remove R2s and R3s on the fly  
and they should automatically configure themselves. The network spreads

out from a central point and no meshed connections between R2s and/or  
R3s are expected.

Best regards,
-andi

-- 
| Andreas Maier               Paris-Lodron University of Salzburg   |
| ([email-masked])       Department of Scientific Computing    |
| Tel. +43/662/8044-6339      Jakob Haringerstr. 2                  |
| Fax. +43/662/8044-172       5020 Salzburg / Austria, Europe       |

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andreas Maier <[email-masked]>
Date: Thu, 17 Feb 2005 13:13:25 +0000

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.

On 02/15/05 22:50:17, Changming Liu wrote:
> same thing. To me it seems that the hybrid mode of immediate routers
> is an implementation issue. There will be no interoperability issue  
> and thus the current DHCP-PD spec should be sufficient. Is this  
> correct?
> 
> Changming
>

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 17 Feb 2005 17:02:20 -0500

Actually, I think there are implementations that support this.

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).

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.

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.

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.

This then would allow both types of operation - either relayed or where the
relay is both a client and server.

- Bernie

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Andreas Maier
> Sent: Thursday, February 17, 2005 8:13 AM
> To: dhcwg
> > In this case R3 would ask R2 for a delegation which in turn 
> may need 
> > to
> > 
> > of hops (routers) in the field so that various R3s at user 
> sites can 
> > be
> >

---

From: Andreas Maier <[email-masked]>
Date: Mon, 21 Feb 2005 16:43:36 +0000

Dear Bernie,

please find comments in-lined.

> 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.
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.

> 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.

> 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.

Thank you for your input. Best regards,
-andi

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 23 Feb 2005 08:21:17 -0500

Hi:

More comments in-lined.

- Bernie

> Sent: Monday, February 21, 2005 11:44 AM
> To: [email-masked]
> 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.
> 
> 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

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.

> 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.

> Can the upstream path be automatically detected or need it be 
> assigned manually to an interface?
> 
> 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!

> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Andreas Maier
> > > Unfortunately no such implementation seems to exist so I can not 
> > > test it immediately.
> > >
> > > -) Is it useful to standardize the operation of the hybrid mode 
> > > DHCPv6 server?
> > >
> > > hierarchical network is valid. Thanks for conforming that 
> it should 
> > > be possible to implement it on top of the existing DHCP-PD without
> > > much appreciated would be pointers to research performed 
> in the same 
> > > or a similar area.
> > >
> > > PS: Security is also a major concern but I would like to 
> deal with 
> > > it later.
> > >