RE: IPV6 in Isolated/VPC networks

[Alex Mattioli]

Hi Wido,
That's pretty much in line with our thoughts, thanks for the input.  I believe 
we agree on the following points then:

- FRR with BGP (no OSPF)
- Route /48 (or/56) down to the VR
- /64 per network
- SLACC for IP addressing

I believe the next big question is then "on which level of ACS do we manage AS 
numbers?".  I see two options:
1) Private AS number on a per-zone basis
2) Root Admin assigned AS number on a domain/account basis
3) End-user driven AS number on a per network basis (for bring your own AS and 
IP scenario)

Thoughts?

Cheers
Alex

 


-Original Message-
From: Wido den Hollander  
Sent: 13 July 2021 15:08
To: dev@cloudstack.apache.org; Alex Mattioli 
Cc: Wei Zhou ; Rohit Yadav ; 
Gabriel Beims Bräscher 
Subject: Re: IPV6 in Isolated/VPC networks



On 7/7/21 1:16 PM, Alex Mattioli wrote:
> Hi all,
> @Wei Zhou @Rohit 
> Yadav and myself are investigating how to 
> enable IPV6 support on Isolated and VPC networks and would like your input on 
> it.
> At the moment we are looking at implementing FRR with BGP (and possibly OSPF) 
> on the ACS VR.
> 
> We are looking for requirements, recommendations, ideas, rants, etc...etc...
> 

Ok! Here we go.

I think that you mean that the VR will actually route the IPv6 traffic and for 
that you need to have a way of getting a subnet routed to the VR.

BGP is probably you best bet here. Although OSPFv3 technically supports this it 
is very badly implemented in Frr for example.

Now FRR is a very good router and one of the fancy features it supports is BGP 
Unnumered. This allows for auto configuration of BGP over a L2 network when 
both sides are sending Router Advertisements. This is very easy for flexible 
BGP configurations where both sides have dynamic IPs.

What you want to do is that you get a /56, /48 or something which is
>/64 bits routed to the VR.

Now you can sub-segment this into separate /64 subnets. You don't want to go 
smaller then a /64 is that prevents you from using SLAAC for IPv6 address 
configuration. This is how it works for Shared Networks now in Basic and 
Advanced Zones.

FRR can now also send out the Router Advertisements on the downlinks sending 
out:

- DNS servers
- DNS domain
- Prefix (/64) to be used

There is no need for DHCPv6. You can calculate the IPv6 address the VM will 
obtain by using the MAC and the prefix.

So in short:

- Using BGP you routed a /48 to the VR
- Now you split this into /64 subnets towards the isolated networks

Wido

> Alex Mattioli
> 
>  
> 
> 

RE: IPV6 in Isolated/VPC networks

[Alex Mattioli]

Hi Kristaps,
Thanks for the nice schematic, pretty much where we were going.

I just didn't understand your first statement " I would like to argue that 
implementer dynamic routing protocol and associated security 
problems/challenges with it to have IPv6 route inserted in L3 router/s is not a 
good goal."

Would you mind clarifying/expanding on it please?

Thanks
Alex

 


-Original Message-
From: Kristaps Cudars  
Sent: 13 July 2021 20:44
To: dev@cloudstack.apache.org
Subject: Re: IPV6 in Isolated/VPC networks

Hi,

I would like to argue that implementer dynamic routing protocol and associated 
security problems/challenges with it to have IPv6 route inserted in L3 router/s 
is not a good goal.

In my opinion dynamic routing on VR would be interesting to scale availability 
of service across several datacenter if they participate in same AS. With BGP 
you could advertise same IP form different VR located in different DC IPv6/128 
or/and IPv4/32.

I would delegate task of router creation to ACS somewhere at moment of VR 
creation. 
It could happen over ssh/snmp/api rest or ansible- something that supports wide 
variety of vendors/devices.

Have created rough schematic on how it could look on VR side: 
https://dice.lv/acs/ACS_router_v2.pdf


On 2021/07/13 13:08:20, Wido den Hollander  wrote: 
> 
> 
> On 7/7/21 1:16 PM, Alex Mattioli wrote:
> > Hi all,
> > @Wei Zhou @Rohit 
> > Yadav and myself are investigating how to 
> > enable IPV6 support on Isolated and VPC networks and would like your input 
> > on it.
> > At the moment we are looking at implementing FRR with BGP (and possibly 
> > OSPF) on the ACS VR.
> > 
> > We are looking for requirements, recommendations, ideas, rants, etc...etc...
> > 
> 
> Ok! Here we go.
> 
> I think that you mean that the VR will actually route the IPv6 traffic 
> and for that you need to have a way of getting a subnet routed to the VR.
> 
> BGP is probably you best bet here. Although OSPFv3 technically 
> supports this it is very badly implemented in Frr for example.
> 
> Now FRR is a very good router and one of the fancy features it 
> supports is BGP Unnumered. This allows for auto configuration of BGP 
> over a L2 network when both sides are sending Router Advertisements. 
> This is very easy for flexible BGP configurations where both sides have 
> dynamic IPs.
> 
> What you want to do is that you get a /56, /48 or something which is
> >/64 bits routed to the VR.
> 
> Now you can sub-segment this into separate /64 subnets. You don't want 
> to go smaller then a /64 is that prevents you from using SLAAC for 
> IPv6 address configuration. This is how it works for Shared Networks 
> now in Basic and Advanced Zones.
> 
> FRR can now also send out the Router Advertisements on the downlinks 
> sending out:
> 
> - DNS servers
> - DNS domain
> - Prefix (/64) to be used
> 
> There is no need for DHCPv6. You can calculate the IPv6 address the VM 
> will obtain by using the MAC and the prefix.
> 
> So in short:
> 
> - Using BGP you routed a /48 to the VR
> - Now you split this into /64 subnets towards the isolated networks
> 
> Wido
> 
> > Alex Mattioli
> > 
> >  
> > 
> > 
> 

RE: IPV6 in Isolated/VPC networks

[Alex Mattioli]

Hi Hean,
Do you mean using NAT66?  Or did I miss something?

Regards,
Alex

 


-Original Message-
From: Hean Seng  
Sent: 14 July 2021 16:44
To: us...@cloudstack.apache.org
Cc: Wido den Hollander ; dev@cloudstack.apache.org; Wei Zhou 
; Rohit Yadav ; Gabriel 
Beims Bräscher 
Subject: Re: IPV6 in Isolated/VPC networks

Hi

I replied in another thread, i think do not need implement BGP or OSPF, that 
would be complicated .

We only need assign  IPv6 's /64 prefix to Virtual Router (VR) in NAT zone, and 
the VR responsible to deliver single IPv6 to VM via DHCP6.

In VR, you need to have Default IPv6 route to  Physical Router's /48. IP as
IPv6 Gateway.  Thens should be done .

Example :
Physical Router Interface
 IPv6 IP : 2000:::1/48

Cloudstack  virtual router : 2000::200:201::1/64 with default ipv6 route to 
router ip 2000:::1 and Clodustack Virtual router dhcp allocate IP to VM , 
and  VM will have default route to VR. IPv6 2000::200:201::1

So in cloudstack need to allow  user to enter ,  IPv6 gwateway , and the
/48 Ipv6 prefix , then it will self allocate the /64 ip to the VR , and 
maintain make sure not ovelap allocation







On Wed, Jul 14, 2021 at 8:55 PM Alex Mattioli 
wrote:

> Hi Wido,
> That's pretty much in line with our thoughts, thanks for the input.  I 
> believe we agree on the following points then:
>
> - FRR with BGP (no OSPF)
> - Route /48 (or/56) down to the VR
> - /64 per network
> - SLACC for IP addressing
>
> I believe the next big question is then "on which level of ACS do we 
> manage AS numbers?".  I see two options:
> 1) Private AS number on a per-zone basis
> 2) Root Admin assigned AS number on a domain/account basis
> 3) End-user driven AS number on a per network basis (for bring your 
> own AS and IP scenario)
>
> Thoughts?
>
> Cheers
> Alex
>
>
>
>
> -Original Message-
> From: Wido den Hollander 
> Sent: 13 July 2021 15:08
> To: dev@cloudstack.apache.org; Alex Mattioli 
> 
> Cc: Wei Zhou ; Rohit Yadav < 
> rohit.ya...@shapeblue.com>; Gabriel Beims Bräscher 
> 
> Subject: Re: IPV6 in Isolated/VPC networks
>
>
>
> On 7/7/21 1:16 PM, Alex Mattioli wrote:
> > Hi all,
> > @Wei Zhou @Rohit Yadav rohit.ya...@shapeblue.com> and myself are investigating how to enable
> IPV6 support on Isolated and VPC networks and would like your input on it.
> > At the moment we are looking at implementing FRR with BGP (and 
> > possibly
> OSPF) on the ACS VR.
> >
> > We are looking for requirements, recommendations, ideas, rants,
> etc...etc...
> >
>
> Ok! Here we go.
>
> I think that you mean that the VR will actually route the IPv6 traffic 
> and for that you need to have a way of getting a subnet routed to the VR.
>
> BGP is probably you best bet here. Although OSPFv3 technically 
> supports this it is very badly implemented in Frr for example.
>
> Now FRR is a very good router and one of the fancy features it 
> supports is BGP Unnumered. This allows for auto configuration of BGP 
> over a L2 network when both sides are sending Router Advertisements. 
> This is very easy for flexible BGP configurations where both sides have 
> dynamic IPs.
>
> What you want to do is that you get a /56, /48 or something which is
> >/64 bits routed to the VR.
>
> Now you can sub-segment this into separate /64 subnets. You don't want 
> to go smaller then a /64 is that prevents you from using SLAAC for 
> IPv6 address configuration. This is how it works for Shared Networks 
> now in Basic and Advanced Zones.
>
> FRR can now also send out the Router Advertisements on the downlinks 
> sending out:
>
> - DNS servers
> - DNS domain
> - Prefix (/64) to be used
>
> There is no need for DHCPv6. You can calculate the IPv6 address the VM 
> will obtain by using the MAC and the prefix.
>
> So in short:
>
> - Using BGP you routed a /48 to the VR
> - Now you split this into /64 subnets towards the isolated networks
>
> Wido
>
> > Alex Mattioli
> >
> >
> >
> >
>
>

--
Regards,
Hean Seng

Re: RE: IPV6 in Isolated/VPC networks

[Kristaps Cudars]

Pony Mail is blocking me :(

Hi,

Elaborating on my previous email.

In my opinion SLAAC (StateLess Address Auto Configuration) is not good
candidate for VR as it was created for situations of connecting million
devices with less amount of effort and no micromanagement needed.

One example that coms in mind is- I want to reassign IPv6 from one instance
to another with SLAAC I will need to change mac address on instance. This
will introduce new workflows in ACS.

Suggestion would be to use same IPv4 services for IPv6 and have feature
parity between both protocols in dual-stack configuration as much as
possible. IPv4 will stay with NAT and IPv6 will be routable. Form ACS
interface and workflow perspective everything will stay same for both
protocols with excursion that IPv6 will not have source and destination NAT.

In Primate it can be handled with protocols selection dropdown, checkboxes,
additional fields in same isolated/vpc workflow.

Vision from user/admin perspective could look as following:

For Zones > Traffic Types > Public for existing or new add/edit IPv6

When isolated/vpc network is created you are presented with option to
enable or disable both protocols. (One of them should be enabled)

For IPv6 there must be predefined list of /64 networks that can be
automatically assigned.
In VR creation menu IPv6 is prefilled and not changeable by user.
It could be in Zones > Traffic Types > Internal

In case of isolated network public IP must be assigned in case of vpc its
already assigned.

At this point ACS should do api call/or something to insert route in L3
element.
You have two variables internal IPv6 network and public IPv6 address that
will form route entry.

In our case we are using Cisco NX-OS and it has NX-API. I stand for choice
and there are many more grate L3 devices. Inserting those variables in to
ansible that can play route add/remove against many vendors is better. List
can be git repository.
It also could be ACS api where you can get list public and internal ip
relations and how you form/create routing entries is up to you.
This can be something else proposed by others.

Or do it manually is also option for beginning/ small deployments/ lab.
Nothing bad happens if you do not create route instantly. It simply will
not work until route is created.

Probably it would be smart to have global option that enables/disable IPv6.

I’m accepting questions, something must be explained in more detail, rant…
that this is not good.

Re: IPV6 in Isolated/VPC networks

[Hean Seng]

Yes, sorry for that, can use NAT 6 also .I mentiioned DHCP6 , and you
can point the gateway to /48 gw, and this does not need any BGP.  Maintain
BGP or OSPF is good, but is a lot more complicated ,

On Wed, Jul 14, 2021 at 10:57 PM Alex Mattioli 
wrote:

> Hi Hean,
> Do you mean using NAT66?  Or did I miss something?
>
> Regards,
> Alex
>
>
>
>
> -Original Message-
> From: Hean Seng 
> Sent: 14 July 2021 16:44
> To: us...@cloudstack.apache.org
> Cc: Wido den Hollander ; dev@cloudstack.apache.org; Wei
> Zhou ; Rohit Yadav ;
> Gabriel Beims Bräscher 
> Subject: Re: IPV6 in Isolated/VPC networks
>
> Hi
>
> I replied in another thread, i think do not need implement BGP or OSPF,
> that would be complicated .
>
> We only need assign  IPv6 's /64 prefix to Virtual Router (VR) in NAT
> zone, and the VR responsible to deliver single IPv6 to VM via DHCP6.
>
> In VR, you need to have Default IPv6 route to  Physical Router's /48. IP as
> IPv6 Gateway.  Thens should be done .
>
> Example :
> Physical Router Interface
>  IPv6 IP : 2000:::1/48
>
> Cloudstack  virtual router : 2000::200:201::1/64 with default ipv6
> route to router ip 2000:::1 and Clodustack Virtual router dhcp allocate
> IP to VM , and  VM will have default route to VR. IPv6 2000::200:201::1
>
> So in cloudstack need to allow  user to enter ,  IPv6 gwateway , and the
> /48 Ipv6 prefix , then it will self allocate the /64 ip to the VR , and
> maintain make sure not ovelap allocation
>
>
>
>
>
>
>
> On Wed, Jul 14, 2021 at 8:55 PM Alex Mattioli  >
> wrote:
>
> > Hi Wido,
> > That's pretty much in line with our thoughts, thanks for the input.  I
> > believe we agree on the following points then:
> >
> > - FRR with BGP (no OSPF)
> > - Route /48 (or/56) down to the VR
> > - /64 per network
> > - SLACC for IP addressing
> >
> > I believe the next big question is then "on which level of ACS do we
> > manage AS numbers?".  I see two options:
> > 1) Private AS number on a per-zone basis
> > 2) Root Admin assigned AS number on a domain/account basis
> > 3) End-user driven AS number on a per network basis (for bring your
> > own AS and IP scenario)
> >
> > Thoughts?
> >
> > Cheers
> > Alex
> >
> >
> >
> >
> > -Original Message-
> > From: Wido den Hollander 
> > Sent: 13 July 2021 15:08
> > To: dev@cloudstack.apache.org; Alex Mattioli
> > 
> > Cc: Wei Zhou ; Rohit Yadav <
> > rohit.ya...@shapeblue.com>; Gabriel Beims Bräscher
> > 
> > Subject: Re: IPV6 in Isolated/VPC networks
> >
> >
> >
> > On 7/7/21 1:16 PM, Alex Mattioli wrote:
> > > Hi all,
> > > @Wei Zhou @Rohit Yadav > rohit.ya...@shapeblue.com> and myself are investigating how to enable
> > IPV6 support on Isolated and VPC networks and would like your input on
> it.
> > > At the moment we are looking at implementing FRR with BGP (and
> > > possibly
> > OSPF) on the ACS VR.
> > >
> > > We are looking for requirements, recommendations, ideas, rants,
> > etc...etc...
> > >
> >
> > Ok! Here we go.
> >
> > I think that you mean that the VR will actually route the IPv6 traffic
> > and for that you need to have a way of getting a subnet routed to the VR.
> >
> > BGP is probably you best bet here. Although OSPFv3 technically
> > supports this it is very badly implemented in Frr for example.
> >
> > Now FRR is a very good router and one of the fancy features it
> > supports is BGP Unnumered. This allows for auto configuration of BGP
> > over a L2 network when both sides are sending Router Advertisements.
> > This is very easy for flexible BGP configurations where both sides have
> dynamic IPs.
> >
> > What you want to do is that you get a /56, /48 or something which is
> > >/64 bits routed to the VR.
> >
> > Now you can sub-segment this into separate /64 subnets. You don't want
> > to go smaller then a /64 is that prevents you from using SLAAC for
> > IPv6 address configuration. This is how it works for Shared Networks
> > now in Basic and Advanced Zones.
> >
> > FRR can now also send out the Router Advertisements on the downlinks
> > sending out:
> >
> > - DNS servers
> > - DNS domain
> > - Prefix (/64) to be used
> >
> > There is no need for DHCPv6. You can calculate the IPv6 address the VM
> > will obtain by using the MAC and the prefix.
> >
> > So in short:
> >
> > - Using BGP you routed a /48 to the VR
> > - Now you split this into /64 subnets towards the isolated networks
> >
> > Wido
> >
> > > Alex Mattioli
> > >
> > >
> > >
> > >
> >
> >
>
> --
> Regards,
> Hean Seng
>


-- 
Regards,
Hean Seng

Re: IPV6 in Isolated/VPC networks

[Hean Seng]

Hi

I replied in another thread, i think do not need implement BGP or OSPF,
that would be complicated .

We only need assign  IPv6 's /64 prefix to Virtual Router (VR) in NAT zone,
and the VR responsible to deliver single IPv6 to VM via DHCP6.

In VR, you need to have Default IPv6 route to  Physical Router's /48. IP as
IPv6 Gateway.  Thens should be done .

Example :
Physical Router Interface
 IPv6 IP : 2000:::1/48

Cloudstack  virtual router : 2000::200:201::1/64 with default ipv6
route to router ip 2000:::1
and Clodustack Virtual router dhcp allocate IP to VM , and  VM will have
default route to VR. IPv6 2000::200:201::1

So in cloudstack need to allow  user to enter ,  IPv6 gwateway , and the
/48 Ipv6 prefix , then it will self allocate the /64 ip to the VR , and
maintain make sure not ovelap allocation







On Wed, Jul 14, 2021 at 8:55 PM Alex Mattioli 
wrote:

> Hi Wido,
> That's pretty much in line with our thoughts, thanks for the input.  I
> believe we agree on the following points then:
>
> - FRR with BGP (no OSPF)
> - Route /48 (or/56) down to the VR
> - /64 per network
> - SLACC for IP addressing
>
> I believe the next big question is then "on which level of ACS do we
> manage AS numbers?".  I see two options:
> 1) Private AS number on a per-zone basis
> 2) Root Admin assigned AS number on a domain/account basis
> 3) End-user driven AS number on a per network basis (for bring your own AS
> and IP scenario)
>
> Thoughts?
>
> Cheers
> Alex
>
>
>
>
> -Original Message-
> From: Wido den Hollander 
> Sent: 13 July 2021 15:08
> To: dev@cloudstack.apache.org; Alex Mattioli 
> Cc: Wei Zhou ; Rohit Yadav <
> rohit.ya...@shapeblue.com>; Gabriel Beims Bräscher 
> Subject: Re: IPV6 in Isolated/VPC networks
>
>
>
> On 7/7/21 1:16 PM, Alex Mattioli wrote:
> > Hi all,
> > @Wei Zhou @Rohit Yadav rohit.ya...@shapeblue.com> and myself are investigating how to enable
> IPV6 support on Isolated and VPC networks and would like your input on it.
> > At the moment we are looking at implementing FRR with BGP (and possibly
> OSPF) on the ACS VR.
> >
> > We are looking for requirements, recommendations, ideas, rants,
> etc...etc...
> >
>
> Ok! Here we go.
>
> I think that you mean that the VR will actually route the IPv6 traffic and
> for that you need to have a way of getting a subnet routed to the VR.
>
> BGP is probably you best bet here. Although OSPFv3 technically supports
> this it is very badly implemented in Frr for example.
>
> Now FRR is a very good router and one of the fancy features it supports is
> BGP Unnumered. This allows for auto configuration of BGP over a L2 network
> when both sides are sending Router Advertisements. This is very easy for
> flexible BGP configurations where both sides have dynamic IPs.
>
> What you want to do is that you get a /56, /48 or something which is
> >/64 bits routed to the VR.
>
> Now you can sub-segment this into separate /64 subnets. You don't want to
> go smaller then a /64 is that prevents you from using SLAAC for IPv6
> address configuration. This is how it works for Shared Networks now in
> Basic and Advanced Zones.
>
> FRR can now also send out the Router Advertisements on the downlinks
> sending out:
>
> - DNS servers
> - DNS domain
> - Prefix (/64) to be used
>
> There is no need for DHCPv6. You can calculate the IPv6 address the VM
> will obtain by using the MAC and the prefix.
>
> So in short:
>
> - Using BGP you routed a /48 to the VR
> - Now you split this into /64 subnets towards the isolated networks
>
> Wido
>
> > Alex Mattioli
> >
> >
> >
> >
>
>

-- 
Regards,
Hean Seng

Re: IPV6 in Isolated/VPC networks

[Kristaps Cudars]

Hi Alex,

No BGP or NAT66 on VR.

Route insert in to L3 handled or list acquired from ACS api.

On Wed, 14 Jul 2021 at 19:05, Hean Seng  wrote:

> Yes, sorry for that, can use NAT 6 also .I mentiioned DHCP6 , and you
> can point the gateway to /48 gw, and this does not need any BGP.  Maintain
> BGP or OSPF is good, but is a lot more complicated ,
>
> On Wed, Jul 14, 2021 at 10:57 PM Alex Mattioli <
> alex.matti...@shapeblue.com>
> wrote:
>
> > Hi Hean,
> > Do you mean using NAT66?  Or did I miss something?
> >
> > Regards,
> > Alex
> >
> >
> >
> >
> > -Original Message-
> > From: Hean Seng 
> > Sent: 14 July 2021 16:44
> > To: us...@cloudstack.apache.org
> > Cc: Wido den Hollander ; dev@cloudstack.apache.org; Wei
> > Zhou ; Rohit Yadav ;
> > Gabriel Beims Bräscher 
> > Subject: Re: IPV6 in Isolated/VPC networks
> >
> > Hi
> >
> > I replied in another thread, i think do not need implement BGP or OSPF,
> > that would be complicated .
> >
> > We only need assign  IPv6 's /64 prefix to Virtual Router (VR) in NAT
> > zone, and the VR responsible to deliver single IPv6 to VM via DHCP6.
> >
> > In VR, you need to have Default IPv6 route to  Physical Router's /48. IP
> as
> > IPv6 Gateway.  Thens should be done .
> >
> > Example :
> > Physical Router Interface
> >  IPv6 IP : 2000:::1/48
> >
> > Cloudstack  virtual router : 2000::200:201::1/64 with default ipv6
> > route to router ip 2000:::1 and Clodustack Virtual router dhcp
> allocate
> > IP to VM , and  VM will have default route to VR. IPv6
> 2000::200:201::1
> >
> > So in cloudstack need to allow  user to enter ,  IPv6 gwateway , and the
> > /48 Ipv6 prefix , then it will self allocate the /64 ip to the VR , and
> > maintain make sure not ovelap allocation
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Jul 14, 2021 at 8:55 PM Alex Mattioli <
> alex.matti...@shapeblue.com
> > >
> > wrote:
> >
> > > Hi Wido,
> > > That's pretty much in line with our thoughts, thanks for the input.  I
> > > believe we agree on the following points then:
> > >
> > > - FRR with BGP (no OSPF)
> > > - Route /48 (or/56) down to the VR
> > > - /64 per network
> > > - SLACC for IP addressing
> > >
> > > I believe the next big question is then "on which level of ACS do we
> > > manage AS numbers?".  I see two options:
> > > 1) Private AS number on a per-zone basis
> > > 2) Root Admin assigned AS number on a domain/account basis
> > > 3) End-user driven AS number on a per network basis (for bring your
> > > own AS and IP scenario)
> > >
> > > Thoughts?
> > >
> > > Cheers
> > > Alex
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Wido den Hollander 
> > > Sent: 13 July 2021 15:08
> > > To: dev@cloudstack.apache.org; Alex Mattioli
> > > 
> > > Cc: Wei Zhou ; Rohit Yadav <
> > > rohit.ya...@shapeblue.com>; Gabriel Beims Bräscher
> > > 
> > > Subject: Re: IPV6 in Isolated/VPC networks
> > >
> > >
> > >
> > > On 7/7/21 1:16 PM, Alex Mattioli wrote:
> > > > Hi all,
> > > > @Wei Zhou @Rohit Yadav > > rohit.ya...@shapeblue.com> and myself are investigating how to enable
> > > IPV6 support on Isolated and VPC networks and would like your input on
> > it.
> > > > At the moment we are looking at implementing FRR with BGP (and
> > > > possibly
> > > OSPF) on the ACS VR.
> > > >
> > > > We are looking for requirements, recommendations, ideas, rants,
> > > etc...etc...
> > > >
> > >
> > > Ok! Here we go.
> > >
> > > I think that you mean that the VR will actually route the IPv6 traffic
> > > and for that you need to have a way of getting a subnet routed to the
> VR.
> > >
> > > BGP is probably you best bet here. Although OSPFv3 technically
> > > supports this it is very badly implemented in Frr for example.
> > >
> > > Now FRR is a very good router and one of the fancy features it
> > > supports is BGP Unnumered. This allows for auto configuration of BGP
> > > over a L2 network when both sides are sending Router Advertisements.
> > > This is very easy for flexible BGP configurations where both sides have
> > dynamic IPs.
> > >
> > > What you want to do is that you get a /56, /48 or something which is
> > > >/64 bits routed to the VR.
> > >
> > > Now you can sub-segment this into separate /64 subnets. You don't want
> > > to go smaller then a /64 is that prevents you from using SLAAC for
> > > IPv6 address configuration. This is how it works for Shared Networks
> > > now in Basic and Advanced Zones.
> > >
> > > FRR can now also send out the Router Advertisements on the downlinks
> > > sending out:
> > >
> > > - DNS servers
> > > - DNS domain
> > > - Prefix (/64) to be used
> > >
> > > There is no need for DHCPv6. You can calculate the IPv6 address the VM
> > > will obtain by using the MAC and the prefix.
> > >
> > > So in short:
> > >
> > > - Using BGP you routed a /48 to the VR
> > > - Now you split this into /64 subnets towards the isolated networks
> > >
> > > Wido
> > >
> > > > Alex Mattioli
> > > >
> > > >
> > > >
> > > >
> >

[PROPOSE] RM for CloudStack Kubernetes Provider v1.0

[David Jumani]

Hi,

I'd like to put myself forward as the release manager for CloudStack Kubernetes 
Provider v1.0.

This will be the first release of CloudStack Kubernetes Provider which 
facilitates Kubernetes deployments on Cloudstack.
It allows Kubernetes to dynamically allocate IP addresses and the respective 
networking rules on CloudStack to ensure seamless TCP, UDP and TCP-Proxy 
LoadBalancer deployments on Kubernetes.

It was initially the Cloudstack provider in Kubernetes which was later 
extracted to allow for pluggable providers.
A lot of work and effort has gone into developing it, and we are looking 
forward to its grand debut.

The list of open issues triaged for the v1.0 milestone can be found at 
https://github.com/apache/cloudstack-kubernetes-provider/milestone/1
If you encounter any issues, please do report them at 
https://github.com/apache/cloudstack-kubernetes-provider/issues

Looking forward to your support

Thanks,
David

 

Re: RE: IPV6 in Isolated/VPC networks

[Rohit Yadav]

Hi Kristaps,

I think the public list may not allow you larger email and doc/attachments. If 
there are any documents you want to share, can you say put them on Google docs 
and share the link with dev list? Thanks.


Regards.


From: Kristaps Cudars 
Sent: Wednesday, July 14, 2021 21:09
To: dev@cloudstack.apache.org 
Subject: Re: RE: IPV6 in Isolated/VPC networks

Pony Mail is blocking me :(

Hi,

Elaborating on my previous email.

In my opinion SLAAC (StateLess Address Auto Configuration) is not good
candidate for VR as it was created for situations of connecting million
devices with less amount of effort and no micromanagement needed.

One example that coms in mind is- I want to reassign IPv6 from one instance
to another with SLAAC I will need to change mac address on instance. This
will introduce new workflows in ACS.

Suggestion would be to use same IPv4 services for IPv6 and have feature
parity between both protocols in dual-stack configuration as much as
possible. IPv4 will stay with NAT and IPv6 will be routable. Form ACS
interface and workflow perspective everything will stay same for both
protocols with excursion that IPv6 will not have source and destination NAT.

In Primate it can be handled with protocols selection dropdown, checkboxes,
additional fields in same isolated/vpc workflow.

Vision from user/admin perspective could look as following:

For Zones > Traffic Types > Public for existing or new add/edit IPv6

When isolated/vpc network is created you are presented with option to
enable or disable both protocols. (One of them should be enabled)

For IPv6 there must be predefined list of /64 networks that can be
automatically assigned.
In VR creation menu IPv6 is prefilled and not changeable by user.
It could be in Zones > Traffic Types > Internal

In case of isolated network public IP must be assigned in case of vpc its
already assigned.

At this point ACS should do api call/or something to insert route in L3
element.
You have two variables internal IPv6 network and public IPv6 address that
will form route entry.

In our case we are using Cisco NX-OS and it has NX-API. I stand for choice
and there are many more grate L3 devices. Inserting those variables in to
ansible that can play route add/remove against many vendors is better. List
can be git repository.
It also could be ACS api where you can get list public and internal ip
relations and how you form/create routing entries is up to you.
This can be something else proposed by others.

Or do it manually is also option for beginning/ small deployments/ lab.
Nothing bad happens if you do not create route instantly. It simply will
not work until route is created.

Probably it would be smart to have global option that enables/disable IPv6.

I’m accepting questions, something must be explained in more detail, rant…
that this is not good.