Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop
Note: This ballot was opened for revision 04 and is now closed.
Martin Vigoureux Yes
Deborah Brungard No Objection
Alissa Cooper No Objection
Roman Danyliw No Objection
Martin Duke No Objection
Benjamin Kaduk No Objection
Comment (2020-08-24 for -04)
The IANA Considerations need to be updated to reflect that this is a "bis" of 5549, and is not making the allocation de novo. I.e., it should be "update the reference for the existing registration". RFC 5549 says that the "Length of Next Hop Address" field for AFI/SAFI 1/128 is "16 or 32", but this document says that it is "24 or 48", which has no overlap. Is this a breaking change? Ah, I guess this is essentially errata report 5253 (https://www.rfc-editor.org/errata/eid5253). I'd suggest that we note that this update includes addressing that errata report. I would also suggest a brief note that the main nature of the update is to add support for AFI/SAFI 1/129 (as that seems to be the bulk of the diff between RFC 5549 and this document); I believe Alvaro has asked for something similar as well. Other than that, just a few very minor comments for your consideration (and for which no reply is necessary). Section 1 There are situations such as those described in [RFC4925] and in [RFC5565] where carriers (or large enterprise networks acting as nit: the transition into this paragraph is a bit abrupt, wth the previous paragraphs talking about existing AFI/SAFIs that already are flexible about IPv4 vs IPv6 based on length, but now we're back into describing a problem statement for which the solution looks quite similar. Section 4 I'm happy to see that the format of the Capability Value field explicitly indicates the NLRI AFI/SAFI and nexthop AFI triples supported, so there is no deployability concern about using the same capability code value to indicate support for new SAFI types. Section 5 When a next hop address needs to be passed along unchanged (e.g., as a Route Reflector (RR) would do), its encoding MUST NOT be changed. If a particular RR client cannot handle that encoding (as determined by the BGP Capability Advertisement), then the NLRI in question cannot be distributed to that client. For sound routing in certain scenarios, this will require that all the RR clients be able to handle whatever encodings any of them may generate. This is good advice; I wonder if it is worth a brief mention in the security considerations as well. Section 10.1 In my reading, the places where we reference RFC 4291 do not require it to be a normative reference. Section 10.2 I agree with Alvaro about draft-ietf-idr-dynamic-cap.
Erik Kline No Objection
Comment (2020-08-16 for -04)
[[ comments ]] [ section 3 ] * Perhaps "8-octet RD is set to zero" -> "8-octet RD set to zero" [ section 4 ] * Perhaps "for which there is already solution" -> "for which there is already a solution" * "from the onset" -> "from the outset", I think [ section 6.2 ] * "IPV4" -> "IPv4" [ section 6.3 ] * "IPV4" -> "IPv4"
Murray Kucherawy (was Discuss) No Objection
[DISCUSS cleared] Thanks for this document. It was easy to read even for people like me who don't get involved in routing too much. Thank you also for the shepherd writeup, which (unlike most lately) actually answered the question "Why is this the proper type of RFC?" I also concur with Warren's suggestion.
Warren Kumari No Objection
Comment (2020-08-26 for -04)
I found this document really hard to review - not because the document itself was unclear, but rather because I had to keep going back and forth between it and RFC5549. Passing it though 'diff' helped some, but a few sentences explaining the differences would have helped immensely; it would also help RFC5549 implementers understand what they need to change to be compliant...
Barry Leiba No Objection
Comment (2020-08-26 for -04)
I agree with Murray’s DISCUSS and Warren’s comment.
Alvaro Retana No Objection
Comment (2020-08-24 for -04)
(1) Security Considerations The use of an IPv6 Next Hop opens up the possibility of diverting the traffic: there is no provision in this draft, or rfc2545, to validate or somehow verify that the address is "correct". IOW, a rogue BGP speaker may use a Next Hop address to redirect the traffic elsewhere. Traffic diversion is a known vulnerability, but I would still like to see something in this document about it. Suggestion (borrowing from draft-ietf-idr-tunnel-encaps)> As [RFC4272] discusses, BGP is vulnerable to traffic diversion attacks. The ability to advertise an IPv6 Next Hop adds a new means by which an attacker could cause traffic to be diverted from its normal path. Such an attack differs from pre-existing vulnerabilities in that traffic could be forwarded to a distant target across an intervening network infrastructure (e.g. an IPv6 core), allowing an attack to potentially succeed more easily, since less infrastructure would have to be subverted. Potential consequences include "hijacking" of traffic or denial of service. (2) §4: The Extended Next Hop Encoding capability MAY be dynamically updated through the use of the Dynamic Capability capability and associated mechanisms defined in [I-D.ietf-idr-dynamic-cap]. This text creates a Normative dependence on I-D.ietf-idr-dynamic-cap. However, that document expired more than 8 years ago. Please remove this paragraph. (3) It would be very nice if a section summarizing the changes between this document and rfc5549 was included. (4) rfc5549 was written more than 10 years ago...what qualified then as "current" and "new" doesn't anymore. It would be nice to update some of that language. (5) [nits] s/IPV4/IPv4/g s/allows advertising with [RFC4760] of an MP_REACH_NLRI with/allows advertising the MP_REACH_NLRI attribute [RFC4760] with this content
Éric Vyncke No Objection
Comment (2020-08-27 for -04)
Thank you for the work put into this document. I share Warren Kumari's point about the readability of the text. About the lack of the 'bis' delta. I had to use https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-rfc5549revision-04.txt&url1=https://tools.ietf.org/rfc/rfc5549.txt to see them :-) OTOH, it is easier for a new implementation to simply read the 'bis' document without going back and forth between the obsolete document and apply the diff. -éric