draft-ietf-babel-v4viav6-01.txt   draft-ietf-babel-v4viav6-02.txt 
Network Working Group J. Chroboczek Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris Internet-Draft IRIF, University of Paris
Updates: 8966 (if approved) 9 April 2021 Updates: 8966 (if approved) 13 April 2021
Intended status: Experimental Intended status: Standards Track
Expires: 11 October 2021 Expires: 15 October 2021
IPv4 routes with an IPv6 next-hop in the Babel routing protocol IPv4 routes with an IPv6 next-hop in the Babel routing protocol
draft-ietf-babel-v4viav6-01 draft-ietf-babel-v4viav6-02
Abstract Abstract
This document defines an extension to the Babel routing protocol that This document defines an extension to the Babel routing protocol that
allows annoncing routes to an IPv4 prefix with an IPv6 next-hop, allows annoncing routes to an IPv4 prefix with an IPv6 next-hop,
which makes it possible for IPv4 traffic to flow through interfaces which makes it possible for IPv4 traffic to flow through interfaces
that have not been assigned an IPv4 address. that have not been assigned an IPv4 address.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 October 2021. This Internet-Draft will expire on 15 October 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 5, line 19 skipping to change at page 5, line 19
2.4. Other TLVs 2.4. Other TLVs
The only other TLVs defined by [RFC8966] that carry an AE field are The only other TLVs defined by [RFC8966] that carry an AE field are
Next-Hop and TLV. Next-Hop and IHU TLVs MUST NOT carry the AE TBD Next-Hop and TLV. Next-Hop and IHU TLVs MUST NOT carry the AE TBD
(v4-via-v6). (v4-via-v6).
3. ICMPv4 and PMTU discovery 3. ICMPv4 and PMTU discovery
The Internet Control Message Protocol (ICMPv4, or simply ICMP) The Internet Control Message Protocol (ICMPv4, or simply ICMP)
[RFC792] is a protocol related to IPv4 that carries diagnostic and [RFC792] is a protocol related to IPv4 that is primarily used to
debugging information. ICMPv4 packets may be originated by end hosts carry diagnostic and debugging information. ICMPv4 packets may be
(e.g., the "destination unreachable, port unreachable" ICMPv4 originated by end hosts (e.g., the "destination unreachable, port
packet), but they may also be originated by intermediate routers unreachable" ICMPv4 packet), but they may also be originated by
(e.g., most other kinds of "destination unreachable" packets). intermediate routers (e.g., most other kinds of "destination
unreachable" packets).
Path MTU Discovery (PMTUd) [RFC1191] is an algorithm executed by end Some protocols deployed in the Internet rely on ICMPv4 packets sent
hosts to discover the maximum packet size that a route is able to by intermediate routers. Most notably, path MTU Discovery (PMTUd)
carry. While there exist variants of PMTUd that are purely end-to- [RFC1191] is an algorithm executed by end hosts to discover the
end [RFC4821], the variant most commonly deployed in the Internet has maximum packet size that a route is able to carry. While there exist
a hard dependency on ICMPv4 packets originated by intermediate variants of PMTUd that are purely end-to-end [RFC4821], the variant
routers: if intermediate routers are unable to send ICMPv4 packets, most commonly deployed in the Internet has a hard dependency on
PMTUd may lead to persistent blackholing of IPv4 traffic. ICMPv4 packets originated by intermediate routers: if intermediate
routers are unable to send ICMPv4 packets, PMTUd may lead to
persistent blackholing of IPv4 traffic.
For that reason, every Babel router that is able to forward IPv4 Due to this dependency, every Babel router that is able to forward
traffic MUST be able originate ICMPv4 traffic. Since the extension IPv4 traffic MUST be able originate ICMPv4 traffic. Since the
described in this document enables routers to forward IPv4 traffic extension described in this document enables routers to forward IPv4
even when they have not been assigned an IPv4 address, a router traffic received over an interface that has not been assigned an IPv4
implementing this extension MUST be able to originate ICMPv4 packets address, a router implementing this extension MUST be able to
even when it has not been assigned an IPv4 address. originate ICMPv4 packets, even when the outgoing interface has not
been assigned an IPv4 address.
There are various ways to meet this requirement, and choosing between There are various ways to meet this requirement, and choosing between
them is left to the implementation. For example, if a router has an them is left to the implementation. For example, if a router has an
interface that has been assigned an IPv4 address, or if it has an interface that has been assigned an IPv4 address, or if an IPv4
IPv4 address that has been assigned to the router itself (to the address has been assigned to the router itself (to the "loopback
"loopback interface"), then that IPv4 address may be "borrowed" to interface"), then that IPv4 address may be "borrowed" to serve as the
serve as the source of originated ICMPv4 packets. If no IPv4 address source of originated ICMPv4 packets. If no IPv4 address is
is available, a router may use a dummy IPv4 address as the source of available, a router may use a dummy IPv4 address as the source of
outgoing ICMPv4 packets, for example an address taken from a private outgoing ICMPv4 packets, for example an address taken from a private
address range [RFC1918] that is known to not be used in the local address range [RFC1918] that is known to not be used in the local
routing domain. Note however that using the same address on multiple routing domain (either dynamically chosen, for example drawn randomly
routers may hamper debugging and fault isolation. or derived algorithmically from an IPv6 address, or statically
configured). Note however that using the same address on multiple
routers may hamper debugging and fault isolation, e.g., when using
the "traceroute" utility.
4. Backwards compatibility 4. Backwards compatibility
This protocol extension adds no new TLVs or sub-TLVs. This protocol extension adds no new TLVs or sub-TLVs.
This protocol extension uses a new AE. As discussed in Appendix D of This protocol extension uses a new AE. As discussed in Appendix D of
[RFC8966] and specified in the same document, implementations that do [RFC8966] and specified in the same document, implementations that do
not understand the present extension will silently ignore the various not understand the present extension will silently ignore the various
TLVs that use this new AE. As a result, incompatible versions will TLVs that use this new AE. As a result, incompatible versions will
ignore v4-via-v6 routes. They will also ignore requests with AE TBD, ignore v4-via-v6 routes. They will also ignore requests with AE TBD,
skipping to change at page 8, line 28 skipping to change at page 8, line 36
assumption is broken if the intermediary routers implement the assumption is broken if the intermediary routers implement the
extension described in this document, which might expose the extension described in this document, which might expose the
IPv4-only hosts to traffic from the IPv4 Internet. If this is IPv4-only hosts to traffic from the IPv4 Internet. If this is
undesirable, the flow of IPv4 traffic must be restricted by the use undesirable, the flow of IPv4 traffic must be restricted by the use
of suitable filtering rules (Appendix C of [RFC8966]) together with of suitable filtering rules (Appendix C of [RFC8966]) together with
matching packet filters in the data plane. matching packet filters in the data plane.
8. Acknowledgments 8. Acknowledgments
This protocol extension was originally designed, described and This protocol extension was originally designed, described and
implemented in collaboration with Theophile Bastian. The author is implemented in collaboration with Theophile Bastian. Margaret Cullen
also indebted to Margaret Cullen, who pointed out the issues with pointed out the issues with ICMP and helped coin the phrase "v4-via-
ICMP and helped coin the expression "V4-via-V6". v6". The author is also indebted to Donald Eastlake, Toke Hoiland-
Jorgensen, and David Schinazi.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
 End of changes. 9 change blocks. 
33 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/