Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

Mark ZZZ Smith <> Mon, 05 August 2013 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 598F421F9DF0 for <>; Mon, 5 Aug 2013 14:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h0u-oSSJjQDB for <>; Mon, 5 Aug 2013 14:39:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D18CA21F9E43 for <>; Mon, 5 Aug 2013 14:39:10 -0700 (PDT)
Received: from [] by with NNFMP; 05 Aug 2013 21:39:09 -0000
Received: from [] by with NNFMP; 05 Aug 2013 21:39:09 -0000
Received: from [] by with NNFMP; 05 Aug 2013 21:39:09 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 46475 invoked by uid 60001); 5 Aug 2013 21:39:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1375738749; bh=gYAFSU3pKOmPWsQPWbQNVx/u7So+IzM8OspqNEzxR6A=; 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=bFBKeAnvvELREYF5XZrfj2pzdPoEtgjsJgVYY5lilG5GjtdfeS6XybGiiseUAGc1gfm83djugAoRf2GiyOrgbnHknW7EcwzqcHNKjPBl/MBsDnPt6BHPvBOiCSO7/AzW4CnYiuZv7/RFHFx7sk2dhUeJN7y1IQ2KVwx7A3m6tOM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; 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=4Ju9ozwRTva/LbSApyZvArEXHNTJJ4bmxaYF2Pe9WCrVZ5ujQiQ3nmCMSJO4kfsQ0MuUeeyJj51XdZZuv6y2DNDMr1Kaa0c8P+I1FDiBkvZKkQiGJvJV7H/PS5Ose2r6vdOkHKDFNe+mmPGJ07AHQNitVBaDt5bZozAIH7N0Xww=;
X-YMail-OSG: mIrO29EVM1k1YTebP_VKSPVgbrCE2q5fdP9WYR4ZIuRbmYI k9Bb5ZncoccubSN1LmRa9cUfvZvlzlsOSQFbM.bnznSVRBMCtbFrO.MVMp2A b4NgXwGoBfM9znw7.RCvzTH6IKIHfg6GKtqCwrzy_WhMFBBsk_rGxIuEZCG3 Q2bRNIWAHtNuqCBW522raNv4sT4YvRZDiGdbFuDr_xiwZuOFT9W_woRXFb77 xklu7Hrn8enPmHBMYv6b2Y9wKt0rrsHZ58_mZ8a4_bx_yX5BCj4zq6PXaQwb dnzJfpvUWbmWCM9384ZPi3L3sw0u7vW5usL.AalfmJeOXvNO.sYSxsNXPTRT Q639mkANq.uK1IRjcFUGe789tWhYu.K2Lcuzov.B0atT6qmcQWz2posafgwb i8CUo8vb7lcTqg3wZh_dh4OEk6.bAtTP1pFe9lVAInhLtqe1AMSzHLxB1R6T ZOG2e_u0mRM96KD7odKE.IaBQieErIFvufydZCUqdcaprWaiodeebDIelxGN SdVc.s0yC54m74JdEmpewTkeMHC95hF.702Vh.Tsv2jCRpVc4sp_5rCZgMGY aKGA9BFhAYtqQ7YDNPcSMSG9BgEe_ZfgPkg_vWs5GEHeXNg--
Received: from [] by via HTTP; Mon, 05 Aug 2013 14:39:08 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.Cj4gVG86ICJjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb20iIDxjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb20.OyBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPiBDYzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogVHVlc2RheSwgNiBBdWd1c3QgMjAxMyAyOjM3IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHIBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <>
Message-ID: <>
Date: Mon, 5 Aug 2013 14:39:08 -0700 (PDT)
From: Mark ZZZ Smith <>
To: "Fred Baker \(fred\)" <>, "" <>, Lorenzo Colitti <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Aug 2013 21:39:25 -0000

----- Original Message -----
> From: Fred Baker (fred) <>
> To: "" <>om>; Lorenzo Colitti <>
> Cc: "" <>
> Sent: Tuesday, 6 August 2013 2:37 AM
> Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
> A thought - tell me if this makes sense.
> In IPv4 networks, it is pretty common to in some way advertise the address of an 
> internal-only server and then block access to it at the firewall. If you want 
> Cisco examples, try or - dig them, ping 
> them, and traceroute towards them. From my perspective, in IPv4 or in IPv6, the 
> firewall rule makes little sense except as an additional defensive layer; one 
> should not advertise the name to the great unwashed, and whether or not one 
> does, one should give the system an address that is not advertised to the great 
> unwashed. The next question, of course, is how to achieve that - does one only 
> advertise half of their address space? Announce multiple prefixes? The ULA, 
> whatever its other ills or uses may be, is an address that is not advertised 
> upstream, and therefore a very logical address for an internal-only system in an 
> IPv6 network.

Makes sense to me. I think ULAs would be better than globals with ACLs blocking access for these sorts of sites because ULAs aren't globally reachable, and even if they're accidentally leaked, their external reachability should be very limited. If the default unreachability of ULAs isn't good enough, ACLs blocking the fc00::/7 on the edge of the network would be further protection.

The nature of globals is that they're intended to provide global reachability by default. ULAs are not intended to provide global reachability, and even if leaked, probably won't provide global reachability reliably, which will also discourage their use for "global purposes". So if you don't want global reachability, it would seem to me that ULA is the better address space to use.

> I scratch my head a bit on the vehemence that seems to come across in 

> discussions of the ULA. I understand that there is a strong distaste for NATs, 
> and I share it in the stateful case. It sounds a bit like the baby is being 
> discarded with the bathwater, though, in the case of a system that one 
> doesn't want to have communicating with the great wide world.

I don't really understand it either. The value I see in ULAs is that it is your own local address space, meaning that you're in complete charge of it, unlike the global address space you have been given by somebody else. It seems to me that one way to increase robustness is to reduce external dependencies. Using a local address space, that is used in preference to a global address space when there is a choice, in general should be more robust because you have absolute control over it.

> Am I out to lunch? If so, in what way?
> On Aug 5, 2013, at 1:23 AM, wrote:
>>  WG, 
>>  I've read (and commented) this draft some time ago. This document is 
> useful and I think it should move forward.
>>  Regarding the ULA-related discussion, I don't think the document should 
> simply ignore the potential use of such addresses, e.g., because our experience 
> of providing IPv6 VPN service to our corporate customers since 2009 has shown 
> that some of these customers ask for (and sometimes demand) a ULA-based 
> addressing plan, mostly because these customers still think that private 
> addressing provides some form of security. 
>>  This is partly an educational matter which we usually address by organizing 
> training sessions within the enterprise, but the reality is that we could never 
> avoid the discussion about ULA usage with these customers. And there are indeed 
> a few of them who have chosen to go for an ULA addressing plan, at least for the 
> duration of field trials or even pilot deployments.
>>  I would therefore expect the draft to mention ULA addresses. But I would 
> also expect the draft to clearly discourage the use of such addresses, for the 
> reasons mentioned by Lorenzo in his recent message. 
>>  For the sake of readability, I would (1) remove the ULA-related text from 
> Sections 2.4.2, 3.1 and 6.3, and (2) dedicate a specific "On ULA Addressing 
> and Its Foreseen Implications" subsection in Section 2.6, which would 
> better elaborate on the warnings highlighted in the aforementioned sections 
> (e.g., Section 3.1's "use of PI space obviates the need for 
> ULAs").
>>  A few additional typos:
>>  Section 2.1, page 7: "...after all initial *deployment* has been 
> completed."
>>  Section 2.2.2., page 9: s/recommend/recommended
>>  Section 6.3, page 26: s/enterprise/university (second paragraph), s/campus 
> enterprise/campus
>>  Section 8, page 27: s/Jaquenet/Jacquenet 
>>  Cheers,
>>  Christian.
>>  -----Message d'origine-----
>>  De : [] De la part de 
> Fred Baker
>>  Envoyé : dimanche 4 août 2013 20:00
>>  À :
>>  Objet : [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
>>  This is to initiate a two week working group last call of 
>  Please 
> read it now. If you find nits (spelling errors, minor suggested wording changes, 
> etc), comment to the authors; if you find greater issues, such as disagreeing 
> with a statement or finding additional issues that need to be addressed, please 
> post your comments to the list.
>>  We are looking specifically for comments on the importance of the document 
> as well as its content. If you have read the document and believe it to be of 
> operational utility, that is also an important comment to make.
>>  _______________________________________________
>>  v6ops mailing list
> _________________________________________________________________________________________________________________________
>>  Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>>  pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>>  a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
>>  Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>>  This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>>  they should not be distributed, used or copied without authorisation.
>>  If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
>>  As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
>>  Thank you.
>     • Make things as simple as possible, but not simpler.
> Albert Einstein
> _______________________________________________
> v6ops mailing list