IETF Logo Mail Archive

Re: Extending a /64

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 10 November 2020 02:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 027D83A158A for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 18:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 Eq0koVz-oet8 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 18:01:12 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8C23A1588 for <ipv6@ietf.org>; Mon, 9 Nov 2020 18:01:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 78C6338A52; Mon, 9 Nov 2020 21:01:34 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RwnPRCxHAWVB; Mon, 9 Nov 2020 21:01:34 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D4EA338A51; Mon, 9 Nov 2020 21:01:33 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 09D60558; Mon, 9 Nov 2020 21:01:10 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, ipv6@ietf.org
Subject: Re: Extending a /64
In-Reply-To: <m1kbkaI-0000ImC@stereo.hq.phicoh.net>
References: <m1kbkaI-0000ImC@stereo.hq.phicoh.net>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 09 Nov 2020 21:01:10 -0500
Message-ID: <24577.1604973670@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YwItG_K4MES7Qv6rXDeusHhSTJs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Nov 2020 02:01:14 -0000

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> wrote:
    >> A problem described in variable-slaac is:
    >>
    >> "It should be possible to extend an end-user network that is only
    >> assigned a /64"
    >>
    >> I believe that is a problem worth looking at.  This problem is not
    >> only restricted to the mobile access case, think connecting a host
    >> with VMs to a link.

    > I don't quite understand the problem statement.

    > We can distinguish inter-site prefix delegation from intra-site prefix
    > delegation.

    > For inter-site prefix delegation we have DHCP PD. This is widely
    > supported on landlines but not on mobile. It seems that it is not
    > supported on mobile because they never bothered to implement it.

They didn't implement it because for single smartphone "terminals", there was
no implementations, and IPv6 sharing is too new.  But, a smartphone can
easily take it's /64, and pass out pieces on the "WiFi" via RA using onlink=false.
Plus Proxy-ND.
It's doable, although the mess in the stack that this would cause (see
Lorenzo's NetDev talk...) makes me embarassed.

The place where we get into trouble is that LTE is being used for fixed
wireless, and in that case, it's a real Home Router at the other end, and the
operators have no idea how to do things, because they didn't really think
things through.  {I experienced this at my cousin's farm in Alberta}

    > Of course we can just change every last IPv6 implementation in the
    > world to support what the mobile world broke. But does that really make
    > sense?

No.

While Barbara makes good point in another thread about how we whack on
operators a lot: there are an awful lot of really good clueful ones.
They just don't come to the IETF (or NANOG or RIPE or Apricot), I think.

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


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email