Mahesh Jethanandani 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: ---------------------------------------------------------------------- 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). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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". _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
