[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-wbeebee-ipv6-cpe-router-03

I think an important question is how firm we want to be on the issue of cascading CPEs.
With IPv4, you can nest/cascade CPEs that do NAT, which makes life harder on NAT traversal protocols but otherwise works without trouble. Because with IPv6, each CPE needs a prefix for its LAN interface(s) cascading CPEs without some kind of support from the ISP and upstream CPEs isn't possible. Basically, what needs to happen is that the first CPE gets a prefix from the ISP, and then implement a DHCPv6 server that delegates smaller prefixes to downstream CPEs.
The first CPE can't simply relay the request to the ISP, because even if we can presume the ISP to be generous and give more than one prefix to a single subscriber, the first CPE needs to install this prefix in its routing table. So that would require extensive DHCP relaying logic. So the situation where the CPE acts as a DHCPv6 server makes more sense. (Note that in the case where the cascading happens, we would also want the upstream CPE to disable its firewall for addresses in the delegated prefix to avoid double firewalling.)
Now I could see how vendors (especially of cheap) CPEs may not want to implement all of this. But in the case where such a CPE is provided by a broadband ISP and has a non-ethernet WAN port, the end-user would be unable to buy a premium CPE and be stuck with whatever suboptimal features the ISP-provided CPE incorporates. This is bad for everyone. The situation where the customer can go out and buy a better CPE is good for: 

- the CPE vendors: more CPEs sold
- the ISPs: the ISP-provided CPEs don't have to be all things to all people 
- the consumers: choice
So in the case that a CPE vendor doesn't want to implement the DHCPv6 server necessary for cascading, I think we should mandate that the first CPE, when it detects that a secondary CPE is connected on the LAN side, becomes a transparent bridge. (Insert DHCPv6 option to make this happen.)
Unfortunately, this mode of operation would be incompatible with additional requirements for address assignment/registration and the use of a single, known good MAC address that broadband ISPs may impose. So I guess when those requirements are present, we're back with requiring a DHCPv6 server in the CPE.
Implementing a DHCPv6 server in the CPE rather than relaying DHCPv6 requests to the ISP also reduces the amount of DHCPv6 traffic seen by the ISPs, which could be helpful. 

Is the above something we can agree on?


Here are some more detailed comments on the draft:
You point to the IPv6 node requirements. I thought that router requirements would be more appropriate, but although there is an IPv4 router requirements document penned by our esteemed chair, there is no such document for IPv6...
mDNS - Multicast Domain Name System - see http:// www.zeroconf.org.
There's a bunch of multicast DNS related drafts floating around, maybe you can link to the most relevant one of those? 

   If stateful DHCPv6 is not used to obtain other
IPv6 configuration, then stateless DHCPv6 [RFC3736] must be initiated 
   by the WAN interface to obtain other IPv6 configuration.

must or MUST?
I don't think there is any reason to use statless DHCPv6, because the router must always do stateful DHCPv6 to obtain a prefix anyway. It would be extremely unlikely that the server wouldn't return other info such as DNS addresses statefully but then provide this information if queried again statelessly.
BTW, what happens if the prefix delegation request fails and there is no prefix? 

5.3.3.  Both Models

   At any instance in time of the CPE Router operation, the router does
   not forward any traffic between its WAN and LAN interface(s) if the
   router has not completed IPv6 provisioning process that involves the
   acquisition of a global IPv6 address by the WAN or if the WAN is
   unnumbered and there is no GUA available to source WAN packets.
A router generally doesn't source packets itself, so the presence of a WAN address doesn't really impact the router functionality... 

   This document recommends the RA sent out by LAN Interface(S) to be
   configured for SLAAC so that the prefix advertised in the RA is
   derived from the IA_PD assigned to the CPE Router by the Service
   Provider; the O-bit is also set so that the CPE Router can pass
   Domain Name Server(s) IPv6 address(es) to home devices.  The CPE
   Router obtained the Domain Name Server(s) in OPTION_DNS_SERVERS
   option from the DHCPv6 server when the CPE Router WAN interface
   completed DHCPv6.
It would be good if CPEs would also insert DNS addresses in RAs as per RFC 5006. If requiring the support of an experimental RFC is a bridge too far, at the very least say this is a good idea and point to 5006.
It would be useful to tell people to align the timers in RAs with those in the PD delegation for easier renumbering. Note that during renumbering hosts may source packets with the old addresses even though the new ones are already available. This shouldn't cause trouble, but in cases where routes or filter rules are created, multiple sets of these are necessary during transition from one prefix to another.
For the purpose of shim6 support: it would be possible for a user to get service from two different ISPs and then hook up a third CPE to the two connected to these ISPs. This third CPE would then get a subdelegated prefix from each ISP. So either this CPE should support this, and use two prefixes at the same time, and send packets with source addresses from ISP A to the CPE that gave out addresses from ISP A, and packets with B addresses to the B CPE, or it should only accept one prefix and then make sure that all packets go to the router that delegated that prefix. 

8.1.  Path MTU Discovery Support
When the WAN MTU is less than 1500 (such as in the case of PPPoE), the router should put the WAN MTU in the RA MTU option on the LAN side so the hosts use the reduced MTU and adjust their TCP MSS accordingly, reducing the likelihood of trouble because of PMTUD black holes. 

8.2.  Optional RIPng Support

Is this useful?

8.3.  Firewall

There must be a way for the user to disable the firewall if desired.
These CPEs will be dual stack but they may be connected to an IPv4- only or even IPv6-only network. (Intentionally or by mistake, maybe one protocol has failed but the other still works, we certainly don't want fait sharing here...)
In the case where IPv4 is non-functional, a router MAY still advertise private addresses, which can be used for configuration or DNS lookups (if the CPE is a DNS forwarder, useful in the case of OSes that can't do DNS over IPv6 transport (Windows XP) or have no autoconfiguration of IPv6 DNS addresses (MacOS)) but MUST NOT provide a default gateway so that the hosts know they can't send packets towards IPv4 destinations so long timeouts are avoided.
In the case of non-functional IPv6 but working IPv4, it's probably best to not let hosts autoconfigure addresses and also not have RAs create default gateways, because some OSes take the former to mean that there is working IPv6 and others the latter.
Please let me know what of the above is non-controversial and I'll submit text, if desired.