Re: RFC6085 update to rfc2464bis

otroan@employees.org Wed, 11 January 2017 09:48 UTC

Return-Path: <otroan@employees.org>
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 CF232129AE7 for <ipv6@ietfa.amsl.com>; Wed, 11 Jan 2017 01:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.264
X-Spam-Level: **
X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 k60sjyPlTYNk for <ipv6@ietfa.amsl.com>; Wed, 11 Jan 2017 01:48:50 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 97B06129AE9 for <ipv6@ietf.org>; Wed, 11 Jan 2017 01:48:47 -0800 (PST)
Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 11 Jan 2017 09:48:47 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BC4A29CC7E; Wed, 11 Jan 2017 01:48:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=eIvOGulJLhOI/lhJKo5QhKa5QvI=; b=OTzA5ce03D9Kd2Kps/ gYeNkV6aH650JQR5W9VX7hiBrcW89x2TWaymJXTfBh5CAoP29rQxBdmfP19+XECQ 6qIEArDZ6NAhHU8FCVNZ2+9Wxzl21Jr1vK8VoGrDWgknN1c83xUuiJ0XOHuIvn2g s9H6Cn/YfZR5IvJAjnqJd9CvQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=lC3+ZVR9TxiXbDPr6/J811ZACZjiwYEifB8KHeg+hruU7yBc3+J jXWUzAyv5LMgjRVSHWNX+k3IL0RvCW0HizsUrfFomorwGwLWMQJWWIOk4Quovy/g b5QNhNj5BmS6obxjNkPhKoiCnAkKLD1RmFGogGl8xAZwCzyewyZ5mbLk=
Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5BFE59CC7C; Wed, 11 Jan 2017 01:48:46 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A24FA7450CE7; Wed, 11 Jan 2017 10:48:45 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: RFC6085 update to rfc2464bis
From: otroan@employees.org
In-Reply-To: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com>
Date: Wed, 11 Jan 2017 10:48:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org>
References: <C2C9A241-BBE1-4DC1-BA9D-B6D20EF75FD6@gmail.com> <CAJE_bqc4LBxeJFupiG=P0WiXqmM2Y-pyDN9skggGPd9c_N=AbQ@mail.gmail.com> <CAJE_bqeGO-8TJkdCDS-tChGCsLYH8ve=pySXBcSFZG9AFcK6CQ@mail.gmail.com> <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RzdyQ8C_lEr2KZntgmIVTBReV7s>
Cc: 6man WG <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 11 Jan 2017 09:48:52 -0000

Bob, Jinmei,

As one of the authors of RFC6085 let me try to clarify how it would typically be used.
Scenario: Wireless AP that already knows the L2 unicast address of all stations on a link.
Some APs try to improve on IPv6 multicast on wireless by sending the RAs as L2 unicast to each individual station.
The AP then runs through it's list of L2 unicast addresses and sends the multicast RA with the given L2 unicast mapping.

2464bis says:
   An IPv6 multicast packet may also be mapped to a unicast Ethernet
   Link layer address as defined in Section 6.

   An IPv6 node receiving an IPv6 packet with a multicast destination
   address and an Ethernet link-layer unicast address must not drop the
   packet as a result using of this form of address mapping.


As Jinmei also says, referring to section 6 is then wrong. That implies that the 6085 address mapping uses address resolution. Which is not the case.

6085 is indeed very underspecified in stating how the mapping is done, from 6085:
   The determination of the unicast Ethernet link-layer
   address and the construction of the outgoing IPv6 packet are out of
   scope for this document.


Either do (Jinmei): 
   An IPv6 multicast packet may also be mapped to a unicast Ethernet
   Link layer address as described in RFC6085.

Or something like:
  An IPv6 packet with a multicast destination address may also be mapped to an 
  Ethernet link-layer unicast address [RFC6085].
  E.g. when it is clear that only one address is relevant on the link and that the
  mapping between an IPv6 multicast destination address and an Ethernet link-layer
  unicast address is already known.

Cheers,
Ole



> On 11 Jan 2017, at 01:05, Bob Hinden <bob.hinden@gmail.com> wrote:
> 
> Jinmei-san,
> 
>> On Jan 10, 2017, at 11:22 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:
>> 
>> On Tue, Jan 10, 2017 at 9:26 AM <jinmei@wide.ad.jp> wrote:
>> 
>>>>  An IPv6 multicast packet may also be mapped to a unicast Ethernet
>>>>  Link layer address as defined in Section 6.
>>> 
>>> I think it's more helpful to refer to RFC6085 explicitly here.
>>> Otherwise the proposed text looks good to me.
>> 
>> On re-reading it more closely, I wonder whether "as defined in Section
>> 6" may not be very appropriate.  RFC6085 intentionally left the
>> mapping open:
>> 
>>  [...]  The determination of the unicast Ethernet link-layer
>>  address and the construction of the outgoing IPv6 packet are out of
>>  scope for this document.
>> 
>> but I suspect it doesn't really intend to perform link-layer address
>> resolution using ND (which is in my understanding what "Section 6"
>> talks about) to determine the unicast Ethernet address.  In fact, the
>> address resolution itself uses a multicast IPv6 address, which is
>> derived from the target unicast IPv6 address.  So it would be a kind
>> of circular definition.
>> 
>> So it's probably even better to just refer to the RFC instead of
>> Section 6:
>> 
>>   An IPv6 multicast packet may also be mapped to a unicast Ethernet
>>   Link layer address as noted in [RFC6085].
> 
> I think the problem remains that RFC6085 isn’t very clear how to do that.  Pointing to RFC6085 is that it doesn’t say what to do :-(
> 
> It would be good to hear from the authors of RFC6085.  Also, what is current practice.
> 
>> 
>> And, for that matter, this text of Section 6 of rfc2464bis-01 now
>> looks a bit awkward to me:
>> 
>>  The procedure for mapping IPv6 unicast addresses into Ethernet link-
>>  layer addresses is described in [DISC].
> 
> That is original text from RFC2464.  I tried to avoid changing anything that wasn’t part of an update or errata.
> 
>> 
>> On reading both Sections 6 and 7, this "the procedure for mapping"
>> could read some static mapping whereas it should actually refer to
>> dynamic link-layer address resolution.
>> 
>> I suggest revising the first paragraph from:
>> 
>>  The procedure for mapping IPv6 unicast addresses into Ethernet link-
>>  layer addresses is described in [DISC].  The Source/Target Link-layer
>>  Address option has the following form when the link layer is
>>  Ethernet.
>> 
>> to:
>> 
>>  When the link layer is Ethernet, the Ethernet address for an IPv6
>>  unicast address is resolved using the address resolution protocol
>>  as defined in [DISC].  The Source/Target Link-layer Address option
>>  used in that protocol has the following form.
> 
> I find that an improvement (maybe without the “When” text), but I am not sure a change is needed.
> 
> Thanks,
> Bob
> 
> 
>> 
>> --
>> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------