From cloudstack-dev-return-17390-apmail-incubator-cloudstack-dev-archive=incubator.apache.org@incubator.apache.org Wed Jan 16 02:11:02 2013 Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E7F93E499 for ; Wed, 16 Jan 2013 02:11:02 +0000 (UTC) Received: (qmail 93797 invoked by uid 500); 16 Jan 2013 02:11:02 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 93767 invoked by uid 500); 16 Jan 2013 02:11:02 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 93759 invoked by uid 99); 16 Jan 2013 02:11:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2013 02:11:02 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.210.180] (HELO mail-ia0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2013 02:10:56 +0000 Received: by mail-ia0-f180.google.com with SMTP id f27so67545iae.25 for ; Tue, 15 Jan 2013 18:10:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=mb2RmNvzxyttNwY9db1XvKtvyA53LuOreA640Y+Mb90=; b=f1AeemUfDbqGSVENSPZ5Cyryx6h7pydPiys84pKjYlGILTDw9Mfiyoy3vIitNdH3vX GG48LrG/vizbs+ky2FhANGcIwNLOlVHQNBX5ylLtbqoZI20bqHmIoT2x4anP9uvjy0yd OqQaIm2ruDzWLsSKf+6xKCESOQvcT9eVzzNmzbAua04qQkMqubTcgcf0bzepgL9lqAAP er7WYWh5lHuqOZrccrGcclPVMREcdEFDgd+NkLuC0paEzefWwspu9Iutx4U6+608pe6s +mCmZqZxVe+qmyMI8+S2jVlv2ywHZ9BWwSGvgF9g+NxQrSXR/bVrg1PoxWwb+5iidM5p qcyw== MIME-Version: 1.0 X-Received: by 10.50.196.198 with SMTP id io6mr3648888igc.39.1358302235136; Tue, 15 Jan 2013 18:10:35 -0800 (PST) Received: by 10.64.107.200 with HTTP; Tue, 15 Jan 2013 18:10:34 -0800 (PST) X-Originating-IP: [63.110.51.11] In-Reply-To: References: Date: Tue, 15 Jan 2013 18:10:34 -0800 Message-ID: Subject: Re: [ASFCS41] IPv6 Support From: Sheng Yang To: cloudstack-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl5dEESSfeClwHZ9SQSLRfWCo2VzThHPAmlb1+T6MErN+MCgjnmamyQ0Lldo+4Sgk4mqh+A X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jan 14, 2013 at 3:34 PM, Sheng Yang wrote: > On Mon, Jan 14, 2013 at 10:51 AM, Sheng Yang wrote: >> >> On Mon, Jan 14, 2013 at 10:45 AM, Chiradeep Vittal >> wrote: >>> >>> You can if you assume that it is of LL-type. Windows requires a registry >>> fix to generate an 'LL' type DUID. >> >> >> Does dhcp6c support it? Didn't see a word from the document about DUID type, >> and it genereate LLT type by default Probably I should try another dhcpv6 >> client. >>> >>> >>> You can also get dnsmasq to ignore the duid and use the mac. >> >> >> Haven't confirmed it's possible to use the mac, asking dnsmasq mailing >> list... > > Get answer from Dnsmasq's author Simon, it's impossible to use MAC to > identify client right now, since there is no such dhcpv6 standard. > > So it looks like we need stick to DUID-LL. I am failed to generated DUID-LL from the latest version of dhcp6c in CentOS 5.6. Is DUID-LL poorly supported by dhcpv6 client? Any other suggestion? User may need to install new dhcpv6 client to use with CloudStack, that sounds not that good... I am working on the FS right now, since we have the key steps(except DUID-LL, which should be a dhcpv6 client issue), and likely able to get it done tomorrow. Since we're working on advance shared network, it's easier to deal with createNetwork API rather than createVlanAndIpRange API. --Sheng > > --Sheng > > >> >> --Sheng >> >> >>> >>> >>> On 1/14/13 9:54 AM, "Sheng Yang" wrote: >>> >>> >On Sun, Jan 13, 2013 at 11:21 PM, Hugo Trippaers < >>> >HTrippaers@schubergphilis.com> wrote: >>> > >>> >> Side note, but where are we going to do development? I think we should >>> >>get >>> >> our work in a feature branch as soon as possible so we can all >>> >>contribute >>> >> to the development. >>> >> >>> >> Sheng, can you push any work you have done to a branch? I'll check and >>> >>see >>> >> if I need to commit any of my changes then. >>> >> >>> > >>> >We'd like to have the work based on Chiradeep's network refactor branch, >>> >but currently we're waiting for Javelin to be merged. >>> > >>> >And I am dong some PoC right now, so no code is written so far. I just >>> >found it's not that straightforward to get the dnsmasq work as we >>> > thought. >>> > >>> >We need DUID from client(not MAC) to hand out ipv6 addresses, but I am >>> > not >>> >sure if that's something we can know from mgmt server side. >>> > >>> >--Sheng >>> > >>> >> >>> >> Cheers, >>> >> >>> >> Hugo >>> >> >>> >> -----Original Message----- >>> >> From: John Kinsella [mailto:jlk@stratosec.co] >>> >> Sent: vrijdag 11 januari 2013 19:50 >>> >> To: cloudstack-dev@incubator.apache.org >>> >> Subject: Re: [ASFCS41] IPv6 Support >>> >> >>> >> >>> >> On Jan 10, 2013, at 11:09 AM, Sheng Yang wrote: >>> >> >>> >> > On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella >>> >>wrote: >>> >> >> From a quick glance at it's man page, looks like it can do v4 and v6 >>> >> >> leases at the same time... >>> >> > You mean dhcpd? >>> >> > >>> >> >>> >> No, dnsmasq looked like it could... >>> >> >>> >> > I am exploring all the possibility right now. >>> >> > >>> >> > Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would >>> >> > either update to a newer version dnsmasq, or using other dhcp >>> >>server(e.g. >>> >> > dhcpd) on DHCPv6. >>> >> > >>> >> > But replacing the dhcp server is a big work, all the configuration >>> >> > need to be rewritten. Regarding dhcpd, I haven't figured out how much >>> >> > effort we need to spend if we want to switch. >>> >> > >>> >> > There is one possible solution for this release: say, using dhcpd >>> >> > only >>> >> > for IPv6, to reduce our effort of introducing IPv6(if it's easier >>> >> > than >>> >> > moving to dhcpd). And then we can make the choice in the later >>> >>release. >>> >> > >>> >> > John, do you have some experiences can share regarding dhcpd? >>> >> > >>> >> > Also, regarding your problem, have you used cloudstack to distribute >>> >> > IP? I don't think we support leasing on two /28s in advance network >>> >>now? >>> >> >>> >> So, in my lab env I've made a few changes to the server and UI to allow >>> >> multiple IP blocks in basic network (haven't tried in advanced yet), >>> >>then >>> >> additionally I'm passing a netmask down to the agent, then that's >>> >> passed >>> >> through to dhcp_entry.sh, and then into edithosts.sh, which I've >>> >>updated to >>> >> support dhcpd. The one thing I wanted to do but haven't is to update >>> >> edithosts.sh to support both dnsmasq as well as dhcpd. >>> >> >>> >> Note: this was done in-house without community involvement as I didn't >>> >> expect general interest in this, but I'm happy to use experience gained >>> >>to >>> >> write similar support in the ASF tree. >>> >> >>> >> Johh >>> >> >>> >>