IETF Logo Mail Archive

Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt

Ted Lemon <ted.lemon@nominum.com> Tue, 18 February 2014 22:27 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE07B1A0470 for <v6ops@ietfa.amsl.com>; Tue, 18 Feb 2014 14:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STvLKy7Ugasj for <v6ops@ietfa.amsl.com>; Tue, 18 Feb 2014 14:27:28 -0800 (PST)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 534E81A026A for <v6ops@ietf.org>; Tue, 18 Feb 2014 14:27:28 -0800 (PST)
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 90EA71B8189 for <v6ops@ietf.org>; Tue, 18 Feb 2014 14:27:25 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 71C5E190052; Tue, 18 Feb 2014 14:27:25 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 14:27:25 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <5303CD3E.1010907@gmail.com>
Date: Tue, 18 Feb 2014 17:27:23 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <292269AF-CB65-4368-A4F3-9B4589CD5802@nominum.com>
References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <m21tz6javn.wl%randy@psg.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <BD473E46-E382-44E6-B474-A56D074318FA@delong.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <E91E49CA-7BA6-4DA3-B4F3-46BB0F25F8F1@delong.com> <5303CD3E.1010907@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kFwUMGCEhkjbXuVdBlZeoiHIq7Q
Cc: V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 18 Feb 2014 22:27:29 -0000

On Feb 18, 2014, at 4:14 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> But ULAs aren't bogons. They aren't supposed to be routed, but
> if some people break that rule, is a ULA prefix objectively any
> more harmful than an "official" PI prefix?

To expand on that, one of the big problems with RFC 1918 bogons is that the address might well wind up on some network on which it is valid, but refers to a different host.   This is _much_ less likely with ULAs.

So the sense in which ULAs are less harmful than PIs is that in principle at least, this cannot happen with PIs—if they escape their designated network, they are valid nowhere else.

v2.23.0 | Report a Bug | By Email