IPv6 Subnet Support for AdvanceZone NAT

hstan77 commented 3 years ago

ISSUE TYPE

Feature Idea

COMPONENT NAME


Current Cloudstack lack of Support for IPv6 Advance Zone NAT. I would like to suggest allocation of IPv6 Subnet to Advance zone with NAT.

Suggested WorkFlow:
- Admin add IPv6 subnet (for example , with /48)  to Cloudstack.
- Cloudstack create available /64 subnet to AdvanceZone with NAT 
- IPv6 Gateway assigned to Virtual Router with /64 subnet .
-  VM created under this VR, will get the IPv6 via DHCP6 from VR,  or system auto generated Ipv6 .

CLOUDSTACK VERSION

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

wido commented 3 years ago

But the VMs will use IPv6 NAT to communicate with the outside world?

hstan77 commented 3 years ago

Not IPv6 NAT, it not suppose to run NAT on ipv6 .

I suggest is , for Advance zone with NAT, allow assign /64 ipv6 subnet to VR, and VR. wil be IPv6 Gateway for all the VM inside the Network, VR will be. the DHCP6 for the /64 subnet allocated to him.

If the VM inside the VR. have allow DHCP6, then it will. IPv6 Ip allocated to it. This is not NAT, This will be each VM one IPv6 Address.

If they do not want the IPv6 for VM, then disable the DHCP6 in VM, and only get the LAN IPv4.

wido commented 3 years ago

So how will you route this to the VR? You will need to run BGP or OSPF in the VR to talk to upper layers in the network. How did you envision this?

mkriegs commented 3 years ago

Why is no systemvm version with frr installed out there? So u can usw mp-bgp/ospf/egrp to route and Filter stuff. Nearly Same setup for your kvmhost @wido ?

wido commented 3 years ago

Yes, FRR with BGP/OSPFv3 would be great and very welcome!

It's just that somebody needs to write this implementation. This would allow for routing IPv4 and IPv6 public IP-space through the VR and have the VR perform firewalling and all kinds of other things.

I would like to see this in CloudStack as well. We just need somebody to design and implement it.

hstan77 commented 3 years ago

May be consider OSPF or BGP over. soft router , can consider the quagga, frr or exabgp, or bird.

Bird is quite easy for text configuration and reload for taking effect. Or doing script api integration.

If BGP or OSPF is complicated, It can be just static route , and IPv6 router out there need to have static route too.

wido commented 3 years ago

May be consider OSPF or BGP over. soft router , can consider the quagga, frr or exabgp, or bird.

Bird is quite easy for text configuration and reload for taking effect. Or doing script api integration.

If BGP or OSPF is complicated, It can be just static route , and IPv6 router out there need to have static route too.

Yes, Quagga or Frr can do this work inside the VR.

The main point is that somebody needs to implement it and test it. That's the main issue.

mkriegs commented 3 years ago

yeah its lots of work to do with all the test and stuff. Somethink like this ? https://github.com/apache/cloudstack/tree/master/systemvm/debian/opt/cloud/bin

there are some guys working on Integrate Tungsten Fabric integration so its may not need?!

mkriegs commented 3 years ago

https://github.com/packethost/packet-networking or https://github.com/packethost/network-helpers/blob/master/routers/frr/README.md

wido commented 3 years ago

@mkriegs Yes, the management server needs to do the work.

But again, the routing itself, either BGP or OSPF isn't really the problem. The point is the whole orchestration which is way more difficult.

I think that OSPFv3 is the easiest as BGP requires static IP adresses for the VR and OSPFv3 is more dynamic.

The main development work will be in the management server where you need extra models and logic.

This then needs to be pushed to the VR and translated into configuration of FRR/Bird.

Do-able, but not a super easy task.

weizhouapache commented 3 years ago

@wido @GabrielBrascher @mkriegs @hstan77 @luhaijiao we are investigating the ipv6 support in cloudstack, (see my colleague Alex's email in users/dev mailing list: https://markmail.org/message/dd7uihxwpav6jhkc). It would be nice to get your input.

hstan77 commented 3 years ago

Hi All,

i suggested before in on gitshub to do like this, may be can consider it:

Physical Router have IPv6 with /48 prefix

Cloudstack allocates each VR with one /64 prefix , and VR will have function of DHCP6 to assign to the VM . Cloudstack VR have a default route to the /48 IP in Physical Router.

Cloudstack only allocates the /64 of /48 that available in Physical router to VR. and VR assign IPv6 via DHCP6 to the VM.

The router side need to make sure the /48 is only use for Cloudstack , but not self allocate it to others to avoid overlap.

For IPv6, minimum to use in Router is /48 cause that is like minimum prefix to annocue to outside world, This /48 is similar to /24 in IPv4 . While Ipv6 /64 is similar to /32 in IPv4 k which is like a single IP . So in this way, it shall no need any BGP / OSPF session between Cloustack and Physical Router. The traffic will reach /64 at VR and VR route to VM single IPv6

We can try on this.

On Tue, Jul 13, 2021 at 5:14 PM Wei Zhou @.***> wrote:

@wido https://github.com/wido @GabrielBrascher https://github.com/GabrielBrascher @mkriegs https://github.com/mkriegs @hstan77 https://github.com/hstan77 @luhaijiao https://github.com/luhaijiao we are investigating the ipv6 support in cloudstack, (see my colleague Alex's email in users/dev mailing list: https://markmail.org/message/dd7uihxwpav6jhkc). It would be nice to get your input.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apache/cloudstack/issues/4463#issuecomment-878919734, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARFNGASVGGUS5QC4E4AX7O3TXP7YBANCNFSM4TSMJQXA .

-- Regards, Hean Seng

apache / cloudstack