IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Sat, 01 June 2013 02:21 UTC

Return-Path: <Ted.Lemon@nominum.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 6A5E121F88AC for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 19:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 HeQsQYU5m3SS for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 19:21:13 -0700 (PDT)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 861F721F883B for <v6ops@ietf.org>; Fri, 31 May 2013 19:21:13 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUalalF1f7XHMgA5XVKWI1IO/YTLu55D7@postini.com; Fri, 31 May 2013 19:21:13 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4364C1B81D0 for <v6ops@ietf.org>; Fri, 31 May 2013 19:21:08 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3B328190052; Fri, 31 May 2013 19:21:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 31 May 2013 19:21:08 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Owen DeLong <owen@delong.com>
Thread-Topic: [v6ops] A good example of why we need to careful about ULAs
Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAdoBgIAABWYA
Date: Sat, 01 Jun 2013 02:21:06 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.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>
In-Reply-To: <BCEC2341-CF91-4184-B14A-FE0BE683F89F@delong.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28F6ACB2FD452A4BA86F08A38C9B387D@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 02:21:20 -0000

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.

v2.23.0 | Report a Bug | By Email