Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop
draft-ietf-bess-rfc5549revision-06

[[ 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"

[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.

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...

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

(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

I agree with Murray’s DISCUSS and Warren’s comment.

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.