Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux

Alexandre Petrescu <> Thu, 02 March 2017 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CEB4129534 for <>; Thu, 2 Mar 2017 05:29:55 -0800 (PST)
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 kEq139QU6gsn for <>; Thu, 2 Mar 2017 05:29:53 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8FD7B129464 for <>; Thu, 2 Mar 2017 05:29:53 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22DTncr023248; Thu, 2 Mar 2017 14:29:49 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id A91AC208223; Thu, 2 Mar 2017 14:29:49 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 9B7332041FD; Thu, 2 Mar 2017 14:29:49 +0100 (CET)
Received: from [] ( []) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22DTnCe029905; Thu, 2 Mar 2017 14:29:49 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux
To: Mikael Abrahamsson <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 2 Mar 2017 14:29:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Mar 2017 13:29:55 -0000

Le 02/03/2017 à 13:46, Mikael Abrahamsson a écrit :
> On Thu, 2 Mar 2017, Alexandre Petrescu wrote:
>> Yes.  For more precision - correct _only_ for the 802.3 case (IPv6
>>  over Ethernet).  Because we dont have an IPv6-over-WiFi either
>> (802.11).
> We have IPv6 for 802.1 framed networks (that was my understanding).
> Both 802.3 and 802.11 uses ethernet frames,

Well, yes in principle.  But I would doubt your saying 'both'.

Because if one looks at an IPv6 packet captured in monitor mode on WiFi
one does not see any Ethernet header.  Or maybe you mean something else
by an Ethernet frame(?).  Or maybe you meant that local processing
converts between these Ethernet headers and 802.11 headers(?).

On the air the IPv6 packets have 802.11 headers (not EthernetII headers)
_and_ 802.11 trailers.  One can see them with wireshark in monitor mode.
  These headers and trailers have many fields relevant for some IPv6
fields in IPv6 headers (e.g. traffic class, and others).  Yet we have no
spec about how would one map some these from 802.11 to IP.

We do have a spec about how to map an IP mcast address to a MAC mcast
address, what ethertype to use in EthernetII header (which is _not_ the
802.11 Headers), and that's about it.

We also have software everywhere that converts between 802.11 headers
and 802.3 EthernetII headers.  That software is not documented either.

> so why wouldn't they be considered the same from L3 IPv6 point of
> view?

Because that is the easy choice.  And because if we do so, then we lose
many of features these miriad of link layers have to offer.

This is one reason why many IPv6-over-foo IoT-specific links get
written: to take advantage of the link layer features at IP layer.

I would agree that all these links _could_ be the same from the IPv6
stack standpoint, but there are many IoT adaptation layers out there
which make it that the Ethernet view you mention above is not used at
least in some places.

> That's the way it's been done historically anyway, as far as I can
> see.

I agree with you.

But, there are some IETF documents that consider some aspects which
could be qualified as the domain of IPv6-over-802.11, and without
considering a IPv6-over-Ethernet.  E.g. draft-ietf-tsvwg-ieee-802-11-01
"Guidelines for DiffServ to IEEE 802.11 Mapping".

_If_ we had an IPv6-over-WiFi document (not just IPv6-over-Ethernet)
then we could have proposed these DiffServ mapping proposals to go along
with unicast mapping, and mcast mapping proposals of the typical