Ketan Talaulikar has entered the following ballot position for draft-ietf-intarea-v4-via-v6-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-intarea-v4-via-v6/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document that describes "IPv4 via IPv6" forwarding/routing that is supported by multiple implementations. I am very supportive of this work and there are a few aspects that I would like to discuss. <discuss-1> The document does not touch upon two "knobs" that implementations might need to support. I will base this on the MIB-2 extensions in RFC4293 for lack of my ability to find a better reference - the scalar "ipForwarding" and the per-interface "ipv4InterfaceEnableStatus". Even on a device without any IPv4 address, I would expect that the equivalent of these two knobs are required to be enabled for this feature to work? Although the scalar seems redundant for a router implementation, I am wondering if implementations will accept and forward IPv4 packets arriving on an interface that is not enabled for IPv4 forwarding. I wanted to check if this aspect needs to be discussed or covered in this document. I didn't look into the WG deliberations to check if this was already discussed. <discuss-2> OSPFv2 only supports IPv4 (although some very minimal work was done to make it also work for IPv6 - not fully specified). OSPFv3 was for IPv6 and was later extended to also support IPv4 by RFC5838 using multi-instance. My guess was that the document intended to reference RFC5838 and not multi-topology. OSPFv2 MT (RFC4915) does not support IPv6. <discuss-3> Please consider covering link types other than Ethernet (e.g., Wifi?) and even point-to-point links. The PTP link brings other aspects of ND operations over links that don't have MAC addresses. Were these aspects discussed by the WG for covering in this document? <discuss-4> The document uses the term "routing table" to cover both the RIB and FIB. Conceptually, this is OK. However, someone reading the document could literally consider the routing table to be referring to the RIB. Could you consider clarifying that "routing table" term used here is conceptual and implementations may have it organized as RIB and FIB? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also have some comments and suggestions to offer for your consideration. 1) Can you consider removing "(In fact, it is even possible to store link-layer addresses directly in the next-hop entry of the routing table, thus avoiding the use of an address resolution protocol altogether, which was commonly done in networks using the OSI protocol suite.)"? Instead please see <discuss-2> and many implementations perform optimization by storing MAC with NH in their FIB entries. Then, there is also static stuff. But do we need to refer to OSI for it? :-) 2) I would have expected the following MAY to be SHOULD (i.e., at least have one IPv4 address on the router) for supporting ICMPv4 instead of the current "For these reasons, even if a router performs v4-via-v6 routing on all interfaces, it MAY be assigned one or more IPv4 addresses." ? As in, if this is not done then ICMPv4 does not work well. _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
