Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-06.txt

From: [email-masked]
Date: Mon, 06 Jan 2014 09:13:54 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.

        Title           : Using Only Link-Local Addressing Inside an IPv6 Network
        Authors         : Michael Behringer
                          Eric Vyncke
	Filename        : draft-ietf-opsec-lla-only-06.txt
	Pages           : 10
	Date            : 2014-01-06

Abstract:
   In an IPv6 network it is possible to use only link-local addresses on
   infrastructure links between routers.  This document discusses the
   advantages and disadvantages of this approach to help the decision
   process for a given network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsec-lla-only-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-lla-only-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "George, Wes" <[email-masked]>
Date: Wed, 8 Jan 2014 09:25:17 -0500

I’ve reviewed the latest version, and I have two comments.
First, while this document has come a long way in avoiding a
“recommendation” to use LLA-only, I still am concerned at putting this
forward as a WG draft, as it still serves as implicit IETF endorsement of
something I still view as a bad idea. It’s the last I’ll say about it and
I’ll go with WG consensus on the matter, but I’d much rather see this as
an individual draft.

Second, you briefly mention some complications with RSVP-TE in your
caveats section. There is currently a draft we’re hoping to get adopted in
the MPLS WG (draft-george-mpls-ipv6-only-gap) that analyzes the gaps
preventing operation of MPLS on an IPv6-only network. We received some
feedback from Nagendra Kumar pointing out that an additional gap is
created if one uses LLA-only, but the authors have made the decision to
try to avoid discussing draft implementations in that gap analysis, or
else the draft will never be finished. We are instead encouraging draft
authors to consider IPv6-only operation in their drafts, and to identify
existing gaps that the draft depends on getting resolved, or making
changes to address any gaps as appropriate. Therefore, you may want to
include some of the reviewer’s suggested text in this draft:
RSVP-TE
[I-D.ietf-opsec-lla-only] describes the approach of enabling link-
   local addresses alone in transit links.  This raises a need for new
   SubObject to carry a combination of RouterID and Link/Interface ID in
   RSVP PATH and RESV message.

   Gap: Minor, New SubObject for RSVP message for specific IPv6 deployment.

If the WG decides to move this -06 version on for IETF LC consideration,
this is probably something that can be added when the authors are
incorporating last call comments.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 17 Jan 2014 20:43:18 +0000

Wes, thanks for your comments, and sorry for the late reply... Inline...

> -----Original Message-----
> From: OPSEC [mailto:[email-masked]] On Behalf Of George, Wes
> Sent: 08 January 2014 15:25
> To: [email-masked]
> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-06.txt
> 
> something I still view as a bad idea. It’s the last I’ll say about it and I’ll go
> with WG consensus on the matter, but I’d much rather see this as an
> individual draft.

RFC2026#section-4.2.2: 

    4.2.2  Informational
      An "Informational" specification is published for the general
      information of the Internet community, and does not represent an
      Internet community consensus or recommendation.  The Informational
      designation is intended to provide for the timely publication of a
      very broad range of responsible informational documents from many
      sources, subject only to editorial considerations and to verification
      that there has been adequate coordination with the standards process
      (see section 4.2.3).

So we clearly don't want to do something that goes against the intuition of many people, but at least from a formal point of view I cannot see a problem. We are now in WG last call, so I think we should complete it. But if there is broad concern, we're also happy to re-submit as an individual draft. 

Whichever way we go: This concern has been brought up before, and I'd like to have a conclusion on this topic, so that we can progress. So, chairs - what do you suggest? 
 
> caveats section. There is currently a draft we’re hoping to get adopted in the
> MPLS WG (draft-george-mpls-ipv6-only-gap) that analyzes the gaps
> created if one uses LLA-only, but the authors have made the decision to try
> to avoid discussing draft implementations in that gap analysis, or else the
> draft will never be finished. We are instead encouraging draft authors to
> consider IPv6-only operation in their drafts, and to identify existing gaps
> that the draft depends on getting resolved, or making changes to address
> any gaps as appropriate. Therefore, you may want to include some of the
> reviewer’s suggested text in this draft:
> RSVP-TE

We can include this in that section, not a problem. It does add value, as it describes how the issue can be solved. Thanks for the info!

> If the WG decides to move this -06 version on for IETF LC consideration, this
> is probably something that can be added when the authors are

Thanks! Chairs, what is missing in the WG LC? Are we done? 

Michael

---

From: "George, Wes" <[email-masked]>
Date: Wed, 22 Jan 2014 10:45:36 -0500

>      that there has been adequate coordination with the standards process
You make a good point, and those familiar with IETF may well interpret it
that way. However, we have plenty of Informational drafts that go through
a WG and IETF LC, are evaluated by the IESG and do represent IETF
consensus, and that is the path this document is currently on.
Additionally, what I’ve found in practice with those who are consumers of
IETF drafts but not active participants and thus not familiar with the
nuances of our document classifications is that to them, an RFC is an RFC.
Therefore, the boilerplate note that accompanies an individual draft (see
5742) provides the necessary disclaimer to make it clear that IETF doesn’t
endorse something, even if it is documented as “this is a thing that
consenting adults may do on their network if they choose” instead of “this
is a thing that you SHOULD do on your network”.

Thanks
Wes

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 23 Jan 2014 17:12:27 +0000

>> If the WG decides to move this -06 version on for IETF LC 
>> consideration, this is probably something that can be added when the 
>> authors are incorporating last call comments.
>

Hi Michael, All,

Many thanks for all the constructive work upon the work.
Good to see all these good considerations of operational security impact discussed.

The chairs have looked at all comments during WGLC.
From that we see that there is agreement that the document is correct from a technical.

There is rough consensus that the document does not provide recommendation, and yet only provides data-points if one would utilize the link-locals in such a way. There is a notion of worry that the bare existence of the document will trigger people to utilize the solution.

We will take these WG thoughts together with the summary of WG document status in the shepherd write-up for IETF LC.

G/