Subject: Re: [OPSEC] Last Call: <draft-ietf-opsec-lla-only-07.txt> (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC

From: "George, Wes" <[email-masked]>
Date: Thu, 27 Mar 2014 11:35:23 -0400

I’d like to add another voice supporting the suggestion that this document
include an IESG warning that it is not an IETF-recommended thing to do, in
order to reduce possibility of confusion about whether or not IETF
consensus in this case is “yes this is a thing consenting adults can do on
the privacy of their own network” vs a ringing endorsement that “IETF
thinks that this is a thing that you SHOULD do on your network”. Even
though the document is not a BCP, the document’s status as an
informational consensus RFC carries weight among those looking for
guidance on the nuts and bolts of implementing IPv6 on a network.

The authors have done a good job of responding to this concern by
eliminating the language contained in earlier versions of the doc that
read like a recommendation/endorsement, but I’d still rather see this as
an individual document, and failing that, suitably prefaced with a warning.

Some specific comments to help explain why “bad idea” keeps getting thrown
around:

On 3/26/14, 9:31 PM, "Christopher Morrow" <[email-masked]>
wrote:
>So, I was presuming that the LLA was ONLY for the ptp links, and that
>loopbacks would still be standard old addresses like today.
>
>If the above is the case (my presumption) then you have access to the
>local-lo0 equivalent as along as your IGP is healthy, and you're ok.

Conveniently, I’ve raised this before [1]
"Diagnostic tools like pings and traces, as well as more important things
like PMTUD are brittle enough without advocating this practice for
questionable benefit. Yes, you can configure a router to respond to ICMP
via a routable loopback address. However,  relying on such configuration
being properly implemented, let alone applied pervasively and consistently
to make critical bits of infrastructure work seems risky. Now I have to
ask whether the trace failed because the router isn't responding with the
right interface, or because something's actually broken. I also have a
hunch that this would expose a whole new crop of routing protocol next-hop
bugs and assorted weirdness based on what (flawed) assumptions router
vendors made about interface addressing and reachability when
implementing."

>
>complexity is going to cause you pain, it is going to cause you
>problems and it is going to lengthen outages :( avoid complexity.
+1

A further quote from [1] regarding operational considerations that the
document has not, IMO suitably addressed:
"LLA has other issues:
- diagnostic pings across connected interfaces are harder to complete -
instead of simply typing ping [address], one must now specify the exit
interface, effectively doubling the commands required.
- diagnostic traceroutes are similarly harder because one must specify a
routable source interface and destination.
- in large networks, most connected interfaces are numbered using a
standard numbering scheme such that one can derive the address of the
remote side by simply adding or subtracting 1 from the local IP address.
Pings to the remote side when dynamic LLAs are used require determining
the address to be pinged, either via a show interface on the remote side,
or a show ipv6 neighbor on the local side, and may be more prone to
operator-induced failure due to the fact that the addresses are not
obviously similar to one another.
- because dynamic addresses are not present in the configuration, it is
impossible to search for them to determine where a given address may be if
it shows up in diagnostic information (packet captures, traces, routing
updates, etc). Statically-assigned addresses show up in configuration,
meaning that simple tools like grepping a rancid config repository can
find the router on which that address is located."

Thanks,

Wes George

[1] http://www.ietf.org/mail-archive/web/opsec/current/msg01258.html

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: Pete Resnick <[email-masked]>
Date: Thu, 27 Mar 2014 17:02:35 -0500

On 3/27/14 10:35 AM, George, Wes wrote:
> thinks that this is a thing that you SHOULD do on your network”.

I'm speaking as only 1/15 of the IESG, but putting IESG statements on 
the tops of documents is a very icky business, *especially* on IETF 
consensus documents. I'd much rather tell the WG, "There's a bunch of 
IETF folks who came out during Last Call and said you have to fix this, 
so go fix it" than try to get the IESG into the business of writing 
text. If there's not IETF-wide rough consensus for the document as-is, 
fix it or ditch it. Telling the IESG to "approve it, but put in a note 
from on high saying why it's bogus" is....bogus.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: joel jaeggli <[email-masked]>
Date: Thu, 27 Mar 2014 15:13:12 -0700

> from on high saying why it's bogus" is....bogus.

So I think the issue, and I don't want to second guess the chairs here
(unless asked, in which case it's my job), is that fundamentally if you
don't like this approach there's no fixing it. It's just icky.

 So if you dislike it, but concede that it does work for some people
then you're in my camp. I absolutely would not go to the wall over this
approach even if I wouldn't employ it and find it to be more trouble
then it's worth. There is evidence of successful deployments and a
plausible rational for why people find it necessary.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 27 Mar 2014 17:55:19 -0500

> don't like this approach there's no fixing it. It's just icky.

Oh, don't get me wrong. When I say "fix it", I don't mean that they 
necessarily need to fix the protocol the approach. I simply mean fix the 
document, which may amount to the WG getting sufficient text in to say, 
"This is only useful in X Y and Z circumstances and is otherwise a bad 
idea and you shouldn't do it." We are happy to publish all sorts of 
applicability statements that say, "This is stupid in all but these 
circumstances." I just don't want the IESG to have to write it up. The 
WG should make their document reflect what the community wants.

> plausible rational for why people find it necessary.

Just in case that "you" was me: I am completely agnostic about this 
document; I'm just talking about what the community should be expecting 
of the IESG. If the community decides that this thing is useful to 
document for the segment of people who do want to do it, have at it. If 
not, not.

pr

---

From: Randy Bush <[email-masked]>
Date: Fri, 28 Mar 2014 07:57:31 +0900

> putting IESG statements on the tops of documents is a very icky
> business, *especially* on IETF consensus documents. I'd much rather
> tell the WG, "There's a bunch of IETF folks who came out during Last
> Call and said you have to fix this, so go fix it" than try to get the
> IESG into the business of writing text. If there's not IETF-wide rough
> consensus for the document as-is, fix it or ditch it.

the iesg can sort out the process.  i really don't care.  i gave at the
office (apologies fo ramerican idiom).  what matters to me is that, if
this document is published that it is clear to the reader that doing
this is ill-advised.  a deep dive into why it is ill-advised might be
educational, but i see it as optional.

randy

---

From: John Leslie <[email-masked]>
Date: Thu, 27 Mar 2014 19:34:22 -0400

Randy Bush <[email-masked]> wrote:
> [Pete Resnick <[email-masked]> wrote:]
> 
>> business, *especially* on IETF consensus documents.

   The IESG really doesn't have the spare cycles to go there.

>> I'd much rather tell the WG, "There's a bunch of IETF folks who came
>> out during Last Call and said you have to fix this, so go fix it"
>> than try to get the IESG into the business of writing text.

   When the IESG tries that, a _very_ common outcome is for the
document to come back on the agenda with the responsible AD reporting
"The authors declined that offer." ... at which point the IESG admits
it doesn't have the spare cycles to go further.

>> If there's not IETF-wide rough consensus for the document as-is, fix
>> it or ditch it.

   The sad truth is, the IESG no longer has the spare cycles to "Just
say No."

   (I wish we'd find boilerplate to record such "limited" consensus.)

> educational, but i see it as optional.

   I'm not sure the OPSEC WG has the cycles to go there, either :^(

   (FWIW, I'm with Randy on this being a bad idea; but I doubt that
actual operators pay much attention to RFCs when looking for operational
advice.)

   Bottom line: _I_ really don't have the cycles to go there. :^(

--
John Leslie <[email-masked]>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 27 Mar 2014 16:46:15 -0700

On 3/27/14, 4:41 PM, Andrew Sullivan wrote:
> On Thu, Mar 27, 2014 at 07:34:22PM -0400, John Leslie wrote:
>>

responsible AD here.

I take the IETF LC input with the gravitas that's appropriate. the IESG
review occurs after the LC.

> I was on the receiving end of an IESG that simply stalled a document
> until the WG changed its approach, because of IETF concerns, so I
> disagree with that claim.  But if it is true, then we might as well
> give up.  If there's weak IETF consensus (with some strong objections)
> to a document that comes from a WG and has strong consensus inside the
> WG, the _only_ people who can say no are the IESG; and they must.
>
> Best regards,
> 
> A
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Mar 2014 19:53:26 -0500

On Mar 27, 2014, at 6:41 PM, Andrew Sullivan <[email-masked]> wrote:
> If there's weak IETF consensus (with some strong objections)

Not to put words in the responsible AD's mouth, but we do have a process for dealing with this situation.   What it looks like to me is that there is IETF consensus to publish the document, as long as it comes with appropriate caveats about applicability.   Normally in a situation like this, there would be text added to the document as a result of IETF last call comments before the document ever made it to IESG review.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 28 Mar 2014 07:43:05 +0100

Hi Andrew

I think if the IETF has strong objections with engineering reasons, then it
is already a NO. That document should not even get to IESG. We only need
IESG decision (saying yes or no) when we all in IETF agree with consensus.
All IETF WGs should adapt/amend their document to total IETF consensus
(that is WGs interaction).

AB

On Thursday, March 27, 2014, Andrew Sullivan wrote:

> Andrew Sullivan
> [email-masked] <javascript:;>
>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Mar 2014 19:41:37 -0400

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sun, 30 Mar 2014 16:41:48 -0400

--On Thursday, March 27, 2014 17:55 -0500 Pete Resnick
<[email-masked]> wrote:

> Oh, don't get me wrong. When I say "fix it", I don't mean that
> they necessarily need to fix the protocol the approach. I
> simply mean fix the document, which may amount to the WG
> getting sufficient text in to say, "This is only useful in X Y
> and Z circumstances and is otherwise a bad idea and you
> shouldn't do it." We are happy to publish all sorts of
> applicability statements that say, "This is stupid in all but
> these circumstances." I just don't want the IESG to have to
> write it up. The WG should make their document reflect what
> the community wants.

--On Thursday, March 27, 2014 19:41 -0400 Andrew Sullivan
<[email-masked]> wrote:

>>    The sad truth is, the IESG no longer has the spare cycles
>>    to "Just say No."
> 
> I was on the receiving end of an IESG that simply stalled a
> document until the WG changed its approach, because of IETF
> concerns, so I disagree with that claim.  But if it is true,
> then we might as well give up.  If there's weak IETF consensus
> (with some strong objections) to a document that comes from a
> WG and has strong consensus inside the WG, the _only_ people
> who can say no are the IESG; and they must.

Hi.
Two observations:

(1) If the IESG were to ever reach the point that it doesn't
have the cycles to properly evaluate community consensus about a
document and to make sure that the document reflects that
consensus before it is published, then they, and we, are in bad
trouble.  That is one or only two key parts of the IESG job (the
other being WG oversight).  If the IESG doesn't have the cycles
do that that and still do anything else, then the "anything
else" should go.  If doing this type of work is still not
possible, I'd expect to see the IESG giving serious
consideration to procedural changes that would reduce their
workload [1], reducing the number of WGs to what they can handle
[2], or resigning in the hope that the Nomcom can find people
with either the cycles or the willingness to make changes.

(2) Like Pete, I strongly prefer getting a document to the point
where it is consistent with community consensus by having the
responsible WG and document editors make changes rather than
using IESG statements.  The latter should, IMO, be reserved for
the most unusual situations if they are used at all.   But the
priority should be that we never publish an IETF-stream
document, especially a standards track one, that doesn't reflect
community consensus without its being very clear about that.

(3) If a WG and the community run out of cycles to get a
document right, then the document ought to be dead, especially
if it is proposed for standards track.    Too bad, but,...

(4) Some of the notes in this thread -- and some IESG actions in
the past-- have implied that at appropriate goal of the IESG
review process is to find compromise positions that make
everyone more or less happy.  IMO, if we ever reach the point
where we believe that, we will have given up everything that
makes IETF standards superior to those of SDOs who believe that
something produced by a WG, or even seriously proposed to one,
is entitled to standardization.  Our standards, and the Internet
itself, work because we have focused on good, workable,
solutions -- ideally with a minimum of options that could lead,
intentionally or not, to lack of interoperability-- not
compromises among ground who want "their" ideas standardized and
the resulting "almost anything conforms" standards.

   john

 we should expect to see a lot of resignations
(1) If we reach the point that either the IESG 

[1] (there has been no shortage of such proposals