Re: [6lo] Quick comments on http://tools.ietf.org/html/draft-ietf-6lo-lowpanz-04

Anders Brandt <Anders_Brandt@sigmadesigns.com> Fri, 21 March 2014 13:58 UTC

Return-Path: <Anders_Brandt@sigmadesigns.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F7B1A08CC for <6lo@ietfa.amsl.com>; Fri, 21 Mar 2014 06:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] 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 R40E3NEEbG-d for <6lo@ietfa.amsl.com>; Fri, 21 Mar 2014 06:58:24 -0700 (PDT)
Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0E94E1A072D for <6lo@ietf.org>; Fri, 21 Mar 2014 06:58:23 -0700 (PDT)
From: Anders Brandt <Anders_Brandt@sigmadesigns.com>
To: Samita Chakrabarti <samita.chakrabarti@ericsson.com>
Thread-Topic: Quick comments on http://tools.ietf.org/html/draft-ietf-6lo-lowpanz-04
Thread-Index: Ac9CRdO9YsyUvRgAQOeS+pXASgMlgwCxBb2Q
Date: Fri, 21 Mar 2014 13:58:12 +0000
Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD5A69C4C1@cph-ex1>
References: <ECA43DA70480A3498E43C3471FB2E1F01C1941F2@eusaamb103.ericsson.se>
In-Reply-To: <ECA43DA70480A3498E43C3471FB2E1F01C1941F2@eusaamb103.ericsson.se>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.10.99]
Content-Type: multipart/alternative; boundary="_000_03F31C213F2C6941BFDDBB4336E9E6CD5A69C4C1cphex1_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6lo/SQ7pPmMMktycHC-S-PP1XFwrDCE
Cc: "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6lo] Quick comments on http://tools.ietf.org/html/draft-ietf-6lo-lowpanz-04
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 21 Mar 2014 13:58:27 -0000

Samita,

Thanks for your comments.

1)
> Quote: ".  Address registration is only needed in certain cases."
> It is not clear when address registration is needed. "certain cases" is ambiguous.
> Do we need it when DHCPv6 assigned addresses are used? Please clarify

I agree that the particular sentence seems unclear but this is the introduction and
the idea was to warn the user of that fact without getting into details in the introduction.

Fortunately, the principle of the draft is very clear:
Address registration is always needed in route over mode and it is needed in mesh under mode if DHCP is used.

Alternative proposal:
Address registration is not needed in mesh-under mode when using link-layer-derived IPv6 addresses.

Though I prefer the existing one...

2)
>Do you want to clarify DHCP assigned addresses with short lease period or short lifetime
> and ability to obtain a different IPv6 address upon renewal of the lease?
> If there is a pointer to a document which defines how DHCPv6 address allocation can be
> used for privacy - referencing that would have been nice.

I am not aware of a pointer as such, except for a statement in the 6man WG session in London that DHCPv6 provided good privacy properties when the DHCP
server is configured correctly. This should just be considered as a deployment guidance.

Alternative proposal (first line unmodified from draft -04):
  While intended for central address management, DHCPv6 address assignment also decouples the
  IPv6 address from the link layer address. Addresses may be made dynamic by the use of a short DHCP
  lease period and an assignment policy which makes the DHCP server hand out a fresh IP address every time.


Thanks,
  Anders.


From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com]
Sent: 18. marts 2014 02:13
To: Anders Brandt
Cc: 6lo@ietf.org
Subject: Quick comments on http://tools.ietf.org/html/draft-ietf-6lo-lowpanz-04

Hi Anders,

I have a quick question/comment on the v-04 of your draft:


1)      Introduction says:

If using

   that method, Duplicate Address Detection (DAD) is not needed.

   Alternatively, IPv6 addresses may be assigned centrally via DHCP,

   leading to a "non-link-layer-derived IPv6 address".  Address

   registration is only needed in certain cases.



Comment:  It is not clear when address registration is needed. "certain cases" is ambiguous. Do we need it when DHCPv6 assigned addresses are used? Please clarify





2)      In privacy section, it talks about using centrally assigned Ipv6 addresses by DHCP. Do you want to clarify DHCP assigned addresses with short lease period or short lifetime and ability to obtain a different IPv6 address upon renewal of the lease?  If there is a pointer to a document which defines how DHCPv6 address allocation can be used for privacy - referencing that would have been nice.

Will do some more review later.

Thanks,
-Samita