[homenet] Support for RFC 7084 on shipping devices...

Ted Lemon <mellon@fugue.com> Fri, 04 October 2019 00:39 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EE31208A4 for <homenet@ietfa.amsl.com>; Thu, 3 Oct 2019 17:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 3XcJRRJiDuCJ for <homenet@ietfa.amsl.com>; Thu, 3 Oct 2019 17:39:20 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 06792120834 for <homenet@ietf.org>; Thu, 3 Oct 2019 17:39:20 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id a3so2705224pgm.13 for <homenet@ietf.org>; Thu, 03 Oct 2019 17:39:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=B8TCBhRs+zHzhWrVUUGj/Bgi5D3nzNxqFgwpDuEpl1c=; b=DxzRzD3MwDDr7C/Ijz4oUf6JeJ5/h6xneZpN3ez7UzBG+uC00Q4e4zAfE2u17TMZ0D x6LR5PtTR7Mdw2chAMXym+iRue2zqBUoI2w02+NhbGfGogWV3TeJv2pUEtYQUlBPCD08 QS2i988qHg6+VFpL32UVHeYyAyw9nTP/LITu6HNThBHuCPp7RIuosGExrtqdPDy9TlOt 5O3vM2xnzFSIQ/5482J48oY55UKuTmvxvHWawuF7/Nl+PhvVTubp1UKJ0UgqtSmks7JJ ALRA63sO/tFb3HXh4SzmayiNCoNQ+bTnUkD3kVFfjKKmoXHe4XsjvGl4nLdyb9FIT1im 37bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=B8TCBhRs+zHzhWrVUUGj/Bgi5D3nzNxqFgwpDuEpl1c=; b=hEa4VOmVpqT5zjnE8bWykx3bskmtnfng6qK4dQeHWmvKRI7mDMtTHYvM2w6r4Z08V1 xe0JG2Y2ru39Q0PTog4sPjQvMnd2of/EDBrAzIaFEsF4F11YRuXZfliH4W7v7C6hQfXu V7iqZyPNglF1uSrvdnyyPhC/43zeGJ6GeTF8xXooI/T0PhZYU1nuEKYBz82sA1F0zMrt Y8uhmvGWFAhjt1gK9Uy4+nMCPNTV/3jz1XHPLSgzgbN7kfJkWFU9CZr4VsxQpqolQqdm VGd/Z7pr+CaPZ9U8y4Vny5t6BBLoo/qvwiTGnu7VGOLz4+zMd4Yj4jXzTe3zl2vGCeC0 SGlw==
X-Gm-Message-State: APjAAAV8WXsMf5ByAcqmd8bIc8GVvVyMKAqKzCP/9MF+tYUvVfucXAMN SN2wjoSJ4Gb8buMUcjGsM63decz8dWE=
X-Google-Smtp-Source: APXvYqwZOimMpPkM+LSm17h77RRPeLz/g3ew45WNqTTdIWvSWZi1bPopF0fPM0fbWGMEAqRQjeHxGw==
X-Received: by 2002:a65:4506:: with SMTP id n6mr12391286pgq.240.1570149558278; Thu, 03 Oct 2019 17:39:18 -0700 (PDT)
Received: from [17.192.138.229] ([17.192.138.229]) by smtp.gmail.com with ESMTPSA id r2sm4591020pfq.60.2019.10.03.17.39.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 17:39:17 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3599.1\))
Date: Thu, 03 Oct 2019 17:39:15 -0700
Message-Id: <56255ECF-9002-4440-BA0D-665EFC4BA9C6@fugue.com>
To: HOMENET <homenet@ietf.org>, 6MAN <6man@ietf.org>
X-Mailer: Apple Mail (2.3599.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/MR8uNNyVTUzrgI8kKPRAI9oCGW0>
Subject: [homenet] Support for RFC 7084 on shipping devices...
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2019 00:39:22 -0000

(If you got this as a Bcc, it’s because I am hoping you can contribute to the discussion, but might not be on the mailing list to which I sent the question, so please answer on-list if you are willing.)

I’ve been involved in some discussions recently where the question has come up: how good is support for RFC7084 in shipping routers?   And what gaps exist in RFC7084 that could cause problems?   And in cases where RFC7084 support either isn’t present, or isn’t useful because no IPv6 or because ISP is delegating a /64, what things might work and what things might not, if we want bidirectional reachability between two separate network links in the home.

So for example, suppose we have "CE Router," which supports RFC7084, including prefix delegation.  And we have "Internal Router" on that network requests a delegation, and gets a prefix from the CE router.  Presumably that prefix is out of a larger prefix that CE Router got from the ISP.  Great so far.  Let’s call the network on the southbound interface of Internal Router “South Network”. Let’s call the network on its northbound interface, which is also the network on CE router’s southbound interface, “North Network.”

viz:

                                                ISP
                                                 |
                                             CE Router
                                                 |
North Network    |-------------------------------+--------------+-----------------|
                                                 |              |
                                           Internal Router      +---- Node A
                                                 |
South Network    |-----------+-------------------+--------------------------------|
                             |
                   Node B ---+


If I want hosts on South Network to communicate with hosts on North Network, what do I have to do?   Should Internal Router publish an RA on its northbound interface?   What is the likelihood of that being filtered by the network?   If packets for South Network are forwarded through CE Router, will it forward them on to Internal Router, forward them north, or drop them?

Similarly, suppose we have a network where unfortunately PD Isn’t available internally, but IPv6 is present on the northbound interface of the internal node and southbound interface of the CE router.   Suppose further that Internal Router allocates itself a ULA prefix and advertises that as reachable and on-link on its southbound interface, and as reachable but not on-link on its northbound interface.   Will that be blocked at layer 2 by CE Router?   I’m sort of assuming here that the CE router is managing the North Network link, which is probably WiFi.

Okay, now what if there’s no IPv6 support on CE Router or being provided by CE router on North Network.   Suppose Internal Router allocates a ULA and allocates two /64s out of the ULA, one of which is advertised as reachable on its northbound interface and on-link on its southbound interface, and a second of which is advertised as on-link on its northbound interface and reachable on its southbound interface.

Fourth possibility: Node A is manually configured with an IPv6 address on a prefix that Internal router is advertising as reachable on its southbound interface, but which is not advertised on South Network because of filtering.  Node B has an address on a prefix that Internal Router is advertising as on-link on its southbound interface.   Node A has a static route configured through Internal Router to the second prefix.   Is there any reason to think that traffic between Node A and Node B will be filtered at layer 2 by CE Router, assuming that traffic on North Network is all going through CE Router?

The goal here is to have bidirectional reachability between the two nodes on IPv6 using either a global prefix or a ULA.  The concern is that something could prevent each of these cases from working.   What I’m really curious about is whether people have experience with doing communications of this type using actual routers that ISPs are shipping.   Is this “internal network” scenario part of acceptance testing for these routers?  Is this all a big question mark?   In principle this should all work, unless RA guard is hyperactive in CE Router.   But what about in practice?