Hello Jen Thanks for your interest for our I-D and even more thanks for your valuable comments.
1) accepted 2) point taken for redirect message & use of loopback address being implementation dependent, we have modified this section 3) Control plane protocols, we now use 'Most control plane protocols' as RSVP is an exception ;-) 4) Same as 2) indeed 5) added that the order of advantage has no significance and added the 'Simpler address management' as suggestion (thanks) 6) good catch, traceroute text has been changed 7) static LLA configuration text has been modified 8) IXP, we preferred not to call out advantages and caveats as they previous ones also apply to IXP Again big thanks -éric > -----Original Message----- > From: Jen Linkova [mailto:furr...@gmail.com] > Sent: jeudi 14 novembre 2013 18:23 > To: opsec WG; Eric Vyncke (evyncke); Michael Behringer (mbehring) > Subject: comments on draft-ietf-opsec-lla-only-04 > > 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 OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
