cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wido den Hollander (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-674) IPV6 support for instances in Basic Zone
Date Fri, 10 Jul 2015 10:15:04 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622085#comment-14622085
] 

Wido den Hollander commented on CLOUDSTACK-674:
-----------------------------------------------

It has been silent on this for a while, but work is being done on this.

I send this proposal to the dev list a while ago, but here it is as well:


After the EU User Group meetup in London today I sat down with Rohit,
John Burwell and some other people and I wanted to ventilate the ideas
we/I came up with for IPv6 in BASIC networking.


(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.

The management server should be told that a specific subnet can be
used within a pod, eg a /64.

When a new IPv6 Address is requested the management server generates a
random new address in that subnet and checks if no duplicate exists.
If not, it stores the /128 (single IP) in the MySQL database and
configures the DHCPv6 server on the Virtual Router (VR).

When the Instance boots it knowns that due to the "managed other flag"
in the RA that it should query DHCPv6 for acquiring a IPv6 address.

The VR responds to the DHCPv6 request with a IPv6 address, DNS
servers, domain and maybe a NTP server.

We ONLY store addresses we handed out, not with IPv4 where we store
every address. A address NOT stored in the database means it's not
handed out.

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.

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.

To use this seems like a simple, but robust solution. The real
hardware routers do all the traffic forwarding and the VR only does
DHCPv6.

Security grouping has to be extended to also support IPv6, but should
allow ICMPv6 by default.

At the end of June 2015 we want to keep a one-day meetup in Amsterdam
with various developers to discuss some more details.

Wido

[0]: https://www.ietf.org/rfc/rfc5075.txt
[1]: https://www.ietf.org/rfc/rfc4861.txt



> IPV6 support for instances in Basic Zone
> ----------------------------------------
>
>                 Key: CLOUDSTACK-674
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-674
>             Project: CloudStack
>          Issue Type: Sub-task
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Network Controller
>            Reporter: Chiradeep Vittal
>             Fix For: Future
>
>
> This can enhance the security group function to include ipv6 support.
> Changes will include the need for ipv6 iptables in dom0 and support for ipv6 in ipset
(XS)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message