IETF Logo Mail Archive

Re: [v6ops] control and security of DHCP

Owen DeLong <owen@delong.com> Tue, 14 January 2014 18:18 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC31ADF8F for <v6ops@ietfa.amsl.com>; Tue, 14 Jan 2014 10:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.529
X-Spam-Level:
X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZbuFA2hHxmg for <v6ops@ietfa.amsl.com>; Tue, 14 Jan 2014 10:18:09 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D63D61ADEB4 for <v6ops@ietf.org>; Tue, 14 Jan 2014 10:18:08 -0800 (PST)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s0EIH8tq031563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jan 2014 10:17:08 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s0EIH8tq031563
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389723428; bh=2VQ650Gvu6hoQZDOaV64vmX9py4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rhwnhDEUBXdr334CgZze2p2U/hTgSvieYq7YumQStHgGWgEd4mF+HOWF77T5cO8m5 Kmx+4WgSEeFR90D0qGfWBbyRfXh8NFBdmUwGhXZzO7oJB9BGWYQcBQK9KR0b6KIwc+ FPxOxrwoilfFhl3R9nuBtvdioL3zuNm4a7988cLE=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <52D57DC5.9080603@globis.net>
Date: Tue, 14 Jan 2014 10:17:13 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <807E80E4-40CA-49CD-AC7D-F512D5B51B23@delong.com>
References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <B54D5283-8880-434A-A3C0-9BFF0081E13B@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <alpine.DEB.2.02.1401101651580.20074@uplift.swm.pp.se> <D1FC3C0B-CC5D-44BC-B753-2F1BD94A48FA@nominum.com> <CAKD1Yr1C0jRNq-ta=HeGFusC8VFGGg1ffDFLoroUoiHmX-KYiA@mail.gmail.com> <52D18F22.1070708@foobar.org> <CAKD1Yr2PrG_Rit2YCAkep4_-LUSqNpEU-t+ttRsLPpSbYVLoig@mail.gmail.com> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1827)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 14 Jan 2014 10:17:08 -0800 (PST)
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] control and security of DHCP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 18:18:10 -0000

On Jan 14, 2014, at 10:11 , Ray Hunter <v6ops@globis.net> wrote:

>> Nick Hilliard <mailto:nick@foobar.org>
>> 14 January 2014 18:21
>> 
>> private vlans are troublesome, to say the least. In a virtualised
>> environment, you need multi-switch support for specific types of pvlans.
>> This places vendor restrictions on the types of kit you need to deploy.
>> 
>> Nick
>> ------------------------------------------------------------------------
> Yes.
> 
> I've read posts from a number of DC operators who have expressly chosen for PVLANs compared to deploying dedicated L3 ports per server/ customer in multi-tenant environments, driven by a desire to save on very scarce public IPv4 addresses.

Which might make sense when the customers are on separate hardware.

When the customers are separate virtuals on the same hardware, PVLANs become a bit less useful, though at that point, dedicated L3 ports in the virtual switch on the host become much more feasible, though you still have the network addressing cost issue if you're tied to IPv4.

> That of course will likely bring problems migrating to IPv6 in the future e.g. DAD is probably not going to be able to detect duplicate addresses via multicast.

Depends on how the PVLANs treat link-scoped IPv6 multicast.

> Hence my suggestion of prefix length >> 64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup.

Not sure how that really helps. Why is a longer prefix length allegedly useful in this context?

Owen

v2.23.0 | Report a Bug | By Email