[6lo] 6LoWPAN which type of MAC or channel access mechanisms are considered?

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 29 September 2016 12:20 UTC

Return-Path: <pthubert@cisco.com>
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 913EA12B544; Thu, 29 Sep 2016 05:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.836
X-Spam-Level:
X-Spam-Status: No, score=-16.836 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=-2.316, SPF_PASS=-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 N0ne6Dd3uhbj; Thu, 29 Sep 2016 05:20:16 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F1212B53C; Thu, 29 Sep 2016 05:19:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24638; q=dns/txt; s=iport; t=1475151574; x=1476361174; h=from:to:cc:subject:date:message-id:mime-version; bh=89JX4ITYj44buw/3MnqObY/kYSDExCcNsBjGE3xF9tU=; b=XA7qtr/IzvqgSxY/AtIQ4mAI/b3hSe5xvPdWEExq0uN7SGYd1mW6h9Kb /txqYzW5CNCsb5aUKzn3pveBOlAQa6110b+ubTlIL/H3IjASdVxeWemIf EcXbAg/hhD5EzvDM8/8SuJVP5CGNcWP/7qWYRYPbTlPXfnqs63dcRwkMm 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DYAQDTBe1X/5NdJa1TChkBAQEBAQEBAQEBAQcBAQEBAYMJNgEBAQEBHld8B40rln2HWIxLggYZAQyFeAIcgUQ4FAECAQEBAQEBAV4nhGEBAQEDAQEBARoGCkELBQ0BGQQBASgDAgQfBgsUCQkBBAENBQiIKwMPCA6vc4kIDYNeAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGN4ccgVUOUIJOgloFiRmFHIsNNQGGJoZJgnmBdYRmiRqHCoFShBCDfAEeNoUJcgGGRYEAAQEB
X-IronPort-AV: E=Sophos;i="5.30,414,1470700800"; d="scan'208,217";a="328114374"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2016 12:19:32 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u8TCJWGa017297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2016 12:19:32 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; Thu, 29 Sep 2016 07:19:32 -0500
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; Thu, 29 Sep 2016 07:19:31 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: sajjad akbar <sajjad.akr1@gmail.com>, samita Chakrabarti <samitac.ietf@gmail.com>
Thread-Topic: 6LoWPAN which type of MAC or channel access mechanisms are considered?
Thread-Index: AdIaS3sf8nBoMx3bRIKbtvt9D0Gxsg==
Date: Thu, 29 Sep 2016 12:19:06 +0000
Deferred-Delivery: Thu, 29 Sep 2016 12:18:47 +0000
Message-ID: <99ddcc5586f54a49b0bc33ce46932818@XCH-RCD-001.cisco.com>
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.17]
Content-Type: multipart/alternative; boundary="_000_99ddcc5586f54a49b0bc33ce46932818XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/mTygLcblIVfrKMwWgLhtKQtA-5g>
Cc: "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, lo <6lo@ietf.org>
Subject: [6lo] 6LoWPAN which type of MAC or channel access mechanisms are considered?
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: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2016 12:20:18 -0000

Hello Sajjad :

More as a side effect than a mandate of the doc, section A.3<https://tools.ietf.org/html/draft-thubert-6lo-rfc6775-update-00#appendix-A.3>. of https://tools.ietf.org/html/draft-thubert-6lo-rfc6775-update lists a number of LLNs that support 6LoWPAN, or are on the way to. Ethernet – and Wi-Fi- may join the band as soon as https://tools.ietf.org/html/draft-droms-6lo-ethertype-request is fulfilled.

Cheers,

Pascal

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of sajjad akbar
Sent: mardi 27 septembre 2016 12:13
To: samita Chakrabarti <samitac.ietf@gmail.com>
Cc: 6lo-chairs@ietf.org; lo <6lo@ietf.org>
Subject: Re: [6lo] WG adoption call for draft-sarikaya-6lo-ap-nd-04

Hi everyone

Can anybody guide me that for 6LoWPAN which type of MAC or channel access mechanisms are considered? Is ther any specific document which address this?

Kind Regards
Sajjad

On Tue, Sep 27, 2016 at 2:14 AM, samita Chakrabarti <samitac.ietf@gmail.com<mailto:samitac.ietf@gmail.com>> wrote:


Hello 6lo WG:

We have discussed the following document at the IETF meetings and mailing list about the use of cryptographic ID to identify one device with a particular IPv6 address during the Neighbor Discovery Process. The crypto-ID association is helpful when MAC-ID or EUI-64 ID may not be used.
There has been fair amount of interest in securing the IP-address owner authentication using this method, in the WG meetings(IETF95).

The co-authors have addressed several WG comments in the 04 version.

The adoption call  starts now and ends on Oct 10th, 2016.

Please provide your opinion with  yes/no  answer and a short explanation for this adoption call within the deadline.

Thanks and Regards,
-Gabriel and Samita (6lo co-chairs)

>
>
> Name:           draft-sarikaya-6lo-ap-nd
> Revision:       04
> Title:          Address Protected Neighbor Discovery for Low-power and Lossy Networks
> Document date:  2016-08-22
> Group:          Individual Submission
> Pages:          17
> URL:            https://www.ietf.org/internet-drafts/draft-sarikaya-6lo-ap-nd-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-sarikaya-6lo-ap-nd/
> Htmlized:       https://tools.ietf.org/html/draft-sarikaya-6lo-ap-nd-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-sarikaya-6lo-ap-nd-04
>
> Abstract:
>    This document defines an extension to 6LoWPAN Neighbor Discovery.
>    This extension is designed for low-power and lossy network
>    environments and it supports multi-hop operation.  Nodes supporting
>    this extension compute a Cryptographically Unique Interface ID and
>    associate it with one or more of their Registered Addresses.  The
>    Cryptographic ID (Crypto-ID) uniquely identifies the owner of the
>    Registered Address.  It is used in place of the EUI-64 address that
>    is specified in RFC 6775.  Once an address is registered with a
>    Cryptographic ID, only the owner of that ID can modify the state
>    information of the Registered Address in the 6LR and 6LBR.


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