Tweaking how we handle IPv6CP

Looks like we have to tweak the normal PPP negotiation we do on the LNS. I plan to install the new code this weekend.

The reason is not flaky implementation of IPv6 on routers (and that is pretty flaky), it is flaky PPP on older routers.

PPP is pretty good in that there is a message to report back to the other end to say when you don't understand something. This allows backwards compatibility.

If we ask a router to do IPv6 (using IPv6CP conf request) the router should either understand it and reply, or generate an error. Normally one would expect a protocol reject message saying it does not understand IPv6CP.

This makes PPP pretty safe and easy to handle fallback. If we get such a response we conclude the device cannot handle IPv6 and continue accordingly, allowing an IPv4 only connection to work.

However, if we don't get a reply, we retry the request. Eventually we just give up because we are getting no reply to our PPP and close the link with a negotiation failed.

Sadly we have found routers with a couple of problems. One (I forget the make) sends an incorrect protocol reject message. So it is not rejecting IPv6CP but something completely different. Naturally we don't take any notice of this, and keep trying the IPv6CP. Another (an older juniper model) simply ignores the IPv6CP and does not reject it or reply. The result is the same.


The change we are making is that we'll now give up on the IPv6CP after a number of tries and conclude that the far end does not handle IPv6, but we will continue as if we had received a protocol reject, allowing IPv4 operation.

This makes the policy of giving all customers an IPv6 allocation as standard somewhat safer!