Re: RFC7084

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 11 December 2013 10:04 UTC

Return-Path: <alexandru.petrescu@gmail.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 C59921ADF0E for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2013 02:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 rFWUfKjMAhnz for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2013 02:04:40 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6C1AD935 for <ipv6@ietf.org>; Wed, 11 Dec 2013 02:04:40 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBBA4YOx001496; Wed, 11 Dec 2013 11:04:34 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E683F204BEF; Wed, 11 Dec 2013 11:04:51 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D89A2204BE9; Wed, 11 Dec 2013 11:04:51 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBBA4Xs5015392; Wed, 11 Dec 2013 11:04:34 +0100
Message-ID: <52A838B1.7040402@gmail.com>
Date: Wed, 11 Dec 2013 11:04:33 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Wuyts Carl <Carl.Wuyts@technicolor.com>, Simon Perreault <simon.perreault@viagenie.ca>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: RFC7084
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> <96747494E3D74D41B20907035DB1E48DCE42@MOPESMBX03.eu.thmulti.com> <52A7236A.30605@viagenie.ca> <96747494E3D74D41B20907035DB1E48DD168@MOPESMBX03.eu.thmulti.com> <52A72500.6020009@viagenie.ca> <96747494E3D74D41B20907035DB1E48DD181@MOPESMBX03.eu.thmulti.com>
In-Reply-To: <96747494E3D74D41B20907035DB1E48DD181@MOPESMBX03.eu.thmulti.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Wed, 11 Dec 2013 10:04:42 -0000

Le 10/12/2013 15:29, Wuyts Carl a écrit :
> M=1 equals Managed flag = request ia_na or/and ia_pd.

How about a new 3rd flag?

> Please note a router is also acting as host.

YEs and no.

YEs in that it may act as a DHCP Client (which is typically a Host).

No in that, e.g., the link-scoped multicast groups are different among 
Routers and Nodes (Node being an additional quirk).

Alex


>
> Regs
> Carl
>
>
> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault@viagenie.ca]
> Sent: dinsdag 10 december 2013 15:28
> To: Wuyts Carl; ipv6@ietf.org
> Subject: Re: RFC7084
>
> Le 2013-12-10 09:25, Wuyts Carl a écrit :
>> M=1 should not be equal to force request ia_na.
>
> What should M=1 mean then?
>
>> what's the purpose of having separate options (ia_na and ia_pd)  if you're going to request both of them anyway ?
>
> The answer to that seems simple to me: an end host would never request IA_PD. Only routers would.
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>