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 <shadow...@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" <w...@widodh.nl> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> 
>> 
>> 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
>> 
>> iQIcBAEBAgAGBQJVYJwhAAoJEAGbWC3bPspCWXEQAISPV1PdGWa6KOck9IsTVXBt
>> jUTpyFyg+qnmlG+QQ3LWOFjXRVUvQroryBbxkBnEbNm5d5qOsKptwwOaXMOut4A2
>> Nv4WCcFlAjnj78c9C/mpJvqu+Bh/WLKy4mBaMEqLiSAzqoz+CPlaiubJ/TDXR+jp
>> XSY3XNk/jhdI02QTPNHvYc1ZbWNjuZrb+YVqEzFLra25I0bfXuq2tcBVDEMr1zmA
>> qQVfCabkAx/a8wW2wGnz2GSg1UFDJUHOb7c6bae9nE5wo1MYpXyjpO53IBpRQuPt
>> +VMzkjyf75yS1LFel9zS/BzV97mgEBxux9Nb3M9f/ZJW0QvS9onZdIhYgCeDyxJe
>> M/XTD6M0O+ha4mFaYTeSudWoQnv/ZZ1P5RuPTQyQRD4P7nSkorz6QOR/SVb+OhXG
>> 7tqd0GaUS/OFTC69wBTN/t9m98mYRZ5s4XtuocE5DadHqIv5JslrKLzC2YJEWonm
>> RqL2Gow0/h+k99esJatmCZq+6jXwsy9pIVsLspfDt+GKBOVw8sHNTDUPTvdVzffv
>> Qa+gVl5gg9RvSonJ8xS7sHI/p/gDFJrN1lWzxl9YWyurjDKFz2zI0OWfOKGZdhrE
>> Ywgzb+2ExzGSgLSE6AL8awLbl1N57TOlQI4SlfN7Ph4kaS2T9eCleAXP3BxPSXqK
>> Hji1OI5/luKcQVyYqwaT
>> =acrP
>> -----END PGP SIGNATURE-----
>> 

Reply via email to