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

Jeroen Massar <jeroen@massar.ch> Thu, 30 May 2013 22:07 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 A0B4E21F9289 for <v6ops@ietfa.amsl.com>; Thu, 30 May 2013 15:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NxD8lgjLzs+o for <v6ops@ietfa.amsl.com>; Thu, 30 May 2013 15:07:47 -0700 (PDT)
Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id E91E521F86F0 for <v6ops@ietf.org>; Thu, 30 May 2013 15:07:42 -0700 (PDT)
Received: from kami.ch.unfix.org (unknown [149.20.50.237]) (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 27ECF801C2BA; Fri, 31 May 2013 00:07:37 +0200 (CEST)
Message-ID: <51A7CDA9.4090304@massar.ch>
Date: Thu, 30 May 2013 15:07: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: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <CAKD1Yr29kf1Me=6JR66Gq0dFYgQx2wq=pjW8WZyHByPA0POsMQ@mail.gmail.com> <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com>
In-Reply-To: <51A7C86B.3020808@gmail.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: Thu, 30 May 2013 22:07:53 -0000

On 2013-05-30 14:45, Brian E Carpenter wrote:
[..]
>> In the early news, not really a new problem.
>>
>> RFC1918 and 100.64/10 leak too, 
> 
> In traceroutes, link-locals sometimes leak too.

I have never come across that; except maybe when tracerouting to a
link-local, and then, that would only be one hop anyway.

If you know how to replicate it, I am very interested in a packet dump
or what is involved to cause it.

> All these are confusing and make the traceroute hard to interpret,
> but they don't actually *matter*. What matters is if they leak in
> actual traffic such as attempted TCP connections. Does that happen?

One should only see a link-local when:
 - the source packet is link-local
 - the destination host only has a link-local and replies (TTL or so)

But that should never cross more than one (1) hop as link-locals should
not be forwarded.

Greets,
 Jeroen