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

[Ole Trøan <[e-mail]>]

Tomek,

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

this doesn't mean a separate binding for the relay set of options?

the alternatives as I see it are:
 - use whatever other management / configuration protocol used to manage the relay
 - use a separate DHC session for the relay. noting that DHC isn't the protocol
   normally used to manage PE routers.

there are lots of other hammers in the toolbox, so we don't need to use the DHC hammer for every problem we have...

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

right, I think that is broken.

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

ah, I see. I must have missed that in the text. I see there is a MAY in 3315.

cheers,
Ole