PATCH DHCPv6/PPP [Was: DHCP over PPP - or how to use sockets instead of BPF?]

[Patrik Lahti]

Hi,

I would like to share with you the attached patch which enables DHCPv6 
over PPP interfaces in 4.1.1 release with the hope that we can work 
together to add support for this in future releases.

Brief description of changes:
  - try other interfaces when forming DUID automatically, if it fails 
then exit requiring the user to configure it.
  - Accept PPP interfaces in get_hw_addr() making it a zero length 
HTYPE_RESERVED address.
  - safety checks for hlen == 0 when generating random seed.
  - IAIDs for PPP interfaces become sequential numbers rather than based 
upon MAC address.
  - Limited to BPF and LPF, only because that's the only thing I could 
test at the moment.

Please let me know your feedback.

Cheers!
/P


On 16/04/10 01:19 PM, Patrik Lahti wrote:
> 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
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: isc-dhcp-4.1.1-ppp.diff
Type: text/x-diff
Size: 5845 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100426/9deb431f/attachment.bin>