2011-01-24

DHCPv6 over PPP

Why why why why why????

OK, making progress on this - apart from working with some guy in China to try and beat up the WG on this and get PPP parameters anyway, I am trying to sort the coding for DHCPv6 on our LNS.

For a start it is a new protocol I did not have, which is a pain. PPP would have been easy. I have decided not to go down the DHCPv6 relay route as it is as complex to do, and adds a dependency on another box, plus delays things. We have enough data from RADIUS to reply directly. Of course we don't see DHCPv6 until PPP is complete and all that information has been thrown away, but I am sure I can cope somehow.

For a start I have had to bodge it around the source filters on the PPP side because it would not allow traffic from an FE80:: link local for good reason. Done that!

Then I had to get rid of sanity checks that confirmed DHCP was from an Ethernet interface as well as somehow pass the PPP endpoint details via the UDP stack to the DHCPv6 handler. Something one should not have to do between protocol layers. Done that!

I finally have the DHCPv6 server seeing the packet and with enough information to proceed.

Next step is it talking to the L2TP system (another bodge) to get the data needed to reply, and then to send the reply to L2TP (as normal routing will not work as it is link local IP). That is tomorrow's job.

Then we have to do all the same bodges in reverse for the CPE end on the FB2700 I expect.

Arrrrg!

However, good news is we have two DSL routers on the bench that are trying DHCPv6 on the WAN PPP. They don't seem to DHCPv6 or SLAAC on the LAN when statically configured, which is probably a bug, so fingers crossed that once we have the WAN side sorted they will.

No comments:

Post a Comment

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Deliveries from China

I have PCBs made in China (well Hong Kong). This is all my many small PCB projects (not FireBrick). I would rather use UK suppliers but I am...