Re: [dhcwg] MTU option for DHCPv6?

Alexandre Petrescu <> Fri, 29 July 2016 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03D5112D17A for <>; Fri, 29 Jul 2016 08:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vh55LZjvnDVX for <>; Fri, 29 Jul 2016 08:14:19 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E84312D0AD for <>; Fri, 29 Jul 2016 08:14:19 -0700 (PDT)
Received: from ( []) by (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6TFEGrW000695; Fri, 29 Jul 2016 17:14:16 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 9C58420C7FC; Fri, 29 Jul 2016 17:14:16 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 8EDAD20C7A1; Fri, 29 Jul 2016 17:14:16 +0200 (CEST)
Received: from [] ( []) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6TFEGdS012499; Fri, 29 Jul 2016 17:14:16 +0200
To: Lorenzo Colitti <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Fri, 29 Jul 2016 17:14:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>
Subject: Re: [dhcwg] MTU option for DHCPv6?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2016 15:14:21 -0000

Le 29/07/2016 à 16:20, Lorenzo Colitti a écrit :
> On Fri, Jul 29, 2016 at 2:27 AM, Alexandre Petrescu
> < <>>
> wrote:
> Alexandre, that doesn't make sense. The only specified mechanism for
>  IPv6 on 3GPP links is RAs.
> I would doubt so.  I think DHCPv6 is there in the 3GPP specs too.
> DHCPv6 PD (only) was added in release 10. SLAAC has been there for at
> least a decade, I think.
> There is no Ethernet on cellular links, where did you get that from?
>> From packet dumps, looking at the headers.
> Just because the driver of a device you own pretends that the 3GPP
> link is an Ethernet link doesn't mean that there's Ethernet on the
> air.

I agree, there may be no Ethernet headers in the air of cellular links.

But there is an additional indicator.  Companies like Huawei and Sierra
have requested and paid for IEEE OUI numbers that they use to form MAC
addresses on cellular links (Huawei E392 4G LTE dongle, Sierra Wireless
Airprime module).  These IEEE OUI numbers and MAC addresses are
obviously not part of 3GPP specs either, yet they are there printed
on the boards, in the driver, etc.  I suspect these MAC addresses do get
sent over the air on cellular links.

Add to this that in some cases this is on USB too.

This is completely unspecified behaviour (no IPv6-over-USB, no 3GPP
specs mention IEEE addressing, etc).

> Look at an Android phone and you'll see something completely
> different - no Ethernet address and a different ARPHRD_xxx value.

Somehow I dont understand ARPHRD_xxx value.

I wonder what chipset the Android phone in question uses to communicate
on cellular?

I am asking because I just got hold of a brand new Huwaei Mate 8 phone
running Androing, and I still have to figure whether this uses these
Huawei IEEE OUI MAC addresses on cellular links (like the Huawei dongle

> It is a bug when the Host configures so many IPv6 addresses on its
> interface.  It's looking like getting out of hand.
> RFC 7934 claims the opposite.

This is an excellent RFC that makes it an excellent case to deliver many
addresses to Host, instead of just one.

But there are a couple of ways to satisfy that requirement (give more
addresses to a Host) and one of the ways is pretty bad.  RA a /64 to a
Host is not the right way to deliver many addresses to a Host.

Unless you agree that a Prefix Delegation during RA operation may be a
good idea?