IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Fri, 31 May 2013 02:12 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 5CAD421F901A for <v6ops@ietfa.amsl.com>; Thu, 30 May 2013 19:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.558
X-Spam-Level:
X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 J-NRjl7iFuO7 for <v6ops@ietfa.amsl.com>; Thu, 30 May 2013 19:12:26 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id AB1B721F8E9D for <v6ops@ietf.org>; Thu, 30 May 2013 19:12:26 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUagHCYzHk05OMIYxjhdPdOcgKEFCT7sW@postini.com; Thu, 30 May 2013 19:12:26 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 457461B81C5 for <v6ops@ietf.org>; Thu, 30 May 2013 19:12:25 -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 365CB190052; Thu, 30 May 2013 19:12:25 -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; Thu, 30 May 2013 19:12:25 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Jeroen Massar <jeroen@massar.ch>
Thread-Topic: [v6ops] A good example of why we need to careful about ULAs
Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAAZAgIAARGOA
Date: Fri, 31 May 2013 02:12:24 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BDDBD@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>
In-Reply-To: <51A7CDA9.4090304@massar.ch>
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="Windows-1252"
Content-ID: <55D743264804C844A16E5DD7181FDB46@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: Fri, 31 May 2013 02:12:37 -0000

On May 30, 2013, at 6:07 PM, Jeroen Massar <jeroen@massar.ch> wrote:
> If you know how to replicate it, I am very interested in a packet dump
> or what is involved to cause it.

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.   Of course, it's just shy of brokenness—if the devices that are answering the ICMP messages in the core of the network are using ULAs for that, they would also use ULAs if they tried to *connect* to hosts outside of the core of the network.   But they are infrastructure devices—routers—so in practice they don't do this, and it isn't a problem.

v2.23.0 | Report a Bug | By Email