Hello,
I've reviewed draft-ietf-opsec-lla-only-04, see my comments below.
1) 2.1. The Approach
"Neither global IPv6 addresses nor unique local addresses are
configured on infrastructure links. "
[comment] Formally ULAs are of the global scope so maybe re-phrasing
to "neither globally routed addresses nor unique local addresses".
2) 2.1. The Approach
" [RFC6724] mandates that greater than link-local scope IPv6 addresses
must be used as the source IPv6 address for all generated ICMPv6
messages sent to a non link-local address.
"
[comment] As I mentioned in Vancouver, I think this statement is not
absolutely accurate.
What RFC6724 mandates is that *if* candidate source addresses set
contains link-local and global addresses, then global address is
preferred for global destinations.
Therefore it is possible to chose link-local source for global
destination in some cases.
For example, ND redirects MUST be sent from link-local address
(RFC4861, Section 4.5) while the destination may be global address.
Speaking of candidate set for DAS..
RFC6724 says:
"It is RECOMMENDED that the candidate source addresses be the set of
unicast addresses assigned to the interface that will be used to send
to the destination (the "outgoing" interface). On routers, the
candidate set MAY include unicast addresses assigned to any interface
that forwards packets, subject to the restrictions described below.
Implementations that wish to support the use of global source
addresses assigned to a loopback interface MUST behave as if the
loopback interface originates and forwards the packet."
Which means that it some implementations might not include lo0 into
the candidate set, in which case a router might use link-local as a
source which leads to operational issues and makes the troubleshooting
more difficult. I think it worth be discussed in the 'Caveats'
section.
3) 2.1. The Approach
"Control plane protocols, such as BGP [RFC4271], ISIS [IS-IS],
OSPFv3 [RFC5340], RIPng [RFC2080], PIM [RFC4609] work by default
or can be configured to work with link-local addresses.......
We therefore conclude that it is possible to construct a working
network in this way."
[comment] However there are protocols which may experience issues in
such topology (RSVP). While you do mention RSVP later, this section
discusses the effect on specific traffic types, so I'd suggest that
you add a sentence or two about protocols which might not work and
clarify that it is possible to construct a working network if those
protocols are not in use.
4) 2.1. The Approach
"ICMP error message can be sourced from a loopback interface. They
must not be sourced from link-local addresses when the destination
is non link-local."
See my comment #2 - applies here as well.
5) 2.2. Advantages
[comment] If I were you, I'd reordered the paragraphs. IMHO, lower
configuration complexity & simpler DNS are the main advantages of the
suggested approach, then routing table reduction.
Reducing attack surface does not sound like a really big advantage
providing that risk can easily be mitigated - so probably it would
make sense to put it at the end of the section. What do you think?
"Lower configuration complexity: link-local addresses require no
specific configuration, thereby lowering the complexity and size of
router configurations. This also reduces the likelihood of
configuration mistakes."
[comment] I'd also mention that it simplifies the whole address
management process.
6)2.3. Caveats
"
Traceroute: similar to the ping case, a reply to a traceroute packet
would come from the address of a loopback interface, and current
implementations do not display the specific interface the packets
came in on. Also here, RFC5837 [RFC5837] provides a solution.
"
[comment] in the traceroute/ping section you are saying that RFC5837
provides a solution.
However there are two problems and only one might be solved by
including interface identifier into ICMPv6. The first problem is to
*see* which interface the packet arrived via. RFC5837 does help with
it. The second issue is that we are losing the ability to control the
path of the packet and specify which interface the traceroute/ping
packet should arrive on. It is especially useful for packet loss
troubleshooting. Would it be possible to clarify that RFC5837 provided
only partical solution?
7) 2.3. Caveats
"
Hardware dependency:.....
LLAs can
be statically configured such as fe80::1 and fe80::2 which can be
used to configure any required static routing neighborship. This
static configuration is similar in complexity to statically
configured greater than link-local addresses"
[comment] I'd say that the complexity is higher as such approach
introduces an additional complexity in monitoring/troubleshooting.
Such configuration results in situation when an operator has to deal
with messages like 'BGP neighbor fe80::1%ae1 is down' which might be
confusing and requires additional efforts to identify neighbors. This
also applies to the next paragraph about NMS toolkit: an operator
needs to ensure that NMS and other tools support link-local addresses
not just for router interfaces but for protocol configuration (such as
BGP peers etc).
8) 2.4. Internet Exchange Points
[comment] It would be great to see two subsection discussing
advantages and caveats like it is done above.
Typos found:
1)
1. Introduction
s/OPSF/OSPF/
2)
2.3. Caveats
s/implementions/implementations/
--
SY, Jen Linkova aka Furry
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
