IETF Logo Mail Archive

Re: universal RA option

james woodyatt <jhw@conjury.org> Mon, 08 April 2019 13:59 UTC

Return-Path: <jhw@conjury.org>
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 4C7EC1203A6 for <ipv6@ietfa.amsl.com>; Mon, 8 Apr 2019 06:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 EUSjHBJV3-mF for <ipv6@ietfa.amsl.com>; Mon, 8 Apr 2019 06:59:49 -0700 (PDT)
Received: from mail.conjury.org (prime.conjury.org [174.136.98.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCBC120310 for <6man@ietf.org>; Mon, 8 Apr 2019 06:59:49 -0700 (PDT)
Received: from [IPv6:2607:f598:b0b2:cf00:5c2d:f361:8ee:5f6] (unknown [IPv6:2607:f598:b0b2:cf00:5c2d:f361:8ee:5f6]) by mail.conjury.org (Postfix) with ESMTPSA id 6A421E6003; Mon, 8 Apr 2019 06:22:35 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: universal RA option
From: james woodyatt <jhw@conjury.org>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <7C422B44-CA7E-403C-B187-56FBE8142AB0@employees.org>
Date: Mon, 08 Apr 2019 06:59:47 -0700
Cc: 6man@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F63627C3-4D8F-464D-923E-0EB744EA7C66@conjury.org>
References: <E2AC1BED-4D13-4169-B9A9-4B29F00E8FCE@conjury.org> <7C422B44-CA7E-403C-B187-56FBE8142AB0@employees.org>
To: Ole Troan <otroan@employees.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/88fgMROMohNIX9gZUy2QyeOKxhg>
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, 08 Apr 2019 13:59:52 -0000

Hi Ole,

By some lights, neighbor discovery is already a routing protocol. One with a lot of terrible limitations that are the subject of various recurring debates in 6MAN.

The question you’re asking, by those lights, seems to be this one: do we want to improve the protocol by addressing those limitations? Or do we reaffirm the case that hosts sensitive to dynamic routing changes should participate in existing standard routing protocols?

I think if we publish this draft, then we’re kind of inviting experimentation aimed to improve neighbor discovery, and we would do well to optimize it for the opportunity. Otherwise, I’m not sure I see the point of limiting the utility of the universal option to just Routing Advertisement messages.

—sent from my phone

> On Apr 8, 2019, at 06:41, Ole Troan <otroan@employees.org> wrote:
> 
> James,
> 
>> If a universal option format is warranted for Router Advertisement messages, then I suggest defining it for all the messages in section 4 of RFC 4861, and not just for the Router Advertisement message. That would allow, for example, refactoring of this expired draft to use it:
>> 
>>    <https://tools.ietf.org/html/draft-templin-6man-rio-redirect>
> 
> Right…
> Do we want to evolve ND into a poor mans routing protocol though?
> Or a “static route negotiation protocol”?
> 
> Cheers,
> Ole

v2.23.0 | Report a Bug | By Email