Ballot for draft-ietf-intarea-v4-via-v6
Discuss
Yes
No Objection
No Record
Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
# Gunter Van de Velde, RTG AD, comments for draft-ietf-intarea-v4-via-v6-08 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-intarea-v4-via-v6-08.txt # Many thanks RTGDIR review from Emmanuel Baccelli # This draft reads well and i support this work. Thank you for this write up. # In this ballot you'll find few discuss observations, which i believe will be easy to resolve through discussion or by consideration in the document. # DISCUSS # ======= # [DISCUSS#1] # This is a request for clarification of we are talking about 'routing' or 'forwarding' there is a subtle difference between the two. (see comments section) # [DISCUSS#2] # To transport IPv4 over an ipv6 interface, the correct encoding for ipv4 (for example ethertype 0x86DD vs 0x0800) must be enabled on such interfaces to avoid encap error (see comments section). # [DISCUSS#3] # As Ketan flagged in his review, the IGP examples provided are not fully accuratly documented. See comments for extra info and suggestions. # [DISCUSS#4] # pMTU is a procedure to find the maximum packet size of a path, not for a route. A route has no concept of maximum supported packet size (it just points to the next hop independent from supported MTU), however a path may have MTU awareness.
# COMMENTS # ======== 15 V4-via-v6 routing is a technique that uses IPv6 next-hop addresses 16 for routing IPv4 packets, and thus makes it possible to route IPv4 17 packets across a network where some routers have not been assigned 18 IPv4 addresses. This document describes v4-via-v6 routing, and 19 defines related operational procedures, notably the origination of 20 ICMPv4 packets by nodes that might not have an IPv4 address. GV> [DISCUSS#1] When i was reading the abstract i was wondering if the procedures are not more for forwarding instead of routing and should maybe be named v4-via-v6 forwarding? The mindmap i have between the two terms is: * Routing = deciding where traffic should go * Forwarding = actually sending the packet out the correct interface. Looking at this terms, maybe the word Routing was selected inappropriately? 111 forward packets. The routing table is a data structure that maps 112 network prefixes in a given family (IPv4 or IPv6) to next hops, pairs 113 of an outgoing interface and a neighbor's network address, for 114 example: GV> [DISCUSS#2] in addition there is information in the routing table on how to encapsulate the packet towards the next hop. IPv4 ethertype is 0x0800 while IPv6 ethertype is 0x86DD. Having mismatch between frame ipv4/ipv6 payload and supported ethertypes causes encapsulation failures and forwarding breaks. 238 * Multi-Topology (MT) Routing in OSPF ([RFC4915]) 239 240 * Multi-Topology (MT) Routing in IS-IS ([RFC5120]) GV> [DISCUSS#3] Ketan pointed this out already in his review that ospfv2 is IPv4 only, while OSPFv3 is the protocol that support IPv6 or IPv4 (RFC5838) Instance ID # 0 - # 31 IPv6 unicast AF Instance ID # 32 - # 63 IPv6 multicast AF Instance ID # 64 - # 95 IPv4 unicast AF Instance ID # 96 - # 127 IPv4 multicast AF Instance ID # 128 - # 255 Unassigned GV> [DISCUSS#3] ISIS supports in base topology (rfc5308) both unicast v4 and unicast v6 on a congruent topology where all links and nodes support both v4 and v6. What MT-ISIS introduces is for example MT#2 and allows v4 and v6 unicast topologies to be different from each other (for example when a single link link would only support v4 and no v6 or only supports v6 and no v4). - MT ID #0: Equivalent to the "standard" topology. - MT ID #1: Reserved for IPv4 in-band management purposes. - MT ID #2: Reserved for IPv6 routing topology. - MT ID #3: Reserved for IPv4 multicast routing topology. - MT ID #4: Reserved for IPv6 multicast routing topology. - MT ID #5: Reserved for IPv6 in-band management purposes. - MT ID #6-#3995: Reserved for IETF consensus. - MT ID #3996-#4095: Reserved for development, experimental and proprietary features [RFC3692]. 247 The Internet Control Message Protocol (ICMPv4, or simply ICMP) 248 [RFC0792] is a protocol related to IPv4 that is primarily used to GV> when looking at RFC792 there is no entry of ICMPv4 but there are 33 instances of ICMP. Does 'ICMPv4' formally exist? I understand that the intent is to make it more obvious that it is for IPv4, but from my reading of rfc792 it is called icmp and not icmpv4 256 by intermediate routers. Most notably, path MTU Discovery (PMTUd) 257 [RFC1191] is an algorithm executed by end hosts to discover the 258 maximum packet size that a route is able to carry. While there exist GV> [DISCUSS#4] Could it be that the terminology between path and route is confused? s/that a route/that a path/ . The route is simply a table construct and is not aware of MTU at all. A route points to a next hop without taking MTU in consideration. 275 assigned. If a router does not have any IPv4 addresses assigned, the 276 router MUST use the dummy address 192.0.0.8 as the source address of 277 outgoing ICMPv4 packets (which is compatible with [RFC7600], 278 Section 4.8, Requirement R-22). GV> I suspect that the above procedure is intentionally undefined when a router has a loopback/system interface configured with an IPv4 address but is not used as router-id or not used as reference for unnumbered interfaces? in such situation something more meaningful as the dummy address may be used as src address. Was there a reason this is not considered in the text? 291 For these reasons, even if a router performs v4-via-v6 routing on all 292 interfaces, it MAY be assigned one or more IPv4 addresses. GV> why use routable IPv4 addresses? would valid 32 bit router-id's not be sufficient to identify the router that originated the response? 405 hopefully simplify the management of double-stack networks. Since it GV> Commonly i see instead of "double-stack" networks in literature the term "dual-stack" more often used. It is not wrong, just unusual for me to see. Many thanks for this quality write-up, Kind Regards, Gunter Van de Velde Routing AD
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?
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.
Section 4, paragraph 3 > Routers implementing the mechanism described in this document do not > need to have any IPv4 addresses assigned to any of their interfaces, > and [RFC1812] does not specify what happens if no router-id has been > assigned. If a router does not have any IPv4 addresses assigned, the > router MUST use the dummy address 192.0.0.8 as the source address of > outgoing ICMPv4 packets (which is compatible with [RFC7600], > Section 4.8, Requirement R-22). RFC7600 was downgraded from normative to informative to avoid the Experimental-under-Standards-Track downref problem. However, the normative dependency on that address allocation was not resolved by making the reference informative. A Standards Track document that issues a MUST requirement using a specific address must normatively ground that address choice. The options are: - Make RFC7600 normative and add it to the DOWNREF registry (per the shepherd writeup's earlier observation), or - Add an IANA Considerations request to formally register 192.0.0.8 in the IANA Special-Purpose Address Registry for this use (if it is not already registered for this specific purpose independently of RFC7600).
Section 1, paragraph 5
> A route towards an IPv4 prefix that uses an IPv6 next hop is called a
> "v4-via-v6" route. While v4-via-v6 routing is applicable both to
> hosts and to routers, this document focuses on its implementation in
> routers. Applying v4-via-v6 routing to hosts will require solving
> the issue of host configuration, for example by extending either
> DHCPv4 or DHCPv6 to publish an IPv4 default route with an IPv6 next
> hop.
The author agreed in response to the GenART review by Linda Dunbar
(thanks, Linda) that "rewording the introduction should be enough."
That reword has not yet appeared in -08. The GenART concern stands:
either remove the claim of host applicability or explicitly defer
it to future work with a sentence identifying the open problem
(host configuration via DHCPv4/DHCPv6 extension). The RTGDIR reviewer
(Emmanuel Baccelli, thanks Emmanuel) also recommended more careful treatment of
this applicability boundary.
Section 3.2, paragraph 1
> With v4-via-v6 routing, the address family of the next-hop address is
> no longer determined by the address family of the prefix: since the
> routing table may map an IPv4 prefix to either an IPv4 or an IPv6
> next hop, the forwarding plane must be able to determine, on a per-
> packet basis, which address resolution protocol (ARP for IPv4, ND for
> IPv6) to consult.
The last sentence frames next-hop address resolution exclusively in
terms of ARP (IPv4) and ND (IPv6). These are Ethernet/IEEE 802 protocols.
The document does not address how v4-via-v6 forwarding operates on
non-Ethernet links (e.g., point-to-point links, MPLS, GRE) where neither
ARP nor ND is applicable. A sentence noting that on such links, address
resolution is link-type-specific (or is not needed) would bound the
scope appropriately.
Section 6, paragraph 1
> Just like any other extension to an existing technology, however, it
> requires changes to existing infrastructure. Even though v4-via-v6
> routes are similar in structure to traditional next-hop routes, at
> least some monitoring and management tools will not be able to
> interpret them. Deployment of v4-via-v6 routing in a network
> requires testing and potentially updating of all tools and scripts
> that manipulate or examine routes.
Thomas Graf, in his OPSDIR review (thanks Thomas), suggested some
additional text here. I also know the authors in their response
argued that a generic statement ("requires testing and potentially
updating of all tools and scripts") is sufficient. That text is generic
and does not give an operator actionable guidance on a specific and
foreseeable gap. A single sentence noting that flow monitoring exports
will require template updates to accommodate IPv6 next-hop information
elements would be concrete without being prescriptive.
No reference entries found for these items, which were mentioned in the text:
[draft-chroboczek-intarea-v4-via-v6] and [draft-ietf-babel-v4viav6].
Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:
* Term "dummy"; alternatives might be "placeholder", "sample", "stand-in",
"substitute"
* Term "traditional"; alternatives might be "classic", "classical", "common",
"conventional", "customary", "fixed", "habitual", "historic",
"long-established", "popular", "prescribed", "regular", "rooted",
"time-honored", "universal", "widely used", "widespread"
Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges:
"fe80::1234:5678", "fe80::201:5cff:feb2:1646", "10.0.0.2/32", "192.0.0.8",
"2:16:3e:ff:fe:9a:5e:22", "0.0.0.0/0", "10.0.0.2", "192.168.0.27", and
"fe80::216:3eff:fe00:1".
Hi Juliusz, Warren, and Toke, Thank you for the effort put into this document. This is useful piece of work, hence my YES. Thanks Thomas Graf for the OPSDIR review and the authors for engaging. I think that proving the informative examples provided (IPFIX, …) by Thomas good additions to the document. Please find below some comments: # From where I sit, I think that the forwarding behavior (and ICMP part, in particular) is the main technical contribution, not much the narrative part about routing. # It is about forwarding, not routing There are several places in the document that mix routing and forwarding. For example, OLD: that uses IPv6 next-hop addresses for routing IPv4 packets… NEW: that uses IPv6 next-hop addresses for forwarding IPv4 packets… OLD: When a packet is routed according to a given routing table NEW: When a packet is forwarded according to a given routing table OLD: preventing an IPv6 packet from being routed through a next NEW: preventing an IPv6 packet from being forwarded through a next OLD: routing makes it easy to route IPv4 traffic across interfaces NEW: routing makes it easy to forward IPv4 traffic across interfaces And several other places. Please check all uses through the document. I trust the responsible AD to help with that check. # I found it odd that we don’t have any mention of FIBs. Please refer, for example, to RFC1812 about how it reasons for selecting next-hop RFC1812 has also the following, which can be imported here or referred to: Forwarding Information Base (FIB) The table containing the information necessary to forward IP Datagrams, in this document, is called the Forwarding Information Base. At minimum, this contains the interface identifier and next hop information for each reachable destination network prefix. # Manual configuration argument is marginal, IMO: Automation is in place in many operations to handle such provisioning CURRENT: assigned IP addresses of either family, which significantly reduces the amount of manual configuration required. # Independent of routing protocols CURRENT: This document, on the other hand, discusses the concept of v4-via-v6 routes independently of any specific routing protocol, The statement is correct, but I think that this can be even expanded to say that the forwarding behavior described in the document does not even assume or require that a dynamic routing protocol is in place. # Restrictive assumption: forwarders can be deployed without routing engines (e.g., centralized routing) CURRENT: The forwarding plane is the part of the routing implementation that is executed for every forwarded packet. Statements such as the above assume that there is co-location of routing and forwarding engines for the mechanism to work. I don’t this is required. Is that on purpose? If so, why? # Compliant with RFC1812 OLD: The forwarding plane is the part of the routing implementation that is executed for every forwarded packet. The packet may or may not be forwarded as a result of the forwarding process. I appreciate this is being picky, but RFC1812 says: Forwarding Forwarding is the process a router goes through for each packet received by the router. The packet may be consumed by the router, it may be output on one or more interfaces of the router, or both. Forwarding includes the process of deciding what to do with the packet as well as queuing it up for (possible) output or internal consumption. I suggest: NEW: The forwarding plane is the part of the routing implementation that is executed for every packet to be forwarded. # Section 3.3: I would also add centralized routing + programmatic means to populate the FIBs # I don’t think that we need to the first 2 paragraphs in Section 4. # Same address 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. RFC6791 which uses such IPv4 addresses but for a distinct purpose. That RFC includes the following reco: If a pool of public IPv4 addresses is configured on the translator, it is RECOMMENDED to randomly select the IPv4 source address from the pool. Random selection reduces the probability that two ICMP messages elicited by the same TRACEROUTE might specify the same source address and, therefore, erroneously present the appearance of a routing loop. Should we have a similar one here when more IPv4 addresses are configured? # Accelerate the deployment of IPv6: Speculative CURRENT: Since it promises IPv4 routing essentially "for free" once IPv6 addressing has been set up, it has the potential to slightly accelerate the deployment of IPv6. The “accelerate the IPv6 deployment” is operationally more subtle than. To be balanced, as a popular tool that is widely used is 6PE..depends on IPv4. I think that the point about you made in the previous sentence about dual stack is sufficient. I think that we can simply delete the sentence about accelerating deployment as that is speculative. # More Operational Considerations Please consider some brief text for need to have means for routers to expose and for operator to retrieve the capabilities of underlying routers with regards to v4-via-v6 forwarding. This is helpful for operator to maintain a network view of its networks, especilally when bootstrapping new nodes. Cheers, Med
Thanks to the authors for this very interesting and very well-written document. Also, thanks to Barry Leiba for the ARTART review.
Thanks to Barry Leiba for the ARTART review and to the authors for their clarifying response.
Thanks to Karen O for the SECDIR review, spot on.
Thanks to Karen O'Donoghue for their secdir review.
Thank you for the work that has been put into this document.I think this is useful work, and it does seem great to document. I do have some COMMENTS (non-blocking), but would be pleased to hear your response to these: (1) I expect some of the text ought to be about forwarding rather than routing? - I see Med made many comments, I support this question (but have removed duplicate comments - since I assume these will be resolved one way or another in response to his comments). (2) Current text: there is nothing preventing an IPv6 packet from being routed through a next hop with an IPv4 address (in which case the next hop's MAC address will be obtained using ARP), or, conversely, an IPv4 packet from being routed through a next hop with an IPv6 address. - This text seems to detail IPv4, but not the same level of detail for the IPv6 case. This ought also to mention how that uses ND and other methods, to complete the equivalent to arp? (3) I'd encourage adding a reference for RFC 8899, alongside the existing referene to RFC 4821. (4) The text currently says: "PMTUd may lead to persistent black-holing of IPv4 traffic." - But not if using RFC 8899? (e.g., as in QUIC). (Altghough I agree this would still be "useful" to have the ICMP PTB message delivered even when using RFC 8899.) (5) Perhaps obvious to some, but to forward IPv6 packets there must be an IPv4 interface MTU of at least 1280 bytes (the minimum for IPv6): Could something be said? (6) I am curiuous whether thought was given to multicast routing, or whether that was out-of-scope, either way, I expected something to be said. NiT: There was one use of /don't/ - is it worh making this /do not/? best wishes, Gorry Fairhurst
Thanks for documenting this hopefully-useful configuration. I have only one minor COMMENT and a few nits: In Section 1, ND and ARP are given as examples of neighbor discovery protocols; in Section 3.2, they are given as examples of address resolution protocols. Are the terms equivalent? If so, where is that stated? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Grammar/style #### "Abstract", paragraph 4 ``` ace on the Internet Area Working Group Working Group mailing list (mailto:int ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This phrase is duplicated. You should probably use "Working Group" only once. [PHRASE_REPETITION] #### Section 5, paragraph 1 ``` ocument is heavily based on RFC9229 (nee draft-ietf-babel-v4viav6), and this ^^^ ``` Did you mean the adjective "née" (= formerly called), the verb "need" or the adjective "new"? [NEE] #### Section 6, paragraph 1 ``` han it would otherwise be (see Section Section 4). Even if the procedures de ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. [ENGLISH_WORD_REPEAT_RULE]
Thank you to Linda Dunbar for the GENART review.