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 Configuration impact
 215 ---------------------
 216 None
 217
 218
 219 Clustering considerations
 220 -------------------------
 221 None
 222
 223 Other Infra considerations
 224 --------------------------
 225 None
 226
 227 Security considerations
 228 -----------------------
 229
 230 Scale and Performance Impact
 231 ----------------------------
 232 * In the proposed implementation, we have to configure a static route
 233   on the external IPv6 Gateway with next-hop as the router-gateway-ip.
 234   In a future patch, we would enhance the implementation to use BGP for
 235   advertising the necessary routes.
 236
 237 * When the external IPv6 Gateway wants to contact the tenant VMs, it
 238   forwards all the traffic to the router-gateway-port on the designated
 239   NAPT Switch. To know the target-link-layer address of the router-gw-port,
 240   the external IPv6 Gateway would send out a Neighbor Solicitation for the
 241   router-gateway-port-ip. This request would be punted to the Controller
 242   and ipv6service would respond with the corresponding Neighbor Advertisement.
 243   In large deployments this can become a bottleneck.
 244   Note: Currently, OpenFlow does not have support to auto-respond to Neighbor
 245   Solicitation packets like IPv4 ARP. When the corresponding support is added
 246   in OpenFlow, we would program the necessary ovs flows to auto-respond to
 247   the Neighbor Soliciation requests for router-gateway-ports.
 248
 249 Targeted Release
 250 -----------------
 251 Carbon
 252
 253 Alternatives
 254 ------------
 255 An alternate solution is to implement a fully distributed IPv6 router and
 256 would be pursued in a future SPEC.
 257
 258 Usage
 259 =====
 260
 261 * Create an external FLAT/VLAN network with an IPv6 (or dual-stack) subnet.
 262
 263 ::
 264
 265  neutron net-create public-net -- --router:external --is-default
 266  --provider:network_type=flat --provider:physical_network=public
 267
 268  neutron subnet-create --ip_version 6 --name ipv6-public-subnet
 269  --gateway <LLA-of-external-ipv6-gateway> <public-net-uuid> 2001:db8:0:1::/64
 270
 271 * Create an internal tenant network with an IPv6 (or dual-stack) subnet.
 272
 273 ::
 274
 275  neutron net-create private-net
 276  neutron subnet-create --name ipv6-int-subnet --ip-version 6
 277  --ipv6-ra-mode slaac --ipv6-address-mode slaac private-net 2001:db8:0:2::/64
 278
 279 * Create a router and associate the external and internal subnets.
 280   Explicitly specify the fixed_ip of router-gateway-port, as it would help us
 281   when manually configuring the downstream route on the external IPv6 Gateway.
 282
 283 ::
 284
 285  neutron router-create router1
 286  neutron router-gateway-set --fixed-ip subnet_id=<ipv6-public-subnet-id>,ip_address=2001:db8:0:10 router1 public-net
 287  neutron router-interface-add router1 ipv6-int-subnet
 288
 289 * Manually configure a downstream route in the external IPv6 gateway
 290   for the IPv6 subnet "2001:db8:0:2::/64" with next hop address as the
 291   router-gateway-ip.
 292
 293 ::
 294
 295  Example (on Linux host acting as an external IPv6 gateway):
 296  ip -6 route add 2001:db8:0:2::/64 via 2001:db8:0:10
 297
 298 * Spawn a VM in the tenant network
 299
 300 ::
 301
 302  nova boot --image <image-id> --flavor <flavor-id> --nic net-id=<private-net> VM1
 303
 304 Features to Install
 305 -------------------
 306 odl-netvirt-openstack
 307
 308 REST API
 309 --------
 310
 311 CLI
 312 ---
 313
 314
 315 Implementation
 316 ==============
 317
 318 Assignee(s)
 319 -----------
 320 Primary assignee:
 321   Sridhar Gaddam <sgaddam@redhat.com>
 322
 323 Other contributors:
 324   TBD
 325
 326 Work Items
 327 ----------
 328 https://trello.com/c/cqjOFmow/147-ipv6-centralized-router-l3-north-south-support-for-flat-vlan-provider-networks
 329
 330 * Program necessary pipeline flows to support IPv6 North-South communication.
 331 * Enhance ipv6service to send out Neighbor Solicitation requests
 332   for the external/physical IPv6 gateway-ip and parse the response.
 333 * Support controller based Neighbor Advertisement for router-gateway-ports
 334   on the external network.
 335 * Implement Unit and Integration tests to validate the use-case.
 336
 337 Dependencies
 338 ============
 339 None
 340
 341 Testing
 342 =======
 343
 344 Unit Tests
 345 ----------
 346 Necessary Unit tests would be added to validate the use-case.
 347
 348 Integration Tests
 349 -----------------
 350 Necessary Integration tests would be added to validate the use-case.
 351
 352 CSIT
 353 ----
 354 We shall explore the possibility to validate this use-case in CSIT.
 355
 356 Documentation Impact
 357 ====================
 358 Necessary documentation would be added on how to use this feature.
 359
 360 References
 361 ==========
 362 [1] `OpenDaylight Documentation Guide <http://docs.opendaylight.org/en/latest/documentation.html>`__
 363
 364 [2] https://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html
 365
 366 [3] `Spec to support IPv6 Inter DC L3VPN connectivity using BGPVPN <https://git.opendaylight.org/gerrit/#/c/50359/>`_
 367
 368 .. note::
 369
 370   This template was derived from [2], and has been modified to support our project.
 371
 372   This work is licensed under a Creative Commons Attribution 3.0 Unported License.
 373   http://creativecommons.org/licenses/by/3.0/legalcode