Re: [v6ops] A good example of why we need to careful about ULAs

Jeroen Massar <jeroen@massar.ch> Sat, 01 June 2013 04:50 UTC

Return-Path: <jeroen@massar.ch>
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 46E3121F86F4 for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 21:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 5Prl7CaPSmCi for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 21:50:44 -0700 (PDT)
Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 184DE21F8657 for <v6ops@ietf.org>; Fri, 31 May 2013 21:50:42 -0700 (PDT)
Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 37381801C2BA; Sat, 1 Jun 2013 06:50:37 +0200 (CEST)
Message-ID: <51A97D9D.5010003@massar.ch>
Date: Fri, 31 May 2013 21:50:37 -0700
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Owen DeLong <owen@delong.com>
References: <CAKD1Yr29kf1Me=6JR66Gq0dFYgQx2wq=pjW8WZyHByPA0POsMQ@mail.gmail.com> <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <BCEC2341-CF91-4184-B14A-FE0BE683F89F@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> <51A97918.9070404@massar.ch> <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com>
In-Reply-To: <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" <draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org>
Subject: Re: [v6ops] A good example of why we need to careful about ULAs
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: Sat, 01 Jun 2013 04:50:58 -0000

On 2013-05-31 21:33, Owen DeLong wrote:
> 
> On May 31, 2013, at 9:31 PM, Jeroen Massar <jeroen@massar.ch> wrote:
> 
>> On 2013-05-31 21:07, Brian E Carpenter wrote: [..]
>>> Agreed. But when it does get through, it does no particular harm
>>> (you just see a bizarre hop in the traceroute). If it got through
>>> in a SYN/ACK exchange, it would probably distress a user.
>> 
>> If such a packet gets through it means BCP38 is not applied as
>> things are not properly filtered.
>> 
> 
> This has nothing to do with BCP38.

I would say it has everything to do with it actually ;)

Especially as it covers checking ALL traffic being forwarded and doing a
simple source check on them.

> Any router which forwards a packet containing a link local address in
> the header is broken regardless of any BCP38 configuration.

And BCP38 (Section 3, please read it, it is really informative ;) is
inclusive of those requirements. Of course do also take into account
BCP84 which details things a lot more.

Note that you have a fe80::/10 on every single interface, thus receiving
such packets from another box and trying to forward it to another
interface is just not right as it would fail uRPF do it being present on
multiple interfaces.

Greets,
 Jeroen