IETF Logo Mail Archive

RE: RFC7084

Wuyts Carl <Carl.Wuyts@technicolor.com> Tue, 10 December 2013 07:20 UTC

Return-Path: <Carl.Wuyts@technicolor.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 74FF91AE330; Mon, 9 Dec 2013 23:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.695
X-Spam-Level:
X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5P9tHVk92Y9Y; Mon, 9 Dec 2013 23:20:34 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id ABAEE1AE20B; Mon, 9 Dec 2013 23:20:30 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUqbAuboyTFGo7+L0ZPWlFq4Eg2dOWudk@postini.com; Mon, 09 Dec 2013 23:20:29 PST
Received: from MOPESMAILHTC01.eu.thmulti.com (141.11.100.10) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 10 Dec 2013 08:13:13 +0100
Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.32]) by MOPESMAILHTC01.eu.thmulti.com ([141.11.100.10]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 08:13:15 +0100
From: Wuyts Carl <Carl.Wuyts@technicolor.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Subject: RE: RFC7084
Thread-Topic: RFC7084
Thread-Index: Ac705Oox+bAOGgDPSBCf3B3p1FF6cAAA4TqgACKmQYD///b6gP//7wHQ
Date: Tue, 10 Dec 2013 07:13:14 +0000
Message-ID: <96747494E3D74D41B20907035DB1E48DCE42@MOPESMBX03.eu.thmulti.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>
In-Reply-To: <alpine.DEB.2.02.1312100803370.24602@uplift.swm.pp.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.11.249.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:20:39 -0000

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
Sent: dinsdag 10 december 2013 8:10
To: Wuyts Carl
Cc: STARK, BARBARA H; <ipv6@ietf.org>; v6ops@ietf.org
Subject: RE: RFC7084

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?

[Carl] Correct, as you state and/OR, not AND only.  RFC7084 today says AND.

> 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.
[Carl] why ask for both ?  Why making diff between the 2 if you always ask for both ?  Why not asking all options and just wait and see what you get back ?

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

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