Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Message-ID: <556F4938.20503@widodh.nl>
Date: Wed, 03 Jun 2015 20:36:40 +0200
From: Wido den Hollander <wido@widodh.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Suresh Ramamurthy <sureshr.hasvik@gmail.com>
CC: dev@cloudstack.apache.org
Subject: Re: IPv6 ideas for Basic Networking
References: <555E2B16.1030202@widodh.nl>	<555F9A31.1060805@server24.eu>
	<55609C22.2070707@widodh.nl>
	<CALFpzo5cBgvvBaU7sgdOWD4cb2ea57oJu6uO9LM9uCdNcHY=rg@mail.gmail.com>
	<EA8405EF-57CB-4739-900A-7BAD444C154A@schubergphilis.com>
 <CAN9WiTb__7yNmU5A86Azc7pd5QqmenTOYoeo21gYK3k41zZZPw@mail.gmail.com>
In-Reply-To: 
 <CAN9WiTb__7yNmU5A86Azc7pd5QqmenTOYoeo21gYK3k41zZZPw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 05/29/2015 09:59 PM, Suresh Ramamurthy wrote:
> Hi Wido,
> 
> After reading your IPv6 ideas for Basic Networking, I realized that
> couple of them can be reused for Advanced Networking too.
> 

Great! Like which parts? I guess there is a big overlap between
Advanced and Basic networking.

> We have come up with a proposal for IPv6 support in VPC and it is
> posted in wiki
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Rou
ter
>
>  Did you get a chance to look at it? Let me know your feedback on
> the DD.
> 

No, I didn't, but I really should!

> I work from bay area, so I will not be able to attend the meetup
> at Amsterdam. But, I would like to have a call/chat with you to
> discuss on further details about IPv6 support.
> 
> I would like to schedule a conference call with you. Would you be
> available for the call?
> 

Yes, that seems like a good idea. I'm heading off on vacation and it
won't be until around June 20th before I'll be available.

Wido

> Thanks, Suresh
> 
> 
> 
> On Sat, May 23, 2015 at 11:18 PM, Remi Bergsma
> <RBergsma@schubergphilis.com> wrote:
> 
>> At Schuberg Philis we’ve been working on a design voor IPv6 in
>> VPC networks (so this is Advanced Networking) and I indeed had a
>> look at your functional spec. I’ll finalise what we’ve come up
>> with and publish it early next week so we can align and discuss
>> and work from there. Nice to see there is a design for Basic
>> Networking as well!
>> 
>> Regards, Remi
>> 
>>> On 24 May 2015, at 02:47, Marcus <shadowsor@gmail.com> wrote:
>>> 
>>> Did you guys review the functional spec that has been floating
>>> around on cwiki? On May 23, 2015 8:27 AM, "Wido den Hollander"
>>> <wido@widodh.nl> wrote:
>>> 
> 
> 
> On 05/22/2015 11:05 PM, server24 Cloudstack wrote:
>>>>>> Hi Wido,
>>>>>> 
>>>>>> was nice talking to you about this.
>>>>>> 
>>>>>> On 5/21/2015 8:59 PM, Wido den Hollander wrote:
>>>>>> 
>>>>>>> (IPv6) routers should send out RAs (Router
>>>>>>> Advertisements) with the managed-other-flag [0][1],
>>>>>>> telling Instances to ONLY use that routers as their
>>>>>>> default gateways and NOT to use SLAAC to autoconfigure
>>>>>>> their IP-Address.
>>>>>> 
>>>>>> OK, so no autonomous flag
>>>>>> 
> 
> No, the "managed other flag" as described in RFC 4862. Meaning
> that the Routers should only be used as a default gateway and
> DHCPv6 should be used for obtaining a address.
> 
>>>>>>> The (ip6tables) Security Groups should allow ICMPv6 by
>>>>>>> default. IPv6 traffic breaks really hard without ICMPv6
>>>>>>> traffic, for example PMTU doesn't work properly and
>>>>>>> breaks IPv6 connections.
>>>>>> yes, and default ip(6)tables should be in place to block 
>>>>>> VNC-related traffic except to the Virtual Console (as
>>>>>> currently VNC ports on IPv6 are world-wide-open in BASIC
>>>>>> network)!
>>>>>> 
> 
> Yes, but in that case you are talking about the Console Proxy
> which should be firewalled properly.
> 
>>>>>>> In CloudStack we might configure a /48, but tell it to
>>>>>>> hand out addresses for each instance from a /64 out of
>>>>>>> that /48. That means we can have 65k Instances in that
>>>>>>> pod. Some firewall policies block a complete /64 when
>>>>>>> they see malicious traffic coming from that subnet, so
>>>>>>> if the subnet is big enough we should try to keep all
>>>>>>> the IPv6 addresses from one Instance in the same /64
>>>>>>> subnet. This could also simplify the iptable rules.
>>>>>> so one /48 per pod? RIRs provide either /48 or /32 (the
>>>>>> latter to the providers) IPv6 blocks. So this should then
>>>>>> be configurable, both per instance and per pod. One /48
>>>>>> per pod still looks large to me..
>>>>>> 
> 
> A /48 should be a possibility. If you only have a /64 available
> that should be no problem either.
> 
>>>>>> On the other hand any prefix more specific than /64 could
>>>>>> break IPv6 features, so that there are at least some
>>>>>> practical values to rely on.
>>>>>>> Security grouping has to be extended to also support
>>>>>>> IPv6, but should allow ICMPv6 by default.
>>>>>> yes, ICMPv6 should be on by default (maybe it should be
>>>>>> forced to be always on for IPv6?).
>>>>>> 
>>>>>>> At the end of June 2015 we want to keep a one-day
>>>>>>> meetup in Amsterdam with various developers to discuss
>>>>>>> some more details.
>>>>>> 
>>>>>> great work and very good meeting, was a pleasure to be
>>>>>> there.
>>>>>> 
>>>>>> Thomas Moroder
>>>>>> 
>>>>>> -- Incubatec GmbH - Srl Via Scurcia'str. 36, 39046
>>>>>> Ortisei(BZ), ITALY Registered with the chamber of
>>>>>> commerce of Bolzano the 8th of November 2001 with REA-No.
>>>>>> 168204 (s.c. of EUR 10.000 f.p.u.) President: Thomas
>>>>>> Moroder, VAT-No. IT 02283140214 Tel: +39.0471796829 -
>>>>>> Fax: +39.0471797949
>>>>>> 
>>>>>> IMPRINT: http://www.incubatec.com/imprint.html PRIVACY: 
>>>>>> http://www.server24.it/informativa_completa.html
>>>>>> 
>>>> 
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVb0k4AAoJEAGbWC3bPspC484P/2AsM2ylxNkWF0kfDcirOFC1
/BQGjZYBJ5gozHt9U/UkJcba/jwCIZYO9ZzMZ7q3jxXWATXkFLrPkcnMf6LJmkgz
9hEkgU0109n66dK37gL5oslPVaLgYAPOPJS0A6O7iw2LEifIzTSDk5JnANAykTNc
waY39Zr3RPqAI78VQRzbgIXNzEC7j2C0RACHO+dzz1r5CM3x2TxqjkR26dfJ4FNV
gZ/A0ijtotgtV93Fg8DlutyyRhy3kwdmAGVzqaq4Iw2dC5+kM40CUlp2d4tbDBVc
hqdoAGkgFUuEKq9F4Cv1INjNDsBi7tgQA5G86QLANvGYeVg8YJC4avgNTCz/kezx
tTtWSiWtdHqDK7LPji6YNA8KvoCj3hBAguSSZ1T0W89cl9vuYVR9j3e28XpgXWEy
9rXlF0IBGMkeJngtO+9CzbJA48FN1V3gB6Y51InuyuzhFu7Y3qoMm5KxNNhW5PgA
a6aeatpQ/foxedZHUoMaGDRtI03mhDqG243YQHGr2U64AfmGwUyy9tdu+xFaYLiP
xahnWNIWenB3bZpOrlJ6PTJMS4gQ4EmKZYgMOrNQMoTG0jNotd+z2QXZfBRL7Ur5
PyCJHYk1AXQGenX85tSPPzQbZbpB/bRMd7UHZ82tUUsMUN+MpNEdJvRse+WLgiz1
3KgiOzv7hnyNNvcrUBZj
=Dqac
-----END PGP SIGNATURE-----