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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 24 November 2020 14:05 UTC

Return-Path: <pthubert@cisco.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 F2CE53A0E3E for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 06:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.72
X-Spam-Level:
X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eeUczqv0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VRorz3yY
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 cTRWEstgiXCn for <ipv6@ietfa.amsl.com>; Tue, 24 Nov 2020 06:05:52 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011343A0E3C for <ipv6@ietf.org>; Tue, 24 Nov 2020 06:05:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2680; q=dns/txt; s=iport; t=1606226752; x=1607436352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wiZov0DbMCXSsgpRpReGKQOled9Be5cNh2RVbj2s+7s=; b=eeUczqv07DOPWrFOtDXRtcp/huxC87qJmScDIqdfPCa6vX2eUOyrK4Es apZjR3RNErdtztJgakmv703afr4JBdJ20dAuF1gsmFpyXVQpEDgVqKPre TdIhRU2cctMIh7uwu/lX1R2BWrmU+z6oXLh/yqF//lgpeyGHiainmLUOi E=;
X-IPAS-Result: A0DeCAABEb1ffYENJK1igQmDIVF7WS8uCod8A41bmQSCUwNUCwEBAQ0BARgLCgIEAQGESgKCLAIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAQMBARAoBgEBLAsBCwQCAQgRBAEBHxAnCx0IAgQBDQUIGoMFglUDLgEOoxkCgTyIaHSBNIMEAQEFhScYghADBoE4gnOCZk6HGRuBQT+BVIIhLj6CXQEBgWGDSIIskEqoAwqCbpQEhz6iBpNdnCuEOAIEAgQFAg4BAQWBayGBWXAVO4JpUBcCDY5WgzqFFIVDAXQ3AgYKAQEDCXyOOQGBEAEB
IronPort-PHdr: 9a23:lImtpRcMWfRNXMUlhMh/zSvflGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwaTB9fW7upAjPvbvrumXnYPst6Ns3EHJZpLURJNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8XC39ToVCxjyLkxyPOumUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwRrSqXwOcONTlm4=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,366,1599523200"; d="scan'208";a="598844034"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Nov 2020 14:05:51 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AOE5oqd029510 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2020 14:05:50 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 08:05:50 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 09:05:49 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 08:05:48 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HH8ao66OJEZaK1HQ3cPrZWQQ2FZWf2l5n6KdG2XuUrBfQwf5bhL2oOzHZjcyOKuTtJvi+Jf3P18eBlEnOpCuTSBlP1eJolJ/MLjKtasMy6GkYWbS/1nIZ6IsMtXMQqBAw3xu29f8SLCZKNnt9tZ6V+tkx4YF3UCp+SvxRcGDwsIPjlf+TUe7fPphQjJFb08ax4NC+yGljY/zLfWF/ADbPtlEQH5fGEomTpf79+Qu3Xo3v5qN7HnpZKzMB8Vkl6muQVBI4fBCmAX6MaM9LXyYPXRp5wzneJ2MiyCl9xEi61yuc11DiLydNs0LVqfaWp1IlWSxktw9cxSpwS1h8kPwdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eLpzaYhnN4E+3PMUCsQPo8XqVuLSCNmi+VjTXU+oHLA=; b=acn6ZhrlP4Si7yiDHlHeTyZ22PmFVg7FeIqF9PUWpM/4V+JJ+1U7ziyisKD+UsvPs1s5ahhuGqumycQD4RIYz++WTigv0jSPJ5DSoIr5Z0nYcBhKEuDmGhH+QTtrrfibLNdjvrGuHupPO2PAKsUpAfrz+jmyz0nneXcJwML8XcyylIGzwVqCDNh3qES4aCf4vokcwip9feMzIWTiB9Qu6r+eTp9jOcpAWcJprBiJk9D2hBXajgyx2aa5Rvk0bWsxvZ5ojP1qKfkWN6C+Fb1g99uwT+wirBRl2ItXLJxeojYeHGY2qeP0royas87YBP2WYlAOUyMTU2qLOuJ19JfkVw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eLpzaYhnN4E+3PMUCsQPo8XqVuLSCNmi+VjTXU+oHLA=; b=VRorz3yYp8TyWD5hpRCzao/L70mXPcpTsF0UVa6aiBxSzMFkzoZucYxW5MTW9IyHRBx0jitwZrivONbEcF+El51wJ6u9JsQqJAwnxMjPo3ppvhqLs7LiszOW9YbEOcw1dKgJmpZN64lSmzqtgvQtZiyoAEe7GclpEJrJ/F745Mw=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1469.namprd11.prod.outlook.com (2603:10b6:301:c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Tue, 24 Nov 2020 14:05:47 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Tue, 24 Nov 2020 14:05:47 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "otroan@employees.org" <otroan@employees.org>, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Topic: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Index: AQHWwWx8hRdZ0+Gjz02hr/+CM8zWL6nWfrEAgABVowCAAGBbAIAABRMDgAABVoCAABUS4A==
Date: Tue, 24 Nov 2020 14:05:26 +0000
Deferred-Delivery: Tue, 24 Nov 2020 14:04:52 +0000
Message-ID: <CO1PR11MB4881B56CFA1E2133D00153AFD8FB0@CO1PR11MB4881.namprd11.prod.outlook.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> <m1khXWs-00007wC@stereo.hq.phicoh.net> <47150D97-27D7-4AFD-8418-692D68D09828@employees.org>
In-Reply-To: <47150D97-27D7-4AFD-8418-692D68D09828@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: employees.org; dkim=none (message not signed) header.d=none;employees.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.44]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d66e31c7-1ba0-4965-0b2b-08d890820aec
x-ms-traffictypediagnostic: MWHPR11MB1469:
x-microsoft-antispam-prvs: <MWHPR11MB14699F685B198CAF022244DAD8FB0@MWHPR11MB1469.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MaSqw6E07zgTIuk4ZAj6WnrMVjQYWvNeZkiwaR/4+gQ0TVunmQbJQShCvorUq8SPlYKVorVX3/eKttva0ishp/8QRpPwwsmaHnA9aFqhcZ+5OBm4aSv9v6m7sK+7VZgLSowMWa/zUkJnJG9QiHUle6mrR+aTdpU6MYNGPjijMzTUEf5vKEjJlGuAWKiT4JFnIFz7vJIg28hARTK/dfyflC2pu7SGq8lrn3gmKleKoFWjo2xY4sM4kjiHk6C/+YpO/t9bewl9v6YcpBeFaS4Jl7vnYBAH+Z0v9e7/9VCcYs/vggOxH6awtnqkZ5+sLMN8lL09BUA12LlZLtcdDhbVg04SHwce4VUYQsvQVGn6TfuOQC0qnUE08mUlOrwavFiOVzXr+baEsRdT8LHEE3ugqw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(39860400002)(366004)(346002)(8676002)(6666004)(6506007)(53546011)(4743002)(66574015)(76116006)(71200400001)(64756008)(478600001)(83380400001)(966005)(66946007)(66556008)(7696005)(52536014)(66446008)(66476007)(55016002)(5660300002)(316002)(86362001)(9686003)(8936002)(4326008)(2906002)(110136005)(33656002)(26005)(186003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: M8pfoLrxKPoIVUyo5sMfXrTqGpm++R/fe1OuTKwFZSGDhED/hGkwp7meF0u7ex+C9k9ITj7xappRagj1INyw0Hm4m1qjAquKHsIUmtTYjBQP3GfAqwEoKfc0X8B9IxlZtgwQOX8k4l6dwGZeEy2OvxNSFrthtdeWOihrRkAKGDF1bFY9XvSAc90sbFa+tz9zaLLWoN7UHYqw3Pyv6tEJ62wVf5waxjSJOmFpAlzCSW5je5ttwIwwyPf5/U7ktPJM8cfSIbuBcLOAHQ+hEQ2Z/uExpjInJp3U/LUFZJgcKD0aWn+MEcXapoxQTdYmNs8Q24IkUqcahFw8eRadmr27KGf/Dsozsnjj3YGihQgEeHXMHIxgmCZ17F60yB4ID/c57ZvljKgNc8+DyUjK+VOyLjN0mloY6W0crFABuicNWGZ2RpqKnO0aUaYmbDdwy9XZp8wrp+HdjlooK+JUIbHlmzn1L8/ifcMOYAVuGm5xVuLstgmJ0Iwu60GXKBTleWNEUlFddJXMNmaW9fvVERSQPQJ0EkiuQSYDbgw6fxvkze+QUThji4DnFpIhZAg7vbk1qGrOVJtikO1dpsQIA3rE+byH664s+B22RJdbSo820mu14bBeDUjVqRndEgPU+ctTQi7vTefDNecEDDmT7TBNC9iLwQ+vSg77bDT+r+LmONG0qh2TRWFCce8pa9z77Kft2BeLGQHU8pFBcWQ2pdpnJMIexevnqs1qoGG7IV7OveXRZwNDQddj5Cs5UHG2gwzb1F1RFKd1aXgMUvgENLiwGDzsoypXErZhIamS1sEsV5ql3bM1/fURmKhkdG2DqqkiGQoEaMKYvCLsmf1kFZr6F6JRT6Yl8twU46IG7Yzj296nmiRrs0RB3LSpWbVHq80vybLdRw0Bzts27QpVFH0MLH0RWdJ+Nvt1BQTWMhvHBC2YMgLxitKK4np1D4fNe/wSCsAetdwjA1gwPynb362BcMdc0sQJBcmn5XhzbPxTaYUmWOLS6/anfUlAOYMquv3b
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d66e31c7-1ba0-4965-0b2b-08d890820aec
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 14:05:47.5777 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VVOUt+xK/cf7qJyT+Lsom6izc0sVpAzhnbv/V05yOf28nhX8cmFC2TO9JiggPPuWNBXyeQzylvS3lL4Avqfg6g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1469
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rDTVK4IKv0zv8Rgib02vwFtPNKw>
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 14:05:54 -0000

Hello Ole, 

I'm a bit dumbfounded that there would be an expectation that there is a GUA/ULA  prefix on each and every link. 

Routers do their onlink exchanges such as IGP games using link locals. Even the access router talks to the onlink nodes (e.g., sends RA) using its link local.

We can assign global addresses to the routers in loopbacks if we care, but where does that idea of assigning a /64 on a link between routers come from?

I've not seen such a thing; it seems to me like an IPv4 expectation, not IPv6. 

Keep safe;

Pascal


> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of otroan@employees.org
> Sent: mardi 24 novembre 2020 13:40
> To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
> Cc: 6man WG <ipv6@ietf.org>
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor
> handset supports PD?
> 
> Philip,
> 
> >> 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.
> 
> That is correct for any implementation I have written.
> 
> > 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.
> >
> 
> And my point was that this is the desired behaviour in this case.
> At least we should explore the consequences of not treating the nodes on each
> end as having a directly connected shared subnet (apart from fe80::/10) and
> what that does for address assignment/pd.
> 
> Best regards,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------