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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 01 June 2013 04:07 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 D185721F8904 for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 21:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JYYluiEJ3iwO for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 21:07:10 -0700 (PDT)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6756821F888F for <v6ops@ietf.org>; Fri, 31 May 2013 21:07:10 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id wy17so3148812pbc.23 for <v6ops@ietf.org>; Fri, 31 May 2013 21:07:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DFrzJiMgXe1UOifA2wU6dPnH//7RxRuhtZ1PY7WD7So=; b=GavdpD3X6ZICX8IjTEjpR6Q2XO/INLFipIWk2/FNdXGjCBiM/HVft5+byIgVrwCRin GzYN9kO9gxtG5g+hWQqp5GI7gY2lqcm39jKuyD7L90Cru0htUkOpBdEgCLqE8VFl7yXL 4lhXEkVegO4Bk2cTBA42SrPxuy9J7A9n0KmTTlnOodhNqoKLD7vGG5oRouoV5O4TjUqi vJolJjtZlisJBPFj0B5AMkrAIsRUzi8eY6wUVSpGJLb7QuSL+BrTBB2FGW+nuHm9vW1x 3NtufWeKBU2YpASJ3SgiPQq32dQxGuShVmYC0iOlNVa69b5FhT5WIpbMvvVfn2eDAUg2 Wa7w==
X-Received: by 10.66.232.69 with SMTP id tm5mr16387880pac.120.1370059629632; Fri, 31 May 2013 21:07:09 -0700 (PDT)
Received: from [192.168.1.2] (224.171.252.27.dyn.cust.vf.net.nz. [27.252.171.224]) by mx.google.com with ESMTPSA id pl9sm31074253pbc.5.2013.05.31.21.07.05 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 21:07:08 -0700 (PDT)
Message-ID: <51A97375.1090402@gmail.com>
Date: Sat, 01 Jun 2013 16:07:17 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
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>
In-Reply-To: <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com>
Content-Type: text/plain; charset="UTF-8"
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:07:10 -0000

On 01/06/2013 14:44, Owen DeLong wrote:
> On May 31, 2013, at 7:21 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
> 
>> On May 31, 2013, at 10:01 PM, Owen DeLong <owen@delong.com> wrote:
>>> How is having them leak in attempted TCP connections worse than having them leak in ICMP headers? It's still an invalid header.
>> The ttl exceeded return packet doesn't expect a return packet of its own, so the fact that there's a "bogus" IP address on the header causes no harm, despite being technically wrong.   Filtering the packet based on the source address, on the other hand, would cause harm.   Nobody ever said life was going to be simple.
> 
> The TTL Exceeded packet shouldn't get forwarded by any router as a result of the LL Source address.
> 
> Thus it should never reach its destination.

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.

> 
> Thus it will break traceroutes.
> 
> Thus it is harmful.

I'm not defending bad practice; just observing that it doesn't
cause a disaster in traceroute.

    Brian