rfc9229v2.txt   rfc9229.txt 
Internet Engineering Task Force (IETF) J. Chroboczek Internet Engineering Task Force (IETF) J. Chroboczek
Request for Comments: 9229 IRIF, University of Paris Request for Comments: 9229 IRIF, University of Paris
Category: Experimental April 2022 Category: Experimental May 2022
ISSN: 2070-1721 ISSN: 2070-1721
IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol
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 announcing routes to an IPv4 prefix with an IPv6 next hop, allows announcing 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.
skipping to change at line 65 skipping to change at line 65
2.2. Receiving v4-via-v6 Routes 2.2. Receiving v4-via-v6 Routes
2.3. Route and Seqno Requests 2.3. Route and Seqno Requests
2.4. Other TLVs 2.4. Other TLVs
3. ICMPv4 and PMTU Discovery 3. ICMPv4 and PMTU Discovery
4. Protocol Encoding 4. Protocol Encoding
4.1. Prefix Encoding 4.1. Prefix Encoding
4.2. Changes to Existing TLVs 4.2. Changes to Existing TLVs
5. Backwards Compatibility 5. Backwards Compatibility
6. IANA Considerations 6. IANA Considerations
7. Security Considerations 7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments Acknowledgments
References
Normative References
Informative References
Author's Address Author's Address
1. Introduction 1. Introduction
The role of a routing protocol is to build a routing table, a data The role of a routing protocol is to build a routing table, a data
structure that maps network prefixes in a given family (IPv4 or IPv6) structure that maps network prefixes in a given family (IPv4 or IPv6)
to next hops, which are (at least conceptually) pairs of an outgoing to next hops, which are (at least conceptually) pairs of an outgoing
interface and a neighbour's network address. For example: interface and a neighbour's network address. For example:
destination next hop destination next hop
skipping to change at line 377 skipping to change at line 377
IPv4 Internet by routers that have not been assigned IPv4 addresses, IPv4 Internet by routers that have not been assigned IPv4 addresses,
a network administrator might reasonably assume that the IPv4-only a network administrator might reasonably assume that the IPv4-only
hosts are unreachable from the IPv4 Internet. This assumption is hosts are unreachable from the IPv4 Internet. This assumption is
broken if the intermediary routers implement the extension described broken if the intermediary routers implement the extension described
in this document, which might expose the IPv4-only hosts to traffic in this document, which might expose the IPv4-only hosts to traffic
from the IPv4 Internet. If this is undesirable, the flow of IPv4 from the IPv4 Internet. If this is undesirable, the flow of IPv4
traffic must be restricted by the use of suitable filtering rules traffic must be restricted by the use of suitable filtering rules
(see Appendix C of [RFC8966]) together with matching packet filters (see Appendix C of [RFC8966]) together with matching packet filters
in the data plane. in the data plane.
Acknowledgments 8. References
This protocol extension was originally designed, described, and
implemented in collaboration with Theophile Bastian. Margaret Cullen
pointed out the issues with ICMP and helped coin the phrase "v4-via-
v6". The author is also indebted to Donald Eastlake, Toke Høiland-
Jørgensen, David Schinazi, and Donald Sharp.
References
Normative References 8.1. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[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/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021, Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
<https://www.rfc-editor.org/info/rfc8966>. <https://www.rfc-editor.org/info/rfc8966>.
Informative References 8.2. Informative References
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>. <https://www.rfc-editor.org/info/rfc826>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
skipping to change at line 442 skipping to change at line 434
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014, DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>. <https://www.rfc-editor.org/info/rfc7404>.
[RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G., [RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G.,
and M. Chen, "IPv4 Residual Deployment via IPv6 - A and M. Chen, "IPv4 Residual Deployment via IPv6 - A
Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600, Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600,
July 2015, <https://www.rfc-editor.org/info/rfc7600>. July 2015, <https://www.rfc-editor.org/info/rfc7600>.
Acknowledgments
This protocol extension was originally designed, described, and
implemented in collaboration with Theophile Bastian. Margaret Cullen
pointed out the issues with ICMP and helped coin the phrase "v4-via-
v6". The author is also indebted to Donald Eastlake, Toke Høiland-
Jørgensen, David Schinazi, and Donald Sharp.
Author's Address Author's Address
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris IRIF, University of Paris
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
 End of changes. 7 change blocks. 
15 lines changed or deleted 15 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/