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.morrow@xxxxxxxxx> 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.