draft-ietf-babel-v4viav6-02.txt   draft-ietf-babel-v4viav6-03.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) 13 April 2021 Updates: 8966 (if approved) 21 April 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 15 October 2021 Expires: 23 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-02 draft-ietf-babel-v4viav6-03
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 15 October 2021. This Internet-Draft will expire on 23 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 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. Protocol operation . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol operation . . . . . . . . . . . . . . . . . . . . . 3
2.1. Announcing v4-via-v6 routes . . . . . . . . . . . . . . . 3 2.1. Announcing v4-via-v6 routes . . . . . . . . . . . . . . . 3
2.2. Receiving v4-via-v6 routes . . . . . . . . . . . . . . . 4 2.2. Receiving v4-via-v6 routes . . . . . . . . . . . . . . . 4
2.3. Prefix and seqno requests . . . . . . . . . . . . . . . . 4 2.3. Prefix and seqno requests . . . . . . . . . . . . . . . . 4
2.4. Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 5
3. ICMPv4 and PMTU discovery . . . . . . . . . . . . . . . . . . 5 3. ICMPv4 and PMTU discovery . . . . . . . . . . . . . . . . . . 5
4. Backwards compatibility . . . . . . . . . . . . . . . . . . . 6 4. Protocol encoding . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol encoding . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Prefix encoding . . . . . . . . . . . . . . . . . . . . . 6
5.1. Prefix encoding . . . . . . . . . . . . . . . . . . . . . 6 4.2. Changes to existing TLVs . . . . . . . . . . . . . . . . 6
5.2. Changes for existing TLVs . . . . . . . . . . . . . . . . 7 5. Backwards compatibility . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
skipping to change at page 5, line 36 skipping to change at page 5, line 36
Some protocols deployed in the Internet rely on ICMPv4 packets sent Some protocols deployed in the Internet rely on ICMPv4 packets sent
by intermediate routers. Most notably, path MTU Discovery (PMTUd) by intermediate routers. Most notably, path MTU Discovery (PMTUd)
[RFC1191] is an algorithm executed by end hosts to discover the [RFC1191] is an algorithm executed by end hosts to discover the
maximum packet size that a route is able to carry. While there exist maximum packet size that a route is able to carry. While there exist
variants of PMTUd that are purely end-to-end [RFC4821], the variant variants of PMTUd that are purely end-to-end [RFC4821], the variant
most commonly deployed in the Internet has a hard dependency on most commonly deployed in the Internet has a hard dependency on
ICMPv4 packets originated by intermediate routers: if intermediate ICMPv4 packets originated by intermediate routers: if intermediate
routers are unable to send ICMPv4 packets, PMTUd may lead to routers are unable to send ICMPv4 packets, PMTUd may lead to
persistent blackholing of IPv4 traffic. persistent blackholing of IPv4 traffic.
Due to this dependency, every Babel router that is able to forward Due to this kind of dependency, every Babel router that is able to
IPv4 traffic MUST be able originate ICMPv4 traffic. Since the forward IPv4 traffic MUST be able originate ICMPv4 traffic. Since
extension described in this document enables routers to forward IPv4 the extension described in this document enables routers to forward
traffic received over an interface that has not been assigned an IPv4 IPv4 traffic received over an interface that has not been assigned an
address, a router implementing this extension MUST be able to IPv4 address, a router implementing this extension MUST be able to
originate ICMPv4 packets, even when the outgoing interface has not originate ICMPv4 packets even when the outgoing interface has not
been assigned an IPv4 address. 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 an IPv4 interface that has been assigned an IPv4 address, or if an IPv4
address has been assigned to the router itself (to the "loopback address has been assigned to the router itself (to the "loopback
interface"), then that IPv4 address may be "borrowed" to serve as the interface"), then that IPv4 address may be "borrowed" to serve as the
source of originated ICMPv4 packets. If no IPv4 address is source of originated ICMPv4 packets. If no IPv4 address is
available, a router may use a dummy IPv4 address as the source of available, a router may choose a source address from a prefix known
outgoing ICMPv4 packets, for example an address taken from a private to be unused, for example from a suitably chosen private address
address range [RFC1918] that is known to not be used in the local range [RFC1918]. If no more suitable address is available, then a
routing domain (either dynamically chosen, for example drawn randomly router MAY use the IPv4 dummy address 192.0.0.8 as the source address
or derived algorithmically from an IPv6 address, or statically of the IMCPv4 packets that it sends. Note however that using the
configured). Note however that using the same address on multiple same address on multiple routers may hamper debugging and fault
routers may hamper debugging and fault isolation, e.g., when using isolation, e.g., when using the "traceroute" utility.
the "traceroute" utility.
4. Backwards compatibility
This protocol extension adds no new TLVs or sub-TLVs.
This protocol extension uses a new AE. As discussed in Appendix D of
[RFC8966] and specified in the same document, implementations that do
not understand the present extension will silently ignore the various
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,
which, as stated in Section 2.3, are NOT RECOMMENDED.
Using a new AE introduces a new compression state, used to parse the
network prefixes. As this compression state is separate from other
AEs' states, it will not interfere with the compression state of
unextended nodes.
This extension reuses the next-hop state from AEs 2 and 3 (IPv6), but
makes no changes to the way it is updated, and therefore causes no
compatibility issues.
As mentioned in Section 2.1, ordinary IPv4 announcements are
preferred to v4-via-v6 announcements when the outgoing interface has
an assigned IPv4 address; doing otherwise would prevent routers that
do not implement this extension from learning the route being
announced.
5. Protocol encoding 4. Protocol encoding
This extension defines the v4-via-v6 AE, whose value is TBD. This AE This extension defines the v4-via-v6 AE, whose value is TBD. This AE
is solely used to tag network prefixes, and MUST NOT be used to tag is solely used to tag network prefixes, and MUST NOT be used to tag
peers' addresses, eg. in Next-Hop or IHU TLVs. peers' addresses, eg. in Next-Hop or IHU TLVs.
This extension defines no new TLVs or sub-TLVs. This extension defines no new TLVs or sub-TLVs.
5.1. Prefix encoding 4.1. Prefix encoding
Network prefixes tagged with AE TBD MUST be encoded and decoded as Network prefixes tagged with AE TBD MUST be encoded and decoded just
prefixes tagged with AE 1 (IPv4), as described in Section 4.3.1 of like prefixes tagged with AE 1 (IPv4), as described in Section 4.3.1
[RFC8966]. of [RFC8966].
A new compression state for AE TBD (v4-via-v6) distinct from that of A new compression state for AE TBD (v4-via-v6) distinct from that of
AE 1 (IPv4) is introduced, and MUST be used for address compression AE 1 (IPv4) is introduced, and MUST be used for address compression
of prefixes tagged with AE TBD, as described in Section 4.6.9 of of prefixes tagged with AE TBD, as described in Section 4.6.9 of
[RFC8966] [RFC8966]
5.2. Changes for existing TLVs 4.2. Changes to existing TLVs
The following TLVs MAY be tagged with AE TBD: The following TLVs MAY be tagged with AE TBD:
* Update (Type = 8) * Update (Type = 8)
* Route Request (Type = 9) * Route Request (Type = 9)
* Seqno Request (Type = 10) * Seqno Request (Type = 10)
As AE TBD is suitable only to tag network prefixes, IHU (Type = 5) As AE TBD is suitable only for network prefixes, IHU (Type = 5) and
and Next-Hop (Type = 7) TLVs MUST NOT be tagged with AE TBD. Such Next-Hop (Type = 7) TLVs MUST NOT be tagged with AE TBD. Such
(incorrect) TLVs MUST be silently ignored upon reception. (incorrect) TLVs MUST be ignored upon reception.
5.2.1. Update 4.2.1. Update
An Update (Type = 8) TLV with AE = TBD is constructed as described in An Update (Type = 8) TLV with AE = TBD is constructed as described in
Section 4.6.9 of [RFC8966] for AE 1 (IPv4), with the following Section 4.6.9 of [RFC8966] for AE 1 (IPv4), with the following
specificities: specificities:
* Prefix. The Prefix field is constructed according to the * Prefix. The Prefix field is constructed according to Section 4.1
Section 5.1 above. above.
* Next hop. The next hop is determined as described in Section 2.2 * Next hop. The next hop is determined as described in Section 2.2
above. above.
5.2.2. Other valid TLVs tagged with AE = TBD 4.2.2. Other TLVs
Any other valid TLV tagged with AE = TBD MUST be constructed and When tagged with the AE TBD, Route Request and Seqno Request updates
decoded as described in Section 4.6 of [RFC8966]. Network prefixes MUST be constructed and decoded as described in Section 4.6 of
within MUST be constructed and decoded as described in Section 5.1 [RFC8966], and the network prefixes contained within them decoded as
above. described in Section 4.1 above.
5. Backwards compatibility
This protocol extension adds no new TLVs or sub-TLVs.
This protocol extension uses a new AE. As discussed in Appendix D of
[RFC8966] and specified in the same document, implementations that do
not understand the present extension will silently ignore the various
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,
which, as stated in Section 2.3, are NOT RECOMMENDED.
Using a new AE introduces a new compression state, used to parse the
network prefixes. As this compression state is separate from other
AEs' states, it will not interfere with the compression state of
unextended nodes.
This extension reuses the next-hop state from AEs 2 and 3 (IPv6), but
makes no changes to the way it is updated, and therefore causes no
compatibility issues.
As mentioned in Section 2.1, ordinary IPv4 announcements are
preferred to v4-via-v6 announcements when the outgoing interface has
an assigned IPv4 address; doing otherwise would prevent routers that
do not implement this extension from learning the route being
announced.
6. IANA Considerations 6. IANA Considerations
IANA is requested to allocate a value (4 suggested) in the "Babel IANA is requested to allocate a value (4 suggested) in the "Babel
Address Encodings" registry as follows: Address Encodings" registry as follows:
+=====+===========+=================+ +=====+===========+=================+
| AE | Name | Reference | | AE | Name | Reference |
+=====+===========+=================+ +=====+===========+=================+
| TBD | v4-via-v6 | (this document) | | TBD | v4-via-v6 | (this document) |
 End of changes. 16 change blocks. 
65 lines changed or deleted 64 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/