RE: More CPE

["Miguel A. Diaz" <miguelangel.diaz@consulintel.es>]

If both RA and DHPCPv6 are setup in the WAN port, the ISP has to
manage two prefix pools: one for the point-to-point link (RA) and the
other one for the delegated prefix (usually /48).

That can be avoided by getting one /64 for the point-to-point link
(RA) from the delegated prefix (/48) as explained at
http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-
01.txt

This approach has benefits from both operational and routing
aggregation perspectives and it may be taken into account by both ISPs
and CPEs manufacturers.


Regarding MIPv6, the most important feature that a firewalled CPE must
implement is not filtering the specific extension headers to let MIPv6
to work:

* Destination option extension header
* Type 2 routing extension header
* MIPv6 extension header messages (BU, BA, BE, etc.)

See
http://www.ist-enable.org/open/draft-thiruvengadam-nsis-mip6-fw-06.txt
for detailed explanation on this.

Otherwise the firewalled CPE should implement some signaling mechanism
to open the required pinholes in the firewall for allowing such
packets to go out/come in, for instance by using the NSIS protocol as
proposed at
http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-mip6-fw-0
8.txt


Regards
Miguel

> -----Mensaje original-----
> De: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] En nombre de Iljitsch van Beijnum
> Enviado el: jueves, 10 de enero de 2008 1:16
> Para: IPv6 Operations
> Asunto: 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?)
> 
> 




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.