Hello Stackers!
It is very nice to watch the OpenStack evolution in IPv6! Great job guys!!
Thanks!
I have another idea:
Floating IP for IPv6, or just Floating IPv6
With IPv4, as we know, OpenStack have a feature called Floating IP, which is
basically a 1-to-1 NAT rule (within tenant's Namespace q-router). In IPv4
networks, we need this Floating IP attached to a Instance, to be able to
reach it from the Internet (I don't like it). But, what is the use case for a
Floating IP when you have no NAT* (as it is with IPv6)?!
There are definitely cases for it, and we were planning to address it in a
future release.
At first, when with IPv6, I was planning to disable the Floating IP feature
entirely, by removing it from Dashboard and from APIs (even for IPv4, if FWaaS
can in somehow, be able to manage q-router IPv4 NAT rules, and not only the
iptables filter table) and, I just had an idea!
For IPv6, the Floating IP can still be used to allocate more (and more) IPs
to a Instance BUT, instead of creating a NAT rule (like it is for IPv4), it
will configure the DNSMasq (or something like it) to provide more IPv6 address
per MAC / Instance. That way, we can virtually allocate unlimited IPs (v6) for
each Instance!
It will be pretty cool to see the attached Floating IPv6, literally floating
around the tenant subnet, appearing inside the Instances itself (instead of
inside the tenant's Namespace), so, we'll be able to see it (the Floating IPv6)
with ip -6 address command within the attached Instance!
The only problem I see with this is that, for IPv4, the allocated Floating
IPs come from the External Network (neutron / --allocation-pool) and, for
IPv6, it will come from the tenant's IPv6 subnet itself... I think... Right?!
I think the real issue here is how neutron handles these from a network/port
perspective. In the IPv4 case, the IPs are from and entirely separate block.
I think that should probably stay the same for IPv6, since you have twofold
problems:
1. You've already issued an RA on the network for a specific address scope.
Another one, when an interface is already addressed, won't trigger adding a new
address.
2. Routing. Which address should be the source address? If it's on the same
network, the majority of distributions will ignore further routes and addresses
for the purpose of sourcing packets.
Because of the above, it would make sense for floats to end up on a floating
IP subnet. However, we'd go back to earlier neutron issues about having
multiple subnets on a network. So then, we end up with a new network, a new
subnet and a new port. My personal vote is to go this route.
---
Why I want tons of IPv6 within each Instance?
A.: Because we can! I mean, we can go back to the days when we had 1 website
per 1 public IP (i.e. using IP-Based Virtual Hosts with Apache - I prefer this
approach).
Also, we can try to turn the Floating IPv6, in some kind of Floating IPv6
Range, this way, we can for example, allocate millions of IPs per Instance,
like this in DHCPv6: range6 2001:db8:1:1::1000 2001:db8:1:1000:1000;...
I'd also argue for security/policy/reserved addressing reasons. Also, let's
not get into the habit of assigning loads of addresses. Each network needs to
be a /64, and going all out means you're back to the exhaustion issue we have
in IPv4 ;)
---
NOTE: I prefer multiple IPs per Instance, instead of 1 IP per Instance, when
using VT, unless, of course, the Instances are based on Docker, so, with it, I
can easily see millions of tiny instances, each of it with its own IPv6
address, without the overhead of virtualized environment. So, with Docker, this
Floating IPv6 Range doesn't seems to be useful...
* I know that there is NAT66 out there but, who is actually using it?! I'll
never use this thing. Personally I dislike NAT very much, mostly because it
breaks the end-to-end Internet connectivity, effectively kicking you out from
the real Internet, and it is just a workaround created to deal with IPv4
exhaustion.
As a long-time IPv6 engineer, I will advocate against NAT wherever I possibly
can. +1 to this!
BTW, please guys, let me know if this isn't the right place to post ideas for
OpenStack / feature requests... I don't want to bloat this list with
undesirable messages.
It absolutely is! Also, you might want to join the discussions for the IPv6
sub-team: https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam
Best Regards,
Thiago Martins
-Anthony Veiga
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
