Re: [homenet] homenet: what now? ... next?

Ted Lemon <mellon@fugue.com> Sun, 03 March 2019 02:08 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 E07DE12941A for <homenet@ietfa.amsl.com>; Sat, 2 Mar 2019 18:08:39 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 AZbyasoE26Bq for <homenet@ietfa.amsl.com>; Sat, 2 Mar 2019 18:08:36 -0800 (PST)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 9B7201288BD for <homenet@ietf.org>; Sat, 2 Mar 2019 18:08:36 -0800 (PST)
Received: by mail-qt1-x833.google.com with SMTP id d18so1694255qtg.12 for <homenet@ietf.org>; Sat, 02 Mar 2019 18:08:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m0Kc9/PE+ysgr/K3FSqm+z2Bcc8xrhQzA8H9LEDUuG8=; b=vp/D40k2U+zzN2kZ5AsvB9TVZ8s3vj0p49AoiRYCB783Y3Wfkn/hRM+747CcJQiT25 WEFeb3bPgLOT8rWMQLhoK9EKrixkKSC2KSMHxecf83NNLWXQvoVPuAlnV/Zu6lIZyiZ0 t83xV7DJkfHSKpWjF3cIryXWlCtl21j8ck3MfGB7LEieykKrUJDfDuoyfMQa4ss5j+s2 SslwQpB91OqdIoP2Hg9L+I4k4a47ApImR2kqsIRXlivtPi8hoJgsft1XriYiii+UZv1J GQxMvBiDOwRchqZ+6PEC77U4YEcu9cCDnUvT+o54ZpedaVUhD0r/rCIhlbZY9+i/qI69 1zyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m0Kc9/PE+ysgr/K3FSqm+z2Bcc8xrhQzA8H9LEDUuG8=; b=nK8r4lTZM4UUl/MonwcjpDPqIRnX3AWbp722g/mJS/uKHdyW9HLq56oCSM+NEH+oAp vcr7r2RG12GAOrNemLg8w03GMiUvk1r9n5Rd+Ww5owYZlVoxdj4giWKbgdkJt/QmxW4r YQSKqIE5rAlsZXCV04z0uJZOX/r2DC+WdotWGNJcgFNRYY2VLBh+5A3hoS1Zag/XXugo WQl+P/AgVPsaw3kECj4RFbhxXm4ZV5H68aygP7m/nTGMz2Mm0NwULmsiruTuth8xwup8 pwmovDPxP9ajGH6NPfUuolUaJUZ60j+0jiRaT4VPJPbjEmzD9gIaiNgTUWGmORSTstkm sO7A==
X-Gm-Message-State: APjAAAVnYjEuIo2OREuMztARUJzablXuuVa35l3ZjKIxwVMikIp0CA2G c0orzeQ4zI/d13R5x2qm+m1nL3za/LCnHA==
X-Google-Smtp-Source: APXvYqw+dStTLdNANczWUeL0GnJttr3Z+wNzVela0RGIYgF5284+VO6SFQOWGYyDee5VGy/PrUeVvg==
X-Received: by 2002:ac8:16d0:: with SMTP id y16mr9392442qtk.345.1551578915433; Sat, 02 Mar 2019 18:08:35 -0800 (PST)
Received: from [10.0.100.12] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id p35sm1514635qte.83.2019.03.02.18.08.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 18:08:34 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <CD0B51EE-DC94-41DA-8DE3-E1382B845BAC@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_31984CB4-C1E9-4606-A44F-89604946A3BB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Sat, 02 Mar 2019 21:08:31 -0500
In-Reply-To: <87bm2s680z.wl-jch@irif.fr>
Cc: "homenet@ietf.org" <homenet@ietf.org>
To: Juliusz Chroboczek <jch@irif.fr>
References: <894b4181-c4ca-5cf1-adba-1c5fcab0d355@cs.tcd.ie> <90A48EC1-C13D-4B9B-9F04-252C0CC87084@fugue.com> <dbe6e19f-84c2-f2eb-b9ab-d085de7c299c@mtcc.com> <2D09D61DDFA73D4C884805CC7865E6114E0C50C4@GAALPA1MSGUSRBF.ITServices.sbc.com> <ed1e6a2c-b830-07fb-df0d-df6dae96cdd9@mtcc.com> <87fts55jdi.wl-jch@irif.fr> <2B9C4EC0-7BE3-40E4-8AB4-C569916A9A6E@fugue.com> <87bm2s680z.wl-jch@irif.fr>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/M5vO0Xy2-aY_z8eHrPoh1FoXhfw>
Subject: Re: [homenet] homenet: what now? ... next?
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: Sun, 03 Mar 2019 02:08:40 -0000

On Mar 2, 2019, at 8:50 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
> That's an property of the hnetd implementation, not a feature of the
> protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

The text:

      An HNCP router MUST create a private IPv4 prefix [RFC1918 <https://tools.ietf.org/html/rfc1918>]
      whenever it wishes to provide IPv4 Internet connectivity to the
      network and no other private IPv4 prefix with Internet
      connectivity currently exists.  It MAY also enable local IPv4
      connectivity by creating a private IPv4 prefix if no IPv4 prefix
      exists but MUST NOT do so otherwise.

So it does allow the implementation to use use RFC1918 addresses internally when there is no upstream address, but it really does seem to be saying that’s not necessary.   Better advice would be that if an IPv4 address is ever obtained externally, that internal RFC1918 addressing should remain available until some substantial amount of time has passed.   Right now this behavior is optional.

>> This is one of the reasons that I would like us to get together and hack on
>> this at the hackathon:
> 
> It should be an easy fix, feel free to go ahead.

The point of soliciting participation at hackathon is for us to gain collective experience on the easy or difficulty of deploying homenet in practice.   It’s all very well and good to have implementations, but if nobody is able to use them, this isn’t really what we want when we talk about having interoperating implementations.   This is particularly true when the goal of a body of work is automatic operation (as in ops), as opposed to mere protocol interoperation.