Re: RA Option Guidelines

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 07 April 2015 12:02 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 03D701B3523 for <ipv6@ietfa.amsl.com>; Tue, 7 Apr 2015 05:02:51 -0700 (PDT)
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 rxDdr7pPCefd for <ipv6@ietfa.amsl.com>; Tue, 7 Apr 2015 05:02:45 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C931B3513 for <ipv6@ietf.org>; Tue, 7 Apr 2015 05:02:43 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t37C2eTw031763 for <ipv6@ietf.org>; Tue, 7 Apr 2015 14:02:40 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 507E9202CC2 for <ipv6@ietf.org>; Tue, 7 Apr 2015 14:03:43 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 48D4F202C7E for <ipv6@ietf.org>; Tue, 7 Apr 2015 14:03:43 +0200 (CEST)
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 t37C2Ki0024725 for <ipv6@ietf.org>; Tue, 7 Apr 2015 14:02:40 +0200
Message-ID: <5523C74C.4050201@gmail.com>
Date: Tue, 07 Apr 2015 14:02:20 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: RA Option Guidelines
References: <5515A9A7.3080508@innovationslab.net> <281018849.2116525.1427767749309.JavaMail.yahoo@mail.yahoo.com> <75B6FA9F576969419E42BECB86CB1B8916834620@xmb-rcd-x06.cisco.com> <2D09D61DDFA73D4C884805CC7865E61130F8C7AF@GAALPA1MSGUSRBF.ITServices.sbc.com> <75B6FA9F576969419E42BECB86CB1B89168346DA@xmb-rcd-x06.cisco.com> <551AF4E5.7000207@gmail.com> <551EE710.2050301@gmail.com>
In-Reply-To: <551EE710.2050301@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/71Asec6ypuxGksR5wqiB82g6_p0>
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, 07 Apr 2015 12:02:51 -0000

Le 03/04/2015 21:16, Brian E Carpenter a écrit :
> I'm glad y'all have got DHCPv6 sorted out. Now, as to the original
> subject of this thread: On 01/04/2015 08:26, Brian E Carpenter
> wrote:
>> On 01/04/2015 03:27, Hemant Singh (shemant) wrote: ...
>>> Also, why does one need an RA Option Guideline?  RFC4861
>>> specifies a TLV format and an option Type.   I don't see
>>> anything else needed if I need to specify a new RA option.
>>
>> Section 9 "Extensibility - Option Processing" gives some general
>> advice, too.
>>
>> The question is what do we collectively want. I liked Mark's
>> restrictive criterion "RA options should be limited to
>> link-local/subnet specific parameters (i.e., layer 3 parameters
>> only)". DHCPv6 is available as the kitchen sink protocol for other
>> stuff. I'm not sure whether we want to write this down; it seems
>> as if  one or two sentences should be added to RFC4861bis if there
>> ever is such a document.
>
> Do we actually agree on this, or rather on a slightly expanded
> version:
>
> RA options should be limited to link-local/subnet specific parameters
> (i.e., layer 3 parameters only) necessary for a simple unmanaged
> network. The only exception is RFC 6106 (DNS Configuration). More
> complex situations are better handled by other configuration metods
> such as DHCPv6.

It makes sense.

But, would it be possible to tell link-local subnet of a particular
Router?  I am asking because currently it is the link-local subnet of
one particular interface, the "on-link" prefix;  and it would be good to
allow a prefix in one subnet of an interface of a router be announced on
another interface of same router as "other prefix nearby".

And still forbid one Router to read an RA and propagate its contents
further down the network.

Alex


>
> Brian
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>