Thiago, Throwing IPv6 in the mix does blur the distinction between internal and external. In the blueprints, internal and external have more to do with whether we're dealing with the name/IP mapping internally to Neutron or externally to Neutron by integrating with an external DNS service. In other words, are DNS entries being consumed by other VMs on the same network from the dnsmasq server or are they being consumed external to the network from DNSaaS.
This is the type of question that I was looking forward to to help flesh out the blueprints to make them IPv6 friendly. Thanks for asking. I don't think that we need a separate blueprint as I think that IPv6 will be worked in to the current Neutron architecture. Sean Collins made one comment on my blueprint that IPv6 addresses are being inserted in to the dnsmasq host file. Thoughts? Carl On Wed, Apr 30, 2014 at 4:10 PM, Martinx - ジェームズ <thiagocmarti...@gmail.com> wrote: > Carl, > > Let me ask you something... > > If my cloud is IPv6-Only based (that's my intention), which blueprint will > fit on it (internal-dns-resolution or external-dns-resolution) ? > > Since IPv6 is all public, don't you think that we (might) need a new > blueprint for IPv6-Only, like just "dns-resolution"? > > BTW, maybe this "dns-resolution" for IPv6-Only networks (if desired) might > also handle the IPv4 Floating IPs (in a NAT46 fashion)... My plan is to have > IPv4 only at the border (i.e. only at the qg-* interface within the > Namespace router (NAT46 will happen here)), so, the old internet > infrastructure will be able to reach a IPv6-Only project subnet using a well > know FQDN DNS IPv4 entry... > > Best! > Thiago > > > On 29 April 2014 17:09, Carl Baldwin <c...@ecbaldwin.net> wrote: >> >> The design summit discussion topic I submitted [1] for my DNS >> blueprints [2][3][4] and this one [5] just missed the cut for the >> design session schedule. It stung a little to be turned down but I >> totally understand the time and resource constraints that drove the >> decision. >> >> I feel this is an important subject to discuss because the end result >> will be a better cloud user experience overall. The design summit >> could be a great time to bring together interested parties from >> Neutron, Nova, and Designate to discuss the integration that I propose >> in these blueprints. >> >> DNS for IPv6 in Neutron is also something I would like to discuss. >> Mostly, I'd like to get a good sense for where this is at currently >> with the current Neutron dns implementation (dnsmasq) and how it will >> fit in. >> >> I've created an etherpad to help us coordinate [6]. If you are >> interested, please go there and help me flesh it out. >> >> Carl Baldwin >> Neutron L3 Subteam >> >> [1] http://summit.openstack.org/cfp/details/403 >> [2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution >> [3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution >> [4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution >> [5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem >> [6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
