Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

["JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[e-mail]>]

Tomek,

Since the goal of the solution is to transfer a prefix table from dhcp server to the relay why not use DHCP inform with options,or a separate message to get this information(draft-joshi-dhc-dhcpv6-aggr-route-opt)  ? 

This would not have the overhead per transaction and also the handling at the relay would be much elegant and simpler.
Current draft requires relay to implement bulk lease query and additional processing per relayed PD request.

As such the prefix routes are not supposed to change frequently and would in any case require additional routing policy and routing protocol configuration which would be done external to DHCP.

So is this additional complexity & piggy backing at relay per dhcp PD exchange really required or should alternatives be considered /

--
Shree



>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Tomek Mrugalski
>Sent: Monday, September 03, 2012 8:19 PM
>To: [e-mail]
>Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
>
>On 03.09.2012 10:03, Ole Trøan wrote:
>>> [...]
>>> If you think this work should be adopted by the working
>>> group, please reply to this message saying so.   If you think this
>>> work should not be adopted by the working group, please reply to
>>> this message saying so.   We will evaluate consensus on September
>>> 7.
>>
>> I'm generally uncomfortable with piggybacking on the client
>> initiated protocol, to manage a DHCPv6 relay sitting in the middle of
>> the conversation.
>Piggybacking is not very elegant, but the alternatives are worse. If you
>chose not to piggyback, you would have to use some form (something like)
>leasequery + active pushback from the server to notify relays that
>something has changed. Such a protocol would add new message types, new
>connections, perhaps even new state in the server. What is such
>hypothetical prefix-pool-queries came from outside your network (or any
>unathorized source)? So new attack vectors would have to be considered
>and possible protected against.
>
>With prefix pool option in RELAY_REPL that contains PD REPLY, your
>server already decided that is ok to respond. No extra connections, no
>extra message types, no new state. So in my opinion piggybacking is not
>the most elegant solution, but the alternatives are much worse.
>
>One thing that should probably improved is handing of the case when
>server policy changes. Right now the draft says to trigger reconfigure
>and force a client to start reconfigure process. The client won't get
>any new or changed configuration. Also, there may be a network does not
>have any client that supports reconfigure (which is optional). So in my
>opinion that part of the draft requires some extra work. Does it mean
>that we should throw away the whole concept? In my opinion - definitely not.
>
>> I do not think it is a good idea to require DHCPv6 relays to rewrite
>> DHCPv6 client messages.
>Nobody suggested such a thing. Relays would consume some options put in
>RELAY-REPL. The decapsulation process would work as it is now - take
>contents of RELAY-MSG option and send it downlink (be it the next relay
>or the client - it doesn't matter).
>
>> does this work with DHCPv6 authentication?
>It doesn't affect it at all. Servers that auhenticate their responses
>are signing REPLY message that is in turn encapsulated in RELAY-REPL.
>THe prefix-pool option is insterted in RELAY-REPL and the REPLY inside
>is never modified. prefix-pool never reaches the client. If that is was
>your impression after reading the draft, perhaps it should be clarified
>in the text?
>
>Tomek
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg