More CPE

[Iljitsch van Beijnum <iljitsch@muada.com>]

Based on the discussion of the past days, I think this is a mixture of  
what we seem to agree on and some random things that I think are  
necessary and/or a good idea. Feel free to shoot down any part as  
needed.
All of this only applies to presumably unmanaged consumer and SOHO  
installations.
1. The expectation is that broadband modems will have IPv6 routing  
functionality.
2. Despite 1., we expect users to be able to add zero or more IPv6  
routers of their own.
3. Authentication of users towards ISPs is undefined at this time.

4. These routers (both with and without modem functionality) configure  
addresses and routing functionality as follows:
4a. The router listens for RAs on its WAN port. If there are RAs with  
global prefixes, the router autoconfigures global addresses as usual  
for hosts. If there are no global prefixes in the RAs then the router  
doesn't autoconfigure global addresses and borrows a global address  
from another interface when necessary for generating ICMP messages  
etc. If the advertised prefixes are (unique) site local the behavior  
is undefined; this is not recommended. If there are no RAs there is no  
native IPv6 connectivity and/or manual configuration is required.
4b. DAD is performed as specified in the relevant RFCs with the  
understanding that if the layer 2 network echoes back the router's own  
neighbor solicitation that is used for DAD the router recognizes its  
own source MAC address and doesn't take reception of this packet to  
mean the address is a duplicate. (To aid in ISP configurations where  
layer 2 multicasts must go through a central point so looping back of  
multicast packets can't be avoided.)
4c. Routers obtain an IPv6 prefix through DHCPv6 prefix delegation.  
They honor the unicast server option if they have a RA configured  
global address so that ISPs may base DHCPv6 server decisions on the  
autoconfigured address if this is desired as an alternative for  
implementing DHCPv6 snooping and option injection.
4d. If prefix delegation is unsuccessful but there are RAs with global  
prefixes on the WAN side, the router ceases native IPv6 routing and  
offers the user the option to operate in bridge mode and/or falls back  
to tunneling. Routers that can reasonably assume to operate behind  
another router (i.e., routers that don't have modem functionality) and  
routers that can firewall while operating in bridge mode MAY enter  
bridge mode automatically.
4e. Because of 2., it is recommended that routers implement DHCPv6  
prefix delegation server functionality in order to sub-delegate part  
of the prefix obtained from the ISP to routers connected on the LAN  
side. Routing of delegated prefixes must track the delegation;  
lifetimes must track those of the prefix the router itself obtained as  
a DHCPv6 PD client. It is recommended that routers sub-delegate the  
next power of two block equal to or larger than half the address space  
obtained but not in use in order to allow for the maximum possible  
daisy chaining of routers. Prefix delegation through a DHCPv6 relay is  
not recommended because the relay can't be presumed capable of  
installing the required routes.
5. Routers advertise the prefixes they have learned through DHCPv6  
prefix delegation using RAs on the LAN side using lifetimes copied  
from the DHCPv6 lifetimes. If the ISP-supplied prefix is shorter than / 
64 then, in the absense of user configuration, the router uses the  
lowest /64 from that prefix on the LAN side. (Discussion: this makes  
everything easier to guess for attackers. But using random bits here  
will lead to unnecessary address changes when the router reboots and  
makes troubleshooting more difficult.) The router tracks at least the  
two most recently delegated prefixes from the ISP, i.e., during  
renumbering events both the old and new prefix are usable for as long  
as the lifetime of the old prefix persists.
6. Routers validate the source addresses of outgoing packets.

6a. Optionally, routers track the presence of other routers on their  
LAN side and forward packets with source addresses that match the  
prefixes advertised by those routers to them. (Helps to get around  
ingress filtering by ISPs when there are multiple routers connecting  
to multiple ISPs.)
6b. Optionally, routers may obtain multiple global addresses and  
default gateways through RAs and multiple prefixes using DHCPv6 PD and  
then use both sets of information side by side in such a way that  
packets go to the next hop router / ISP matching the source address in  
packets received on the LAN side. (Very helpful for shim6-style  
multihoming.)
6c. Routers generate "invalid source address" ICMP errors for packets  
that can't be forwarded because their source address falls outside of  
the delegated prefix. (The full prefix if shorter than /64.) (More  
robust in the presence of ingress filtering.)
7. Routers support at least a small number of static routes,  
preferably such that static routes to other routers within the site  
can be set up with wildcard bits for the ISP-delegated prefix. (To  
allow having different subnets separated by different routers within a  
site.)
8. If routers have stateless DHCPv6 server capability, they MAY set  
the O bit in their router advertisements and provide DNS, domain etc  
information that they obtained along with the DHCPv6 prefix  
delegation, IPv4 DHCP or from manual configuration to hosts on the LAN  
side through stateless DHCPv6. A router that is prepared to forward  
DNS queries to IPv4 DNS servers, has 1 or more IPv4 resolver addresses  
and IPv4 connectivity SHOULD advertise its own address through  
stateless DHCPv6 if it doesn't know of any IPv6 DNS resolvers.
9. If routers don't implement DHCPv6 server capability, they SHOULD  
implement a DHCPv6 relay function and copy the O bit from RAs received  
on the WAN side in their own RAs on the LAN side.
(Discussion: having ISPs push the M bit / stateful address  
configuration is probably not appropriate. However, if the hosts  
generate stateful DHCP requests anyway, a relay is a relay...)
10. Routers SHOULD insert the IPv6 DNS resolver addresses they have  
knowledge of in an RFC 5006 RA option. A router that is prepared to  
forward DNS queries to IPv4 DNS servers, has 1 or more IPv4 resolver  
addresses and IPv4 connectivity SHOULD advertise its own address in an  
RFC 5006 RA option if it doesn't know of any IPv6 DNS resolvers.
11. Firewalling in unmanaged routers is a complex issue. Both  
firewalling and not firewalling have important downsides. See separate  
documents on firewalling best practices in this area and on how to  
open up ports in firewalls. Irrespective of that, it is highly  
recommended that vendors in this area make it as easy as possible for  
users to enable/disable firewalling, both site-wide and on a per-host  
basis. (Based on MAC address?)
(Discussion: how does a host know if it's firewalled? In IPv4 you can  
see that you have an RFC1918 address. But your IPv6 address is the  
same whether you need to bypass a firewall or not. Apparently, at  
least one vendor has decided to not publish AAAA records because of  
this issue. Do we need to push out information about the firewall  
status to hosts?)
(Discussion: is there any MIPv6 functionality that is so important  
that we should try to get CPE vendors to implement it?)