Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 14 November 2019 15:46 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87A120896 for <v6ops@ietfa.amsl.com>; Thu, 14 Nov 2019 07:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 bWh7Zup_UYNB for <v6ops@ietfa.amsl.com>; Thu, 14 Nov 2019 07:46:15 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43181208A8 for <v6ops@ietf.org>; Thu, 14 Nov 2019 07:46:15 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAEFkE6r003953 for <v6ops@ietf.org>; Thu, 14 Nov 2019 16:46:14 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F13D120802D for <v6ops@ietf.org>; Thu, 14 Nov 2019 16:46:13 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E69F1208029 for <v6ops@ietf.org>; Thu, 14 Nov 2019 16:46:13 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xAEFkDtr009172 for <v6ops@ietf.org>; Thu, 14 Nov 2019 16:46:13 +0100
To: v6ops@ietf.org
References: <c4791cdd-6021-de83-6863-4d77ef1d1694@gmail.com> <CAOSSMjWu7C9jmG+8Yg7V++3GWzG+BSzFu0o0nHHYJY60P2T2oA@mail.gmail.com> <835b8b49-b00a-6fe3-1f47-7db7d5a76b92@gmail.com> <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <858c9dc2-374c-41a3-5726-90794c6af1f3@gmail.com>
Date: Thu, 14 Nov 2019 16:46:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <3e0779de-b740-a9e6-02ce-e18d43795f5c@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/MKTCVuXsow2jvlRLn8EMznpqrAY>
Subject: Re: [v6ops] RFC7084 - absence of req of prefix presence in PIO on LAN?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2019 15:46:19 -0000

It boils down to distinct intepretations of these terms:

- a router _advertises_ itself as a router for prefix A:
   - does it mean it puts A in PIO in Router Advertisement?
   - does it mean it puts A in Link-State Advertisement of OSPF?
   - does it mean that some other router has a route for that prefix A
     pointing to this router?

- a prefix is 'assigned' to an interface:
   - does it mean the ifconfig add address/prefix was run on that
     interface?
   - does it mean that the prefis is put in the RA in PIO put on
     that interface?

There are other difficulties with other terms, such as 'delegate 
prefix', 'subnetted prefix' and 'assigned prefix'.

I propose that we clarify these.

Alex


Le 14/11/2019 à 13:49, Alexandre Petrescu a écrit :
> Brian,
> 
> Thanks for the reply.
> 
> Le 13/11/2019 à 20:39, Brian E Carpenter a écrit :
>> On 14-Nov-19 03:16, Timothy Winters wrote:
>>> Hi Alex,
>>>
>>> On Wed, Nov 13, 2019 at 2:54 AM Alexandre Petrescu 
>>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
>>> wrote:
>>>
>>>> Hi, v6opsers,
>>>>
>>>> While reading through RFC7084 I couldnt find a place where the
>>>> CE Router is mandated to put a prefix in the PIO, even though
>>>> there is a (strange?) requirement to use RIO.
>>>>
>>>> I would like to ask:
>>>>
>>>> - which existing particular requirement the author assumes to be 
>>>> putting a derived /64 in the PIO in the RA?
>>>
>>> The placing of the prefixes in the PIO from the IA_PD was originally 
>>> located in RFC 3633, so it's not covered in 7084.
>>
>> More to the point of Alex's question, 7084 says:
>>
>>>>> The IPv6 CE router MUST support router behavior according to 
>>>>> Neighbor Discovery for IPv6 [RFC4861].
>>
>> which therefore requires properly formed PIOs.
> 
> It is clear to certain readers.  But to me it is a long stretch.  It is
> a long stretch to consider RFC7084 ref to RFC4861 to consider that
> RFC7084 requires prefixes be present in the PIO.
> 
> For one, RFC7084 also refers to DHCPv6 RFC, which in turns talks about
> 'assigning a prefix to an interface', and not about putting a prefix in
> the PIO.
> 
> In practice, assigning a prefix to an interface does not mean putting it
> in the PIO in the RA.  It means to add a particular kind of entry in the
> routing table for that prefix and that interface.
> 
> Second, RFC4861 never talks about 'assigning a prefix to an interface'.
>   Where RFC4861 assigns something it is either addresses to interfaces
> (not prefixes), or numbers at IANA.
> 
>>>> - what does it mean 'An IPv6 CE router MUST advertise itself as
>>>> a router for the delegated prefix(es) [...] using the "Route 
>>>> Information Option" specified in Section 2.3 of [RFC4191].'?  (I am 
>>>> asking because I suspect this requirement is wrong: the CE Router 
>>>> must certainly not use RIO with these prefixes).
>>
>> Why is that wrong? It is under "LAN requirements:" and seems to mean 
>> exactly what Alex says next:
>>
>>>> CE Routers should place the RIO in the RAs on the LAN interface to 
>>>> have Host route traffic for those prefixes to that Router if they 
>>>> have multi-homed
> 
> a. reading L-2 after L-3 makes think (IMHO) that the prefix derived from
>     the delegated prefix would be put in the RIO.  That is wrong.  It
>     should be put in the PIO, not in the RIO.
> 
> b.  L-3 "[on LAN] CE router MUST advertise itself as a router for the
>      delegated prefix(es)" is wrong in many readings I could try.
>      The right statements are:
>     - CE router MUST advertise itself as a router for reaching the
>       Internet.
>     - CE router MUST put in PIO in RA some prefix useful for SLAAC;
>       this prefix is obtained out of the delegated prefix, or elsewhere.
>       this prefix MUST NOT be the delegated prefix.
>     - CE router MUST NOT advertise itself as a router for the delegated
>       prefix(es); it is the router situated in the ISP premisses that
>       must do that.
> 
>> (Although, not surprisingly, I would like to see RFC8028 mandated>
>> too.)
> 
> I think RFC8028 sounds in context: "First-Hop Router Selection in a
> Multi-Prefix Network".
> 
> However, I am not sure where RFC8028 would apply: is it between the CE
> Router and the two ISPs?  Or is it between in-house Host and the single
> CE Router?
> 
> Alex
> 
>>
>> Regards Brian
>>>>
>>>> Alex
>>>
>>> Regards, Tim
>>
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops