On Tue, Sep 15, 2015 at 5:09 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote:
> Unfortunately, I haven't had enough chance to play with ipv6 yet. > > I still think ipv6 with floating ip's probably makes sense though. > > In ipv4, the floating ip's solve one particular problem: > > End Users want to be able to consume a service provided by a VM. They have > two options: > 1. contact the ip directly > 2. use DNS. > > DNS is preferable, since humans don't remember ip's very well. IPv6 is > much harder to remember then v4 too. > > 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. > I'm curious if you tried out Designate / DNSaaS. > > 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. > > I'd expect v6 usage to have the same issues. > > The floating ip is great in that its an abstraction of a contactable > address, separate from any VM it may currently be bound to. > > 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. > > 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. > > Thanks, > Kevin > > > > > > > ________________________________________ > From: Clark Boylan [cboy...@sapwetik.org] > Sent: Tuesday, September 15, 2015 1:06 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed > 'default' network model > > On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote: > > We run several clouds where there are multiple external networks. the > > "just run it in on THE public network" doesn't work. :/ > Maybe this would be better expressed as "just run it on an existing > public network" then? > > > > I also strongly recommend to users to put vms on a private network and > > use floating ip's/load balancers. For many reasons. Such as, if you > > don't, the ip that gets assigned to the vm helps it become a pet. you > > can't replace the vm and get the same IP. Floating IP's and load > > balancers can help prevent pets. It also prevents security issues with > > DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or > > more the number of instances that are on the private network. Sure its > > easy to put everything on the public network, but it provides much better > > security if you only put what you must on the public network. Consider > > the internet. would you want to expose every device in your house > > directly on the internet? No. you put them in a private network and poke > > holes just for the stuff that does. we should be encouraging good > > security practices. If we encourage bad ones, then it will bite us later > > when OpenStack gets a reputation for being associated with compromises. > There are a few issues with this. Neutron IPv6 does not support floating > IPs. So now you have to use two completely different concepts for > networking on a single dual stacked VM. IPv4 goes on a private network > and you attach a floating IP. IPv6 is publicly routable. If security and > DNS and not making pets were really the driving force behind floating > IPs we would see IPv6 support them too. These aren't the reasons > floating IPs exist, they exist because we are running out of IPv4 > addresses and NAT is everyones preferred solution to that problem. But > that doesn't make it a good default for a cloud; use them if you are > affected by an IP shortage. > > Nothing prevents you from load balancing against public IPs to address > the DNS and firewall rule concerns (basically don't make pets). This > works great and is how OpenStack's git mirrors work. > > It is also easy to firewall public IPs using Neutron via security groups > (and possibly the firewall service? I have never used it and don't > know). All this to say I think it is reasonable to use public shared > networks by default particularly since IPv6 does not have any concept of > a floating IP in Neutron so using them is just odd unless you really > really need them and you aren't actually any less secure. > > Not to get too off topic, but I would love it if all the devices in my > home were publicly routable. I can use my firewall to punch holes for > them, NAT is not required. Unfortunately I still have issues with IPv6 > at home. Maybe one day this will be a reality :) > > > > I do consider making things as simple as possible very important. but > > that is, make them as simple as possible, but no simpler. There's danger > > here of making things too simple. > > > > Thanks, > > Kevin > > > > Clark > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev