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

"Fred Baker (fred)" <> Mon, 05 August 2013 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55A0F21F9FC6 for <>; Mon, 5 Aug 2013 09:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YEgKF2UYOLPL for <>; Mon, 5 Aug 2013 09:38:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FFB521F9D33 for <>; Mon, 5 Aug 2013 09:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5582; q=dns/txt; s=iport; t=1375720681; x=1376930281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FUZVHO8TwnxXMThwriVS6gJckEsHBT5zSRNxOzc9L5A=; b=OlOKv2Pp128jWRFEVawFML2bbP8UrluDA9RD+tmMF8AtHQ4DM+VUW3s8 7GY754qhg26u929HZ5m+FwlrVIjsDbiuSohFrWNXvvuCTOFdnl6DhwHau RWHRf0CU5uLZMmhHzWOpJ60uSygetZ3c43L5eVgZzsP+sMZd0bPWFinB1 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,819,1367971200"; d="scan'208";a="243607120"
Received: from ([]) by with ESMTP; 05 Aug 2013 16:37:55 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r75GbsQE014993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 16:37:54 GMT
Received: from ([]) by ([fe80::200:5efe:]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 11:37:54 -0500
From: "Fred Baker (fred)" <>
To: "" <>, "Lorenzo Colitti" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
Thread-Index: AQHOkfohNjEYIMkIb0i5L4Ne0hNrqQ==
Date: Mon, 5 Aug 2013 16:37:53 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Aug 2013 16:38:27 -0000

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.

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.

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