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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 04 October 2019 08:18 UTC

Return-Path: <mcr@sandelman.ca>
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 29972120815; Fri, 4 Oct 2019 01:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 RoQlUSE_JrYr; Fri, 4 Oct 2019 01:18:16 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192F1120018; Fri, 4 Oct 2019 01:18:16 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [89.248.140.14]) by relay.sandelman.ca (Postfix) with ESMTPS id 6D8511F47B; Fri, 4 Oct 2019 08:18:14 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5AD0B2D7C; Fri, 4 Oct 2019 04:19:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ted Lemon <mellon@fugue.com>
cc: HOMENET <homenet@ietf.org>, 6MAN <6man@ietf.org>
In-reply-to: <56255ECF-9002-4440-BA0D-665EFC4BA9C6@fugue.com>
References: <56255ECF-9002-4440-BA0D-665EFC4BA9C6@fugue.com>
Comments: In-reply-to Ted Lemon <mellon@fugue.com> message dated "Thu, 03 Oct 2019 17:39:15 -0700."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Fri, 04 Oct 2019 10:19:01 +0200
Message-ID: <14354.1570177141@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/DlsTejcAk355l0htBx6YzHlW5-0>
Subject: Re: [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 08:18:18 -0000

Ted Lemon <mellon@fugue.com> wrote:
    > 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.

I see it (7084) in most every router at pubs in Ottawa.  
They are connected by one of the incumbents that also does TV (think sports
channels in bars). There isn't always an IPv6 uplink (30% of them have IPv6),
but there is consistently an IPv6 ULA visible.
Less often in coffee shops (WPA is on chalkboard), where it seems that they
tend to either buy from smaller ISPs (and provide their own crappy router),
or they are a multinational with hostile portals.

    > 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.”

But 7084 has no requirements for DHCPv6-PD server.

    > 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.

That would probably work.

    > 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?

I have never tried it, but I'm keen to.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [