Re: On sending SLAAC information into split RAs

Fernando Gont <fgont@si6networks.com> Mon, 09 March 2020 19:10 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB153A159B for <ipv6@ietfa.amsl.com>; Mon, 9 Mar 2020 12:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 6GVYc52dByYb for <ipv6@ietfa.amsl.com>; Mon, 9 Mar 2020 12:10:16 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38ED83A15AA for <6man@ietf.org>; Mon, 9 Mar 2020 12:10:15 -0700 (PDT)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 846FE803C3; Mon, 9 Mar 2020 20:10:10 +0100 (CET)
Subject: Re: On sending SLAAC information into split RAs
To: Timothy Winters <tim@qacafe.com>
Cc: "6man@ietf.org" <6man@ietf.org>
References: <7605befb-1d49-50d0-c8af-e1fb0f1af171@si6networks.com> <CAJgLMKtVvk8g7wjiVgWO+v_jxZaMybArzpMEAJLxeyLWwM5rfA@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <2490147b-be1a-0fe6-8dcb-d79f1cd7dc82@si6networks.com>
Date: Mon, 09 Mar 2020 16:09:53 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAJgLMKtVvk8g7wjiVgWO+v_jxZaMybArzpMEAJLxeyLWwM5rfA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZL_s_gDlrYsUsKNJSZtwjvHJ3vA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 09 Mar 2020 19:10:24 -0000

Hello, Tim,

Thanks for your timely and useful data! In-line....

On 9/3/20 14:28, Timothy Winters wrote:
> Hi Fernando,
> 
> While I think we could say something about this, I've not seen a Router 
> implementation split this type of information up into multiple 
> messages.   Probably safest to recommend that it be done in one message.

Looking at Section 6.2.3 of RFC4861, it seems such behavior is implicit.

I'm curious: Have you seen any implementations that "omit" information 
as allowed in Section 6.2.3 of RFC4861:

   "A router MAY choose not to include some or all options when sending
    unsolicited Router Advertisements.  For example, if prefix lifetimes
    are much longer than AdvDefaultLifetime, including them every few
    advertisements may be sufficient.  However, when responding to a
    Router Solicitation or while sending the first few initial
    unsolicited advertisements, a router SHOULD include all options so
    that all information (e.g., prefixes) is propagated quickly during
    system initialization."

I've never seen one myself, and also think that it implies more trouble 
(increased code complexity, etc.)



So our plan is to have this doc update this text:

---- cut here ----
    A router MAY choose not to include some or all options when sending
    unsolicited Router Advertisements.  For example, if prefix lifetimes
    are much longer than AdvDefaultLifetime, including them every few
    advertisements may be sufficient.  However, when responding to a
    Router Solicitation or while sending the first few initial
    unsolicited advertisements, a router SHOULD include all options so
    that all information (e.g., prefixes) is propagated quickly during
    system initialization.

    If including all options causes the size of an advertisement to
    exceed the link MTU, multiple advertisements can be sent, each
    containing a subset of the options.
---- cut here ----

with this:

---- cut here ----
    When sending Router Advertisements, a router SHOULD include all
    options wso that all information (e.g., prefixes) propagates
    quickly, and hosts result in more uniform configuration.

    If including all options causes the size of an advertisement to
    exceed the link MTU, multiple advertisements can be sent, each
    containing a subset of the options. In all cases, routers SHOULD
    convey all information using the smallest possible number of
    packets.
---- cut here ----

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492