But you still need routing. See the attached PNG (and draw.io XML).

You need to route the /48 subnet TO the VR which can then route it to the Virtual Networks behind the VR.

There is no other way then routing with either BGP or a Static route.

Wido

Op 15-07-2021 om 12:39 schreef Hean Seng:
Or explain like this :

1) Cloudstack generate list of /64 subnet from /48 that Network admin assigned to Cloudstack 2) Cloudsack allocated the subnet (that generated from step1) to Virtual Router, one Virtual Router have one subniet /64 3) Virtual Router allocate single IPv6 (within the range of /64 allocated to VR)  to VM






On Thu, Jul 15, 2021 at 6:25 PM Hean Seng <heans...@gmail.com <mailto:heans...@gmail.com>> wrote:

    Hi Wido,

    I think the /48 is at physical router as gateway , and subnet of /64
    at VR of Cloudstack.   Cloudstack only keep which /48 prefix and
    vlan information of this /48 to be later split the  /64. to VR.

    And the instances is getting singe IPv6 of /64  IP.   The VR is
    getting /64.  The default gateway shall goes to /48 of physical
    router ip .   In this case ,does not need any BGP router .


    Similar concept as IPv4 :

    /48 subnet of IPv6 is equivalent to current /24 subnet of IPv4 that
    created in Network.
    and /64  of IPv6 is equivalent to single IP of IPv4 assign to VM.




    On Thu, Jul 15, 2021 at 5:31 PM Wido den Hollander <w...@widodh.nl
    <mailto: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>
        <mailto: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> <mailto:w...@widodh.nl
        <mailto:w...@widodh.nl>>>
         >     Sent: 13 July 2021 15:08
         >     To: d...@cloudstack.apache.org
        <mailto:d...@cloudstack.apache.org>
        <mailto:d...@cloudstack.apache.org
        <mailto:d...@cloudstack.apache.org>>;
         >     Alex Mattioli <alex.matti...@shapeblue.com
        <mailto:alex.matti...@shapeblue.com>
         >     <mailto:alex.matti...@shapeblue.com
        <mailto:alex.matti...@shapeblue.com>>>
         >     Cc: Wei Zhou <wei.z...@shapeblue.com
        <mailto:wei.z...@shapeblue.com>
         >     <mailto:wei.z...@shapeblue.com
        <mailto:wei.z...@shapeblue.com>>>; Rohit Yadav
         >     <rohit.ya...@shapeblue.com
        <mailto:rohit.ya...@shapeblue.com>
        <mailto:rohit.ya...@shapeblue.com
        <mailto:rohit.ya...@shapeblue.com>>>;
         >     Gabriel Beims Bräscher <gabr...@pcextreme.nl
        <mailto:gabr...@pcextreme.nl>
         >     <mailto: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>
         >     <mailto:wei.z...@shapeblue.com
        <mailto:wei.z...@shapeblue.com>>> @Rohit
         >     Yadav<mailto:rohit.ya...@shapeblue.com
        <mailto:rohit.ya...@shapeblue.com>
         >     <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



-- Regards,
    Hean Seng



--
Regards,
Hean Seng
<mxfile host="app.diagrams.net" modified="2021-07-15T14:45:08.685Z" agent="5.0 
(Macintosh)" etag="Tw_0yf--ObaU8HRtsTaj" version="14.8.3" 
type="device"><diagram id="UWmSsMReI2uaSybzz6nz" 
name="Page-1">3Vpbk6MoFP41qdp9mJSoGPPYSffMbu32TNdmZ3b6kUSSUG0ki+Q2v35AwShqkp5ctFLVF0HOEb7vnAMc6DjDxfYTQ8v5Mw1w2LGtYNtxHju2bVueJ/7Jml1aAyzXTWtmjASqbl8xIj+wbqhqVyTAcaEhpzTkZFmsnNAowhNeqEOM0U2x2ZSGxa8u0QyXKkYTFJZr/yMBn6taD7r7F39gMpvrTwOvn75ZIN1aDSWeo4BuclXOU8cZMkp5+rTYDnEo4dPApHIfa95mPWM44qcIrNevz+vh/POXr0/c76N/8V//v35QWtYoXKkRd2wvFPoGAVmLx5l8/EYYXyGp6x+64pjpJuJbuVa2ZYGO8xCMffFX/Nhq2HynwRT9EbyJwmAzJxyPlmgi32yE7Yi6OV+EoiR0DFC8TMmcki0Oki8lvcSM423t8EEGqrBHTBeYs51oogR6mgdliq6nypscr7rNPE+prkTKlmaZ7j3a4kEB/g7wnVPA/3P0cgT4CqHfhMiXFY+F84inYUhXwYijydvvuu2YmdJHdZ4hapoGOF1Xm0zI7hkm5FSYkF9lQv61TAieYkIZ2mWH/oz5hrI38QRyDIxPY3hcye90mpIsZDy3WqlBKqOrKJAkJcwdIXZKwnBIQ8pEOaIRvgy1wLKK3NpWmdtsVroNt70St9+eD2BnHcfuIkAZcTSb33JAeRU4udeCyW8lTMBpGUz9VsJkWpPTNEzaxVuGk2lOjeNk2xebeeyDq4Hz5yJwD/NR1VrjxvORXV6vtsE1zBDiwqZdw20lTmYIaR6n8uK1DTiZ9gQbx8lrJU6mPTWPU3nB/KtTknPlKcm+hynJq8ig3HpKaufi3wwhnt+0a7Rz9W+GkMZx0v1pGU6mPfUax6mcN24DTqY9NY9T1S7JQAlHwYM8qdgH6xwqYuRs910hmBReZaELdfFxm3/5uFOl9Cs4KJ1uGFiKntAVm+ADY9DHLojNMD/QDlZzk4MeVkCv6xgOESfrYner+FBfeKFEDCSj3jfmJugZlKbDVFJ7VsuKoKEIGIpSHEqKEvPIhn2GxZRnNJ37tx4C6R4kxgtBYlw2JMH232iMQyMTHpJZJJ4nQkiocQaJkgkKH9SLBQkCqWPAcEx+oHGiTxrRUg4yGTYcdODjISdV529KuJNlu/IGd8BDal36g9W1AfQLlIDzLEY3odNpjK/DYdXBzp16vV3D343c3gFdt+c40O9B33L1qaze4fpe13OB6/uwJ+YGVycw3hsTgAWKQcGxbhwUysu3+w4KzrGgAOBF7AfYRYkrxoRyUuhXY0LXsmAxLnhiH3Q4MiSlF8yIGIfku7Fw0Ws0XLgHw0X/UuHCPNS48RrCLe9i7jtcuMfCheXDAiN265cQVQf77wkXF/Rt50Tfrtmc3ci14SHXhtalXLvuHO5WK4FyLti8XKOSinfh2DV7ystsBFQni5EBGPJXdPH6dHWWB/4ak2gm2gw+yUtgVAZwJH5HXAx4Iocuw7r0zbn8G6/GkeyrVXcfx/Vlp2ItGEhJarZPr+6dkJMWNPOiNcWc0TdspJ4rstGnW11V0qiYVqq1utPzRm7fcOqKtFF2H+jcq4GiuL/zmdrS/u6s8/QT</diagram></mxfile>

Reply via email to