Hi,

First-time reviewer here….given the level of interest in this draft in LC, there's an abundance of material to work with. 

Standard disclaimer applies: these remarks are intended primarily as guidance to the Ops ADs, as part of the ops-dir effort to make sure there's been ops review of everything going to the IESG, and are otherwise to be treated exactly like any other LC/review comments.

I reviewed Appendix A of RFC 5706, but discovered many of the questions don't really apply. This document is not standards track, and the answers to most of the RFC 5706 questions are either implementation-dependent (router OS) or specified elsewhere (such as usage of ULAs). A couple of the questions have helped point to a suggestion though (see below).

I agree with the general tone of the LC comments on ietf at ietf.org, and some I found in the opsec WG list archive, in that the major question about this document is whether it adequately documents the practice it describes, including that for the most part the practice in question appears to be sub-optimal ("most expedient current practice for some use cases"?) I've tried to approach it from the perspective of a network operator trying to determine whether I want to use this technique in my network.

I'm struck by two limitations in particular: 

* The only real advantage that seems to be claimed for using LLAs in this manner for routers is in reducing the attack surface for attacks that rely on sending packets from outside the network to router interfaces. (The rest seem to be about simplicity/scalability but don't actually say so, and see below on that.) While this may well be true, it sounds a bit like the corresponding justifications for IPv4 NAT, which was an ex-post-facto rationalization-- the original use case for IPv4 NAT was address scarcity, which doesn't apply for IPv6. What would be the initial driver for a network operator to investigate this configuration option, besides that global addresses may not actually be necessary for all router interfaces? 

* While the document has a list of caveats to go with the advantages, the only use case specifically discussed is IXPs. This limits the usefulness of the document in practical terms. For example, the stated advantage of reduced routes to carry in the IGP seems only narrowly applicable, and there's no discussion of how big a network might be before this isn't a negligible concern. Obviously the network operator is the one who determines this in practice, but actual guidance here is extremely thin.

From the record, it looks like the WG was strongly in favor of documenting this practice without commenting on whether it was a good idea, but without use cases, specific comments on scalability, or comments on existing deployment, it's hard for this (admittedly rusty) network operator to get a lot of insight beyond the flat statement that "We therefore conclude that it is possible to construct a working network in this way." Obviously the question whether it's a good idea could be answered "It depends," and there's nothing wrong with that, but this document seems of limited help in determining "Depends on what?"

A suggestion, given both my own reaction to the document and the LC comments I've seen so far:

1. Add a brief paragraph to the introduction on "systemic impacts", laying out the sense from the LC comments that using LLAs in this way generally adds complexity to debugging, may not scale well (addresses that are invisible to your addressing plan and DNS but appear in running router debug and IGP tables may not actually be an improvement over maintaining those), and may limit interoperability in specific contexts (such as needing to debug across operational boundaries/LL scope, by making  global/ULA addresses a special case). These add up to "don't do it unless you're comfortable with the implications," without dismissing the advantages if they're important to you.

2. Further comments on existing deployment: is anyone doing this today, and what seems to be the use case that compels them?

Hopefully this would balance the concerns raised with the ambiguous applicability of the document, reluctance to go back and re-tool it too aggressively, and the sense that the document needs to be strengthened from the perspective of operational impacts.

HTH,
Suzanne