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

[Tomek Mrugalski <[e-mail]>]

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