However, we now need cheap consumer routers that just work without any complex setup. The last thing we need is people having to type in IPv6 addresses in to anything!
Well, this is where we are. We have router manufacturers starting to make routers and asking us for what we need. We make an LNS (FB6000) for the ISP end and PPPoE router (FB2700) for end user end. At the moment we are like everyone else, expecting a static config on the FB2700, though we do make it a lot easier than most :-).
The trick is a way to tell the router a few key details :-
- Router link IPv6 address so it can talk to the internet (i.e. a proper IPv6) for things like setting clock, updating s/w, etc. This could use the LAN address though.
- IPv6 DNS server addresses so not having to rely on IPv4
- Prefix to announce on the LAN so equipment connected knows DNS and router and IPs
This is basically the information that was supplied using PPP for IPv4. On the LAN DHCP was typically used, and a prefix was not delegated but NAT used (ug!). So the obvious choice is to use PPP to provide these IPv6 details. IP6CP is already a PPP protocol and already used to define one parameter (interface 64 bit address). It could easily have more parameters.
However, there seems to be some suggestion of using DHCPv6 for this. I am at a loss why. Some suggestions of avoiding more than one protocol, but it is a pain for router manufacturers and LNS manufacturers to use so who is behind this?
- LNS already has IPv6 details by RADIUS as it needs these for routing and source filtering
- LNS already has PPP and knows how to handle and route PPP
- LNS already has IP6CP to negotiate interface address
- Adding extra IP6CP parameters is an easy change at LNS or router
- DHCPv6 means LNS has to accept FE80:: link local that it would normally drop/filter
- DHCPv6 on LNS has to pass these to IP/UDP layer but has to include interface details to identify source (not normally needed at UDP layer)
- DHCPv6 on LNS has to be able to reply to specific PPP link (not usually needed for UDP)
- DHCPv6 on LNS either needs this totally new DHCPv6 protocol, or, just as complex, a DHCPv6 relay
- DHCPv6 relay means DHCPv6 server needs IP allocation details as well as RADIUS does and they need to be in sync
- Router already has PPP and IP6CP and adding more parameters is easy
- DHCPv6 on router would need whole new DHCPv6 protocol adding
Anyone know CISCOs view on this? What will be in their LNSs?
Update: Thanks to Simon for tracking this down. Seems I am not alone...
These proposals cover the problem quite well and make specific proposals.
http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-requirements-00
http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-00
Don't know anything much about LNS config, but does this thread help throw any light on what Cisco think/do?
ReplyDelete"Because IETF decided to not include global IP negotiation in IP6CP in PPP."
ReplyDeleteMay be a clue to views on it.
At the end of the day the equipment vendors decide what they put in their code, and if they do not agree with the IETF then tough.
AFAIK we can all raise an RFC and support it. If there is any backing from CISCO I will be very keen to push for the PPP route in IP6CP rather than DHCPv6.
Interestingly, the more you argue about this I'm starting to become convinced that DHCPv6 is the right way to do it. :-)
ReplyDeleteYour arguments are based on an unstated assumption: broadband access is always provided using a PPP model. Under this assumption, IPv6CP is indeed the obvious way to provide configuration information.
However, this assumption isn't true in the general case, since there are a number of counter examples (that use DHCP instead): cable networks, DSL using an IPOE model. (Ethernet based FTTP will probably most commonly fall into this group too, although PPPoE could be used).
So, let's consider the position of a CPE vendor. They make DSL products (that handle PPPoA, PPPoE and IPOE) and 'cable modem routers' (i.e. with an Ethernet 'WAN' interface). Ideally they'd like commonality across the range. DHCPv6 works in all the scenarios they handle, IPv6CP only applies to two of them. At which point the choice would tend to point to DHCPv6 as the more obvious approach. (You could also factor in the issue that the non-PPP models are using DHCP already for IPv4.)
Indeed the DSL CPE that you want is still going to have to support DHCPv6 for IPOE. So, PPP is much more of a special case, and requires some logic of the form "if we've already got config via IPv6CP, then don't do DHCPv6".
There is also an argument from the standards maintenance perspective: if you add it to PPP you've got two protocols to maintain. Inevitably you are likely to find that some options get added to the specifications for DHCPv6 but not IPv6CP, and vice versa.
If you're a vendor of an LNS for a PPP-based broadband access service, then the right approach is obvious. However, from a more general perspective I think there are definitely arguments in favour of DHCPv6 (and against IPv6CP).
Of course, you're free to write an Internet Draft - though I can't see much point in repeating draft-hu-... Assigning IPv6CP codepoints requires IETF Review so it would need to be submitted as an RFC through a working group (i.e. pppext) or via the AD sponsored route (though I can't see them wanting to do that since an appropriate WG exists).
I'm sure there was something else I was going to add, but it has currently escaped from my brain...
Well, interesting. I am indeed addressing the PPP broadband which is pretty much the case for most of UK. There are plenty of cases for DHCPv6 I am sure.
ReplyDeleteBut there is already PPP. Adding DHCPv6 is a new protocol and a problem at least for one end - the LNS - where the PPP connection goes. Yes, for cases with no LNS that are Ethernet and DHCPv6 this is not relevant.
So the end user kit probably needs to cater for Ethernet (DHCPv6) and PPP (using PPP FFS not DHCPv6).
Personally I would love it if RADIUS, DHCP, DHCPv6, and PPP all used the same tags for settings or at least a block of settings, so that things can map them transparently. Sadly too late to do that.
I am glad someone else is at least pushing an RFC for PPP for this. I am not saying that DHCPv6 should not be used where sensible. I am just saying that on a PPP link, PPP protocols make sense.
Oh, and "assigning codepoints needs IETF review" - no! It can be done by vendors. I can, as a vendor, make kit using code points I made up. There is not *need* for IETF review for that.
ReplyDeleteIt is better for everyone if we can agree the code points and work to the same standard though.
By "assigning codepoints" I was talking about the standards process (i.e. getting it assigned by IANA and recorded in the appropriate registry), since you mentioned writing an RFC.
ReplyDeleteOf course, there are no number police - so no one can stop you from doing something different. Though that would allow people to describe you using terms that I normally expect to hear you using in a pejorative sense: "proprietary", "vendor specific", etc. ;-)
LOL, fair enough.
ReplyDeleteAnyway, regardless of DHCPv6 deployment, we want to see PPP IP6CP. If that is instead or as-well, I don't mind.
Well we're talking DSL here - cable isn't relevant as at least in the UK the virgin network uses entirely proprietary kit that you can't replace.
ReplyDeleteA DSL modem has 2 modes (discounting bridge as it bypasses all the inbuild mechanism anyway). PPPoA/oE and IPoA - and IPoA is only used by one provider in the UK (and they may be moving away from it). FTTC is PPPoE based and very likely FTTP will be too.
In the PPPoA/oE case they already support ppp - adding extensions to ipv6cp is trivial. In the IPoA case there is no PPP and it's either fixed IP or DHCP already. No detection required.. it's either one or the other.
There doesn't appear to be a convincing argument for doing *both* ppp and dhcpv6.. they perform similar tasks, and the level of extra complexity in doing both seems to be unwarranted. There are those arguing for doing RA across the PPP link as well.. that's really nuts as then you've got 3 protocols with overlapping functions just to bring a link up.
Nobody's arguing dhcpv6 should go away (well, some are, but not in this case) - merely that it's a poor fit for this use case.