RE: Route Information Options in Redirect Messages (updated)

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 07 February 2017 19:54 UTC

Return-Path: <Fred.L.Templin@boeing.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 BF785129E8D for <ipv6@ietfa.amsl.com>; Tue, 7 Feb 2017 11:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9nS9hn4ATKhA for <ipv6@ietfa.amsl.com>; Tue, 7 Feb 2017 11:54:13 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 086FB129E88 for <ipv6@ietf.org>; Tue, 7 Feb 2017 11:54:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v17Js6bd050793; Tue, 7 Feb 2017 12:54:06 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v17Jrv44050696 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2017 12:53:57 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 11:53:57 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Tue, 7 Feb 2017 11:53:57 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Mark Smith <markzzzsmith@gmail.com>
Subject: RE: Route Information Options in Redirect Messages (updated)
Thread-Topic: Route Information Options in Redirect Messages (updated)
Thread-Index: AdJ8F7CvYW0JrWzvRzOTQSlLsXA0KQA/bwYAACZxdWAA79nnKQAAmI2QABLuxgAAEEj3sA==
Date: Tue, 7 Feb 2017 19:53:57 +0000
Message-ID: <383329d88978415c9b0a12f473787c2e@XCH15-06-08.nw.nos.boeing.com>
References: <9910b4acd87044e89fad83bb5c795b77@XCH15-06-08.nw.nos.boeing.com> <CAJE_bqfJMW5SRDxm04rC67Xvf4YqaxihyCRUXfGW3TUq42Xk-A@mail.gmail.com> <5ebd374f4ec8454b8a3796cffe5e1919@XCH15-06-08.nw.nos.boeing.com> <CAJE_bqfN9x031TXBd8Hpiv5168=zXXN+U02gGqsxyXhpQ-SDWA@mail.gmail.com> <E291D7B9-7492-4043-BE4F-E45CB54985D7@google.com> <CAJE_bqePL1bKAZL53=oebn=2eiYKdxyULd5jS4uJk9jo1sFrcA@mail.gmail.com> <614ead862aa54a548ed4835a998a42e4@XCH15-06-08.nw.nos.boeing.com> <CAO42Z2x4WZ6ObVBkawXEhtO2SqWfoQrOCvNCNXVrkpNKrzj=LQ@mail.gmail.com>
In-Reply-To: <CAO42Z2x4WZ6ObVBkawXEhtO2SqWfoQrOCvNCNXVrkpNKrzj=LQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: multipart/alternative; boundary="_000_383329d88978415c9b0a12f473787c2eXCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/a7zIphuEMMaZdVkcZAMdJ5-htlI>
Cc: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>, =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 07 Feb 2017 19:54:16 -0000

Hi Mark,


Ø  I think you need to be careful of not effectively reinventing a dynamic routing protocol

No, there is no reinvention going on here. The behavior parallels redirects
for singleton destination addresses, where Redirects are accepted from the
current first-hop router, be it a default or non-default.

Thanks - Fred

From: Mark Smith [mailto:markzzzsmith@gmail.com]
Sent: Tuesday, February 07, 2017 11:38 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: 6man WG <ipv6@ietf.org>rg>; james woodyatt <jhw@google.com>om>; 神明達哉 <jinmei@wide.ad.jp>
Subject: RE: Route Information Options in Redirect Messages (updated)



On 8 Feb. 2017 05:43, "Templin, Fred L" <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
Hi Jinmei-san,
<snip>
>
> Hmm, maybe I'm so dumb but I'm afraid I still don't understand intent
> clearly.  Do you mean an operational assumption of this proposal is to
> use it in a link where RA guard isn't deployed?  If so, it's far
> better (at least to me) to just say so.
>
> BTW, if this proposal keeps the concept of "unsolicited redirect" and
> also allows the destination address of '::' to bypass the host's
> validity check of whether it's really the first hop router for the
> destination,
No, that is not what we want to have happen. The document doesn't
say this currently, but we want to retain a revised version of the validity
check. The revised version of the check would say:

OLD:
      - The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address.
NEW:
      - The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address, or
        (when the ICMP Destination Address is '::') the same as the current
        first-hop router for the specified RIOs

Would welcome better wording than this, but we definitely do want
to retain the validity check. Comments?

I think you need to be careful of not effectively reinventing a dynamic routing protocol that ends up missing the necessary capabilities required of one to keep this method simple.

When I've thought about this sort of capability, I've thought of it as a hint from the routing system to the users of the forwarding domain - hosts and stub routers (default and connected route only routers, possibly with other static routes) - of a better entry point for their packets into the forwarding domain.

In the case of a stub router, if it needs or would benefit from more dynamic network information than just a prefix redirect hint, then I think that is really saying that the stub router shouldn't be a stub router - it needs to be a full and proper participant in the routing system (running dynamic routing protocol, discovering and conveying network topology information etc.), rather than a user of it via  default route to the forwarding domain.

That's why I thought the validation should be that these prefix redirects are only accepted from a default router learned via an RA or static default router configuration, as a default router has the role of offering an entry point into the forwarding domain. It would enforce the existing boundary between the devices that are users of the forwarding domain, and the devices that are participants in the routing system that decide the paths through the forwarding domain.

Regards,
Mark.