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

["George, Wes" <[e-mail]>]

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" <[e-mail]>
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.