 Good morning. My name is Sean Collins. I'm Sean from IBM. I'm Robert Lee from Cisco So we'd like to welcome you to our presentation about the IPv6 features that we were able to get into the Juno release of neutron So we have a brief agenda today Where we're going to describe the API changes that we made into neutron The changes that we made into the neutron command line client and And then also the changes that we've added to horizon from the community So the earliest use case that we had for IPv6 and what necessitated some of the changes that were made Include provider networking where you already have a configured router that is advertising IPv6 routes and a prefix we have support for router advertising advertisements through RA DVD and And we also have support for using DHCP v6 For stateful and stateless configuration as well as we'll also introduce the changes that we made into neutron on the security side To make all of this work We'll also go through some of the deployment options for IPv6 and how you would actually wire up Your instances and the networking and then we'll also discuss some of the features that we have Working for that. We hope to get into the kilo release that is upcoming So we made a small change to the neutron subnet object model During this release cycle where we introduced two new optional API attributes that allow neutron to make Better decisions about how IPv6 networking is provisioned how addresses are assigned And how the routing is done So for most cases The attributes will be set to identical values and using this table You will determine which mode you will use Now we use two attributes because there are also some corner cases where only one of the attributes will be set In this case if you already have a router that is advertising routes and a prefix The only thing that you would want to do is to have open stack calculate the address correctly so that in the API Requests in the dashboard and all the other types of interactions the address is shown to the user correctly So as you can see this is a IPv6 subnet with the optional attribute set it looks very similar to The subnet API before the changes were introduced, but as you can see there are just two new attributes to them Okay so for horizon GUI the changes are very similar, but With a little bit difference, so so so first you have to create the Network here so you so you can create a pure IPv6 network or you can create a dual stack Network as well and and then you have to create a subnet Yeah, yeah in in said then Network you have to input IPv6 as the IP version and then you can optionally input the Gateway address if you you you don't want to to use the Default first IP of the Gateway Then then you have to input the CIDR for for the IPv6 subnet Then go into the next page You have to select the IPv6 address mode for the subnet so here to to read to reduce the complicated user scenarios were reduced the configuration mode to only four You can select no no no options here or you can select select Select mode and and you can also select the Cpv4 Stateless or the Cpv4 state for mode so here You have to make the IPv6 RA mode and IPv6 address mode the same Value from from previous change so So to to recap if you Select no no option here. So so the virtual servers will not discover address from IPv6 router or DHCP server if you use you select slack or DHCP Stateless then then your virtual server can discover IPv6 address from the open stack manage the router here and then then if you select the DHCP way for state for mode then the Dress can be discovered from open stack controlled DNS mass queue DHCP server here So so I so I also want to to mention here. We have a limitation That we we don't support provider Provider router you use case in our GUI changes yet Because for provider router you use case you have to select different combination of values for IPv6 RA mode and and address mode So so we are going to support that in kilo release I Think that will be all for the horizon changes and Now we are going to talk about talk about our use cases on the first will be the Provider router use case. Thank you So one of the earliest use cases that we had for IPv6 would be where you already had a Router that was configured outside of open stack and What you wanted to do is through the provider networking extension Just attach virtual machines or instances to this already existing and configured network So this is a brief sort of diagram of what the compute node has and the interfaces That allow a provider routers RA packet to pass through into the instance so in this case you would only set the existing attribute for IPv6 address mode to slack and that will prompt Open-stack neutron to correctly calculate the address that the instance itself will do the same So when it receives an RA packet in with the prefix it will then calculate an address using EUI 64 Which combines the MAC address and the prefix and does some bit flipping so that it creates an address So for this we just needed to give a hint into neutron to do the same calculation so that when you do an API request It'll show the correct IPv6 address Thank you so in Juneau we provided a support to IPv6 RA and Basically the virtual machines and can Automatically configure is IPv6 address in stateless mode and so there are two cases if you Create a router port and You configured the two modes the modes to be slack and it will you know give the default rod and the IP prefix to the virtual server Otherwise, it will just advertise default rod So what you would normally do if you want to use Slike an RA is that you know you create a neutron router first and The next thing you would do is to create a neutron network Then followed by adding the IPv6 subnet into the network When you create the subnet you want to specify the two H attributes and in this case you want to either specify the attributes to be Slike or stateless for both the attributes The last thing you would do is to add the IPv6 subnet into the neutron router Created in a bow by doing that it added a router port into the router. So as a result a an RADVD instance will be spawned in the router's namespace if it hasn't been spawned yet It started advertising a default rod and the prefix if any into the neutron subnet Yeah, yeah, I can talk about that. So for DHCP v6 stateless use case the this use This use case is very similar with Slike use case Where the virtual server on the compute host will get the default root and the prefix by open stack managed router running on network host router name space and the difference with Slike use case is The virtual server on the compute host will get optional information from DHCP server for example the DNS Server information that that that can be discovered from the DNS mass queue by DHCP v6 in instead of router router advertisement process So so that will be the stateless DHCP v6 and I'll skip this one and for a state for this DHCP v6 There there will be no RADVD process spawned by open stack unless there there is a another slack or DHCP v6 stateless subnet in the same network. So so so in this case the address and default root and Optional information will be all discovered from DHCP v6 running by the DNS mass queue on them DHCP name name space This is very similar with IPv4 DHCP and I think that that will be it and then now I want to cover the security perspective So for security parts we focus on how to run security group filtering on the compute host to pass the IPv6 specific packets through the compute host and get into the virtual machine so you can see that IPv6 specific packets in includes router advertisements messages and other IPv6 related packages so I so I want to talk about two use case One is the provider router use case and one one is the tenant router use case here So first one the provider router use case to to to recap This is the use case that we we can fit IPv6 RA mode as none and we can fake IPv6 address mode as slack so so so the router advertisement is actually coming from the provider routers interface with a source address of the link local address of the provider routers interface So so so now we we have to allow that router advertisement Coming from the provider router to pass compute host and get into virtual machine and we also want to drop the other router or the advertisement coming from unknown sources so now the question Becomes how do we know how from open stacks perspective? How do we know the? Link local address of the provider router here marketing in blue here, so the answer is you have to specify the link local address of the provider router as you create the IPv6 subnet you have to specify that address as the Gateway address of yours IPv6 subnet so when When you when you do that after a virtual server is spawned on the on the compute host There are there will be a security group rule automatically created on the compute host to to allow this router for the advertisement coming from the provider router to Can pass through the compute host? so that is very similar with provider DHCP server use case The different is for a provider DHCP server use case There is no way for open stack to know about the address of the DHCP server Outside the open stack so you so you have to create a security group rule For the DHCP server if you want to to use a provider DHCP and that that that is the provider router use case and now for the open stacks own router tennis router you use case so the router advertisement in this case is coming from the network host so we so we have to allow the the security group rule running on compute host to pass the router advertisement package which has a source source IP address of the router interface on the network host which is the link local address of the QR device in in router name namespace, so we have some code in new neutron with calculus the link local address by the Mac address of the router's interface then so so so when you create a open stack tenant router and you spawn a virtual machine which can consumes a IPv6 subnet there will be automatically a security group rule Which allows the source source IP address with the link local address of the router the advertisement so that that that is very similar with the open stack manage DHCP server except that for DHCP server we allow the the address from the DNS mass queue interface running on Network host here, so that will be all for our IPv6 use case from Slack to DHCP to security perspective and then next we will cover some IPv6 deployment use cases So in June or we were trying to add some Dev Stack patches So that the user can deploy IPv6 with ease The both patches are still under review, you know it gone through very very scrutinized from the community and hopefully The the data patch that network patch can be merged soon and the second patch We're still working on that. So with the the first patch That's the management network patch Mainly what it does is to set up the default host IP if it's not Explicitly specified in the Dev Stack config file The next thing it does is to enable the binding to IPv6 any address so that you know the the servers running on the host can take connections from Both IPv4 clients and IPv6 clients The next patch is to support the IPv6 data network It provides three modes it can support IPv4 only or IPv6 only or do stack So currently the neutron code Doesn't support do stack Automatically so the this this Dev Stack script will try something will to do something to Configure the host to support the do stack mode The next thing that supports is to configure the host and the Neutron router namespace So that it can provide IPv6 internet access to the virtual machines So as long as your host has been configured with internet access after running the script Your virtual machines should be outside in terms of accessing the internet so again the both patches are still on the review and Very folks have been downloaded these Scripts to be used in their environment. So hopefully we'll see them to be merged soon Next So so so this is an example of you using IPv6 as the Tendence network, so we have Two tendons here virtual machine one and virtual machine three are from tendon one and BM two and the four are from tendon two and I'll how the virtual machines here are Consuming pure global unicast address So we so we need to open stack routers running on network nodes to route the private IPv6 network to external IPv6 network and and and and as you and you can see We have two separate namespace On network host to separate the traffic. So so the two tendons can even use the same address for for for their attendance. So so we have the router or the part of our ties meant to have RADVD running on Each name namespace they are bounded to the QR device and then the virtual server can can get the prefix and default route from the router for the advertisement and and and the down we have two gateways or router interface QQG device running on the Network host so so so so out of the traffic can can can go in from from private to public through the External gateway and You can see that QQG here has a external IPv6 address and they they have all go through the external route routers as the gateway of the external network here so so our Limitation in Juneau will be Currently we cannot can config dual stack IPv6 and IPv4 simultaneously on the BR Sorry on the QQQG device so so so we can only have IPv6 address on the router interface or IPv4 as was supported and Now we will we will have some some work in next release to support the dual-stack router interface address So that will be the tenant network deployment now the future IPv6 features So a lot of the work that we've just demonstrated to you has been to build a foundation For using IPv6 with neutron networking A lot of the work that we've just done during this development cycle is in order for the future developments that we have So for example, we want to support multiple prefixes on an IPv6 router We want to have support for prefix delegation We also have in the works support for using Floating IPs so for IPv6 addresses that are similar to the behavior of IPv4 Addresses for floating IPs where you can reassign them to different instances We also want to work on fixing some of the gaps that we've seen with the gateway to be dual-stack And then one of the more aggressive things that we want to work on is to reduce the amount of IPv4 that is used by the actual management and The API and then also the data plane. I think that's been a really important use case for a lot of projects where they want to reduce the amount of IPv4 addresses that they're consuming for the management the APIs and stuff like that so This is just what we've done within the community by a lot of different companies that have a lot of different needs We created a sub team within the neutron project We have a weekly IRC meeting and we also discuss a lot of these things on the development mailing list If there are features that you don't see that were on the previous slide certainly reach out to us started attending the meetings Create some specs or reach out to people we can help you create specs And basically just participate a lot of these features were created by people who needed them and All of the work that we've done has been driven by the community. So we do Highly encourage people to help participate So I think with that we are going to open up the floor to questions If you have a question, I believe there are mics in the rows Thank you for presentation One question. I didn't sell in your presentation. Do you perform the not translation for IPv6 addresses? I'm sorry. Could you repeat that? Do you perform translation network address translation for addresses on the rotor not currently I Believe not currently right. We don't plan to support IPv6 address translation Between IPv6 addresses, so you're talking about from unique link or local address to Global unique address translation. Yes, I'm mostly about moving floating IP between virtual machines online without any restarting and so on On IPv4 you can move IP address from one virtual machine to other instantly right through net through net For IPv6 is So we have a couple of specs that are floating out there for how to Answer that question correctly. So there hasn't been really an established Mechanism that we've that we've actually determined. I think there's still a lot of discussion about that that needs to be done Okay, thank you. I'm unfortunately. I can't answer that So the floating IP for the future release kilo release may be able to address your issue We would certainly appreciate your input So So I have a question along similar lines So you showed something in the diagram where the 2001 address was getting converted to 2003 So Nat doesn't happen for that as well for the external gateway case No, no, I don't think so. We have the routing things but not address the translation I think yeah so, I mean, so there are There is code that disables putting these NAT rules specific to IPv6 because here you can see the VMs have 2001 and the BRX has 2003 so all the traffic actually is still 2001 when it goes out I think you know hit here is talking about two tenants, right? Right? So two tenants have different prefixes and they are talking to each other through the external router and when they go out How about that case when they're actually going out to the external world? What address would the packets have? It would have whatever the address that's assigned to the virtual machine Yeah, so this is routing through the external router It would be for it would just be packet it forward So you need a global unique addresses for your virtual machines to be able to route today Routing IP you can do that with private addresses then. Yes So similar question here actually I'm the typically, you know right now when we use IPv4 for for for building the tenant private network we use actually VLE tune obvious bridgey Where we deploy kind of overlay network right VX LAN or GRI stuff, but in this case we don't need such an approach at all then Correct understanding. I'm sorry. Can you just so we don't need if we use IPv6. We may not need Utilizing that you know VR tunnel obvious bridge at all correct understanding. So I think The encapsulation that you're using For your networking so for example in neutron networks in the API are these isolated Broadcast domains so, you know, there's ton you can either accomplish that separation of networks for your tenants through either tunneling or VLAN tags or VX LAN so I May have lost what your question was asking for We do utilize those bridges still the integration bridge, right? You're talking about the integration bridge and The tunnel the VR dash Tu and bridgey that has been used now in I south and you know to provide that, you know tenant to private network utilizing VX LAN or GRI tunneling. Yeah, I think you do still need those your implementation will also include that VR tune here I think for this one This may be based on using VLAN encapsulation But the idea would be very similar the diagram would be similar It would just be that with their tunnel your tunnel devices rather than the BREX device. Okay. Thank you any other questions Okay, well then thank you very much One more Because there is no a network translation now that mean external rotor provider rotor should know about every Allocated networking in open stack installation. I Mean there is a thousand tenants inside installation everyone want to have separate IPv6 networking and They should be Routed on external rotor, isn't it? I believe so that means we're losing good kind Situation when networking guys Know nothing about internals of open stack about how much tenants in v4 they just allocate a block of addresses and open stack can decide which addresses go to which tenant and IPv6 we need to add routing to external rotor ask networking guys about adding each next IPv6 network. I mean Is that so I do believe there are actually some specs in the community being filed for Discussing routing information And distributing routing information. Does that answer your question? But anyway, it will require cooperation of networking guys Yes, I am is yes. I believe so. Okay. Thank you any other questions Well, then I'd like to thank you for your time