Re: [v6ops] RFC7084

Ole Troan <otroan@employees.org> Tue, 10 December 2013 17:15 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14D01AE037; Tue, 10 Dec 2013 09:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 1xaWmfVQ0jaq; Tue, 10 Dec 2013 09:15:15 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4C1AE136; Tue, 10 Dec 2013 09:15:15 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8FAGdLp1KQ/khN/2dsb2JhbABZgwe6KYEeFnSCJQEBBAF5BQsLRlcGiA8GwRMXjwUHgyGBEwSQMZl2gyo7
X-IronPort-AV: E=Sophos; i="4.93,865,1378857600"; d="asc'?scan'208"; a="1970817"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 10 Dec 2013 17:15:09 +0000
Received: from dhcp-10-61-104-186.cisco.com (dhcp-10-61-104-186.cisco.com [10.61.104.186]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBAHF1PC024392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 17:15:05 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_4FFDB8B1-EF34-4974-A170-8652236A0321"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: [v6ops] RFC7084
From: Ole Troan <otroan@employees.org>
In-Reply-To: <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com>
Date: Tue, 10 Dec 2013 18:14:56 +0100
Message-Id: <8185CEF1-9037-4956-B37E-0CFAE5689316@employees.org>
References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <alpine.DEB.2.02.1312100803370.24602@uplift.swm.pp.se> <F92E1B55-C74B-400C-B83E-6B50D175D121@steffann.nl> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1822)
Cc: 6man WG <ipv6@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Dec 2013 17:15:17 -0000

Ted,

>> As far as I know the M flag is linked only to IA_NA. As far as I can see IA_PD is not linked to the M flag at all.
> 
> There is no agreement on what the M and O bits do.   Some people think M means stateful address management; some think M means IA_NA and O means IA_PD.   RFC 4861 is actually fairly clear, at least to my reading of it, that "M" means IA_NA and IA_PD, and that "O" means stateless DHCPv6, but I've heard people argue vehemently that "M" means _only_ IA_NA, and that "O" means IA_PD, because prefixes aren't addresses.

that's incorrect. there are no flags in the RA that indicates if prefix delegation is available or not.
prefix delegation is between routers, routers don't listen to RAs was the rationale.

> So if you believe my reading of RFC 4861, you would set 'M' and expect the HG to get both IA_NA and IA_PD; RFC 7084 makes it clear that _either_ the 'M' or 'O' bit being set triggers the HG to do prefix delegation.

a RFC6204 CPE must act as a requesting router and request IA_PD in all cases.
it may choose to request the IA_NA based on the M flag or it might do so regardless, both
approaches are fine.

> So if you want to do prefix delegation and not stateful address assignment, set the 'O' bit and _not_ the 'M' bit, even though that contradicts what RFC 4861 says.

no, that's not what these flags mean.

cheers,
Ole