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 11:08 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 6BC9821F8746 for <v6ops@ietfa.amsl.com>; Sat, 1 Jun 2013 04:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vaa0GcqEF00M for <v6ops@ietfa.amsl.com>; Sat, 1 Jun 2013 04:08:24 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 07B8321F8763 for <v6ops@ietf.org>; Sat, 1 Jun 2013 04:07:02 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUanV1kU5VlmPulOMQh5gzqB5P2ROXH7l@postini.com; Sat, 01 Jun 2013 04:07:03 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 8EE941B81D4 for <v6ops@ietf.org>; Sat, 1 Jun 2013 04:07:02 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 85F91190052; Sat, 1 Jun 2013 04:07:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 04:07:02 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] A good example of why we need to careful about ULAs
Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAAZAgIAARGOAgAGlBACAAIKugA==
Date: Sat, 01 Jun 2013 11:07:01 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C02D0@mbx-01.win.nominum.com>
References: <CAKD1Yr29kf1Me=6JR66Gq0dFYgQx2wq=pjW8WZyHByPA0POsMQ@mail.gmail.com> <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <51A7CDA9.4090304@massar.ch> <8D23D4052ABE7A4490E77B1A012B6307751BDDBD@mbx-01.win.nominum.com> <CAKD1Yr1L6OPw4oF6JeDsQpo-iWbrJDh26hMcSohocPYZvVD-Mw@mail.gmail.com>
In-Reply-To: <CAKD1Yr1L6OPw4oF6JeDsQpo-iWbrJDh26hMcSohocPYZvVD-Mw@mail.gmail.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: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C02D0mbx01winnominum_"
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 11:08:31 -0000

On May 31, 2013, at 11:19 PM, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:
Just number your internal network using ULAs and no global addresses, and then run a traceroute across it.   Global addresses on the source end, global addresses on the destination end, ULAs in the middle.   The only way to "fix" this is to break traceroute.   This does not represent brokenness.

RFC 4193 section 4.3 disagrees with you. It says that border routers should drop those packets and send back ICMP unreachables.

To be clear, I'm not saying that a network that uses ULAs for transit routers and that returns those ULAs as source addresses in TTL exceeded packets is following 4193, or even that its behavior is correct.   What I am saying is that if the border routers behave correctly, they break traceroute across such a network.   So there's an incentive not to filter the ULA at the border router.   But likely the reason people are seeing these is simply that there's no egress filtering for the ULA on the border router due to inaction, rather than due to deliberate action.

v2.23.0 | Report a Bug | By Email