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
- On sending SLAAC information into split RAs Fernando Gont
- Re: On sending SLAAC information into split RAs Timothy Winters
- Re: On sending SLAAC information into split RAs Fernando Gont
- Re: On sending SLAAC information into split RAs Timothy Winters
- Re: On sending SLAAC information into split RAs Michael Richardson
- Re: On sending SLAAC information into split RAs Fernando Gont
- Re: On sending SLAAC information into split RAs Philip Homburg
- Re: On sending SLAAC information into split RAs Timothy Winters
- Re: On sending SLAAC information into split RAs otroan
- Re: On sending SLAAC information into split RAs Michael Richardson
- Re: On sending SLAAC information into split RAs Fernando Gont