Hi Wido, Can you explain why “DHCPv6 as much as possible as that's not really the intended use-case” it’s not intended use-case?
On 2021/07/15 09:31:26, Wido den Hollander <w...@widodh.nl> wrote: > > > 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 >
