Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 31 May 2011 21:05 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F14E08F4 for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 14:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level:
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kebcACqPDjmu for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 14:05:41 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9DE08F8 for <ipv6@ietf.org>; Tue, 31 May 2011 14:05:40 -0700 (PDT)
Received: by bwz13 with SMTP id 13so4652796bwz.31 for <ipv6@ietf.org>; Tue, 31 May 2011 14:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ymc6BdnwV3pWgDRbZ40bRhFrAzzc1z5XrEL1cW6OBsE=; b=ECtWMujJPGvmZ7nHAkERwA8iycFBVYJmuuYTJMZaP9smZwJePHFYik2EXaWcfkE8qs Bcn4hs+gxkAlLh6llutU7NpHTxdKUpCzvhBWxwTfRIv6An+2S3tRaJZ/k+bkEPhWmfr4 aTheJV9ilxMWc7grW+LMXwBBxCpX3xo5Dw08Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=W32dreDmGYdGYx2pXzLlvzGOC2TXQ6el6QzKtkh+/Aoj0yaXslchMYXX7ck4+mJhHy m1/unSersTjHZ+Sq7Giy7d6Dw+tc1xl31u0JnX2zekXtQ/w4O4NmuvrzwMoaeG8i0mDC 5gNQDXNW1g0kJODZX4xdhNVqaoj6DiS+UGjQ4=
Received: by 10.204.20.147 with SMTP id f19mr5867479bkb.163.1306875939844; Tue, 31 May 2011 14:05:39 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id l24sm337017bkw.15.2011.05.31.14.05.33 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 14:05:38 -0700 (PDT)
Message-ID: <4DE55815.3080702@gmail.com>
Date: Wed, 01 Jun 2011 09:05:25 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter <v6ops@globis.net>
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4DE5536D.9050906@globis.net> <4DE554F9.20603@globis.net>
In-Reply-To: <4DE554F9.20603@globis.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org, Ralph Droms <rdroms.ietf@gmail.com>, Thomas Narten <narten@us.ibm.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2011 21:05:42 -0000
Ray, Without going into details: how about turning this into draft-hunter-v6ops-something and having the debate over in v6ops? I think that would be useful, personally. Regards Brian On 2011-06-01 08:52, Ray Hunter wrote: > Sorry a couple of important typos on RFC numbers: email escaped too early. > Disregard previous message, and use this one. > > Ray Hunter wrote: >> It's definitely going to become an operational FAQ, unless it is very >> clear whether/how a network operator can force equivalent use of >> DHCPv4 static address assignment for both source and destination >> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of >> GUA on an interface via a flag, or via RFC3484 bis), and how to >> achieve this effect for all nodes on a link, without resorting to >> local configuration. So I may as well be the first to ask. > > In the absence of other answers, here's my analysis and "how to achieve > current semi backward-compatible DHCPv4 like behavior in DHCPv6". > > Conclusion: it does not see to be very straightforward IMVVHO. > [note: not in any way a flame, just an attempt at documenting a > real-live use-case v. current implementations of current standards > The use case is based on current implementations of IETF standards in > Windows 7 and Windows 2008. This is not a criticism of those OS'es. It's > just a common combination already in production that people like me can > easily relate to.] > > > Problem statement: a network manager wants to be able to create firewall > rules to control access at a granularity level of an individual Windows > 7 PC communicating via IPv6 with an individual Windows Server 2008. The > motivation is SoX / ISO27001 compliance. The manager does not want the > firewall rules to have to change every day, and the rules should also be > independent of the NIC related MAC/EUI-64 address so that they do not > change upon NIC hardware replacement. > > > Suggested analysis & solution according to TODAY's documents: > > Assumptions of today's default behavior (implementation dependent): > Both Windows 2008 & Windows 7 have IPv6 enabled by default and IPv6 is > preferred over IPv4 (source: Understanding IPv6 2) > Windows Server 2008 auto registers SLAAC IPv6 GUA in DNS, but not > temporary addresses. (source: Understanding IPv6 2) > DHCPv6 IPAM system will also register DHCPv6 assigned IPv6 GUA in DNS > (source: an commercial implementation) > Windows 7 uses temporary addresses for outbound sessions by default. > (source: Understanding IPv6 2) > Firewall only supports static filtering rules configured by the CLI. > (source: all common implementations) > DHCPv6 will be available in every implementation (via recent upgrade to > SHOULD in draft-ietf-6man-node-req-bis-10) > > > If a DNS server received auto-registration for both SLAAC GUA and DHCPv6 > GUA derived addresses in DNS, the manager does not want the Windows 7 > machine to connect to the SLAAC generated GUA e.g. > 2001:4f0:df8c:2:021c:c0ff:fee2:84e4 instead of the DHCPv6 obtained GUA > e.g. 2001:47f0:df8c:2::2 because only the DHCPv6 GUA 2001:47f0:df8c:2::2 > will have a firewall rule entry. > > Equally it is more than likely that there will be no firewall rule to > allow RFC 3041 temporary addresses from the Windows 7 PC source address, > so any session attempts to connect from a source using a temporary > address will also fail. > > > After doing my own research, I think the answer today to achieve desired > semi-backwards compatible DHCPv4 like behavior is: > > RFC3484 prefix policy table is required to determine source and > destination address preference if there are both DHCPv6 GUA & SLAAC GUA > configured on the same node at the same precedence in the prefix policy > table. > > RFC3484 & RFC3484 bis currently have no mechanism to achieve preference > of DHCPv6 GUA over a SLAAC GUA on the same prefix, so the manager > currently needs to stop both nodes obtaining a SLAAC derived GUA in the > first place, otherwise behavior is unpredictable [no tie break in > RFC3484 or RFC3484 bis]. > > Any RFC 3041 temporary addresses that are used by a client or server on > outbound sessions (Windows default) would also probably get blocked by a > host to server firewall rule. So the manager needs to turn off the > feature of using temporary addresses by default on every server and > every host system [no IETF mechanism to do this, so this is local > configuration via Active Directory or via a netsh command: netsh > interface ipv6 set global randomizeidentifiers=disabled]. > > > Now the router: > DHCPv6 relay =ENABLED, and manually configured pointed at a central > DHCPv6 server > > RA = ENABLED because it is needed for the default route on both Windows > machines > source http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-10 >> Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > are expected to determine their default router information and on-link > prefix information from received Router Advertisements. > > RA has to include all the DHCPv6 valid prefixes as RA options for on > link / off link determination > source RFC 4861 >> A router SHOULD include all its on-link prefixes (except the > link-local prefix) so that multihomed hosts have complete prefix > information about on-link destinations for the links to which they attach. > > RA has to be configured to set the A flag = OFF for ALL prefixes on this > router interface (autonomous address-configuration flag) > source RFC4862 >> If the Autonomous flag is not set, silently ignore the Prefix > Information option. > > M (managed) flag = ON -> indicate presence of DHCPv6 and desire to use it > source RFC4861 >> When set, it indicates that addresses are available via Dynamic Host > Configuration Protocol [DHCPv6]. > > O (Other) flag = X -> irrelevant > source RFC4861 >> If the M flag is set, the O flag is redundant and can be ignored > because DHCPv6 will return all available configuration information. > > > You may ask "how is this different from IPv4 today at an operational/ > implementation level?" > > IMVHO [this is not a flame! just an attempt at a neutral analysis from > an existing enterprise network based implementation] > We have no temporary IPv4 addresses to override by default > We have no SLAAC equivalent in IPv4 to turn off > By default nodes generally use DHCPv4 + broadcast on link connection > (hard coded default in almost every OS but which can be overridden) > Default router is generally learned via DHCPv4 in an existing tool > We generally only have one IPv4 address that is auto-registered in DNS > per adapter > We have no address selection issues (there's only 1 source and 1 > destination address) > DHCPv4 server or DHCPv4 relay is built into almost every implementation > even though it was hardly formally standardized > > regards, > RayH >
- RE: Node Requirements: Elevating DHCPv6 from MAY … Templin, Fred L
- Re: Node Requirements: Elevating DHCPv6 from MAY … Bob Hinden
- Node Requirements: Elevating DHCPv6 from MAY to S… Thomas Narten
- Re: Node Requirements: Elevating DHCPv6 from MAY … Ralph Droms
- Re: Node Requirements: Elevating DHCPv6 from MAY … Tim Chown
- Re: Node Requirements: Elevating DHCPv6 from MAY … Cameron Byrne
- Re: Node Requirements: Elevating DHCPv6 from MAY … Scott Brim
- Re: Node Requirements: Elevating DHCPv6 from MAY … Thomas Narten
- RE: Node Requirements: Elevating DHCPv6 from MAY … john.loughney
- Re: Node Requirements: Elevating DHCPv6 from MAY … Ralph Droms
- Re: Node Requirements: Elevating DHCPv6 from MAY … Thomas Narten
- Re: Node Requirements: Elevating DHCPv6 from MAY … Ralph Droms
- Re: Node Requirements: Elevating DHCPv6 from MAY … Timothy E. Enos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Bob Hinden
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mikael Abrahamsson
- RE: Node Requirements: Elevating DHCPv6 from MAY … john.loughney
- RE: Node Requirements: Elevating DHCPv6 from MAY … john.loughney
- RE: Node Requirements: Elevating DHCPv6 from MAY … john.loughney
- RE: Node Requirements: Elevating DHCPv6 from MAY … Basavaraj.Patil
- Re: Node Requirements: Elevating DHCPv6 from MAY … Christopher Morrow
- Re: Node Requirements: Elevating DHCPv6 from MAY … Wes Beebee
- Re: Node Requirements: Elevating DHCPv6 from MAY … Alexandru Petrescu
- Re: Node Requirements: Elevating DHCPv6 from MAY … Alexandru Petrescu
- Re: Node Requirements: Elevating DHCPv6 from MAY … james woodyatt
- Re: Node Requirements: Elevating DHCPv6 from MAY … Suresh Krishnan
- Re: Node Requirements: Elevating DHCPv6 from MAY … Cameron Byrne
- Re: Node Requirements: Elevating DHCPv6 from MAY … Randy Bush
- Re: Node Requirements: Elevating DHCPv6 from MAY … Wes Beebee
- Re: Node Requirements: Elevating DHCPv6 from MAY … james woodyatt
- Re: Node Requirements: Elevating DHCPv6 from MAY … Basavaraj.Patil
- Re: Node Requirements: Elevating DHCPv6 from MAY … Behcet Sarikaya
- Re: Node Requirements: Elevating DHCPv6 from MAY … Ed Jankiewicz
- RE: Node Requirements: Elevating DHCPv6 from MAY … Manfredi, Albert E
- RE: Node Requirements: Elevating DHCPv6 from MAY … Tony Hain
- Re: Node Requirements: Elevating DHCPv6 from MAY … sthaug
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brian Haberman
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brzozowski, John
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brzozowski, John
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brzozowski, John
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brzozowski, John
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brzozowski, John
- Re: Node Requirements: Elevating DHCPv6 from MAY … Timothy E. Enos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brian E Carpenter
- Re: Node Requirements: Elevating DHCPv6 from MAY … Seiichi Kawamura
- Re: Node Requirements: Elevating DHCPv6 from MAY … Thomas Narten
- Re: Node Requirements: Elevating DHCPv6 from MAY … Ralph Droms
- Re: Node Requirements: Elevating DHCPv6 from MAY … Christopher Morrow
- Re: Node Requirements: Elevating DHCPv6 from MAY … Thomas Narten
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brian E Carpenter
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mark Smith
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brian E Carpenter
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mark Smith
- RE: Node Requirements: Elevating DHCPv6 from MAY … Manfredi, Albert E
- Re: Node Requirements: Elevating DHCPv6 from MAY … Christopher Morrow
- Re: Node Requirements: Elevating DHCPv6 from MAY … Christopher Morrow
- Re: Node Requirements: Elevating DHCPv6 from MAY … Thomas Narten
- Re: Node Requirements: Elevating DHCPv6 from MAY … Christopher Morrow
- Re: Node Requirements: Elevating DHCPv6 from MAY … Thomas Narten
- Re: Node Requirements: Elevating DHCPv6 from MAY … Carsten Bormann
- Re: Node Requirements: Elevating DHCPv6 from MAY … james woodyatt
- RE: Node Requirements: Elevating DHCPv6 from MAY … Templin, Fred L
- RE: Node Requirements: Elevating DHCPv6 from MAY … Christopher Palmer
- RE: Node Requirements: Elevating DHCPv6 from MAY … john.loughney
- Re: Node Requirements: Elevating DHCPv6 from MAY … Thomas Narten
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mark Smith
- Re: Node Requirements: Elevating DHCPv6 from MAY … Brian E Carpenter
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mark Smith
- RE: Node Requirements: Elevating DHCPv6 from MAY … Templin, Fred L
- Re: Node Requirements: Elevating DHCPv6 from MAY … Doug Barton
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mark Smith
- Re: Node Requirements: Elevating DHCPv6 from MAY … Tim Chown
- Re: Node Requirements: Elevating DHCPv6 from MAY … RJ Atkinson
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: [ipv6] Node Requirements: Elevating DHCPv6 fr… Ray Hunter
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Multiple addresses [was Node Requirements: Elevat… Brian E Carpenter
- Re: Multiple addresses [was Node Requirements: El… Fred Baker
- Re: Multiple addresses [was Node Requirements: El… Ray Hunter
- Re: Multiple addresses [was Node Requirements: El… Fred Baker
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mohacsi Janos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mohacsi Janos
- Re: [ipv6] Node Requirements: Elevating DHCPv6 fr… Markus Hanauska
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: [ipv6] Node Requirements: Elevating DHCPv6 fr… Mohacsi Janos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mohacsi Janos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mikael Abrahamsson
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mikael Abrahamsson
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mohacsi Janos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mohacsi Janos
- Re: [ipv6] Node Requirements: Elevating DHCPv6 fr… Markus Hanauska
- Re: Multiple addresses [was Node Requirements: El… Brian E Carpenter
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mikael Abrahamsson
- Re: [ipv6] Node Requirements: Elevating DHCPv6 fr… Mohacsi Janos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: Multiple addresses [was Node Requirements: El… Tim Chown
- Re: Multiple addresses [was Node Requirements: El… Ralph Droms
- Re: Node Requirements: Elevating DHCPv6 from MAY … Markus Hanauska
- Re: Node Requirements: Elevating DHCPv6 from MAY … Mohacsi Janos
- Re: Node Requirements: Elevating DHCPv6 from MAY … Philip Homburg
- Re: [ipv6] Node Requirements: Elevating DHCPv6 fr… Mark Smith
- Re: [ipv6] Node Requirements: Elevating DHCPv6 fr… Markus Hanauska
- Re: Multiple addresses [was Node Requirements: El… james woodyatt
- Re: Multiple addresses [was Node Requirements: El… Ray Hunter
- Re: Multiple addresses [was Node Requirements: El… Ray Hunter
- Re: Multiple addresses [was Node Requirements: El… Mark Smith
- Re: Multiple addresses [was Node Requirements: El… Ralph Droms
- Re: Multiple addresses [was Node Requirements: El… Thomas Narten
- Re: Multiple addresses [was Node Requirements: El… Ralph Droms