DHCP over PPP - or how to use sockets instead of BPF?

[Patrik Lahti]

On 15/04/10 05:59 PM, David W. Hankins wrote:
> On Thu, Apr 15, 2010 at 02:51:17PM -0400, Patrik Lahti wrote:
>    
>> PS. I know IPCP provides IPv4 addresses and link-local IPv6 addresses, but
>> DHCP over PPP is useful to get other configuration (such as name servers)
>> as well as IPv6 (global/UL scope) address configuration.
>>      
> This is basically a known design limit.  We've been trying to gear up
> for a rework of the common interface discovery/socket-management code,
> but haven't made enough momentum for escape velocity yet.
>    

Thanks David,

That's very understandable, gravity and all, I know how it is :-)

Wrt rework, the patch to change to socket use, which Steinar Haug 
suggested on this thread, is a start. Together with a simple change to 
get_hw_addr() to recognize IFT_PPP, I got a successful basic DHCPv6 
SOLICIT/ADV/REQ/REPL exchange over PPP. I had to require the DUIDs be 
pre-configured. However, I noted the IAID was zero, and realized it's 
based on hw_address too... More about this below...


> Essentially we only want to permit ppp interfaces for DHCPv6 since
> DHCPv4 isn't specified for ppp links.
>    
Aha, I see. For this reason my main interest would be DHCPv6 too.

But it would be nice to allow DHCPv4 to "work" somehow. Otherwise, how 
do people automatically get DNS servers on PPP links? I remember 
statically configuring name servers back in the modem days but we're 
trying to make things "just work" when you plug them in these days right :-)

Is there any implementation which supports DHCPv4/PPP (in a non-standard 
way) out there? Is there a "de facto" way of doing it?

> One of the thorny parts of this move is that we do still need to fetch
> data from _some_ physical interface, like ethernet or etc, in order to
> draw a MAC address to create an initial DUID.
>
>    

Yes, I investigated the use of struct interface_info.hw_address in the 
code, and saw the issue with DUID and also IAID.

a) DUID LL and LLT is required by standards, and in practice one could 
automagically try to create it by scanning for Ethernet interfaces on 
the box in order to create them, and fail with an error message if that 
wasn't possible.

b) Alternatively, and much more simple, would be to require that DUID 
manually configured through dhcp-client-id and server-duid (or already 
be present inside the lease file upon startup - this is what I did in my 
experiments).

c) DUID Enterprise would always need to be manually configured, right?

The hw_address is also used for:
1) IAID, but as I understand this it is an implementation choice and 
maybe another scheme which still meets the RFC uniqueness requirement 
could be used for PPP interfaces?
2) Random seed
3) CHADDR in DHCPv4, maybe the only way to solve this is to write an 
IETF draft and go through the whole procedure, unless there's an 
interoperable way to do this "out there"...
4) Tracing code.... not sure what this is about yet...

IMHO, what's left to do is a) make the code use sockets for PPP 
interfaces, and still use BPF for other interfaces, rather than a crude 
compile directive to make all interfaces use sockets, and b) try to 
generate "something" into hw_address to make the rest which depend on it 
fly, alternatively make the rest fly without hw_address but I don't 
think I'd want to go there...

Do you think that would take care of it?

Do you know of any other problems beside the ones related to hw_address 
usage?

Regards,
/P