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

"Templin (US), Fred L" <> Mon, 30 November 2020 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 744393A0D48 for <>; Mon, 30 Nov 2020 07:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E6PasqqT7Cuz for <>; Mon, 30 Nov 2020 07:03:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 121C23A0D47 for <>; Mon, 30 Nov 2020 07:03:57 -0800 (PST)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AUF3rgG031538; Mon, 30 Nov 2020 10:03:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1606748636; bh=8kTpSCA5b4saUNK5dAXsIkmVpK5ScBK5yCzw+SGBxJ4=; h=From:To:Subject:Date:References:In-Reply-To:From; b=vfNtysIApC3rH6PunxMbxIT0iksIB8W14Ieit6ZhhuJF5xABV9dTi7QLvgvVbqr4b 0CDIfZU4ymfatf9plAAJcNt/8oZcCpT7VoWkoTHDc1adDYYLrzvk69CKJS4HqH5sHJ B2uZcqb7xHmJVCEm4DagqmbUJHvd72LseR897c3t0G9CtpmoNsGJkT+1MhnFcot0Pa KKZxqn2cRHNfSqUVWdxi19va/XheCbRSO8u4wx8l36MbE3SnP5zrHCzjtZ3s4C+zgK RV1hSEBROCeM425jK4nSJikeCHinJt14TtMx6+XhomamKM+OXbT1ycQb+/p8yImK13 uGjYQVU2Hk4hw==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AUF3kGV031358 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Nov 2020 10:03:46 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 30 Nov 2020 07:03:45 -0800
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 30 Nov 2020 07:03:45 -0800
From: "Templin (US), Fred L" <>
To: Philip Homburg <>, "" <>
Subject: RE: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Topic: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Index: AdbDOEZ74Lub7t3bVESvC0PbrYUO2KnZCyNQ1ihW+SP/+Za5AIAM5/Fc///+2xA=
Date: Mon, 30 Nov 2020 15:03:45 +0000
Message-ID: <>
References: Your message of "Wed, 25 Nov 2020 14:35:53 +0000 ." <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: C0493A9DB9C183DB6905D5D593AAD7AC38BB1404C38FB6E16D65BD5B40BD8C632000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Nov 2020 15:04:00 -0000

Having the Type field would allow an administrator to manually configure an
administratively-assigned LLA without risk of colliding with another LLA that was
configured via one of the multiple and growing numbers of LLA autoconfiguration
methods. This is true today, and will become even more true as more and more
LLA autoconfiguration methods are standardized.


> -----Original Message-----
> From: [] On Behalf Of Philip Homburg
> Sent: Monday, November 30, 2020 6:54 AM
> To:
> Cc: Templin (US), Fred L <>
> Subject: Re: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> > Having a Type field that unambiguously differentiates the multiple
> > LLA config types that could all be used on the same interface avoids
> > collisions.
> You keep talking about collisions and confusion, but there is no evidence
> that collision among pseudo random IIDs actually happen. Furthermore, pseudo
> randoms IID doesn't collide with EUI-64. We have many years of experience with
> this.
> Similarly, where IIDs are used as identifers, and not as a hack to obtain
> a few protocol bits, there is no confusion when it comes to different ways
> of generating IIDs. An address is just something to pass to ND to revolve
> to an L2 address (for multi-access links). There is no need to know how
> remote host generates it's IIDs.