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

Mark Smith <> Thu, 26 November 2020 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41EB63A0954 for <>; Thu, 26 Nov 2020 11:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.596
X-Spam-Status: No, score=-1.596 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3H9i1T7T5yV3 for <>; Thu, 26 Nov 2020 11:54:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DB293A0937 for <>; Thu, 26 Nov 2020 11:54:32 -0800 (PST)
Received: by with SMTP id t142so624218oot.7 for <>; Thu, 26 Nov 2020 11:54:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KY35myEDR+ItZASstl+97ngBlcVZ/uaKyQg7HsCdGyc=; b=vHqWOkzmodktic0hUs0D8/wF3bjD2gyD7mNpRrbcJHNvufWbYnkppsQhPzUAkVnlP1 RGGelt4dRU8zqzgPM0RjO5ZbOAr6dkOcsoNAoxNe6l6tEcXml4Hrh/EgEVqq+77SxqJZ M93RPamA8HpsLgW6utccKo8k5V5PzqKy6cYI0S8iNfHsdF21T9dya5oRazft+LI+BnUQ FMsBthXT49bqCEiNsQkGmy8SH0Y7DYeY9msE/1gmcK1BOr9m3pjnkT64oVtKQV1PSMqR eUubGlzJejOrEHRjISu/FtK+7EHba+FyJUU9gLlwd+CI7kz7DcFALWFFp4N5bQgeKurH jo7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KY35myEDR+ItZASstl+97ngBlcVZ/uaKyQg7HsCdGyc=; b=hZkBZsTGFLNNPwKHIzQ/tkik61Rnrl5WlyOaZrp5Sq3eyrtwOfbDG5vU0QTPFD6fHI a/AhqXthiawU8flSL+6CJHJDaw0Fy5f0VSgyXauvSTY59zYiTrYN+xEQ1dVbjFXmvgWp 4ycYZM1YBd3lOSn6YcefE5tuQvvRzPdQIDCzrHjxedIJY5VzUAO/o0UWXMNsf/W9WwhG QlQE29IAAxc1SGox0lpnpE+9ekoUYFWbTmz7zskk6czG6zjmg2TX0cavm15eANVBM8zy yjiwaS9f/4fPQ2kzrwnTTs5oru7KSg8PIjxy2mI9KeSTe9a6dfP4Xlkf4q6fk+DgtmrJ g/sw==
X-Gm-Message-State: AOAM530eL0I5P2eIiMd8HCUJX4OLA4M9jh2EAc4c75gMkULFti2jPP2H s2uU1862qx9UhdbVoh0c9fNNDeNpXMK4XwbdSIaiLDkdKX8=
X-Google-Smtp-Source: ABdhPJwFQZRimO72MNtyZhfDEKWF/FipDtemgtY3LEoGYAWYCRZlKL9DP+WdNQYSzj+ye4Czzh6ImHLEq/tZ/rHQBaA=
X-Received: by 2002:a4a:cf08:: with SMTP id l8mr3038265oos.29.1606420472249; Thu, 26 Nov 2020 11:54:32 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <27311.1606325147@localhost> <> <6063.1606343239@localhost>
In-Reply-To: <6063.1606343239@localhost>
From: Mark Smith <>
Date: Fri, 27 Nov 2020 06:54:06 +1100
Message-ID: <>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
To: Michael Richardson <>
Cc: 6man WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Thu, 26 Nov 2020 19:54:34 -0000

On Thu, 26 Nov 2020 at 09:27, Michael Richardson <> wrote:
> Mark Smith <> wrote:
>     > This would have been making a specific layer 2 involved in layer 3,
>     > coupling layer 3 advancement to that layer 2.
> So why does it matter at all?
> The point is to make things work better for the set of layer-2 that use PPP.
> That set is rather large.
>     > IPv6 has moved away from layer 2 extensions or protocols to operate or
>     > configure layer 3, and the advantage is that options can be added to a
>     > protocol that operates at the IPv6 layer, and it automatically works over
>     > all current and future link layers.
> That's an interesting statement, which I don't think is at all relevent.
> On what authority to make this statement?

Christian Huitema's IPv6 book. You can also see that theme in the ND RFC:

"Placing address resolution at the ICMP layer makes the protocol
      more media-independent than ARP and makes it possible to use
      generic IP-layer authentication and security mechanisms as

The NBMA RFC (RFC2491) also is generalising multicast emulation over
NBMA networks so that standard IPv6 unicast and multicast protocols
like ND can be used over NBMA.

> The document explains that this is about announcing capabilities so that the
> Layer-3 configuration mechanism can be tuned better.
> We could do this in layer-3, but we usually need to decide, (in a BMS),
> BEFORE starting the RA daemon, if we should be allocating a /64 to the link or not.

That sounds to me like that could be solved with PPP's existing PAP or
CHAP authentication mechanisms to identify the device, to then decide
things like whether a /64 should be allocated.

If you don't want or need to actually authenticate the device via a
shared secret password, you just blindly accept whatever the supplied
password is. You'd be using the PPP authentication protocol really as
just a device identification protocol, and then use RADIUS to supply
whatever attributes to the BMS you want for that identified device.


> --
> Michael Richardson <>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide