RE: Route Information Options in Redirect Messages (updated)

Mark Smith <markzzzsmith@gmail.com> Tue, 07 February 2017 19:38 UTC

Return-Path: <markzzzsmith@gmail.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 EA4E5129E3E for <ipv6@ietfa.amsl.com>; Tue, 7 Feb 2017 11:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Q2Kj0SWFOu1A for <ipv6@ietfa.amsl.com>; Tue, 7 Feb 2017 11:38:20 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5168D129E5E for <ipv6@ietf.org>; Tue, 7 Feb 2017 11:38:20 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id 96so92774961uaq.3 for <ipv6@ietf.org>; Tue, 07 Feb 2017 11:38:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G3ReoA+Q3hMysE2G/yhL0kVFt1j21GtqD1MjxckBZS4=; b=fcsbauEmtn9Jnj9kNGhgNVSw9soxPuIdUhoI3mqG8tCi+S/fkxuaZpyzvQ0l037qxf bJlgZOvwIutpZJn6cdc6UcXk/85QhpmBt5k344useb4WOQc84cAdwkEFjvktqSDkMKGz qg/pC6CSBcNjreyEpUn+lU5ZmYv7gXx/whOZ3L6UBXt7R7CP+9nj4bKG0cDOXrLIkl7s xiMvqQ/0hQJgtoQEzkIRRX11NbDugLpcVz52brm1VUniewHxy+7MtxnQ48vIgVD7ENs8 6ECr6HTgsnwybFxbaCeSeK4/dE9OuT8JJPoTOtZm+20T2yimbtD+YkkC1lJgED5V6hTD /yIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G3ReoA+Q3hMysE2G/yhL0kVFt1j21GtqD1MjxckBZS4=; b=GrLs1kLTJDvaK5iG2JQcFi/1nL5hOCxqdYarXlDPtGxr4FA0CUX1J07u83odGwN5Sh 6gyXYis5ctL54Zrt6CfV3ZVktvZ0C/vxpY78r9t5L9x7OPE8cl0epiNGLW2AkLVixe9x hNTk3RvRQsPP3PVLx8bANtbKY0r+luK/zdwTzpONa4nLo9S79ZSybLf7gYCXp38XNuiB OV731xB17rgR/cUh4wyqEGDIpO4+ozyR2rs6yzPByh6IfWxNg0xn2KZoEgEccDM3GIVT JD0Hq8sOd4/U+IFwZODenZhj2uBlqa44jz6qTMGcXfJnFQi6R9J3iJEA89kqUchD0Zlj gnZg==
X-Gm-Message-State: AMke39koZTgtyilWMCyVYkvmevu1HwQD6/+wEjQ5S9OV2CH/VvOeqcbJgngi4YJxHWPzl11ozXvpWJ4+u6FZwg==
X-Received: by 10.176.23.89 with SMTP id k25mr7274471uaf.49.1486496299359; Tue, 07 Feb 2017 11:38:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.33.173 with HTTP; Tue, 7 Feb 2017 11:37:48 -0800 (PST)
In-Reply-To: <614ead862aa54a548ed4835a998a42e4@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>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 8 Feb 2017 06:37:48 +1100
Message-ID: <CAO42Z2x4WZ6ObVBkawXEhtO2SqWfoQrOCvNCNXVrkpNKrzj=LQ@mail.gmail.com>
Subject: RE: Route Information Options in Redirect Messages (updated)
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: multipart/alternative; boundary=f40304361e12e2887c0547f5e3da
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XHxg4ZQ5vlWAruTM97Quc0JpxpQ>
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:38:22 -0000

On 8 Feb. 2017 05:43, "Templin, Fred L" <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.