I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational document is an update to the requirements for an IPv6 Customer Edge Router (i.e., a router in a residence or small office that supports IPv6). Note that most of the security requirements (e.g., packet filtering / sanitation) for such a Customer Edge Router are provided not in this document but in RFC 6092 and RFC 2827 (which are included by reference, i.e., that draft states that Customer Edge Routers SHOULD be compliant with RFCs 6092 and 2827). The most significant change between this draft and RFC 6204 (which it replaces) is that it adds a section recommending (at the SHOULD level) support for 6RD (RFC 5969) and DS-LITE (RFC 6333). Note that supporting 6RD and/or DS-LITE the CPE is causes the Customer Edge Router to perform the additional role of encapsulation/decapsulation of tunneled packets. Due to the addition of support for 6RD, and DS-LITE the security considerations adds the additional clarification that it should be possible to apply filtering (as per RFC 6092) to decapsulated packets (i.e., apply filter rules after stripping off the outer header). Other than this consideration, I cannot see any additional security issues related to adding support for 6RD and/or DS-LITE to Customer Edge Routers (excepting, of course, the general 6RD/DS-LITE security considerations in RFCs 5969 and 6333 which need not be repeated in this document). The only concern that I have is that requirement S-3 in the Security Considerations section is a "SHOULD" and not a "MUST". If I understand S-3 correctly it says "If the Customer Edge Router supports filtering as described in 6092, and if this feature is turned on, then it SHOULD be possible to apply this filtering after decapsulation (as opposed to applying filters before the outer tunnel header is removed)". I have trouble imagining why it would be a good idea to provide the packet filtering features described in RFC 6092 but only allow these firewall rules to be applied prior to decapsulation. It seems that if the user (who may not be well versed in IP tunneling) turns on some firewall/filtering service in a Customer Edge Router, that what the user probably wants is for the filtering rules to be applied to the packets "inside" the tunnel (after decapsulation) and not to packets containing the "outer" tunnel header. I would therefore recommend that S-3 be changed to a "MUST" instead of a "SHOULD". [Note: Please correct me if I misunderstood, S-3] As a concrete example, RFC 6092 (in REC-1) says that when a (Customer Premises) router receives a packet with a multicast source address, that this packet must not be forwarded. When the incoming packet is a tunneled packet, the outer IP header always has as its source address the IP address of the tunnel ingress device. Therefore, surely if this kind of filtering is turned on in a Customer Edge Router, it ought to be applied to the inner packet (after removal of the outer tunnel header). - Matt Lepinski