Merge branch 'int-new' of ssh://gitlab.labs.nic.cz/labs/bird into int-new

1 files changed, 58 insertions, 26 deletions

diff --git a/doc/bird.sgml b/doc/bird.sgml
index 04f9258b..903456f0 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -293,6 +293,20 @@ routes are:
 	<item>Route next hops (see below)
 </itemize>
 
+<sect1>IPv6 source-specific routes
+<label id="ip-sadr-routes">
+
+<p>The IPv6 routes containing both destination and source prefix. They are used
+for source-specific routing (SSR), also called source-address dependent routing
+(SADR), see <rfc id="8043">. Currently limited mostly to the Babel protocol.
+Configuration keyword is <cf/ipv6 sadr/.
+
+<itemize>
+	<item>(PK) Route destination (IP prefix together with its length)
+	<item>(PK) Route source (IP prefix together with its length)
+	<item>Route next hops (see below)
+</itemize>
+
 <sect1>VPN IPv4 and IPv6 routes
 <label id="vpn-routes">
 
@@ -646,9 +660,9 @@ agreement").
 	restricted to interfaces assigned to the VRF and will use sockets bound
 	to the VRF. Appropriate VRF interface must exist on OS level. For kernel
 	protocol, an appropriate table still must be explicitly selected by
-	<cf/table/ option. Note that the VRF support in BIRD and Linux kernel
-	(4.11) is still in development and is currently problematic outside of
-	multihop BGP.
+	<cf/table/ option. Note that for proper VRF support it is necessary to
+	use Linux kernel version at least 4.14, older versions have limited VRF
+	implementation.
 
 	<tag><label id="proto-channel"><m/channel name/ [{<m/channel config/}]</tag>
 	Every channel must be explicitly stated. See the protocol-specific
@@ -1234,12 +1248,17 @@ foot).
 	operator <cf/.type/. The type may be:
 
 	<cf/NET_IP4/ and <cf/NET_IP6/ prefixes hold an IP prefix. The literals
-	are written as <cf><m/ipaddress//<m/pxlen/</cf>,
-	or <cf><m>ipaddress</m>/<m>netmask</m></cf>. There are two special
+	are written as <cf><m/ipaddress//<m/pxlen/</cf>. There are two special
 	operators on these: <cf/.ip/ which extracts the IP address from the
 	pair, and <cf/.len/, which separates prefix length from the pair.
 	So <cf>1.2.0.0/16.len = 16</cf> is true.
 
+	<cf/NET_IP6_SADR/ nettype holds both destination and source IPv6
+	prefix. The literals are written as <cf><m/ipaddress//<m/pxlen/ from
+	<m/ipaddress//<m/pxlen/</cf>, where the first part is the destination
+	prefix and the second art is the source prefix. They support the same
+	operators as IP prefixes, but just for the destination part.
+
 	<cf/NET_VPN4/ and <cf/NET_VPN6/ prefixes hold an IP prefix with VPN
 	Route Distinguisher (<rfc id="4364">). They support the same special
 	operators as IP prefixes, and also <cf/.rd/ which extracts the Route
@@ -1460,6 +1479,7 @@ foot).
 	lclists, with LCs instead of pairs as arguments.
 </descrip>
 
+
 <sect>Operators
 <label id="operators">
 
@@ -1652,19 +1672,25 @@ cases desirable.
 routes over the same IPv6 transport. For sending and receiving Babel packets,
 only a link-local IPv6 address is needed.
 
-<p>BIRD does not implement any Babel extensions, but will coexist with
-implementations using extensions (and will just ignore extension messages).
+<p>BIRD implements an extension for IPv6 source-specific routing (SSR or SADR),
+but must be configured accordingly to use it. SADR-enabled Babel router can
+interoperate with non-SADR Babel router, but the later would ignore routes
+with specific (non-zero) source prefix.
 
 <sect1>Configuration
 <label id="babel-config">
 
-<p>Babel supports no global configuration options apart from those common to all
-other protocols, but supports the following per-interface configuration options:
+<p>The Babel protocol support both IPv4 and IPv6 channels; both can be
+configured simultaneously. It can also be configured with <ref
+id="ip-sadr-routes" name="IPv6 SADR"> channel instead of regular IPv6
+channel, in such case SADR support is enabled. Babel supports no global
+configuration options apart from those common to all other protocols, but
+supports the following per-interface configuration options:
 
 <code>
 protocol babel [<name>] {
 	ipv4 { <channel config> };
-	ipv6 { <channel config> };
+	ipv6 [sadr] { <channel config> };
 	interface <interface pattern> {
 		type <wired|wireless>;
 		rxcost <number>;
@@ -1684,8 +1710,8 @@ protocol babel [<name>] {
 </code>
 
 <descrip>
-      <tag><label id="babel-channel">ipv4|ipv6 <m/channel config/</tag>
-      The supported channels are IPv4 and IPv6.
+      <tag><label id="babel-channel">ipv4 | ipv6 [sadr] <m/channel config/</tag>
+      The supported channels are IPv4, IPv6, and IPv6 SADR.
 
       <tag><label id="babel-type">type wired|wireless </tag>
       This option specifies the interface type: Wired or wireless. On wired
@@ -2119,22 +2145,24 @@ to set routing policy and all the other parameters differently for each neighbor
 using the following configuration parameters:
 
 <descrip>
-	<tag><label id="bgp-local">local [<m/ip/] as <m/number/</tag>
+	<tag><label id="bgp-local">local [<m/ip/] [port <m/number/] [as <m/number/]</tag>
 	Define which AS we are part of. (Note that contrary to other IP routers,
 	BIRD is able to act as a router located in multiple AS'es simultaneously,
 	but in such cases you need to tweak the BGP paths manually in the filters
 	to get consistent behavior.) Optional <cf/ip/ argument specifies a source
-	address, equivalent to the <cf/source address/ option (see below). This
-	parameter is mandatory.
+	address, equivalent to the <cf/source address/ option (see below).
+	Optional <cf/port/ argument specifies the local BGP port instead of
+	standard port 179. The parameter may be used multiple times with
+	different sub-options (e.g., both <cf/local 10.0.0.1 as 65000;/ and
+	<cf/local 10.0.0.1; local as 65000;/ are valid). This parameter is
+	mandatory.
 
 	<tag><label id="bgp-neighbor">neighbor [<m/ip/] [port <m/number/] [as <m/number/]</tag>
 	Define neighboring router this instance will be talking to and what AS
 	it is located in. In case the neighbor is in the same AS as we are, we
 	automatically switch to iBGP. Optionally, the remote port may also be
-	specified. The parameter may be used multiple times with different
-	sub-options (e.g., both <cf/neighbor 10.0.0.1 as 65000;/ and
-	<cf/neighbor 10.0.0.1; neighbor as 65000;/ are valid). This parameter is
-	mandatory.
+	specified. Like <cf/local/ parameter, this parameter may also be used
+	multiple times with different sub-options. This parameter is mandatory.
 
 	<tag><label id="bgp-iface">interface <m/string/</tag>
 	Define interface we should use for link-local BGP IPv6 sessions.
@@ -2744,16 +2772,17 @@ protocol device {
 <p>The Direct protocol is a simple generator of device routes for all the
 directly connected networks according to the list of interfaces provided by the
 kernel via the Device protocol. The Direct protocol supports both IPv4 and IPv6
-channels.
+channels; both can be configured simultaneously. It can also be configured with
+<ref id="ip-sadr-routes" name="IPv6 SADR"> channel instead of regular IPv6
+channel in order to be used together with SADR-enabled Babel protocol.
 
 <p>The question is whether it is a good idea to have such device routes in BIRD
 routing table. OS kernel usually handles device routes for directly connected
 networks by itself so we don't need (and don't want) to export these routes to
 the kernel protocol. OSPF protocol creates device routes for its interfaces
-itself and BGP protocol is usually used for exporting aggregate routes. Although
-there are some use cases that use the direct protocol (like abusing eBGP as an
-IGP routing protocol), in most cases it is not needed to have these device
-routes in BIRD routing table and to use the direct protocol.
+itself and BGP protocol is usually used for exporting aggregate routes. But the
+Direct protocol is necessary for distance-vector protocols like RIP or Babel to
+announce local networks.
 
 <p>There is one notable case when you definitely want to use the direct protocol
 -- running BIRD on BSD systems. Having high priority device routes for directly
@@ -2828,8 +2857,10 @@ kernel protocols to the same routing table and changing route destination
 (gateway) in an export filter of a kernel protocol does not work. Both
 limitations can be overcome using another routing table and the pipe protocol.
 
-<p>The Kernel protocol supports both IPv4 and IPv6 channels; only one of them
-can be configured in each protocol instance.
+<p>The Kernel protocol supports both IPv4 and IPv6 channels; only one channel
+can be configured in each protocol instance. On Linux, it also supports <ref
+id="ip-sadr-routes" name="IPv6 SADR"> and <ref id="mpls-routes" name="MPLS">
+channels.
 
 <sect1>Configuration
 <label id="krt-config">
@@ -4280,6 +4311,7 @@ protocol rip {
 
 
 <sect>RPKI
+<label id="rpki">
 
 <sect1>Introduction