IETF Logo Mail Archive

Re: [v6ops] RFC7084

Ted Lemon <ted.lemon@nominum.com> Tue, 10 December 2013 16:51 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 8ED751AE18D; Tue, 10 Dec 2013 08:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 S0H96_t4DdYq; Tue, 10 Dec 2013 08:51:52 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id B73A81AE190; Tue, 10 Dec 2013 08:51:52 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUqdGo/CDhGgEPYE/lwfO4A8nI3am72jk@postini.com; Tue, 10 Dec 2013 08:51:47 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 49ED01B8307; Tue, 10 Dec 2013 08:51:47 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2974D190052; Tue, 10 Dec 2013 08:51:47 -0800 (PST)
Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 08:51:46 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: [v6ops] RFC7084
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <F92E1B55-C74B-400C-B83E-6B50D175D121@steffann.nl>
Date: Tue, 10 Dec 2013 11:51:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com>
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>
To: Sander Steffann <sander@steffann.nl>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: [192.168.1.10]
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "<ipv6@ietf.org>" <ipv6@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 16:51:54 -0000

On Dec 10, 2013, at 6:08 AM, Sander Steffann <sander@steffann.nl> wrote:
> 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.

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.

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.

v2.43.4 | Report a Bug | By Email | System Status