<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 15, 2015 at 5:09 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Unfortunately, I haven't had enough chance to play with ipv6 yet.<br>
<br>
I still think ipv6 with floating ip's probably makes sense though.<br>
<br>
In ipv4, the floating ip's solve one particular problem:<br>
<br>
End Users want to be able to consume a service provided by a VM. They have two options:<br>
1. contact the ip directly<br>
2. use DNS.<br>
<br>
DNS is preferable, since humans don't remember ip's very well. IPv6 is much harder to remember then v4 too.<br>
<br>
DNS has its own issues, mostly, its usually not very quick to get a DNS entry updated.  At our site (and I'm sure, others), I'm afraid to say in some cases it takes as long as 24 hours to get updates to happen. Even if that was fixed, caching can bite you too.<br></blockquote><div><br></div><div>I'm curious if you tried out Designate / DNSaaS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, when you register a DNS record, the ip that its pointing at, kind of becomes a set of state. If it can't be separated from a VM its a bad thing. You can move it from VM to VM and your VM is not a pet. But, if your IP is allocated to the VM specifically, as non Floating IP's are, you run into problems if your VM dies and you have to replace it. If your unlucky, it dies, and someone else gets allocated the fixed ip, and now someone else's server is sitting on your DNS entry! So you are very unlikely to want to give up your VM, turning it into a pet.<br>
<br>
I'd expect v6 usage to have the same issues.<br>
<br>
The floating ip is great in that its an abstraction of a contactable address, separate from any VM it may currently be bound to.<br>
<br>
You allocate a floating ip. You can then register it with DNS, and another tenant can not get accidentally assigned it. You can move it from vm to vm until your done with it. You can Unregister it from DNS, and then it is safe to return to others to use.<br>
<br>
To me, the NAT aspect of it is a secondary thing. Its primary importance is in enabling things to be more cattleish and helping with dns security.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<br>
<br>
<br>
<br>
<br>
________________________________________<br>
From: Clark Boylan [<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>]<br>
Sent: Tuesday, September 15, 2015 1:06 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<span class="im HOEnZb">Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model<br>
<br>
</span><div class="HOEnZb"><div class="h5">On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote:<br>
> We run several clouds where there are multiple external networks. the<br>
> "just run it in on THE public network" doesn't work. :/<br>
Maybe this would be better expressed as "just run it on an existing<br>
public network" then?<br>
><br>
> I also strongly recommend to users to put vms on a private network and<br>
> use floating ip's/load balancers. For many reasons. Such as, if you<br>
> don't, the ip that gets assigned to the vm helps it become a pet. you<br>
> can't replace the vm and get the same IP. Floating IP's and load<br>
> balancers can help prevent pets. It also prevents security issues with<br>
> DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or<br>
> more the number of instances that are on the private network. Sure its<br>
> easy to put everything on the public network, but it provides much better<br>
> security if you only put what you must on the public network. Consider<br>
> the internet. would you want to expose every device in your house<br>
> directly on the internet? No. you put them in a private network and poke<br>
> holes just for the stuff that does. we should be encouraging good<br>
> security practices. If we encourage bad ones, then it will bite us later<br>
> when OpenStack gets a reputation for being associated with compromises.<br>
There are a few issues with this. Neutron IPv6 does not support floating<br>
IPs. So now you have to use two completely different concepts for<br>
networking on a single dual stacked VM. IPv4 goes on a private network<br>
and you attach a floating IP. IPv6 is publicly routable. If security and<br>
DNS and not making pets were really the driving force behind floating<br>
IPs we would see IPv6 support them too. These aren't the reasons<br>
floating IPs exist, they exist because we are running out of IPv4<br>
addresses and NAT is everyones preferred solution to that problem. But<br>
that doesn't make it a good default for a cloud; use them if you are<br>
affected by an IP shortage.<br>
<br>
Nothing prevents you from load balancing against public IPs to address<br>
the DNS and firewall rule concerns (basically don't make pets). This<br>
works great and is how OpenStack's git mirrors work.<br>
<br>
It is also easy to firewall public IPs using Neutron via security groups<br>
(and possibly the firewall service? I have never used it and don't<br>
know). All this to say I think it is reasonable to use public shared<br>
networks by default particularly since IPv6 does not have any concept of<br>
a floating IP in Neutron so using them is just odd unless you really<br>
really need them and you aren't actually any less secure.<br>
<br>
Not to get too off topic, but I would love it if all the devices in my<br>
home were publicly routable. I can use my firewall to punch holes for<br>
them, NAT is not required. Unfortunately I still have issues with IPv6<br>
at home. Maybe one day this will be a reality :)<br>
><br>
> I do consider making things as simple as possible very important. but<br>
> that is, make them as simple as possible, but no simpler. There's danger<br>
> here of making things too simple.<br>
><br>
> Thanks,<br>
> Kevin<br>
><br>
<br>
Clark<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>