Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

2015-05-08 Thread Andrew Ruthven
On Wed, 2015-05-06 at 02:46 -0400, Mike Spreitzer wrote:
 While I am a Neutron operator, I am also a customer of a lower layer
 network provider.  That network provider will happily give me a
 few /64.  How do I serve IPv6 subnets to lots of my tenants?  In the
 bad old v4 days this would be easy: a tenant puts all his stuff on his
 private networks and NATs (e.g., floating IP) his edge servers onto a
 public network --- no need to align tenant private subnets with public
 subnets.  But with no NAT for v6, there is no public/private
 distinction --- I can only give out the public v6 subnets that I am
 given.  Yes, NAT is bad.  But not being able to get your job done is
 worse. 

I would suggest that you talk to your network provider, or apply to your
local RIR to obtain Provider Independent address space. It should be
relatively trivial to obtain a significant amount of IPv6 address space.
Trying to make this work with only a few /64s is going to lead to a
world of pain.

Cheers,
Andrew 

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz | linux.conf.au 2015 
  New Zealand's only Cloud:   |  BeAwesome in Auckland, NZ
https://catalyst.net.nz/cloud | http://lca2015.linux.org.au



__
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


Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

2015-05-07 Thread John Davidge (jodavidg)
On the subject of Prefix Delegation - yes, the external system is
responsible for the routing. Here¹s a couple of video guides on using
PD in Neutron and setting up the Prefix Delegation Server (in this case
a dibbler server):

Using Neutron PD: https://www.youtube.com/watch?v=wI830s881HQ

Configuring the PD server: https://www.youtube.com/watch?v=zfsFyS01Fn0

The patch is up for review at: https://review.openstack.org/#/c/158697

And the networking guide docs: https://review.openstack.org/#/c/178739

John

On 06/05/2015 17:57, Carl Baldwin c...@ecbaldwin.net wrote:


On Wed, May 6, 2015 at 12:46 AM, Mike Spreitzer mspre...@us.ibm.com
wrote:
 While I am a Neutron operator, I am also a customer of a lower layer
network
 provider.  That network provider will happily give me a few /64.  How
do I
 serve IPv6 subnets to lots of my tenants?  In the bad old v4 days this
would
 be easy: a tenant puts all his stuff on his private networks and NATs
(e.g.,
 floating IP) his edge servers onto a public network --- no need to align
 tenant private subnets with public subnets.  But with no NAT for v6,
there
 is no public/private distinction --- I can only give out the public v6
 subnets that I am given.  Yes, NAT is bad.  But not being able to get
your
 job done is worse.

Mike, in this paragraph, you're hitting on something that has been on
my mind for a while.  We plan to cover this problem in detail in this
talk [1] and we're defining some work for Liberty to better address it
[2][3].  You hit the nail on the head, there is no distinguishing
private and public IP addresses in Neutron currently with IPv6.

Kilo's new subnet pool feature is a start.  It will allow you to
create a shared subnet pool including the /64s from your service
provider.  Tenants can then create a subnet getting an allocation from
it automatically.  However, given the current state of things, there
will be some manual work on the gateway router to route them to the
tenant's router.

Prefix delegation -- which looks on track for Liberty -- is another
option which could fill this void.  It will allow a router to get a
prefix delegation from an external PD system which will be useable on
a tenant subnet.  Presumably the external system will take care of
routing the subnet to the appropriate tenant router.

Carl

[1] http://sched.co/2qdm
[2] https://review.openstack.org/#/c/180267/
[3] https://review.openstack.org/#/c/125401/

__
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


Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

2015-05-06 Thread Mike Spreitzer
Robert Li (baoli) ba...@cisco.com wrote on 05/05/2015 09:02:08 AM:

 Currently dual stack is supported. Can you be specific on what 
 interoperation/transition techniques you are interested in? We’ve 
 been thinking about NAT64 (stateless or stateful).
 
 thanks,
 Robert
 
 On 5/4/15, 9:56 PM, Mike Spreitzer mspre...@us.ibm.com wrote:
 
 Does Neutron support any of the 4/6 interoperation/transition 
 techniques?  I wear an operator's hat nowadays, and want to make 
 IPv6 as useful and easy to use as possible for my tenants.  I think 
 the interoperation/transition techniques will play a big role in this. 


Is dual stacking working in routers now?  At the moment I am still using 
Juno, but plan to move to Kilo.

I want to encourage my tenants to use as much IPv6 as possible.  But I 
expect some will have to keep some of their workload on v4 (I know there 
is on-going work to get many application frameworks up to v6 speed, and it 
is not complete yet).  I expect some tenants could be mixed: some workload 
on v4 and some on v6.  Such a tenant would appreciate a NAT between his v6 
space and his v4 space.  This is the easiest cases --- sections 2.5 and 
2.6 --- of RFC 6144.

I would prefer to do it in a stateless way if possible.  That would be 
pretty easy if Neutron and Nova were willing to accept an IPv6 subnet that 
is much smaller than 2^64 addresses.  I see that my macs differ only in 
their last 24 bits.

Some tenants could put their entire workload on v6, but that workload 
would be unreachable from customers of all those ISPs (such as mine, 
CableVision) that deny IPv6 service to their customers.  There are 
techniques for coping, and Teredo looks like a pretty good one.  It has 
been shipped in Windows for years.  Yet I can not find a Windows machine 
where the Teredo actually works.  What's up with that?  If Windows somehow 
got its Teredo, or other, act together, that would be only half the job; 
Teredo requires something from the server side as well, right?

Supposing a focus on mobile, where IPv6 is much more available, and/or 
progress by Microsoft and/or other ISPs, my tenant might face a situation 
where his clients could come in over v6 but some of his servers still have 
to run on v4.  That's section 2.3 of RFC 6144.

While I am a Neutron operator, I am also a customer of a lower layer 
network provider.  That network provider will happily give me a few /64. 
How do I serve IPv6 subnets to lots of my tenants?  In the bad old v4 days 
this would be easy: a tenant puts all his stuff on his private networks 
and NATs (e.g., floating IP) his edge servers onto a public network --- no 
need to align tenant private subnets with public subnets.  But with no NAT 
for v6, there is no public/private distinction --- I can only give out the 
public v6 subnets that I am given.  Yes, NAT is bad.  But not being able 
to get your job done is worse.


Sean M. Collins s...@coreitpro.com wrote on 05/05/2015 06:26:28 AM:

 I think that Neutron exposes enough primitives through the API that
 advanced services for handling your transition technique of choice could
 be built.

I think that is right, if I am willing to assume Neutron is using OVS --- 
or build a bunch of alternatives that correspond to all the Neutron 
plugins and mechanisms that I might encounter.  And it would feel a lot 
like Neutron implementation work.  Really, it is one instance of doing 
some NFV.


Thanks,
Mike

__
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


Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

2015-05-06 Thread Carl Baldwin
On Wed, May 6, 2015 at 12:46 AM, Mike Spreitzer mspre...@us.ibm.com wrote:
 While I am a Neutron operator, I am also a customer of a lower layer network
 provider.  That network provider will happily give me a few /64.  How do I
 serve IPv6 subnets to lots of my tenants?  In the bad old v4 days this would
 be easy: a tenant puts all his stuff on his private networks and NATs (e.g.,
 floating IP) his edge servers onto a public network --- no need to align
 tenant private subnets with public subnets.  But with no NAT for v6, there
 is no public/private distinction --- I can only give out the public v6
 subnets that I am given.  Yes, NAT is bad.  But not being able to get your
 job done is worse.

Mike, in this paragraph, you're hitting on something that has been on
my mind for a while.  We plan to cover this problem in detail in this
talk [1] and we're defining some work for Liberty to better address it
[2][3].  You hit the nail on the head, there is no distinguishing
private and public IP addresses in Neutron currently with IPv6.

Kilo's new subnet pool feature is a start.  It will allow you to
create a shared subnet pool including the /64s from your service
provider.  Tenants can then create a subnet getting an allocation from
it automatically.  However, given the current state of things, there
will be some manual work on the gateway router to route them to the
tenant's router.

Prefix delegation -- which looks on track for Liberty -- is another
option which could fill this void.  It will allow a router to get a
prefix delegation from an external PD system which will be useable on
a tenant subnet.  Presumably the external system will take care of
routing the subnet to the appropriate tenant router.

Carl

[1] http://sched.co/2qdm
[2] https://review.openstack.org/#/c/180267/
[3] https://review.openstack.org/#/c/125401/

__
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


Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

2015-05-05 Thread Robert Li (baoli)
Hi Mike,

Currently dual stack is supported. Can you be specific on what 
interoperation/transition techniques you are interested in? We’ve been thinking 
about NAT64 (stateless or stateful).

thanks,
Robert

On 5/4/15, 9:56 PM, Mike Spreitzer 
mspre...@us.ibm.commailto:mspre...@us.ibm.com wrote:

Does Neutron support any of the 4/6 interoperation/transition techniques?  I 
wear an operator's hat nowadays, and want to make IPv6 as useful and easy to 
use as possible for my tenants.  I think the interoperation/transition 
techniques will play a big role in this.

Thanks,
Mike
__
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


Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

2015-05-05 Thread Sean M. Collins
I think that Neutron exposes enough primitives through the API that
advanced services for handling your transition technique of choice could
be built.
-- 
Sean M. Collins

__
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-dev] [neutron] IPv4 transition/interoperation with IPv6

2015-05-04 Thread Mike Spreitzer
Does Neutron support any of the 4/6 interoperation/transition techniques? 
I wear an operator's hat nowadays, and want to make IPv6 as useful and 
easy to use as possible for my tenants.  I think the 
interoperation/transition techniques will play a big role in this.

Thanks,
Mike__
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