Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Tue, 24 November 2020 12:34 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 AC1833A0A1D for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 04:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.018
X-Spam-Level:
X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 t-2DTVq5yJf3 for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 04:34:53 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B083A0A10 for <ipv6@ietf.org>; Tue, 24 Nov 2020 04:34:52 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1khXWs-00007wC; Tue, 24 Nov 2020 13:34:42 +0100
Message-Id: <m1khXWs-00007wC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CABNhwV2-dH81CY4wSisV8BU-7H9m5a1xYMqTMecRxhNqZe=ApQ@mail.gmail.com> <CAKD1Yr1xV179LZ7Kxtk5mGruJcJ+BpGb2heBBy4ORtRU7bfvqw@mail.gmail.com> <CAMGpriWqnmL0qo0Hm=b+GbzcdCuXz6PM5aq8owE7-=ty5pDFsw@mail.gmail.com> <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org>
In-reply-to: Your message of "Tue, 24 Nov 2020 13:17:24 +0100 ." <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org>
Date: Tue, 24 Nov 2020 13:34:41 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8IVlYSqVZjSbY-SjCTj-BHx_jPk>
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, 24 Nov 2020 12:34:55 -0000

In your letter dated Tue, 24 Nov 2020 13:17:24 +0100 you wrote:
>In the P2P Ethernet/3GPP case it says:
> This prefix is not used on the link between us.
> The prefix is dedicated to you, and I promise to install a route like:
>  ipv6 route <prefix> p2p-interface | interface, NH pointing at you.
> You can if you like configure an address on the interface on the upstream lin
>k,
> as the router will forward traffic to anything in that prefix blindly.
> (you aren't strictly doing SLAAC at that point though.)

In my experience, many true point-to-point links (such as ppp, but also
tunnels) are like this.

The reason is that in theory you should do neighbor discovery even if a link
has no L2 addresses. I found that many implementations just don't react
to an NS or send any themselves.

So all traffic is just sent to the other side of the link. I.e., the route
could actually point to the link, but you can't really tell the difference.

In theory you could try to see if the router has an address on the link, but
I never tried that experiment.