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