Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

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

Ted,

> First of all, I apologize for having taken so long to look at this draft.   The working group is doing quite a bit of work, and it's hard to stay on top of it all.
> 
> I just gave the draft a thorough read, and I have come away with it not knowing how I would write a shepherd doc for the draft, because I don't really understand what it's supposed to do.   The motivation for the draft is to be able to get a DHCP packet up through a tunnel to a DHCP server on the far end of the tunnel.   The solution is to use a relay agent to get the packet through the tunnel.
> 
> But how does this work?   The relay agent is co-located with the client, right?   So the client sends a DHCP packet, and the relay agent receives it, and then it relays it up the tunnel, right?   But on what interface does the client send the packet?   On what interface does the relay agent listen?

this is quite similar to how http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-05 works (I think).

> If the answer is that the client sends the packet on the tunnel interface, you haven't solved the stated problem, because you still are out of spec with respect to RFC3315: you still don't have a link-local address to use as a source address.   If the answer is that the client sends the packet on some other interface, that has several problems.

a global source address is used by the relay.
or are you thinking of the link-address field in the relay message?

> The first problem is that now the relay agent has to listen on the interface the client will transmit on.   But that interface is a configurable interface in its own right.  How do we distinguish between DHCP packets intended to configure that interface, and DHCP packets intended to go up the tunnel?

the use of a relay message is purely to get around the 3315 restriction of using a link-local address.
the client is local to the node. assume for arguments sake that in the implementation the client is acting also as the relay.

> Second, how does the relay avoid relaying packets from _other_ hosts?

it isn't a relay, it is a client using the relay message. we should make this clearer I think.

> 
> Third, how does the DHCP server know what configuration information to send?
> 
> I think it's quite possible that I have simply failed to understand what this draft is trying to do, and that if I did understand, all of these questions would be satisfactorily answered.   But the point of writing a draft is to allow a new reader to understand the proposed solution to the problem; since I haven't been able to accurately glean that answer from the draft as written, I think the draft needs more work.
> 
> As for the question of consensus, Bernie Volz also raised some questions about the draft which Leaf tried to answer, but as far as I can tell did not actually answer.   Although we do seem to have a consensus to advance the draft, without answering Bernie's questions and mine, we aren't actually ready to advance yet.
> 
> So I would appreciate it if the authors and the people who said they wanted the draft to advance, and whom I assume therefore carefully reviewed the draft, would make an effort to fix the draft so that it's possible for a naive reader like me to understand what it says to do.

cheers,
Ole