cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Ramamurthy <sureshr.has...@gmail.com>
Subject Re: IPv6 ideas for Basic Networking
Date Thu, 04 Jun 2015 18:32:59 GMT
Hi Wido,

Parts like DHCPv6, IP6Table, IPv6 network carving, IPv6 IP allocation etc
could be reused. I proposed to implement RA in VPC Router.
This could also be reused. And, there could be few others too..

I will ping you once you are back from vacation. Right now, I am in
investigation mode. So, I might have few more details to discuss with you
by then.

Thanks,
Suresh


On Wed, Jun 3, 2015 at 11:36 AM, Wido den Hollander <wido@widodh.nl> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message