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

Victor Kuarsingh <> Mon, 05 August 2013 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D05D21F9C05 for <>; Mon, 5 Aug 2013 07:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gVJkZHHtO3b2 for <>; Mon, 5 Aug 2013 07:20:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D77121F9E01 for <>; Mon, 5 Aug 2013 07:20:32 -0700 (PDT)
Received: by with SMTP id f6so1733772qej.26 for <>; Mon, 05 Aug 2013 07:20:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=gzvXAcp06FQKACHb/vDc4FkpkSGgVv5rR+XU09eTZB4=; b=n1JamihHqvJClMKhjHtDOwJgMy0eyd7jGbFKaFVoRdyHh3lKul/4trLnO4mKkhiD+b k9iQu7Vq+8R9rY+qSyYLQbh5zaq+iFrrllVZMlgvQ6zVwOkIuFc4e2N5NTXTSu2WyeR6 SJFWLcvUT3UjWvyv+jexbSspM+3vf4lQfGaO+ZLxRGRtY+7l1QkD8yv72Xxlyt2Q8A4j qqkZDG0uU1c4ByV3AT5Jwjtp0iByRW3l7edgQiJlamY0m3NXlkDF0IHtCnV+ZSbSU19M Lp9jueSKcAPKRIqWxxPEIql18zlBRtxjhSyw7ZrWfIgDTjh3J18Opso7Fw09PD7YJs+D ZwmQ==
X-Received: by with SMTP id 6mr18566674qeg.48.1375712431463; Mon, 05 Aug 2013 07:20:31 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id h4sm7312783qai.6.2013. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 07:20:30 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Mon, 05 Aug 2013 10:20:23 -0400
From: Victor Kuarsingh <>
To: <>, Fred Baker <>, "" <>
Message-ID: <>
Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Gm-Message-State: ALoCoQkRVqyYHGDXBB6OcoyZQ+q8OQZNqqUvqO5jx3zsSI6gpGj5Ye8Y2LFqmx2SFrfMgl9ki8S6
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 14:20:39 -0000

On 2013-08-05 4:23 AM, ""
<> wrote:
>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.

Agreed in principle.  I am not able to talk about my personal experiences
per NDA with customers.  I would say the the use of ULAs in a network is
not a secret and people are considering it.  Being mute on the subject may
result in incorrect analysis of ULA validity in the enterprise. Not
considering the good/bad, or the various aspects by which one needs to
factor it against - I.e. Security, Internet Reachability, inter-op with
other functions like Multicast etc).

>This is partly an educational matter which we usually address by
>organizing training sessions within the enterprise,

Fair enough, but I am sure there may be some mis-informed folks
potentially advising some customers in the other direction (lets call them
rogue consultants).  My largest concern is that irrespective of any IETF
guidance (if it's negative or positive), ULAs will likely still show up.

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

I want to agree with this, but given we have little long term operational
experience with ULAs, discouraging it's use based on perceived downfalls
may be as bad as encouraging it.  If we are unable to provide guidance one
way or the other, then pointing to other works (which will continue this
debate I am sure), may be the most practical.

I think some mention of ULAs, in-line with the text is a good idea since
it's with the flow of the document (I.e address subject matters based on
document context). 

As an example, Section 2.4.2 discusses ULAs with respect to [perceived]
connections to RFC1918 and security.  It was the specific intent of the
draft to provide such security guidance in-line.  I think pulling out such
text would then leave the reading to guess whether ULAs play into the
security considerations during the assessment phase.

So in summary (my input):
(1) Mention ULAs, in-line within text per relevant topic area
(2) Don¹t encourage it's use, and provide due warning of potential issues
(again in-line)*
(3) Point to other works/drafts on usage cases and further information

* I think repetitive warnings throughout document, per subject area will
have a better deterrent affect vs. a single section with a "bad for your
health" warning.


Victor Kuarsingh

>-----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.
>v6ops mailing list