Op 14-07-2021 om 16:44 schreef 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:aaaa::1/48
Cloudstack virtual router : 2000:aaaa:200:201::1/64 with default ipv6
route to router ip 2000:aaaa::1
and Clodustack Virtual router dhcp allocate IP to VM , and VM will have
default route to VR. IPv6 2000:aaaa: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
But NAT is truly not the solution with IPv6. IPv6 is supposed to be
routable. In addition you should avoid DHCPv6 as much as possible as
that's not really the intended use-case for address allocation with IPv6.
In order to route an /48 IPv6 subnet to the VR you have a few possibilities:
- Static route from the upperlying routers which are outside of CloudStack
- BGP
- OSPFv3 (broken in most cases!)
- DHCPv6 Prefix Delegation
BGP and/or Static routes are still the best bet here.
So what you do is that you tell CloudStack that you will route
2001:db8::/48 to the VR, the VR can then use that to split it up into
multiple /64 subnets going towards the instances:
- 2001:db8::/64
- 2001:db8:1::/64
- 2001:db8:2::/64
...
- 2001:db8:f::/64
And go on.
In case of BGP you indeed have to tell the VR a few things:
- It's own AS number
- The peer's address(es)
With FRR you can simply say:
neighbor 2001:db8:4fa::179 remote-as external
The /48 you need to have at the VR anyway in case of either a static
route or BGP.
We just need to add a NullRoute on the VR for that /48 so that traffic
will not be routed to the upper gateway in case of the VR can't find a
route.
Wido
On Wed, Jul 14, 2021 at 8:55 PM Alex Mattioli
<alex.matti...@shapeblue.com <mailto: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 <w...@widodh.nl <mailto:w...@widodh.nl>>
Sent: 13 July 2021 15:08
To: dev@cloudstack.apache.org <mailto:dev@cloudstack.apache.org>;
Alex Mattioli <alex.matti...@shapeblue.com
<mailto:alex.matti...@shapeblue.com>>
Cc: Wei Zhou <wei.z...@shapeblue.com
<mailto:wei.z...@shapeblue.com>>; Rohit Yadav
<rohit.ya...@shapeblue.com <mailto:rohit.ya...@shapeblue.com>>;
Gabriel Beims Bräscher <gabr...@pcextreme.nl
<mailto:gabr...@pcextreme.nl>>
Subject: Re: IPV6 in Isolated/VPC networks
On 7/7/21 1:16 PM, Alex Mattioli wrote:
> Hi all,
> @Wei Zhou<mailto:wei.z...@shapeblue.com
<mailto:wei.z...@shapeblue.com>> @Rohit
Yadav<mailto:rohit.ya...@shapeblue.com
<mailto: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
