docs/specs/ipv6-cvr-north-south.rst

   1 .. contents:: Table of Contents
   2          :depth: 3
   3
   4 ============================================================
   5 IPv6 L3 North-South support for Flat/VLAN Provider Networks.
   6 ============================================================
   7
   8 https://git.opendaylight.org/gerrit/#/q/topic:ipv6-cvr-north-south
   9
  10 In this specification we will be discussing the high level design of
  11 IPv6 North-South support in OpenDaylight for VLAN/FLAT provider network
  12 use-case.
  13
  14 Problem description
  15 ===================
  16
  17 OpenDaylight currently supports IPv6 IPAM (IP Address Management) and a fully
  18 distributed east-west router. IPv6 external connectivity is not yet supported.
  19 This SPEC captures the implementation details of IPv6 external connectivity for
  20 VLAN/FLAT provider network use-cases.
  21
  22 We have a separate SPEC [3] that captures external connectivity for L3VPN use-case.
  23
  24 The expectation in OpenStack is that Tenant IPv6 subnets are created with Globally
  25 Unique Addresses (GUA) that are routable by the external physical IPv6 gateway in
  26 the datacenter for external connectivity. So, there is no concept of NAT or
  27 Floating-IPs for IPv6 addresses in Neutron. An IPv6 router is hence expected to do
  28 a plain forwarding.
  29
  30 Initially, we would like to pursue a Centralized IPv6 router (CVR) use-case and
  31 look into a fully distributed router via a future spec. One of the main reasons
  32 for pursuing the CVR over DVR is that OpenStack Neutron creates only a single
  33 router gateway port (i.e., port with device owner as network:router_gateway)
  34 when the router is associated with the external network. When implementing
  35 a distributed router, we cannot use the same router gateway port MAC address
  36 from multiple Compute nodes as it could create issues in the underlying physical
  37 switches. In order to implement a fully distributed router, we would ideally
  38 require a router-gateway-port per compute node. We will be addressing the
  39 distributed router in a future spec taking into consideration both IPv4 and IPv6
  40 use-cases.
  41
  42 Use Cases
  43 ---------
  44
  45 IPv6 external connectivity (north-south) for VMs spawned on tenant networks,
  46 when the external network is of type FLAT/VLAN based.
  47
  48 Steps:
  49
  50 - Create a tenant network with IPv6 subnet using GUA/ULA prefix or an
  51   admin-created-shared-ipv6-subnet-pool.
  52 - Create an external network of type FLAT/VLAN with an IPv6 subnet where the
  53   gateway_ip points to the Link Local Address (LLA) of external/physical IPv6
  54   gateway.
  55 - Create a Neutron Router and associate it with the internal subnets and external
  56   network.
  57 - Spawn VMs on the tenant network.
  58
  59 ::
  60
  61
  62             +------------------+
  63             |                  |
  64             |                  +------->Internet
  65             |   External IPv6  |
  66             |      Gateway     |
  67             |                  |
  68             |                  |
  69             +------------------+
  70                 |LLA of IPv6 GW
  71                 |
  72                 |                          Flat/VLAN External Network: 2001:db8:0:1::/64
  73         +------------------------------------------------------------------------------+
  74                 |                               |                          |
  75                 |                               |                          |
  76                 |     -----------------------------------------------------------------+
  77                 |      |  Internal Tenant N/W   |     |                    |      |
  78   router-gw-port|      |                        |     |                    |      |
  79     +------------------------+   +-------------------------+  +-------------------------+
  80     | +--------------------+ |   |                         |  |                         |
  81     | | Virtual IPv6 Router| |   |                         |  |                         |
  82     | |  using OVS Flows   | |   |                         |  |                         |
  83     | +--------------------+ |   |                         |  |                         |
  84     |                        |   |                         |  |                         |
  85     |                        |   |                         |  |                         |
  86     | +--------------------+ |   | +---------------------+ |  | +---------------------+ |
  87     | | VM1                | |   | | VM2                 | |  | | VM3                 | |
  88     | | Tenant IPv6 Subnet | |   | |                     | |  | |                     | |
  89     | | 2001:db8:0:2::10/64| |   | | 2001:db8:0:2::20/64 | |  | | 2001:db8:0:2::30/64 | |
  90     | +--------------------+ |   | +---------------------+ |  | +---------------------+ |
  91     +------------------------+   +-------------------------+  +-------------------------+
  92     Compute Node-1 designated           Compute Node-2               Compute Node-3
  93     as NAPT Switch for router1
  94
  95
  96 Proposed change
  97 ===============
  98
  99 ODL Controller would implement the following.
 100
 101 * Program the necessary pipeline flows to support IPv6 forwarding
 102 * Support Neighbor Discovery for Router Gateway port-ips on the external network.
 103   i.e., When the upstream/external IPv6 Gateway does a Neighbor Solicitation for the
 104   router-gateway-ip, ODL-Controller/ipv6service would respond with a Neighbor Advertisement
 105   providing the target link layer address.
 106 * Enhance IPv6Service to learn the MAC-address of external-subnet-gateway-ip by framing
 107   the necessary Neighbor Solicitation messages and parsing the corresponding response.
 108   The APIs in IPv6Service would be triggered from Gateway MAC resolver code and the
 109   information obtained will be used while programming the ProviderNetworkGroup entries.
 110
 111 The implementation would be aligned with the existing IPv4 SNAT support we have
 112 in Netvirt. ODL controller would designate one of the compute nodes (also referred
 113 as NAPT Switch), one per router, to act as an IPv6/IPv4-SNAT router, from where the
 114 tenant traffic is routed to the external network. External traffic from VMs hosted
 115 on the NAPT switch is forwarded directly, whereas traffic from VMs hosted on other
 116 compute nodes would have to do an extra hop to NAPT switch before hitting the
 117 external network. If a router has both IPv4 and IPv6 subnets, the same NAPT Switch
 118 for the router will be used for IPv4-SNAT and IPV6 external-packet forwarding.
 119
 120 Pipeline changes
 121 ----------------
 122
 123 **Flows on NAPT Switch for Egress traffic from VM to the internet**
 124
 125 | Classifier Table (0) =>
 126 | LPORT_DISPATCHER_TABLE (17) ``l3vpn service: set: vpn-id=router-id`` =>
 127 | L3_GW_MAC_TABLE (19) ``priority=20, match: vpn-id=router-id, dst-mac=router-internal-interface-mac`` =>
 128 | L3_FIB_TABLE (21) ``priority=10, match: ipv6, vpn-id=router-id, default-route-flow`` =>
 129 | PSNAT_TABLE (26) ``priority=5, match: ipv6, vpn-id=router-id, unknown-sip`` =>
 130 | OUTBOUND_NAPT_TABLE (46) ``priority=10, match: ipv6, vpn-id=router-id, ip-src=vm-ip set: src-mac=external-router-gateway-mac-address, vpn-id=external-net-id,`` =>
 131 | NAPT_PFIB_TABLE (47) ``priority=6, match: ipv6, vpn-id=external-net-id, src-ip=vm-ip`` =>
 132 | ProviderNetworkGroup: ``set dst-mac=ext-subnet-gw-mac, reg6=provider-lport-tag`` =>
 133 | EGRESS_LPORT_DISPATCHER_TABLE (220) output to provider network
 134
 135 **Flows on NAPT Switch for Ingress traffic from internet to VM**
 136
 137 | Classifier Table (0) =>
 138 | LPORT_DISPATCHER_TABLE (17) ``l3vpn service: set: vpn-id=ext-net-id`` =>
 139 | L3_GW_MAC_TABLE (19) ``priority=20, match: vpn-id=ext-net-id, dst-mac=router-gateway-mac`` =>
 140 | L3_FIB_TABLE (21) ``priority=138, match: ipv6, vpn-id=ext-net-id, dst-ip=vm-ip`` =>
 141 | INBOUND_NAPT_TABLE (44) ``priority=10, match: ipv6, vpn-id=ext-net-id, dst-ip=vm-ip set: vpn-id=router-id`` =>
 142 | NAPT_PFIB_TABLE (47) ``priority=5, match: ipv6, vpn-id=router-id set: in_port=0`` =>
 143 | L3_FIB_TABLE (21) ``priority=138, match: ipv6, vpn-id=router-id, dst-ip=vm-ip`` =>
 144 | Local Next-Hop group: ``set: src-mac=router-intf-mac, dst-mac=vm-mac,reg6=vm-lport-tag`` =>
 145 | Egress table (220) output to VM port
 146
 147 **Flows for VMs hosted on Compute node that is not acting as an NAPT Switch**
 148
 149 | Same egress pipeline flows as above until L3_FIB_TABLE (21).
 150 | PSNAT_TABLE (26) ``priority=5, match: ipv6, vpn-id=router-id set: tun_id=<tunnel-id>`` =>
 151 | TunnelOutputGroup: ``output to tunnel-port`` =>
 152 | OnNAPTSwitch (for Egress Traffic from VM)
 153 |     INTERNAL_TUNNEL_TABLE (36): ``priority=10, match: ipv6, tun_id=<tunnel-id-set-on-compute-node> set: vpn-id=router-id, goto_table:46``
 154 |     Rest of the flows are common.
 155 | OnNAPTSwitch (for Ingress Traffic from Internet to VM)
 156 |     Same flows in ingress pipeline shown above until NAPT_PFIB_TABLE (47) =>
 157 |     L3_FIB_TABLE (21) ``priority=138, match: ipv6, vpn-id=router-id, dst-ip=vm-ip set: tun_id=<tunnel-id>, dst-mac=vm-mac, output: <tunnel-port>`` =>
 158
 159
 160 Yang changes
 161 ------------
 162 IPv6Service would implement the following YANG model.
 163
 164 ::
 165
 166   module ipv6-ndutil {
 167     yang-version 1;
 168     namespace "urn:opendaylight:netvirt:ipv6service:ipv6util";
 169     prefix "ipv6-ndutil";
 170
 171     import ietf-interfaces {
 172         prefix if;
 173     }
 174
 175     import ietf-inet-types {
 176         prefix inet; revision-date 2013-07-15;
 177     }
 178
 179     import ietf-yang-types {
 180         prefix yang;
 181     }
 182
 183     revision "2017-02-10" {
 184         description "IPv6 Neighbor Discovery Util module";
 185     }
 186
 187     grouping interfaces {
 188         list interface-address {
 189            key interface;
 190            leaf interface {
 191                 type leafref {
 192                     path "/if:interfaces/if:interface/if:name";
 193                 }
 194            }
 195            leaf src-ip-address {
 196                 type inet:ipv6-address;
 197            }
 198            leaf src-mac-address {
 199                 type yang:phys-address;
 200             }
 201         }
 202     }
 203
 204     rpc send-neighbor-solicitation {
 205         input {
 206             leaf target-ip-address {
 207                 type inet:ipv6-address;
 208             }
 209             uses interfaces;
 210         }
 211     }
 212   }
 213
 214
 215 neighbor-solicitation-packet container in neighbor-discovery.yang would be enhanced
 216 with Source Link Layer optional header.
 217
 218 ::
 219
 220   container neighbor-solicitation-packet {
 221     uses ethernet-header;
 222     uses ipv6-header;
 223     uses icmp6-header;
 224     leaf reserved {
 225         type uint32;
 226     }
 227     leaf target-ip-address {
 228         type inet:ipv6-address;
 229     }
 230     leaf option-type {
 231         type uint8;
 232     }
 233     leaf source-addr-length {
 234         type uint8;
 235     }
 236     leaf source-ll-address {
 237         type yang:mac-address;
 238     }
 239   }
 240
 241
 242 Configuration impact
 243 ---------------------
 244 None
 245
 246
 247 Clustering considerations
 248 -------------------------
 249 None
 250
 251 Other Infra considerations
 252 --------------------------
 253 None
 254
 255 Security considerations
 256 -----------------------
 257
 258 Scale and Performance Impact
 259 ----------------------------
 260 * In the proposed implementation, we have to configure a static route
 261   on the external IPv6 Gateway with next-hop as the router-gateway-ip.
 262   In a future patch, we would enhance the implementation to use BGP for
 263   advertising the necessary routes.
 264
 265 * When the external IPv6 Gateway wants to contact the tenant VMs, it
 266   forwards all the traffic to the router-gateway-port on the designated
 267   NAPT Switch. To know the target-link-layer address of the router-gw-port,
 268   the external IPv6 Gateway would send out a Neighbor Solicitation for the
 269   router-gateway-port-ip. This request would be punted to the Controller
 270   and ipv6service would respond with the corresponding Neighbor Advertisement.
 271   In large deployments this can become a bottleneck.
 272   Note: Currently, OpenFlow does not have support to auto-respond to Neighbor
 273   Solicitation packets like IPv4 ARP. When the corresponding support is added
 274   in OpenFlow, we would program the necessary ovs flows to auto-respond to
 275   the Neighbor Soliciation requests for router-gateway-ports.
 276
 277 Targeted Release
 278 -----------------
 279 Carbon
 280
 281 Alternatives
 282 ------------
 283 An alternate solution is to implement a fully distributed IPv6 router and
 284 would be pursued in a future SPEC.
 285
 286 Usage
 287 =====
 288
 289 * Create an external FLAT/VLAN network with an IPv6 (or dual-stack) subnet.
 290
 291 ::
 292
 293  neutron net-create public-net -- --router:external --is-default
 294  --provider:network_type=flat --provider:physical_network=public
 295
 296  neutron subnet-create --ip_version 6 --name ipv6-public-subnet
 297  --gateway <LLA-of-external-ipv6-gateway> <public-net-uuid> 2001:db8:0:1::/64
 298
 299 * Create an internal tenant network with an IPv6 (or dual-stack) subnet.
 300
 301 ::
 302
 303  neutron net-create private-net
 304  neutron subnet-create --name ipv6-int-subnet --ip-version 6
 305  --ipv6-ra-mode slaac --ipv6-address-mode slaac private-net 2001:db8:0:2::/64
 306
 307 * Create a router and associate the external and internal subnets.
 308   Explicitly specify the fixed_ip of router-gateway-port, as it would help us
 309   when manually configuring the downstream route on the external IPv6 Gateway.
 310
 311 ::
 312
 313  neutron router-create router1
 314  neutron router-gateway-set --fixed-ip subnet_id=<ipv6-public-subnet-id>,ip_address=2001:db8:0:10 router1 public-net
 315  neutron router-interface-add router1 ipv6-int-subnet
 316
 317 * Manually configure a downstream route in the external IPv6 gateway
 318   for the IPv6 subnet "2001:db8:0:2::/64" with next hop address as the
 319   router-gateway-ip.
 320
 321 ::
 322
 323  Example (on Linux host acting as an external IPv6 gateway):
 324  ip -6 route add 2001:db8:0:2::/64 via 2001:db8:0:10
 325
 326 * Spawn a VM in the tenant network
 327
 328 ::
 329
 330  nova boot --image <image-id> --flavor <flavor-id> --nic net-id=<private-net> VM1
 331
 332 Features to Install
 333 -------------------
 334 odl-netvirt-openstack
 335
 336 REST API
 337 --------
 338
 339 CLI
 340 ---
 341
 342
 343 Implementation
 344 ==============
 345
 346 Assignee(s)
 347 -----------
 348 Primary assignee:
 349   Sridhar Gaddam <sgaddam@redhat.com>
 350
 351 Other contributors:
 352   TBD
 353
 354 Work Items
 355 ----------
 356 https://trello.com/c/cqjOFmow/147-ipv6-centralized-router-l3-north-south-support-for-flat-vlan-provider-networks
 357
 358 * Program necessary pipeline flows to support IPv6 North-South communication.
 359 * Enhance ipv6service to send out Neighbor Solicitation requests
 360   for the external/physical IPv6 gateway-ip and parse the response.
 361 * Support controller based Neighbor Advertisement for router-gateway-ports
 362   on the external network.
 363 * Implement Unit and Integration tests to validate the use-case.
 364
 365 Dependencies
 366 ============
 367 None
 368
 369 Testing
 370 =======
 371
 372 Unit Tests
 373 ----------
 374 Necessary Unit tests would be added to validate the use-case.
 375
 376 Integration Tests
 377 -----------------
 378 Necessary Integration tests would be added to validate the use-case.
 379
 380 CSIT
 381 ----
 382 We shall explore the possibility to validate this use-case in CSIT.
 383
 384 Documentation Impact
 385 ====================
 386 Necessary documentation would be added on how to use this feature.
 387
 388 References
 389 ==========
 390 [1] `OpenDaylight Documentation Guide <http://docs.opendaylight.org/en/latest/documentation.html>`__
 391
 392 [2] https://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html
 393
 394 [3] `Spec to support IPv6 Inter DC L3VPN connectivity using BGPVPN <https://git.opendaylight.org/gerrit/#/c/50359/>`_
 395
 396 .. note::
 397
 398   This template was derived from [2], and has been modified to support our project.
 399
 400   This work is licensed under a Creative Commons Attribution 3.0 Unported License.
 401   http://creativecommons.org/licenses/by/3.0/legalcode