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

More CPE



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?)