"Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", James Woodyatt, 27-Jul-09. ( bytes)

This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.

"IPv6 RA-Guard", Eric Levy-Abegnoli, Gunter Van de Velde, Chip Popoviciu, Janos Mohacsi, 28-May-09. ( bytes)

It is particularly easy to experience "rogue" routers on an unsecured link [reference4]. Devices acting as a rougue router may send illegitimate RAs. Section 6 of SeND [RFC3971] provides a full solution to this problem, by enabling routers certification. This solution does, however, require all nodes on an L2 network segment to support SeND, as well as it carries some deployment challenges. End- nodes must be provisioned with certificate anchors. The solution works better when end-nodes have access to a Certificate Revocation List server, and to a Network Time Protocol server, both typically off-link, which brings some bootstrap issues. When using IPv6 within a single L2 network segment it is possible and sometimes desirable to enable layer 2 devices to drop rogue RAs before they reach end-nodes. In order to distinguish valid from rogue RAs, the L2 devices can use a spectrum of criterias, from a static scheme that blocks RAs received on un-trusted ports, or from un-trusted sources, to a more dynamic scheme that uses SeND to challenge RA sources. This document reviews various techniques applicable on the L2 devices to reduce the threat of rogue RAs.

"IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 25-Mar-09. ( bytes)

This document recommends IPv6 behavior for Customer Premises Equipment (CPE) routers in Internet-enabled homes and small offices. The CPE Router may be a standalone device. The CPE Router may also be embedded in a device such as a cable modem, DSL modem, cellular phone, etc. This document describes the router portion of such a device. The purpose behind this document is to provide minimal functionality for interoperability and create consistency in the customer experience and satisfy customer expectations for the device. Further, the document also provide some guidance for implementers to expedite availability of IPv6 CPE router products in the marketplace. It is expected that standards bodies other than the IETF developing standards for specific products in this area (e.g. CableLabs eRouter, Broadband Forum, Home Gateway Initiative, etc.) may reference this work for basic functionality and provide value-added or linktype-specific customizations and enhancements which are beyond the scope of this document.

"Rogue IPv6 Router Advertisement Problem Statement", Tim Chown, Stig Venaas, 27-May-09. ( bytes)

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the Router Advertisement (RA) message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this draft we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.

"IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano, 3-Jul-09. ( bytes)

This document provides a guide for IPv6 deployment in Internet Exchange Points (IXP). It includes information about the switch fabric configuration, the addressing plan options and general organizational tasks to be performed. IXP are mainly a layer 2 device and in many case the best recommendations state that the IPv6 data, control and management plane should not be handled differently than in IPv4.

Return to Internet-Draft directory.

Return to IETF home page.