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

<> Mon, 05 August 2013 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DA1821F9D0D for <>; Mon, 5 Aug 2013 01:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0+bSjwLH945a for <>; Mon, 5 Aug 2013 01:23:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C491921F9CEF for <>; Mon, 5 Aug 2013 01:23:05 -0700 (PDT)
Received: from (unknown [xx.xx.xx.3]) by (ESMTP service) with ESMTP id 8ED703B46EF; Mon, 5 Aug 2013 10:23:04 +0200 (CEST)
Received: from (unknown []) by (ESMTP service) with ESMTP id 6B62A4C195; Mon, 5 Aug 2013 10:23:04 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Mon, 5 Aug 2013 10:23:04 +0200
From: <>
To: Fred Baker <>, "" <>
Date: Mon, 5 Aug 2013 10:23:02 +0200
Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
Thread-Index: Ac6RPJAPvCz0VJrVRye5mfYc/5k3oQAc/iMw
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR
Content-Language: fr-FR
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2013.6.28.101520
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 08:23:13 -0000


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 



-----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.