Gunter Van de Velde 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: ---------------------------------------------------------------------- # 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # 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 _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
