IETF Logo Mail Archive

RE: RFC7084

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 10 December 2013 07:10 UTC

Return-Path: <swmike@swm.pp.se>
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 637371AE2CF; Mon, 9 Dec 2013 23:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level:
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 y-CmsT-ivLml; Mon, 9 Dec 2013 23:10:33 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id AE33B1AE2D1; Mon, 9 Dec 2013 23:10:33 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8D8969C; Tue, 10 Dec 2013 08:10:27 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 86C3F9A; Tue, 10 Dec 2013 08:10:27 +0100 (CET)
Date: Tue, 10 Dec 2013 08:10:27 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Wuyts Carl <Carl.Wuyts@technicolor.com>
Subject: RE: RFC7084
In-Reply-To: <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com>
Message-ID: <alpine.DEB.2.02.1312100803370.24602@uplift.swm.pp.se>
References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
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 07:10:36 -0000

On Tue, 10 Dec 2013, Wuyts Carl wrote:

> Again, you're binding WRONG the M to ia_na.  this is really not good. 
> Let us implement standards based upon what they are designed for.  The 
> M-flag was initially designed to flag the device to be Managed, not to

>From RFC4861:

M              1-bit "Managed address configuration" flag.  When
                      set, it indicates that addresses are available via
                      Dynamic Host Configuration Protocol [DHCPv6].

I interpret this as M=1 means addresses are available via DHCPv6, that 
means IA_NA and/or IA_PD, one or both might be available. I don't really 
understand why you do not. What do you think the M flag means? Reading the 
above text seems to indicate that you think it has something to do with 
managing the CPE?

> Just FYI.  A lot of our customers don't even use ia_na.  And yes, they 
> are using M=1, nearly all of them.

That's fine. The CPE should however ask for both, if the network doesn't 
give ia_na to it, then that's fine.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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