Document Action: 'IPv6 Router Advertisement Guard' to Informational RFC

The IESG <iesg-secretary@ietf.org> Wed, 27 October 2010 23:07 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@core3.amsl.com
Delivered-To: ietf-announce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9653A63EC for <ietf-announce@core3.amsl.com>; Wed, 27 Oct 2010 16:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level:
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSXSj7M-alM1 for <ietf-announce@core3.amsl.com>; Wed, 27 Oct 2010 16:07:27 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4324A3A679F for <ietf-announce@ietf.org>; Wed, 27 Oct 2010 16:07:26 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'IPv6 Router Advertisement Guard' to Informational RFC
X-Test-IDTracker: no
Message-ID: <20101027230726.394.42552.idtracker@localhost>
Date: Wed, 27 Oct 2010 16:07:26 -0700
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 23:07:28 -0000

The IESG has approved the following document:
- 'IPv6 Router Advertisement Guard'
  <draft-ietf-v6ops-ra-guard-08.txt> as an Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard/



Technical Summary
 
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.

Working Group Summary 

Working group discussion was generally supportive.

Document Quality
 
The document is generally clear and concise. 

Personnel

Fred Baker is shepherd for this document.

RFC Editor Note

OLD TEXT:
>A device or interface in the RA-Guard "Learning" state is
>actively acquiring information about the IPv6 routing devices
>connected.

NEW TEXT:

>A device or interface in the RA-Guard "Learning" state is
>actively acquiring information about the IPv6 routing devices
>connected to its interfaces.

OLD TEXT:
> Once the L2-device has identified through "Learning" the valid
> IPv6 routers and hence also identified the valid RAs, it
> transtions each interface from "LEARNING" into either BLOCKING
> state if there was no valid IPv6 router discovered at the
> interface, or transitions the interface into FORWARDING state
> if there was a valid IPv6 router discovered.

NEW TEXT:

> When the L2-device reaches the end of the LEARNING state, it
> has a record of which interfaces are attached to links with
> valid IPv6 routers.  The L2-device transtions each interface
> from "LEARNING" into either BLOCKING state if there was no
> valid IPv6 router discovered at the interface, or transitions
> the interface into FORWARDING state if there was a valid IPv6
> router discovered.