IETF Logo Mail Archive

Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

Ronald Bonica <rbonica@juniper.net> Thu, 31 May 2012 13:54 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4758221F8658 for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 06:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.137
X-Spam-Level:
X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp8+JObZxGxX for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 06:54:09 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3C21F84BF for <v6ops@ietf.org>; Thu, 31 May 2012 06:54:05 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT8d3/NMnMgWer7tee96VZg0qNfHd4xBF@postini.com; Thu, 31 May 2012 06:54:09 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 May 2012 06:53:33 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 31 May 2012 09:53:32 -0400
From: Ronald Bonica <rbonica@juniper.net>
To: Fernando Gont <fgont@si6networks.com>, RJ Atkinson <rja.lists@gmail.com>
Date: Thu, 31 May 2012 09:53:31 -0400
Thread-Topic: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
Thread-Index: Ac0+urf3eurbOELfRiCIageJy4wFRAAdwA8Q
Message-ID: <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net>
References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com>
In-Reply-To: <4FC6AAD4.4090108@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2012 13:54:10 -0000

Fernando,

The problem that we are wrestling with isn't specific to RA Guard. The kind of fragmentation that we are discussing will cause problems for firewalls, in general. Therefore, we might want to request the following from 6man:

1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6 header, all extension headers, the ICMPv6 type, code, and checksum are included in the first fragment

2) Hosts MUST NOT send fragmented packets carrying any next-layer protocol unless the IPv6 header, all extension headers, the entire next-layer protocol header are included in the first fragment. TCP and UDP are examples of next-layer protocols.

                                             Ron
                                             <speaking as individual contributor>


> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Fernando Gont
> Sent: Wednesday, May 30, 2012 7:19 PM
> To: RJ Atkinson
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-
> implementation-04.txt> (Implementation Advice for IPv6 Router
> Advertisement Guard (RA-Guard)) to Best Current Practice
> 
> On 05/30/2012 05:59 PM, RJ Atkinson wrote:
> >
> > A better approach for the RA Guard document would be:
> >
> > 1) to put together a separate I-D for 6MAN that says approximately
> >    the above (and explains why).  There is probably a little text
> >    clarifying that any host receiving an RA that did not comply with
> >    the proposed new rule above MUST be dropped by that receiving
> host.
> 
> FWIW, something like that has already been published and presented at
> the last IETF:
> 
> * <http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-
> 02.txt>
> 
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email