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"
<christopher(_dot_)morrow(_at_)gmail(_dot_)com>
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.