I've discussed this a bit with various subject matter experts at our
datacenters/business, and so far we're leaning toward a rollout like
this:
* VPC has no global IPv6 prefix (super CIDR as current private space),
it's simply IPv6 enabled or not. Admins can choose to route a /60 or a
/48 to a vpc
(test-)attention needs to go to:
HaProxy version/feature matrix has to be reviewed to check for ipv6
compatability.
Does dnsmasq work with ipv6?
Does keepalived work seemslessly?
Ipv6 tables configuration needs to be pushed to the VRs
-Original Message-
From: Marcus Sorensen [mailto:s
ancers to pull from. How will this range be made
>> available?
> Is a cidr configured?
> Will we preconfigure all ranges or have a dynamic availability check?
>
> Radvd package is added to the systemvm template. (Done by Hugo this morning)
>
> Some standard UI components are ne
On Thu, Jan 9, 2014 at 5:28 PM, Marcus Sorensen wrote:
> Do you have any specific reasoning or need for the
> VPC itself to have a configured contiguous block, rather than just
> assign the /64s the networks?
convenience in configuring the upstream router. The idea is that
everything on the netw
On Thu, Jan 9, 2014 at 9:43 AM, Daan Hoogland wrote:
> On Thu, Jan 9, 2014 at 5:28 PM, Marcus Sorensen wrote:
>> Do you have any specific reasoning or need for the
>> VPC itself to have a configured contiguous block, rather than just
>> assign the /64s the networks?
>
>
> convenience in configuri
I think you are overlooking the fact that if you do not assign a
continuous block to a vpc you need to set routes upstream for every
tier. If you do you can set only the vpc block and let the vpc router
take care of the internal routing. Maybe I am wrong and we are just
speaking a different type of
Not necessarily. You can still set the upstream to send a /60 to VPC
X, and then just assign individual /64s from that /60 into the
networks in that VPC. You can create a route upstream for each /64,
but you can also just program the contiguous /60 route into the
upstream. That gives you future e
]
Sent: vrijdag 10 januari 2014 6:14
To: dev@cloudstack.apache.org
Cc: Daan Hoogland; Hugo Trippaers; Edwin Beekman; Erwin Blekkenhorst; Daan de
Goede
Subject: Re: IPv6 in VPC (was Re: IPv6 plan - questions)
Not necessarily. You can still set the upstream to send a /60 to VPC X, and
then just assign
me, or to us I should say.
>
> Regards,
> DaanH
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: vrijdag 10 januari 2014 6:14
> To: dev@cloudstack.apache.org
> Cc: Daan Hoogland; Hugo Trippaers; Edwin Beekman; Erwin Blekkenhorst; Daan de
Hi Marcus,
Sorry for jump in late.
On Mon, Jan 6, 2014 at 12:11 PM, Marcus Sorensen wrote:
> I've discussed this a bit with various subject matter experts at our
> datacenters/business, and so far we're leaning toward a rollout like
> this:
>
> * VPC has no global IPv6 prefix (super CIDR as curr
On Thu, Jan 16, 2014 at 12:23 PM, Sheng Yang wrote:
> Hi Marcus,
>
> Sorry for jump in late.
>
> On Mon, Jan 6, 2014 at 12:11 PM, Marcus Sorensen wrote:
>
>> I've discussed this a bit with various subject matter experts at our
>> datacenters/business, and so far we're leaning toward a rollout like
ived work seemslessly?
>
According to http://www.keepalived.org/, it should work. But seems works
are still going on.
--Sheng
> Ipv6 tables configuration needs to be pushed to the VRs
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent:
ted
>>for
>> VPC routers/static nat/loadbalancers to pull from. How will this range
>>be
>> made available?
>> Is a cidr configured?
>> Will we preconfigure all ranges or have a dynamic availability check?
>>
>> Radvd package is added to the systemvm t
gt;> Is a cidr configured?
>> Will we preconfigure all ranges or have a dynamic availability check?
>>
>> Radvd package is added to the systemvm template. (Done by Hugo this
>> morning)
>>
>> Some standard UI components are needed.
>>
>> (test-)at
alancing etc as well?
>>> Or at least think
>>> about what impact these decisions have.
>>> This is not a version 1 consideration?!?
>>>
>>> > * We assume there will be an ipv6 public range assignable, allocated
>>>for
>>> VPC routers/stati
On Fri, Jan 17, 2014 at 8:45 AM, Marcus Sorensen wrote:
> guest networks, my initial preference would be for SLAAC, but I think
> ultimately we'd want to be able to assign multiple ips to a guest.
> With the 64 bits of the SLAAC space dedicated to all of the unique MAC
> address possibilities, we
>From what I understand, SLAAC only works with /64s, larger breaks
various discovery protocols and is against RFC. Half of the address is
the prefix and the other half is (mostly) MAC. What you're describing
would work if we didn't want to do SLAAC, but would require an
alternate means of assignmen
Ok, I though those could come from the same vpc range.
On Fri, Jan 17, 2014 at 2:58 PM, Marcus Sorensen wrote:
> From what I understand, SLAAC only works with /64s, larger breaks
> various discovery protocols and is against RFC. Half of the address is
> the prefix and the other half is (mostly) M
t;to
>>>> implement and enforce?
>>>>
>>>
>>>The routing is controlled by upstream router, so it's straightforward
>>>that
>>>ACL would be done by upstream router.
>>>
>>>But after rethink, modifying the upstream route
This is not a version 1 consideration?!?
> >>
> >> > * We assume there will be an ipv6 public range assignable, allocated
> for
> >> > VPC routers/static nat/loadbalancers to pull from. How will this
> range be
> >> > made available?
> >> Is a cidr
clients than servers; that is, a
>>>>>client
>>>>> moving around the country would be traceable because of the MAC, but a
>>>>> server always has the same address anyway.
>>>>>
>>>>> > * Still need to figure out what to
;/
>>>>>> VPC and the block will be routed.
>>>>>>
>>>>>>
>>>>>> > * Work could be done in stages, e.g. SLAAC/manual network ranges
>>>>>>would
>>>>>> be fairly straightforward, whereas
22 matches
Mail list logo
