Well, we have clearly made an impression.
I think we now have around 3 different DSL router manufacturers finally getting some clue and ask *us* to test their latest IPv6 offerings.
Most seem to be going for new kit to do it, and typically starting with the more up-market WiFi models rather than entry level single port Ethernet models.
My staff have a directive to test everything they can - we are after a cheap, (give-away price), single port DSL router with a good DSL level chipset that will do IPv6 native over PPP (as well as IPv4 non-NAT and NAT) and offer sensible fire-walling options to the end user.
We are also after really cheap modems that will with PPPoA/PPPoE bridge or PPPoE/PPPoE bridge with 1508 byte frames (1500 IP over PPP) and just work, including annex M ADSL2+.
We are happy to look at changes on the LNS end to work with such kit, but to be honest DHCPv6 looks so much the wrong protocol for the job I am tempted to try and write an RFC on this. It should be PPP for prefix delegation, IMHO.
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
I can understand some of the logic on DHCPv6: it means there is one configuration protocol running over IP that can be used on any network type, rather than repeating it for each link layer protocol.
ReplyDeleteHowever, it isn't obviously the most natural way to do it, particularly coming from an IPv4 background.
You're not the first to suggest an IPv6CP option, e.g.:
http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-00
However, it doesn't look like this approach is going anywhere, e.g. see the recent threads with ipv6cp in the subject in the pppext archives:
http://www.ietf.org/mail-archive/web/pppext/current/maillist.html
I'm reaching the view that we've spent long enough fiddling around with the specification of IPv6 (including plenty of second system syndrome), and so am tempted to just go with the flow (i.e. draft-ietf-v6ops-ipv6-cpe-router-09) on this.
It might not be the best solution. It might not be the most beautiful solution. But it is a solution.
To be honest I can't see the argument for using one protocol DHCPv6. You need RADIUS already on the LNS end which uses another protocol which already exists and the LNS has to map this to something.
ReplyDeleteThe LNS already does PPP and already does IP6CP. A few extra parameters on there is not complicated at all. However a whole new protocol on there that is not needed anywhere else is a pain.
It is not as if the LNS can sensibly pass the DHCPv6 out on to the LAN as there is no routing for the return traffic as it is not using the IPv6 addresses assigned to the line by RADIUS. Well, unless you create some incredible bodge somehow). Even withing the LNS you need some horrible routing bodge to handle DHCPv6 or any IP where the traffic is not to the assigned IP addresses, where as PPP routing already exists.
Also, I see no reason we have to decide DHCPv6 or PPP. Surely there are merits in both.
I am tempted to just get on am implement it.