From nobody Tue Feb 7 16:04:35 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB64129677; Tue, 7 Feb 2017 16:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OS8dQ7LNILvF; Tue, 7 Feb 2017 16:04:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C60128B37; Tue, 7 Feb 2017 16:04:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 36733B81A9D; Tue, 7 Feb 2017 16:04:33 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170208000433.36733B81A9D@rfc-editor.org> Date: Tue, 7 Feb 2017 16:04:33 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, 6lo@ietf.org, rfc-editor@rfc-editor.org Subject: [6lo] RFC 8066 on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 00:04:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8066 Title: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines Author: S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt Status: Standards Track Stream: IETF Date: February 2017 Mailbox: samitac.ietf@gmail.com, Gabriel.Montenegro@microsoft.com, rdroms.ietf@gmail.com, jhw@google.com Pages: 9 Characters: 17494 Updates: RFC 4944, RFC 6282 I-D Tag: draft-ietf-6lo-dispatch-iana-registry-07.txt URL: https://www.rfc-editor.org/info/rfc8066 DOI: 10.17487/RFC8066 RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document. This document is a product of the IPv6 over Networks of Resource-constrained Nodes Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Feb 8 11:33:12 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8609A129FC6; Wed, 8 Feb 2017 11:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mGvvLvU9_R87; Wed, 8 Feb 2017 11:32:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BD8129418; Wed, 8 Feb 2017 11:32:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7CE3D203AE; Wed, 8 Feb 2017 14:53:57 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7EDE7636BB; Wed, 8 Feb 2017 14:32:51 -0500 (EST) From: Michael Richardson to: 6tisch@ietf.org In-Reply-To: <855.1482509287@obiwan.sandelman.ca> References: <14596.1479347046@dooku.sandelman.ca> <360614422818437292b671f00cb498d3@XCH-RCD-001.cisco.com> <855.1482509287@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6tisch-security@ietf.org, 6lo@ietf.org Subject: [6lo] 6lo-ra-in-ie becoming X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch@ietf.org List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:32:54 -0000 --=-=-= Content-Type: text/plain {6lo is CC'ed to close this question up, but Reply-To: set to 6tisch, as there isn't anything that is not 6tisch specific left at this point} I have just posted: draft-richardson-6tisch-join-enhanced-beacon https://datatracker.ietf.org/doc/draft-richardson-6tisch-join-enhanced-beacon/ The diff isn't very interesting, as it's mostly a forklift upgrade. This is the result of ongoing discussion to make the zero-touch and one-touch join processes work together, and to achieve a level of interoperation such that a zero-touch capable device, which has received a one-touch, could actually recognize that it needs to do zero-touch. Further, we are trying to accomodate both one-touch and zero-touch bootstrap using both pledge initiated communications (the one-touch preference), and Join Registrar/Coordinator initiated communications. The network shall know which way it will operate, and the network will announce this in the proposed enhanced beacon. (ENHANCED. I hope I stamped out all the occurances of that other E-word, which I will not write here) This text could go into 6tisch-minimal-security, or it could be a seperate document. It would have been nice to put it into 6tisch-minimal; but I sure hope that ship has sailed. Maybe it should Update that? The R flag is for host-operation of nodes which would otherwise want to listen for a multicast Router-Advertisement, or initiate one with a multicast RS. It is hard for me to construct a scenario where the R bit would be zero, and yet the device is alive enough that it thinks it ought to send beacons. It could be that some networks do not wish to support attachment of leaf nodes to all routers though. {previous paragraph probably belongs in document?} The core is: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD-XXX |J|I|R| R E S V | network ID | +-+-+-+-+-+-+-+-+-+-+-+---------+ | | network ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | network ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ J : the Join Proxy flag is set if the sending node will operate as a Join Proxy according to {{I-D.ietf-6tisch-minimal-security}}. I : the Initiate Join flag is set if this network supports pledges initiating the join process themselves according to {{I-D.ietf-6tisch-minimal-security}}. If not set, then the pledge should do an NS DAD operation ({{RFC6775}} section 4.3, explained in {{I-D.ietf-6tisch-dtsecurity-secure-join}}) and then remain silent, to wait to be contacted. R : the Router Advertisement flag is set if the sending node will act as a Router for host-only nodes that need addressing via unicast Router Solicitation messages. network ID : this is an opaque 16-byte identifier that uniquely identifies this network, potentially among many networks that are operating in the same frequencies in overlapping physical space. In a 6tisch network, where RPL is used as the mesh routing protocol, the network ID SHOULD be constructed from a SHA256 hash of the DODAGID of the network. The result will be a 32-byte hash, and the lower 16-bytes should be used. {oh. I show only 8 bytes of network-ID in the picture. Oops. I will grow the diagram} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlibcmMACgkQgItw+93Q 3WWh6QgAoMRsUjWGNa1I9vl3PgpIufhSdBUO9sHqwUyj/DSmQuUi4kR2V0X+F/91 35efGp3A3aO9Xyqaz5vkOKCFSzAuPZSBeMINc+ZGE37g+N2CDJ2E9u6MU/srN5ox DfTt01lIXjcsxwyPAx7+/gMF2KUdPHGYetyBB4b+vbpcsQwEsaIVuR9YopflKwU1 GtpRbMv0/wOi/7soWWJRhiJwHFTL3RDL9iP45fiz3Rwf8AnJdzomWrTSFtlTRdCE y2SzK4t7yIz6nDqJTxfYj0uReVhcyng+2BAVDgdO/qGfnqE5UEWcuZNRIxRfOoNl GZomFidx1e5tI/okWrVbMFSDGDjECw== =CkxW -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 8 12:56:58 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD611295C6 for <6lo@ietfa.amsl.com>; Wed, 8 Feb 2017 12:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GJcBuB9tqO4M for <6lo@ietfa.amsl.com>; Wed, 8 Feb 2017 12:56:56 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C271295C4 for <6lo@ietf.org>; Wed, 8 Feb 2017 12:56:56 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id y9so119553312uae.2 for <6lo@ietf.org>; Wed, 08 Feb 2017 12:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=c+SqEzOF/QUGBAzKaH9hlD0Qqth6AWs9leakhAM7/IQ=; b=mVsEKnw2eu0hyHrMv00RZvclZBoFkpkEj2oNF5pEjbbsjxKwIFnhd9PyXMc5yqzXAF 1vbGSghCJrAaMH7Vwd374s47HCvAUoxbReAzvcZ9S9Xbs4mN/hNe1xFinuuWBOxYNV00 BdJYTgj+7yxdfUJ13w5QkNPCF86kiV8uNaH7q2XZZytNtvXYufeQTUKj9nV+qbkz4nDc tuV7FTGrbLwP7BAdX7o3fVHMeh7KuElK1wAzMNk+Pkq3EX7BJZbSDtwkNy/BkSQzChxp 7xv40KPQmrlOGX9zx0MlKZvBihEFROCLk+dW8yvpvoSF6OpyT7VIVkdE3z6uhGlGBn45 auYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c+SqEzOF/QUGBAzKaH9hlD0Qqth6AWs9leakhAM7/IQ=; b=X9dstnw4nh4ULxmnsgDHz5c4VFCeoS+PrlO5llzM7jjKak2/LVB/xymGuTwu4ozKBQ KQfngyywjGJl0k3KPjbXdn1p7QvFRhWwe3RIduikg5EHChPlOQs7tiF2yoitYv2bJ9eK 2bvicEOeSpCMIIxbNACEJsFWEPF7xf3ayKefBW6CcVpmQLTYpr0KZtSZ/AEtFX8uHo8j RM8q/sLHnidD/JTrUAIqI4ZESI87voa9BV/O+xFaLb+kpOHus8/rco1wVuEgGyYBXWED CoW059byupAXeP2WGMyoYBS+6q4JVzomwWVarw6m0R7rtxj7wNSc0YZn501/E6ws3uBz /IKg== X-Gm-Message-State: AIkVDXLrd84FY0FdJsKBfAlzmKAA3h5osaXFlLfFN9yxVdqbxYgBVOrh/aOfpIcXUhXs7n7msMo/YITSgG9IaA== X-Received: by 10.159.35.15 with SMTP id 15mr11802408uae.47.1486587415137; Wed, 08 Feb 2017 12:56:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.152.80 with HTTP; Wed, 8 Feb 2017 12:56:54 -0800 (PST) From: Samita Chakrabarti Date: Wed, 8 Feb 2017 12:56:54 -0800 Message-ID: To: lo <6lo@ietf.org>, "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a113d0e18ceb36505480b1aa5 Archived-At: Subject: [6lo] Understanding RFC8025 implementation and page switcihing X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 20:56:57 -0000 --001a113d0e18ceb36505480b1aa5 Content-Type: text/plain; charset=UTF-8 Hello : I am trying to decipher the RFC 8025 packet header sequence and bit patterns from reading the document and http://www.iana.org/assignments/_6lowpan-parameters/. Sorry, I should have asked these questions before, but it is never too late... * I assume the main purpose is to give the implementor tools to go and parse/interprete additional data carried by original RFC 4944 style packet or not. * The document says that the page-switch dispatch type should be always preceded by mesh and fragment header. I would assume that original pg 0 or LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if the following sequences are valid ? 1) [Mesh][page-switch-to-X][New-dispatch-type from page X][Payload] 2) [ESC][ESC-Bytes][LOWPAN_IPHC][page-switch-to-X][Page-X-dispatch][Payload] 3) [LOWPAN-IPHC][Payload][page-switch-toX][Page-X-dispatch][additional-payload] If both 2 and 3 are valid sequences, can you please provide two examples of use-cases ? I was not sure if we can allow payload with each page and parse multiple payloads with the same packet [ assuming we have large enough frame size]. Thanks, -Samita --001a113d0e18ceb36505480b1aa5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello :

I am trying to decipher the RFC= 8025 =C2=A0packet header sequence and bit patterns from reading the docume= nt and=C2=A0http://www.iana.org/assignments/_6lowpan-parameters/.

<= /div>
Sorry, I should have asked these questions before, but it is neve= r too late...

* I assume the main purpose is to gi= ve the implementor tools to go and parse/interprete additional data carried= by original RFC 4944 style packet or not.

* The d= ocument says that the page-switch dispatch type should be always preceded b= y mesh and fragment header. I would assume that original pg 0 or LOWPAN-IPH= C dispatch type can precede as well. Can some one confirm if the following = sequences are valid ?

1) [Mesh][page-switch-to-X][= New-dispatch-type from page X][Payload]
2) [ESC][ESC-Bytes][LOWPA= N_IPHC][page-switch-to-X][Page-X-dispatch][Payload]
3) [LOWPAN-IP= HC][Payload][page-switch-toX][Page-X-dispatch][additional-payload]


If both 2 and 3 are valid sequences, can yo= u please provide two examples of use-cases ?

I was= not sure if we can allow payload with each page and parse multiple payload= s with the same packet [ assuming we have large enough frame size].

Thanks,
-Samita

--001a113d0e18ceb36505480b1aa5-- From nobody Wed Feb 22 12:22:01 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E869129AFA for <6lo@ietfa.amsl.com>; Wed, 22 Feb 2017 12:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xd3ZPd1B-pWL for <6lo@ietfa.amsl.com>; Wed, 22 Feb 2017 12:21:58 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F55129AEE for <6lo@ietf.org>; Wed, 22 Feb 2017 12:21:58 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id r136so8652356vke.1 for <6lo@ietf.org>; Wed, 22 Feb 2017 12:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dJFyrMQC95GyIUoqmhceqoqpWbpDJ+JY5iN5tn7XaP8=; b=mCAPRIoVjgqURYXTCw/mvvNJSuv5J87a/kwkT2m4hoXFSgzYnIbRHjJeRl0RyHVjNH qpeHQWSwEISjt0PCd2UE9B6ZVUcqoAYkxsdpIXFTjAlhMNrnzOa8ojthsyD07I7BVo8A +IymLJsOsEtn/YoXbzc8nPOejroPWmrP2ozgfYS2KmmIGtAGA121+cRdP7XPchScrfhY pF6ce8qePrsMxC1ak4hl4zcU46rPx/UJ3WO9W2RGJmmM6Dzu5DQ29wPdhpOQyVz3qzzu l4KdT56fKufOG43y1RpnEGSjHtRsRO1zzwkLKHZ+5YmS+MaayfKxMfBk6X8tL2SXr6CK pKpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dJFyrMQC95GyIUoqmhceqoqpWbpDJ+JY5iN5tn7XaP8=; b=BeVasvy2YPdW7BRTJZAvdQaircgddbwhBwczGF3Rg90IcTYRrX5KzqIUNIxVdBGs5M pAhr0LTXbskToCHVqRd+gRwhlmmXwWP9n3Ft5Ho7wVBxtZncSRhe7nlD1lOdzNpCX1mM X5/E1tic/Qvc1wxNTn11b1c+2Gee/GXbfoZgODwVhNGbB7QnG2f10okfYnfN81LEFHq2 yfkciJV+pfffMqemCb33NBKHc7FrBC7WVjcvk6eHpOh4w9TWaOOEFNiVyzEjtZrs+cW8 Uv3Wr8w4Ek39oWBusWfuN+yoguAKECBg7mi9cbdEmr5CSPXAyS+NZWOgxtdQFVDUlNJP 4lkg== X-Gm-Message-State: AMke39n/Inhv7VIbdPUezuTdlKFuaA9vJu9JCHPH8WxfGV/EPd8HOmyHjk040DYMgPaQFRsd4D/gd9rw+AUTFg== X-Received: by 10.31.110.134 with SMTP id j128mr17498113vkc.142.1487794917073; Wed, 22 Feb 2017 12:21:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.152.80 with HTTP; Wed, 22 Feb 2017 12:21:56 -0800 (PST) From: Samita Chakrabarti Date: Wed, 22 Feb 2017 12:21:56 -0800 Message-ID: To: lo <6lo@ietf.org> Content-Type: multipart/alternative; boundary=94eb2c14a138880ca90549243f73 Archived-At: Subject: [6lo] Call for 6lo presentations at Chicago March IETF X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:21:59 -0000 --94eb2c14a138880ca90549243f73 Content-Type: text/plain; charset=UTF-8 Hello 6lo Colleagues: Gabriel and I are starting to plan for the upcoming 6lo session at IETF98. We have requested 2.5 hours slot this time. Please send us your request to 6lo-chairs@ietf.org on presentations of drafts with the following information: Draft name : Brief description: Presenter: Objective : -- We have successfully completed many drafts to RFC that were on the queue. New proposals are welcome. The requests are due on or before March 13th, 2017. Remember that the draft submission cut-off date is March 13th as well. Thanks, -Samita --94eb2c14a138880ca90549243f73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello 6lo Colleagues:

Gabriel and I are= starting to plan for the upcoming 6lo session at IETF98.

We have requested 2.5 hours slot this time.

Please send us your request to 6lo= -chairs@ietf.org on presentations of drafts with the following informat= ion:

Draft name :
Brief description:
Presenter:
Objective :

--
We have successfully completed many drafts to RFC that were on the queue= . New proposals are welcome.

The requests are due = on or before March 13th, 2017.

Remember that the d= raft submission cut-off date is March 13th as well.
Thanks,
=
-Samita
--94eb2c14a138880ca90549243f73-- From nobody Wed Feb 22 14:57:17 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9A4129C97; Wed, 22 Feb 2017 14:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Mun3C9IRqfk8; Wed, 22 Feb 2017 14:56:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B280129C78; Wed, 22 Feb 2017 14:56:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3E30CB802E4; Wed, 22 Feb 2017 14:56:48 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170222225648.3E30CB802E4@rfc-editor.org> Date: Wed, 22 Feb 2017 14:56:48 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, 6lo@ietf.org, rfc-editor@rfc-editor.org Subject: [6lo] RFC 8065 on Privacy Considerations for IPv6 Adaptation-Layer Mechanisms X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 22:57:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8065 Title: Privacy Considerations for IPv6 Adaptation-Layer Mechanisms Author: D. Thaler Status: Informational Stream: IETF Date: February 2017 Mailbox: dthaler@microsoft.com Pages: 10 Characters: 22718 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6lo-privacy-considerations-04.txt URL: https://www.rfc-editor.org/info/rfc8065 DOI: 10.17487/RFC8065 This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links. This document is a product of the IPv6 over Networks of Resource-constrained Nodes Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Feb 25 22:05:51 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BC0129630 for <6lo@ietfa.amsl.com>; Sat, 25 Feb 2017 22:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 iGimVj5RgQ68 for <6lo@ietfa.amsl.com>; Sat, 25 Feb 2017 22:05:47 -0800 (PST) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E04A129460 for <6lo@ietf.org>; Sat, 25 Feb 2017 22:05:46 -0800 (PST) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtp (Exim 4.84_2) (envelope-from ) id 1chrxm-00048x-UO; Sun, 26 Feb 2017 07:05:42 +0100 To: Luiz Augusto von Dentz References: <20170224121440.32269-1-luiz.dentz@gmail.com> <20170224121440.32269-7-luiz.dentz@gmail.com> From: Alexander Aring Message-ID: Date: Sun, 26 Feb 2017 07:05:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170224121440.32269-7-luiz.dentz@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: aar@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: 6lo@ietf.org Archived-At: Cc: netdev@vger.kernel.org, devel@riot-os.org, linux-bluetooth@vger.kernel.org, 6lo@ietf.org, linux-wpan@vger.kernel.org, patrik.flykt@linux.intel.com Subject: Re: [6lo] [PATCH v5 6/6] 6lowpan: Fix IID format for Bluetooth X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 06:05:49 -0000 Hi, On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote: > From: Luiz Augusto von Dentz > > Accourding to RFC 7668 U/L bit shall not be used: > > https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]: > > In the figure, letter 'b' represents a bit from the > Bluetooth device address, copied as is without any changes on any > bit. This means that no bit in the IID indicates whether the > underlying Bluetooth device address is public or random. > > |0 1|1 3|3 4|4 6| > |0 5|6 1|2 7|8 3| > +----------------+----------------+----------------+----------------+ > |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb| > +----------------+----------------+----------------+----------------+ > > Because of this the code cannot figure out the address type from the IP > address anymore thus it makes no sense to use peer_lookup_ba as it needs > the peer address type. > I am still not quite 100% of this and want to leave my opinion about this handling which can be interpreted in a different way. The RFC says here: Following the guidance of [RFC7136], a 64-bit Interface Identifier (IID) is formed from the 48-bit Bluetooth device address by inserting two octets, with hexadecimal values of 0xFF and 0xFE in the middle of the 48-bit Bluetooth device address as shown in Figure 6. In the figure, letter 'b' represents a bit from the Bluetooth device address, copied as is without any changes on any bit. You cut the important part "Following the guidance of [RFC7136]". --- What you describe is "How to see the link layer address from L3 layer" and then it clearly said "there is no bit which indicate something special that the address is public/random, whatever". --- At my point of you the RFC tells here: grab the L2 layer in the way how you quote above, but then apply [RFC7136] which is L3 handling. I simple cc now some 6lo ietf stuff and others 6lowpan hackers, maybe we have luck and somebody can answer this question. --- And when we already about to start a discussion about that, what is do to with the multicast bit of L2 address? I know you told it's not an EUI-48 address. Are you sure? If it's really EUI-48 then I think [RFC7136] should be applied. - Alex From nobody Sat Feb 25 22:25:10 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A02129884 for <6lo@ietfa.amsl.com>; Sat, 25 Feb 2017 22:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 YKuASOrb6MXU for <6lo@ietfa.amsl.com>; Sat, 25 Feb 2017 22:25:07 -0800 (PST) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F63129630 for <6lo@ietf.org>; Sat, 25 Feb 2017 22:25:07 -0800 (PST) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtp (Exim 4.84_2) (envelope-from ) id 1chsGW-0006Km-CW; Sun, 26 Feb 2017 07:25:04 +0100 References: <20170224121440.32269-1-luiz.dentz@gmail.com> <20170224121440.32269-7-luiz.dentz@gmail.com> To: Luiz Augusto von Dentz From: Alexander Aring Message-ID: <145a7942-b86e-30e9-9542-187705c80fbf@pengutronix.de> Date: Sun, 26 Feb 2017 07:25:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: aar@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: 6lo@ietf.org Archived-At: Cc: netdev@vger.kernel.org, devel@riot-os.org, linux-bluetooth@vger.kernel.org, 6lo@ietf.org, linux-wpan@vger.kernel.org, patrik.flykt@linux.intel.com Subject: Re: [6lo] [PATCH v5 6/6] 6lowpan: Fix IID format for Bluetooth X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 06:25:09 -0000 Hi, On 02/26/2017 07:05 AM, Alexander Aring wrote: > > Hi, > > On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote: >> From: Luiz Augusto von Dentz >> >> Accourding to RFC 7668 U/L bit shall not be used: >> >> https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]: >> >> In the figure, letter 'b' represents a bit from the >> Bluetooth device address, copied as is without any changes on any >> bit. This means that no bit in the IID indicates whether the >> underlying Bluetooth device address is public or random. >> >> |0 1|1 3|3 4|4 6| >> |0 5|6 1|2 7|8 3| >> +----------------+----------------+----------------+----------------+ >> |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb| >> +----------------+----------------+----------------+----------------+ >> >> Because of this the code cannot figure out the address type from the IP >> address anymore thus it makes no sense to use peer_lookup_ba as it needs >> the peer address type. >> > > I am still not quite 100% of this and want to leave my opinion about this > handling which can be interpreted in a different way. > > The RFC says here: > > Following the guidance of [RFC7136], a 64-bit > Interface Identifier (IID) is formed from the 48-bit Bluetooth device > address by inserting two octets, with hexadecimal values of 0xFF and > 0xFE in the middle of the 48-bit Bluetooth device address as shown in > Figure 6. Okay, they said from IID from the 48-bit address. And IID is what you need here and what [RFC7136] describes as result, so I think you are right. There is no need for special u/l bitflip or link-layer multicast handling. - Alex From nobody Sun Feb 26 14:15:11 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7452F1294A0; Sun, 26 Feb 2017 14:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 v5MhSP0NIU0T; Sun, 26 Feb 2017 14:14:57 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DF71294A7; Sun, 26 Feb 2017 14:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1QMElKL028890; Sun, 26 Feb 2017 23:14:47 +0100 (CET) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vWfK33grYzDHRb; Sun, 26 Feb 2017 23:14:47 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 509840086.855156-08f7fbcefca09b0e23a26350e9f274fe Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 26 Feb 2017 23:14:46 +0100 Message-Id: <74320B9C-EA99-48E5-9F5F-7BE7982EF945@tzi.org> To: 6lo@ietf.org, 6tisch@ietf.org, lp-wan , lwip@ietf.org, roll@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [6lo] Constrained Node/Network Cluster @ IETF98: DRAFT AGENDA X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 22:15:04 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF98. Remember that there is still quite some potential for changes. ACE/HOMENET/DISPATCH is a bit of a triple whammy. WUGH on LWIG will pull many constrained networks people off the github discussion. I'm not seeing any other major issues, but please do alert the respective chairs when you see one. All times are CDT (UTC-0500) -- yes, the US will be on DST already for a couple of weeks, while Europe moves over right on Mar 26th. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, March 26, 2017 0900-1700 IRTF*** icnrg, with some t2trg-related items on the = agenda MONDAY, March 27, 2017 0900-1130 Morning Session I Zurich A ART dispatch Dispatch WG Zurich D INT homenet Home Networking WG Zurich C SEC *** ace Authentication and Authorization for = Constrained Environments WG 1300-1500 Afternoon Session I Zurich E/F IRTF*** t2trg Thing-to-Thing Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich B RTG bier Bit Indexed Explicit Replication WG Zurich G RTG detnet Deterministic Networking WG Vevey 1/2 TSV tsvarea Transport Area Open Meeting 1520-1650 Afternoon Session II Zurich A SEC tokbind Token Binding WG 1710-1810 Afternoon Session III Vevey 1/2 GEN wugh WGs Using GitHub BOF Zurich E/F INT *** lwig Light-Weight Implementation Guidance WG Montreux 3 SEC curdle CURves, Deprecating and a Little more = Encryption WG Zurich C SEC oauth Web Authorization Protocol WG Zurich G TSV tsvwg Transport Area Working Group WG TUESDAY, March 28, 2017 0900-1130 Morning Session I Zurich C INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Zurich D IRTF maprg Measurement and Analysis for Protocols Zurich E/F SEC tls Transport Layer Security WG 1300-1430 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG Zurich D INT intarea Internet Area Working Group WG Zurich A RTG babel Babel routing protocol WG 1450-1620 Afternoon Session II Zurich G ART uta Using TLS in Applications WG Zurich E/F SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF 1640-1840 Afternoon Session III Zurich C INT dnssd Extensions for Scalable DNS Service = Discovery WG Zurich E/F TSV taps Transport Services WG WEDNESDAY, March 29, 2017 0900-1130 Morning Session I Zurich A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG 1300-1500 Afternoon Session I Zurich A INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Montreux 3 TSV tcpinc TCP Increased Security WG THURSDAY, March 30, 2017 0900-1130 Morning Session I Zurich D INT 6man IPv6 Maintenance WG Zurich C IRTF icnrg Information-Centric Networking Zurich E/F RTG rtgarea Routing Area Open Meeting Vevey 1/2 TSV quic QUIC WG 1300-1500 Afternoon Session I Zurich B ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Zurich G SEC acme Automated Certificate Management = Environment WG Zurich A TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Zurich A OPS v6ops IPv6 Operations WG Zurich D SEC saag Security Area Open Meeting 1740-1840 Afternoon Session III Zurich A RTG *** roll Routing Over Low power and Lossy = networks WG FRIDAY, March 31, 2017 0900-1130 Morning Session I Vevey 1/2 ART httpbis Hypertext Transfer Protocol WG Zurich E/F INT ipwave IP Wireless Access in Vehicular = Environments WG Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich C SEC oauth Web Authorization Protocol WG 1150-1320 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG From nobody Mon Feb 27 01:31:32 2017 Return-Path: X-Original-To: 6lo@ietf.org Delivered-To: 6lo@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FB6128E18; Mon, 27 Feb 2017 01:31:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148818788649.21101.3025759710729034640.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 01:31:26 -0800 Archived-At: Cc: 6lo@ietf.org Subject: [6lo] I-D Action: draft-ietf-6lo-6lobac-07.txt X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 09:31:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes of the IETF. Title : Transmission of IPv6 over MS/TP Networks Authors : Kerry Lynn Jerry Martocci Carl Neilson Stuart Donaldson Filename : draft-ietf-6lo-6lobac-07.txt Pages : 27 Date : 2017-02-27 Abstract: Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6lo-6lobac-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-6lobac-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 27 05:56:39 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2386F1298C8 for <6lo@ietfa.amsl.com>; Mon, 27 Feb 2017 05:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 P7H_aHB6CdDv for <6lo@ietfa.amsl.com>; Mon, 27 Feb 2017 05:56:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4597F129FC9 for <6lo@ietf.org>; Mon, 27 Feb 2017 05:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17104; q=dns/txt; s=iport; t=1488203795; x=1489413395; h=from:to:cc:subject:date:message-id:mime-version; bh=Gdp2k1vzWMwiy9ghsp9JEe1Y+Z494xsVJ1vjVPT/ee8=; b=mHLmi82eoIQM0OOLG4Tp3sDQn1ubq7Ye7LyZTF4seJrW6fITC7R7ZkI6 VVwk85PGInQdeE7g1PAMQL02oq7oYJ7cZof5XcEI3JVmRWdVM6WgUQx1j 0Kfa6Rl8j6ozRseG1FVYKEGwWCR1EediFWKCQhC9eGgB64tzcGSVC5dVW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWBADeLrRY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5iYTFYB4NUigiRYIgMh32FLIINKoV4AhqBfT8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEcAEGIwo6EhIBCBUqAwIEHxEUEgEEDgUIAYlTAxUOr2eCJocxDYQAAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYZMhG+BPIEVgjmCFjqCXwWbZDoBjgWEGIIEhSC?= =?us-ascii?q?JfYg8gg6IZgEfOIEBVBWFCiCBYXWJDYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,214,1484006400"; d="scan'208,217";a="211752723" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 13:56:34 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1RDuYBi029443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Feb 2017 13:56:34 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Feb 2017 07:56:33 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Mon, 27 Feb 2017 07:56:33 -0600 From: "Pascal Thubert (pthubert)" To: Samita Chakrabarti Thread-Topic: Understanding RFC8025 implementation and page switching Thread-Index: AdKRASBYDe/9j8+ZR0qXALnqIdVSzw== Date: Mon, 27 Feb 2017 13:56:19 +0000 Deferred-Delivery: Mon, 27 Feb 2017 13:56:17 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.38] Content-Type: multipart/alternative; boundary="_000_dfb9774b121f441ea3a098b2c92c1280XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: lo <6lo@ietf.org> Subject: Re: [6lo] Understanding RFC8025 implementation and page switching X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:56:37 -0000 --_000_dfb9774b121f441ea3a098b2c92c1280XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTYW1pdGEgOg0KDQpGcm9tOiBTYW1pdGEgQ2hha3JhYmFydGkgW21haWx0bzpzYW1pdGFj LmlldGZAZ21haWwuY29tXQ0KDQoNCkhlbGxvIDoNCg0KSSBhbSB0cnlpbmcgdG8gZGVjaXBoZXIg dGhlIFJGQyA4MDI1ICBwYWNrZXQgaGVhZGVyIHNlcXVlbmNlIGFuZCBiaXQgcGF0dGVybnMgZnJv bSByZWFkaW5nIHRoZSBkb2N1bWVudCBhbmQgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50 cy9fNmxvd3Bhbi1wYXJhbWV0ZXJzLy4NCg0KU29ycnksIEkgc2hvdWxkIGhhdmUgYXNrZWQgdGhl c2UgcXVlc3Rpb25zIGJlZm9yZSwgYnV0IGl0IGlzIG5ldmVyIHRvbyBsYXRlLi4uDQoNCiogSSBh c3N1bWUgdGhlIG1haW4gcHVycG9zZSBpcyB0byBnaXZlIHRoZSBpbXBsZW1lbnRvciB0b29scyB0 byBnbyBhbmQgcGFyc2UvaW50ZXJwcmV0ZSBhZGRpdGlvbmFsIGRhdGEgY2FycmllZCBieSBvcmln aW5hbCBSRkMgNDk0NCBzdHlsZSBwYWNrZXQgb3Igbm90Lg0KDQpbUGFzY2FsXSBZZXMsIHdlIGhh dmUgYSB2ZXJ5IGxhcmdlIHNwYWNlIG5vdy4NCg0KKiBUaGUgZG9jdW1lbnQgc2F5cyB0aGF0IHRo ZSBwYWdlLXN3aXRjaCBkaXNwYXRjaCB0eXBlIHNob3VsZCBiZSBhbHdheXMgcHJlY2VkZWQgYnkg bWVzaCBhbmQgZnJhZ21lbnQgaGVhZGVyLiBJIHdvdWxkIGFzc3VtZSB0aGF0IG9yaWdpbmFsIHBn IDAgb3IgTE9XUEFOLUlQSEMgZGlzcGF0Y2ggdHlwZSBjYW4gcHJlY2VkZSBhcyB3ZWxsLiBDYW4g c29tZSBvbmUgY29uZmlybSBpZiB0aGUgZm9sbG93aW5nIHNlcXVlbmNlcyBhcmUgdmFsaWQgPw0K DQpbUGFzY2FsXSBUaGUgcGFnZSAwIHN3aXRjaCBpcyBpbXBsaWNpdCBhbmQgcGxhY2VkIGJlZm9y ZSB0aGUgbWVzaCBoZWFkZXIsIHdoaWNoIGlzIGRlZmluZWQgaW4gdGhhdCBwYWdlLiBUaGVyZSBj YW4gYmUgYSBwYWNrZXQgd2l0aG91dCBhIG1lc2ggb3IgYSBmcmFnbWVudCBoZWFkZXIsIHNvIGEg cGFnZSBzd2l0Y2ggaXMgbm90IGFsd2F5cyBwcmVjZWRlZCBieSBvbmUgb2YgdGhvc2UuIEJ1dCBp ZiBvbmUgb2YgdGhvc2UgaGVhZGVycyBpcyBwcmVzZW50LCB0aGVuIGl0IGFwcGVhcnMgYmVmb3Jl IHN3aXRjaGluZyB0byBhbm90aGVyIHBhZ2UuDQoNCjEpIFtNZXNoXVtwYWdlLXN3aXRjaC10by1Y XVtOZXctZGlzcGF0Y2gtdHlwZSBmcm9tIHBhZ2UgWF1bUGF5bG9hZF0NCltQYXNjYWxdIFZhbGlk DQoyKSBbRVNDXVtFU0MtQnl0ZXNdW0xPV1BBTl9JUEhDXVtwYWdlLXN3aXRjaC10by1YXVtQYWdl LVgtZGlzcGF0Y2hdW1BheWxvYWRdDQpbUGFzY2FsXSBJIGV4cGVjdCB0aGF0IHRoaXMgY291bGQg aGFwcGVuIHdpdGggYW4gdXBkYXRlIG9mIFJGQyA2MjgyLCBidXQgd2l0aCB0aGUgY3VycmVudCBz cGVjIHlvdSBjYW5ub3Qgc2luY2UgUkZDNjI4MiBkZWZpbmVzIHRoZSBjaGFpbiBhbGwgdGhlIHdh eSB0byB0aGUgcGF5bG9hZCBvciBhdCBsZWFzdCB0aGUgZW5kIG9mIHRoZSBjb21wcmVzc2VkIHBp ZWNlLg0KDQozKSBbTE9XUEFOLUlQSENdW1BheWxvYWRdW3BhZ2Utc3dpdGNoLXRvWF1bUGFnZS1Y LWRpc3BhdGNoXVthZGRpdGlvbmFsLXBheWxvYWRdDQpbUGFzY2FsXSBUaGVuIGFnYWluIHRoaXMg Y291bGQgaGFwcGVuIGJ1dCB3b3VsZCBuZWVkIG5ldyBzcGVjcw0KDQoNCklmIGJvdGggMiBhbmQg MyBhcmUgdmFsaWQgc2VxdWVuY2VzLCBjYW4geW91IHBsZWFzZSBwcm92aWRlIHR3byBleGFtcGxl cyBvZiB1c2UtY2FzZXMgPw0KDQpbUGFzY2FsXSBJdCBjb3VsZCBwb3RlbnRpYWxseSBiZSB1c2Vk IGZvciBzZWxlY3RpdmVseSBjb21wcmVzc2luZyBvciBzaWduaW5nIHRoZSBwYXlsb2FkOyBidXQg IEnigJltIG5vdCBhd2FyZSBvZiBhbnlvbmUgdHJ5aW5nIHRoaXMuDQpJdCBjb3VsZCBhbHNvIGJl IHVzZWQgZm9yIHBhY2thZ2luZyBzZXBhcmF0ZSBmcmFnbWVudHMgYmFjayB0b2dldGhlciBvciBz b21ldGhpbmcuIEkgZG8gaG9wZSB0aGF0IG5vIG9uZSBldmVyIHNwZWNpZmllcyB0aGlzIGJhc2Vk IG9uIHdoYXQgSSBoZWFyZCBmcm9tIE1QLVRDUCBhbmQgbWlkZGxlIGJveCBnYW1lcy4NClRoZSBt b3N0IGNvbW1vbiBzZXF1ZW5jZSBpbnZvbHZpbmcgUkZDIDgwMjUgd291bGQgYmUgW3BhZ2Utc3dp dGNoLXRvLVBhZ2UxXSBbNkxvUkhdKiBbTE9XUEFOLUlQSENdIFtJUHY2IGhlYWRlcnNdKiBbTE9X UEFOLU5IQ10gW1BheWxvYWRdDQoNCkkgd2FzIG5vdCBzdXJlIGlmIHdlIGNhbiBhbGxvdyBwYXls b2FkIHdpdGggZWFjaCBwYWdlIGFuZCBwYXJzZSBtdWx0aXBsZSBwYXlsb2FkcyB3aXRoIHRoZSBz YW1lIHBhY2tldCBbIGFzc3VtaW5nIHdlIGhhdmUgbGFyZ2UgZW5vdWdoIGZyYW1lIHNpemVdLg0K W1Bhc2NhbF0gVGhlIHBhZ2luZyBkb2VzIG5vdCBzYXksIGJ1dCBuZXcgc3BlY3MgdXNpbmcgaXQg d291bGQuDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNClRoYW5rcywNCi1TYW1pdGENCg0K --_000_dfb9774b121f441ea3a098b2c92c1280XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RGVhciBTYW1pdGEmbmJzcDs6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTYW1pdGEgQ2hha3JhYmFydGkgW21haWx0 bzpzYW1pdGFjLmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+SGVsbG8gOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+SSBhbSB0cnlpbmcgdG8gZGVjaXBoZXIgdGhlIFJGQyA4MDI1ICZuYnNwO3Bh Y2tldCBoZWFkZXIgc2VxdWVuY2UgYW5kIGJpdCBwYXR0ZXJucyBmcm9tIHJlYWRpbmcgdGhlIGRv Y3VtZW50IGFuZCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv XzZsb3dwYW4tcGFyYW1ldGVycy8iPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvXzZs b3dwYW4tcGFyYW1ldGVycy88L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5Tb3JyeSwgSSBzaG91bGQgaGF2ZSBhc2tlZCB0aGVzZSBxdWVzdGlv bnMgYmVmb3JlLCBidXQgaXQgaXMgbmV2ZXIgdG9vIGxhdGUuLi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+KiBJIGFzc3VtZSB0aGUgbWFpbiBwdXJw b3NlIGlzIHRvIGdpdmUgdGhlIGltcGxlbWVudG9yIHRvb2xzIHRvIGdvIGFuZCBwYXJzZS9pbnRl cnByZXRlIGFkZGl0aW9uYWwgZGF0YSBjYXJyaWVkIGJ5IG9yaWdpbmFsIFJGQyA0OTQ0IHN0eWxl IHBhY2tldCBvciBub3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltQYXNjYWxdIFllcywgd2UgaGF2 ZSBhIHZlcnkgbGFyZ2Ugc3BhY2Ugbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+KiBUaGUgZG9jdW1lbnQgc2F5cyB0aGF0IHRoZSBw YWdlLXN3aXRjaCBkaXNwYXRjaCB0eXBlIHNob3VsZCBiZSBhbHdheXMgcHJlY2VkZWQgYnkgbWVz aCBhbmQgZnJhZ21lbnQgaGVhZGVyLiBJIHdvdWxkIGFzc3VtZSB0aGF0IG9yaWdpbmFsIHBnIDAg b3IgTE9XUEFOLUlQSEMgZGlzcGF0Y2ggdHlwZSBjYW4gcHJlY2VkZSBhcyB3ZWxsLiBDYW4gc29t ZSBvbmUgY29uZmlybQ0KIGlmIHRoZSBmb2xsb3dpbmcgc2VxdWVuY2VzIGFyZSB2YWxpZCA/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPltQYXNjYWxdIFRoZSBwYWdlIDAgc3dpdGNoIGlzIGltcGxpY2l0 IGFuZCBwbGFjZWQgYmVmb3JlIHRoZSBtZXNoIGhlYWRlciwgd2hpY2ggaXMgZGVmaW5lZCBpbiB0 aGF0IHBhZ2UuIFRoZXJlIGNhbiBiZSBhIHBhY2tldCB3aXRob3V0IGEgbWVzaCBvciBhIGZyYWdt ZW50DQogaGVhZGVyLCBzbyBhIHBhZ2Ugc3dpdGNoIGlzIG5vdCBhbHdheXMgcHJlY2VkZWQgYnkg b25lIG9mIHRob3NlLiBCdXQgaWYgb25lIG9mIHRob3NlIGhlYWRlcnMgaXMgcHJlc2VudCwgdGhl biBpdCBhcHBlYXJzIGJlZm9yZSBzd2l0Y2hpbmcgdG8gYW5vdGhlciBwYWdlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MSkgW01lc2hd W3BhZ2Utc3dpdGNoLXRvLVhdW05ldy1kaXNwYXRjaC10eXBlIGZyb20gcGFnZSBYXVtQYXlsb2Fk XTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltQYXNjYWxdIFZhbGlkPC9zcGFuPjwvaT48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MikgW0VTQ11bRVNDLUJ5 dGVzXVtMT1dQQU5fSVBIQ11bcGFnZS1zd2l0Y2gtdG8tWF1bUGFnZS1YLWRpc3BhdGNoXVtQYXls b2FkXQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Bhc2NhbF0gSSBleHBlY3QgdGhhdCB0aGlzIGNvdWxkIGhh cHBlbiB3aXRoIGFuIHVwZGF0ZSBvZiBSRkMgNjI4MiwgYnV0IHdpdGggdGhlIGN1cnJlbnQgc3Bl YyB5b3UgY2Fubm90IHNpbmNlIFJGQzYyODIgZGVmaW5lcyB0aGUgY2hhaW4gYWxsIHRoZSB3YXkg dG8gdGhlDQogcGF5bG9hZCBvciBhdCBsZWFzdCB0aGUgZW5kIG9mIHRoZSBjb21wcmVzc2VkIHBp ZWNlLjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MykgW0xPV1BBTi1JUEhDXVtQYXlsb2FkXVtw YWdlLXN3aXRjaC10b1hdW1BhZ2UtWC1kaXNwYXRjaF1bYWRkaXRpb25hbC1wYXlsb2FkXTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltQYXNjYWxdIFRoZW4gYWdhaW4gdGhpcyBjb3VsZCBo YXBwZW4gYnV0IHdvdWxkIG5lZWQgbmV3IHNwZWNzDQo8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYgYm90aCAyIGFuZCAzIGFyZSB2YWxpZCBz ZXF1ZW5jZXMsIGNhbiB5b3UgcGxlYXNlIHByb3ZpZGUgdHdvIGV4YW1wbGVzIG9mIHVzZS1jYXNl cyA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ W1Bhc2NhbF0gSXQgY291bGQgcG90ZW50aWFsbHkgYmUgdXNlZCBmb3Igc2VsZWN0aXZlbHkgY29t cHJlc3Npbmcgb3Igc2lnbmluZyB0aGUgcGF5bG9hZDsgYnV0ICZuYnNwO0nigJltIG5vdCBhd2Fy ZSBvZiBhbnlvbmUgdHJ5aW5nIHRoaXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IGNv dWxkIGFsc28gYmUgdXNlZCBmb3IgcGFja2FnaW5nIHNlcGFyYXRlIGZyYWdtZW50cyBiYWNrIHRv Z2V0aGVyIG9yIHNvbWV0aGluZy4gSSBkbyBob3BlIHRoYXQgbm8gb25lIGV2ZXIgc3BlY2lmaWVz IHRoaXMgYmFzZWQgb24gd2hhdCBJIGhlYXJkIGZyb20gTVAtVENQDQogYW5kIG1pZGRsZSBib3gg Z2FtZXMuPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgbW9zdCBjb21tb24gc2VxdWVuY2Ug aW52b2x2aW5nIFJGQyA4MDI1IHdvdWxkIGJlDQo8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xv cjojNTQ4MjM1O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiM1NDgyMzU7bXNvLXN0eWxl LXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj5bcGFnZS1zd2l0Y2gtdG8tUGFnZTFdIFs2TG9S SF0qIFtMT1dQQU4tSVBIQ10gW0lQdjYgaGVhZGVyc10qIFtMT1dQQU4tTkhDXSBbUGF5bG9hZF08 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB3YXMgbm90IHN1cmUgaWYg d2UgY2FuIGFsbG93IHBheWxvYWQgd2l0aCBlYWNoIHBhZ2UgYW5kIHBhcnNlIG11bHRpcGxlIHBh eWxvYWRzIHdpdGggdGhlIHNhbWUgcGFja2V0IFsgYXNzdW1pbmcgd2UgaGF2ZSBsYXJnZSBlbm91 Z2ggZnJhbWUgc2l6ZV0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Bhc2NhbF0gVGhlIHBhZ2luZyBkb2VzIG5v dCBzYXksIGJ1dCBuZXcgc3BlY3MgdXNpbmcgaXQgd291bGQuPG86cD48L286cD48L3NwYW4+PC9p PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRha2UgY2FyZSwNCjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYXNjYWw8 L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPi1TYW1pdGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_dfb9774b121f441ea3a098b2c92c1280XCHRCD001ciscocom_-- From nobody Mon Feb 27 09:17:00 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB412A257 for <6lo@ietfa.amsl.com>; Mon, 27 Feb 2017 09:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 eRqVdRwo5sJ2 for <6lo@ietfa.amsl.com>; Mon, 27 Feb 2017 09:16:57 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DD812A255 for <6lo@ietf.org>; Mon, 27 Feb 2017 09:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1RHGicc016075; Mon, 27 Feb 2017 18:16:45 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vX7fh56mXzDHpv; Mon, 27 Feb 2017 18:16:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Mon, 27 Feb 2017 18:16:44 +0100 X-Mao-Original-Outgoing-Id: 509908604.150677-25778b2cd3ecf4ce84f86457d763cdc8 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pascal Thubert X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Samita Chakrabarti , lo <6lo@ietf.org> Subject: Re: [6lo] Understanding RFC8025 implementation and page switching X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 17:16:59 -0000 On 27 Feb 2017, at 14:56, Pascal Thubert (pthubert) = wrote: >=20 > [Pascal] I expect that this could happen with an update of RFC 6282, = but with the current spec you cannot since RFC6282 defines the chain all = the way to the payload or at least the end of the compressed piece. >=20 Well, yes. 6282 does define a registry for LOWPAN_NHC types, so the set = available for those can be extended without updating RFC 6282. We = don=E2=80=99t have any page switching for those, but probably don=E2=80=99= t need something like that any time soon, as only 20 of the 256 code = positions are taken. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 27 09:46:55 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754A0129996 for <6lo@ietfa.amsl.com>; Mon, 27 Feb 2017 09:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Y8oSaUiDNx9F for <6lo@ietfa.amsl.com>; Mon, 27 Feb 2017 09:46:40 -0800 (PST) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA0F12A2CA for <6lo@ietf.org>; Mon, 27 Feb 2017 09:46:33 -0800 (PST) Received: by mail-qk0-x242.google.com with SMTP id n127so18785549qkf.2 for <6lo@ietf.org>; Mon, 27 Feb 2017 09:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QWZyz4T3a2VKYl36P4UpCIIH+Az2t8iLidCusw69gik=; b=RzxZqRACZfneTYo9tdzNaD8T2ePFw8P4W2hwRQ79+WH5WOZkyk3at2htxcOzPwwviK ZExac7XbeFje02sXiwyujg0HmXkG57kvR8X2P6B0pAImc5i040nN8AT0Z1FxFWNdCJwD e1PcIuDOmqfmi3ywt4T+wnf5qqoBWQkT7PvfiFGFUtRO8DlAk/NwGIwFsuyXwJV9vjcA m0jlDhxUMRCbVgg3YKhKURQCDIRlMejdByMXqSNJucOzLkOiAf21RXHmpIvPrpGnjEny 1S6HFowhmSxhkreZW6e/d49V/yh5vIrzn//ZD+NnKvHjjsvRn6BYRa/7DE12FZym8s3d mt+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:from:date:message-id:subject:to:cc; bh=QWZyz4T3a2VKYl36P4UpCIIH+Az2t8iLidCusw69gik=; b=oBJb8poPRFsrgFlkJk46nEfAO9RZZJrXOru+bW+R7JVB8ej/9ACJkbEjxnox/AOy5I SN1YuToeHqXiJL1+MakIXaEffjKxI4shWkqzSUo1hU0upX3e/mZIMIiyqFJJ4H9Ejn5h 34THy/l+fGTSSWFhG6nd1m3yjIXQJU2RbCdZYiuQtUbiVG8If+RCGMZVFQ7yGcmz+JT/ slzmKCVkD1s+9u1JJq9cNnBzbn1Ak1h7V2DMtI6BF5AFOHFfnuB4SyJw4MBJoItZoH/H m1NPz9R62Z9fios6reIu6CbfSzGAleKMJAH3XHcuhkzdWgUia/LG30jqfHLbGINYmXoj TajA== X-Gm-Message-State: AMke39l07VnV0gnOAKGmKVRtqd2g1GztvTehySc3xGRpQp0GY8vAXDZGC9+fcwTGHGblKJ6PF1JUQ0C6bg+RkQ== X-Received: by 10.55.184.5 with SMTP id i5mr18531954qkf.217.1488217592299; Mon, 27 Feb 2017 09:46:32 -0800 (PST) MIME-Version: 1.0 Sender: robert.cragie@gmail.com Received: by 10.237.59.186 with HTTP; Mon, 27 Feb 2017 09:46:31 -0800 (PST) In-Reply-To: References: From: Robert Cragie Date: Mon, 27 Feb 2017 17:46:31 +0000 X-Google-Sender-Auth: eEUUX5f9fOLwhIdNzS6QeBx6CL0 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=94eb2c07927cf00b0d054986a8c7 Archived-At: Cc: Samita Chakrabarti , lo <6lo@ietf.org> Subject: Re: [6lo] Understanding RFC8025 implementation and page switching X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 17:46:42 -0000 --94eb2c07927cf00b0d054986a8c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27 February 2017 at 13:56, Pascal Thubert (pthubert) wrote: > Dear Samita : > > > > *From:* Samita Chakrabarti [mailto:samitac.ietf@gmail.com] > > > > Hello : > > > > I am trying to decipher the RFC 8025 packet header sequence and bit > patterns from reading the document and http://www.iana.org/ > assignments/_6lowpan-parameters/. > > > > Sorry, I should have asked these questions before, but it is never too > late... > > > > * I assume the main purpose is to give the implementor tools to go and > parse/interprete additional data carried by original RFC 4944 style packe= t > or not. > > > > *[Pascal] Yes, we have a very large space now.* > > > > * The document says that the page-switch dispatch type should be always > preceded by mesh and fragment header. I would assume that original pg 0 o= r > LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if th= e > following sequences are valid ? > > > > *[Pascal] The page 0 switch is implicit and placed before the mesh header= , > which is defined in that page. There can be a packet without a mesh or a > fragment header, so a page switch is not always preceded by one of those. > But if one of those headers is present, then it appears before switching = to > another page.* > There is nothing stopping definitions for a mesh header equivalent in pages 2-14 and fragment header equivalent in pages 1-14. However, in the context of RFC 8025, mesh and fragment headers are strictly considered as being in page 0, hence having to precede them with a page 0 dispatch, which as Pascal says is implicit at the beginning of a frame, i.e. at the moment we would have: [(implicit page 0 dispatch)][MESH][FRAG0][page-switch-to-X][New-dispatch-ty= pe from page X][Payload] In the future, one can envisage alternatives however: [page-switch-to-2][MESH from page 2][FRAG from page 2][New-dispatch-type from page 2][Payload] > > > 1) [Mesh][page-switch-to-X][New-dispatch-type from page X][Payload] > > *[Pascal] Valid* > > 2) [ESC][ESC-Bytes][LOWPAN_IPHC][page-switch-to-X][Page-X-dispatch][Paylo= ad] > > > *[Pascal] I expect that this could happen with an update of RFC 6282, but > with the current spec you cannot since RFC6282 defines the chain all the > way to the payload or at least the end of the compressed piece.* > > > > 3) [LOWPAN-IPHC][Payload][page-switch-toX][Page-X-dispatch][ > additional-payload] > > *[Pascal] Then again this could happen but would need new specs * > > > > > > If both 2 and 3 are valid sequences, can you please provide two examples > of use-cases ? > > > > *[Pascal] It could potentially be used for selectively compressing or > signing the payload; but I=E2=80=99m not aware of anyone trying this. * > > *It could also be used for packaging separate fragments back together or > something. I do hope that no one ever specifies this based on what I hear= d > from MP-TCP and middle box games.* > > *The most common sequence involving RFC 8025 would be *[page-switch-to-Pa= ge1] > [6LoRH]* [LOWPAN-IPHC] [IPv6 headers]* [LOWPAN-NHC] [Payload] > > > > I was not sure if we can allow payload with each page and parse multiple > payloads with the same packet [ assuming we have large enough frame size]= . > > *[Pascal] The paging does not say, but new specs using it would.* > > > > *Take care, * > > > > *Pascal* > > > > Thanks, > > -Samita > > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > > --94eb2c07927cf00b0d054986a8c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 27 February 2017 at 13:56, Pascal Thubert (pthubert) <pthubert@cis= co.com> wrote:

Dear Samita=C2=A0:=

=C2=A0

From: Samita Chakrabarti [mailto:samitac.ietf@gmail.= com]

=C2=A0

Hello :

=C2=A0

I am trying to decipher t= he RFC 8025 =C2=A0packet header sequence and bit patterns from reading the = document and=C2=A0http://www.iana.org/assignments/_6lowpan-parameters/.

=C2=A0

Sorry, I should have aske= d these questions before, but it is never too late...

=C2=A0

* I assume the main purpo= se is to give the implementor tools to go and parse/interprete additional d= ata carried by original RFC 4944 style packet or not.

=C2=A0

[Pascal] Yes, we have a very large space = now.

=C2=A0

* The document says that = the page-switch dispatch type should be always preceded by mesh and fragmen= t header. I would assume that original pg 0 or LOWPAN-IPHC dispatch type ca= n precede as well. Can some one confirm if the following sequences are valid ?

=C2=A0

[Pascal] The page 0 switch is implicit an= d placed before the mesh header, which is defined in that page. There can b= e a packet without a mesh or a fragment header, so a page switch is not always preceded by one of those. But if on= e of those headers is present, then it appears before switching to another = page.


<RCC>
There is nothing stopping definitions for a mesh he= ader equivalent in pages 2-14 and fragment header equivalent in pages 1-14.= However, in the context of RFC 8025, mesh and fragment headers are strictl= y considered as being in page 0, hence having to precede them with a page 0= dispatch, which as Pascal says is implicit at the beginning of a frame, i.= e. at the moment we would have:

[(implicit page 0 = dispatch)][MESH][FRAG0][page-switch-to-X][New-dispatch-type from page = X][Payload]

In the future, one can envisage altern= atives however:

[page-switch-to-2][MESH from page = 2][FRAG from page 2][New-dispatch-type from page 2][Payload]
</RCC>

=C2=A0

1) [Mesh][page-switch-to-= X][New-dispatch-type from page X][Payload]

[Pascal] Valid

2) [ESC][ESC-Bytes][LOWPA= N_IPHC][page-switch-to-X][Page-X-dispatch][Payload]

[Pascal] I expect that this could happen = with an update of RFC 6282, but with the current spec you cannot since RFC6= 282 defines the chain all the way to the payload or at least the end of the compressed piece.

=C2=A0

3) [LOWPAN-IPHC][Payload]= [page-switch-toX][Page-X-dispatch][additional-payload]<= /u>

[Pascal] Then again this could happen but= would need new specs

=C2=A0

=C2=A0

If both 2 and 3 are valid= sequences, can you please provide two examples of use-cases ?

=C2=A0

[Pascal] It could potentially be used for= selectively compressing or signing the payload; but =C2=A0I=E2=80=99m not = aware of anyone trying this.

It could also be used for packaging separ= ate fragments back together or something. I do hope that no one ever specif= ies this based on what I heard from MP-TCP and middle box games.

The most common sequence involving RFC 80= 25 would be [page-switch-to-Page1] [6Lo= RH]* [LOWPAN-IPHC] [IPv6 headers]* [LOWPAN-NHC] [Payload]=

=C2=A0

I was not sure if we can = allow payload with each page and parse multiple payloads with the same pack= et [ assuming we have large enough frame size].

[Pascal] The paging does not say, but new= specs using it would.

=C2=A0

Take care,

=C2=A0

Pascal

=C2=A0

Thanks,

-Samita

=C2=A0


_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo


--94eb2c07927cf00b0d054986a8c7-- From nobody Mon Feb 27 14:53:41 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBBB129447; Mon, 27 Feb 2017 14:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oThYxHMz-KRa; Mon, 27 Feb 2017 14:53:31 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8813E129443; Mon, 27 Feb 2017 14:53:31 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id 62so46503920oih.2; Mon, 27 Feb 2017 14:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rnZvXipBZIXrYjhUdgEqkSTJdVXttaMKH3lWdSkRW5M=; b=a8lPX1/9klVmTyI29z1n7b+/zHJul40ca84Iaa0/419n5SRbLB2fTCiSc8YXga00Yz GeeDxHwXcRzgsrTaHsm7EzLIpyncW6cZlZtffCk5pRoTjZxuECbKA+PjBb+ry0chMaDz iUC+r8hSDrjAskyKuqpKjS+SUsrGo7UHm7iTEdPXa/nAMSxORNCuySVPYJKQe7dSSRie Z/IRP7ABQ9elD2lHxbfrsEjrmGNUzY5hIbw5x8THWc0JxrzFTyL0irnPjPrk0Kac0xBx fBkxBUSpn+QqytnMARs/luXvbAn2OGCUt3yx219pvjT6oYYrxrEm/KXoie6vcyxJMa9g 2Auw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rnZvXipBZIXrYjhUdgEqkSTJdVXttaMKH3lWdSkRW5M=; b=YnyVQT+JkGIrZTFhZxF6X9Xi4z2MzUwq2iZpcUqWB73y7oi3dOj9PmBCmYXcfmNj2/ 8fMuiRguFHTGX4aPlLkW9BRG+Z+TGMcCqm52Prf1TRjkKUUCVfyE8+ctLCJ6whXrDEe5 Cu2BC78XZyh9GVgn4e8Zg3jBrs6ltTdN6gZsGIrtDpDfFCaR3YWnQYNARJSwjV7wbmjQ nX3g2qSqm46JADqdjdzTty8BMai4w+IVW4lrp6h23/ooLzs6iFnkK8Ip4d/xYzBBjNEa 2M+Q+wp4fy+h8xmeB/KGKXpV/KjwfcPyirL+aYndoZSnAidm0CEJfehfi239xyWGcowv PAiA== X-Gm-Message-State: AMke39nb94rk1jHxJ9YtaFyGaJ+qk4e6IDvjPKEcZWIK+h1wn4veCxjSRJ4ijVDKFfocFB6K62BFKNi0h5Ce2g== X-Received: by 10.202.245.132 with SMTP id t126mr9008838oih.52.1488236010763; Mon, 27 Feb 2017 14:53:30 -0800 (PST) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.182.217.38 with HTTP; Mon, 27 Feb 2017 14:53:30 -0800 (PST) In-Reply-To: <87h97b41wc.fsf@hobgoblin.ariadne.com> References: <87h97b41wc.fsf@hobgoblin.ariadne.com> From: Kerry Lynn Date: Mon, 27 Feb 2017 17:53:30 -0500 X-Google-Sender-Auth: bHPr6Q-HSgDQnUXrhFNgiWyrin4 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a1149526cc37c9b05498af2a2 Archived-At: Cc: ietf@ietf.org, draft-ietf-6lo-6lobac@ietf.org, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6lo] Last Call: (Transmission of IPv6 over MS/TP Networks) to Proposed Standard X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:53:34 -0000 --001a1149526cc37c9b05498af2a2 Content-Type: text/plain; charset=UTF-8 Dale, Thanks for your thorough review of draft-ietf-6lo-6lobac. Sorry that it has taken so long to get back to you. Can you take a look at the new version and see if it addresses your concerns? Comments inline... On Sun, Nov 13, 2016 at 2:26 PM, Dale R. Worley wrote: > Comments on draft-ietf-6lo-6lobac-06 > > (This is probably the best-written Internet-Draft that I have ever > read.) > > Technical issues: > > 6. Stateless Address Autoconfiguration > > This section defines how to obtain an IPv6 Interface Identifier. The > general procedure for creating a MAC-address-derived IID is described > in [RFC4291] Appendix A, "Creating Modified EUI-64 Format Interface > Identifiers", as updated by [RFC7136]. > > The IID SHOULD NOT embed an [EUI-64] or any other globally unique > hardware identifier assigned to a device (see Section 12). > > Section 6 has been reworked to more clearly distinguish between two types of IIDs: "MAC-address-derived" and "semantically opaque". The first is recommended for link-local addresses because it enables maximum IPv6 header compression efficiency. Since MS/TP is used primarily as a field bus, I expect most installations will only ever involve link-local traffic between an MS/TP device and a local controller. For applications where the MS/TP device is a client or server with routable addresses, the spec strongly recommends generating a semantically opaque IID, with 64 bits of entropy, for each global address. > I have a hard time correlating these two paragraphs. At first read, > the first paragraph describes how an IID is to be constructed from a > MAC address, and the second one specifies that the IID should not > contain a MAC address. Reading more carefully, it seems that the > intention is to refer to one of the methods of constructing IIDs that > are listed in section 2 of RFC 7136 which construct IIDs *from* MAC > addresses but the IIDs do not directly contain them: > > The recommended method of generating IIDs from the 8-bit node address is described, so the reference to EUI-64 has been removed as it was confusing (and MS/TP devices don't typically have static 48- or 64-bit hardware addresses.) > In addition to IIDs formed from IEEE EUI-64 addresses, various new > forms of IIDs have been defined, including temporary addresses > [RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972] > [RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP > addresses [RFC5214]. > > Though, strctily speaking, those formats aren't introduced due to RFC > 7136 updating RFC 4291, but rather by RFC 4941 etc. doing so. > > But if my understanding is correct, it would help greatly if this text > was revised to point more directly to the text that is relevant, as my > reflexive behavior is to read Appendix A of RFC 4291, which only > discusses embedding MAC addresses in IIDs. > > It would also help to explain what the important difference is between > "MAC-address-derived" and "embed an [EUI-64] or other globally unique > hardware identifier" -- I think the critical distinction is that with > the former, knowing the MAC address is not sufficient for an attacker > to guess the IID, but I'm left to guess that. > > Editorial issues: > > 1. Introduction > > a) MS/TP devices typically have a continuous source of power > > I think this isn't quite how you want to phrase it, since a battery is > a "continuous source of power". Perhaps "typically have mains power". > > 1.4. Goals and Constraints > > The primary goal of this specification is to enable IPv6 directly on > wired end devices in building automation and control networks by > leveraging existing standards to the greatest extent possible. A > secondary goal is to co-exist with legacy MS/TP implementations. > > This doesn't seem to be as clear as it could be in a number of ways. > > One issue is the distinction between "primary goal" and "secondary > goal". Naively it seems to me that both are necessary for success, > but as written it sounds like coexistence has in some way been > sacrificed or compromised in order to achieve the primary goal. But > it seems that draft-ietf-6lo-6lobac provides for complete coexistence. > > Only the minimum changes necessary to support IPv6 over MS/TP were > specified in BACnet [Addendum_an] (see Section 1.3). > > This sentence seems to mean that Addendum_an contains just enough > changes to MS/TP to allow draft-ietf-6lo-6lobac to be written. But > it's hard to tell what the significance of that is -- if Addendum_an > is *only* to support draft-ietf-6lo-6lobac, then the partitioning of > changes between Addendum_an and draft-ietf-6lo-6lobac is arbitrary, > and Addendum_an could have been made smaller by shifting some of its > content into draft-ietf-6lo-6lobac. And that contradicts the claim > that Addendum_is "minimum". > > It seems that what is really meant is that Addendum_an support is > necessary for draft-ietf-6lo-6lobac support, or perhaps that the only > use of Addendum_an is to support draft-ietf-6lo-6lobac. > > In order to co-exist with legacy devices, no changes are permitted to > the MS/TP addressing modes, frame header format, control frames, or > Master Node state machine as specified in BACnet [Clause9]. > > Another issue is that there are three "levels", as it were, that a > device can be designed to: > 1. Clause9 alone > 2. Clause9 with Addendum_an > 3. Clause9, Addendum_an, and draft-ietf-6lo-6lobac > I assume that the three levels are upward compatible, in that you can > mix devices designed to all three levels on one network, and then any > two devices will interoperate at the highest level that they share. > But it seems that this could be stated much more clearly by just > saying that draft-ietf-6lo-6lobac is upward-compatible with devices > designed to Clause9 and with devices designed to Clause9 with > Addendum_an. > > ANSI/ASHRAE Standard 135-2016 was published late last year. This version integrates the changes that were standardized in 135-2012 Addendum an, so there's no longer any jumping back and forth between references. Also, I didn't make it clear (outside of 6lo wg) that I can provide a copy of [BACnet] Clause 9 to anyone who wants to reference it in the course of reviewing the ID. It's not really clear what the phrase "no changes are permitted to" > applies to -- is it a description of draft-ietf-6lo-6lobac, or a > warning that there are certain constraints on devices that aren't > stated in this document? > > This is a statement on how to achieve co-existence. Hopefully the context is clearer in the current version of the ID. > 2. MS/TP Mode for IPv6 > > Must all nodes that support IPv6 be master nodes? > > Yes, slave nodes cannot initiate async transmission. MS/TP nodes are designed to ignore frames they don't understand (e.g. 6LoBAC). > ... implement the Receive Frame state machine specified in > [Clause9] as extended by BACnet [Addendum_an]. > > There seems to be an alternative use of "BACnet [Clause9]" > vs. "[Clause9]", and also "BACnet [Addendum_an]" vs. "[Addendum_an]". > The usage should be made consistent, and also aligned with the > definition: > > BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol > for Building Automation and Control Networks > > Does "BACnet" mean just Clause9 or Clause9 plus Addendum_an, or is it > a generic that applies to both sets of specifications? > > Due to the update to the base spec, these references have all been converted to [BACnet] Clause 9. There is a single reference to [Addendum_an] for any historians in the audience. [BACnet] refers to the latest version, ANSI/ASHRAE Standard 135-2016. 5. LoBAC Adaptation Layer > > Implementations MAY also support Generic Header Compression (GHC) > [RFC7400] for transport layer headers. A node implementing [RFC7400] > MUST probe its peers for GHC support before applying GHC. > > This would probably read better if the second "[RFC7400]" was written > "GHC". > > 6. Stateless Address Autoconfiguration > > concatenating a node's' 8-bit MS/TP MAC address to the seven octets > > s/node's'/node's/ > > 9. Multicast Address Mapping > > When represented as > a 16-bit address in a compressed header (see Section 10), it MUST be > formed by padding on the left with a zero: > > This would read more smoothly if "it" was "the broadcast link address" > and "a zero" was "a zero octet". > > 10. Header Compression > > When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short > address") it MUST be formed by padding the MS/TP address to the left > with a zero: > > Similarly, this would read more smoothly if "a zero" was "a zero > octet". > > Appendix B. Consistent Overhead Byte Stuffing [COBS] > > The minimum overhead of COBS is one octet per encoded field. The > worst-case overhead in long fields is bounded to one octet per 254, > or less than 0.4%, as described in [COBS]. > > This could be more informative as: > > The minimum overhead of COBS is one octet per encoded field, and > the maximum overhead is ceiling(length/254) octets. In the limit > for very long fields, the overhead is less than 0.4%. For 1280 > octet fields, the overhead is 0.47% and for 1500 octet fields, the > overhead is 0.39%. > I punted on calculating percentages, assuming the reader could do the math. I guessing it varies discretely between 50% for a 1-byte field and 0.39% for a 254 byte field. The salient fact is the overhead is bounded to six bytes of overhead for a 1500-byte MTU, but maybe I need to say that explicitly. > > Appendix C. Encoded CRC-32K [CRC32K] > > BACnet [Addendum_an] specifies the CRC-32K (Koopman) polynomial. > > "CRC-32K" is not bound at this point. Perhaps > > BACnet [Addendum_an] specifies one of these, the CRC-32K (Koopman) > polynomial. > > I'm pretty sure I incorporated all of your editorial changes. Thanks again, Kerry > Dale > --001a1149526cc37c9b05498af2a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dale,

Thanks for your thorough review o= f draft-ietf-6lo-6lobac.=C2=A0 Sorry that it has taken
so long to= get back to you.=C2=A0 Can you take a look at the new version and see if
it addresses your concerns?=C2=A0 Comments inline...

On Sun, Nov 13, 2016 at 2= :26 PM, Dale R. Worley <worley@ariadne.com> wrote:
Comments on draft-ietf-6lo-6lo= bac-06

(This is probably the best-written Internet-Draft that I have ever
read.)

Technical issues:

6.=C2=A0 Stateless Address Autoconfiguration

=C2=A0 =C2=A0This section defines how to obtain an IPv6 Interface Identifie= r.=C2=A0 The
=C2=A0 =C2=A0general procedure for creating a MAC-address-derived IID is de= scribed
=C2=A0 =C2=A0in [RFC4291] Appendix A, "Creating Modified EUI-64 Format= Interface
=C2=A0 =C2=A0Identifiers", as updated by [RFC7136].

=C2=A0 =C2=A0The IID SHOULD NOT embed an [EUI-64] or any other globally uni= que
=C2=A0 =C2=A0hardware identifier assigned to a device (see Section 12).

<kel>
Section 6 has been reworked to = more clearly distinguish between two types
of IIDs: "MAC-add= ress-derived" and "semantically opaque".=C2=A0 The first is<= /div>
recommended for link-local addresses because it enables maximum I= Pv6
header compression efficiency.=C2=A0 Since MS/TP is used prim= arily as a field
bus, I expect most installations will only ever = involve link-local traffic between
an MS/TP device and a local co= ntroller.

For applications where the MS/TP device = is a client or server with routable
addresses, the spec strongly = recommends generating a semantically opaque
IID, with 64 bits of = entropy, for each global address.
</kel>
I have a hard time correlating these two paragraphs.=C2=A0 At first read, the first paragraph describes how an IID is to be constructed from a
MAC address, and the second one specifies that the IID should not
contain a MAC address.=C2=A0 Reading more carefully, it seems that the
intention is to refer to one of the methods of constructing IIDs that
are listed in section 2 of RFC 7136 which construct IIDs *from* MAC
addresses but the IIDs do not directly contain them:

<kel>
The recommended method of gener= ating IIDs from the 8-bit node address
is described, so the refer= ence to EUI-64 has been removed as it was
confusing (and MS/TP de= vices don't typically have static 48- or 64-bit
hardware addr= esses.)
</kel>=C2=A0
=C2=A0 =C2=A0In addition to IIDs formed from IEEE EUI-64 addresses, various= new
=C2=A0 =C2=A0forms of IIDs have been defined, including temporary addresses=
=C2=A0 =C2=A0[RFC4941], Cryptographically Generated Addresses (CGAs) [RFC39= 72]
=C2=A0 =C2=A0[RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP =C2=A0 =C2=A0addresses [RFC5214].

Though, strctily speaking, those formats aren't introduced due to RFC 7136 updating RFC 4291, but rather by RFC 4941 etc. doing so.

But if my understanding is correct, it would help greatly if this text
was revised to point more directly to the text that is relevant, as my
reflexive behavior is to read Appendix A of RFC 4291, which only
discusses embedding MAC addresses in IIDs.

It would also help to explain what the important difference is between
"MAC-address-derived" and "embed an [EUI-64] or other global= ly unique
hardware identifier" -- I think the critical distinction is that with<= br> the former, knowing the MAC address is not sufficient for an attacker
to guess the IID, but I'm left to guess that.

Editorial issues:

1.=C2=A0 Introduction

=C2=A0 =C2=A0a) MS/TP devices typically have a continuous source of power
I think this isn't quite how you want to phrase it, since a battery is<= br> a "continuous source of power".=C2=A0 Perhaps "typically hav= e mains power".

1.4.=C2=A0 Goals and Constraints

=C2=A0 =C2=A0The primary goal of this specification is to enable IPv6 direc= tly on
=C2=A0 =C2=A0wired end devices in building automation and control networks = by
=C2=A0 =C2=A0leveraging existing standards to the greatest extent possible.= =C2=A0 A
=C2=A0 =C2=A0secondary goal is to co-exist with legacy MS/TP implementation= s.

This doesn't seem to be as clear as it could be in a number of ways.
One issue is the distinction between "primary goal" and "sec= ondary
goal".=C2=A0 Naively it seems to me that both are necessary for succes= s,
but as written it sounds like coexistence has in some way been
sacrificed or compromised in order to achieve the primary goal.=C2=A0 But it seems that draft-ietf-6lo-6lobac provides for complete coexistence.

=C2=A0 =C2=A0Only the minimum changes necessary to support IPv6 over MS/TP = were
=C2=A0 =C2=A0specified in BACnet [Addendum_an] (see Section 1.3).

This sentence seems to mean that Addendum_an contains just enough
changes to MS/TP to allow draft-ietf-6lo-6lobac to be written.=C2=A0 But it's hard to tell what the significance of that is -- if Addendum_an is *only* to support draft-ietf-6lo-6lobac, then the partitioning of
changes between Addendum_an and draft-ietf-6lo-6lobac is arbitrary,
and Addendum_an could have been made smaller by shifting some of its
content into draft-ietf-6lo-6lobac.=C2=A0 And that contradicts the claim that Addendum_is "minimum".

It seems that what is really meant is that Addendum_an support is
necessary for draft-ietf-6lo-6lobac support, or perhaps that the only
use of Addendum_an is to support draft-ietf-6lo-6lobac.

=C2=A0 =C2=A0In order to co-exist with legacy devices, no changes are permi= tted to
=C2=A0 =C2=A0the MS/TP addressing modes, frame header format, control frame= s, or
=C2=A0 =C2=A0Master Node state machine as specified in BACnet [Clause9].
Another issue is that there are three "levels", as it were, that = a
device can be designed to:
=C2=A0 =C2=A0 1. Clause9 alone
=C2=A0 =C2=A0 2. Clause9 with Addendum_an
=C2=A0 =C2=A0 3. Clause9, Addendum_an, and draft-ietf-6lo-6lobac
I assume that the three levels are upward compatible, in that you can
mix devices designed to all three levels on one network, and then any
two devices will interoperate at the highest level that they share.
But it seems that this could be stated much more clearly by just
saying that draft-ietf-6lo-6lobac is upward-compatible with devices
designed to Clause9 and with devices designed to Clause9 with
Addendum_an.

<kel>
ANSI/ASHRAE Standard 135-2016 w= as published late last year.=C2=A0 This
version integrates the ch= anges that were standardized in 135-2012
Addendum an, so there= 9;s no longer any jumping back and forth between
references.

Also, I didn't make it clear (outside of 6lo wg) t= hat I can provide a copy
of [BACnet] Clause 9 to anyone who wants= to reference it in the course
of reviewing the ID.
<= ;/kel>

It's not really clear what the phrase "no changes are permitted to= "
applies to -- is it a description of draft-ietf-6lo-6lobac, or a
warning that there are certain constraints on devices that aren't
stated in this document?

<kel>
This is a statement on how to a= chieve co-existence.=C2=A0 Hopefully the
context is clearer in th= e current version of the ID.
</kel>
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> 2.=C2=A0 MS/TP Mode for IPv6

Must all nodes that support IPv6 be master nodes?

<kel>
Yes, slave nodes cannot initiat= e async transmission.=C2=A0 MS/TP nodes
are designed to ignore fr= ames they don't understand (e.g. 6LoBAC).
</kel>
<= div>=C2=A0
=C2=A0 =C2=A0... implement the Receive Frame state machine specified in
=C2=A0 =C2=A0[Clause9] as extended by BACnet [Addendum_an].

There seems to be an alternative use of "BACnet [Clause9]"
vs. "[Clause9]", and also "BACnet [Addendum_an]" vs. &q= uot;[Addendum_an]".
The usage should be made consistent, and also aligned with the
definition:

=C2=A0 =C2=A0BACnet:=C2=A0 An ISO/ANSI/ASHRAE Standard Data Communication P= rotocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for Building Automation and Contr= ol Networks

Does "BACnet" mean just Clause9 or Clause9 plus Addendum_an, or i= s it
a generic that applies to both sets of specifications?

<kel>
Due to the update to the base s= pec, these references have all been converted
to [BACnet] Clause = 9.=C2=A0 There is a single reference to [Addendum_an] for any
his= torians in the audience. =C2=A0[BACnet] refers to the latest version, ANSI/= ASHRAE
Standard 135-2016.
</kel>

5.=C2=A0 LoBAC Adaptation Layer

=C2=A0 =C2=A0Implementations MAY also support Generic Header Compression (G= HC)
=C2=A0 =C2=A0[RFC7400] for transport layer headers.=C2=A0 A node implementi= ng [RFC7400]
=C2=A0 =C2=A0MUST probe its peers for GHC support before applying GHC.

This would probably read better if the second "[RFC7400]" was wri= tten "GHC".

6.=C2=A0 Stateless Address Autoconfiguration

=C2=A0 =C2=A0concatenating a node's' 8-bit MS/TP MAC address to the= seven octets

s/node's'/node's/

9.=C2=A0 Multicast Address Mapping

=C2=A0 =C2=A0When represented as
=C2=A0 =C2=A0a 16-bit address in a compressed header (see Section 10), it M= UST be
=C2=A0 =C2=A0formed by padding on the left with a zero:

This would read more smoothly if "it" was "the broadcast lin= k address"
and "a zero" was "a zero octet".

10.=C2=A0 Header Compression

=C2=A0 =C2=A0When a 16-bit address is called for (i.e., an IEEE 802.15.4 &q= uot;short
=C2=A0 =C2=A0address") it MUST be formed by padding the MS/TP address = to the left
=C2=A0 =C2=A0with a zero:

Similarly, this would read more smoothly if "a zero" was "a = zero
octet".

Appendix B.=C2=A0 Consistent Overhead Byte Stuffing [COBS]

=C2=A0 =C2=A0The minimum overhead of COBS is one octet per encoded field.= =C2=A0 The
=C2=A0 =C2=A0worst-case overhead in long fields is bounded to one octet per= 254,
=C2=A0 =C2=A0or less than 0.4%, as described in [COBS].

This could be more informative as:

=C2=A0 =C2=A0The minimum overhead of COBS is one octet per encoded field, a= nd
=C2=A0 =C2=A0the maximum overhead is ceiling(length/254) octets.=C2=A0 In t= he limit
=C2=A0 =C2=A0for very long fields, the overhead is less than 0.4%.=C2=A0 Fo= r 1280
=C2=A0 =C2=A0octet fields, the overhead is 0.47% and for 1500 octet fields,= the
=C2=A0 =C2=A0overhead is 0.39%.

<kel= >
I punted on calculating percentages, assuming the reader cou= ld do the math.
I guessing it varies discretely between 50% for a= 1-byte field and 0.39% for
a 254 byte field.=C2=A0 The salient f= act is the overhead is bounded to six bytes of
overhead for a 150= 0-byte MTU, but maybe I need to say that explicitly.
</kel>= =C2=A0

Appendix C.=C2=A0 Encoded CRC-32K [CRC32K]

=C2=A0 =C2=A0BACnet [Addendum_an] specifies the CRC-32K (Koopman) polynomia= l.

"CRC-32K" is not bound at this point.=C2=A0 Perhaps

=C2=A0 =C2=A0BACnet [Addendum_an] specifies one of these, the CRC-32K (Koop= man)
=C2=A0 =C2=A0polynomial.

<kel>
I'= ;m pretty sure I incorporated all of your editorial changes.
<= /kel>

Thanks again, Kerry
=C2=A0
Dale

--001a1149526cc37c9b05498af2a2-- From nobody Mon Feb 27 14:54:00 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C59129459; Mon, 27 Feb 2017 14:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PtJKWvsUWV6u; Mon, 27 Feb 2017 14:53:40 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC7612944F; Mon, 27 Feb 2017 14:53:40 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id x10so62129843otb.1; Mon, 27 Feb 2017 14:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bIg/kPEbjG9Ry69WjQqwc1E0Wr7Dq06JmblcbQh27ww=; b=cfINvipwTYCwBxvHBcEmnBS2R9gVggawrz+Y0OZtqvflnx+BS30U8UxV+Z9RmyZ+d3 CSPBL0Lck9QIM398SHfy+vaShAhET1r0ljkqgdNTu1wXBVopkRHfW5BoXMspBZKDNqf3 RumMDiaQBGuh7GABN6Hw6TvOdw94MszvQ5ehlMT23/0a69SbTd+4liJZnfxfy4echTB5 vC7STU9Mng6XszZ/2jLbRZlONBcgVjzq+OadO1oRCcYfeD+reJemq3MHGbhsFeJS7eKs a8cmgb5EzQ6avOOGir18Fu62AxrshOPp2sdbPbs6U2WuI1UFuUb6h7J4dKGBCmKLdhwZ qdYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bIg/kPEbjG9Ry69WjQqwc1E0Wr7Dq06JmblcbQh27ww=; b=R3r8A7MT9/tRKVFeydMY0SpNlk9yzuJtSRMN7WaK3vhDxXQ1D+Jd2RDrjiWGkWZISg T19Fr7Gnej+bUSmwKo1bcedJlYU0JGS35U+U4f7Di2IXQfIC0o3OYjOKo1FOnxxhJt9s f4Rab62Ve3FCDztQyqq3bi00c1oQi4NnnAZrWHt4a5J/b7xpS17+49hvfhaqa7tgw40W /3ew3fM8ty/NwM/YllqiH8BxCkAODYJoTGpcJ79tmyWnoqUKEkkDUnuYTt67MkSShuP8 YQYQxW+J7h+EQYbfwUOKday0SZ+iYteQ36ebgvf+WaeKgkORHkd6HTZnsW4SVKNgtd3q jitg== X-Gm-Message-State: AMke39n1w4FM3XTRb8PrU8Pbj+1xQEel10eqxRkqEG0cN6+mS0c1NuEO1+xHbVil1TWsBz+o/ORAhKkGtLV5DA== X-Received: by 10.157.33.181 with SMTP id s50mr10895555otb.15.1488236020043; Mon, 27 Feb 2017 14:53:40 -0800 (PST) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.182.217.38 with HTTP; Mon, 27 Feb 2017 14:53:39 -0800 (PST) In-Reply-To: <148052358314.2961.7757929872750287025.idtracker@ietfa.amsl.com> References: <148052358314.2961.7757929872750287025.idtracker@ietfa.amsl.com> From: Kerry Lynn Date: Mon, 27 Feb 2017 17:53:39 -0500 X-Google-Sender-Auth: 9gzOvni5VyfB69OtzRtjmwRec3I Message-ID: To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a1147f2c851156f05498af3b9 Archived-At: Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG , draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-6lobac-06: (with DISCUSS and COMMENT) X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:53:43 -0000 --001a1147f2c851156f05498af3b9 Content-Type: text/plain; charset=UTF-8 Hi Alissa, Thanks for your review. Sorry it has taken to long to get back to you. Comments inline... On Wed, Nov 30, 2016 at 11:33 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-6lo-6lobac-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 12 says: > > "For this reason, it is RECOMMENDED that a different (but stable) IID be > generated for each globally scoped address in use according to, for > example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]." > > I have a couple of questions about this recommendation that should be > easy to clear up. First, do you really mean "different" IID? EUI-64 > identifiers are different from each other, but embedding one in an IID > still leaves you susceptible to address scanning attacks. Maybe what is > meant here is "semantically opaque" or "with maximum supportable entropy" > or something along those lines? > > I've added text that distinguishes between "MAC-address-derived" and "semantically opaque" IIDs. The first is formed from the dynamically assigned 8-bit MS/TP node address and is recommended for link-local traffic (which is likely the only type of traffic for many deployments). "Semantically opaque" IIDs having 64 bits of entropy are strongly recommended for forming globally scoped addresses. Section 12 recommends a different such IID for each routable address in use. Second, what is meant by the word "stable" here? The mechanisms cited > offer a variety of different "stability" spans -- DHCP lease lifetime, > temporary address lifetime, lifetime of connection to a link, etc. So > it's not clear what is actually being recommended or if the cited > mechanisms all provide the desired property. > > Section 12 now references RFC 8065, which distinguishes between "stable" and "temporary" addresses - the former typically employed by servers and the latter by clients. Section 12 recommends the latter be changed "frequently" but doesn't go into details (implying you should read RFC 8065 for guidance). The point of changing global addresses frequently is to mitigate address scanning attacks. The analysis in RFC 8065 Section 2 could have been presented as (number of trials to 0.5 probability of a "hit") X (time per trial). The number of trials to 0.5 probability of a hit can be modeled as between an urn without replacement (in the case of a stable address) to an urn with replacement (in the limit, where the address changes with each new connection). > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I mostly understand why Sections 6 and 12 are specified as they are but > there are a couple of points of departure from > draft-ietf-6lo-privacy-considerations and draft-ietf-6man-default-iids > that I'd like to discuss. > > (1) draft-ietf-6man-default-iids says that the choice of address > generation mechanism should be configurable when a mechanism is specified > to embed a link layer address in an IID. Is there a reason that doesn't > apply here? The document doesn't say anything about it for the link-local > case. > > I have been trying to follow RFC 8064, but not too successfully. I'm under the impression that it only applies to situations where the guidance is that a link-layer derived IID is used in a globally scoped address? 6LoBAC strongly recommends the use of semantically opaque IIDs for such addresses. > (2) draft-ietf-6lo-privacy-considerations says: > > "Specifications should make sure that an IPv6 address can change > over long periods of time. For example, the interface identifier > might change each time a device connects to the network (if > connections are short), or might change each day (if connections > can be long). This is necessary to mitigate correlation over > time." > > This document doesn't seem to provide any guidance about supporting the > ability to change an IPv6 address within the life span of a long-lived > attachment to the same physical network. Some of the mechanisms cited in > Section 12 provide this and some do not. I appreciate that correlation of > activities over time isn't perceived to be a huge threat here, but aren't > there cases where being able to change an address despite remaining > attached to the same physical network would be desirable? That seems > worth some guidance for nodes that want to support it. > > The guidance is that "temporary" globally scoped addresses should change frequently. An issue arises with MAC-address-derived IIDs used to form link-local addresses. It is quite typical that the address of an MS/TP device is selected by DIP switches and then the device is placed e.g. in the ceiling for an extended period (ideally years). For this to present a correlation of activities over time risk, the link-local address would a) have to leak offlink, and b) be correlated with a temporary globally scoped address that is changing frequently. Does this scenario pose a serious concern? If so, I think the best guidance that can be offered is to not let link-local addresses leak. This is unlikely in the first place, as MS/TP devices are usually quite constrained and all the bytes in flash are accounted for (thermostats don't typically send email). Thanks again, Kerry --001a1147f2c851156f05498af3b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa,

Thanks for your review.=C2= =A0 Sorry it has taken to long to get back to you.
Comments inlin= e...


On Wed, Nov 30, 2016 at 11:33 AM, Alissa Cooper &= lt;alissa@cooperw.in= > wrote:
Alissa Cooper has = entered the following ballot position for
draft-ietf-6lo-6lobac-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-6lo-6lobac/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Section 12 says:

"For this reason, it is RECOMMENDED that a different (but stable) IID = be
=C2=A0 =C2=A0generated for each globally scoped address in use according to= , for
=C2=A0 =C2=A0example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC72= 17]."

I have a couple of questions about this recommendation that should be
easy to clear up. First, do you really mean "different" IID? EUI-= 64
identifiers are different from each other, but embedding one in an IID
still leaves you susceptible to address scanning attacks. Maybe what is
meant here is "semantically opaque" or "with maximum support= able entropy"
or something along those lines?

<kel>
I've added text that distin= guishes between "MAC-address-derived" and
"semanti= cally opaque" IIDs.=C2=A0 The first is formed from the dynamically
assigned 8-bit MS/TP node address and is recommended for link-local<= /div>
traffic (which is likely the only type of traffic for many deploy= ments).

"Semantically opaque" IIDs havin= g 64 bits of entropy are strongly
recommended for forming globall= y scoped addresses.=C2=A0 Section 12
recommends a different such = IID for each routable address in use.
</kel?
=C2=A0<= /div>
Second, what is meant by the word "stable" here? The mechanisms c= ited
offer a variety of different "stability" spans -- DHCP lease life= time,
temporary address lifetime, lifetime of connection to a link, etc. So
it's not clear what is actually being recommended or if the cited
mechanisms all provide the desired property.

<kel>
Section 12 now references RFC 8= 065, which distinguishes between "stable"
and "tem= porary" addresses =C2=A0- the former typically employed by servers and=
the latter by clients.=C2=A0 Section 12 recommends the latter be= changed
"frequently" but doesn't go into details (= implying you should read RFC 8065
for guidance).

The point of changing global addresses frequently is to mitigate a= ddress
scanning attacks.=C2=A0 The analysis in RFC 8065 Section 2= could have been
presented as (number of trials to 0.5 probabilit= y of a "hit") X (time per trial).
The number of trials = to 0.5 probability of a hit can be modeled as between
an urn with= out replacement (in the case of a stable address) to an urn with
= replacement (in the limit, where the address changes with each new
connection).
</kel>

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I mostly understand why Sections 6 and 12 are specified as they are but
there are a couple of points of departure from
draft-ietf-6lo-privacy-considerations and draft-ietf-6man-default-iids=
that I'd like to discuss.

(1) draft-ietf-6man-default-iids says that the choice of address
generation mechanism should be configurable when a mechanism is specified to embed a link layer address in an IID. Is there a reason that doesn't=
apply here? The document doesn't say anything about it for the link-loc= al
case.

<kel>
I have been trying to follow RF= C 8064, but not too successfully.=C2=A0 I'm under
the impress= ion that it only applies to situations where the guidance is that
a link-layer derived IID is used in a globally scoped address? =C2=A06LoBA= C
strongly recommends the use of semantically opaque IIDs for suc= h addresses.
</kel>
=C2=A0
(2) draft-ietf-6lo-privacy-considerations says:

"Specifications should make sure that an IPv6 address can change
=C2=A0 =C2=A0 =C2=A0 over long periods of time.=C2=A0 For example, the inte= rface identifier
=C2=A0 =C2=A0 =C2=A0 might change each time a device connects to the networ= k (if
=C2=A0 =C2=A0 =C2=A0 connections are short), or might change each day (if c= onnections
=C2=A0 =C2=A0 =C2=A0 can be long).=C2=A0 This is necessary to mitigate corr= elation over
=C2=A0 =C2=A0 =C2=A0 time."

This document doesn't seem to provide any guidance about supporting the=
ability to change an IPv6 address within the life span of a long-lived
attachment to the same physical network. Some of the mechanisms cited in Section 12 provide this and some do not. I appreciate that correlation of activities over time isn't perceived to be a huge threat here, but aren= 't
there cases where being able to change an address despite remaining
attached to the same physical network would be desirable? That seems
worth some guidance for nodes that want to support it.

<kel>
The guidance is that "temp= orary" globally scoped addresses should change
frequently.= =C2=A0 An issue arises with MAC-address-derived IIDs used to form
link-local addresses.=C2=A0 It is quite typical that the address of an MS/= TP device
is selected by DIP switches and then the device is plac= ed e.g. in the ceiling
for an extended period (ideally years).=C2= =A0 For this to present a correlation of
activities over time ris= k, the link-local address would a) have to leak offlink,
and b) b= e correlated with a temporary globally scoped address that is
cha= nging frequently.

Does this scenario pose a seriou= s concern?=C2=A0 If so, I think the best guidance
that can be off= ered is to not let link-local addresses leak.=C2=A0 This is unlikely
<= div>in the first place, as MS/TP devices are usually quite constrained and = all
the bytes in flash are accounted for (thermostats don't t= ypically send email).
</kel>

Thanks again, Kerry
--001a1147f2c851156f05498af3b9-- From nobody Tue Feb 28 10:52:50 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE56129682 for <6lo@ietfa.amsl.com>; Tue, 28 Feb 2017 10:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 LMSDxcH9DK3E for <6lo@ietfa.amsl.com>; Tue, 28 Feb 2017 10:52:49 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6622F12967F for <6lo@ietf.org>; Tue, 28 Feb 2017 10:52:49 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-12v.sys.comcast.net with SMTP id imqzcnSY3CGpRimtEc7t3m; Tue, 28 Feb 2017 18:52:48 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-06v.sys.comcast.net with SMTP id imtCccwy5oqz9imtDcZ86z; Tue, 28 Feb 2017 18:52:48 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1SIqj2W032447; Tue, 28 Feb 2017 13:52:45 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1SIqjDi032444; Tue, 28 Feb 2017 13:52:45 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Kerry Lynn In-Reply-To: (kerlyn@ieee.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 28 Feb 2017 13:52:45 -0500 Message-ID: <87wpcajgg2.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBpORgYfZ059naQc8GnNOvEEJpWlj7Pm5iEWjb5YGC3KpyT+N4mXwss3C4hkpU8VmOAtTXHOwALm8wCiF7RLU0wyzZoCEcqCREmYw4Py7fRc7Aoplgjk 1Srr6f+/ArEwqfTm2rRtj6wyshQ+G+RvNT6DwLY7hB8zllOXileHlf0x/sWPuIWGam/30XP0nJauhxTa3JkPqG93LogdtBHWeynSvR4FCOln1sjSWN5RuQYR eiwFZMN89amZfRlZQwygOw== Archived-At: Cc: ietf@ietf.org, draft-ietf-6lo-6lobac@ietf.org, 6lo@ietf.org Subject: Re: [6lo] Last Call: (Transmission of IPv6 over MS/TP Networks) to Proposed Standard X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 18:52:50 -0000 Kerry Lynn writes: > Thanks for your thorough review of draft-ietf-6lo-6lobac. Sorry that > it has taken so long to get back to you. Can you take a look at the > new version and see if it addresses your concerns? Comments inline... Yes, the -07 cleans up all my concerns. > Section 6 has been reworked to more clearly distinguish between two types > of IIDs: "MAC-address-derived" and "semantically opaque". The first is > recommended for link-local addresses because it enables maximum IPv6 > header compression efficiency. Since MS/TP is used primarily as a field > bus, I expect most installations will only ever involve link-local traffic > between an MS/TP device and a local controller. > > For applications where the MS/TP device is a client or server with routable > addresses, the spec strongly recommends generating a semantically opaque > IID, with 64 bits of entropy, for each global address. Ah, yes, that's the distinction that makes it clear. > ANSI/ASHRAE Standard 135-2016 was published late last year. This > version integrates the changes that were standardized in 135-2012 > Addendum an, so there's no longer any jumping back and forth between > references. And so you simplified the references to Std. 135 . Dale From nobody Tue Feb 28 14:55:14 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68874129412; Tue, 28 Feb 2017 14:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8O9k6TwgfinV; Tue, 28 Feb 2017 14:55:12 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114F5129409; Tue, 28 Feb 2017 14:55:12 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id k4so18215979otc.0; Tue, 28 Feb 2017 14:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KV7dOqoqvuBqCn4o2dsvL5Oj4IFYtDQoNCj0Kcusnpo=; b=R8lioaOHpVzxwJd7KkzbxEftI7uBQrNaxbCykjgfgkwcEevGWFF8lAVFWeKIwKHjAi unTZ7Bg5O1pcxqN6NyTaMSoBulHRPWBurrQrshL3hfpDuqE6LdoBe8CrcqT1zIJFSIrE 6gZQPqQslPW7QS4h2ajejvvPqiTDtt724YxC9hqqHaz5pP0YFjsEfYTiujY9l57QChZ1 TUsptDIPFfcF+QWMF5CXg9MmAUq3EDftm3cR0/6tBM714wPvV+qf3hzvcd86UneJdmyC g6ez2QoxhdcK2PwVR+7REF0swwf2d3ZHuxsCyM0JbVDGXsMaBx9uGS1RLE9azn73W/7V WbVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KV7dOqoqvuBqCn4o2dsvL5Oj4IFYtDQoNCj0Kcusnpo=; b=gcqrZS3H4tzdiaLdCMHdvp/CIxP+AhwU2v5qyL0qfyvHsC/QQn49l5oo0zufdswOut JvXzlWb1Ig4Sr0bkupcTAJuhSmIVV5cQsh/klsagtBdssUw0UtRoHQhkEQfExFbPIdHR QAuUmHNGY402q5YSxP4s6jaAPxeKFX+Z8Ukn4vbsDmq8EmQXoRd0HCEWtXsbjTVRpNex CmQThnkuJokWtSvVfPSQPsbOqfA/54J6ZkLW5ifwgaSES49/no5k6gkglX3azppGERsI oFnNxvNlaG4R+p6NTf8xxT336awfbmCvLg6VqQN+5DigzuFEKwekGFFgnhFjNAhF8NuB nkyA== X-Gm-Message-State: AMke39kzJAe0gLiMZwZujPDWJPXM96vCIRznLV76cmQrTJROrFNpwRfZIv52kUPCgJdT0crQjbC86jDLAqOazQ== X-Received: by 10.157.27.154 with SMTP id z26mr2752987otd.181.1488322511474; Tue, 28 Feb 2017 14:55:11 -0800 (PST) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.182.217.38 with HTTP; Tue, 28 Feb 2017 14:55:11 -0800 (PST) In-Reply-To: <148046235620.11752.2233031007089619864.idtracker@ietfa.amsl.com> References: <148046235620.11752.2233031007089619864.idtracker@ietfa.amsl.com> From: Kerry Lynn Date: Tue, 28 Feb 2017 17:55:11 -0500 X-Google-Sender-Auth: RjK11plbJ99Gg4Jysz-rk1JLWZE Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113e026c9b959b05499f16f3 Archived-At: Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG , draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti Subject: Re: [6lo] Alia Atlas' No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT) X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:55:13 -0000 --001a113e026c9b959b05499f16f3 Content-Type: text/plain; charset=UTF-8 Hi Alia, Thanks for your review. Comments inline... On Tue, Nov 29, 2016 at 6:32 PM, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-6lo-6lobac-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Appendix B, given that there is code, it would be good to specifically > mark it as such. As I recall, there are different copyright aspects to > the code fragments in an RFC than to the text. I believe that > https://www.ietf.org/iesg/statement/copyright.html provides pointers to > the implications and encourages marking the code segments with > and . > > > Done. Thanks again, Kerry --001a113e026c9b959b05499f16f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,

Tha= nks for your review.=C2=A0 Comments inline...

On Tue, Nov 29, 2016 at 6:32 PM, Al= ia Atlas <akatlas@gmail.com> wrote:
Alia Atlas has entered the following ballot p= osition for
draft-ietf-6lo-6lobac-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-6lo-6lobac/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

In Appendix B, given that there is code, it would be good to specifically mark it as such.=C2=A0 As I recall, there are different copyright aspects t= o
the code fragments in an RFC than to the text.=C2=A0 I believe that
https://www.ietf.org/iesg/statement/copyright= .html=C2=A0 provides pointers to
the implications and encourages marking the code segments with
<CODE_BEGINS> and <CODE_ENDS>.


Done.

Thanks again, Kerry
=C2=A0


--001a113e026c9b959b05499f16f3-- From nobody Tue Feb 28 14:55:36 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC22129412; Tue, 28 Feb 2017 14:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iL2Lx9jwrRoc; Tue, 28 Feb 2017 14:55:24 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956A3129409; Tue, 28 Feb 2017 14:55:24 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id m124so13817307oig.1; Tue, 28 Feb 2017 14:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cNuRZk5336L1RR9VSb+4Uubueen1WmzgL15k4mPsos8=; b=EQeQAth/+ik0SjrJUsCPkNr/+YXbKtDL8Ng3dwKKBGwAlY5ehAjJWrwPyMMo7n2Sdg 099SYEZav36erbcU9Pqozit6vsrtWb660Puf3dOj30N/tqatWzQpPNJtoXBPvp03b+dj sVt23S2L+PXXcyVosaXyww5AtVHWtaVcKij6D+FdNb9I5TL2FHp8AS4AmAuOQwYtwSo7 gZTO3UeR/EbFTY/qjZo3mkXCCq2AgkAfV4051UO3t0brnN14yZdMYyTSgbznMkmBjle4 Dh7eD5eOtEeceloiaYq1+K4kwUe6yerJGc3LzWN8RFMJZeAdOMvM4asGkWDhNI+grpOu LljQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cNuRZk5336L1RR9VSb+4Uubueen1WmzgL15k4mPsos8=; b=d5LOU47CVyrfvJ0kQUVatI+LIz1Waw8KmLzk5h8GTYd2HQVXCDBbG3m16+OWSJIYc7 4YnFDOqaIywfMii4rqjHdTIIhn2Wt3d1Xl/4loB0Tz7jtqAELwp0patg6Sc87fiQfB5P yLK1GkcepiVwFtOzvygSxyeAPxB72imlbOYgRBZYG0grB9GzFInqtGBxgpt7UAN1vCSI Gl7UCnDuCrPFm2eNS3F9y3NkXWD/N/34qDR1RPxjQs7oyhe1JoL+6KrzP2qqywJ1r4Ww hise4xFCGx27Os0McknaFE8DxNQbxI3h87IeIkOXFHcbqlZGJzQp7nBofFcfFgmwfkEs aHyQ== X-Gm-Message-State: AMke39nKCGDi0FXtu1FZ+3JDJ9n/IQ6fqEHuUOgdZwoDeXGHEQc1GDu++2O7vHevc/UA/6KkNOJiK5LHQLcrwA== X-Received: by 10.202.8.201 with SMTP id 192mr2228388oii.6.1488322523844; Tue, 28 Feb 2017 14:55:23 -0800 (PST) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.182.217.38 with HTTP; Tue, 28 Feb 2017 14:55:23 -0800 (PST) In-Reply-To: <148046209788.11736.10660684548298111998.idtracker@ietfa.amsl.com> References: <148046209788.11736.10660684548298111998.idtracker@ietfa.amsl.com> From: Kerry Lynn Date: Tue, 28 Feb 2017 17:55:23 -0500 X-Google-Sender-Auth: jQCbL-7Tlz-_ZsnO_IU96oTtmYM Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c12f984585ad705499f173e Archived-At: Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG , draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti Subject: Re: [6lo] Ben Campbell's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT) X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:55:31 -0000 --94eb2c12f984585ad705499f173e Content-Type: text/plain; charset=UTF-8 Hi Ben, Thanks for your review. Comments inline... On Tue, Nov 29, 2016 at 6:28 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-6lo-6lobac-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive: > > - 1.3 Do I undertand correctly that this section is strictly an overview > of something described elsewhere? If so, I am surprised to find the MUSTs > in the the 5th paragraph from the end of the section. > > I failed to communicate to reviewers outside of 6lo wg that I can provide a copy of [BACnet] Clause 9, if requested. The issue is that Clause 9 describes different types implementations, so it's necessary to spell out in this ID which features are required to implement IPv6 over MS/TP (6LoBAC). I have recast section 2 as a profile for 6LoBAC, partly to answer the concerns of the OPSDIR review. The question is whether it can/should contain RFC 2119 language? For example, [BACnet] Clause 9 specifies that 9600 bps is mandatory and all other rates are optional, but 6LoBAC requires that 115.2 Kbps be supported. Having said that, I see that I missed removing a "must" from 1.3 and will do that next round. - 2 and 3 also have some MUSTs that seem to describe MS/TP nodes in > general--are those new requirements described in this spec, or existing > requirements? (If the later, please consider stating them without 2119 > keywords.) > > As above. If I understand your point, the correct division is between what is specified in the 6LoBAC adaptation layer and what is required below the MAC i/f. So sections 2 & 3 still have some 2119 keywords that should be eliminated. This just means lower-casing them where used, right? -6, 2nd paragraph: Why is the SHOULD NOT not a MUST NOT? What is the > consequences of ignoring the SHOULD NOT? > > This section was re-worked and the offending paragraph removed (at least one other reviewer found it confusing). - 12, 2nd paragraph: "MS/TP networks are by definition wired and not > susceptible to casual > eavesdropping. " > I think this depends on too many factors to state this broadly. It may be > easier to eves drop on an unprotected piece of wire than, say, an > encrypted wireless link. > > Point taken; easier to remove it than defend it. > - 14.2: [EUI-64] and [I-D.ietf-6lo-privacy-considerations] seem to be > cited normatively. > > The EUI-64 reference has been removed and the Section 12 reference to RFC 8064 has been reworked a bit. Is the latest version satisfactory? (I know it still says [I-D.ietf-6lo-privacy-considerations]; that will be fixed in the next version) Editorial: > - 4: Please expand MSDU > > Done. Thanks again, Kerry --94eb2c12f984585ad705499f173e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks for your review.=C2=A0 C= omments inline...

On Tue, Nov 29, 2016 at 6:28 PM, Ben Campbell <<= a href=3D"mailto:ben@nostrum.com" target=3D"_blank">ben@nostrum.com>= wrote:
Ben Cam= pbell has entered the following ballot position for
draft-ietf-6lo-6lobac-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-6lo-6lobac/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Substantive:

- 1.3 Do I undertand correctly that this section is strictly an overview of something described elsewhere? If so, I am surprised to find the MUSTs in the the 5th paragraph from the end of the section.

<kel>
I failed to communicate to revi= ewers outside of 6lo wg that I can provide a
copy of [BACnet] Cla= use 9, if requested.

The issue is that Clause 9 de= scribes different types implementations, so it's
necessary to= spell out in this ID which features are required to implement
IP= v6 over MS/TP (6LoBAC).=C2=A0 I have recast section 2 as a profile for 6LoB= AC,
partly to answer the concerns of the OPSDIR review.=C2=A0 The= question is whether
it can/should contain RFC 2119 language?=C2= =A0 For example, [BACnet] Clause 9
specifies that 9600 bps is man= datory and all other rates are optional, but
6LoBAC requires that= 115.2 Kbps be supported.

Having said that, I see = that I missed removing a "must" from 1.3 and will
do th= at next round.
</kel>

- 2 and 3 also have some MUSTs that seem to describe MS/TP nodes in
general--are those new requirements described in this spec, or existing
requirements? (If the later, please consider stating them without 2119
keywords.)

<kel>
As above.=C2=A0 If I understand= your point, the correct division is between what
is specified in= the 6LoBAC adaptation layer and what is required below the
MAC i= /f.=C2=A0 So sections 2 & 3 still have some 2119 keywords that should b= e
eliminated.=C2=A0 This just means lower-casing them where used,= right?
</kel>

-6, 2nd paragraph: Why is the SHOULD NOT not a MUST NOT? What is the
consequences of ignoring the SHOULD NOT?

<kel>=C2=A0
This section was re-worke= d and the offending paragraph removed (at
least one other reviewe= r found it confusing).
</kel>

- 12, 2nd paragraph: "MS/TP networks are by definition wired and not susceptible to casual
=C2=A0 =C2=A0eavesdropping. "
I think this depends on too many factors to state this broadly. It may be easier to eves drop on an unprotected piece of wire than, say, an
encrypted wireless link.

<kel>
Point taken; easier to remove i= t than defend it.
</kel>
=C2=A0
- 14.2: [EUI-64] and [I-D.ietf-6lo-privacy-considerations] seem to be<= br> cited normatively.

<kel>
=C2=A0The EUI-64 reference has = been removed and the Section 12 reference
to RFC 8064 has been re= worked a bit.=C2=A0 Is the latest version satisfactory?
(I know i= t still says [I-D.ietf-6lo-privacy-considerations]; that will be fixed=
in the next version)
</kel>

=
Editorial:
- 4: Please expand MSDU

Done.

=
Thanks again, Kerry=C2=A0

--94eb2c12f984585ad705499f173e-- From nobody Tue Feb 28 14:55:57 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6B812942F; Tue, 28 Feb 2017 14:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MD9-UgeIpNwI; Tue, 28 Feb 2017 14:55:36 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDD712940E; Tue, 28 Feb 2017 14:55:36 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id x10so18241527otb.1; Tue, 28 Feb 2017 14:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UrxBAuuKrbtYXiTIaubg96ZlnB5iCq7fTlLmeSKsFW0=; b=Y8oS+QoBXj1mWbamywnQuLmjpGO5L8zU26GXmjmhQu9ExaJZ/ynvPi7g9PcPFdVzlt PEy3xm/bZM3rMFgl9As6Cg0VZfYHPNXNjgR0pkWun5UAp8NOYrgvDvJuMEs0kA02cFUw U2LPupseRk868cpTOQxEUBRNIHSp/SD8TU9LYbauF+gUiE11Paic94XzeqOx/bVy4+q2 y5b3qCLN5tJvKrkJ2a3fzBy8G+WvWXjwwg+k6IFpftNBC2JP9SIw+RYqGPCv9yDM8M6Y YWZNMR09tc0twH8ywNVUQqITIhCS1DLAPy3pa5l7WO+NBRVLi6HHDvZTj0ahi+8AVNVl oV9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UrxBAuuKrbtYXiTIaubg96ZlnB5iCq7fTlLmeSKsFW0=; b=SQUhkPPJjDxTfrH2/myCW0YlwIZOGD3xMvV5sznED4q/bEkHIZTYj1TZDgrsfXEge1 YQCeV5eZW4ugm7siWKTowLQ2sJTulCK74Iz1EWhJdSc7Tl5ANINGy55OmFL1Jg+mkZnZ Vw2MRa/maqJOU8PhYV638TPLm3k6aLpebYv4ODdpJng0+6FOll/Az+BQwvH5KoDGSwX1 7A8lVPs3QRgDZt5dy/GR9LOV2zkNfDJZcow0BmXuywaTnv1kRAi1z9ZS/0xlbGhWpsnZ vXxMTKZkAHimpvKUCR9Ly11rYJdhvwtUWcsdACYaS3ZkZviSLtJT+gUiiVPLDbZXLzHR 101w== X-Gm-Message-State: AMke39nQjRVrF0Apkp9dj970zPNj1d+7H+tsVetW1hpj9H1Q610opUk74uOKqUJno/oIGnLuYy7R04hRjpx1TA== X-Received: by 10.157.17.17 with SMTP id g17mr2487649ote.138.1488322535811; Tue, 28 Feb 2017 14:55:35 -0800 (PST) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.182.217.38 with HTTP; Tue, 28 Feb 2017 14:55:35 -0800 (PST) In-Reply-To: <148049464851.6756.15999062513580049117.idtracker@ietfa.amsl.com> References: <148049464851.6756.15999062513580049117.idtracker@ietfa.amsl.com> From: Kerry Lynn Date: Tue, 28 Feb 2017 17:55:35 -0500 X-Google-Sender-Auth: QGtozSUk1Jw37kFJmb0Rmc_MOiQ Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113d00d60ef2bc05499f18bc Archived-At: Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG , draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti Subject: Re: [6lo] Stephen Farrell's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT) X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:55:38 -0000 --001a113d00d60ef2bc05499f18bc Content-Type: text/plain; charset=UTF-8 Hi Stephen, Thanks for your review. Comments inline... On Wed, Nov 30, 2016 at 3:30 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-6lo-6lobac-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 1.3: "cost effective" and similar marketing language is > better avoided. I'd say deleting that sentence is better. > > Done. > - section 5: It's not clear to me why the 115k data rate > "dictates" header compression to reduce latency. I'm not > doubting that it might, but it's not clear from what's > stated that it does. > > Removed. The I-D now requires header compression without rationale, though it's mentioned in passing that header compression improves link utilization. > - Appendices B/C: I'm not clear how these are not part of > the standard. I think what you mean is that the code is > not, but the algorithms in fact are in fact necessary to > implement this. (I also agree with Alia's suggestion to add > the IETF trust stuff, assuming that's not > problematic.) > I failed to communicate to reviewers outside of 6lo wg that I can provide a copy of [BACnet] Clause 9, if requested. The I-D by itself is not sufficient to implement 6LoBAC; one would have to acquire the BACnet standard. However, I've tried to summarize enough of the standard so that a reader of the I-D can at least understand the complete packet format without needing the standard. The information in the Appendices is for that purpose. Thanks again, Kerry --001a113d00d60ef2bc05499f18bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks for your review.=C2= =A0 Comments inline...

On Wed, Nov 30, 2016 at 3:30 AM, Stephen Farrell <steph= en.farrell@cs.tcd.ie> wrote:
Stephen Farrell has entered the following ballot posit= ion for
draft-ietf-6lo-6lobac-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-6lo-6lobac/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----


- 1.3: "cost effective" and similar marketing language is
better avoided. I'd say deleting that sentence is better.

Done.
=C2=A0
- section 5: It's not clear to me why the 115k data rate
"dictates" header compression to reduce latency. I'm not
doubting that it might, but it's not clear from what's
stated that it does.

<kel>
Removed.=C2=A0 The I-D now requ= ires header compression without
rationale, though it's mentio= ned in passing that header compression
improves link utilization.=
</kel>
=C2=A0
- Appendices B/C: I'm not clear how these are not part of
the standard. I think what you mean is that the code is
not, but the algorithms in fact are in fact necessary to
implement this. (I also agree with Alia's suggestion to add
the IETF trust <CODE BEGINS> stuff, assuming that's not
problematic.)
=C2=A0
<kel>
I faile= d to communicate to reviewers outside of 6lo wg that I can
provid= e a copy of [BACnet] Clause 9, if requested.

The I-D by itself is not sufficient to implement 6LoBAC; one
wou= ld have to acquire the BACnet standard.=C2=A0 However, I've
t= ried to summarize enough of the standard so that a reader of
the = I-D can at least understand the complete packet format
without ne= eding the standard.=C2=A0 The information in the Appendices
is fo= r that purpose.
</kel>

Thanks again, Kerry
--001a113d00d60ef2bc05499f18bc-- From nobody Tue Feb 28 14:56:01 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CF7129412; Tue, 28 Feb 2017 14:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kr6ZpoujHgO9; Tue, 28 Feb 2017 14:55:46 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E261129415; Tue, 28 Feb 2017 14:55:45 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id k4so18223309otc.0; Tue, 28 Feb 2017 14:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TnC3plE82ZOvK+RHpz3AoD6GyyWxRWoT+aPtfJxH8r0=; b=XuAhGpXr63TvPdv+PEeYg91YChmK6OQI6sQChg/LkCRvPQ8qvzU0Ltbp/S2lZcfquC P2hRSDHi7k+qx/yyjjNXpXC1YVFYFvAmQ6xDKez7StOjqnLPbF0NdAXI6ATWK3ELfBTo fdni4GchASaX58ChFLinFRKnLyolGj/gIBoYVWYrbl+Q4kEnQcOWXtuiHpEuW9cXRLoa W7PzU/gCeqL8S5hpV7/PA/LnZD7mbQReW5cXZAF4/oXmgJsdvFYg7mVMmWRmJhWClYdw uVPUkPPd6bIIopPUap7NTixTemquYu6+2JI6k2kl3mPe4tTXm1cYvglL3xIf7iOrB7RZ ePuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TnC3plE82ZOvK+RHpz3AoD6GyyWxRWoT+aPtfJxH8r0=; b=Azn5vGIW3/xCBNu4GLtVZIT5qHMjRSDlGJRUZmeC6rTxgeKcTOMKAZf6pDIaPHZwy8 h7v6/+m8CKWYxTh/MrnbFSSDKsc+RiPVvO4PWSpY4u5sDGrQbRxMiSC144stpltJhUgj IjGB2lmEzW7JWJ2eZNkQAghbfqL10FfrV4nfKxQObx+p9mOCdD5VzYZ2jBehPPExAoMA HKswrUWTCFPhPQHNkmkRMPlDqpGCElGUQEAeH+Jg8T7jLXlrmWD0OuqKpy+UDCFeVt39 aBbB9Ezd4gg0tElZvp+RFrMkLBwv54VZ6eXzGQy1SoRb6RDEyl/iYtSmiWpjrw7FBYQf 7qUw== X-Gm-Message-State: AMke39l2I3Far2Wk7Qv+K4SwFNtluQj0X5QzIX92t6BgY5kXuQnKKU+sDOoyAsKvx4DHR3QU36f1F38jHVJQUw== X-Received: by 10.157.20.102 with SMTP id h93mr2335901oth.73.1488322544791; Tue, 28 Feb 2017 14:55:44 -0800 (PST) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.182.217.38 with HTTP; Tue, 28 Feb 2017 14:55:44 -0800 (PST) In-Reply-To: <148052202047.14046.10952186150977815778.idtracker@ietfa.amsl.com> References: <148052202047.14046.10952186150977815778.idtracker@ietfa.amsl.com> From: Kerry Lynn Date: Tue, 28 Feb 2017 17:55:44 -0500 X-Google-Sender-Auth: V-3lSA61534mV-CIql6Nt43j0Mc Message-ID: To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=001a1135adb097f8bd05499f1855 Archived-At: Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG , draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti Subject: Re: [6lo] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-6lo-6lobac-06=3A_=28with_COMMENT=29?= X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:55:48 -0000 --001a1135adb097f8bd05499f1855 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, Thanks for your review. Comments inline... On Wed, Nov 30, 2016 at 11:07 AM, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-6lo-6lobac-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) Agree with Ben that normative wording should not be used if it just > summarizes things that are specified in a different doc. > > See if my response to Ben is satisfactory for you. > 2) Section 5: "A node implementing [RFC7400] MUST probe its peers for GHC > support before applying GHC." How? > > I deleted this sentence. RFC 7400 discusses it. > 3) Just to make sure I get the security section right: MS/TP networks are > not connected to the Internet or use something like a gateway. Maybe make > this point more clear: basically say that the reason to use IPv6 is NOT > that you want to send these packets eventually directly to the Internet! > > Not sure I wanted to create the impression that MS/TP nodes will never connect to the Internet. I reworked Sections 6 & 12 to make clear that different methods of forming addresses are recommended depending on the scope of the address. Thanks again, Kerry --001a1135adb097f8bd05499f1855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Thanks for your review.=C2=A0= Comments inline...

On Wed, Nov 30, 2016 at 11:07 AM, Mirja Kuehlewind <ietf@kuehlew= ind.net> wrote:
Mirja K=C3= =BChlewind has entered the following ballot position for
draft-ietf-6lo-6lobac-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-6lo-6lobac/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

1) Agree with Ben that normative wording should not be used if it just
summarizes things that are specified in a different doc.

See if my response to Ben is satisfactory for you.
=C2=A0
2) Section 5: "A node implementing [RFC7400] MUST probe its peers for = GHC
support before applying GHC." How?

I deleted this sentence.=C2=A0 RFC 7400 discusses it.=
=C2=A0
3) Just to make sure I get the security section right: MS/TP networks are not connected to the Internet or use something like a gateway. Maybe make this point more clear: basically say that the reason to use IPv6 is NOT
that you want to send these packets eventually directly to the Internet!
Not sure I wanted to create the impression that MS/T= P nodes will never
connect to the Internet.=C2=A0 I reworked Sect= ions 6 & 12 to make clear that
different methods of forming a= ddresses are recommended depending on
the scope of the address.

Thanks again, Kerry

--001a1135adb097f8bd05499f1855-- From nobody Tue Feb 28 14:56:15 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8C1297AB; Tue, 28 Feb 2017 14:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 x0n3lmSvQbBN; Tue, 28 Feb 2017 14:55:57 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCE912940E; Tue, 28 Feb 2017 14:55:57 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id i1so18241126ota.3; Tue, 28 Feb 2017 14:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YAzQGkDBxPOIY61us0Qmhshj2r5geDKHK+hi6CJ51d8=; b=niE0aytnBh9FDHV4FUI9SbIm5uf6H0GhzdaAH1SfXuTh+9eEroBOFy1L1uptd1mkaX jVWW4rLq37bdNr5RiIQ0/iwvrd8PGP9hd0LAlw6AkD2RjXdJMuxMHLAuh1+yzWA5ru1u 2emQ1fiyKMDaudc37Ui5AG2chMwvse7L+0PH0orXIhspb0472FO11FPTTScWQyMyFIfF 9JDHexv2K6HECxvD9lvVmuqW+89Wtt9gJ8U86ELLHikgax5UwGcLACh7srzciROA5Z+M CcC0Hqe1SMLXhr1VOn2B7cKfbPSblKHLTfc6vkmnopyt1sCipHV/2id37JhEVC/g7MSF RLlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YAzQGkDBxPOIY61us0Qmhshj2r5geDKHK+hi6CJ51d8=; b=njiU2wuK1OK7F49oolAIWq1BLG6Hp4YWS7svl5kBfWdYrCBfyF5J/LPtDe+1SGjW0g VSe3v6hDnZyYFCofOw2pJAUMHW3PdZUJFaqTZ9sYI415PPaV5RQHxXxZxfZsw7O9dSRw 7zwr7txCpCuWoLCmw6823ouc3BPvdtXaTVSAZxazEbkyjmkquS8JHsOxWS3yCnpFmsWA EF8waKtDTipBHFfu4dj0dzrDGwDhDcG6V2MnbXOcMQgaQDhzIp6mD+RDrc/inqY9z7nn eMkxu9SOPXjGufBPGs/VLLST+0gb8NUGHX0QleGKPJrf1wJAJhKnbo6hIHQMtPOsDO1u fAIQ== X-Gm-Message-State: AMke39mYfFOEprncrG149YzcEJ8mVPN6aRhLx1mVMnb/npMgfMH5WOuKLkCqWPJzrVG7TZKb2m5RDGQq/Ljpow== X-Received: by 10.157.46.41 with SMTP id q38mr2236079otb.134.1488322556349; Tue, 28 Feb 2017 14:55:56 -0800 (PST) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.182.217.38 with HTTP; Tue, 28 Feb 2017 14:55:56 -0800 (PST) In-Reply-To: <148057866865.9634.910157038646776937.idtracker@ietfa.amsl.com> References: <148057866865.9634.910157038646776937.idtracker@ietfa.amsl.com> From: Kerry Lynn Date: Tue, 28 Feb 2017 17:55:56 -0500 X-Google-Sender-Auth: -_k8XcjOaK9b-JTHyAQ5vpVGdck Message-ID: To: Joel Jaeggli Content-Type: multipart/alternative; boundary=001a1139ab0c48569405499f1923 Archived-At: Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG , draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti Subject: Re: [6lo] Joel Jaeggli's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT) X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:55:59 -0000 --001a1139ab0c48569405499f1923 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joel, Thanks for your review. Comments inline... On Thu, Dec 1, 2016 at 2:51 AM, Joel Jaeggli wrote: > Joel Jaeggli has entered the following ballot position for > draft-ietf-6lo-6lobac-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Mahesh Jethanandani performed the opsdir > review > > it would probably be good to discuss these concerns before it gets out > the door. > > I have reviewed this document as part of the Operational directorate=E2= =80=99s > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the operational > aspects of the IETF drafts. Comments that are not addressed in last call > may be included in AD reviews during the IESG review. Document editors > and WG chairs should treat these comments just like any other last call > comments. > > Document reviewed: draft-ietf-6lo-6lobac-06 > > Summary: > > The abstract of the document says =E2=80=9CThis specification defines= the > frame format for transmission of IPv6 packets and the method of forming > link-local and statelessly autoconfigured IPv6 addresses on MS/TP > networks. > This document is on a standards track. > > > Operational Considerations > > Operations. The document does talk about existence of legacy Master > Slave/Token Passing (MS/TP) along with nodes that will implement this new > MS/TP frame format. It says that if these legacy nodes are present, they > will ignore the frame format defined in this specification. It also says > that co-existence with legacy implementations is only a secondary goal. > To enable this, no changes are permitted to the MS/TP addressing modes, > frame header format, control frames, or Master Node state machine. > Section 1.4 has been reworked to promote the importance of co-existence (it allows MS/TP networks to be incrementally upgraded to IPv6). The constraints on making any changes to the L2 frame header are necessary to meet the co-existence goal. > From an operational perspective, everything that can be configured > can also be misconfigured. One way to simplify configuration, would be by > specifying reasonable defaults, including default modes and parameters. > Are there default parameters? If so, what are they? > I expanded Section 2 to include constants and configuration parameters (with default values for the latter) that are required for implementation. The mechanism for changing default values is outside the scope of this I-D. > It appears from the draft that the deployment scenario in > consideration is a green field opportunity. That only nodes that > implement the new MS/TP frame format will be able to communicate with > each other. So there is no consideration outlined for a migration path. > In other words, even though co-existence with legacy implementations is > one of the goals, it is not clear how that will enable a migration from > that implementation to the new format. > This is similar to the way Ethernet and 802.3 frames co-exist on the same media without interoperation. Prior to this work (and I include [Addendum_an]), MS/TP could only be used by the BACnet network layer. As BACnet eventually migrates to IPv6 as the transport, it may be that a mix of old and new BACnet MS/TP devices exist on the same link, in which case they will have to communicate with each other through a router or application layer gateway. But I think this discussion is well outside the scope of the I-D. What 6LoBAC enables is a true green field opportunity; for constrained IPv6 devices running arbitrary applications to use a wired datalink that can reliably cover distances up to 1Km at relatively low cost. > It is also not clear on what the impact if any this new format may > have on existing legacy implementations. For example, for multicast > frames, it states that multicast is not supported in MS/TP. That all > multicast frames are broadcasted at the MAC layer and filtered at the > IPv6 layer. What impact could this have on the nodes that have to process > these multicast packets that are broadcasted to all the nodes? > As stated in Section 1, "If present on the link, legacy MS/TP implementations (including any slave nodes) will ignore the frame format defined in this specification." This is handled by the MS/TP Receive Frame state machine, which includes a SKIP_DATA state. How is the node with the new MS/TP frame format expected to verified > for correct operation? Is it by actively monitoring the node, and if so > what are the elements that can be verified for correct operation. Are > there events generated as part of protocol operations that can be used to > verify its operation? > > My understanding is that management of 6lo hosts is being considered by another WG. Definition of a MIB, etc. is outside the scope of this I-D. I think this applies to most of the questions below... > > Management Considerations: > > Will the nodes with this new MS/TP frame format need to be > configured, or monitored? What are some of the management operations that > are needed? How are these operations performed, e.g. locally, remotely > etc. Where is this management interface defined? > Are there any new faults or health indicators associated with this > new frame formats? How are the alarms and events exposed? Will they be > pushed or do the devices have to be polled? > Similarly, if one of the nodes in the network is not behaving > correctly, how would an operator be able to determine which node it is? > [BACnet] Clause 9 defines Test_Request and Test_Response frame types, which can be used for local loopback tests at L2. > Are there counters maintained by each node that can be monitored to see > what each node is doing? Anything that can be used to do a root cause > analysis, and or fault isolation is helpful. > Are there any performance considerations that an operator should be > aware of with this new frame format? > Certain properties of this new frame format can be useful to monitor. > For example, the number of packets received with the frame format or the > number of packets sent. Are there particular counters that can be used > for monitoring? > > > Accounting Considerations > > Is it appropriate to collect usage information related to this new > frame format? If so, what usage information would be appropriate to > collect? > > > A run of idnits reveals one misc. warning that might be worth looking > at. > > Miscellaneous warnings: > > ------------------------------------------------------------ > ---------------- > > -- Found something which looks like a code comment -- if you have code > sections in the document, please surround them with '' > and > '' lines. > > Done. Thanks again, Kerry > Thanks. > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > > > --001a1139ab0c48569405499f1923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

Thanks for your review.=C2=A0 = Comments inline...

On Thu, Dec 1, 2016 at 2:51 AM, Joel Jaeggli <<= a href=3D"mailto:joelja@bogus.com" target=3D"_blank">joelja@bogus.com&g= t; wrote:
Joel Jaeggli has entered= the following ballot position for
draft-ietf-6lo-6lobac-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-6lo-6lobac/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Mahesh Jethanandani <mjethanandani@gmail.com> performed the opsdir
review

it would probably be good to discuss these concerns before it gets out
the door.

I have reviewed this document as part of the Operational directorate=E2=80= =99s
ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.=C2=A0 Document editor= s
and WG chairs should treat these comments just like any other last call
comments.

Document reviewed:=C2=A0 draft-ietf-6lo-6lobac-06

Summary:

=C2=A0 =C2=A0 The abstract of the document says =E2=80=9CThis specification= defines the
frame format for transmission of IPv6 packets and the method of forming
link-local and statelessly autoconfigured IPv6 addresses on MS/TP
networks.
=C2=A0 =C2=A0 This document is on a standards track.


Operational Considerations

=C2=A0 =C2=A0 Operations. The document does talk about existence of legacy = Master
Slave/Token Passing (MS/TP) along with nodes that will implement this new MS/TP frame format. It says that if these legacy nodes are present, they will ignore the frame format defined in this specification. It also says that co-existence with legacy implementations is only a secondary goal.
To enable this, no changes are permitted to the MS/TP addressing modes,
frame header format, control frames, or Master Node state machine.

<kel>
Section 1.4 has been rewo= rked to promote the importance of co-existence
(it allows MS/TP n= etworks to be incrementally upgraded to IPv6).=C2=A0 The
constrai= nts on making any changes to the L2 frame header are necessary
to= meet the co-existence goal.
</kel>
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =C2=A0 =C2=A0 From an operational perspective, everything that can be confi= gured
can also be misconfigured. One way to simplify configuration, would be by specifying reasonable defaults, including default modes and parameters.
Are there default parameters? If so, what are they?
<kel>
I expanded Section 2 to include constant= s and configuration parameters
(with default values for the latte= r) that are required for implementation.
The mechanism for changi= ng default values is outside the scope of this I-D.
</kel><= /div>
=C2=A0
=C2=A0 =C2=A0 It appears from the draft that the deployment scenario in
consideration is a green field opportunity. That only nodes that
implement the new MS/TP frame format will be able to communicate with
each other. So there is no consideration outlined for a migration path.
In other words, even though co-existence with legacy implementations is
one of the goals, it is not clear how that will enable a migration from
that implementation to the new format.

= <kel>
This is similar to the way Ethernet and 802.3 frames = co-exist on the
same media without interoperation.=C2=A0 Prior to= this work (and I include
[Addendum_an]), MS/TP could only be use= d by the BACnet network
layer.=C2=A0 As BACnet eventually migrate= s to IPv6 as the transport, it may
be that a mix of old and new B= ACnet MS/TP devices exist on the same
link, in which case they wi= ll have to communicate with each other through
a router or applic= ation layer gateway. But I think this discussion is well
outside = the scope of the I-D.

What 6LoBAC enables is a tru= e green field opportunity; for constrained
IPv6 devices running a= rbitrary applications to use a wired datalink that
can reliably c= over distances up to 1Km at relatively low cost.
</kel>
=C2=A0
=C2=A0 =C2=A0 It is also not clear on what the impact if any this new forma= t may
have on existing legacy implementations. For example, for multicast
frames, it states that multicast is not supported in MS/TP. That all
multicast frames are broadcasted at the MAC layer and filtered at the
IPv6 layer. What impact could this have on the nodes that have to process these multicast packets that are broadcasted to all the nodes?

<kel>
As stated in Section 1, "= ;If present on the link, legacy MS/TP implementations
(including = any slave nodes) will ignore the frame format defined in this
spe= cification." =C2=A0This is handled by the MS/TP Receive Frame state ma= chine,
which includes a SKIP_DATA state.
</kel>

=C2=A0 =C2=A0 How is the node with the new MS/TP frame format expected to v= erified
for correct operation? Is it by actively monitoring the node, and if so
what are the elements that can be verified for correct operation. Are
there events generated as part of protocol operations that can be used to verify its operation?

<kel>
My understanding is that manage= ment of 6lo hosts is being considered by
another WG.=C2=A0 Defini= tion of a MIB, etc. is outside the scope of this I-D. =C2=A0I
thi= nk this applies to most of the questions below...
</kel>=C2= =A0

Management Considerations:

=C2=A0 =C2=A0 Will the nodes with this new MS/TP frame format need to be configured, or monitored? What are some of the management operations that are needed? How are these operations performed, e.g. locally, remotely
etc. Where is this management interface defined?
=C2=A0 =C2=A0 Are there any new faults or health indicators associated with= this
new frame formats? How are the alarms and events exposed? Will they be
pushed or do the devices have to be polled?
=C2=A0 =C2=A0 Similarly, if one of the nodes in the network is not behaving=
correctly, how would an operator be able to determine which node it is?
=

<kel>
[BACnet] Clause 9 de= fines Test_Request and Test_Response frame types,
which can be us= ed for local loopback tests at L2.
</kel>
=C2=A0<= /div>
Are there counters maintained by each node that can be monitored to see
what each node is doing? Anything that can be used to do a root cause
analysis, and or fault isolation is helpful.
=C2=A0 =C2=A0 Are there any performance considerations that an operator sho= uld be
aware of with this new frame format?
=C2=A0 =C2=A0 Certain properties of this new frame format can be useful to = monitor.
For example, the number of packets received with the frame format or the number of packets sent. Are there particular counters that can be used
for monitoring?


Accounting Considerations

=C2=A0 =C2=A0 Is it appropriate to collect usage information related to thi= s new
frame format? If so, what usage information would be appropriate to
collect?


A run of idnits reveals one misc. warning that might be worth looking
at.

=C2=A0 =C2=A0 Miscellaneous warnings:

-----------------------------------------------------------------= -----------

=C2=A0 -- Found something which looks like a code comment -- if you have co= de
=C2=A0 =C2=A0 =C2=A0sections in the document, please surround them with = 9;<CODE BEGINS>'
and
=C2=A0 =C2=A0 =C2=A0'<CODE ENDS>' lines.

Done.

Thanks again, Kerry
=C2=A0
Thanks.

Mahesh Jethanandani
mjethanandani@= gmail.com





_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org<= br> https://www.ietf.org/mailman/listinfo/ops-dir<= br>


--001a1139ab0c48569405499f1923-- From nobody Tue Feb 28 15:35:25 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ACD129450; Tue, 28 Feb 2017 15:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 W-nxEKY8jckm; Tue, 28 Feb 2017 15:35:18 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02B2126BF6; Tue, 28 Feb 2017 15:35:18 -0800 (PST) Received: from mbp-4.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v1SNZG1j013047 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 28 Feb 2017 23:35:16 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mbp-4.local To: Kerry Lynn References: <148057866865.9634.910157038646776937.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: <10c84cfe-febe-3c2f-7c97-e54cbeeff913@bogus.com> Date: Tue, 28 Feb 2017 15:35:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="28wQRWQoWVvFIctMvW7rWM5PgjbBEuPgs" Archived-At: Cc: Samita Chakrabarti , 6lo-chairs@ietf.org, The IESG , draft-ietf-6lo-6lobac@ietf.org, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6lo] Joel Jaeggli's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT) X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:35:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --28wQRWQoWVvFIctMvW7rWM5PgjbBEuPgs Content-Type: multipart/mixed; boundary="CQOfhqHPqewM4xJKd1GXJhKbReA12LoQr"; protected-headers="v1" From: joel jaeggli To: Kerry Lynn Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG , draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti Message-ID: <10c84cfe-febe-3c2f-7c97-e54cbeeff913@bogus.com> Subject: Re: Joel Jaeggli's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT) References: <148057866865.9634.910157038646776937.idtracker@ietfa.amsl.com> In-Reply-To: --CQOfhqHPqewM4xJKd1GXJhKbReA12LoQr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, sounds like you have it under control. On 2/28/17 2:55 PM, Kerry Lynn wrote: > Hi Joel, > > Thanks for your review. Comments inline... > > On Thu, Dec 1, 2016 at 2:51 AM, Joel Jaeggli > wrote: > > Joel Jaeggli has entered the following ballot position for > draft-ietf-6lo-6lobac-06: No Objection > > When responding, please keep the subject line intact and reply to a= ll > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here:= > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > > -------------------------------------------------------------------= --- > COMMENT: > -------------------------------------------------------------------= --- > > Mahesh Jethanandani > performed the opsdir > review > > it would probably be good to discuss these concerns before it gets = out > the door. > > I have reviewed this document as part of the Operational directorat= e=E2=80=99s > ongoing effort to review all IETF documents being processed by the > IESG. > These comments were written with the intent of improving the > operational > aspects of the IETF drafts. Comments that are not addressed in > last call > may be included in AD reviews during the IESG review. Document > editors > and WG chairs should treat these comments just like any other last > call > comments. > > Document reviewed: draft-ietf-6lo-6lobac-06 > > Summary: > > The abstract of the document says =E2=80=9CThis specification d= efines the > frame format for transmission of IPv6 packets and the method of > forming > link-local and statelessly autoconfigured IPv6 addresses on MS/TP > networks. > This document is on a standards track. > > > Operational Considerations > > Operations. The document does talk about existence of legacy > Master > Slave/Token Passing (MS/TP) along with nodes that will implement > this new > MS/TP frame format. It says that if these legacy nodes are > present, they > will ignore the frame format defined in this specification. It > also says > that co-existence with legacy implementations is only a secondary > goal. > To enable this, no changes are permitted to the MS/TP addressing > modes, > frame header format, control frames, or Master Node state machine. > > > > Section 1.4 has been reworked to promote the importance of co-existence= > (it allows MS/TP networks to be incrementally upgraded to IPv6). The > constraints on making any changes to the L2 frame header are necessary > to meet the co-existence goal. > > =20 > > From an operational perspective, everything that can be configu= red > can also be misconfigured. One way to simplify configuration, > would be by > specifying reasonable defaults, including default modes and > parameters. > Are there default parameters? If so, what are they? > > > > I expanded Section 2 to include constants and configuration parameters > (with default values for the latter) that are required for implementati= on. > The mechanism for changing default values is outside the scope of this > I-D. > > =20 > > It appears from the draft that the deployment scenario in > consideration is a green field opportunity. That only nodes that > implement the new MS/TP frame format will be able to communicate wi= th > each other. So there is no consideration outlined for a migration > path. > In other words, even though co-existence with legacy > implementations is > one of the goals, it is not clear how that will enable a migration > from > that implementation to the new format. > > > > This is similar to the way Ethernet and 802.3 frames co-exist on the > same media without interoperation. Prior to this work (and I include > [Addendum_an]), MS/TP could only be used by the BACnet network > layer. As BACnet eventually migrates to IPv6 as the transport, it may > be that a mix of old and new BACnet MS/TP devices exist on the same > link, in which case they will have to communicate with each other throu= gh > a router or application layer gateway. But I think this discussion is w= ell > outside the scope of the I-D. > > What 6LoBAC enables is a true green field opportunity; for constrained > IPv6 devices running arbitrary applications to use a wired datalink tha= t > can reliably cover distances up to 1Km at relatively low cost. > > =20 > > It is also not clear on what the impact if any this new format = may > have on existing legacy implementations. For example, for multicast= > frames, it states that multicast is not supported in MS/TP. That al= l > multicast frames are broadcasted at the MAC layer and filtered at t= he > IPv6 layer. What impact could this have on the nodes that have to > process > these multicast packets that are broadcasted to all the nodes? > > > > As stated in Section 1, "If present on the link, legacy MS/TP > implementations > (including any slave nodes) will ignore the frame format defined in thi= s > specification." This is handled by the MS/TP Receive Frame state machi= ne, > which includes a SKIP_DATA state. > > > How is the node with the new MS/TP frame format expected to > verified > for correct operation? Is it by actively monitoring the node, and > if so > what are the elements that can be verified for correct operation. A= re > there events generated as part of protocol operations that can be > used to > verify its operation? > > > My understanding is that management of 6lo hosts is being considered by= > another WG. Definition of a MIB, etc. is outside the scope of this > I-D. I > think this applies to most of the questions below... > =20 > > > Management Considerations: > > Will the nodes with this new MS/TP frame format need to be > configured, or monitored? What are some of the management > operations that > are needed? How are these operations performed, e.g. locally, remot= ely > etc. Where is this management interface defined? > Are there any new faults or health indicators associated with t= his > new frame formats? How are the alarms and events exposed? Will they= be > pushed or do the devices have to be polled? > Similarly, if one of the nodes in the network is not behaving > correctly, how would an operator be able to determine which node > it is? > > > > [BACnet] Clause 9 defines Test_Request and Test_Response frame types, > which can be used for local loopback tests at L2. > > =20 > > Are there counters maintained by each node that can be monitored > to see > what each node is doing? Anything that can be used to do a root cau= se > analysis, and or fault isolation is helpful. > Are there any performance considerations that an operator > should be > aware of with this new frame format? > Certain properties of this new frame format can be useful to > monitor. > For example, the number of packets received with the frame format > or the > number of packets sent. Are there particular counters that can be u= sed > for monitoring? > > > Accounting Considerations > > Is it appropriate to collect usage information related to this = new > frame format? If so, what usage information would be appropriate to= > collect? > > > A run of idnits reveals one misc. warning that might be worth looki= ng > at. > > Miscellaneous warnings: > > -------------------------------------------------------------------= --------- > > -- Found something which looks like a code comment -- if you > have code > sections in the document, please surround them with ' BEGINS>' > and > '' lines. > > Done. > > Thanks again, Kerry > =20 > > Thanks. > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > > > > --CQOfhqHPqewM4xJKd1GXJhKbReA12LoQr-- --28wQRWQoWVvFIctMvW7rWM5PgjbBEuPgs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAli2CS8ACgkQ8AA1q7Z/VrJD+gCfa93YqJ7d1jJ6eQzZBTJk+vMc F44An1M78aq29eEM2/RXKBSgKkDx9yat =C6Yr -----END PGP SIGNATURE----- --28wQRWQoWVvFIctMvW7rWM5PgjbBEuPgs-- From nobody Tue Feb 28 17:28:56 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFD1129408 for <6lo@ietfa.amsl.com>; Tue, 28 Feb 2017 17:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P_Gqp5IQ_HOH for <6lo@ietfa.amsl.com>; Tue, 28 Feb 2017 17:28:53 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0D91293DA for <6lo@ietf.org>; Tue, 28 Feb 2017 17:28:53 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id x24so32378170uab.0 for <6lo@ietf.org>; Tue, 28 Feb 2017 17:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=33o6uW8YmzdgEBg1u3ObZrQUawlXdADh4Op4sKETpnw=; b=B82e0GL8PzmRU1mKJi7/K3g3kXZ+S02nCH20PvZbzgX7FYJD3DdumpbxLh54SCB74z JDtyj32eM1W3c/6c3eF1gVDNeY2CSuTqk+1bnZsqBd/koignmLC+GowinaQgaCYo/aF3 lmHyYcnF/7N7bRc//jY1LnKR7/bFKsBeTEs2G2XdPNj6NwozAW0J8HxC2wLFq4XRRU3S OOJxIeB993bQXdAwTGRH1zqmSmBev7m3WcsLEC0BZB7hXg98nCRqTg4dFep+PegbUay+ 7+lvlQfzPooqu8zgp1QRNtGG4G58x7adY5qCrPPa4jOt1ybQ9VffzokRFeF+tO7TXFCO qeQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=33o6uW8YmzdgEBg1u3ObZrQUawlXdADh4Op4sKETpnw=; b=D9Uq9AAK5uLcBShEK6HKmuJtz+PQg97r7Qu2/2apWzHV7C6xbSFMMWJ6rNBJivah+J 98xCZjqPjSA9QKIMOWQrXAtTso/YD467ofs/W1Sspg9ZHvKTAaNJw1PshyY5pB83REDR /GClcb9bThhQ+tjfIOeM+T4L5jjyNfVmPt1b+8AWu7GgeEtfyYtzt5xEJqGjvDaP+ekZ q1rVt8KjZMs8DCewGtfOZMOF589XluKlZe/Ci0oxxx5vJZ/8Nd7h9v7YoSf2kYcpX/bg Hu/pAvzCsd7wwsw68+OvMeAs5t4tcntVlVidESoJTOQwr2/owQn7oXYVLXj4VvgqK+Xl UF2Q== X-Gm-Message-State: AMke39nUE7fXoVYBHhID5f1fYhYd682crq0A5beksH461ZbDqnZ/6l/kU/iHm/7b1zKL2Rlq7Ht7z2oueuF7vg== X-Received: by 10.159.35.50 with SMTP id 47mr2503918uae.47.1488331732327; Tue, 28 Feb 2017 17:28:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.152.80 with HTTP; Tue, 28 Feb 2017 17:28:51 -0800 (PST) In-Reply-To: <145a7942-b86e-30e9-9542-187705c80fbf@pengutronix.de> References: <20170224121440.32269-1-luiz.dentz@gmail.com> <20170224121440.32269-7-luiz.dentz@gmail.com> <145a7942-b86e-30e9-9542-187705c80fbf@pengutronix.de> From: Samita Chakrabarti Date: Tue, 28 Feb 2017 17:28:51 -0800 Message-ID: To: Alexander Aring , lo <6lo@ietf.org>, "Savolainen Teemu (Nokia-TECH/Tampere)" , luiz.von.dentz@intel.com Content-Type: multipart/alternative; boundary=001a113d15b436a3630549a13c1d Archived-At: Subject: Re: [6lo] [PATCH v5 6/6] 6lowpan: Fix IID format for Bluetooth X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:28:55 -0000 --001a113d15b436a3630549a13c1d Content-Type: text/plain; charset=UTF-8 Hello Alexander, Glad to hear that folks are trying to implement RFC 7668. You are right in conclusion that no u or g bit handling is required. >From RFC 7668, section 3.2.2 -- it says that one should use 48-bit BT device identification and form the 64-bit IID separated by oxFFFE. The BT identification bits are marked as 'b' in the specification and they stay unchanged. So U/L considerations are not needed. This is still following RFC 7136 method of IPv6 address formation as the 48-bit BT device identification is not the same IEEE based 48bit MAC address. Thanks, -Samita On Sat, Feb 25, 2017 at 10:25 PM, Alexander Aring wrote: > > Hi, > > On 02/26/2017 07:05 AM, Alexander Aring wrote: > > > > Hi, > > > > On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote: > >> From: Luiz Augusto von Dentz > >> > >> Accourding to RFC 7668 U/L bit shall not be used: > >> > >> https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]: > >> > >> In the figure, letter 'b' represents a bit from the > >> Bluetooth device address, copied as is without any changes on any > >> bit. This means that no bit in the IID indicates whether the > >> underlying Bluetooth device address is public or random. > >> > >> |0 1|1 3|3 4|4 6| > >> |0 5|6 1|2 7|8 3| > >> +----------------+----------------+----------------+-------- > --------+ > >> |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb| > bbbbbbbbbbbbbbbb| > >> +----------------+----------------+----------------+-------- > --------+ > >> > >> Because of this the code cannot figure out the address type from the IP > >> address anymore thus it makes no sense to use peer_lookup_ba as it needs > >> the peer address type. > >> > > > > I am still not quite 100% of this and want to leave my opinion about this > > handling which can be interpreted in a different way. > > > > The RFC says here: > > > > Following the guidance of [RFC7136], a 64-bit > > Interface Identifier (IID) is formed from the 48-bit Bluetooth device > > address by inserting two octets, with hexadecimal values of 0xFF and > > 0xFE in the middle of the 48-bit Bluetooth device address as shown in > > Figure 6. > > Okay, they said from IID from the 48-bit address. > > And IID is what you need here and what [RFC7136] describes as result, > so I think you are right. > > There is no need for special u/l bitflip or link-layer multicast handling. > > - Alex > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --001a113d15b436a3630549a13c1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Alexander,

Glad to hear that folk= s are trying to implement RFC 7668.

You are right = in conclusion that no u or g bit handling is required.

=
From RFC 7668, section 3.2.2 -- it says that one should use 48-bit BT = device identification =C2=A0and form the 64-bit IID =C2=A0separated by oxFF= FE. The BT identification bits are marked as 'b' in the specificati= on and they stay unchanged. So U/L considerations are not needed.

This is still following RFC 7136 method of IPv6 address for= mation as the 48-bit BT device identification is not the same IEEE based 48= bit MAC address.=C2=A0

Thanks,
-Samita



On Sat, Feb 25, 2017 at 10:25 PM, Alexander Aring <aar@pengutronix.de> wrote:

Hi,

On 02/26/2017 07:05 AM, Alexander Aring wrote:
>
> Hi,
>
> On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote:
>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>>
>> Accourding to RFC 7668 U/L bit shall not be used:
>>
>> https://wiki.tools.ietf.org/html= /rfc7668#section-3.2.2 [Page 10]:
>>
>>=C2=A0 =C2=A0 In the figure, letter 'b' represents a bit fr= om the
>>=C2=A0 =C2=A0 Bluetooth device address, copied as is without any ch= anges on any
>>=C2=A0 =C2=A0 bit.=C2=A0 This means that no bit in the IID indicate= s whether the
>>=C2=A0 =C2=A0 underlying Bluetooth device address is public or rand= om.
>>
>>=C2=A0 =C2=A0 |0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1|= 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3|3=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 4|4=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 6|
>>=C2=A0 =C2=A0 |0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5|= 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1|2=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 7|8=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 3|
>>=C2=A0 =C2=A0 +----------------+----------------+-------------= ---+----------------+
>>=C2=A0 =C2=A0 |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110= bbbbbbbb|bbbbbbbbbbbbbbbb|
>>=C2=A0 =C2=A0 +----------------+----------------+-------------= ---+----------------+
>>
>> Because of this the code cannot figure out the address type from t= he IP
>> address anymore thus it makes no sense to use peer_lookup_ba as it= needs
>> the peer address type.
>>
>
> I am still not quite 100% of this and want to leave my opinion about t= his
> handling which can be interpreted in a different way.
>
> The RFC says here:
>
> Following the guidance of [RFC7136], a 64-bit
> Interface Identifier (IID) is formed from the 48-bit Bluetooth device<= br> > address by inserting two octets, with hexadecimal values of 0xFF and > 0xFE in the middle of the 48-bit Bluetooth device address as shown in<= br> > Figure 6.

Okay, they said from IID from the 48-bit address.

And IID is what you need here and what [RFC7136] describes as result,
so I think you are right.

There is no need for special u/l bitflip or link-layer multicast handling.<= br>

- Alex

_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

--001a113d15b436a3630549a13c1d-- From nobody Tue Feb 28 17:46:41 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81DC1296F4 for <6lo@ietfa.amsl.com>; Tue, 28 Feb 2017 17:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tOh0hfFxbHOO for <6lo@ietfa.amsl.com>; Tue, 28 Feb 2017 17:46:38 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B26F12960E for <6lo@ietf.org>; Tue, 28 Feb 2017 17:46:38 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id r136so1868584vke.1 for <6lo@ietf.org>; Tue, 28 Feb 2017 17:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zSE1bVJXNpolrV9MelaBLYg2akMIZmqWGd37371XAXk=; b=I0osOMWOlKEF7fYXmeKSBD37uqSlajuOeVpgo5X8qreN6jBSGutsbIYoRA701o2u8Y c/8h0l4fEIDJMt9Ml5YdQKstnxPHTHdihAZ7wXtacCJomqWaK7HbyQcRtXIpAJ0suude VRkMQjfLX2ab9luspoweWS64glwsj/W8eGMo3eGiNwB6oscPUKKLtB7DB5dJogORI4eS fAhuz8HdJJCzKOj3oW+NV8QOSjXs1AcapVOY/MYjqi9MUnfMwk7gQjOPkWVEq/u3A/4/ qn8O4D6PdfEspmBguAkSEjpkg2XDl8Tz41bA00qaIIpzwH6ztWPVQxRgY+SmfsZGJOz7 zp8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zSE1bVJXNpolrV9MelaBLYg2akMIZmqWGd37371XAXk=; b=F1XXy9UzqHGc1RTQfLQ2jeBlez55Z4ErSt3PWP4EBQW8aWyd+ZTwjA4znDDeI8mS3F mpEKegXIBoOmOgc0PBFSDOo1yruFnpnNu/tYvbbPqqZKO9bocOAcC0AIJW7vTv0bcGI5 mUmYY251u+nRCeEDufRenxXfuM8C3a5YFY3cI9+yBuxbnkOC+35w4bJ8dw0J+AXCiUoE z6DC5spV6enGr6BEpLwqdWly/BV6TVq10rCJMdxjeHsX+/8vtjZoQMGKDRFSYHiiEr8n klzuoUz02zqqoPp5/RcMFONuiZKcpjsi2890mhDgszoqIxoATF0K1CZHyr9JutkHsXZQ qKsA== X-Gm-Message-State: AMke39nvRwP8vc8hdaOHIIQGX+YG0Szbu1dgbE0J60XTf3dGlAMcidUgw2FZaW+3qXUSnq3BMHUkYCFfJc5qSQ== X-Received: by 10.31.216.5 with SMTP id p5mr2157167vkg.170.1488332797249; Tue, 28 Feb 2017 17:46:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.152.80 with HTTP; Tue, 28 Feb 2017 17:46:36 -0800 (PST) In-Reply-To: References: From: Samita Chakrabarti Date: Tue, 28 Feb 2017 17:46:36 -0800 Message-ID: To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=001a114ebf30b010e60549a17b39 Archived-At: Cc: "Pascal Thubert \(pthubert\)" , lo <6lo@ietf.org> Subject: Re: [6lo] Understanding RFC8025 implementation and page switching X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:46:41 -0000 --001a114ebf30b010e60549a17b39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Robert, Pascal and Carsten for clarification and order of pages and mesh/frag headers in the context of paging dispatch. Is there a way to capture these information and tag that with RFC page? This is not an Errata but the order and explanation would be quite useful for the implementers for future extensions. Alternatively, updating the 6lo wiki to contain these information would be useful. Any suggestions ? Thanks, -Samita On Mon, Feb 27, 2017 at 9:46 AM, Robert Cragie wrote: > > > On 27 February 2017 at 13:56, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Dear Samita : >> >> >> >> *From:* Samita Chakrabarti [mailto:samitac.ietf@gmail.com] >> >> >> >> Hello : >> >> >> >> I am trying to decipher the RFC 8025 packet header sequence and bit >> patterns from reading the document and http://www.iana.org/assign >> ments/_6lowpan-parameters/. >> >> >> >> Sorry, I should have asked these questions before, but it is never too >> late... >> >> >> >> * I assume the main purpose is to give the implementor tools to go and >> parse/interprete additional data carried by original RFC 4944 style pack= et >> or not. >> >> >> >> *[Pascal] Yes, we have a very large space now.* >> >> >> >> * The document says that the page-switch dispatch type should be always >> preceded by mesh and fragment header. I would assume that original pg 0 = or >> LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if t= he >> following sequences are valid ? >> >> >> >> *[Pascal] The page 0 switch is implicit and placed before the mesh >> header, which is defined in that page. There can be a packet without a m= esh >> or a fragment header, so a page switch is not always preceded by one of >> those. But if one of those headers is present, then it appears before >> switching to another page.* >> > > > There is nothing stopping definitions for a mesh header equivalent in > pages 2-14 and fragment header equivalent in pages 1-14. However, in the > context of RFC 8025, mesh and fragment headers are strictly considered as > being in page 0, hence having to precede them with a page 0 dispatch, whi= ch > as Pascal says is implicit at the beginning of a frame, i.e. at the momen= t > we would have: > > [(implicit page 0 dispatch)][MESH][FRAG0][page-switch-to-X][New-dispatch-= type > from page X][Payload] > > In the future, one can envisage alternatives however: > > [page-switch-to-2][MESH from page 2][FRAG from page 2][New-dispatch-type > from page 2][Payload] > > >> >> >> 1) [Mesh][page-switch-to-X][New-dispatch-type from page X][Payload] >> >> *[Pascal] Valid* >> >> 2) [ESC][ESC-Bytes][LOWPAN_IPHC][page-switch-to-X][Page-X-dispatch][Payl= oad] >> >> >> *[Pascal] I expect that this could happen with an update of RFC 6282, bu= t >> with the current spec you cannot since RFC6282 defines the chain all the >> way to the payload or at least the end of the compressed piece.* >> >> >> >> 3) [LOWPAN-IPHC][Payload][page-switch-toX][Page-X-dispatch][add >> itional-payload] >> >> *[Pascal] Then again this could happen but would need new specs * >> >> >> >> >> >> If both 2 and 3 are valid sequences, can you please provide two examples >> of use-cases ? >> >> >> >> *[Pascal] It could potentially be used for selectively compressing or >> signing the payload; but I=E2=80=99m not aware of anyone trying this. * >> >> *It could also be used for packaging separate fragments back together or >> something. I do hope that no one ever specifies this based on what I hea= rd >> from MP-TCP and middle box games.* >> >> *The most common sequence involving RFC 8025 would be *[page-switch-to-P= age1] >> [6LoRH]* [LOWPAN-IPHC] [IPv6 headers]* [LOWPAN-NHC] [Payload] >> >> >> >> I was not sure if we can allow payload with each page and parse multiple >> payloads with the same packet [ assuming we have large enough frame size= ]. >> >> *[Pascal] The paging does not say, but new specs using it would.* >> >> >> >> *Take care, * >> >> >> >> *Pascal* >> >> >> >> Thanks, >> >> -Samita >> >> >> >> _______________________________________________ >> 6lo mailing list >> 6lo@ietf.org >> https://www.ietf.org/mailman/listinfo/6lo >> >> > --001a114ebf30b010e60549a17b39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Robert, Pascal and Carsten for clarification and or= der of pages and mesh/frag headers in the context of paging dispatch. =C2= =A0
Is there a way to capture these information and tag that with RFC p= age? This is not an Errata but the order and explanation would be quite use= ful for the implementers for future extensions.

Al= ternatively, updating the 6lo wiki =C2=A0to contain these information would= be useful. Any suggestions ?

Thanks,
-S= amita

= On Mon, Feb 27, 2017 at 9:46 AM, Robert Cragie <robert.cragie@gr= idmerge.com> wrote:


On 27 February 2017 at 13:56, Pascal Thubert (pthubert) <pt= hubert@cisco.com> wrote:

Dear Samita=C2=A0:=

=C2=A0

From: Samita Chakrabarti [mailto:samitac.ietf@gmail.= com]

=C2=A0

Hello :

=C2=A0

I am trying to decipher t= he RFC 8025 =C2=A0packet header sequence and bit patterns from reading the = document and=C2=A0http://www.iana.org/assignments/_6lowpan-par= ameters/.

=C2=A0

Sorry, I should have aske= d these questions before, but it is never too late...

=C2=A0

* I assume the main purpo= se is to give the implementor tools to go and parse/interprete additional d= ata carried by original RFC 4944 style packet or not.

=C2=A0

[Pascal] Yes, we have a very large space = now.

=C2=A0

* The document says that = the page-switch dispatch type should be always preceded by mesh and fragmen= t header. I would assume that original pg 0 or LOWPAN-IPHC dispatch type ca= n precede as well. Can some one confirm if the following sequences are valid ?

=C2=A0

[Pascal] The page 0 switch is implicit an= d placed before the mesh header, which is defined in that page. There can b= e a packet without a mesh or a fragment header, so a page switch is not always preceded by one of those. But if on= e of those headers is present, then it appears before switching to another = page.


<RCC>
There is nothing stopping definitions for a = mesh header equivalent in pages 2-14 and fragment header equivalent in page= s 1-14. However, in the context of RFC 8025, mesh and fragment headers are = strictly considered as being in page 0, hence having to precede them with a= page 0 dispatch, which as Pascal says is implicit at the beginning of a fr= ame, i.e. at the moment we would have:

[(implicit = page 0 dispatch)][MESH][FRAG0][page-switch-to-X][New-dispatch-type fro= m page X][Payload]

In the future, one can envisage= alternatives however:

[page-switch-to-2][MESH fro= m page 2][FRAG from page 2][New-dispatch-type from page 2][Payload]
</RCC>
=

<= span style=3D"font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73= ,125)">

=C2=A0

1) [Mesh][page-switch-to-= X][New-dispatch-type from page X][Payload]

[Pascal] Valid

2) [ESC][ESC-Bytes][LOWPA= N_IPHC][page-switch-to-X][Page-X-dispatch][Payload]

[Pascal] I expect that this could happen = with an update of RFC 6282, but with the current spec you cannot since RFC6= 282 defines the chain all the way to the payload or at least the end of the compressed piece.

=C2=A0

3) [LOWPAN-IPHC][Payload]= [page-switch-toX][Page-X-dispatch][additional-payload]<= /u>

[Pascal] Then again this could happen but= would need new specs

=C2=A0

=C2=A0

If both 2 and 3 are valid= sequences, can you please provide two examples of use-cases ?

=C2=A0

[Pascal] It could potentially be used for= selectively compressing or signing the payload; but =C2=A0I=E2=80=99m not = aware of anyone trying this.

It could also be used for packaging separ= ate fragments back together or something. I do hope that no one ever specif= ies this based on what I heard from MP-TCP and middle box games.

The most common sequence involving RFC 80= 25 would be [page-switch-to-Page1] [6Lo= RH]* [LOWPAN-IPHC] [IPv6 headers]* [LOWPAN-NHC] [Payload]=

=C2=A0

I was not sure if we can = allow payload with each page and parse multiple payloads with the same pack= et [ assuming we have large enough frame size].

[Pascal] The paging does not say, but new= specs using it would.

=C2=A0

Take care,

=C2=A0

Pascal

=C2=A0

Thanks,

-Samita

=C2=A0


_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo



--001a114ebf30b010e60549a17b39--