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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 24 November 2020 20:01 UTC

Return-Path: <alexandre.petrescu@gmail.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 56C213A0C9B for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 12:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.648
X-Spam-Level:
X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 iMoZOFbXAfJA for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 12:00:58 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDF63A0B17 for <ipv6@ietf.org>; Tue, 24 Nov 2020 12:00:45 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOK0ifA022764 for <ipv6@ietf.org>; Tue, 24 Nov 2020 21:00:44 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A3F82095FF for <ipv6@ietf.org>; Tue, 24 Nov 2020 21:00:44 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2FD1420958A for <ipv6@ietf.org>; Tue, 24 Nov 2020 21:00:44 +0100 (CET)
Received: from [10.11.244.24] ([10.11.244.24]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOK0hXl030498 for <ipv6@ietf.org>; Tue, 24 Nov 2020 21:00:44 +0100
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
To: ipv6@ietf.org
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> <m1khXWs-00007wC@stereo.hq.phicoh.net>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b27a503a-d5d2-b376-c489-a1d142d13e48@gmail.com>
Date: Tue, 24 Nov 2020 21:00:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <m1khXWs-00007wC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/V3wVh_0Z7Q12geoEglKwAx0Pn28>
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 20:01:07 -0000


Le 24/11/2020 à 13:34, Philip Homburg a écrit :
[...]
> 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.

Indeed NS/NA are also sent on some ptp links.  They are there just to 
respect standard, in some cases.

The use of ND is relevant on ptp links, however.

The distinction is in what is that ND used for.  Is NS/NA used to 
resolve an address that is a nexthop in the rt table, or is it used to 
resolve an address that is just in the dst of the packet.

If the Gateway sends an NS for an address that is in the nexthop field 
in an entry in its rt table, then we are in presence of delegation.

If the Gateway sends an NS for an address that is in the dst field of a 
packet that it needs to forward, then we are in presence of assignment. 
  In this case, the NS/NA is not of any use, because the NA is not used.

Alex

> 
> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>