IETF Logo Mail Archive

Comments on draft-ietf-6man-default-iids-01.txt

"Ralph Droms (rdroms)" <rdroms@cisco.com> Mon, 27 October 2014 18:03 UTC

Return-Path: <rdroms@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6161A890F for <ipv6@ietfa.amsl.com>; Mon, 27 Oct 2014 11:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 sBChgMBBPsvD for <ipv6@ietfa.amsl.com>; Mon, 27 Oct 2014 11:03:40 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A271E1A8734 for <ipv6@ietf.org>; Mon, 27 Oct 2014 11:03:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3359; q=dns/txt; s=iport; t=1414433020; x=1415642620; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gor0Dw4TLwYo/h0OA8iY/lpz35U+YbGoKlCp0F5fs/g=; b=KNFca9tZ4NEKxVYUEB2PD875/mPuHubJWCjYpe0owKZKRDX101+pbFwz fKuYezroPgP7U4Jq4I5Hcnbs9bcBYZZAswO9VWQkE9XbXYoNIGmMwpUQ/ DD+HwWf6J0xYA51TIuTiKxtNafLcn+GuB45q4+InACBZx1mhEtcDQbBcs g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFACiITlStJV2c/2dsb2JhbABcgw6BMNYmFgF9hAk6NB0BPkInBIhUpx+kKAEBAQEGAQEBAQEBARuUPIEeBY9pgh6GP4UbgTGDSYoVhx+DeII0gQMBAQE
X-IronPort-AV: E=Sophos;i="5.04,797,1406592000"; d="scan'208";a="366855656"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 27 Oct 2014 18:03:40 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9RI3dWj026655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ipv6@ietf.org>; Mon, 27 Oct 2014 18:03:40 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.212]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 13:03:39 -0500
From: "Ralph Droms (rdroms)" <rdroms@cisco.com>
To: 6man WG <ipv6@ietf.org>
Subject: Comments on draft-ietf-6man-default-iids-01.txt
Thread-Topic: Comments on draft-ietf-6man-default-iids-01.txt
Thread-Index: AQHP8hBVXrq0mSKkskuqlQqDNp1aBg==
Date: Mon, 27 Oct 2014 18:03:38 +0000
Message-ID: <8676AC11-85F1-4E58-9871-43FD04C89AB8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.131.65.118]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7903E8D48E3C8E409E5B9905BF66BC4A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cFO4R1zNM4iNNNWn1Rf9IhuOOT4
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 18:03:43 -0000

I have a few comments on the new rev of draft-ietf-6man-default-iids.  This message is posted to the 6man WG mailing list, with a bcc to the 6lo WG mailing list.  The draft is of interest to the 6lo WG; please post responses to the 6man WG mailing list.

In this document, I think it is important to be explicit about the considerations that might lead to a decision not to follow the RFC 2119 language recommendations in this document.  My immediate concern is the 6LoWPAN standards, which use IIDs based on hardware addresses as a method for IPv6 header compression.

I also think that some of the wording is too strong, which may lead to confusion in the cases where the recommendations in this document are not followed.

In particular, I think the wording in the "Future Work" section is too strong, and does not allow for continued use of IIDs based on hardware addresses in 6LoWPAN and similar standards.

As an editorial detail, the document lists the various RFCs that are update, but does not explicitly state what is to be updated in those documents.  While the updates could be reasonably inferred, seems to me an explicit statement about what is to be updated would be good.

With those comments in mind, I'll suggest the following text changes:

In section 1, add this paragraph before the "NOTE":

  In some network technologies and adaptation layers, the use of an
  IID based on a hardware address offers some advantages.  For
  example, the IP-over-IEEE802.15.4 standard in RFC6775 allows for
  compression of IPv6 addresses when the IID the address is based
  on the corresponding hardware address.  The design and engineering
  tradeoffs between security and privacy, and network efficiency
  should be considered in any decision about the use of an IID based
  on a hardware address.

Replace section 3 with:

  It is RECOMMENDED by this document that nodes implement and employ
  RFC 7217 as the default scheme for generating stable IPv6 addresses
  with SLAAC.  Some specifications MAY use a an IID based on a node's
  hardware address if design and engineering considerations warrant.

  It is RECOMMENDED by this document that nodes do not employ IPv6
  address generation schemes that embed the underlying hardware
  address in the Interface Identifier.  In particular, this document
  RECOMMENDS that nodes do not generate Interface Identifiers with
  the schemes specified in [RFC2464], [RFC2467], [RFC2470],
  [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572],
  [RFC4338], [RFC4391], [RFC5121], and [RFC5072], and updates those
  documents with this recommendation.

  It is RECOMMENDED by this document that future specifications no
  not specify IPv6 address generation schemes that embed the
  underlying hardware address in the Interface Identifier. Future
  specifications MAY use a an IID based on a node's hardware address
  if design and engineering considerations warrant.

In section 4, replace the last paragraph with:

  Future revisions or updates of these documents should take the
  issues of privacy and security mentioned in section 1 and explain
  any design and engineering considerations that lead to the use of
  IIDs based on a node's hardware address.


I hope this input is helpful.

- Ralph

v2.23.0 | Report a Bug | By Email