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

Mark Smith <markzzzsmith@yahoo.com.au> Thu, 30 May 2013 08:11 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 120C521F9467 for <v6ops@ietfa.amsl.com>; Thu, 30 May 2013 01:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5]
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 OivAgwomooMp for <v6ops@ietfa.amsl.com>; Thu, 30 May 2013 01:11:09 -0700 (PDT)
Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) by ietfa.amsl.com (Postfix) with ESMTP id A783B21F97FC for <v6ops@ietf.org>; Thu, 30 May 2013 01:11:08 -0700 (PDT)
Received: from [98.139.215.140] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 08:11:07 -0000
Received: from [98.139.212.231] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 08:11:07 -0000
Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 30 May 2013 08:11:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 472294.83888.bm@omp1040.mail.bf1.yahoo.com
Received: (qmail 78158 invoked by uid 60001); 30 May 2013 08:11:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1369901467; bh=y2Xu8fbvHVVC4ZsQekLOr8EIYFKjHAIUhAHQhvAgk48=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WBMV6j3ajqTQvv9GToAKvmIIBJ0GDh39opWOT29JlDvqFF9doL4wCBzrMNuxnyORDMgWW9Eee9Mqv0od3U89pqIfehSXXHyHQaWxQH/PYfrxbeF88Kgbp51d/d35z8Uf0xlm+pl7pZNlGUYnL8t4POncRnSK1NC/Q7GIeyIW8p8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VUiqSOl/OMzUGPwWq8qu0CJCFsQgiBnfmXN/VDAhwy7YZrdKYzsnchv2yjdc0J7PkUzcU5Q3sfz3xbnVPSz5RBzeAWX8+1i62F3ddQQzxkgO2uK36zKK8AFz4leDAbWrUwiVDRyEWm15fAjEvdHiUAnO+lQ/tCMnHR6rP0/IzzQ=;
X-YMail-OSG: eYiPTN8VM1lEdRhvJYOMBatmuUWXEr3wt8fd7_ZyopfH7nn skwbg3SsmyIs_c2lPML.MkBei8zzODyUAzWApSfyN55wKMj9r_4ASbkZfMRK 0daULEXfu5llS5pOjsLHp8RC9l1Xb8aHdAQ.h71ugqcemWEnpBBXurEgPbGU i2hJLCcFSgg.1x3zMKb3BVmTatLgK8kEaPdqfkcqrJOTDOOSTfBK13iVPtO_ Dj3TC59vn9VTRySSLAY3Q7EhjI5KG2XDcZjhmeMz_wJF1I.Ed3EMbhfjVHhQ PgrBZzUo3sKibn_Auf.J1sNJgHukDBOtgln2G.b86fiF2J6KQ8Svc2GVMJb7 37dguivYAZnCYBTAnfUcEqgvogFAN7XD5v.KtJgzZoqu3D7it8.pqKjpuJVe rqFlJRGWCSqKNfhJYaXaIP7Nsxh2eo27jvO_D2qRa91mpOPUUQi1CUPR3jzk qSH7LZVEd3FU3FI13nSsXTnISl5M2_tQDesB0cq9zoiXGGiMUae_yHhES32D dmv451IALiXSvLOexmELpFCO0K_al0BHiMXqy2AL2YAtqTJxbK74kQnbW60K fhbOqLGec
Received: from [121.200.231.211] by web142506.mail.bf1.yahoo.com via HTTP; Thu, 30 May 2013 01:11:07 PDT
X-Rocket-MIMEInfo: 002.001, Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20.Cj5UbzogInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.IAo.Q2M6ICJkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnNAdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnNAdG9vbHMuaWV0Zi5vcmc.IAo.U2VudDogVGh1cnNkYXksIDMwIE1heSAyMDEzIDQ6NDEgUE0KPlN1YmoBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.145.547
References: <CAKD1Yr29kf1Me=6JR66Gq0dFYgQx2wq=pjW8WZyHByPA0POsMQ@mail.gmail.com>
Message-ID: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com>
Date: Thu, 30 May 2013 01:11:07 -0700
From: Mark Smith <markzzzsmith@yahoo.com.au>
To: Lorenzo Colitti <lorenzo@google.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>
In-Reply-To: <CAKD1Yr29kf1Me=6JR66Gq0dFYgQx2wq=pjW8WZyHByPA0POsMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "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
Reply-To: Mark Smith <markzzzsmith@yahoo.com.au>
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: Thu, 30 May 2013 08:11:18 -0000

>________________________________
> From: Lorenzo Colitti <lorenzo@google.com>
>To: "v6ops@ietf.org WG" <v6ops@ietf.org> 
>Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" <draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org> 
>Sent: Thursday, 30 May 2013 4:41 PM
>Subject: [v6ops] A good example of why we need to careful about ULAs
> 
>
>
>News at 11:
>
>
>1. ULAs leak.
>
>2. People assign ULAs by hand.
>

In the early news, not really a new problem.

RFC1918 and 100.64/10 leak too, and what is worse, I've seen people intentionally expose RFC1918s to other networks - the largest carrier here in .au uses RFC1918 addresses for their wholesale ADSL L2TP LACs (from memory, at least 20 to 30, spread across multiple /16s within 172.16/12) and then expect their many wholesale ADSL customers' to just accept those addresses and make them work within their own networks, despite their own, quite legitimate internal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that address space from your own). So we can't pretend that RFC1918s have been perfectly used, and therefore ULAs being less private than intended is going to be new problem and experience. At least properly formed ULAs are unlikely to conflict with other network's ones, even if the other network has used fd00::/8, and if the two interconnecting parties have both been lazy and used fd00::/8, they'll both be victims of theirs and the other
 party's laziness (which they'll be used to, since they've probably experienced it with RFC1918). They'll probably resort to NPTv6 to fix it, because that is what they're used to, rather than using IPv6's address aging mechanisms to renumber to a properly formed ULA. Good luck to them, as long as it doesn't effect the rest of us.


>

>Yes, both of these a violation of IETF guidance. I don't think that matters much, though - while we can always claim that the implementer/operator is "holding it wrong", we should be careful that what we design/standardize is hard to misconfigure and possibly robust in the face of misconfiguration. Subtle nuances like "these addresses are global scope, but not globally routable" tend to get lost very easily.
>

I think recommending against ULAs is just going to result in people stealing other address spaces for devices that don't need global reachability - like 2001:db8::/32, or unused global address space (as we saw with 1/8, 5/8 and other IPv4 prefixes).

I think global address space comes with and implies a default assumption of global reachability, and you'll therefore have to actively take measures to ensure they don't provide global reachability if you don't want it. Link-locals don't cut it because they're not routable. The need ULAs fulfils is the gap in between global space and link-locals, and the one which RFC1918 generally fulfils in IPv4, except that the likelyhood of address space collision is reduced.

>
>Of course, in the case of ULAs, there's not much that can be done about the design at this point, but we should make an effort to make it clear that the potential for misconfiguration exists and provide clear guidance on how not to misconfigure them.
>
>

>Personally, I think that providing said guidance is much more useful and important than enumerating scenarios that aren't widely, if at all, implemented, and I hope that the authors of draft-ietf-v6ops-ula-usage-recommendations will agree.
>

So is this draft aiming for BCP status and therefore should only reflect best common practice? If not, I think it is reasonable to present scenarios where ULAs could be useful. We've got a lot of experience with private address spaces from IPv4 (the Deprecating Site Local Addresses RFC3879 is also a pretty complete list of the problems with RFC1918 addresses), so the only real difference is scenarios where concurrent global and private address spaces could be useful. In some cases, they'll just be more capable versions of what we've already doing in IPv4 e.g. private addressed loopbacks on routers, global addresses on the links, in a ULA environment you would add ULAs to the links too, which could make troubleshooting and other OAM less dependent on the global address space.

Regards,
Mark.

>
>Cheers,
>Lorenzo
>
>
>---------- Forwarded message ----------
>From: Jeroen Massar <jeroen@massar.ch>
>Date: Thu, May 30, 2013 at 4:59 AM
>Subject: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
>To: ipv6-ops@lists.cluenet.de
>
>
>...
> 4  2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1)  20.755 ms  20.763 ms  20.784 ms
> 5  fd00:3303::1 (fd00:3303::1)  22.010 ms  21.984 ms  21.986 ms
> 6  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  17.806 ms  17.889 ms  17.842 ms
> 7  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  18.720 ms  18.593 ms  18.617 ms
>...
>
>Hmmmm fd00::/8, that really should never ever be visible on the Internet, being Unique *LOCAL* Addresses.
>And it does not look like they applied the randomness bit for picking a prefix either.
>You would also almost think that a /28 is more than enough address space to put a few router loopbacks in.
>
>It is apparently time for people to start checking their filters again because it seems that these packets leak into other ASNs too...
>
>More generally, do recheck your network for BCP38 compliance, please do apply it and require your peers to do the same!
>
>Greets,
> Jeroen
>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>