From brian.e.carpenter@gmail.com Sun Mar 31 23:59:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9F421F85D2 for ; Sun, 31 Mar 2013 23:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.921 X-Spam-Level: X-Spam-Status: No, score=-98.921 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ptHrk4VTaBB for ; Sun, 31 Mar 2013 23:59:58 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2472321F857E for ; Sun, 31 Mar 2013 23:59:57 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id r3so1587684wey.17 for ; Sun, 31 Mar 2013 23:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TM6QmbSCEFy3bIlhUlnGBs3Vdd4gCDRtXLj4u8B8SNE=; b=0+Agpc0/fJFhx4yTl75wp8Gu+TVF7o/GADIY79VGTdVHovmieaavBgJkjEf4GhIusr FKi+6/NQPgAtNECP1q+NRyny1T6e7TR4StoddJsn/s3o5jcjZqiEkDyYa8X/tCbuTnwC wsZr5jnCHdBEvlf9t7BJb5cSN2OGXWD4ruoSq62NzGvE/HiT6vGL27alkEeSsQijMFqb Sa3tzK6sFNhdHPl0hjTkVEBp6QXPoQBZEFi4yfgSftkJpKr6QqxQ13b5hz5FpItqHfnZ bSVnCziVOKbH7zRW90lXhZyxB1Ac0TB2I8AI4+UUIYw9sHs2JBLAmSf0pgniAxGx9G2f ujsg== X-Received: by 10.194.83.33 with SMTP id n1mr14227361wjy.7.1364799597169; Sun, 31 Mar 2013 23:59:57 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-188-34.as13285.net. [2.101.188.34]) by mx.google.com with ESMTPS id fg6sm13116432wib.10.2013.03.31.23.59.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 23:59:56 -0700 (PDT) Message-ID: <5159306D.20103@gmail.com> Date: Mon, 01 Apr 2013 07:59:57 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Huitema Subject: Re: I-D Action: draft-ietf-6man-ug-00.txt References: <20130329155610.4461.87809.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 06:59:59 -0000 Christian, I'm not sure that the word "apply" is quite right, but otherwise I agree with you; we can be more explicit. Regards Brian On 31/03/2013 20:31, Christian Huitema wrote: > The draft would be a bit easier to read if it announced its purpose immediately, both in the abstract and in the introduction. For example, in the abstract, instead of just stating: > > This document clarifies > the status of those bits for interface identifiers that are not > derived from an IEEE link-layer address, and updates RFC 4291 > accordingly. > > You could have written: > > This document clarifies > that these bits only apply to interface identifiers that are explicitly > derived from an IEEE link-layer address, and updates RFC 4291 > accordingly. > > > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, March 29, 2013 8:56 AM > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-ug-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : The U and G bits in IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ug-00.txt > Pages : 9 > Date : 2013-03-29 > > Abstract: > The IPv6 addressing architecture defines a method by which the > Universal and Group bits of an IEEE link-layer address are mapped > into an IPv6 unicast interface identifier. This document clarifies > the status of those bits for interface identifiers that are not > derived from an IEEE link-layer address, and updates RFC 4291 > accordingly. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-ug > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-ug-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From internet-drafts@ietf.org Mon Apr 1 01:56:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9A21F81FF; Mon, 1 Apr 2013 01:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAuCYIqLXLQz; Mon, 1 Apr 2013 01:56:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8D121F8610; Mon, 1 Apr 2013 01:56:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-considerations-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401085656.4151.64593.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 01:56:56 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:56:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Considerations for IPv6 Address Selection Policy Changes Author(s) : Tim Chown Arifumi Matsumoto Filename : draft-ietf-6man-addr-select-considerations-05.txt Pages : 18 Date : 2013-04-01 Abstract: This ducument is intended to capture the address selection design team's considerations about the address selection issues mainly raised in [RFC5220]. This considerations led to the revision of RFC 3484 [RFC6724], and Address Selection DHCP option. Although it does not perfectly match the current state, this document captures the past discussion and considerations for the historical record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-considerations There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-considerations-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-consideratio= ns-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From n@arifumi.net Mon Apr 1 02:36:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA2221F890D for ; Mon, 1 Apr 2013 02:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUq5xqQmdmZc for ; Mon, 1 Apr 2013 02:36:17 -0700 (PDT) Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4255E21F88D6 for ; Mon, 1 Apr 2013 02:36:17 -0700 (PDT) Received: by mail-da0-f52.google.com with SMTP id f10so1003299dak.39 for ; Mon, 01 Apr 2013 02:36:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:x-gm-message-state; bh=A6ITHopAtDQ03R+6i/vNZwjISF9ctC75sXElAw9+vnc=; b=UIn+TlDMiXAyE99/pcwX9d9OAMuebVmHhkjvGOyA3H2pxxh2ZY/5ebKuw9sWqkh6pt O6N8xMj7RIVSIU8UFhp+Pb7I4EJOEha8s5zjuFQcB9oJrRlgn/LLp2IDPy1SVi4mj6xz ou7oUgdEUyaDD+IOGm12+hv/UCNTkyDY2p98sH6Ive3VkXKO4VBSgawQbnI3qybE/48E FZQUjRqKovnU3ArZKdCqntnqZ20OjnQzSpzbIJ9GPorVajNd4gjXgLR0h75mey1VevIj RCj9CAwpUQJfxTNU5brGISKovc6BzkvwH6EnZ2kuh8VKwkycnPzcKfT7VIdV395RvseZ 4siQ== MIME-Version: 1.0 X-Received: by 10.68.171.133 with SMTP id au5mr7320831pbc.4.1364808976912; Mon, 01 Apr 2013 02:36:16 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.33.3 with HTTP; Mon, 1 Apr 2013 02:36:16 -0700 (PDT) X-Originating-IP: [2001:fa8:1010:0:ac8f:65b3:8606:48fe] In-Reply-To: <20130401085656.4151.64593.idtracker@ietfa.amsl.com> References: <20130401085656.4151.64593.idtracker@ietfa.amsl.com> Date: Mon, 1 Apr 2013 18:36:16 +0900 X-Google-Sender-Auth: suBQOSLdFdM2bJp146KyVeOjHgU Message-ID: Subject: Fwd: I-D Action: draft-ietf-6man-addr-select-considerations-05.txt From: Arifumi Matsumoto To: "ipv6@ietf.org 6man" Content-Type: multipart/alternative; boundary=047d7b67320e4165ea04d9495a7a X-Gm-Message-State: ALoCoQlGTDv4kB+oIa9reNinh8VHNvV7tPzxoUj4Ob6fDqzvZ/L9AuAiqN5iLq1MR0/RWfh64AVf X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 09:36:17 -0000 --047d7b67320e4165ea04d9495a7a Content-Type: text/plain; charset=ISO-8859-1 Hi, this is intended to record the past discussion that resulted in the revision of RFC 3484, and Address Selection DHCPv6 option. If everyone thinks this document useful, I hope this one goes to WGLC. ---------- Forwarded message ---------- From: Date: 2013/4/1 Subject: I-D Action: draft-ietf-6man-addr-select-considerations-05.txt To: i-d-announce@ietf.org Cc: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Considerations for IPv6 Address Selection Policy Changes Author(s) : Tim Chown Arifumi Matsumoto Filename : draft-ietf-6man-addr-select-considerations-05.txt Pages : 18 Date : 2013-04-01 Abstract: This ducument is intended to capture the address selection design team's considerations about the address selection issues mainly raised in [RFC5220]. This considerations led to the revision of RFC 3484 [RFC6724], and Address Selection DHCP option. Although it does not perfectly match the current state, this document captures the past discussion and considerations for the historical record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-considerations There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-considerations-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-considerations-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --047d7b67320e4165ea04d9495a7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

this is intended to r= ecord the past discussion that resulted in
the revision of RFC 348= 4, and Address Selection DHCPv6 option.

If everyone thinks thi= s document useful, I hope this one goes to
WGLC.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/4/1
Subject: I-D Action: draft-ietf-6man-addr-select-consider= ations-05.txt
To: i-d-announce@= ietf.org
Cc: ipv6@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the IPv6 Maintenance Working Group of the I= ETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Considerations for IPv6 Address= Selection Policy Changes
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Tim Chown
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Arifumi Matsumoto
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-6man-addr-select-consi= derations-05.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 18
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-01

Abstract:
=A0 =A0This ducument is intended to capture the address selection design =A0 =A0team's considerations about the address selection issues mainly<= br> =A0 =A0raised in [RFC5220]. =A0This considerations led to the revision of R= FC
=A0 =A03484 [RFC6724], and Address Selection DHCP option. =A0Although it do= es
=A0 =A0not perfectly match the current state, this document captures the =A0 =A0past discussion and considerations for the historical record.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= 6man-addr-select-considerations

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-addr= -select-considerations-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-6man-addr-select-considerations-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--047d7b67320e4165ea04d9495a7a-- From swb@internet2.edu Mon Apr 1 06:23:58 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E7221F84F2 for ; Mon, 1 Apr 2013 06:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mp1cox7Gx-7 for ; Mon, 1 Apr 2013 06:23:58 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8C50C21F9713 for ; Mon, 1 Apr 2013 06:23:50 -0700 (PDT) Received: from mail164-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE030.bigfish.com (10.174.4.93) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Apr 2013 13:23:50 +0000 Received: from mail164-db8 (localhost [127.0.0.1]) by mail164-db8-R.bigfish.com (Postfix) with ESMTP id C93DF72016B; Mon, 1 Apr 2013 13:23:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.53; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0811HT003.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 10 X-BigFish: S10(zzzz1f42h1fc6h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1b1cn1b1bi1155h) Received: from mail164-db8 (localhost.localdomain [127.0.0.1]) by mail164-db8 (MessageSwitch) id 1364822599990899_21817; Mon, 1 Apr 2013 13:23:19 +0000 (UTC) Received: from DB8EHSMHS017.bigfish.com (unknown [10.174.8.231]) by mail164-db8.bigfish.com (Postfix) with ESMTP id EF69CA40045; Mon, 1 Apr 2013 13:23:19 +0000 (UTC) Received: from BLUPRD0811HT003.namprd08.prod.outlook.com (157.56.232.53) by DB8EHSMHS017.bigfish.com (10.174.4.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 1 Apr 2013 13:23:19 +0000 Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.123.38) with Microsoft SMTP Server (TLS) id 14.16.287.8; Mon, 1 Apr 2013 13:23:11 +0000 Message-ID: <51598A3D.20108@internet2.edu> Date: Mon, 1 Apr 2013 09:23:09 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [67.241.75.185] X-OriginatorOrg: internet2.edu Cc: "fgont@si6networks.com" , Alexandru Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 13:23:59 -0000 The scope of the draft was more or less restricted to in-vehicle communications because of the privacy concerns ("The focus of this work is to enable in-vehicle networks to exchange packets with VIN-based IPv6 addresses." -- although inter-vehicle communications is still a big deal under use cases), so I don't think use of DNS, etc., apply. If the draft isn't really restricted to in-vehicle communications I have a number of architectural arguments about why it's a bad idea. VINs are neither topological locators nor IP endpoint identifiers, and trying to map them onto either causes confusion. They're fine as higher layer tokens. Scott From sarikaya2012@gmail.com Mon Apr 1 08:33:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E044911E80BA; Mon, 1 Apr 2013 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOhb1Kvn6pO7; Mon, 1 Apr 2013 08:33:17 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2493A11E809C; Mon, 1 Apr 2013 08:33:13 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so2179968lab.8 for ; Mon, 01 Apr 2013 08:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=irPjt8j013NDruYycrCg0f3I2I7NsQ2op/4nhHcmF3U=; b=F8cbrFHcmsXYCJuayxHKR2Pm9umFVVGZtR5sojd2lrzAOwdl3SL6l/5oIL6xPQhoqN QIiEa7hBU8w4kJnWeiubtU6kANiTkrSWr+G27eg5f7ktcNomin7GuBdfxfZRmqACc8AR L+EG8kRgW0GRoyc1LlVVxpHKVl+1C7THlIRXKbSwo2atQ6S9Ju+7QWfgiYuDx1UvIx4o NbgRQZ5Fzn2vlKKuQ8ALvsGOHCUNx66Rk1XfVvcneyfLJqA+odhD9hStI8f28y/47QsE zH2ZU6fyeSdOEjMu7Evwdig1DspWZa4FYOlhQ+fcqD+QunizTD2R09rgbHd7X/N7avWb lVeA== MIME-Version: 1.0 X-Received: by 10.152.125.239 with SMTP id mt15mr5946068lab.26.1364830392787; Mon, 01 Apr 2013 08:33:12 -0700 (PDT) Received: by 10.114.17.104 with HTTP; Mon, 1 Apr 2013 08:33:12 -0700 (PDT) In-Reply-To: <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Mon, 1 Apr 2013 10:33:12 -0500 Message-ID: Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" From: Behcet Sarikaya To: Mark Smith Content-Type: multipart/alternative; boundary=f46d04426b66bda77504d94e56aa Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:33:19 -0000 --f46d04426b66bda77504d94e56aa Content-Type: text/plain; charset=ISO-8859-1 Hi Mark, On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith wrote: > Hi Behcet, > > Thanks for your review and comments. > > > > >________________________________ > > From: Behcet Sarikaya > >To: Dave Thaler > >Cc: Mark Smith ; "6man@ietf.org" < > 6man@ietf.org>; "mboned@ietf.org" > >Sent: Saturday, 30 March 2013 8:33 AM > >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery > of Multicast" > > > > > >Hi Mark, > > > >I read your draft. > >First of all I think you misunderstood RFC 6085 and based on a wrong > assumption you developed your solution. > > > > > >What specifically do you think I've misunderstood? I was involved in some > of the conversations about that RFC while it was an ID, and all I think it > really is fundamentally saying is that an IPv6 packet with a multicast IPv6 > destination address isn't required to have a link-layer multicast > destination address - it can be a link-layer unicast destination address if > useful or necessary. > > > Really, because I think no one knows how the ID became an RFC. > > > > > > > > > I suggest you take a look at > http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 > >on Netext for PMIPv6. > > > > > >I'll have a read. > But more importantly, it was aimed to solve PMIPv6 problem of establishing point-to-point link on an important shared links like 802.11. Actually there are other ways of doing that, mainly in Layer 2. > > >I believe that we should use multicast delivery as much as possible on > the downlink if the link is a shared link. > > > > > > > > > >I agree with using multicast as much as possible to reduce duplicate > packets sent over the network. The proposal here is to use packet > replication and link-layer unicasts when doing so would either exceed the > performance of link-layer multicast and/or overcome the negative effects of > link-layer multicast, such as when larger volumes of multicast traffic > impact unicast performance on the same link. Both of these issues occur on > 802.11 links when there volume of multicast traffic is in the order of a > few megabits (or less, I've been testing with around 2.5 Mbps of video) > > > > > >The main use case I've been thinking about (which I'll make more obvious > in the next revision), is a multicast IPTV service scenario towards a > residential customer, where the residential customer has a 802.11 network > in their home rather than a wired one. IPv6 multicast/link-layer multicast > would be used all the way from the multicast source servers, across the > service provider network, up until the CPE in the residential customers' > homes, gaining the efficiencies of multicast. However, the CPE in the > customer's house would then use IPv6 multicast/link-layer unicast of the > IPTV traffic over the 802.11 link to the customers end-hosts, saving them > having to put in wired infrastructure, or resorting to buying ethernet over > power devices to make their power cabling their wired infrastructure. Note > that there is still a low level of link-layer multicast traffic in the > customers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal is > not eliminating > link-layer multicasts, just reducing them where possible and where useful. > > > > > >That's not to say this proposal is only useful in an 802.11 scenario. It > could be used in any scenario where packet replication and link-layer > unicasting would provide useful benefits over link-layer multicasts. It > generally increases the data confidentiality of the multicast IPv6 traffic, > and may help increase battery life of some devices. > > > Well, you preached your case quite well. But the main problem is with 802.11 multicast which uses the lowest bandwidth channel. So you are proposing to change multicast to unicast delivery with copying to cope with this problem. Let this be well understood. I would suggest changing 802.11 multicast though. Also, I have concerns on the copying: it seems like copying will be based on neighbor discovery cash. I think it is rather strange. Another point is that point to point link is another solution. Regards, Behcet --f46d04426b66bda77504d94e56aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mark,


On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith <markzzzsmith@yahoo.com.au> wrote:
Hi Behcet,

Thanks for your review and comments.



>________________________________
> From: Behcet Sarikaya <sa= rikaya2012@gmail.com>
>To: Dave Thaler <dthaler@mi= crosoft.com>
>Cc: Mark Smith <markzzz= smith@yahoo.com.au>; "6man@iet= f.org" <6man@ietf.org>;= "mboned@ietf.org" <mboned@ietf.org>
>Sent: Saturday, 30 March 2013 8:33 AM
>Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Del= ivery of Multicast"
>
>
>Hi Mark,
>
>I read your draft.
>First of all I think you misunderstood RFC 6085 and based on a wrong as= sumption you developed your solution.
>
>
>What specifically do you think I've misunderstood? I was invo= lved in some of the conversations about that RFC while it was an ID, and al= l I think it really is fundamentally saying is that an IPv6 packet with a m= ulticast IPv6 destination address isn't required to have a link-layer m= ulticast destination address - it can be a link-layer unicast destination a= ddress if useful or necessary.
>

Really, be= cause I think no one knows how the ID became an RFC.
=A0
>


=A0
>
>
>=A0I suggest you take a look at http://tools.= ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01
>on Netext for PMIPv6.
>
>
>I'll have a read.

But more impo= rtantly, it was aimed to solve PMIPv6 problem of=20 establishing point-to-point link on an important shared links like=20 802.11.

Actually there are other ways of doing that, mainly in= Layer 2.=A0

>
>I believe that we should use multicast delivery as much as possible on = the downlink if the link is a shared link.
>
>
>
>
>I agree with using multicast as much as possible to reduce duplic= ate packets sent over the network. The proposal here is to use packet repli= cation and link-layer unicasts when doing so would either exceed the perfor= mance of link-layer multicast and/or overcome the negative effects of link-= layer multicast, such as when larger volumes of multicast traffic impact un= icast performance on the same link. Both of these issues occur on 802.11 li= nks when there volume of multicast traffic is in the order of a few megabit= s (or less, I've been testing with around 2.5 Mbps of video)
>
>
>The main use case I've been thinking about (which I'll make mor= e obvious in the next revision), is a multicast IPTV service scenario towar= ds a residential customer, where the residential customer has a 802.11 netw= ork in their home rather than a wired one. IPv6 multicast/link-layer multic= ast would be used all the way from the multicast source servers, across the= service provider network, up until the CPE in the residential customers= 9; homes, gaining the efficiencies of multicast. However, the CPE in the cu= stomer's house would then use IPv6 multicast/link-layer unicast of the = IPTV traffic over the 802.11 link to the customers end-hosts, saving them h= aving to put in wired infrastructure, or resorting to buying ethernet over = power devices to make their power cabling their wired infrastructure. Note = that there is still a low level of link-layer multicast traffic in the cust= omers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal is not= eliminating
=A0link-layer multicasts, just reducing them where possible and where usefu= l.
>
>
>That's not to say this proposal is only useful in an 802.11 scenari= o. It could be used in any scenario where packet replication and link-layer= unicasting would provide useful benefits over link-layer multicasts. It ge= nerally increases the data confidentiality of the multicast IPv6 traffic, a= nd may help increase battery life of some devices.
>

Well, you preached your case quite= well.

But the main problem is with 802.11 multicast whic= h uses the lowest bandwidth channel. So you are proposing to change multica= st to unicast delivery with copying=A0 to cope with this problem.

Let this be well understood.

I would sugge= st changing 802.11 multicast though.

Also, I have concern= s on the copying: it seems like copying will be based on neighbor discovery= cash.

I think it is rather strange.

Another poin= t is that point to point link is another solution.

Regard= s,

Behcet

--f46d04426b66bda77504d94e56aa-- From huitema@microsoft.com Mon Apr 1 09:55:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F43E21F8F81; Mon, 1 Apr 2013 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDaJxRnbWySL; Mon, 1 Apr 2013 09:55:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id D880A21F8F3F; Mon, 1 Apr 2013 09:55:30 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.202) by BY2FFO11HUB034.protection.gbl (10.1.14.118) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 1 Apr 2013 16:55:25 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Mon, 1 Apr 2013 16:55:25 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.126]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Mon, 1 Apr 2013 16:55:10 +0000 From: Christian Huitema To: "sarikaya@ieee.org" , Mark Smith Subject: RE: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Thread-Topic: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Thread-Index: AQHOLMUwpHL81jmgpU+Ur/9BeFe62Ji9PQgAgARF3QCAABTpEA== Date: Mon, 1 Apr 2013 16:55:09 +0000 Message-ID: References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFFA224tk5ex14mbxc272r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(189002)(377454001)(53794001)(199002)(24454001)(20776003)(63696002)(49866001)(51856001)(71186001)(69226001)(561944001)(5343655001)(5343635001)(81342001)(16297215001)(77982001)(65816001)(512954001)(4396001)(47976001)(50986001)(59766001)(16236675001)(53806001)(15202345001)(47736001)(55846006)(54356001)(79102001)(16406001)(31966008)(46102001)(74662001)(74502001)(47446002)(44976002)(33656001)(76482001)(66066001)(54316002)(56776001)(56816002)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB034; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0803A0241F Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:55:33 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFFA224tk5ex14mbxc272r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Behcet, If you want to change 802.11 multicast, you ought to do that in the IEEE 80= 2.11 working groups, not in the IETF. As far as we are concerned, 802.11 sp= ecifications are a constraint. It is a fact that multicast over 802.11 is very inefficient, and not approp= riate for multicast high volumes to few receivers. When the number of inten= ded recipients is small, it is much more efficient to send individual copie= s to each recipient than to try to use the 802.11 multicast service. There = is probably a case to be made that if the number of recipient is very large= multicast becomes a better solution, but I suspect that this very large nu= mber is too large for practical applications. So, yes, it is a fairly good idea to study how multicast delivery could be = accomplished by a series of unicast transmission. -- Christian Huitema From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Beh= cet Sarikaya Sent: Monday, April 1, 2013 8:33 AM To: Mark Smith Cc: mboned@ietf.org; 6man@ietf.org; Dave Thaler Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of = Multicast" Hi Mark, On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith > wrote: Hi Behcet, Thanks for your review and comments. >________________________________ > From: Behcet Sarikaya > >To: Dave Thaler > >Cc: Mark Smith >; "6man@ietf.org" <6man@ietf.org>; "mboned@ietf.org" > >Sent: Saturday, 30 March 2013 8:33 AM >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of= Multicast" > > >Hi Mark, > >I read your draft. >First of all I think you misunderstood RFC 6085 and based on a wrong assum= ption you developed your solution. > > >What specifically do you think I've misunderstood? I was involved in some = of the conversations about that RFC while it was an ID, and all I think it = really is fundamentally saying is that an IPv6 packet with a multicast IPv6= destination address isn't required to have a link-layer multicast destinat= ion address - it can be a link-layer unicast destination address if useful = or necessary. > Really, because I think no one knows how the ID became an RFC. > > > > I suggest you take a look at http://tools.ietf.org/html/draft-sarikaya-ne= text-pmipv6-shared-link-01 >on Netext for PMIPv6. > > >I'll have a read. But more importantly, it was aimed to solve PMIPv6 problem of establishing = point-to-point link on an important shared links like 802.11. Actually there are other ways of doing that, mainly in Layer 2. > >I believe that we should use multicast delivery as much as possible on the= downlink if the link is a shared link. > > > > >I agree with using multicast as much as possible to reduce duplicate packe= ts sent over the network. The proposal here is to use packet replication an= d link-layer unicasts when doing so would either exceed the performance of = link-layer multicast and/or overcome the negative effects of link-layer mul= ticast, such as when larger volumes of multicast traffic impact unicast per= formance on the same link. Both of these issues occur on 802.11 links when = there volume of multicast traffic is in the order of a few megabits (or les= s, I've been testing with around 2.5 Mbps of video) > > >The main use case I've been thinking about (which I'll make more obvious i= n the next revision), is a multicast IPTV service scenario towards a reside= ntial customer, where the residential customer has a 802.11 network in thei= r home rather than a wired one. IPv6 multicast/link-layer multicast would b= e used all the way from the multicast source servers, across the service pr= ovider network, up until the CPE in the residential customers' homes, gaini= ng the efficiencies of multicast. However, the CPE in the customer's house = would then use IPv6 multicast/link-layer unicast of the IPTV traffic over t= he 802.11 link to the customers end-hosts, saving them having to put in wir= ed infrastructure, or resorting to buying ethernet over power devices to ma= ke their power cabling their wired infrastructure. Note that there is still= a low level of link-layer multicast traffic in the customers home, for RAs= , ND, MLDv2 messages, DHCPv6, etc.. This proposal is not eliminating link-layer multicasts, just reducing them where possible and where useful. > > >That's not to say this proposal is only useful in an 802.11 scenario. It c= ould be used in any scenario where packet replication and link-layer unicas= ting would provide useful benefits over link-layer multicasts. It generally= increases the data confidentiality of the multicast IPv6 traffic, and may = help increase battery life of some devices. > Well, you preached your case quite well. But the main problem is with 802.11 multicast which uses the lowest bandwid= th channel. So you are proposing to change multicast to unicast delivery wi= th copying to cope with this problem. Let this be well understood. I would suggest changing 802.11 multicast though. Also, I have concerns on the copying: it seems like copying will be based o= n neighbor discovery cash. I think it is rather strange. Another point is that point to point link is another solution. Regards, Behcet --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFFA224tk5ex14mbxc272r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Behcet,=

 <= /p>

If you want to change 802= .11 multicast, you ought to do that in the IEEE 802.11 working groups, not = in the IETF. As far as we are concerned, 802.11 specifications are a constraint.

 <= /p>

It is a fact that multica= st over 802.11 is very inefficient, and not appropriate for multicast high = volumes to few receivers. When the number of intended recipients is small, it is much more efficient to send individual copies to each reci= pient than to try to use the 802.11 multicast service. There is probably a = case to be made that if the number of recipient is very large multicast bec= omes a better solution, but I suspect that this very large number is too large for practical applications.<= /o:p>

 <= /p>

So, yes, it is a fairly g= ood idea to study how multicast delivery could be accomplished by a series = of unicast transmission.

 <= /p>

-- Christian Huitema=

 <= /p>

 <= /p>

 <= /p>

From: ipv6-b= ounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Monday, April 1, 2013 8:33 AM
To: Mark Smith
Cc: mboned@ietf.org; 6man@ietf.org; Dave Thaler
Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast = Delivery of Multicast"

 

Hi Mark,

 

On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith <markzzzsmith@yah= oo.com.au> wrote:

Hi Behcet,

Thanks for your review and comments.



>________________________________
> From: Behcet Sarikaya <sa= rikaya2012@gmail.com>
>To: Dave Thaler <dthaler@mi= crosoft.com>
>Cc: Mark Smith <markzzz= smith@yahoo.com.au>; "6man@iet= f.org" <6man@ietf.org>;= "mboned@ietf.org" <mboned@ietf.org>
>Sent: Saturday, 30 March 2013 8:33 AM
>Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Del= ivery of Multicast"

>
>
>Hi Mark,
>
>I read your draft.
>First of all I think you misunderstood RFC 6085 and based on a wrong as= sumption you developed your solution.
>
>

>What specifically do you think I've misunderstoo= d? I was involved in some of the conversations about that RFC while it was = an ID, and all I think it really is fundamentally saying is that an IPv6 pa= cket with a multicast IPv6 destination address isn't required to have a link-layer multicast destination address = - it can be a link-layer unicast destination address if useful or necessary= .

> 

 

Really, because I think no one knows how the ID beca= me an RFC.
 

> 

 

 

 

>
>
> I suggest you take a look at http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01<= br> >on Netext for PMIPv6.
>
>

>I'll have a read.

 

But more importantly,= it was aimed to solve PMIPv6 problem of establishing point-to-point link o= n an important shared links like 802.11.

Actually there are ot= her ways of doing that, mainly in Layer 2. 

>
>I believe that we should use multicast delivery as much as possible on = the downlink if the link is a shared link.
>
>
>
>

>I agree with using multicast as much as possible= to reduce duplicate packets sent over the network. The proposal here is to= use packet replication and link-layer unicasts when doing so would either = exceed the performance of link-layer multicast and/or overcome the negative effects of link-layer multicast, su= ch as when larger volumes of multicast traffic impact unicast performance o= n the same link. Both of these issues occur on 802.11 links when there volu= me of multicast traffic is in the order of a few megabits (or less, I've been testing with around 2.5 Mbps o= f video)
>
>
>The main use case I've been thinking about (which I'll make more obviou= s in the next revision), is a multicast IPTV service scenario towards a res= idential customer, where the residential customer has a 802.11 network in t= heir home rather than a wired one. IPv6 multicast/link-layer multicast would be used all the way from the mul= ticast source servers, across the service provider network, up until the CP= E in the residential customers' homes, gaining the efficiencies of multicas= t. However, the CPE in the customer's house would then use IPv6 multicast/link-layer unicast of the IPTV traffic= over the 802.11 link to the customers end-hosts, saving them having to put= in wired infrastructure, or resorting to buying ethernet over power device= s to make their power cabling their wired infrastructure. Note that there is still a low level of link-layer m= ulticast traffic in the customers home, for RAs, ND, MLDv2 messages, DHCPv6= , etc.. This proposal is not eliminating
 link-layer multicasts, just reducing them where possible and where us= eful.
>
>
>That's not to say this proposal is only useful in an 802.11 scenario. I= t could be used in any scenario where packet replication and link-layer uni= casting would provide useful benefits over link-layer multicasts. It genera= lly increases the data confidentiality of the multicast IPv6 traffic, and may help increase battery life of some = devices.
>

 

Well, you preached yo= ur case quite well.

But the main problem = is with 802.11 multicast which uses the lowest bandwidth channel. So you ar= e proposing to change multicast to unicast delivery with copying  to c= ope with this problem.

Let this be well unde= rstood.

I would suggest chang= ing 802.11 multicast though.

Also, I have concerns= on the copying: it seems like copying will be based on neighbor discovery = cash.

I think it is rather = strange.

Another point is that= point to point link is another solution.

Regards,

Behcet

 

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFFA224tk5ex14mbxc272r_-- From sarikaya2012@gmail.com Mon Apr 1 10:17:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D672421F9060; Mon, 1 Apr 2013 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoMqTuSXs2IB; Mon, 1 Apr 2013 10:17:53 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 73BDD21F905F; Mon, 1 Apr 2013 10:17:51 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id x11so2145378lbi.1 for ; Mon, 01 Apr 2013 10:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=twRoZOKSuwvzaSJT+WVLvgErQu/IpOpJy8+LQc5r7mA=; b=S5iIj2dS3zxZ5f2BTyqRf+cVa3AwyT3gylohjyfMxi1u1NyTfH8X+Y24bzzZKll0oe KIsIuenwj10lqvXJ++klWbSShB/lOwVmDaqhFoNC8zvrnBZqU7Xl6pIFhlitkW26pIHK UKy9WVJD4a/kufNNbUJk9uXFnZoiXhoxfBejyVsvxUwhNl0j4Vc4jZVeqJ8+mpu9QoQR ICDr+lcwqVMIED6jYu31zN/Mmr0bgu3qdCyM3oEadIQray16EYHU/x427f4hFEAIIFTS gFq5fBAj/tPPkXD9tZK5gZORi4NeSTJ8VpUvo/WtLsS4NdiX3ibDZIW0Z4cu1Y4HZQNU FOBg== MIME-Version: 1.0 X-Received: by 10.112.85.37 with SMTP id e5mr3326422lbz.43.1364836670080; Mon, 01 Apr 2013 10:17:50 -0700 (PDT) Received: by 10.114.17.104 with HTTP; Mon, 1 Apr 2013 10:17:49 -0700 (PDT) In-Reply-To: References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Mon, 1 Apr 2013 12:17:49 -0500 Message-ID: Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" From: Behcet Sarikaya To: Christian Huitema Content-Type: multipart/alternative; boundary=bcaec55553bce590fc04d94fccbe Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:17:55 -0000 --bcaec55553bce590fc04d94fccbe Content-Type: text/plain; charset=ISO-8859-1 Bonjour Christian, On Mon, Apr 1, 2013 at 11:55 AM, Christian Huitema wrote: > Behcet,**** > > ** ** > > If you want to change 802.11 multicast, you ought to do that in the IEEE > 802.11 working groups, not in the IETF. As far as we are concerned, 802.11 > specifications are a constraint. **** > > ** ** > > It is a fact that multicast over 802.11 is very inefficient, and not > appropriate for multicast high volumes to few receivers. When the number of > intended recipients is small, it is much more efficient to send individual > copies to each recipient than to try to use the 802.11 multicast service. > There is probably a case to be made that if the number of recipient is very > large multicast becomes a better solution, but I suspect that this very > large number is too large for practical applications.**** > > ** > As far as I know, the operators prefer native multicast for IPTV applications, for a good reason. It seem like this is the application that Mark has in mind. ** > > So, yes, it is a fairly good idea to study how multicast delivery could be > accomplished by a series of unicast transmission.**** > > ** > Sure, I am not against investigations, studies, research. I am all for it. Behcet > ** > > -- Christian Huitema**** > > ** ** > > ** ** > > ** ** > > *From:* ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] *On Behalf > Of *Behcet Sarikaya > *Sent:* Monday, April 1, 2013 8:33 AM > *To:* Mark Smith > *Cc:* mboned@ietf.org; 6man@ietf.org; Dave Thaler > > *Subject:* Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery > of Multicast"**** > > ** ** > > Hi Mark,**** > > ** ** > > On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith > wrote:**** > > Hi Behcet, > > Thanks for your review and comments. > > > > >________________________________ > > From: Behcet Sarikaya > >To: Dave Thaler > >Cc: Mark Smith ; "6man@ietf.org" < > 6man@ietf.org>; "mboned@ietf.org" > >Sent: Saturday, 30 March 2013 8:33 AM > >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery > of Multicast"**** > > > > > > >Hi Mark, > > > >I read your draft. > >First of all I think you misunderstood RFC 6085 and based on a wrong > assumption you developed your solution. > > > >**** > > >What specifically do you think I've misunderstood? I was involved in some > of the conversations about that RFC while it was an ID, and all I think it > really is fundamentally saying is that an IPv6 packet with a multicast IPv6 > destination address isn't required to have a link-layer multicast > destination address - it can be a link-layer unicast destination address if > useful or necessary.**** > > >** ** > > ** ** > > Really, because I think no one knows how the ID became an RFC. > **** > > >** ** > > ** ** > > ** ** > > **** > > > > > > > I suggest you take a look at > http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 > >on Netext for PMIPv6. > > > >**** > > >I'll have a read.**** > > ** ** > > But more importantly, it was aimed to solve PMIPv6 problem of establishing > point-to-point link on an important shared links like 802.11.**** > > Actually there are other ways of doing that, mainly in Layer 2. **** > > > > >I believe that we should use multicast delivery as much as possible on > the downlink if the link is a shared link. > > > > > > > >**** > > >I agree with using multicast as much as possible to reduce duplicate > packets sent over the network. The proposal here is to use packet > replication and link-layer unicasts when doing so would either exceed the > performance of link-layer multicast and/or overcome the negative effects of > link-layer multicast, such as when larger volumes of multicast traffic > impact unicast performance on the same link. Both of these issues occur on > 802.11 links when there volume of multicast traffic is in the order of a > few megabits (or less, I've been testing with around 2.5 Mbps of video) > > > > > >The main use case I've been thinking about (which I'll make more obvious > in the next revision), is a multicast IPTV service scenario towards a > residential customer, where the residential customer has a 802.11 network > in their home rather than a wired one. IPv6 multicast/link-layer multicast > would be used all the way from the multicast source servers, across the > service provider network, up until the CPE in the residential customers' > homes, gaining the efficiencies of multicast. However, the CPE in the > customer's house would then use IPv6 multicast/link-layer unicast of the > IPTV traffic over the 802.11 link to the customers end-hosts, saving them > having to put in wired infrastructure, or resorting to buying ethernet over > power devices to make their power cabling their wired infrastructure. Note > that there is still a low level of link-layer multicast traffic in the > customers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal is > not eliminating > link-layer multicasts, just reducing them where possible and where useful. > > > > > >That's not to say this proposal is only useful in an 802.11 scenario. It > could be used in any scenario where packet replication and link-layer > unicasting would provide useful benefits over link-layer multicasts. It > generally increases the data confidentiality of the multicast IPv6 traffic, > and may help increase battery life of some devices. > >**** > > ** ** > > Well, you preached your case quite well.**** > > But the main problem is with 802.11 multicast which uses the lowest > bandwidth channel. So you are proposing to change multicast to unicast > delivery with copying to cope with this problem.**** > > Let this be well understood.**** > > I would suggest changing 802.11 multicast though.**** > > Also, I have concerns on the copying: it seems like copying will be based > on neighbor discovery cash.**** > > I think it is rather strange.**** > > Another point is that point to point link is another solution.**** > > Regards,**** > > Behcet**** > > ** ** > --bcaec55553bce590fc04d94fccbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bonjour Christian,

=
On Mon, Apr 1, 2013 at 11:55 AM, Christian H= uitema <huitema@microsoft.com> wrote:

Behcet,

=A0<= /p>

If you want to change 802= .11 multicast, you ought to do that in the IEEE 802.11 working groups, not = in the IETF. As far as we are concerned, 802.11 specifications are a constraint.

=A0<= /p>

It is a fact that multica= st over 802.11 is very inefficient, and not appropriate for multicast high = volumes to few receivers. When the number of intended recipients is small, it is much more efficient to send individual copies to each reci= pient than to try to use the 802.11 multicast service. There is probably a = case to be made that if the number of recipient is very large multicast bec= omes a better solution, but I suspect that this very large number is too large for practical applications.

=A0


As far as I know, the operators pr= efer native multicast for IPTV applications, for a good reason.
It seem like this is the application that=A0 Mark has in mind.

So, yes, it is a fairly g= ood idea to study how multicast delivery could be accomplished by a series = of unicast transmission.

=A0


Sure, I am not against investigati= ons, studies, research. I am all for it.

Behcet
=A0

-- Christian Huitema

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: ipv6-bounces@ietf.org<= /a> [mailto:ipv6= -bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Monday, April 1, 2013 8:33 AM
To: Mark Smith
Cc: mboned@ietf= .org; 6man@ietf.org<= /a>; Dave Thaler

=A0

Hi Mark,

=A0

On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith <markzzzsmith@yah= oo.com.au> wrote:

Hi Behcet,

Thanks for your review and comments.



>________________________________
> From: Behcet Sarikaya <sarikaya2012@gmail.com>
>To: Dave Thaler <dthaler@microsoft.com>
>Cc: Mark Smith <markzzzsmith@yahoo.com.au>; "6man@ietf.org" <6man@ietf.org>; "mboned@ietf.org" <mboned@ietf.org>
>Sent: Saturday, 30 March 2013 8:33 AM
>Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Del= ivery of Multicast"

>
>
>Hi Mark,
>
>I read your draft.
>First of all I think you misunderstood RFC 6085 and based on a wrong as= sumption you developed your solution.
>
>

>What specifically do you think I've misunder= stood? I was involved in some of the conversations about that RFC while it = was an ID, and all I think it really is fundamentally saying is that an IPv= 6 packet with a multicast IPv6 destination address isn't required to have a link-layer multicast destination addr= ess - it can be a link-layer unicast destination address if useful or neces= sary.

>=A0

=A0

Really, because I think no one knows how the ID beca= me an RFC.
=A0

>=A0

=A0

=A0

=A0

>
>
>=A0I suggest you take a look at http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01<= br> >on Netext for PMIPv6.
>
>

>I'll have a read.

=A0

But more importantly,= it was aimed to solve PMIPv6 problem of establishing point-to-point link o= n an important shared links like 802.11.

Actually there are ot= her ways of doing that, mainly in Layer 2.=A0

>
>I believe that we should use multicast delivery as much as possible on = the downlink if the link is a shared link.
>
>
>
>

>I agree with using multicast as much as possible= to reduce duplicate packets sent over the network. The proposal here is to= use packet replication and link-layer unicasts when doing so would either = exceed the performance of link-layer multicast and/or overcome the negative effects of link-layer multicast, su= ch as when larger volumes of multicast traffic impact unicast performance o= n the same link. Both of these issues occur on 802.11 links when there volu= me of multicast traffic is in the order of a few megabits (or less, I've been testing with around 2.5 Mb= ps of video)
>
>
>The main use case I've been thinking about (which I'll make mor= e obvious in the next revision), is a multicast IPTV service scenario towar= ds a residential customer, where the residential customer has a 802.11 netw= ork in their home rather than a wired one. IPv6 multicast/link-layer multicast would be used all the way from the mul= ticast source servers, across the service provider network, up until the CP= E in the residential customers' homes, gaining the efficiencies of mult= icast. However, the CPE in the customer's house would then use IPv6 multicast/link-layer unicast of the IPTV traffic= over the 802.11 link to the customers end-hosts, saving them having to put= in wired infrastructure, or resorting to buying ethernet over power device= s to make their power cabling their wired infrastructure. Note that there is still a low level of link-layer m= ulticast traffic in the customers home, for RAs, ND, MLDv2 messages, DHCPv6= , etc.. This proposal is not eliminating
=A0link-layer multicasts, just reducing them where possible and where usefu= l.
>
>
>That's not to say this proposal is only useful in an 802.11 scenari= o. It could be used in any scenario where packet replication and link-layer= unicasting would provide useful benefits over link-layer multicasts. It ge= nerally increases the data confidentiality of the multicast IPv6 traffic, and may help increase battery life of some = devices.
>

=A0

Well, you preached yo= ur case quite well.

But the main problem = is with 802.11 multicast which uses the lowest bandwidth channel. So you ar= e proposing to change multicast to unicast delivery with copying=A0 to cope= with this problem.

Let this be well unde= rstood.

I would suggest chang= ing 802.11 multicast though.

Also, I have concerns= on the copying: it seems like copying will be based on neighbor discovery = cash.

I think it is rather = strange.

Another point is that= point to point link is another solution.

Regards,

Behcet

=A0


--bcaec55553bce590fc04d94fccbe-- From huitema@microsoft.com Mon Apr 1 11:18:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCA41F0D1B; Mon, 1 Apr 2013 11:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmgyRjB2rXyw; Mon, 1 Apr 2013 11:18:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAC71F0CE0; Mon, 1 Apr 2013 11:18:43 -0700 (PDT) Received: from BY2FFO11FD007.protection.gbl (10.1.15.203) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 1 Apr 2013 18:18:32 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Mon, 1 Apr 2013 18:18:32 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.126]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 1 Apr 2013 18:18:26 +0000 From: Christian Huitema To: "sarikaya@ieee.org" Subject: RE: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Thread-Topic: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Thread-Index: AQHOLvziQC8FSmpZF0aDAcXTjmWUMJjBp+Lw Date: Mon, 1 Apr 2013 18:18:25 +0000 Message-ID: References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(51704002)(54316002)(47736001)(66066001)(16406001)(76482001)(79102001)(81342001)(46102001)(23756002)(54356001)(56776001)(77982001)(47976001)(49866001)(55846006)(53806001)(65816001)(63696002)(47776003)(59766001)(74502001)(33656001)(69226001)(51856001)(50986001)(44976002)(50466001)(80022001)(74662001)(56816002)(20776003)(47446002)(31966008)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0803A0241F Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:18:44 -0000 > As far as I know, the operators prefer native multicast for IPTV applicat= ions, for a good reason. > It seem like this is the application that=A0 Mark has in mind. > >>So, yes, it is a fairly good idea to study how multicast delivery could b= e accomplished by a series of unicast transmission. =A0 There are two solutions today: multicast all the way, from the source to th= e various destinations; and, unicast all the way. The multicast solution su= ffers from very poor performance on the 802.11 network. The unicast solutio= n prevents bandwidth optimization in the distribution network. The "best" s= olution would combine unicast on 802.11 networks and multicast on the distr= ibution network. That requires protocol changes, so that an 802.11 node tha= t subscribes to a multicast group effectively gets unicast delivery from th= e wireless router, while the wireless router gets multicast delivery from t= he network router. That's what Mark's draft is attempting to define. That s= eems like a fine project. Of course that's not an easy project, and there are many details that need = to get solved. For example, allowing multicast delivery to arrive over unic= ast addresses may well have some interesting security implications. Then th= ere is the matter of "multiplying" the multicast packets, which is prone to= create instant congestion in the router. Then there is the decision logic = on when to choose multicast versus unicast delivery. Oh, and doing all that= without an explosion in complexity... Of course, we can observe that unicast delivery can be implemented today us= ing end-to-end procedures. Makes you really wonder whether the right way to= optimize bandwidth for multicast content delivery is a new version of IP f= orwarding standards, or instead some form of compression on the distributio= n links. -- Christian Huitema From stig@venaas.com Mon Apr 1 11:34:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8EF21F8D5F for ; Mon, 1 Apr 2013 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKjmngOBrpli for ; Mon, 1 Apr 2013 11:34:40 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 465FC21F8D2D for ; Mon, 1 Apr 2013 11:34:40 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6606E8030; Mon, 1 Apr 2013 20:34:38 +0200 (CEST) Message-ID: <5159D302.3040000@venaas.com> Date: Mon, 01 Apr 2013 11:33:38 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mark Smith Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <33683AD5-E397-4378-84E4-05A34BC1AA4D@tzi.org> <1364550740.65335.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1364550740.65335.YahooMailNeo@web142505.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:34:41 -0000 Hi Interesting draft. I need to think more about it, but I have a comment below. On 3/29/2013 2:52 AM, Mark Smith wrote: > Hi Carsten, > > Thanks very much for your review and comments. > > > ----- Original Message ----- >> From: Carsten Bormann >> To: Mark Smith >> Cc: "6man@ietf.org" <6man@ietf.org> >> Sent: Friday, 29 March 2013 7:21 PM >> Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" >> >> Hi Mark, >> >> interesting draft. I'm interested in this from a 6LoWPAN perspective -- >> everything we can do to get rid of multicasts is very good for 6LoWPANs. >> >> I don't understand how you think NUD would work with this (3.2) -- are you >> saying that the multicast emitter actively runs NUD to the targets? >> > > Yes. NUD is performed on the link-local addresses used as the source addresses for the MLDv2 messages. > > Originally when I was thinking about this, I thought that might be one of the things that would need to be changed. However, when I reviewed the part of RFC3810 (MLDv2) related to MLD Report source addresses, I came across the following in 5.2.13, "Source Addresses for Reports": > > On the other hand, routers MUST silently discard a message that is > not sent with a valid link-local address, without taking any action > on the contents of the packet. Thus, a Report is discarded if the > router cannot identify the source address of the packet as belonging > to a link connected to the interface on which the packet was > received. A Report sent with the unspecified address is also > discarded by the router. This enhances security, as unidentified > reporting nodes cannot influence the state of the MLDv2 router(s). > > It seems to me that the only way to be sure a MLDv2 source link-local address is valid and belongs to the link is to test it's existence, which is of course what neighbor discovery does using an NS/NA transaction. So the existing ND neighor presence discovery mechanism can, and I think the above implies should be used to determine MLDv2 link-local source address validity, and therefore the ND NUD mechanism can then be used to determine when the neighbor disappears, and therefore link-layer unicasting of mulicast IPv6 should stop for that now absent listener. > > (Out of interest, I checked to see if this sort of link-local address validity checking is being performed by Linux and one of the BSDs (I can't remember which one). Neither of them did, all they checked was that the source address of the MLDv2 report was a link-local address. So they're vulnerable to MLDv2 reports with spoofed, non-existent link-local addresses ...) I'm not at all surprised it's not checked. But note that even if such a check is in place, there is a certain risk of spoofing. It's not that hard to guess some valid link-local addresses. E.g. if SLAAC, just look at the global addresses used. I'm wondering a bit if we should have, or maybe still should, use hop limit 255 for MLDv2. Stig >> MLDv2 is a protocol that runs between multicast listeners and multicast routers. >> How do you handle multicast emitters that aren't multicast routers? >> > > The main use case scenario I've been thinking about is multicast IPTV over a carrier network, towards a residential customer, where the last hop in the customer's home is 802.11, and where the multicast performance problems appear. So the multicast source servers would be wired, and on segments where the volumes of multicast traffic didn't impact link performance. > > My main overriding goals were to avoid changes to the end-hosts, leaving changes to be made to the multicast router's behaviour (e.g. residential CPE), and to reduce the number of multicasts as much as possible, but not eliminate them. Low levels of multicast on 802.11 works ok, it's the high levels that cause problems. > > If a host implementation can be changed, then it could implement the procedures I've described. It could listen to the MLDv2 reports (as non-Querier multicast routers do), do neighbor discovery/NUD on the MLDv2 source link-local addresses, and then proceed to link-layer unicast the multicast IPv6 traffic to its on-link neighbors. > >> How do you wean MLDv2 itself off multicast? (Now that would be my holy grail. >> We didn't get around to do this in RFC 6775 -- we didn't think we'd >> have to, since we were addressing a subnet where subnet-multicast doesn't >> work at all.) Maybe efficient-ND could do something here. >> > > I've put a little bit of thought into this. If you're able to change the host and the router implementations, then I've thought might be able to eliminate multicasts by treating the broadcast/multicast link as a Non-Broadcast Multi-Access link, and then use RFC2491, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" methods. Briefly looking at it, it does mention how to handle the SMDS link layer, and my understanding is that was a connectionless (rather than a connection oriented) NBMA link-layer, so treating 802.11 or 802.3 as an NMBA link could probably use the NBMA IPv6 techniques used for SMDS. > > Regards, > Mark. > >> Grüße, Carsten >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From albert.e.manfredi@boeing.com Mon Apr 1 12:35:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B018721F8714 for ; Mon, 1 Apr 2013 12:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FUU-Zgwt6lj for ; Mon, 1 Apr 2013 12:35:41 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 23FDD21F86F2 for ; Mon, 1 Apr 2013 12:35:41 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r31JaBct018425 for ; Mon, 1 Apr 2013 12:36:11 -0700 Received: from XCH-PHX-304.sw.nos.boeing.com (xch-phx-304.sw.nos.boeing.com [137.136.239.26]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r31Ja9Dp018409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 1 Apr 2013 12:36:10 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.40]) by XCH-PHX-304.sw.nos.boeing.com ([169.254.4.165]) with mapi id 14.02.0328.011; Mon, 1 Apr 2013 12:35:38 -0700 From: "Manfredi, Albert E" To: Scott Brim Subject: RE: I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOLtwqXX/TGDug6EeW/Y9bKB8hdpjBv2FA Date: Mon, 1 Apr 2013 19:35:37 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648101DB2C@XCH-PHX-503.sw.nos.boeing.com> References: <515733A5.8080509@gmail.com> <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> <51598A3D.20108@internet2.edu> In-Reply-To: <51598A3D.20108@internet2.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "fgont@si6networks.com" , Alexandru Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:35:41 -0000 Scott, If the only goal is in-vehicle, then clearly ULAs are the answer, and there= 's nothing more to be discussed. And for that matter, RFC 1918 addresses an= d IPv4 would be more than adequate. Limiting comms to in-vehicle does not r= equire any global uniqueness of addresses. I think the model to follow here is more like E.164 uniform resource identi= fiers (ENUM, RFC 3761). In enum, the telephone numbers are not hard-coded i= n the IP address. Rather, they become a DNS entry. Seems to me that any pla= n on using the uniqueness of the VIN number for cars should follow this sam= e approach. Not saying that this DNS approach would answer all vehicle comms issues to = be resolved, though. For example, for self-driving vehicles, there would be= a need for more real-time (perhaps at layer 2) comms between adjacent cars= and between cars and the roadway. E.g. some way of a car with an impending= problem to be shuttled off to the emergency lanes, to get out of the way o= f the moving traffic. Bert > -----Original Message----- > From: Scott Brim [mailto:swb@internet2.edu] > Sent: Monday, April 01, 2013 9:23 AM > To: Manfredi, Albert E > Cc: Alexandru Petrescu; fgont@si6networks.com; 6man > Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt >=20 > The scope of the draft was more or less restricted to in-vehicle > communications because of the privacy concerns ("The focus of this work > is to enable in-vehicle networks to exchange packets with VIN-based > IPv6 > addresses." -- although inter-vehicle communications is still a big > deal > under use cases), so I don't think use of DNS, etc., apply. If the > draft isn't really restricted to in-vehicle communications I have a > number of architectural arguments about why it's a bad idea. VINs are > neither topological locators nor IP endpoint identifiers, and trying to > map them onto either causes confusion. They're fine as higher layer > tokens. >=20 > Scott From albert.e.manfredi@boeing.com Mon Apr 1 13:07:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BCF11E80E9; Mon, 1 Apr 2013 13:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k6tNLE-I2MH; Mon, 1 Apr 2013 13:07:00 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id AB98611E80E6; Mon, 1 Apr 2013 13:07:00 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r31K70N8008543; Mon, 1 Apr 2013 13:07:00 -0700 Received: from XCH-PHX-107.sw.nos.boeing.com (xch-phx-107.sw.nos.boeing.com [137.136.238.10]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r31K6xP6008540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 1 Apr 2013 13:07:00 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.40]) by XCH-PHX-107.sw.nos.boeing.com ([169.254.7.18]) with mapi id 14.02.0328.011; Mon, 1 Apr 2013 13:06:59 -0700 From: "Manfredi, Albert E" To: Christian Huitema Subject: RE: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Thread-Topic: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Thread-Index: AQHOLu5ER0gpJyA0QU2iZjxrEGp5mJjCCtKAgAAGVYCAABDugP//pEKw Date: Mon, 1 Apr 2013 20:06:58 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648101DBAC@XCH-PHX-503.sw.nos.boeing.com> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:07:03 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Christian Huitema > There are two solutions today: multicast all the way, from the source > to the various destinations; and, unicast all the way. The multicast > solution suffers from very poor performance on the 802.11 network. The > unicast solution prevents bandwidth optimization in the distribution > network. The "best" solution would combine unicast on 802.11 networks > and multicast on the distribution network. That requires protocol > changes, so that an 802.11 node that subscribes to a multicast group > effectively gets unicast delivery from the wireless router, while the > wireless router gets multicast delivery from the network router. That's > what Mark's draft is attempting to define. That seems like a fine > project. Agree. I thought the proposal was to retain the IP header as is, i.e. a Cla= ss D destination address, but to use the unique MAC address at layer 2 (RFC= 6085). To find the individual MAC address, I thought the plan was to use t= he source IP in the IGMP join, and then find the MAC the old fashioned way. Seems like a useful workaround. I think it should be in IETF's scope. Bert From fgont@si6networks.com Mon Apr 1 13:11:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8A721F9132 for ; Mon, 1 Apr 2013 13:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiGg6CBnCl9P for ; Mon, 1 Apr 2013 13:11:27 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBC721F9125 for ; Mon, 1 Apr 2013 13:11:27 -0700 (PDT) Received: from [186.134.3.135] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UMl4a-000700-QA; Mon, 01 Apr 2013 22:11:21 +0200 Message-ID: <5159E9E1.7020909@si6networks.com> Date: Mon, 01 Apr 2013 17:11:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexandru Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:11:28 -0000 On 03/31/2013 07:39 PM, Manfredi, Albert E wrote: > Alexandru Petrescu wrote: > >> I meant to say that this VIN mapping to an IPv6 address may be >> useful not only to newly manufactured vehicles, but also to old >> vehicles. [....] > > A VIN is a fine unique identifier to use in the DNS, though. And > potentially other similar unique identifiers for different components > of each car. E.g., the DNS could have vitalreadings..car > entries, or electicalsystem..car, or > enginediagnostics..car, or numerous entries to identify an ever > growing number interfaces that a car should be expected to sprout, in > the coming decades. > > How you find the moving car from the DNS entry would be same as for > any other mobile client. Using the same set of solutions. This is my view as well. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From markzzzsmith@yahoo.com.au Mon Apr 1 13:39:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C7121E80CD for ; Mon, 1 Apr 2013 13:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cey3jxYjK0mG for ; Mon, 1 Apr 2013 13:39:25 -0700 (PDT) Received: from nm32-vm5.bullet.mail.bf1.yahoo.com (nm32-vm5.bullet.mail.bf1.yahoo.com [72.30.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 580A021E80C0 for <6man@ietf.org>; Mon, 1 Apr 2013 13:39:25 -0700 (PDT) Received: from [98.139.215.140] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2013 20:39:24 -0000 Received: from [98.139.215.251] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2013 20:39:24 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 01 Apr 2013 20:39:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 630421.31272.bm@omp1064.mail.bf1.yahoo.com Received: (qmail 10800 invoked by uid 60001); 1 Apr 2013 20:39:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1364848764; bh=ZKD7QUHEQTIG2LotRTpSNLnaG403/TIfK1LmGcwQCWI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=p/EWtYotjXrUPtR60I6Gkz8JyyVWfRTCbFNkKoOcm+jBhop+PaYMy2JSMJz2bwODu5Fv1tlI2R0aW1aq6XRe8PRvmUacvYyZ/AdobNPxbhVsPGSMpPbPXqmTYBCcfd2/vD4XErbwICjM18gtwjCXlY0k3CuSVTlThQ1R1u/wZEs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=14GhsorFbbzd/TuzbLOvY9aN8unQWZAZjdXYpPJ/CL97cWhMx/nHy3Gv1IAnI+Chk7xGlfDE143CmkMd/sWJu57o6gz5JNYEjvEhdf8fjly+Ox/bT2g02+EkK0X0QFxBptiPSFLjSZ2gPS+KZCFOcfqCPD5z96JKqf9a6x2+2/s=; X-YMail-OSG: 7E92uEAVM1nlryeFzbAOuoGio4dn0hq6qKPFuo7AtrTobIJ NgDf.mlt0iOkIIXIb2Dw0FiMdyTNx4slqEkXFu3B1Zsk1rdR1zZo5lGmLXEA y.7SiP0X7NRZFY2D9PVl2LBU37lDjuMiVdnLevDLLJPTqWlGM9Ydu3lcHNz8 X90h9ij0kiQKnxSYa5TP320XABhj41swUcbfqvFhCrAaILnL8rbZF8D6SJDd DNhEujhu0Rr2E5AtCXjMZMilD6fY1M9BiH2WDyWlK4pOsgiBDt2604806Pwe ohq0czWyTGX8OT1_lEZX5Ak4e3rKV0ASBETYvJvMSFlCWCAYh35Ken9q2lm5 PX06xZs2BsdZtuCO5PMpEwwHrI.Yw1T9F5e8qjVo4_3FBNbx1eDtw0G_4N0e Y0wV9SZ1GM8E4IwoCvQCczdk8pBKmZwdQ27.C8XYYhrOKfYjVG6ytvKwCCiS FKzaSjQu5ldHFdCGxil0sWrYTcgXq0a.JI2b1IdN2XXiHyF6lHaiLw4JKRix XAkAlIf8Yy_nafaxR3eqAhuM- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Mon, 01 Apr 2013 13:39:24 PDT X-Rocket-MIMEInfo: 002.001, SGksCgooSSdtIHJlYWRpbmcgYW5kIGhhdmluZyBhIHRoaW5rIGFib3V0IG90aGVyIHBlb3BsZSdzIGVtYWlscywgYnV0IHRoaXMgb25lIGlzIGVhc3kgdG8gcmVzcG9uZCB0bykKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogIk1hbmZyZWRpLCBBbGJlcnQgRSIgPGFsYmVydC5lLm1hbmZyZWRpQGJvZWluZy5jb20.Cj4gVG86IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQG1pY3Jvc29mdC5jb20.Cj4gQ2M6ICJtYm9uZWRAaWV0Zi5vcmciIDxtYm9uZWRAaWV0Zi5vcmc.OyAiNm1hbkABMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <021E64FECA7E5A4699562F4E6671648101DBAC@XCH-PHX-503.sw.nos.boeing.com> Message-ID: <1364848764.9992.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Mon, 1 Apr 2013 13:39:24 -0700 (PDT) From: Mark Smith Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" To: "Manfredi, Albert E" , Christian Huitema In-Reply-To: <021E64FECA7E5A4699562F4E6671648101DBAC@XCH-PHX-503.sw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:39:26 -0000 Hi,=0A=0A(I'm reading and having a think about other people's emails, but t= his one is easy to respond to)=0A=0A=0A----- Original Message -----=0A> Fro= m: "Manfredi, Albert E" =0A> To: Christian Hu= itema =0A> Cc: "mboned@ietf.org" ; = "6man@ietf.org" <6man@ietf.org>=0A> Sent: Tuesday, 2 April 2013 7:06 AM=0A>= Subject: RE: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of= Multicast"=0A> =0A>> -----Original Message-----=0A>> From: ipv6-bounces@= ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of=0A>> Christian Huitem= a=0A> =0A>> There are two solutions today: multicast all the way, from the= source=0A>> to the various destinations; and, unicast all the way. The mu= lticast=0A>> solution suffers from very poor performance on the 802.11 net= work. The=0A>> unicast solution prevents bandwidth optimization in the dis= tribution=0A>> network. The "best" solution would combine unicast on 802.1= 1 =0A> networks=0A>> and multicast on the distribution network. That requi= res protocol=0A>> changes, so that an 802.11 node that subscribes to a mul= ticast group=0A>> effectively gets unicast delivery from the wireless rout= er, while the=0A>> wireless router gets multicast delivery from the networ= k router. That's=0A>> what Mark's draft is attempting to define. That seem= s like a fine=0A>> project.=0A> =0A> Agree. I thought the proposal was to = retain the IP header as is, i.e. a Class D =0A> destination address, but to= use the unique MAC address at layer 2 (RFC 6085). To =0A> find the individ= ual MAC address, I thought the plan was to use the source IP in =0A> the IG= MP join, and then find the MAC the old fashioned way.=0A>=A0=0A=0AYes, that= is exactly what I'm proposing.=0A=0AIt would only require changes on the m= ulticast sender, and it is only combining the functions of MLDv2 and ND to = determine the link-layer unicast address so that it can be used for link-la= yer unicast delivery of the IPv6 multicast packets (i.e. the IPv6 multicast= packet is exactly as originally sent, the link-layer frame is no different= either, other than having a unicast destination address). Initially it app= eared that there would not be any changes required to either MLDv2 or ND to= support this (which is why I haven't got any RFC2119 words in the ID), alt= hough Carsten has pointed out that a minor change would need to be made to = ND so that NUD is used to track the presence of the neighbors for which mul= ticast traffic is being link-layer unicast to.=A0=0A=0ABest regards,=0AMark= .=0A=0A> Seems like a useful workaround. I think it should be in IETF's sco= pe.=0A>=A0=0A> Bert=0A=0A> =0A> -------------------------------------------= -------------------------=0A> IETF IPv6 working group mailing list=0A> ipv6= @ietf.org=0A> Administrative Requests: https://www.ietf.org/mailman/listinf= o/ipv6=0A> ----------------------------------------------------------------= ----=0A> From eckert@cisco.com Mon Apr 1 13:29:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F1521E80AA; Mon, 1 Apr 2013 13:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8eNVYyRJ6NV; Mon, 1 Apr 2013 13:29:21 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3341F21E80B1; Mon, 1 Apr 2013 13:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5109; q=dns/txt; s=iport; t=1364848161; x=1366057761; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=B56cuRAFXm6Xytc3OLa4OtT1DX8m/MQVaraZfuA0GDI=; b=M7Uuwu6XopEaPlOWB3xjQ0gl3F5RNP1tyO4eKAMIFPDg9AdeA3wXS7E8 gCtYfDJADjAWzza6WaQ7FHbF+GiH2lz/qJcqPodryGtfrxODL+rZvNHLW 6WkKFO8vCLTG2IVKAuWs6r5vb6OUXzF8tDOeqGbNpFW/WtyKpJEeNBYIH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYJAG++WVGrRDoH/2dsb2JhbABDgzu/SQQBfBZ0gh8BAQEEAQEBLwE7CwwECw4DAQMBAQEJHgcPBRMfAwYOEwkSh2cDDg3AUIxggQ8RGoEMCwcGgllhA4h6iioFgWaBWwGBH4pRhRuDKxyBNw X-IronPort-AV: E=Sophos;i="4.87,387,1363132800"; d="scan'208";a="77311571" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 01 Apr 2013 20:29:20 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r31KTFdi015717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Apr 2013 20:29:15 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r31KQxZ0011459; Mon, 1 Apr 2013 13:27:14 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r31KQxZN011458; Mon, 1 Apr 2013 13:26:59 -0700 Date: Mon, 1 Apr 2013 13:26:59 -0700 From: Toerless Eckert To: Dave Thaler Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Message-ID: <20130401202659.GF23316@cisco.com> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Mon, 01 Apr 2013 14:29:57 -0700 Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:29:22 -0000 On Fri, Mar 29, 2013 at 08:55:21PM +0000, Dave Thaler wrote: > http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast > is work we did back in 2000 on this same topic. At the time, the draft is written from > the perspective of the 6to4 NBMA link, but the topic was discussed (specifically by those > in the acknowledgements section, and to a lesser extent by the ngtrans WG as a whole) > as being more generally applicable. > > There wasn't significant interest at the time and so the work was dropped > rather than updating the spec to use generic language. I have forgotten everything about it ;-) > > The same concept as in the above was however then used in 2001 in > http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast > (still specific to a particular link type though), which after 11 years is now in the IESG :) > > The most relevant WG is MBoneD. Right ;-) finally. Alas, the AMT solution requires changes to the receiver host, so the solution proposed in Marks draft is easier to deploy for the purpose it has. Cheers Toerless > -Dave > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > Mark Smith > > Sent: Thursday, March 28, 2013 8:22 PM > > To: 6man@ietf.org > > Subject: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" > > > > Hi, > > > > The following is inspired by some work I did in around 2010/2011 on a > > multicast TV service, where residential customers with Wifi networks > > suffered from performance problems, and had to be advised to buy > > ethernet over power devices if they couldn't run wired ethernet to the STB > > attached to their TV. > > > > I've done some experiments on my home wifi network, using VLC, and > > switching between multicast and unicast IPv6 to test the concept. The wifi > > performance issues disappear when the video is delivered via unicast UDP. > > (If people want to play with VLC and IPv6 multicast, email me off-list, as there > > are a few issues e.g. the GUI doesn't accept some of the IPv6 multicast > > parameters that the command line does). > > > > I think there is a possibility the technique could also be applied to > > IGMPv3/ARP, although it depends on whether ARP has been implemented > > in a similar manner to IPv6 ND (e.g. an ARP equivalent to NUD). My > > understanding is that Linux has implemented ARP this way. I'll do some more > > research to verify this. > > > > I though I'd post it to see if there is merit in the idea and it is worth spending > > more of my time on. I looked for a IETF group more suitable to this, but didn't > > seem to be able to find one. If there is one, please let me know. > > > > Review and comments most appreciated. > > > > Thanks very much, > > Mark. > > > > > > ----- Forwarded Message ----- > > > From: "internet-drafts@ietf.org" > > > To: markzzzsmith@yahoo.com.au > > > Cc: > > > Sent: Friday, 29 March 2013 1:45 PM > > > Subject: New Version Notification for > > > draft-smith-mldv2-link-unicast-00.txt > > > > > > > > > A new version of I-D, draft-smith-mldv2-link-unicast-00.txt > > > has been successfully submitted by Mark Smith and posted to the IETF > > > repository. > > > > > > Filename:    draft-smith-mldv2-link-unicast > > > Revision:    00 > > > Title:        MLDv2 Procedures for Link-Layer Unicast Delivery of > > > Multicast > > > IPv6 > > > Creation date:    2013-03-29 > > > Group:        Individual Submission > > > Number of pages: 7 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00. > > > txt > > > Status: > > > http://datatracker.ietf.org/doc/draft-smith-mldv2-link-unicast > > > Htmlized: > > > http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00 > > > > > > > > > Abstract: > > >   Some multi-access link-layer technologies typically not provide > > > good > > >   IPv6 multicast performance, using link-layer multicasts, when the > > >   volume of multicast traffic is significant.  It would be possible > > > to > > >   replicate and then link-layer unicast multicast IPv6 traffic to > > >   interested listeners to overcome these link-layer performance > > >   limitations.  This memo describes MLDv2 and IPv6 neighbor discovery > > >   procedures to support link-layer unicast delivery of multicast IPv6 > > >   traffic. > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www.ietf.org/mailman/listinfo/mboned -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From eckert@cisco.com Mon Apr 1 13:59:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216921E80E0; Mon, 1 Apr 2013 13:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuVf0MLXpmad; Mon, 1 Apr 2013 13:59:13 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DC0FB21E80DC; Mon, 1 Apr 2013 13:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13549; q=dns/txt; s=iport; t=1364849953; x=1366059553; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=FHcDmZut8zLf+8CVTUXQcyEZ8OQcLRP0J6NFybvAw1g=; b=RaGYdEFP/e9yYGbdI79eR4QOQUjew1HqpkeD6pErGg8g10d4Ikm9A1vv hY4hcvvj3MuYerPDSoC/FCrcfzTGLi2Toz4X336Q7CcjPlRbgsy56EVWa +TSnBvq+dWxP9m2s08NZr4rMGMv/b4qqsuM0F+NRfN3NXp3ruPe/2uQ7S M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAG++WVGrRDoJ/2dsb2JhbABDgzu/TnwWdIIfAQEBBAEBAS8BOQILDAQLEQEDAQEBCQwSBw8FDQYfAwYOEwkQAodnAw4NtmgNiVuMYIEJBgoBBoEmCwcGBIM2A4h6iioBBIFiBIFbAYEfilGFG4MrHIEuAQgX X-IronPort-AV: E=Sophos;i="4.87,387,1363132800"; d="scan'208";a="74213622" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 01 Apr 2013 20:59:12 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r31Kx6Oe012763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Apr 2013 20:59:06 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r31KuLic013086; Mon, 1 Apr 2013 13:56:36 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r31KuLlX013084; Mon, 1 Apr 2013 13:56:21 -0700 Date: Mon, 1 Apr 2013 13:56:21 -0700 From: Toerless Eckert To: Mark Smith Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Message-ID: <20130401205621.GG23316@cisco.com> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Mon, 01 Apr 2013 14:29:58 -0700 Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:59:15 -0000 Bunch of comments... 1. What Mark is proposing is being done AFAIK in a variety of products on the market, for example as the "multicast to unicast" eleement of Cisco VideoStream and i think other vendors do this as well. Not sure about IPv6 though, i've only seen it in IPv4. 2. I am always getting annoyed when IPv6 bigots oops: fans unnecessarily constraining solutions to IPv6 only even though they equally apply to IPv4 and, in the case of IP multicast when its clear that the mayority of use for a while will still be IPv4. Its already bad enough that RFC6085 was written only for IPv6 instead of for IPv4 and IPv6. It would be lovely if Marks draft could be modified to cover both IPv4 and IPv6. I can't remember that RFC6085 was given for review to MBoned, or else i'd hae made that comment for it as well. But see 1: in practice existing IPv4 host stacks will wwell receive DMAC-unicast IP multicast packets due to the fundamental separation of L3 and L2 in the architecture of most host stacks. 3. I think a key eleemnt of the draft that should be made more clear in the description is that this mechanism is meant to be incrementally dpeloyable such that the mayority of devices on the (wireless) L2 domain do not have to be changed at all, and that the only expection against them is 2. (RFC6085 or equivalent for IPv4). To achieve this, the only requirement is to run IGMPv3/MLDv2, inhibit MLDv1/IGMPv1v2, and a device that wants to send multicast as unicast into the L2 domain needs to perform explicit tracking of the membership reports to know whom to send unicast copies to. And then there are optimizations such as RFC4861 which should be optional. But having said all this, the fact that this can be done as a local implementation optimization in a device sending IP multicast into the L2 domain (whether thats a router, switch, host or whatever), it also means that this mechanism does not need to change any protocol signaling, and therefore the question is whether this can be standards track or just be informational. 4. I don't particularily think that the operating models presented and the first sentence of the abstract are correct. Sending L2 (wireless) multicast has a lot of benefits, and it has a lot of downsides. It totally depends on what you try to achieve. It is clear that 802.11 is particularily challenged with native L2 multicast because they never defined a good resilience scheme as for unicast but so far not for multicast. Hopefully this will get fixed sometime. As long as thats not the case we definitely have to tke this into account as a constraint, but it would be good to explain the situation correctly in the doc. Wrt. the operational model, i could easily see that one wold start out with unicasting, but then change over to multicasting for a particular group/channel when the total number of receivers tracked and bandwidth sent over the group/channel is too large. You may also limit IP multicast to a particular bitrate, so if a specific receiver can not support that bitrate, it would need to get unicast, and then that unicast might need to be rate-limited so that the receiver downspeeds (assuming it is using ALC which it really should). I am not aware if any product embodies this dyanmicac switching, i am just saying it sounds logical to me ;-) So, given how many policies there could be to improve behavior of multicast over wireless, i think it would be more appropriate to make this draft informational and collect/document/discss these possible policies. Its not as if a specific individual policy seems to be ubiquoutously preferrable, and given how its all local policy on the device sending into the wireless L2, it doesn't seem to be the right place for a standard track doc. Going informational does hopefully not make a difference for this doc being useful, because whether its standards track or not, customers will hopefully put it into RFPs against their wireless equipment. Which also means its a good idea in these type of documents to give sticky names to individual functions such as different type of policies or optimizations, so customes in RFPs can refer to those sticky names (or section numbers). 5. Not being really a protocol extension but logically device-local improvements with a bunch of policies possible makes it also a good candidate for MBoned as opposed to a protocol group (i think... ). Cheers Toerless tracking of that it is consisting purely of mechanisms that the accss-point type device in a On Fri, Mar 29, 2013 at 03:18:06PM -0700, Mark Smith wrote: > Hi Behcet, > > Thanks for your review and comments. > > > > >________________________________ > > From: Behcet Sarikaya > >To: Dave Thaler > >Cc: Mark Smith ; "6man@ietf.org" <6man@ietf.org>; "mboned@ietf.org" > >Sent: Saturday, 30 March 2013 8:33 AM > >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" > > > > > >Hi Mark, > > > >I read your draft. > >First of all I think you misunderstood RFC 6085 and based on a wrong assumption you developed your solution. > > > > > >What specifically do you think I've misunderstood? I was involved in some of the conversations about that RFC while it was an ID, and all I think it really is fundamentally saying is that an IPv6 packet with a multicast IPv6 destination address isn't required to have a link-layer multicast destination address - it can be a link-layer unicast destination address if useful or necessary. > > > > > > > > > > I suggest you take a look at http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 > >on Netext for PMIPv6. > > > > > >I'll have a read. > > > >I believe that we should use multicast delivery as much as possible on the downlink if the link is a shared link. > > > > > > > > > >I agree with using multicast as much as possible to reduce duplicate packets sent over the network. The proposal here is to use packet replication and link-layer unicasts when doing so would either exceed the performance of link-layer multicast and/or overcome the negative effects of link-layer multicast, such as when larger volumes of multicast traffic impact unicast performance on the same link. Both of these issues occur on 802.11 links when there volume of multicast traffic is in the order of a few megabits (or less, I've been testing with around 2.5 Mbps of video) > > > > > >The main use case I've been thinking about (which I'll make more obvious in the next revision), is a multicast IPTV service scenario towards a residential customer, where the residential customer has a 802.11 network in their home rather than a wired one. IPv6 multicast/link-layer multicast would be used all the way from the multicast source servers, across the service provider network, up until the CPE in the residential customers' homes, gaining the efficiencies of multicast. However, the CPE in the customer's house would then use IPv6 multicast/link-layer unicast of the IPTV traffic over the 802.11 link to the customers end-hosts, saving them having to put in wired infrastructure, or resorting to buying ethernet over power devices to make their power cabling their wired infrastructure. Note that there is still a low level of link-layer multicast traffic in the customers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal is not eliminating > link-layer multicasts, just reducing them where possible and where useful. > > > > > >That's not to say this proposal is only useful in an 802.11 scenario. It could be used in any scenario where packet replication and link-layer unicasting would provide useful benefits over link-layer multicasts. It generally increases the data confidentiality of the multicast IPv6 traffic, and may help increase battery life of some devices. > > > > > >Thanks very much, > >Mark. > > > > > > > >Regards, > > > >Behcet > > > > > > > > > >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler wrote: > > > >http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast > >>is work we did back in 2000 on this same topic.   At the time, the draft is written from > >>the perspective of the 6to4 NBMA link, but the topic was discussed (specifically by those > >>in the acknowledgements section, and to a lesser extent by the ngtrans WG as a whole) > >>as being more generally applicable. > >> > >>There wasn't significant interest at the time and so the work was dropped > >>rather than updating the spec to use generic language. > >> > >>The same concept as in the above was however then used in 2001 in > >>http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast > >>(still specific to a particular link type though), which after 11 years is now in the IESG :) > >> > >>The most relevant WG is MBoneD. > >> > >>-Dave > >> > >> > >>> -----Original Message----- > >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >>> Mark Smith > >>> Sent: Thursday, March 28, 2013 8:22 PM > >>> To: 6man@ietf.org > >>> Subject: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" > >>> > >>> Hi, > >>> > >>> The following is inspired by some work I did in around 2010/2011 on a > >>> multicast TV service, where residential customers with Wifi networks > >>> suffered from performance problems, and had to be advised to buy > >>> ethernet over power devices if they couldn't run wired ethernet to the STB > >>> attached to their TV. > >>> > >>> I've done some experiments on my home wifi network, using VLC, and > >>> switching between multicast and unicast IPv6 to test the concept. The wifi > >>> performance issues disappear when the video is delivered via unicast UDP. > >>> (If people want to play with VLC and IPv6 multicast, email me off-list, as there > >>> are a few issues e.g. the GUI doesn't accept some of the IPv6 multicast > >>> parameters that the command line does). > >>> > >>> I think there is a possibility the technique could also be applied to > >>> IGMPv3/ARP, although it depends on whether ARP has been implemented > >>> in a similar manner to IPv6 ND (e.g. an ARP equivalent to NUD). My > >>> understanding is that Linux has implemented ARP this way. I'll do some more > >>> research to verify this. > >>> > >>> I though I'd post it to see if there is merit in the idea and it is worth spending > >>> more of my time on. I looked for a IETF group more suitable to this, but didn't > >>> seem to be able to find one. If there is one, please let me know. > >>> > >>> Review and comments most appreciated. > >>> > >>> Thanks very much, > >>> Mark. > >>> > >>> > >>> ----- Forwarded Message ----- > >>> > From: "internet-drafts@ietf.org" > >>> > To: markzzzsmith@yahoo.com.au > >>> > Cc: > >>> > Sent: Friday, 29 March 2013 1:45 PM > >>> > Subject: New Version Notification for > >>> > draft-smith-mldv2-link-unicast-00.txt > >>> > > >>> > > >>> > A new version of I-D, draft-smith-mldv2-link-unicast-00.txt > >>> > has been successfully submitted by Mark Smith and posted to the IETF > >>> > repository. > >>> > > >>> > Filename:     draft-smith-mldv2-link-unicast > >>> > Revision:     00 > >>> > Title:         MLDv2 Procedures for Link-Layer Unicast Delivery of > >>> > Multicast > >>> > IPv6 > >>> > Creation date:     2013-03-29 > >>> > Group:         Individual Submission > >>> > Number of pages: 7 > >>> > URL: > >>> > http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00. > >>> > txt > >>> > Status: > >>> > http://datatracker.ietf.org/doc/draft-smith-mldv2-link-unicast > >>> > Htmlized: > >>> > http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00 > >>> > > >>> > > >>> > Abstract: > >>> >    Some multi-access link-layer technologies typically not provide > >>> > good > >>> >    IPv6 multicast performance, using link-layer multicasts, when the > >>> >    volume of multicast traffic is significant.  It would be possible > >>> > to > >>> >    replicate and then link-layer unicast multicast IPv6 traffic to > >>> >    interested listeners to overcome these link-layer performance > >>> >    limitations.  This memo describes MLDv2 and IPv6 neighbor discovery > >>> >    procedures to support link-layer unicast delivery of multicast IPv6 > >>> >    traffic. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > The IETF Secretariat > >>> > > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>_______________________________________________ > >>MBONED mailing list > >>MBONED@ietf.org > >>https://www.ietf.org/mailman/listinfo/mboned > >> > > > > > > > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www.ietf.org/mailman/listinfo/mboned -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From cabo@tzi.org Mon Apr 1 15:24:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371B621F8ECA; Mon, 1 Apr 2013 15:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDO9DXdHDIwh; Mon, 1 Apr 2013 15:24:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0421F85A2; Mon, 1 Apr 2013 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r31ML76d003680; Tue, 2 Apr 2013 00:21:07 +0200 (CEST) Received: from [192.168.217.105] (p54894F4F.dip.t-dialin.net [84.137.79.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E9B1D3B69; Tue, 2 Apr 2013 00:21:06 +0200 (CEST) Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130401205621.GG23316@cisco.com> Date: Tue, 2 Apr 2013 00:21:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F498152-0818-4EAB-B33B-888D54F5F03D@tzi.org> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130401205621.GG23316@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1503) Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:24:05 -0000 On Apr 1, 2013, at 22:56, Toerless Eckert wrote: > It is clear that 802.11 is particularily challenged with native L2 = multicast because > they never defined a good resilience scheme as for unicast but so = far not for multicast. > Hopefully this will get fixed sometime. In a MIMO world, the performance gap between unicast and = (indiscriminate) multicast is likely to grow instead of shrink over = time. Another little observation: Fixing this at the adaptation layer (i.e., where IP packets are mapped = into L2) is suboptimal, because you may not have visibility into the = number of member stations per AP. Once you have a few dozen on an AP, = it may make sense to switch back to multicast. For that AP! At the = adaptation layer, you only see the bridged 802 network, so you don't = know how many stations share an AP, and it is difficult to send = multicast to one AP and multi-unicast to another. It seems really hard = to optimize this. Once you have 802.11 (without any per-AP hacks) in = your bridged 802 network, you probably want to do 6085 globally. Pet peeve: We like to make things too "transparent", and then wonder how = they break horribly when you no longer can see what you are doing. -> http://en.wikipedia.org/wiki/Leaky_abstraction Gr=FC=DFe, Carsten From cabo@tzi.org Mon Apr 1 23:35:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C226D21F986B; Mon, 1 Apr 2013 23:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9Y0AFh0thHV; Mon, 1 Apr 2013 23:35:53 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1064921F9814; Mon, 1 Apr 2013 23:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r326ZiAi007181; Tue, 2 Apr 2013 08:35:44 +0200 (CEST) Received: from [192.168.217.105] (p54894F4F.dip.t-dialin.net [84.137.79.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 102443BE5; Tue, 2 Apr 2013 08:35:44 +0200 (CEST) Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130402014836.GI23316@cisco.com> Date: Tue, 2 Apr 2013 08:35:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F57262A-9403-45AA-AFB3-D46D506F4459@tzi.org> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130401205621.GG23316@cisco.com> <5F498152-0818-4EAB-B33B-888D54F5F03D@tzi.org> <20130402014836.GI23316@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1503) Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 06:35:53 -0000 On Apr 2, 2013, at 03:48, Toerless Eckert wrote: > Why should an AP not be able to convert multicast->unicast. Oh sure. I haven't checked 802.11 if its four-address structure = actually might make this work without any change at the adaptation layer = or above. Hacking the destination address visible at the MAC layer API = may be a bit heavy, but might still work (what do we know about the = implementation status of RFC 6508 or its IPv4 equivalent?). Hey, this = might even be supported by snooping a bit in the 6CIO option that = indicates RFC 6508 is implemented... So please go ahead and build product :-) Mark's problem of course is that he would like to make this work with = commodity consumer APs. > All it would ahve > to do is IGMPv3 snooping to know the clients connected to it. And it = does know the > per-client bitrate, aka: how far or how close a client is. Yes, the AP (or controller) knows all that is needed to do this well. > I guess the one things that not possible is to send the smae multicast = group/channel > in both multicast and unicast from the same AP because that would = potentially create > persistent duplicates. Once you send multicast, you already have wasted the resources. However, a multi-unicast could serve as a fill-in for the losses (e.g., = for a station more remote from the AP). Is getting lots of duplicates going to cause a problem? Gr=FC=DFe, Carsten From eckert@cisco.com Mon Apr 1 18:49:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2521E80B0; Mon, 1 Apr 2013 18:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNRoe-s7rYHB; Mon, 1 Apr 2013 18:49:49 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFB221E804A; Mon, 1 Apr 2013 18:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1962; q=dns/txt; s=iport; t=1364867389; x=1366076989; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=V5vXJ/SukXi0hIJ9vLpWf4P5lU71lzx7bpTm5s+aO1M=; b=COpo6P5ftIPZ2csSFY8cryb3LLiiJ2DRUzlUNjkb6wrcODpJw8CvPKxl 8veb43CqLe4lLHswFbeQF06vP0nVtGxNjsKTza9D+8UE3MZSVJq/+ItLB rN4epPNriiUDaicYrBbzUocReJnpMjU7Qnqi4nz8Ijm9CPoR2g88mISHB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADU4WlGrRDoH/2dsb2JhbABDgzu/Qn4WdIIfAQEBBCcLAUYQCw4EBgklDwU1FBOIEw3BDY8xB4NAA4h6iioFg0EBkQuDKxyBLgc X-IronPort-AV: E=Sophos;i="4.87,390,1363132800"; d="scan'208";a="74756125" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2013 01:49:48 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r321ngCm032297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Apr 2013 01:49:42 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r321mbB1028501; Mon, 1 Apr 2013 18:48:57 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r321maAq028498; Mon, 1 Apr 2013 18:48:36 -0700 Date: Mon, 1 Apr 2013 18:48:36 -0700 From: Toerless Eckert To: Carsten Bormann Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" Message-ID: <20130402014836.GI23316@cisco.com> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130401205621.GG23316@cisco.com> <5F498152-0818-4EAB-B33B-888D54F5F03D@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5F498152-0818-4EAB-B33B-888D54F5F03D@tzi.org> User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Tue, 02 Apr 2013 00:33:28 -0700 Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 01:49:50 -0000 Why should an AP not be able to convert multicast->unicast. All it would ahve to do is IGMPv3 snooping to know the clients connected to it. And it does know the per-client bitrate, aka: how far or how close a client is. I guess the one things that not possible is to send the smae multicast group/channel in both multicast and unicast from the same AP because that would potentially create persistent duplicates. On Tue, Apr 02, 2013 at 12:21:05AM +0200, Carsten Bormann wrote: > On Apr 1, 2013, at 22:56, Toerless Eckert wrote: > > > It is clear that 802.11 is particularily challenged with native L2 multicast because > > they never defined a good resilience scheme as for unicast but so far not for multicast. > > Hopefully this will get fixed sometime. > > In a MIMO world, the performance gap between unicast and (indiscriminate) multicast is likely to grow instead of shrink over time. > > Another little observation: > > Fixing this at the adaptation layer (i.e., where IP packets are mapped into L2) is suboptimal, because you may not have visibility into the number of member stations per AP. Once you have a few dozen on an AP, it may make sense to switch back to multicast. For that AP! At the adaptation layer, you only see the bridged 802 network, so you don't know how many stations share an AP, and it is difficult to send multicast to one AP and multi-unicast to another. It seems really hard to optimize this. Once you have 802.11 (without any per-AP hacks) in your bridged 802 network, you probably want to do 6085 globally. > > Pet peeve: We like to make things too "transparent", and then wonder how they break horribly when you no longer can see what you are doing. > -> http://en.wikipedia.org/wiki/Leaky_abstraction > > Grüße, Carsten > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From andrewmcgr@gmail.com Tue Apr 2 02:00:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4755821F854F; Tue, 2 Apr 2013 02:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq8Vkc89+6xa; Tue, 2 Apr 2013 02:00:19 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A7FD021F8526; Tue, 2 Apr 2013 02:00:18 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so173034lab.9 for ; Tue, 02 Apr 2013 02:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3Gm286MT2NuSA1JGZrUXcMxPOhSRXFsf8ZGip4Uw658=; b=GtRQH2pOO6CExBnzlSnVZ1B+crtPq5GW5Kshj//iTLRY25HU8zZlMMA9Xn1tcZYBor 1gvR/taDHLKUPP8jWJ/0NzARupO4JZe0KXZrVtSnrASFfpmtRi9VNAOIl1VTUTGigKRv Ltfxvwa7AKhvZj5pvPqOgU5Nve1SaGfWuUJEGAk5BXhvnM50Vs1Q5VNa0TytBsSfFZWO gjkyChkTsRFetm79eR1vwZLX44mt3zVUw924VvzuWiCVOgMjXoRt7xectS9BAGz8Wuai vaACa9Ho86kKFYVcuqsjrCKEFCYB7J19mMTGFBziaufsgklg7Xg53X/trugtzObQbX62 jL2w== MIME-Version: 1.0 X-Received: by 10.112.162.65 with SMTP id xy1mr7122224lbb.105.1364893217429; Tue, 02 Apr 2013 02:00:17 -0700 (PDT) Received: by 10.112.46.71 with HTTP; Tue, 2 Apr 2013 02:00:17 -0700 (PDT) In-Reply-To: <4F57262A-9403-45AA-AFB3-D46D506F4459@tzi.org> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130401205621.GG23316@cisco.com> <5F498152-0818-4EAB-B33B-888D54F5F03D@tzi.org> <20130402014836.GI23316@cisco.com> <4F57262A-9403-45AA-AFB3-D46D506F4459@tzi.org> Date: Tue, 2 Apr 2013 20:00:17 +1100 Message-ID: Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" From: Andrew McGregor To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e01160dde619f5b04d95cf7f2 Cc: "mboned@ietf.org" , Toerless Eckert , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:00:20 -0000 --089e01160dde619f5b04d95cf7f2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Indeed, an 802.11 AP should be able to do this without breaking 802.11. However, there are probably wider cases where unicast fanout is worth doing. BTW, it's a common misconception that 802.11 transmit rates have something to do with range; actually, they're only very weakly correlated with range, because other selection effects dominate first. Still, that's not particularly relevant to the present discussion. What is relevant is that multicast selects very low rates and is not aggregatable, which wastes transmitter shots; an AP can easily have 100x more unicast throughput than multicast. On Tue, Apr 2, 2013 at 5:35 PM, Carsten Bormann wrote: > On Apr 2, 2013, at 03:48, Toerless Eckert wrote: > > > Why should an AP not be able to convert multicast->unicast. > > Oh sure. I haven't checked 802.11 if its four-address structure actually > might make this work without any change at the adaptation layer or above. > Hacking the destination address visible at the MAC layer API may be a bi= t > heavy, but might still work (what do we know about the implementation > status of RFC 6508 or its IPv4 equivalent?). Hey, this might even be > supported by snooping a bit in the 6CIO option that indicates RFC 6508 is > implemented... > > So please go ahead and build product :-) > > Mark's problem of course is that he would like to make this work with > commodity consumer APs. > > > All it would ahve > > to do is IGMPv3 snooping to know the clients connected to it. And it > does know the > > per-client bitrate, aka: how far or how close a client is. > > Yes, the AP (or controller) knows all that is needed to do this well. > > > I guess the one things that not possible is to send the smae multicast > group/channel > > in both multicast and unicast from the same AP because that would > potentially create > > persistent duplicates. > > Once you send multicast, you already have wasted the resources. > However, a multi-unicast could serve as a fill-in for the losses (e.g., > for a station more remote from the AP). > Is getting lots of duplicates going to cause a problem? > > Gr=FC=DFe, Carsten > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --089e01160dde619f5b04d95cf7f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Indeed, an 802.11 AP should be able to do this without bre= aking 802.11. =A0However, there are probably wider cases where unicast fano= ut is worth doing.

BTW, it's a common misconception = that 802.11 transmit rates have something to do with range; actually, they&= #39;re only very weakly correlated with range, because other selection effe= cts dominate first. =A0Still, that's not particularly relevant to the p= resent discussion. =A0What is relevant is that multicast selects very low r= ates and is not aggregatable, which wastes transmitter shots; an AP can eas= ily have 100x more unicast throughput than multicast.


On Tue,= Apr 2, 2013 at 5:35 PM, Carsten Bormann <cabo@tzi.org> wrote:
On Apr 2, 2013, at 03:48, Toerless Eckert <eckert@cisco.com> wrote:

> Why should an AP not be able to convert multicast->unicast.

Oh sure. =A0I haven't checked 802.11 if its four-address structur= e actually might make this work without any change at the adaptation layer = or above. =A0Hacking the destination address visible at the MAC layer API m= ay be a bit heavy, but might still work (what do we know about the implemen= tation status of RFC 6508 or its IPv4 equivalent?). =A0Hey, this might even= be supported by snooping a bit in the 6CIO option that indicates RFC 6508 = is implemented...

So please go ahead and build product :-)

Mark's problem of course is that he would like to make this work with c= ommodity consumer APs.

> All it would ahve
> to do is IGMPv3 snooping to know the clients connected to it. And it d= oes know the
> per-client bitrate, aka: how far or how close a client is.

Yes, the AP (or controller) knows all that is needed to do this well.=

> I guess the one things that not possible is to send the smae multicast= group/channel
> in both multicast and unicast from the same AP because that would pote= ntially create
> persistent duplicates.

Once you send multicast, you already have wasted the resources.
However, a multi-unicast could serve as a fill-in for the losses (e.g., for= a station more remote from the AP).
Is getting lots of duplicates going to cause a problem?

Gr=FC=DFe, Carsten

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--089e01160dde619f5b04d95cf7f2-- From alexandru.petrescu@gmail.com Tue Apr 2 08:56:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538A721F8C93 for ; Tue, 2 Apr 2013 08:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Yn9T0epuYb5 for ; Tue, 2 Apr 2013 08:56:51 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 46F5721F8A68 for ; Tue, 2 Apr 2013 08:56:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32Fuo5Q031389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 17:56:50 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32FunKr018776; Tue, 2 Apr 2013 17:56:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32FujnK025770; Tue, 2 Apr 2013 17:56:49 +0200 Message-ID: <515AFF7A.80102@gmail.com> Date: Tue, 02 Apr 2013 17:55:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> In-Reply-To: <5157C8CF.1060503@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:56:52 -0000 Le 31/03/2013 07:25, Fernando Gont a écrit : > On 03/30/2013 03:49 PM, Alexandru Petrescu wrote: >> >>> That said, IPv6 addresses identify network attachment points. If >>> you need semantics other than that ("e.g., distinguish between >>> past, current, and future vehicles"). my take is that you're >>> looking at the wrong place, possibly at the expense of nodes that >>> do the right thing. >> >> I did't mean to say do distinguish between old and new vehicles by >> using an IPv6 address. >> >> I meant to say that this VIN mapping to an IPv6 address may be >> useful not only to newly manufactured vehicles, but also to old >> vehicles. > > Why should a VIN map to an IPv6 address in the first place? > > IMO, you should follow what appears to be the consensus on the > subject: set the IID in whatever way you want, About this there is a tendency to agreement. The privacy aspect should be considered, balanced by a privacy-to-mobility tradeoff. But this VIN topic is also about how to generate an ULA prefix when no EUI-64 is available. (if ULAs are good to be used in a vehicle). > as long as you don't expect others to use the same semantics as > yourself (or as long as you can gracefully handle the case in which > others do not employ the same semantics as you). Ok. >> Third-party vehicle equipment manufacturers (not those who >> manufacture the vehicle itself) may manufacture and sell a Router >> to be deployed in the vehicle, to connect the vehicle to the >> Internet. This Router would be put in new vehicles but also in old >> ones. (just like one may add e.g. rearview camera to a vehicle >> which didnt have one at manufacture time). >> >> This Router sold by the third-party needs to know what IPv6 >> addresses are or should there be in the vehicle. > > Isn't this a case of network mobility? YEs it is. Network mobility has a means to dynamically acquire a prefix for the moving network, from the HA. But it doesnt say whether that prefix could be used for direct vehicle-to-vehicle communications, or shouldnt. >> _If_ ULA space may be used then one wonders how to generate one >> ULA prefix for one vehicle. The RFC ULA does suggest an example >> algorithm, but it says other algorithms may be possible. > > The idea is that the prefix is randomized, as to reduce colisions, > IIRC. Yes, and it suggests an algorithm for doing so. That algorithm uses EUI-64. Some MRs may have several such, or none. What to use in these case? >> Also, the example given has some uncertainties (whose interface >> EUI-64 should be chosen?). > > Not sure what you mean.... > > > >> This is one reason we came to generating IPv6 prefixes, and >> Interface IDs, out of VIN. >> >> (it's maybe only me who sends too many emails on this topic, but it >> is not only me and my co-authors of the mentioned drafts, but there >> are other people at IETF worked on this VIN-IPv6 topic, presented >> to f2f IETF meetings, and there exist some IPR activity in that >> space as well). > > I'm not arguing that you're the only guy working on this, nor that > this VIN->IPv6 mapping might be useful to those working on VIN-IPv6 > topic -- I'm rather arguing that IPv6 address should be... IPv6 > addresses Yes. Precisely as IPv6 addresses are IPv6 addresses and sometimes contain EUI-64 identifiers in clear. > (assuming you want IPv6 address to have any other semantics than > "point of attachment"). > > > If your point is "We are not intending to introduce any additional > semantics to the IPv6 addresses/IIDs, but rather are not sure how we > should implement RFC XXXX in our specific case", please do let me > know, and I'll look further into this. Provided that the use of ULA in a vehicle is acceptable, one would try to find out how to generate a ULA prefix in a vehicle, and maybe on a Mobile Router which has several EUI-64, or none. Alex > > Thanks, > From alexandru.petrescu@gmail.com Tue Apr 2 09:02:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A295321F8CF5 for ; Tue, 2 Apr 2013 09:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lcLax6zYk31 for ; Tue, 2 Apr 2013 09:02:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C057E21F8CF0 for ; Tue, 2 Apr 2013 09:02:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32G2pcW001597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 18:02:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32G2pDc021029; Tue, 2 Apr 2013 18:02:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32G2lTX028888; Tue, 2 Apr 2013 18:02:51 +0200 Message-ID: <515B00E4.7000600@gmail.com> Date: Tue, 02 Apr 2013 18:01:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "fgont@si6networks.com" , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:02:57 -0000 Le 01/04/2013 00:39, Manfredi, Albert E a écrit : > Alexandru Petrescu wrote: > >> I meant to say that this VIN mapping to an IPv6 address may be >> useful not only to newly manufactured vehicles, but also to old >> vehicles. > > Honestly, I've never much liked any scheme that attempts to hardcode > anything about the interface into an IP address that way. And the > more I think about it, the less sense it makes to use such a scheme > especially in a car. Where you really can't have one interface > address for the car anyway. I'm much more inclined to wonder why a > car should be any different from, say, your set of laptop PCs, > tablets, and smartphones. In some sense it's the same - it's also a group of computers with distinct IP stacks on them. In other sense it's different - in a car there's often one 'representative' of these computers whereas a conference room of laptops has no particular representative. > A VIN is a fine unique identifier to use in the DNS, though. And > potentially other similar unique identifiers for different > components of each car. E.g., the DNS could have > vitalreadings..car entries, or electicalsystem..car, or > enginediagnostics..car, or numerous entries to identify an > ever growing number interfaces that a car should be expected to > sprout, in the coming decades. > > How you find the moving car from the DNS entry would be same as for > any other mobile client. Using the same set of solutions. Right. There would be a need for dynamic DNS updates for this to work. This would work when little IP mobility is involved. It would be fine to consider vehicles constantly connected with eg LTE, and have the services formed by DNS names, and maybe from VINs. >> This Router sold by the third-party needs to know what IPv6 >> addresses are or should there be in the vehicle. >> >> With IPv4 it was all simple: just use always the same NAT space >> 192.168.0.0. Example deployments are from a number of vehicles. > > Granted, with the IPv4 address space, anything inside the car would > be assigned a RFC 1918 address, and would have to go through a NAT. > And then for global connectivity, systems inside the car would be > required to initiate any session. You can do functionally the same > thing with IPv6. Use ULAs for anything inside the car, and then use > RFC 6296 Network Prefix Translation and mobile IP. > > Perhaps you have the car acquire a temporary IPv6 address based on > its location? Each car is assigned a temporary /64 prefix from the > local wireless ISP? And the DNS dynamically follows the car that > way? I wouldnt think this could work - too many DNS updates... precisely as too many route updates wouldnt work either (I mean in large deployments). But that's just supposition. It may be different, I dont know. Alex > > Bert > > > From alexandru.petrescu@gmail.com Tue Apr 2 09:06:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D6721F8D28 for ; Tue, 2 Apr 2013 09:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.159 X-Spam-Level: X-Spam-Status: No, score=-10.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89VPxIpt8qR5 for ; Tue, 2 Apr 2013 09:06:01 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1F021F8CF0 for ; Tue, 2 Apr 2013 09:06:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32G5uNh002827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 18:05:56 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32G5ujW021789; Tue, 2 Apr 2013 18:05:56 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32G5t1c030238; Tue, 2 Apr 2013 18:05:55 +0200 Message-ID: <515B01A0.9020509@gmail.com> Date: Tue, 02 Apr 2013 18:04:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Scott Brim Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> <51598A3D.20108@internet2.edu> In-Reply-To: <51598A3D.20108@internet2.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "fgont@si6networks.com" , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:06:03 -0000 Le 01/04/2013 15:23, Scott Brim a écrit : > The scope of the draft was more or less restricted to in-vehicle > communications because of the privacy concerns ("The focus of this > work is to enable in-vehicle networks to exchange packets with > VIN-based IPv6 addresses." -- although inter-vehicle communications > is still a big deal under use cases), so I don't think use of DNS, > etc., apply. If the draft isn't really restricted to in-vehicle > communications I have a number of architectural arguments about why > it's a bad idea. VINs are neither topological locators nor IP > endpoint identifiers, and trying to map them onto either causes > confusion. They're fine as higher layer tokens. I tend to agree. Although I suppose a middle ground could exist where the scope of one ULA prefix could cover not only one vehicle, but maybe all vehicles able to hear it, but not the fixed infrastructure. And yes, VINs are neither topological locators nor IP endppoint identifiers. The VINs themselves may exist into their own layer, with their own message headers, and message passing akin to what SMTP does. Alex > > Scott > > > From alexandru.petrescu@gmail.com Tue Apr 2 09:09:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EB921F8D35 for ; Tue, 2 Apr 2013 09:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNIsSM9f1DUn for ; Tue, 2 Apr 2013 09:09:45 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1B821F8D5F for ; Tue, 2 Apr 2013 09:09:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r32G9dV6013778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 18:09:39 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r32G9d63022541; Tue, 2 Apr 2013 18:09:39 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r32G9co2031843; Tue, 2 Apr 2013 18:09:39 +0200 Message-ID: <515B027F.3030204@gmail.com> Date: Tue, 02 Apr 2013 18:08:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <021E64FECA7E5A4699562F4E6671648101CF73@XCH-PHX-503.sw.nos.boeing.com> <51598A3D.20108@internet2.edu> <021E64FECA7E5A4699562F4E6671648101DB2C@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101DB2C@XCH-PHX-503.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "fgont@si6networks.com" , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:09:46 -0000 Le 01/04/2013 21:35, Manfredi, Albert E a écrit : > Scott, > > If the only goal is in-vehicle, then clearly ULAs are the answer, and > there's nothing more to be discussed. And for that matter, RFC 1918 > addresses and IPv4 would be more than adequate. Limiting comms to > in-vehicle does not require any global uniqueness of addresses. I agree (except the IPv4 part). > I think the model to follow here is more like E.164 uniform resource > identifiers (ENUM, RFC 3761). In enum, the telephone numbers are not > hard-coded in the IP address. Rather, they become a DNS entry. Seems > to me that any plan on using the uniqueness of the VIN number for > cars should follow this same approach. > > Not saying that this DNS approach would answer all vehicle comms > issues to be resolved, though. For example, for self-driving > vehicles, there would be a need for more real-time (perhaps at layer > 2) comms between adjacent cars and between cars and the roadway. E.g. > some way of a car with an impending problem to be shuttled off to the > emergency lanes, to get out of the way of the moving traffic. Alex > > Bert > >> -----Original Message----- From: Scott Brim >> [mailto:swb@internet2.edu] Sent: Monday, April 01, 2013 9:23 AM To: >> Manfredi, Albert E Cc: Alexandru Petrescu; fgont@si6networks.com; >> 6man Subject: Re: I-D Action: >> draft-imadali-its-vinipv6-viid-00.txt >> >> The scope of the draft was more or less restricted to in-vehicle >> communications because of the privacy concerns ("The focus of this >> work is to enable in-vehicle networks to exchange packets with >> VIN-based IPv6 addresses." -- although inter-vehicle communications >> is still a big deal under use cases), so I don't think use of DNS, >> etc., apply. If the draft isn't really restricted to in-vehicle >> communications I have a number of architectural arguments about why >> it's a bad idea. VINs are neither topological locators nor IP >> endpoint identifiers, and trying to map them onto either causes >> confusion. They're fine as higher layer tokens. >> >> Scott > > > From fgont@si6networks.com Tue Apr 2 22:40:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61121F86FA for ; Tue, 2 Apr 2013 22:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoZge1bRLPOX for ; Tue, 2 Apr 2013 22:40:49 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9A21F8689 for ; Tue, 2 Apr 2013 22:40:49 -0700 (PDT) Received: from [2001:5c0:1000:a::f83] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UNGRC-0007ZT-If; Wed, 03 Apr 2013 07:40:46 +0200 Message-ID: <515BC0DA.6040203@si6networks.com> Date: Wed, 03 Apr 2013 02:40:42 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> In-Reply-To: <515AFF7A.80102@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 05:40:50 -0000 Hi, Alex, On 04/02/2013 12:55 PM, Alexandru Petrescu wrote: >> IMO, you should follow what appears to be the consensus on the >> subject: set the IID in whatever way you want, > > About this there is a tendency to agreement. The privacy aspect should > be considered, balanced by a privacy-to-mobility tradeoff. Which privacy aspect? > But this VIN topic is also about how to generate an ULA prefix when no > EUI-64 is available. (if ULAs are good to be used in a vehicle). The ULA spec relies on that? Anyway.. the idea is that you randomize the prefix... >>> This Router sold by the third-party needs to know what IPv6 >>> addresses are or should there be in the vehicle. >> >> Isn't this a case of network mobility? > > YEs it is. Network mobility has a means to dynamically acquire a prefix > for the moving network, from the HA. But it doesnt say whether that > prefix could be used for direct vehicle-to-vehicle communications, or > shouldnt. Not sure what you mean.... >>> _If_ ULA space may be used then one wonders how to generate one >>> ULA prefix for one vehicle. The RFC ULA does suggest an example >>> algorithm, but it says other algorithms may be possible. >> >> The idea is that the prefix is randomized, as to reduce colisions, >> IIRC. > > Yes, and it suggests an algorithm for doing so. That algorithm uses > EUI-64. Some MRs may have several such, or none. What to use in these > case? OK. Lt me take a look -- anyway, my rough guess is that you'd be fine by just randomizing the prefix part. (i.e., the router). >> I'm not arguing that you're the only guy working on this, nor that >> this VIN->IPv6 mapping might be useful to those working on VIN-IPv6 >> topic -- I'm rather arguing that IPv6 address should be... IPv6 >> addresses > > Yes. Precisely as IPv6 addresses are IPv6 addresses and sometimes > contain EUI-64 identifiers in clear. We should eventually move away from that. See draft-ietf-6man-stable-privacy-addresses. >> If your point is "We are not intending to introduce any additional >> semantics to the IPv6 addresses/IIDs, but rather are not sure how we >> should implement RFC XXXX in our specific case", please do let me >> know, and I'll look further into this. > > Provided that the use of ULA in a vehicle is acceptable, one would try > to find out how to generate a ULA prefix in a vehicle, and maybe on a > Mobile Router which has several EUI-64, or none. If you expect communication across vehicles, then your upstream router should be the one generating the prefix. If only in-vehicle communication is expected, you'd be okay by just randomizing the prefix. -- But I'll double-check with the UA spec and come back to you -- please feel free to ping me if I forget. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From swb@internet2.edu Wed Apr 3 06:06:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D429721F8DD0 for ; Wed, 3 Apr 2013 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1RQZ1WZ+i0r for ; Wed, 3 Apr 2013 06:06:12 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 470A321F8DC1 for ; Wed, 3 Apr 2013 06:06:12 -0700 (PDT) Received: from mail97-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE023.bigfish.com (10.243.66.86) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Apr 2013 13:06:11 +0000 Received: from mail97-co1 (localhost [127.0.0.1]) by mail97-co1-R.bigfish.com (Postfix) with ESMTP id 59E464804AD; Wed, 3 Apr 2013 13:06:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.53; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0811HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 21 X-BigFish: S21(zzbb2dI98dI9371I1432Izz1f42h1fc6h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah133w1b1cn1b1bi1155h) Received: from mail97-co1 (localhost.localdomain [127.0.0.1]) by mail97-co1 (MessageSwitch) id 1364994340578815_23925; Wed, 3 Apr 2013 13:05:40 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.253]) by mail97-co1.bigfish.com (Postfix) with ESMTP id 816485800E8; Wed, 3 Apr 2013 13:05:40 +0000 (UTC) Received: from BLUPRD0811HT001.namprd08.prod.outlook.com (157.56.232.53) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Apr 2013 13:05:40 +0000 Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.123.36) with Microsoft SMTP Server (TLS) id 14.16.287.8; Wed, 3 Apr 2013 13:05:32 +0000 Message-ID: <515C291A.6070608@internet2.edu> Date: Wed, 3 Apr 2013 09:05:30 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> In-Reply-To: <515BC0DA.6040203@si6networks.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [67.241.75.185] X-OriginatorOrg: internet2.edu Cc: Alexandru Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 13:06:12 -0000 On 04/03/13 01:40, Fernando Gont allegedly wrote: > Hi, Alex, > > On 04/02/2013 12:55 PM, Alexandru Petrescu wrote: >>> IMO, you should follow what appears to be the consensus on the >>> subject: set the IID in whatever way you want, >> >> About this there is a tendency to agreement. The privacy aspect should >> be considered, balanced by a privacy-to-mobility tradeoff. > > Which privacy aspect? Please dig for previous discussion of this draft. From alexandru.petrescu@gmail.com Wed Apr 3 06:22:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB2F21F8CD2 for ; Wed, 3 Apr 2013 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehTg0OQcmwmk for ; Wed, 3 Apr 2013 06:22:13 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9019021F8B08 for ; Wed, 3 Apr 2013 06:22:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r33DMBSM018418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Apr 2013 15:22:11 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r33DMBQp024059; Wed, 3 Apr 2013 15:22:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r33DM6QS014552; Wed, 3 Apr 2013 15:22:10 +0200 Message-ID: <515C2CFF.3060809@gmail.com> Date: Wed, 03 Apr 2013 15:22:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> In-Reply-To: <515BC0DA.6040203@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 13:22:13 -0000 Le 03/04/2013 07:40, Fernando Gont a écrit : > Hi, Alex, > > On 04/02/2013 12:55 PM, Alexandru Petrescu wrote: >>> IMO, you should follow what appears to be the consensus on the >>> subject: set the IID in whatever way you want, >> >> About this there is a tendency to agreement. The privacy aspect >> should be considered, balanced by a privacy-to-mobility tradeoff. > > Which privacy aspect? Offer privacy by default: avoid a reversible mapping VIN-to- InterfaceID. Because, if a reversible mapping VIN-to-InterfaceID existed, then it could be exploited by attackers by reversing the InterfaceID back into VIN, and exposing this personal information to anyone listening the IP traffic of a vehicle. >> But this VIN topic is also about how to generate an ULA prefix >> when no EUI-64 is available. (if ULAs are good to be used in a >> vehicle). > > The ULA spec relies on that? Yes, the ULA prefix (RFC 4193 section 3.2.2) generates a 48bit prefix randomly. That suggested algorithm is seeded by time, EUI-64 into a key, and then SHA-1. > Anyway.. the idea is that you randomize the prefix... Yes. We may need to say how. Just saying RNG may not be enough, I dont know. >>>> This Router sold by the third-party needs to know what IPv6 >>>> addresses are or should there be in the vehicle. >>> >>> Isn't this a case of network mobility? >> >> YEs it is. Network mobility has a means to dynamically acquire a >> prefix for the moving network, from the HA. But it doesnt say >> whether that prefix could be used for direct vehicle-to-vehicle >> communications, or shouldnt. > > Not sure what you mean.... I mean Network mobility as the RFCs describe them dont say whether the prefix assigned to a moving network is ULA or GUA, PI or PA. Also, that Network mobility doesnt prohibit neither suggests that the prefix of a moving network (MNP: Mobile Network Prefix) be exchanged between two distinct moving networks such as to establish routes between them (route exchange). I am discussing this because you seemed to ask whether this is a case of Network mobility: yes and no. >>>> _If_ ULA space may be used then one wonders how to generate one >>>> ULA prefix for one vehicle. The RFC ULA does suggest an >>>> example algorithm, but it says other algorithms may be >>>> possible. >>> >>> The idea is that the prefix is randomized, as to reduce >>> colisions, IIRC. >> >> Yes, and it suggests an algorithm for doing so. That algorithm >> uses EUI-64. Some MRs may have several such, or none. What to >> use in these case? > > OK. Lt me take a look -- anyway, my rough guess is that you'd be > fine by just randomizing the prefix part. (i.e., the router). Just randomize but how? Just randomize without saying how may lead to everybody outputting same number. One may need to use a detail about generating uniqueness. The RFC ULA suggests that detail to be time and EUI-64. A mobile router in a vehicle may not always have a EUI-64 (yet it has LTE interface, CAN, USB, etc). Or it may have several such EUI-64-interfaces; and a rule may say 'pick any one of the available EUI-64 on this computer'. Or it may say to use the EUI-64 of another interface of another computer in that same vehicle. (there are several distinct such computers, like the 'TCU', the 'ECU', the OBU, the Switch, the App server, and so on). Or it may say just use the VIN because that covers the entire vehicle and whatever computers are inside there's only one VIN. >>> I'm not arguing that you're the only guy working on this, nor >>> that this VIN->IPv6 mapping might be useful to those working on >>> VIN-IPv6 topic -- I'm rather arguing that IPv6 address should >>> be... IPv6 addresses >> >> Yes. Precisely as IPv6 addresses are IPv6 addresses and sometimes >> contain EUI-64 identifiers in clear. > > We should eventually move away from that. See > draft-ietf-6man-stable-privacy-addresses. Well yes I read it and understand it from a privacy perspective. It is very good in that sense because whenever changing the subnet the IID changes, so attacker can not track the user by its IID. However, it may be less attractive to a mobility-inclined reader, because whenever changing the entire address (not only the IID), some of the ongoing communications may break., I think. >>> If your point is "We are not intending to introduce any >>> additional semantics to the IPv6 addresses/IIDs, but rather are >>> not sure how we should implement RFC XXXX in our specific case", >>> please do let me know, and I'll look further into this. >> >> Provided that the use of ULA in a vehicle is acceptable, one >> would try to find out how to generate a ULA prefix in a vehicle, >> and maybe on a Mobile Router which has several EUI-64, or none. > > If you expect communication across vehicles, then your upstream > router should be the one generating the prefix. 'Upstream router' - the topmost router in the vehicle (there are several). Or the first-hop router in the fixed infrastructure? If the first-hop router in the fixed infrastructure - if it's a cellular Access Router it may not have EUI-64 either, or have several. > If only in-vehicle communication is expected, you'd be okay by just > randomizing the prefix. Well, I think that for only in-vehicle communication, random ULA may not be necessary - using the same ULA fd00:1::/64 in every other vehicle will work. The random part of the ULA may be needed for inter-vehicle communications. I.e. use fd00:fef2:3214::/64 inside one vehicle, and fd00:fff2:3214::/64 in the other vehicle. Use no prefix on the ad-hoc link between the two egress interfaces of the mobile router (use their link-local addresses there). If those two prefixes were not random, then collision between prefixes may occur the moment the routes are exchanged between the vehicles. > -- But I'll double-check with the UA spec and come back to you -- > please feel free to ping me if I forget. Ok will do, thanks. Alex > > Cheers, > From mcr@sandelman.ca Wed Apr 3 09:00:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FD321F8F25; Wed, 3 Apr 2013 09:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CsjhetG-qPu; Wed, 3 Apr 2013 09:00:40 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0660E21F8D28; Wed, 3 Apr 2013 09:00:40 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D026E20168; Wed, 3 Apr 2013 12:09:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 532F5638E8; Wed, 3 Apr 2013 12:00:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 276F4638E7; Wed, 3 Apr 2013 12:00:24 -0400 (EDT) From: Michael Richardson To: 6man Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt In-Reply-To: <515C2CFF.3060809@gmail.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Sender: mcr@sandelman.ca Cc: its@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:00:42 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: >> On 04/02/2013 12:55 PM, Alexandru Petrescu wrote: >>>> IMO, you should follow what appears to be the consensus on the >>>> subject: set the IID in whatever way you want, >>>=20 >>> About this there is a tendency to agreement. The privacy aspect >>> should be considered, balanced by a privacy-to-mobility tradeoff. >>=20 >> Which privacy aspect? Alexandru> Offer privacy by default: avoid a reversible mapping VIN-to- Alexandru> InterfaceID. Because, if a reversible mapping Alexandru> VIN-to-InterfaceID=20 Alexandru> existed, then it could be exploited by attackers by Alexandru> reversing the=20 Alexandru> InterfaceID back into VIN, and exposing this personal Alexandru> information to So, I have a question: how much privacy is actually contained in the VIN or indexed by the VIN? Given that it's printed on the windshield. Yes, it contains model, year and manufacturer of the car, but all of that information is also visible by looking at the vehicle.=20=20 So the concern is that it be if the VIN can be discovered during an online transaction of some kind that bad things can happen. Is any priviledge going to be attached to the *VIN* itself (or to the address derived from the VIN). Note that this doesn't meant that the car doesn't have a private key with a certificate attaching that private key to the VIN such that the vehicle can do interesting things with the manufacturer systems, etc. If there are databases indexed by VIN, I wonder if that in itself isn't a violation of privacy given that the VIN is rather publically displayed. (I imagine the Department of Motor Vehicles/DMV-equivalent) does this. The DMV database is sometimes protected, sometimes private, and in some jurisdictions rather porous if 1970 era episodes of Rockford Files and Riptide are to be believed). I am way more concerned about privacy concerns where the VIN, given that it can be easily known, can then be used to derive the prefix that the vehicle uses and then seek out that vehicle's systems electronically. So, I'm saying that VIN->prefix via hash may be great protection for the VIN, but it might be poor protection for the prefix.=20=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUVxSF4qHRg3pndX9AQJWiAQAwTQB5SNIZ+I3bSw9zkiYchm1fpfVsofJ 5uo/j6Z/3Q7iwWbsADYsy/EStM83CAQWDBTgRSjnCQlKWee0epn+9XO9avBts64H +yjGwyJHEVcZrbHFgDAd395xELDIn7KTlZnlSaOdVHy4MuvIkGDMt4w12wsuTAZh PutF8o0hKdg= =y7yt -----END PGP SIGNATURE----- --=-=-=-- From sarikaya2012@gmail.com Wed Apr 3 10:11:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D57821F8FCF; Wed, 3 Apr 2013 10:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOwKwx2B7-+l; Wed, 3 Apr 2013 10:11:31 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 34FAA21F8FA1; Wed, 3 Apr 2013 10:11:30 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id p11so1847363lbi.0 for ; Wed, 03 Apr 2013 10:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DSQP4Qa588zGY/18K94JMLiGCIWYcsv/3M86/6+CQns=; b=hWWaKhO/9Y+Z1UzgWj09zBZeNmeuoJNHRNiTBGg+iuSZFuXBGIfAZRg+kqAaLSxKxS BlarV9KJMuOfAMWSc/scdYRCB3NQG/qY+lkTCbhsro7rTBq2TISmIFplidlMflLEKAEo mbPqTbkqXusYBbeaHBzjd1Llwu3dO1WsVtFvvgYDDEI5ThrV/VSvlAtNeAjZiPKjkC+D giIHlFIa7iOZ4CG6fdKvbWpNzk6/SzNpvTf6CaZr/t8VetEqwLHvLWBFtO+oTqNSjkKu mZ94R8CmjQGF/XVkh1H0ZnAw5gHdS2pkhzUdgXDDtqmKOYzJl4bIbF9cuFmvdAfIkwbj aXqg== MIME-Version: 1.0 X-Received: by 10.112.129.137 with SMTP id nw9mr1547346lbb.56.1365008599366; Wed, 03 Apr 2013 10:03:19 -0700 (PDT) Received: by 10.114.17.104 with HTTP; Wed, 3 Apr 2013 10:03:19 -0700 (PDT) In-Reply-To: <20130401205621.GG23316@cisco.com> References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130401205621.GG23316@cisco.com> Date: Wed, 3 Apr 2013 12:03:19 -0500 Message-ID: Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" From: Behcet Sarikaya To: Toerless Eckert Content-Type: multipart/alternative; boundary=047d7b3a7f10ae417e04d977d4d8 Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:11:33 -0000 --047d7b3a7f10ae417e04d977d4d8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 1, 2013 at 3:56 PM, Toerless Eckert wrote: > Bunch of comments... > > 1. What Mark is proposing is being done AFAIK in a variety of products on > the market, > for example as the "multicast to unicast" eleement of Cisco VideoStream > and i think other vendors do this as well. Not sure about IPv6 though, > i've only seen > it in IPv4. > > 2. I am always getting annoyed when IPv6 bigots oops: fans unnecessarily > constraining > solutions to IPv6 only even though they equally apply to IPv4 and, in > the case > of IP multicast when its clear that the mayority of use for a while > will still be > IPv4. Its already bad enough that RFC6085 was written only for IPv6 > instead of > for IPv4 and IPv6. I explained why already: it was for PMIPv6 which needed to have point-to-point link on 802.11. For the rest of this very long message, yes, this is an application issue and I don't see why IETF should enter into this domain. Behcet > It would be lovely if Marks draft could be modified to cover > both IPv4 and IPv6. I can't remember that RFC6085 was given for review > to MBoned, > or else i'd hae made that comment for it as well. But see 1: in > practice existing > IPv4 host stacks will wwell receive DMAC-unicast IP multicast packets > due to the > fundamental separation of L3 and L2 in the architecture of most host > stacks. > > 3. I think a key eleemnt of the draft that should be made more clear in > the description is > that this mechanism is meant to be incrementally dpeloyable such that > the mayority > of devices on the (wireless) L2 domain do not have to be changed at > all, and that > the only expection against them is 2. (RFC6085 or equivalent for IPv4). > > To achieve this, the only requirement is to run IGMPv3/MLDv2, inhibit > MLDv1/IGMPv1v2, > and a device that wants to send multicast as unicast into the L2 domain > needs to > perform explicit tracking of the membership reports to know whom to > send unicast copies to. > > And then there are optimizations such as RFC4861 which should be > optional. > > But having said all this, the fact that this can be done as a local > implementation > optimization in a device sending IP multicast into the L2 domain > (whether thats > a router, switch, host or whatever), it also means that this mechanism > does not > need to change any protocol signaling, and therefore the question is > whether this > can be standards track or just be informational. > > 4. I don't particularily think that the operating models presented and the > first > sentence of the abstract are correct. Sending L2 (wireless) multicast > has a lot of > benefits, and it has a lot of downsides. It totally depends on what you > try to achieve. > > It is clear that 802.11 is particularily challenged with native L2 > multicast because > they never defined a good resilience scheme as for unicast but so far > not for multicast. > Hopefully this will get fixed sometime. As long as thats not the case > we definitely > have to tke this into account as a constraint, but it would be good to > explain the > situation correctly in the doc. > > Wrt. the operational model, i could easily see that one wold start out > with unicasting, > but then change over to multicasting for a particular group/channel > when the > total number of receivers tracked and bandwidth sent over the > group/channel is too large. > You may also limit IP multicast to a particular bitrate, so if a > specific receiver > can not support that bitrate, it would need to get unicast, and then > that unicast > might need to be rate-limited so that the receiver downspeeds (assuming > it is > using ALC which it really should). I am not aware if any product > embodies > this dyanmicac switching, i am just saying it sounds logical to me ;-) > > So, given how many policies there could be to improve behavior of > multicast over > wireless, i think it would be more appropriate to make this draft > informational > and collect/document/discss these possible policies. Its not as if a > specific individual > policy seems to be ubiquoutously preferrable, and given how its all > local policy on the > device sending into the wireless L2, it doesn't seem to be the right > place for a > standard track doc. Going informational does hopefully not make a > difference for > this doc being useful, because whether its standards track or not, > customers will hopefully > put it into RFPs against their wireless equipment. Which also means its > a good idea > in these type of documents to give sticky names to individual functions > such as > different type of policies or optimizations, so customes in RFPs can > refer to those > sticky names (or section numbers). > > 5. Not being really a protocol extension but logically device-local > improvements with > a bunch of policies possible makes it also a good candidate for MBoned > as opposed to a > protocol group (i think... ). > > Cheers > Toerless > > tracking of > that it is consisting purely of mechanisms that the accss-point type > device in a > > > On Fri, Mar 29, 2013 at 03:18:06PM -0700, Mark Smith wrote: > > Hi Behcet, > > > > Thanks for your review and comments. > > > > > > > > >________________________________ > > > From: Behcet Sarikaya > > >To: Dave Thaler > > >Cc: Mark Smith ; "6man@ietf.org" < > 6man@ietf.org>; "mboned@ietf.org" > > >Sent: Saturday, 30 March 2013 8:33 AM > > >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery > of Multicast" > > > > > > > > >Hi Mark, > > > > > >I read your draft. > > >First of all I think you misunderstood RFC 6085 and based on a wrong > assumption you developed your solution. > > > > > > > > >What specifically do you think I've misunderstood? I was involved in > some of the conversations about that RFC while it was an ID, and all I > think it really is fundamentally saying is that an IPv6 packet with a > multicast IPv6 destination address isn't required to have a link-layer > multicast destination address - it can be a link-layer unicast destination > address if useful or necessary. > > > > > > > > > > > > > > > I suggest you take a look at > http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 > > >on Netext for PMIPv6. > > > > > > > > >I'll have a read. > > > > > >I believe that we should use multicast delivery as much as possible on > the downlink if the link is a shared link. > > > > > > > > > > > > > > >I agree with using multicast as much as possible to reduce duplicate > packets sent over the network. The proposal here is to use packet > replication and link-layer unicasts when doing so would either exceed the > performance of link-layer multicast and/or overcome the negative effects of > link-layer multicast, such as when larger volumes of multicast traffic > impact unicast performance on the same link. Both of these issues occur on > 802.11 links when there volume of multicast traffic is in the order of a > few megabits (or less, I've been testing with around 2.5 Mbps of video) > > > > > > > > >The main use case I've been thinking about (which I'll make more > obvious in the next revision), is a multicast IPTV service scenario towards > a residential customer, where the residential customer has a 802.11 network > in their home rather than a wired one. IPv6 multicast/link-layer multicast > would be used all the way from the multicast source servers, across the > service provider network, up until the CPE in the residential customers' > homes, gaining the efficiencies of multicast. However, the CPE in the > customer's house would then use IPv6 multicast/link-layer unicast of the > IPTV traffic over the 802.11 link to the customers end-hosts, saving them > having to put in wired infrastructure, or resorting to buying ethernet over > power devices to make their power cabling their wired infrastructure. Note > that there is still a low level of link-layer multicast traffic in the > customers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal is > not eliminating > > link-layer multicasts, just reducing them where possible and where > useful. > > > > > > > > >That's not to say this proposal is only useful in an 802.11 scenario. > It could be used in any scenario where packet replication and link-layer > unicasting would provide useful benefits over link-layer multicasts. It > generally increases the data confidentiality of the multicast IPv6 traffic, > and may help increase battery life of some devices. > > > > > > > > >Thanks very much, > > >Mark. > > > > > > > > > > > >Regards, > > > > > >Behcet > > > > > > > > > > > > > > >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler > wrote: > > > > > >http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast > > >>is work we did back in 2000 on this same topic. At the time, the > draft is written from > > >>the perspective of the 6to4 NBMA link, but the topic was discussed > (specifically by those > > >>in the acknowledgements section, and to a lesser extent by the ngtrans > WG as a whole) > > >>as being more generally applicable. > > >> > > >>There wasn't significant interest at the time and so the work was > dropped > > >>rather than updating the spec to use generic language. > > >> > > >>The same concept as in the above was however then used in 2001 in > > >>http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast > > >>(still specific to a particular link type though), which after 11 > years is now in the IESG :) > > >> > > >>The most relevant WG is MBoneD. > > >> > > >>-Dave > > >> > > >> > > >>> -----Original Message----- > > >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > > >>> Mark Smith > > >>> Sent: Thursday, March 28, 2013 8:22 PM > > >>> To: 6man@ietf.org > > >>> Subject: "MLDv2 Procedures for Link-Layer Unicast Delivery of > Multicast" > > >>> > > >>> Hi, > > >>> > > >>> The following is inspired by some work I did in around 2010/2011 on a > > >>> multicast TV service, where residential customers with Wifi networks > > >>> suffered from performance problems, and had to be advised to buy > > >>> ethernet over power devices if they couldn't run wired ethernet to > the STB > > >>> attached to their TV. > > >>> > > >>> I've done some experiments on my home wifi network, using VLC, and > > >>> switching between multicast and unicast IPv6 to test the concept. > The wifi > > >>> performance issues disappear when the video is delivered via unicast > UDP. > > >>> (If people want to play with VLC and IPv6 multicast, email me > off-list, as there > > >>> are a few issues e.g. the GUI doesn't accept some of the IPv6 > multicast > > >>> parameters that the command line does). > > >>> > > >>> I think there is a possibility the technique could also be applied to > > >>> IGMPv3/ARP, although it depends on whether ARP has been implemented > > >>> in a similar manner to IPv6 ND (e.g. an ARP equivalent to NUD). My > > >>> understanding is that Linux has implemented ARP this way. I'll do > some more > > >>> research to verify this. > > >>> > > >>> I though I'd post it to see if there is merit in the idea and it is > worth spending > > >>> more of my time on. I looked for a IETF group more suitable to this, > but didn't > > >>> seem to be able to find one. If there is one, please let me know. > > >>> > > >>> Review and comments most appreciated. > > >>> > > >>> Thanks very much, > > >>> Mark. > > >>> > > >>> > > >>> ----- Forwarded Message ----- > > >>> > From: "internet-drafts@ietf.org" > > >>> > To: markzzzsmith@yahoo.com.au > > >>> > Cc: > > >>> > Sent: Friday, 29 March 2013 1:45 PM > > >>> > Subject: New Version Notification for > > >>> > draft-smith-mldv2-link-unicast-00.txt > > >>> > > > >>> > > > >>> > A new version of I-D, draft-smith-mldv2-link-unicast-00.txt > > >>> > has been successfully submitted by Mark Smith and posted to the > IETF > > >>> > repository. > > >>> > > > >>> > Filename: draft-smith-mldv2-link-unicast > > >>> > Revision: 00 > > >>> > Title: MLDv2 Procedures for Link-Layer Unicast Delivery of > > >>> > Multicast > > >>> > IPv6 > > >>> > Creation date: 2013-03-29 > > >>> > Group: Individual Submission > > >>> > Number of pages: 7 > > >>> > URL: > > >>> > > http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00. > > >>> > txt > > >>> > Status: > > >>> > http://datatracker.ietf.org/doc/draft-smith-mldv2-link-unicast > > >>> > Htmlized: > > >>> > http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00 > > >>> > > > >>> > > > >>> > Abstract: > > >>> > Some multi-access link-layer technologies typically not provide > > >>> > good > > >>> > IPv6 multicast performance, using link-layer multicasts, when > the > > >>> > volume of multicast traffic is significant. It would be > possible > > >>> > to > > >>> > replicate and then link-layer unicast multicast IPv6 traffic to > > >>> > interested listeners to overcome these link-layer performance > > >>> > limitations. This memo describes MLDv2 and IPv6 neighbor > discovery > > >>> > procedures to support link-layer unicast delivery of multicast > IPv6 > > >>> > traffic. > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > The IETF Secretariat > > >>> > > > >>> -------------------------------------------------------------------- > > >>> IETF IPv6 working group mailing list > > >>> ipv6@ietf.org > > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > >>> -------------------------------------------------------------------- > > >>_______________________________________________ > > >>MBONED mailing list > > >>MBONED@ietf.org > > >>https://www.ietf.org/mailman/listinfo/mboned > > >> > > > > > > > > > > > _______________________________________________ > > MBONED mailing list > > MBONED@ietf.org > > https://www.ietf.org/mailman/listinfo/mboned > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > > --047d7b3a7f10ae417e04d977d4d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 1, 2013 at 3:56 PM, Toerless= Eckert <eckert@cisco.com> wrote:
Bunch of comments...

1. What Mark is proposing is being done AFAIK in a variety of products on t= he market,
=A0 =A0for example as the "multicast to unicast" eleement of Cisc= o VideoStream
=A0 =A0and i think other vendors do this as well. Not sure about IPv6 thoug= h, i've only seen
=A0 =A0it in IPv4.

2. I am always getting annoyed when IPv6 bigots oops: fans unnecessarily co= nstraining
=A0 =A0solutions to IPv6 only even though they equally apply to IPv4 and, i= n the case
=A0 =A0of IP multicast when its clear that the mayority of use for a while = will still be
=A0 =A0IPv4. Its already bad enough that RFC6085 was written only for IPv6 = instead of
=A0 =A0for IPv4 and IPv6.


I explained why already= : it was for PMIPv6 which needed to have point-to-point link on 802.11.
=

For the rest of this very long message,

yes, this is an appl= ication issue and I don't see why IETF should enter into this domain.
Behcet
It would be lovely if M= arks draft could be modified to cover
=A0 =A0both IPv4 and IPv6. I can't remember that RFC6085 was given for = review to MBoned,
=A0 =A0or else i'd hae made that comment for it as well. But see 1: in = practice existing
=A0 =A0IPv4 host stacks will wwell receive DMAC-unicast IP multicast packet= s due to the
=A0 =A0fundamental separation of L3 and L2 in the architecture of most host= stacks.

3. I think a key eleemnt of the draft that should be made more clear in the= description is
=A0 =A0that this mechanism is meant to be incrementally dpeloyable such tha= t the mayority
=A0 =A0of devices on the (wireless) L2 domain do not have to be changed at = all, and that
=A0 =A0the only expection against them is 2. (RFC6085 or equivalent for IPv= 4).

=A0 =A0To achieve this, the only requirement is to run IGMPv3/MLDv2, inhibi= t MLDv1/IGMPv1v2,
=A0 =A0and a device that wants to send multicast as unicast into the L2 dom= ain needs to
=A0 =A0perform explicit tracking of the membership reports to know whom to = send unicast copies to.

=A0 =A0And then there are optimizations such as RFC4861 which should be opt= ional.

=A0 =A0But having said all this, the fact that this can be done as a local = implementation
=A0 =A0optimization in a device sending IP multicast into the L2 domain (wh= ether thats
=A0 =A0a router, switch, host or whatever), it also means that this mechani= sm does not
=A0 =A0need to change any protocol signaling, and therefore the question is= whether this
=A0 =A0can be standards track or just be informational.

4. I don't particularily think that the operating models presented and = the first
=A0 =A0sentence of the abstract are correct. Sending L2 (wireless) multicas= t has a lot of
=A0 =A0benefits, and it has a lot of downsides. It totally depends on what = you try to achieve.

=A0 =A0It is clear that 802.11 is particularily challenged with native L2 m= ulticast because
=A0 =A0they never defined a good resilience scheme as for unicast but so fa= r not for multicast.
=A0 =A0Hopefully this will get fixed sometime. As long as thats not the cas= e we definitely
=A0 =A0have to tke this into account as a constraint, but it would be good = to explain the
=A0 =A0situation correctly in the doc.

=A0 =A0Wrt. the operational model, i could easily see that one wold start o= ut with unicasting,
=A0 =A0but then change over to multicasting for a particular group/channel = when the
=A0 =A0total number of receivers tracked and bandwidth sent over the group/= channel is too large.
=A0 =A0You may also limit IP multicast to a particular bitrate, so if a spe= cific receiver
=A0 =A0can not support that bitrate, it would need to get unicast, and then= that unicast
=A0 =A0might need to be rate-limited so that the receiver downspeeds (assum= ing it is
=A0 =A0using ALC which it really should). I am not aware if any product emb= odies
=A0 =A0this dyanmicac switching, i am just saying it sounds logical to me ;= -)

=A0 =A0So, given how many policies there could be to improve behavior of mu= lticast over
=A0 =A0wireless, i think it would be more appropriate to make this draft in= formational
=A0 =A0and collect/document/discss these possible policies. Its not as if a= specific individual
=A0 =A0policy seems to be ubiquoutously preferrable, and given how its all = local policy on the
=A0 =A0device sending into the wireless L2, it doesn't seem to be the r= ight place for a
=A0 =A0standard track doc. Going informational does hopefully not make a di= fference for
=A0 =A0this doc being useful, because whether its standards track or not, c= ustomers will hopefully
=A0 =A0put it into RFPs against their wireless equipment. Which also means = its a good idea
=A0 =A0in these type of documents to give sticky names to individual functi= ons such as
=A0 =A0different type of policies or optimizations, so customes in RFPs can= refer to those
=A0 =A0sticky names (or section numbers).

5. Not being really a protocol extension but logically device-local improve= ments with
=A0 =A0a bunch of policies possible makes it also a good candidate for MBon= ed as opposed to a
=A0 =A0protocol group (i think... ).

Cheers
=A0 =A0 Toerless

=A0 =A0tracking of
=A0 =A0that it is consisting purely of mechanisms that the accss-point type= device in a


On Fri, Mar 29, 2013 at 03:18:06PM -0700, Mark Smith wrote:
> Hi Behcet,
>
> Thanks for your review and comments.
>
>
>
> >________________________________
> > From: Behcet Sarikaya <sarikaya2012@gmail.com>
> >To: Dave Thaler <dthal= er@microsoft.com>
> >Cc: Mark Smith <ma= rkzzzsmith@yahoo.com.au>; "6ma= n@ietf.org" <6man@ietf.org= >; "mboned@ietf.org" &l= t;mboned@ietf.org>
> >Sent: Saturday, 30 March 2013 8:33 AM
> >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicas= t Delivery of Multicast"
> >
> >
> >Hi Mark,
> >
> >I read your draft.
> >First of all I think you misunderstood RFC 6085 and based on a wro= ng assumption you developed your solution.
> >
> >
> >What specifically do you think I've misunderstood? I was invol= ved in some of the conversations about that RFC while it was an ID, and all= I think it really is fundamentally saying is that an IPv6 packet with a mu= lticast IPv6 destination address isn't required to have a link-layer mu= lticast destination address - it can be a link-layer unicast destination ad= dress if useful or necessary.
> >
> >
> >
> >
> >=A0I suggest you take a look at http://t= ools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01
> >on Netext for PMIPv6.
> >
> >
> >I'll have a read.
> >
> >I believe that we should use multicast delivery as much as possibl= e on the downlink if the link is a shared link.
> >
> >
> >
> >
> >I agree with using multicast as much as possible to reduce duplica= te packets sent over the network. The proposal here is to use packet replic= ation and link-layer unicasts when doing so would either exceed the perform= ance of link-layer multicast and/or overcome the negative effects of link-l= ayer multicast, such as when larger volumes of multicast traffic impact uni= cast performance on the same link. Both of these issues occur on 802.11 lin= ks when there volume of multicast traffic is in the order of a few megabits= (or less, I've been testing with around 2.5 Mbps of video)
> >
> >
> >The main use case I've been thinking about (which I'll mak= e more obvious in the next revision), is a multicast IPTV service scenario = towards a residential customer, where the residential customer has a 802.11= network in their home rather than a wired one. IPv6 multicast/link-layer m= ulticast would be used all the way from the multicast source servers, acros= s the service provider network, up until the CPE in the residential custome= rs' homes, gaining the efficiencies of multicast. However, the CPE in t= he customer's house would then use IPv6 multicast/link-layer unicast of= the IPTV traffic over the 802.11 link to the customers end-hosts, saving t= hem having to put in wired infrastructure, or resorting to buying ethernet = over power devices to make their power cabling their wired infrastructure. = Note that there is still a low level of link-layer multicast traffic in the= customers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal i= s not eliminating
> =A0link-layer multicasts, just reducing them where possible and where = useful.
> >
> >
> >That's not to say this proposal is only useful in an 802.11 sc= enario. It could be used in any scenario where packet replication and link-= layer unicasting would provide useful benefits over link-layer multicasts. = It generally increases the data confidentiality of the multicast IPv6 traff= ic, and may help increase battery life of some devices.
> >
> >
> >Thanks very much,
> >Mark.
> >
> >
> >
> >Regards,
> >
> >Behcet
> >
> >
> >
> >
> >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler <dthaler@microsoft.com> wrote:
> >
> >http://tools.ietf.org/html/draft-thaler-ngtrans-= 6to4-multicast
> >>is work we did back in 2000 on this same topic. =A0 At the tim= e, the draft is written from
> >>the perspective of the 6to4 NBMA link, but the topic was discu= ssed (specifically by those
> >>in the acknowledgements section, and to a lesser extent by the= ngtrans WG as a whole)
> >>as being more generally applicable.
> >>
> >>There wasn't significant interest at the time and so the w= ork was dropped
> >>rather than updating the spec to use generic language.
> >>
> >>The same concept as in the above was however then used in 2001= in
> >>http://tools.ietf.org/html/draft-ietf-mboned-au= to-multicast
> >>(still specific to a particular link type though), which after= 11 years is now in the IESG :)
> >>
> >>The most relevant WG is MBoneD.
> >>
> >>-Dave
> >>
> >>
> >>> -----Original Message-----
> >>> From: ipv6-bounc= es@ietf.org [mailto:ipv6-bounc= es@ietf.org] On Behalf Of
> >>> Mark Smith
> >>> Sent: Thursday, March 28, 2013 8:22 PM
> >>> To: 6man@ietf.org > >>> Subject: "MLDv2 Procedures for Link-Layer Unicast De= livery of Multicast"
> >>>
> >>> Hi,
> >>>
> >>> The following is inspired by some work I did in around 20= 10/2011 on a
> >>> multicast TV service, where residential customers with Wi= fi networks
> >>> suffered from performance problems, and had to be advised= to buy
> >>> ethernet over power devices if they couldn't run wire= d ethernet to the STB
> >>> attached to their TV.
> >>>
> >>> I've done some experiments on my home wifi network, u= sing VLC, and
> >>> switching between multicast and unicast IPv6 to test the = concept. The wifi
> >>> performance issues disappear when the video is delivered = via unicast UDP.
> >>> (If people want to play with VLC and IPv6 multicast, emai= l me off-list, as there
> >>> are a few issues e.g. the GUI doesn't accept some of = the IPv6 multicast
> >>> parameters that the command line does).
> >>>
> >>> I think there is a possibility the technique could also b= e applied to
> >>> IGMPv3/ARP, although it depends on whether ARP has been i= mplemented
> >>> in a similar manner to IPv6 ND (e.g. an ARP equivalent to= NUD). My
> >>> understanding is that Linux has implemented ARP this way.= I'll do some more
> >>> research to verify this.
> >>>
> >>> I though I'd post it to see if there is merit in the = idea and it is worth spending
> >>> more of my time on. I looked for a IETF group more suitab= le to this, but didn't
> >>> seem to be able to find one. If there is one, please let = me know.
> >>>
> >>> Review and comments most appreciated.
> >>>
> >>> Thanks very much,
> >>> Mark.
> >>>
> >>>
> >>> ----- Forwarded Message -----
> >>> > From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> >>> > To: mar= kzzzsmith@yahoo.com.au
> >>> > Cc:
> >>> > Sent: Friday, 29 March 2013 1:45 PM
> >>> > Subject: New Version Notification for
> >>> > draft-smith-mldv2-link-unicast-00.txt
> >>> >
> >>> >
> >>> > A new version of I-D, draft-smith-mldv2-link-unicast= -00.txt
> >>> > has been successfully submitted by Mark Smith and po= sted to the IETF
> >>> > repository.
> >>> >
> >>> > Filename:=A0=A0=A0 =A0draft-smith-mldv2-link-unicast=
> >>> > Revision:=A0=A0=A0 =A000
> >>> > Title:=A0=A0=A0 =A0=A0=A0 =A0MLDv2 Procedures for Li= nk-Layer Unicast Delivery of
> >>> > Multicast
> >>> > IPv6
> >>> > Creation date:=A0=A0=A0 =A02013-03-29
> >>> > Group:=A0=A0=A0 =A0=A0=A0 =A0Individual Submission > >>> > Number of pages: 7
> >>> > URL:
> >>> > http://www.ietf.org/interne= t-drafts/draft-smith-mldv2-link-unicast-00.
> >>> > txt
> >>> > Status:
> >>> > http://datatracker.ietf.org/doc/dr= aft-smith-mldv2-link-unicast
> >>> > Htmlized:
> >>> > http://tools.ietf.org/html/draft-smi= th-mldv2-link-unicast-00
> >>> >
> >>> >
> >>> > Abstract:
> >>> > =A0 =A0Some multi-access link-layer technologies typ= ically not provide
> >>> > good
> >>> > =A0 =A0IPv6 multicast performance, using link-layer = multicasts, when the
> >>> > =A0 =A0volume of multicast traffic is significant.= =A0 It would be possible
> >>> > to
> >>> > =A0 =A0replicate and then link-layer unicast multica= st IPv6 traffic to
> >>> > =A0 =A0interested listeners to overcome these link-l= ayer performance
> >>> > =A0 =A0limitations.=A0 This memo describes MLDv2 and= IPv6 neighbor discovery
> >>> > =A0 =A0procedures to support link-layer unicast deli= very of multicast IPv6
> >>> > =A0 =A0traffic.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > The IETF Secretariat
> >>> >
> >>> ---------------------------------------------------------= -----------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listi= nfo/ipv6
> >>> ---------------------------------------------------------= -----------
> >>_______________________________________________
> >>MBONED mailing list
> >>MBONED@ietf.org
> >>https://www.ietf.org/mailman/listinfo/mboned
> >>
> >
> >
> >
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned

--
---
Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!


--047d7b3a7f10ae417e04d977d4d8-- From swb@internet2.edu Wed Apr 3 10:52:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7CB21F8DBF; Wed, 3 Apr 2013 10:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA3bUW1SUR01; Wed, 3 Apr 2013 10:52:32 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id D031E21F8D94; Wed, 3 Apr 2013 10:52:32 -0700 (PDT) Received: from mail187-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE010.bigfish.com (10.236.130.73) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Apr 2013 17:52:32 +0000 Received: from mail187-co9 (localhost [127.0.0.1]) by mail187-co9-R.bigfish.com (Postfix) with ESMTP id EF82B5403A4; Wed, 3 Apr 2013 17:52:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0811HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: S-2(zzbb2dI98dI154cP9371I1432Id799hzz1f42h1fc6h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz8275ch17326ah8275bhz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1b1cn1b1bi1155h) Received: from mail187-co9 (localhost.localdomain [127.0.0.1]) by mail187-co9 (MessageSwitch) id 1365011519831825_23762; Wed, 3 Apr 2013 17:51:59 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.244]) by mail187-co9.bigfish.com (Postfix) with ESMTP id BEB2B360282; Wed, 3 Apr 2013 17:51:59 +0000 (UTC) Received: from BY2PRD0811HT001.namprd08.prod.outlook.com (157.56.237.5) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Apr 2013 17:51:56 +0000 Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.91.164) with Microsoft SMTP Server (TLS) id 14.16.287.8; Wed, 3 Apr 2013 17:51:55 +0000 Message-ID: <515C6C39.8080503@internet2.edu> Date: Wed, 3 Apr 2013 13:51:53 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Richardson Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> In-Reply-To: <28368.1365004823@sandelman.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [67.241.75.185] X-OriginatorOrg: internet2.edu Cc: 6man , its@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:52:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/03/13 12:00, Michael Richardson allegedly wrote: > >>>>>> "Alexandru" == Alexandru Petrescu >>>>>> writes: >>> On 04/02/2013 12:55 PM, Alexandru Petrescu wrote: >>>>> IMO, you should follow what appears to be the consensus on >>>>> the subject: set the IID in whatever way you want, >>>> >>>> About this there is a tendency to agreement. The privacy >>>> aspect should be considered, balanced by a >>>> privacy-to-mobility tradeoff. >>> >>> Which privacy aspect? > > Alexandru> Offer privacy by default: avoid a reversible mapping > VIN-to- Alexandru> InterfaceID. Because, if a reversible mapping > Alexandru> VIN-to-InterfaceID Alexandru> existed, then it could be > exploited by attackers by Alexandru> reversing the Alexandru> > InterfaceID back into VIN, and exposing this personal Alexandru> > information to > > So, I have a question: how much privacy is actually contained in > the VIN or indexed by the VIN? Given that it's printed on the > windshield. Yes, it contains model, year and manufacturer of the > car, but all of that information is also visible by looking at the > vehicle. > > So the concern is that it be if the VIN can be discovered during > an online transaction of some kind that bad things can happen. Is > any priviledge going to be attached to the *VIN* itself (or to the > address derived from the VIN). Note that this doesn't meant that > the car doesn't have a private key with a certificate attaching > that private key to the VIN such that the vehicle can do > interesting things with the manufacturer systems, etc. I figured you knew this already - it's about correlation. IP addresses, for a familiar example, are not a problem in and of themselves. However, they are considered personal information, not to be revealed without justification, because they are relatively constant across multiple interactions, in all of which one or more of a person's identifying tokens will be present (e.g. cookies or an email address or just a session layer ID). Not only that but as you move and your IP address changes, the new IP address's traffic can be correlated with the old one, because some other details persist across the change. Because of that, because different pieces of communicated information have overlapping lifetimes, correlations can be drawn between many of them and all sorts of stuff can be gleaned. I can find out that the guy I've hired as a contract killer occasionally goes to the FBI office in the next town, for example. Same with a VIN - -- the problem is not exposing the VIN, it's having the VIN be associated with many other personal attributes on open networks. Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFcbDkACgkQF0TR2hENFASJ5QCgic6v0Udi+O7+p7kzYhQF7/bl UC8AoKLXQj3xFtoGTuY2LxXfy9C+JGCA =kbYL -----END PGP SIGNATURE----- From dougb@dougbarton.us Wed Apr 3 12:08:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8546E21F862B for ; Wed, 3 Apr 2013 12:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGukCho+hDiy for ; Wed, 3 Apr 2013 12:08:32 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5457F21F8606 for ; Wed, 3 Apr 2013 12:08:32 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:7ce7:29f0:be13:c045] (unknown [IPv6:2001:470:d:5e7:7ce7:29f0:be13:c045]) by dougbarton.us (Postfix) with ESMTPSA id E451722B1C for ; Wed, 3 Apr 2013 19:08:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1365016112; bh=ez0rim4BNNjZAzkAtGAEqXHx6fOVSXvGZjNg7ryVuZI=; h=Date:From:To:Subject:References:In-Reply-To; b=tO/VXiYS40b1qm9vR3/i1EcD7VYNe7Xm2elToBNQqrBsvqYb6SVad3dFSnKNbK9ZD hBqeCwG61Re5UgEZlqmJavlyGVsxfIEqGkUpN/Q2iMd2FLFQXSirc7Y0ZFF4QSTgqh zgWv3/iZKnB0ty77/nkx5B/qmraRvwvBHM6E26BA= Message-ID: <515C7E2F.2080709@dougbarton.us> Date: Wed, 03 Apr 2013 12:08:31 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> In-Reply-To: <28368.1365004823@sandelman.ca> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:08:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2013 09:00 AM, Michael Richardson wrote: | So, I have a question: how much privacy is actually contained in the | VIN or indexed by the VIN? Given that it's printed on the windshield. | Yes, it contains model, year and manufacturer of the car, but all of | that information is also visible by looking at the vehicle. There's orders of magnitude different in having to walk up to the windshield of every car you're interested in vs. passively sniffing IP traffic to discover VINs of thousands of cars in a go. And dare I mention the big brother aspect of setting up roadside monitors? And what about son-of-google-street-view? The privacy aspects of being able to reverse-map IP traffic to VINs are staggering. I remain unconvinced that there should be any special case in the protocol for this, as I've yet to see an argument as to why ULAs are not sufficient. I remain violently opposed to any protocol definition that supports VIN <> IP address mapping. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBCAAGBQJRXH4vAAoJEFzGhvEaGryEkvAIAL72fEzKUqpLEcvdyh177Vla dZov3A88iIMJuq6dE4xG7RzMSRG5ueFkelIB07jxo0TyXQmvvliS029RKeWlZed9 BhIMZwWw2AY2jQVnQTvT9pwZ+8KrY94s4q0YpVzdKsJKKhErvISKnzwn1qCtKFlv 7tsfSXcCq7E4WgcuQSxtUIyaTN/Psw27QVTrJ8PJTHlGTIzrkJrRIczjLJy0pHvv Ekq9Bi/n/w65CQYn1zNume/goW0eUDk9rVHf/XopD5ugnRHW1gn6fkDxjDKc9Jc9 I1QU4nHhP82NiRiqS9xzgXUpMjm/+RCSHYPvAKCcTGdACBDtXUhd5QU9w4gJ3YA= =EAHc -----END PGP SIGNATURE----- From albert.e.manfredi@boeing.com Wed Apr 3 12:36:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB70421F8CC9 for ; Wed, 3 Apr 2013 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8osk6676lwud for ; Wed, 3 Apr 2013 12:36:12 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 328C721F8CA0 for ; Wed, 3 Apr 2013 12:36:12 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r33JaBf5005647 for ; Wed, 3 Apr 2013 12:36:11 -0700 Received: from XCH-PHX-208.sw.nos.boeing.com (xch-phx-208.sw.nos.boeing.com [137.136.238.19]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r33JaAWO005635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Apr 2013 12:36:11 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.40]) by XCH-PHX-208.sw.nos.boeing.com ([169.254.8.166]) with mapi id 14.02.0328.011; Wed, 3 Apr 2013 12:36:10 -0700 From: "Manfredi, Albert E" To: Alexandru Petrescu Subject: RE: I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMC3VsWGPEBsrZU2lVqRQiRtseZjE8XeA///tIJA= Date: Wed, 3 Apr 2013 19:36:10 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648101E304@XCH-PHX-503.sw.nos.boeing.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> In-Reply-To: <515C2CFF.3060809@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:36:12 -0000 > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Yes, the ULA prefix (RFC 4193 section 3.2.2) generates a 48bit prefix > randomly. That suggested algorithm is seeded by time, EUI-64 into a > key, and then SHA-1. >=20 > > Anyway.. the idea is that you randomize the prefix... >=20 > Yes. We may need to say how. >=20 > Just saying RNG may not be enough, I dont know. I really don't put much weight on this. It's just one suggestion. I dare sa= y, pick a decent PRNG, pick a seed out of the air, and for all intents and = purposes, you have your ULA prefix. After all, this use of ULA is only for = in-vehicle comms, and should not transit through any car-Internet router. R= andomness is only a safety net, in case a ULA sneaks out of the local route= r. I don't think we should tie the VIN or any EUI-64 strictly to this idea of = using ULAs. > Also, that Network mobility doesnt prohibit neither suggests that the > prefix of a moving network (MNP: Mobile Network Prefix) be exchanged > between two distinct moving networks such as to establish routes > between > them (route exchange). Well, I have a question about this. I've seen mobility done in a number of = ways. Move individual interfaces, using the home agent approach; move entir= e address blocks, where the routing protocol keeps track of subnet location= ; or use a link layer that always ties the moving subnet(s) to the same geo= graphic location "back home," making the job easier for the IP layer. Added to this, for a vehicle scenario, we may (probably will) also need som= ething along the lines of 802.11 ad-hoc networks, for those tactical car-ca= r and car-road comms. In principle, can't a combination of all of these schemes be used in vehicl= es? For instance, if your IP service is the type that replaces the OnStar s= cheme (used by GM in the US), a lot of that information is not overly time = constrained. And since OnStar is a 3G system, it "knows" what each client's= home network is. > The random part of the ULA may be needed for inter-vehicle > communications. I.e. use fd00:fef2:3214::/64 inside one vehicle, > and fd00:fff2:3214::/64 in the other vehicle. Use no prefix on the > ad-hoc link between the two egress interfaces of the mobile router (use > their link-local addresses there). >=20 > If those two prefixes were not random, then collision between prefixes > may occur the moment the routes are exchanged between the vehicles. No, I would not contaminate the Internet deliberately this way. It seems to= me that each car should be assigned a /64 prefix which is globally unique,= for this sort of use. Just like every household. I really don't see why th= is type of inter-car communications should be thought of as any different f= rom home nets. And again, the mobility aspect can be resolved in at least t= wo different ways that I believe to be in common use already. Bert From joelja@bogus.com Wed Apr 3 12:49:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31A821F8BF2 for ; Wed, 3 Apr 2013 12:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvVbrFVPxyRO for ; Wed, 3 Apr 2013 12:49:55 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6321F8A91 for ; Wed, 3 Apr 2013 12:49:55 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r33JnraV084401 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 3 Apr 2013 19:49:53 GMT (envelope-from joelja@bogus.com) Message-ID: <515C87DB.4020303@bogus.com> Date: Wed, 03 Apr 2013 12:49:47 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Doug Barton , ipv6@ietf.org Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <515C7E2F.2080709@dougbarton.us> In-Reply-To: <515C7E2F.2080709@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 03 Apr 2013 19:49:54 +0000 (UTC) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:49:56 -0000 On 4/3/13 12:08 PM, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 04/03/2013 09:00 AM, Michael Richardson wrote: > | So, I have a question: how much privacy is actually contained in the > | VIN or indexed by the VIN? Given that it's printed on the windshield. > | Yes, it contains model, year and manufacturer of the car, but all of > | that information is also visible by looking at the vehicle. > > There's orders of magnitude different in having to walk up to the > windshield of every car you're interested in vs. passively sniffing IP > traffic to discover VINs of thousands of cars in a go. > > And dare I mention the big brother aspect of setting up roadside > monitors? And what about son-of-google-street-view? The privacy aspects > of being able to reverse-map IP traffic to VINs are staggering. It is relatively costly today to set a distributed monitoring infrastructure that tracks the comings and goings of automobiles (and by proxy their owners) (think city of london or stockholm) and the use of and access to such datasets is generally restricted and subject to strong privacy protections). it should not be the case that we trivially enable such data-gathering. > I remain unconvinced that there should be any special case in the > protocol for this, as I've yet to see an argument as to why ULAs are not > sufficient. I remain violently opposed to any protocol definition that > supports VIN <> IP address mapping. > > Doug > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (GNU/Linux) > > iQEcBAEBCAAGBQJRXH4vAAoJEFzGhvEaGryEkvAIAL72fEzKUqpLEcvdyh177Vla > dZov3A88iIMJuq6dE4xG7RzMSRG5ueFkelIB07jxo0TyXQmvvliS029RKeWlZed9 > BhIMZwWw2AY2jQVnQTvT9pwZ+8KrY94s4q0YpVzdKsJKKhErvISKnzwn1qCtKFlv > 7tsfSXcCq7E4WgcuQSxtUIyaTN/Psw27QVTrJ8PJTHlGTIzrkJrRIczjLJy0pHvv > Ekq9Bi/n/w65CQYn1zNume/goW0eUDk9rVHf/XopD5ugnRHW1gn6fkDxjDKc9Jc9 > I1QU4nHhP82NiRiqS9xzgXUpMjm/+RCSHYPvAKCcTGdACBDtXUhd5QU9w4gJ3YA= > =EAHc > -----END PGP SIGNATURE----- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From Ted.Lemon@nominum.com Wed Apr 3 16:36:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247C421F8EC6; Wed, 3 Apr 2013 16:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5ql9DaMpOI9; Wed, 3 Apr 2013 16:36:22 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3421F8D90; Wed, 3 Apr 2013 16:36:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUVy88VkfIguqWzxasaw5dBXHFfJAnmVo@postini.com; Wed, 03 Apr 2013 16:36:22 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 14AD11281DB; Wed, 3 Apr 2013 16:36:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0B13F190060; Wed, 3 Apr 2013 16:36:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 16:36:17 -0700 From: Ted Lemon To: Michael Richardson Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMIRmAL55WRTfvUStGNkrMagsAZjFnGEA Date: Wed, 3 Apr 2013 23:36:17 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> In-Reply-To: <28368.1365004823@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <461944FDB576A641AB42696B0C1002EB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 23:36:23 -0000 On Apr 3, 2013, at 12:00 PM, Michael Richardson wrote: > So, I have a question: how much privacy is actually contained in the > VIN or indexed by the VIN? Given that it's printed on the windshield. > Yes, it contains model, year and manufacturer of the car, but all of > that information is also visible by looking at the vehicle. =20 The fact that the VIN is printed on the windshield is not as practical a pr= oblem as it would be if the VIN could be trivially retrieved electronically= . How big a privacy issue that is, I don't know, but it would certainly m= ake tracking the car easy. > I am way more concerned about privacy concerns where the VIN, given that > it can be easily known, can then be used to derive the prefix that the > vehicle uses and then seek out that vehicle's systems electronically. Indeed, if a car thief wanted to hack their way into the car to steal it, b= eing able to read the VIN off the window and then immediately identify whic= h messages were coming from that car would be a minor or major problem, dep= ending on how bad the security on the car was. From mcr@sandelman.ca Wed Apr 3 18:00:27 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB51A21F8A09; Wed, 3 Apr 2013 18:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeKvNrnC0TRA; Wed, 3 Apr 2013 18:00:27 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 26BA921F8814; Wed, 3 Apr 2013 18:00:27 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 53BB520168; Wed, 3 Apr 2013 21:09:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5D04C638E8; Wed, 3 Apr 2013 21:00:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B98063781; Wed, 3 Apr 2013 21:00:11 -0400 (EDT) From: Michael Richardson To: 6man , its@ietf.org Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt In-Reply-To: <515C6C39.8080503@internet2.edu> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <515C6C39.8080503@internet2.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 01:00:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Scott" =3D=3D Scott Brim writes: >> So, I have a question: how much privacy is actually contained in >> the VIN or indexed by the VIN? Given that it's printed on the >> windshield. Yes, it contains model, year and manufacturer of the >> car, but all of that information is also visible by looking at the >> vehicle. Scott> I figured you knew this already - it's about correlation. IP Scott> addresses, for a familiar example, are not a problem in and of Scott> themselves. However, they are considered personal Scott> information, not to a) This is true of all IP addresses, regardless of how they are derived. b) In general, we aren't talking about IP addresses that will be used to communicate out to the Internet, but rather within a vehicle, and=20 possibly with adjacent vehicles. (PLEASE recall, the internet protocol suite is used for more than just the Internet)=20 So, while you can get correlation easily from addresses, you can also get them from license plates, and probably a dozen other wireless technologies already present in vehicles (like the tire pressure systems we keep hearing about)... What *additional* privacy violation does knowledge of the VIN do? Or alternatively, what network attacks become possible if you have knowledge of the VIN, which means that you know what the internal addresses are? Scott> goes to the FBI office in the next town, for example. Same Scott> with a VIN=20 Scott> -- the problem is not exposing the VIN, it's having the VIN be Scott> associated with many other personal attributes on open networks. I'm not convinced that there are any advantages to deriving a vehicle-specific prefix from the VIN. It seems that vendors should get space from the RIRs, and allocate the numbers 1.2.3.4., etc.=20=20 If they want to do this from the VIN, they should do this with a keyed hash and keep the key private. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUVzQm4qHRg3pndX9AQLwHwQAwXk6SrkTCjItqsYPLiQtcYmp+l4pxDci skSihskK8G4XHdfRkAu+S27dsbWljbXed/dlBMtCI3tzATU2tf4ElyUsjlcGGCHp UwD/wThYE+3Dr2QXg6CczL3fueeHNsnXVNHPAqIfrWJwOCMbp8uuSfQmogEuzfMd LtMX9+5u0mY= =2sim -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Apr 3 18:13:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40E921F860A; Wed, 3 Apr 2013 18:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TINOrea804wf; Wed, 3 Apr 2013 18:13:37 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DB38221F85F5; Wed, 3 Apr 2013 18:13:36 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0EBA020168; Wed, 3 Apr 2013 21:22:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 13103638E8; Wed, 3 Apr 2013 21:13:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 015C863781; Wed, 3 Apr 2013 21:13:21 -0400 (EDT) From: Michael Richardson To: 6man , "" Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Sender: mcr@sandelman.ca Cc: Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 01:13:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ted" =3D=3D Ted Lemon writes: >> So, I have a question: how much privacy is actually contained in the >> VIN or indexed by the VIN? Given that it's printed on the windshie= ld. >> Yes, it contains model, year and manufacturer of the car, but all of >> that information is also visible by looking at the vehicle.=20=20 Ted> The fact that the VIN is printed on the windshield is not as Ted> practical a problem as it would be if the VIN could be Ted> trivially retrieved electronically. How big a privacy issue Ted> that is, I don't know, but it would certainly make tracking the Ted> car easy.=20 So, we have assumed that a 802.11p sniffer sitting in Times Square can sniff the prefix used by passing vehicles. If I put another sniffer outside Wrigley Field, I can do correlation... how does knowing the VIN help me? I already know it is the same car. If I can derive the VIN from the prefix, I agree that it helps identify the vehicle, but not really. If any of this stuff is going to be useful, there will already be a collision avoidance protocol that will tell each car (even when they are parked) where the other vehicles are, so that they can be avoided. If I can rederive the prefix from the VIN, then it seems we also have problems. What I'm saying is that I don't=20 think that there are *new*=20 privacy problems here.=20 >> I am way more concerned about privacy concerns where the VIN, given = that >> it can be easily known, can then be used to derive the prefix that t= he >> vehicle uses and then seek out that vehicle's systems electronically. Ted> Indeed, if a car thief wanted to hack their way into the car to Ted> steal it, being able to read the VIN off the window and then Ted> immediately identify which messages were coming from that car Ted> would be a minor or major problem, depending on how bad the Ted> security on the car was.=20 If there are security problems with the car security system, I don't think the problem of identifying the vehicle by VIN is a hurdle.=20=20 Use ICMP echo ("ping") RTT as sonar (see, it was named probably), and when = you are nearby, tell the vehicle to turn itself on, honk the horn, and pop the trunk.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUVzTsIqHRg3pndX9AQLESQQAvs27WEUaBhr3tFw4+55aFphCHI4JxjWN q4T/Y1sCHZIZFGaugfgplXR6H10T5gtTDnogJMusNxC1kimgNp6vaenH+YCqvhh/ ZYujTLANxqRnBOCht6SYlVNoJS8k4PzpqDMtLg+dcIq16xWx2jGvKwPUVJYqjCfx +4g4HeLBezs= =DkE8 -----END PGP SIGNATURE----- --=-=-=-- From albert.e.manfredi@boeing.com Wed Apr 3 18:18:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340DC21F8C98; Wed, 3 Apr 2013 18:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV4hTRnra+nl; Wed, 3 Apr 2013 18:18:54 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 87CEF21F8BBD; Wed, 3 Apr 2013 18:18:54 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r341Isad030133; Wed, 3 Apr 2013 18:18:54 -0700 Received: from XCH-PHX-306.sw.nos.boeing.com (xch-phx-306.sw.nos.boeing.com [137.136.239.30]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r341IrHe030120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Apr 2013 18:18:53 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.40]) by XCH-PHX-306.sw.nos.boeing.com ([169.254.6.81]) with mapi id 14.02.0328.011; Wed, 3 Apr 2013 18:18:53 -0700 From: "Manfredi, Albert E" To: Michael Richardson , 6man , "" Subject: RE: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMC3VsWGPEBsrZU2lVqRQiRtseZjE8XeAgAAsOICAAH9ggIAAGx4A//+LNGA= Date: Thu, 4 Apr 2013 01:18:52 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648101E44F@XCH-PHX-503.sw.nos.boeing.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> In-Reply-To: <7858.1365038000@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 01:18:55 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Michael Richardson > If I can derive the VIN from the prefix, I agree that it helps identify > the vehicle, but not really. If any of this stuff is going to be > useful, there will already be a collision avoidance protocol that will > tell each car (even when they are parked) where the other vehicles are, > so that they can be avoided. >=20 > If I can rederive the prefix from the VIN, then it seems we also have > problems. >=20 > What I'm saying is that I don't > think that there are *new* > privacy problems here. I would agree with that comment, but then again, I don't see any compelling= reason (nor any advantage) to use the VIN in the IPv6 address anyway. So p= rivacy concerns or no, I would reiterate my suggestion that if the VIN is u= sed, it be used as part of a DNS name, rather than an integral part of the = address. Bert From dougb@dougbarton.us Wed Apr 3 18:39:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F335C21F8EC6 for ; Wed, 3 Apr 2013 18:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksk6tzGzaegb for ; Wed, 3 Apr 2013 18:39:17 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6690B21F877A for ; Wed, 3 Apr 2013 18:39:17 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:4910:bd04:5b3f:5d14] (unknown [IPv6:2001:470:d:5e7:4910:bd04:5b3f:5d14]) by dougbarton.us (Postfix) with ESMTPSA id 1004722B8D for ; Thu, 4 Apr 2013 01:39:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1365039557; bh=dvb1V65gfLq5lQMkFXsDnprihXf0wpCEUcxZruzV44w=; h=Date:From:To:Subject:References:In-Reply-To; b=p1xPNggGH9L2GMM90f/ef1skOC0y56kcITWw3f0N9ULJ9131oHYHWcvAkJcFY+kHQ 2bi+affkBTeFTpnhZTNLQhaD7aGRWI60nv8WHpLBBJKl2r9y1Me1zixnXxR8KuTXFz gGr6gCYNtOPZKP4AkYVCf+v8a3TwJUYOy555Tl68= Message-ID: <515CD9C4.1080004@dougbarton.us> Date: Wed, 03 Apr 2013 18:39:16 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> In-Reply-To: <7858.1365038000@sandelman.ca> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 01:39:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2013 06:13 PM, Michael Richardson wrote: | So, we have assumed that a 802.11p sniffer sitting in Times Square | can sniff the prefix used by passing vehicles. If I put another | sniffer outside Wrigley Field, I can do correlation... how does | knowing the VIN help me? I already know it is the same car. You're extrapolating from a condition that fits your view (tracking 1 vehicle). The point that I and others are making is that being able to cross-reference VIN and IP address will lead to the ability for various actors to be able to track massive numbers of vehicles. Some of those folks will also have access to the VIN database (whether they are state-sponsored, crackers, or "other") which leads to a whole new level of privacy violation. | If I can derive the VIN from the prefix, I agree that it helps | identify the vehicle, but not really. So if I know the VIN number of the vehicle I'm interested in, all I have to do is get on the network and figure out where it's originating its traffic from, and now I can dramatically narrow down its location, if not pinpoint it with a high degree of accuracy. I've run out of adjectives to describe how bad of an idea this is. I find it hard to believe that you're not seeing the problems here. | If any of this stuff is going to be useful, there will already be a | collision avoidance protocol that will tell each car (even when | they are parked) where the other vehicles are, so that they can be | avoided. I have no idea what this is supposed to mean. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBCAAGBQJRXNnEAAoJEFzGhvEaGryEMegH/jc+1R63D3TdhFiCZyzNW9Ei uHwv5PGR8BrFKY8698okO24mDPZLTfdIV48XadMi0bJHlLpiYPwAJOyF75SRoyBo hPv5+ougB0vwfp+7skJcLsYabnWejILyEDAw3ee3GXDlXJmM786k7/uqSHRh6FP3 kaBb0IL7Bwkc/kbjlQ+bBQr/KPTyAqzK2LIBiJY3m4loD8W/cQSJLYMd8VesKnBG UThrniH70ZPbq1GtSCAuLhufbWzTLbuMwfo9tQBT5vtpP07RCkCimTDcZfrRa6uI yEVaeA/XEKeaYLyhZjfWDL71tIEhAUBGOcgv8XQdsWLZfrXVNCi43hhn27R6C6s= =mSqQ -----END PGP SIGNATURE----- From Ted.Lemon@nominum.com Wed Apr 3 19:14:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B5721F8648; Wed, 3 Apr 2013 19:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIKaeWHsmftb; Wed, 3 Apr 2013 19:14:24 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7739B21F863B; Wed, 3 Apr 2013 19:14:24 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUVziAH8czjFSkJdysGgiezVOXb9ivzuR@postini.com; Wed, 03 Apr 2013 19:14:24 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E51A51B8A87; Wed, 3 Apr 2013 19:14:23 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D9B3B19005D; Wed, 3 Apr 2013 19:14:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 19:14:23 -0700 From: Ted Lemon To: Michael Richardson Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMIRmAL55WRTfvUStGNkrMagsAZjFnGEAgAAbHwCAABEOgA== Date: Thu, 4 Apr 2013 02:14:23 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> In-Reply-To: <7858.1365038000@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <84AB3C2D2E950A4D9706874863224422@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 02:14:25 -0000 On Apr 3, 2013, at 9:13 PM, Michael Richardson wrot= e: > So, we have assumed that a 802.11p sniffer sitting in Times Square can > sniff the prefix used by passing vehicles. If I put another sniffer > outside Wrigley Field, I can do correlation... how does knowing the VIN > help me? I already know it is the same car. Yes, indeed, this seems to argue for vehicles renumbering on a regular basi= s, at least on the prefix that they are using to communicate with the outsi= de world. From swb@internet2.edu Thu Apr 4 07:02:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F6321F8D03; Thu, 4 Apr 2013 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOp9itFwRs-2; Thu, 4 Apr 2013 07:02:39 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id A56ED21F8EF1; Thu, 4 Apr 2013 07:02:39 -0700 (PDT) Received: from mail210-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Apr 2013 14:02:39 +0000 Received: from mail210-co9 (localhost [127.0.0.1]) by mail210-co9-R.bigfish.com (Postfix) with ESMTP id 29FE0980208; Thu, 4 Apr 2013 14:02:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.5; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: S-1(zzbb2dI98dI154cP1432Izz1f42h1fc6h1d77h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kzz8275ch17326ahz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1b1cn1b1bi1155h) Received: from mail210-co9 (localhost.localdomain [127.0.0.1]) by mail210-co9 (MessageSwitch) id 1365084157442460_32749; Thu, 4 Apr 2013 14:02:37 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.245]) by mail210-co9.bigfish.com (Postfix) with ESMTP id 59E2EBC005F; Thu, 4 Apr 2013 14:02:37 +0000 (UTC) Received: from BL2PRD0811HT005.namprd08.prod.outlook.com (157.56.241.5) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Apr 2013 14:02:35 +0000 Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.107.168) with Microsoft SMTP Server (TLS) id 14.16.287.8; Thu, 4 Apr 2013 14:02:34 +0000 Message-ID: <515D87F9.6000003@internet2.edu> Date: Thu, 4 Apr 2013 10:02:33 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Richardson Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> In-Reply-To: <7858.1365038000@sandelman.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [67.241.75.185] X-OriginatorOrg: internet2.edu Cc: 6man , Ted Lemon , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:02:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/03/13 21:13, Michael Richardson allegedly wrote: > If I can derive the VIN from the prefix, I agree that it helps > identify the vehicle, but not really. If any of this stuff is > going to be useful, there will already be a collision avoidance > protocol that will tell each car (even when they are parked) where > the other vehicles are, so that they can be avoided. > > If I can rederive the prefix from the VIN, then it seems we also > have problems. The car is less of an issue than the people. If you start with the VIN in packets over radio, you can the owner, and then do correlations to derive personal information. Yes you can figure out if the owner is the one communicating, to start with, based on previous info. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFdh/gACgkQF0TR2hENFATUfgCfSBJs4/oIPJH7W9dCtA5VnUsi at4An3p8x+7kvdi/X/aLXv7GI5gZCRzu =KcnM -----END PGP SIGNATURE----- From mcr@sandelman.ca Thu Apr 4 07:56:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F357B21F90A1 for ; Thu, 4 Apr 2013 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyvP5SVcxoVS for ; Thu, 4 Apr 2013 07:56:22 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0396E21F902A for ; Thu, 4 Apr 2013 07:56:21 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id BE23A20168; Thu, 4 Apr 2013 11:05:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 47BD7638E8; Thu, 4 Apr 2013 10:56:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3715E638E7; Thu, 4 Apr 2013 10:56:04 -0400 (EDT) From: Michael Richardson To: ipv6@ietf.org Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt In-Reply-To: <515CD9C4.1080004@dougbarton.us> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <515CD9C4.1080004@dougbarton.us> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:56:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Doug" =3D=3D Doug Barton writes: Doug> | If I can derive the VIN from the prefix, I agree that it helps Doug> | identify the vehicle, but not really. Doug> So if I know the VIN number of the vehicle I'm interested in, all= I Doug> have to do is get on the network and figure out where it's origin= ating Doug> its traffic from, and now I can dramatically narrow down its loca= tion, Doug> if not pinpoint it with a high degree of accuracy. You just assumed that the VIN-derived prefix traffic is on the "network", but repeatedly, I say that most of it is inside of the vehicle. And I'm saying that knowing the VIN doesn't significantly *help* you find the vehicle, you can find it *without the VIN*.=20=20 If you are a party that has access to the VIN database, you likely are a state actor, and you also have access to the VIN to OmniStar mapping and a court, and you could just serve a warrant on OmniStar or the manufacturer or whomever you like. Doug> I've run out of adjectives to describe how bad of an idea this is= . I Doug> find it hard to believe that you're not seeing the problems Doug> here. Doug> | If any of this stuff is going to be useful, there will already = be a Doug> | collision avoidance protocol that will tell each car (even when Doug> | they are parked) where the other vehicles are, so that they can= be Doug> | avoided. Doug> I have no idea what this is supposed to mean. That's the problem. You have no idea what I'm talking about, but you keep repeating the same thing about how you can do all this magic. I keep saying, "it's not magic, it's much worse than you are saying, and we can do all of this without knowing the VIN mapping" If you want location privacy, you have to avoid disclosing your location to the Internet. Thinking that hiding the VIN will give that to you is just security through obscurity. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUV2Ug4qHRg3pndX9AQJUzAQAuozPS0rUwLcsR2xTMzGBAmVbyIIY1+EV lDhRqZFL1mMpeIvwg86PM9wTuFOE8xQybXxOUlEAsfQ0rBaI8X8lxMOEZ48lcreM GgEKQptAgw09M/L0s3SB1HjVqiobtLy7wsGXUvb2hOsmlf5G7mrw61nznjp4qy7W 8wV/G0dZ8Ig= =oqxz -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Apr 4 08:02:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DB121F899E; Thu, 4 Apr 2013 08:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfc9UGdelvyv; Thu, 4 Apr 2013 08:02:35 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB821F88BF; Thu, 4 Apr 2013 08:02:35 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D2D4F20168; Thu, 4 Apr 2013 11:11:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 84346638E8; Thu, 4 Apr 2013 11:02:19 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 73D67638E7; Thu, 4 Apr 2013 11:02:19 -0400 (EDT) From: Michael Richardson To: Ted Lemon Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Sender: mcr@sandelman.ca Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:02:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ted" =3D=3D Ted Lemon writes: >> So, we have assumed that a 802.11p sniffer sitting in Times Square c= an >> sniff the prefix used by passing vehicles. If I put another sniffer >> outside Wrigley Field, I can do correlation... how does knowing the = VIN >> help me? I already know it is the same car. Ted> Yes, indeed, this seems to argue for vehicles renumbering on a Ted> regular basis, at least on the prefix that they are using to Ted> communicate with the outside world.=20 Yes. I used two locations, but I assumed that whomever owns the road-side lighting system has thousands of such sniffers.=20=20 I think that imadali-its-vinipv6 is the wrong idea. If it is useful for a manufacturer to derive a subnet-ID from a VIN, that's fine, but I think it's a private matter. Let's write a BCP on how a manufacturer might do this in a way such that the the VIN <-> subnet prefix mapping is neither reversable, nor is it reproduceable. (I.e. I can't get the VIN from the subnet-ID, and I also can't get the subnet-ID from the VIN) Only the manufacturer *might* know the mapping, and maybe we can write the BCP such that the manufacturer can forget it too. The manufacturer likely goes to get RIR space just like any other Enterprise. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUV2V+4qHRg3pndX9AQJPNAP9EbxWTRbvOS64lkp2yZ3WSOEIQvt4G/Jx rREzqF4npDsN/alLeMD66Tp3hkXfBLoc5B41MBuIzD6eAzbFHPfFB4tCodwe7pBA w6si5lQFoVRhASOLmwg/gmVjHt43fg6+ETGTdSyxqj4KHQmBO6YdB9D/slHsO9pz gFJ4hgKVqFw= =5jiu -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Thu Apr 4 08:16:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2864D21F93C5 for ; Thu, 4 Apr 2013 08:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.214 X-Spam-Level: X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRvEvFFMhc3W for ; Thu, 4 Apr 2013 08:16:48 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 476A921F9409 for ; Thu, 4 Apr 2013 08:16:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r34FGlTn025845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 4 Apr 2013 17:16:47 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r34FGko8013434 for ; Thu, 4 Apr 2013 17:16:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r34FGbPS014219 for ; Thu, 4 Apr 2013 17:16:46 +0200 Message-ID: <515D9955.6080508@gmail.com> Date: Thu, 04 Apr 2013 17:16:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <515C7E2F.2080709@dougbarton.us> In-Reply-To: <515C7E2F.2080709@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:16:49 -0000 Le 03/04/2013 21:08, Doug Barton a écrit : > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > On 04/03/2013 09:00 AM, Michael Richardson wrote: | So, I have a > question: how much privacy is actually contained in the | VIN or > indexed by the VIN? Given that it's printed on the windshield. | > Yes, it contains model, year and manufacturer of the car, but all of > | that information is also visible by looking at the vehicle. > > There's orders of magnitude different in having to walk up to the > windshield of every car you're interested in vs. passively sniffing > IP traffic to discover VINs of thousands of cars in a go. Automatic shooting (taking picture of) license plate is a common practice in certain automatic law enforcement, and parking security. The VIN being smaller than the plate may be just a matter of when higher sensor resolutions become available. I would not be surprised to see automated shooting of VIN in the future for various applications. The VIN must remain visible. One of the privacy problems may lie in that requirement per se. And, on the contrary, it could also be used to securely produce a request of an IP service from the vehicle in line of sight, when infrastructure is not available. > And dare I mention the big brother aspect of setting up roadside > monitors? That possibility may already be there. It may be that 802.11p/DSRC/WAVE sends periodic beacons unsecured out of the car, which may contain MAC addresses. (I just suppose). > And what about son-of-google-street-view? I suppose even the father-google-street-view may already have some privacy concerns. Although it is obvious that the engineers went to large efforts to anonymize faces and license plates, its application still misses some points. I have seen a easily dateable picture of StreetView with easily recognizable faces of law enforcement officer and a person being fined. And pictures of intimate clothes out in the air drying, invisible otherwise. I guess they collect these fun things somewhere. > The privacy aspects of being able to reverse-map IP traffic to VINs > are staggering. > > I remain unconvinced that there should be any special case in the > protocol for this, as I've yet to see an argument as to why ULAs are > not sufficient. I remain violently opposed to any protocol > definition that supports VIN <> IP address mapping. Ok. Alex > > Doug > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) > > iQEcBAEBCAAGBQJRXH4vAAoJEFzGhvEaGryEkvAIAL72fEzKUqpLEcvdyh177Vla > dZov3A88iIMJuq6dE4xG7RzMSRG5ueFkelIB07jxo0TyXQmvvliS029RKeWlZed9 > BhIMZwWw2AY2jQVnQTvT9pwZ+8KrY94s4q0YpVzdKsJKKhErvISKnzwn1qCtKFlv > 7tsfSXcCq7E4WgcuQSxtUIyaTN/Psw27QVTrJ8PJTHlGTIzrkJrRIczjLJy0pHvv > Ekq9Bi/n/w65CQYn1zNume/goW0eUDk9rVHf/XopD5ugnRHW1gn6fkDxjDKc9Jc9 > I1QU4nHhP82NiRiqS9xzgXUpMjm/+RCSHYPvAKCcTGdACBDtXUhd5QU9w4gJ3YA= > =EAHc -----END PGP SIGNATURE----- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From alexandru.petrescu@gmail.com Thu Apr 4 08:20:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088D121F8B64 for ; Thu, 4 Apr 2013 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltS-j-+-YDzy for ; Thu, 4 Apr 2013 08:20:38 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCF21F8556 for ; Thu, 4 Apr 2013 08:20:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r34FKSHs027395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 4 Apr 2013 17:20:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r34FKSv4014596 for ; Thu, 4 Apr 2013 17:20:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r34FKRMj024593 for ; Thu, 4 Apr 2013 17:20:28 +0200 Message-ID: <515D9A3B.1040607@gmail.com> Date: Thu, 04 Apr 2013 17:20:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <515CD9C4.1080004@dougbarton.us> In-Reply-To: <515CD9C4.1080004@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:20:40 -0000 Le 04/04/2013 03:39, Doug Barton a écrit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 04/03/2013 06:13 PM, Michael Richardson wrote: > > | So, we have assumed that a 802.11p sniffer sitting in Times Square > | can sniff the prefix used by passing vehicles. If I put another > | sniffer outside Wrigley Field, I can do correlation... how does > | knowing the VIN help me? I already know it is the same car. > > You're extrapolating from a condition that fits your view (tracking 1 > vehicle). The point that I and others are making is that being able to > cross-reference VIN and IP address will lead to the ability for > various actors to be able to track massive numbers of vehicles. Some > of those folks will also have access to the VIN database (whether they > are state-sponsored, crackers, or "other") which leads to a whole new > level of privacy violation. Understood here. Remark, there may still exist possibilities in which mapping VIN-IP (direct or indirect, parts of total) may be done in a privacy-conserving manner, if that brings some advantage to some application. > | If I can derive the VIN from the prefix, I agree that it helps > | identify the vehicle, but not really. > > So if I know the VIN number of the vehicle I'm interested in, all I > have to do is get on the network and figure out where it's originating > its traffic from, and now I can dramatically narrow down its location, > if not pinpoint it with a high degree of accuracy. Ok, it is easier for one to locate a vehicle in that way. > I've run out of adjectives to describe how bad of an idea this is. I > find it hard to believe that you're not seeing the problems here. I think there may be some problems. Alex > > | If any of this stuff is going to be useful, there will already be a > | collision avoidance protocol that will tell each car (even when > | they are parked) where the other vehicles are, so that they can be > | avoided. > > I have no idea what this is supposed to mean. > > > Doug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (GNU/Linux) > > iQEcBAEBCAAGBQJRXNnEAAoJEFzGhvEaGryEMegH/jc+1R63D3TdhFiCZyzNW9Ei > uHwv5PGR8BrFKY8698okO24mDPZLTfdIV48XadMi0bJHlLpiYPwAJOyF75SRoyBo > hPv5+ougB0vwfp+7skJcLsYabnWejILyEDAw3ee3GXDlXJmM786k7/uqSHRh6FP3 > kaBb0IL7Bwkc/kbjlQ+bBQr/KPTyAqzK2LIBiJY3m4loD8W/cQSJLYMd8VesKnBG > UThrniH70ZPbq1GtSCAuLhufbWzTLbuMwfo9tQBT5vtpP07RCkCimTDcZfrRa6uI > yEVaeA/XEKeaYLyhZjfWDL71tIEhAUBGOcgv8XQdsWLZfrXVNCi43hhn27R6C6s= > =mSqQ > -----END PGP SIGNATURE----- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From roland.bless@kit.edu Thu Apr 4 08:59:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7CA21F8F00; Thu, 4 Apr 2013 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-xY8qzYp-55; Thu, 4 Apr 2013 08:59:20 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD221F8EED; Thu, 4 Apr 2013 08:59:18 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1UNmZC-0004eV-Oh; Thu, 04 Apr 2013 17:59:16 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1UNmZB-0008GM-1E; Thu, 04 Apr 2013 17:59:09 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id B2F77A8050C; Thu, 4 Apr 2013 17:59:08 +0200 (CEST) Message-ID: <515DA34C.6020405@kit.edu> Date: Thu, 04 Apr 2013 17:59:08 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Michael Richardson Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> <23965.1365087739@sandelman.ca> In-Reply-To: <23965.1365087739@sandelman.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1365091156.616213000 Cc: 6man , Ted Lemon , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:59:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 04.04.2013 17:02, Michael Richardson wrote: > I think that imadali-its-vinipv6 is the wrong idea. If it is > useful for a manufacturer to derive a subnet-ID from a VIN, that's > fine, but I think it's a private matter. Let's write a BCP on how > a manufacturer might do this in a way such that the the VIN <-> > subnet prefix mapping is neither reversable, nor is it > reproduceable. (I.e. I can't get the VIN from the subnet-ID, and I > also can't get the subnet-ID from the VIN) > > Only the manufacturer *might* know the mapping, and maybe we can > write the BCP such that the manufacturer can forget it too. The > manufacturer likely goes to get RIR space just like any other > Enterprise. Our initial proposal [1] was to use rightbits(SHA-2(VIN | OEM-specific-256bit Key), 40) to algorithmically generate the Global-ID of a ULA-Prefix. As long as the key is kept secret, it would not be reversable or derivable from the VIN. Using a global prefix from an RIR is certainly another viable alternative. [1] http://www.lara.prd.fr/_media/ipv6-its/2012-03-26-seis-kit-ietf83-its.pdf Regards, Roland -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFdo0YACgkQ1YyfLd659kfWvACgx5jchyyAQ1fR2hPVoMsD8dEp a4QAoLnEm1BhSR3piHX4nutLdBpNhRXK =2g2s -----END PGP SIGNATURE----- From joelja@bogus.com Thu Apr 4 09:01:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCEE21F93C5 for ; Thu, 4 Apr 2013 09:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4Bn9aP9evWN for ; Thu, 4 Apr 2013 09:01:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 044F421F93AA for ; Thu, 4 Apr 2013 09:01:10 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r34G19Mh096778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 4 Apr 2013 16:01:09 GMT (envelope-from joelja@bogus.com) Message-ID: <515DA3C0.90909@bogus.com> Date: Thu, 04 Apr 2013 09:01:04 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Alexandru Petrescu , ipv6@ietf.org Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <515C7E2F.2080709@dougbarton.us> <515D9955.6080508@gmail.com> In-Reply-To: <515D9955.6080508@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 04 Apr 2013 16:01:09 +0000 (UTC) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:01:11 -0000 On 4/4/13 8:16 AM, Alexandru Petrescu wrote: > Le 03/04/2013 21:08, Doug Barton a écrit : >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 04/03/2013 09:00 AM, Michael Richardson wrote: | So, I have a >> question: how much privacy is actually contained in the | VIN or >> indexed by the VIN? Given that it's printed on the windshield. | >> Yes, it contains model, year and manufacturer of the car, but all of >> | that information is also visible by looking at the vehicle. >> >> There's orders of magnitude different in having to walk up to the >> windshield of every car you're interested in vs. passively sniffing >> IP traffic to discover VINs of thousands of cars in a go. > > Automatic shooting (taking picture of) license plate is a common > practice in certain automatic law enforcement, and parking security. > yes, and as noted by me, that takes kind of a lot of resources to do at scale (like central london), and it typically has strong privacy protections on the resulting dataset. the second you build a social networking app that passively collects locally broadcast unique identifiers using mobile phone handsets, well you have a lot of data, really useful for all sorts of things. > The VIN being smaller than the plate may be just a matter of when higher > sensor resolutions become available. I would not be surprised to see > automated shooting of VIN in the future for various applications. sure > The VIN must remain visible. One of the privacy problems may lie in > that requirement per se. And, on the contrary, it could also be used to > securely produce a request of an IP service from the vehicle in line of > sight, when infrastructure is not available. vins like fingerprints are not secrets, if you want to use them as an authentication tool you need to be mindful of that limitation. >> And dare I mention the big brother aspect of setting up roadside >> monitors? > > That possibility may already be there. It may be that 802.11p/DSRC/WAVE > sends periodic beacons unsecured out of the car, which may contain MAC > addresses. (I just suppose). > >> And what about son-of-google-street-view? > > I suppose even the father-google-street-view may already have some > privacy concerns. Although it is obvious that the engineers went to > large efforts to anonymize faces and license plates, its application > still misses some points. I have seen a easily dateable picture of > StreetView with easily recognizable faces of law enforcement officer > and a person being fined. And pictures of intimate clothes out in the > air drying, invisible otherwise. I guess they collect these fun things > somewhere. > >> The privacy aspects of being able to reverse-map IP traffic to VINs >> are staggering. >> >> I remain unconvinced that there should be any special case in the >> protocol for this, as I've yet to see an argument as to why ULAs are >> not sufficient. I remain violently opposed to any protocol >> definition that supports VIN <> IP address mapping. > > Ok. > > Alex > >> >> Doug >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) >> >> iQEcBAEBCAAGBQJRXH4vAAoJEFzGhvEaGryEkvAIAL72fEzKUqpLEcvdyh177Vla >> dZov3A88iIMJuq6dE4xG7RzMSRG5ueFkelIB07jxo0TyXQmvvliS029RKeWlZed9 >> BhIMZwWw2AY2jQVnQTvT9pwZ+8KrY94s4q0YpVzdKsJKKhErvISKnzwn1qCtKFlv >> 7tsfSXcCq7E4WgcuQSxtUIyaTN/Psw27QVTrJ8PJTHlGTIzrkJrRIczjLJy0pHvv >> Ekq9Bi/n/w65CQYn1zNume/goW0eUDk9rVHf/XopD5ugnRHW1gn6fkDxjDKc9Jc9 >> I1QU4nHhP82NiRiqS9xzgXUpMjm/+RCSHYPvAKCcTGdACBDtXUhd5QU9w4gJ3YA= >> =EAHc -----END PGP SIGNATURE----- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From joelja@bogus.com Thu Apr 4 10:17:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D05121F9393 for ; Thu, 4 Apr 2013 10:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NdgOTLP9lRL for ; Thu, 4 Apr 2013 10:17:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D4BD921F8F22 for ; Thu, 4 Apr 2013 10:17:31 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r34HHUEe097662 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 4 Apr 2013 17:17:30 GMT (envelope-from joelja@bogus.com) Message-ID: <515DB5A5.1080400@bogus.com> Date: Thu, 04 Apr 2013 10:17:25 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Alexandru Petrescu , ipv6@ietf.org Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <515C7E2F.2080709@dougbarton.us> <515D9955.6080508@gmail.com> <515DA3C0.90909@bogus.com> In-Reply-To: <515DA3C0.90909@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 04 Apr 2013 17:17:30 +0000 (UTC) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:17:33 -0000 for people who are interested, and in the bay area... On 4/3/13 4:12 PM, Christie Dudley wrote: > I posted a while back about hacking privacy in the upcoming > DSRC/802.11p safety protocol they're talking about possibly mandating > for every car. A lot of people expressed interest, but I discouraged > people because we were in the old dojo and really cramped for space. > > Well, Alison Chaiken with Silicon Valley Automotive Open Source has > gone ahead and arranged a talk for next week where there's plenty of > space for everyone who's interested in discovering more about this. > Admission is free and there's also free food. So come join us. > > Tuesday, April 9, 2013 > 7:00 PM > > Mentor Graphics Building B > 46885 Bayside Parkway, Fremont, CA http://www.meetup.com/Silicon-Valley-Automotive-Open-Source/events/101945752/ On 4/4/13 9:01 AM, joel jaeggli wrote: > On 4/4/13 8:16 AM, Alexandru Petrescu wrote: >> Le 03/04/2013 21:08, Doug Barton a écrit : >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> On 04/03/2013 09:00 AM, Michael Richardson wrote: | So, I have a >>> question: how much privacy is actually contained in the | VIN or >>> indexed by the VIN? Given that it's printed on the windshield. | >>> Yes, it contains model, year and manufacturer of the car, but all of >>> | that information is also visible by looking at the vehicle. >>> >>> There's orders of magnitude different in having to walk up to the >>> windshield of every car you're interested in vs. passively sniffing >>> IP traffic to discover VINs of thousands of cars in a go. >> >> Automatic shooting (taking picture of) license plate is a common >> practice in certain automatic law enforcement, and parking security. >> > yes, and as noted by me, that takes kind of a lot of resources to do > at scale (like central london), and it typically has strong privacy > protections on the resulting dataset. the second you build a social > networking app that passively collects locally broadcast unique > identifiers using mobile phone handsets, well you have a lot of data, > really useful for all sorts of things. >> The VIN being smaller than the plate may be just a matter of when higher >> sensor resolutions become available. I would not be surprised to see >> automated shooting of VIN in the future for various applications. > sure >> The VIN must remain visible. One of the privacy problems may lie in >> that requirement per se. And, on the contrary, it could also be used to >> securely produce a request of an IP service from the vehicle in line of >> sight, when infrastructure is not available. > vins like fingerprints are not secrets, if you want to use them as an > authentication tool you need to be mindful of that limitation. >>> And dare I mention the big brother aspect of setting up roadside >>> monitors? >> >> That possibility may already be there. It may be that 802.11p/DSRC/WAVE >> sends periodic beacons unsecured out of the car, which may contain MAC >> addresses. (I just suppose). >> >>> And what about son-of-google-street-view? >> >> I suppose even the father-google-street-view may already have some >> privacy concerns. Although it is obvious that the engineers went to >> large efforts to anonymize faces and license plates, its application >> still misses some points. I have seen a easily dateable picture of >> StreetView with easily recognizable faces of law enforcement officer >> and a person being fined. And pictures of intimate clothes out in the >> air drying, invisible otherwise. I guess they collect these fun things >> somewhere. >> >>> The privacy aspects of being able to reverse-map IP traffic to VINs >>> are staggering. >>> >>> I remain unconvinced that there should be any special case in the >>> protocol for this, as I've yet to see an argument as to why ULAs are >>> not sufficient. I remain violently opposed to any protocol >>> definition that supports VIN <> IP address mapping. >> >> Ok. >> >> Alex >> >>> >>> Doug >>> >>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) >>> >>> iQEcBAEBCAAGBQJRXH4vAAoJEFzGhvEaGryEkvAIAL72fEzKUqpLEcvdyh177Vla >>> dZov3A88iIMJuq6dE4xG7RzMSRG5ueFkelIB07jxo0TyXQmvvliS029RKeWlZed9 >>> BhIMZwWw2AY2jQVnQTvT9pwZ+8KrY94s4q0YpVzdKsJKKhErvISKnzwn1qCtKFlv >>> 7tsfSXcCq7E4WgcuQSxtUIyaTN/Psw27QVTrJ8PJTHlGTIzrkJrRIczjLJy0pHvv >>> Ekq9Bi/n/w65CQYn1zNume/goW0eUDk9rVHf/XopD5ugnRHW1gn6fkDxjDKc9Jc9 >>> I1QU4nHhP82NiRiqS9xzgXUpMjm/+RCSHYPvAKCcTGdACBDtXUhd5QU9w4gJ3YA= >>> =EAHc -----END PGP SIGNATURE----- >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From alexandru.petrescu@gmail.com Thu Apr 4 10:19:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99621F86CB; Thu, 4 Apr 2013 10:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXUZLel0q+F7; Thu, 4 Apr 2013 10:19:18 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 689DC21F8D05; Thu, 4 Apr 2013 10:19:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r34HJBid002101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Apr 2013 19:19:12 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r34HJB78011200; Thu, 4 Apr 2013 19:19:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r34HJ2BZ001790; Thu, 4 Apr 2013 19:19:11 +0200 Message-ID: <515DB606.5070003@gmail.com> Date: Thu, 04 Apr 2013 19:19:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <021E64FECA7E5A4699562F4E6671648101E44F@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101E44F@XCH-PHX-503.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:19:19 -0000 Le 04/04/2013 03:18, Manfredi, Albert E a écrit : >> -----Original Message----- From: ipv6-bounces@ietf.org >> [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson > > >> If I can derive the VIN from the prefix, I agree that it helps >> identify the vehicle, but not really. If any of this stuff is >> going to be useful, there will already be a collision avoidance >> protocol that will tell each car (even when they are parked) where >> the other vehicles are, so that they can be avoided. >> >> If I can rederive the prefix from the VIN, then it seems we also >> have problems. >> >> What I'm saying is that I don't think that there are *new* privacy >> problems here. > > I would agree with that comment, but then again, I don't see any > compelling reason (nor any advantage) to use the VIN in the IPv6 > address anyway. So privacy concerns or no, I would reiterate my > suggestion that if the VIN is used, it be used as part of a DNS > name, rather than an integral part of the address. Some applications involving the use of VIN may have been discussed. One requirement may come from V2V communications when infrastructure is not available: how to know the IP address of the seen vehicle when DNS is unavailable. Other requirement of using parts of the VIN would be remote software update: extract the field of the VIN which represents Manufacturer ID, make an IPv6 multicast group of it, and send the update accordingly. These are just ideas having been floated in various contexts. VIN-to-IPv6-InterfaceIdentifier is just one little thing which could or not could not work. Alex > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From hannes@stressinduktion.org Thu Apr 4 10:51:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF9021F941D for ; Thu, 4 Apr 2013 10:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnLB8HxqpIdy for ; Thu, 4 Apr 2013 10:51:51 -0700 (PDT) Received: from order.stressinduktion.org (order.stressinduktion.org [87.106.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 175F421F8EDE for ; Thu, 4 Apr 2013 10:51:51 -0700 (PDT) Received: by order.stressinduktion.org (Postfix, from userid 500) id 6F8861A0CB24; Thu, 4 Apr 2013 19:51:50 +0200 (CEST) Date: Thu, 4 Apr 2013 19:51:50 +0200 From: Hannes Frederic Sowa To: ipv6@ietf.org Subject: link local address handling while changing hw address of interface Message-ID: <20130404175150.GC23056@order.stressinduktion.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:53:57 -0000 Hello! What is the proposed action if the hardware address of an interface is changed regarding link-local addresses while the interface is up? I see a few possibilities here but have not yet found an answer in the rfcs: a) generate a new link-local interface address in addition to the old one b) drop the old one and generate a new one c) don't change any addresses (this is e.g. current behavior in linux) I would be happy if you could give me some pointers. Thanks, Hannes From alexandru.petrescu@gmail.com Thu Apr 4 10:59:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9604421F93CC for ; Thu, 4 Apr 2013 10:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.217 X-Spam-Level: X-Spam-Status: No, score=-10.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtUwUjVcZQLc for ; Thu, 4 Apr 2013 10:59:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC821F8F33 for ; Thu, 4 Apr 2013 10:59:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r34Hx4am011960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Apr 2013 19:59:04 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r34Hx34N022358; Thu, 4 Apr 2013 19:59:04 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r34HwsSJ024426; Thu, 4 Apr 2013 19:59:03 +0200 Message-ID: <515DBF5E.2050809@gmail.com> Date: Thu, 04 Apr 2013 19:58:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <021E64FECA7E5A4699562F4E6671648101E304@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101E304@XCH-PHX-503.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:59:10 -0000 Le 03/04/2013 21:36, Manfredi, Albert E a écrit : >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >> Behalf Of Alexandru Petrescu > >> Yes, the ULA prefix (RFC 4193 section 3.2.2) generates a 48bit >> prefix randomly. That suggested algorithm is seeded by time, >> EUI-64 into a key, and then SHA-1. >> >>> Anyway.. the idea is that you randomize the prefix... >> >> Yes. We may need to say how. >> >> Just saying RNG may not be enough, I dont know. > > I really don't put much weight on this. It's just one suggestion. I > dare say, pick a decent PRNG, pick a seed out of the air, and for all > intents and purposes, you have your ULA prefix. I agree, this is feasible. > After all, this use of ULA is only for in-vehicle comms, and should > not transit through any car-Internet router. YEs and no. Within a vehicle, it's not sufficient to just use link-local addresses, because it is highly likely that at least two different subnets are present inside (roughly 'safety' and 'entertainment', but just roughly). So one needs addresses inside a vehicle with a scope larger than link. These may be ULAs, or not ULAs, yet they must be larger than link scope. Between vehicles - it may be that one vehicle needs to inform the nearby vehicle about the prefix(es) it holds inside, and vice-versa. If these prefixes are ULA, then this prefix exchange should work. This direct vehicle-to-vehicle communication may not need any car-to-Internet connection - it's a sort of 'peer-to-peer' communication. (WiFi adhoc mode of egress ifaces, or 802.11p - both may establish connections between vehicles without using infrastructure). About the straightedness of connectivity, this V2V acronym is generally understood by IP people by a number of degrees of variation: there is (1) direct vehicle-to-vehicle communication without infrastructure whatsoever, (2) vehicle-to-AP-to-vehicle communication (AP is a fixed router along the roadside, but disconnected from Internet), (3) vehicle-to-AP-to-Internet-to-AP-to-vehicle, (4) V-to-HA-to-HA-to-V and so on (HA is the Home Agent hosted by the vehicle manufacturer, not by the cellular operator). > Randomness is only a safety net, in case a ULA sneaks out of the > local router. YEs. > I don't think we should tie the VIN or any EUI-64 strictly to this > idea of using ULAs. I agree as well. VIN could be used in a Internet setting in a variety of ways. >> Also, that Network mobility doesnt prohibit neither suggests that >> the prefix of a moving network (MNP: Mobile Network Prefix) be >> exchanged between two distinct moving networks such as to establish >> routes between them (route exchange). > > Well, I have a question about this. I've seen mobility done in a > number of ways. Move individual interfaces, using the home agent > approach; move entire address blocks, where the routing protocol > keeps track of subnet location; or use a link layer that always ties > the moving subnet(s) to the same geographic location "back home," > making the job easier for the IP layer. > > Added to this, for a vehicle scenario, we may (probably will) also > need something along the lines of 802.11 ad-hoc networks, for those > tactical car-car and car-road comms. YEs 802.11 ad-hoc but between the egress interfaces of vehicles, not between the inside1 of vehicle1 and inside2 of vehicle2. With that distinction, it appears to me that IP routing should be performed between inside1 and outside of the car. This is ok, because a car Router interface may be Ethernet (ingress) and another may be WiFi (egress). > In principle, can't a combination of all of these schemes be used in > vehicles? For instance, if your IP service is the type that replaces > the OnStar scheme (used by GM in the US), a lot of that information > is not overly time constrained. And since OnStar is a 3G system, it > "knows" what each client's home network is. The OnStar system as I understand it is a good deployment success showing IP is possible in vehicles at a large scale. It is mostly the success of deployment of the cellular network and certain PHY encoding schemes. I compare it to eCall in Europe (which is regulated differently in different countries). But we look here at a much deeper penetration of IP than just one IP address per vehicle and a single interface. It is considered further that several IPv4 and IPv6 addresses _and_ subnets are inter connected inside a vehicle. Many of the typical actions (open window) move from pressing an electrical switch to tapping a circle drawned by PC on LCD screen. There is not one but several Ethernet cables inside. The vehicle has a large number of egress interfaces to the outside world. Just like with mobile phones, recent antenna designs of vehicle are increasingly complex: cellular on frequencies of different countries, GPS of different continents, WiFi at various freq ranges, 802.11p and more. One approach to manage IP mobility of these complex systems is the use of protocol Mobile IP which has extensions to consider all IP addresses inside a vehicle to move as a whole. Conceptually the Mobile IP approach is a 'tunnelling' approach (there's a tunnel between the MR and an anchor - the Home Agent), as opposed to route updates as may be seen with BGP updates. It is an IP-layer mobility protocol (as opposed to link-layer mobility used by e.g. cellular systems). It is a map-and-encap as opposed to rewrite. Other protocols which may be used to do mobility of groups of IP devices may be considered to be LISP and SHIM6. Mobile IP has advantages and inconvenients for vehicular communications. One of the inconvenients is that its perspective is not much that of V2V communications: can't just consider the other vehicle to be one vehicle's HA. On another hand, MIP could very well be used in a V2I setting. >> The random part of the ULA may be needed for inter-vehicle >> communications. I.e. use fd00:fef2:3214::/64 inside one vehicle, >> and fd00:fff2:3214::/64 in the other vehicle. Use no prefix on >> the ad-hoc link between the two egress interfaces of the mobile >> router (use their link-local addresses there). >> >> If those two prefixes were not random, then collision between >> prefixes may occur the moment the routes are exchanged between the >> vehicles. > > No, I would not contaminate the Internet deliberately this way. It > seems to me that each car should be assigned a /64 prefix which is > globally unique, for this sort of use. There is need of more than just one /64 in a vehicle, or otherwise DHCP must be used. There are several subnets in a vehicle and many devices are Ethernet-like. SLAAC can not work with a /65 and Ethernet devices. > Just like every household. There is a well sensed tendency to move towards deployment giving more than one /64 to a household - in France there this OVH and Nerim operators I believe giving shorter len than /64 to households. > I really don't see why this type of inter-car communications should > be thought of as any different from home nets. For one, homenets don't move or at least not as fast as cars. A homenet may change its attachment every year or so, whereas a car may change it every 10 minutes or so. Depends what kind of inter-car communications. Direct car-to-car without any assistance may not be a good candidate for Mobile IP protocol, nor for BGP route updates, nor for link layer communications. For Mobile IP perspective: it's hard for a vehcile's MR to consider every other vehicles' MR to be its HA. Typically a MR has a single HA. For BGP updates perspective: this could be discussed and should be analyzed at length. BGP is one and then there's OSPF RIP and MANET and RPL. Each has peculiarities (e.g. RPL may be designed low power links whereas V2V would be designed for high power links like .11p). For each of these one needs to give properconsideration of the IPv6 addressing architecture to be deployed in vehicles, and the subnet structure. > And again, the mobility aspect can be resolved in at least two > different ways that I believe to be in common use already. Yes, the mobility aspect of vehicles could be resolved in at least two different ways: link-layer mobility and route updates. Link layer mobility works with just one kind of link. But could be used to enhanced the overall mobility support of vehicle. Route updates: could work for small networks of vehicles, as long as one avoids to insert routes in the Internet. Alex > > Bert > > > From Ted.Lemon@nominum.com Thu Apr 4 11:01:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4242021F9615; Thu, 4 Apr 2013 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfS4xjN8QaNx; Thu, 4 Apr 2013 11:01:35 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E032E21F958A; Thu, 4 Apr 2013 11:01:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUV2//plFOh50TQsPR57ZERkDXuZRTC9i@postini.com; Thu, 04 Apr 2013 11:01:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8EDF5108080; Thu, 4 Apr 2013 11:01:34 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8844219005D; Thu, 4 Apr 2013 11:01:34 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 11:01:34 -0700 From: Ted Lemon To: "" Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMIRmAL55WRTfvUStGNkrMagsAZjFnGEAgAAbHwCAABEOgIABBfYAgAACrYA= Date: Thu, 4 Apr 2013 18:01:33 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775131DEA@mbx-01.win.nominum.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com><515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com><515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca><8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com><7858.1365038000@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> <301F74C7B05D4BA6A8258AFA491FD252@SRA4> In-Reply-To: <301F74C7B05D4BA6A8258AFA491FD252@SRA4> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:01:36 -0000 On Apr 4, 2013, at 1:51 PM, Richard Roy wrote: > Furthermore, anonymity concerns and the simultaneous morphing of all cont= ent > in these safety messages that could be used to infer behavior and violate > privacy are being addressed within the IEEE 1609.2 and ETSI TC ITS securi= ty > working groups (as well as in the SafetyPilot program in the US).=20 That's good to hear, although are you addressing the IP layer privacy issue= s, or just the link layer issues? It doesn't do us any good to have priva= cy-supporting link-layer addresses if we screw that up at the IP layer. In any case, I think it's worth making sure that however this problem gets = solved, we talk about it and describe how it is solved, even if how it is s= olved is "in this IEEE spec." From albert.e.manfredi@boeing.com Thu Apr 4 12:56:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3C821F9530; Thu, 4 Apr 2013 12:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FkeocUSuuFv; Thu, 4 Apr 2013 12:56:14 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFBC21F8BF8; Thu, 4 Apr 2013 12:56:14 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r34JuDdT026092; Thu, 4 Apr 2013 12:56:13 -0700 Received: from XCH-PHX-205.sw.nos.boeing.com (xch-phx-205.sw.nos.boeing.com [137.136.238.16]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r34JuCub026088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 4 Apr 2013 12:56:13 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.40]) by XCH-PHX-205.sw.nos.boeing.com ([169.254.5.133]) with mapi id 14.02.0328.011; Thu, 4 Apr 2013 12:56:12 -0700 From: "Manfredi, Albert E" To: Alexandru Petrescu Subject: RE: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMViAr5fycvyPPkuGym/ciC0oU5jGd5NA Date: Thu, 4 Apr 2013 19:56:12 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648101E633@XCH-PHX-503.sw.nos.boeing.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <021E64FECA7E5A4699562F4E6671648101E44F@XCH-PHX-503.sw.nos.boeing.com> <515DB606.5070003@gmail.com> In-Reply-To: <515DB606.5070003@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 19:56:15 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Some applications involving the use of VIN may have been discussed. >=20 > One requirement may come from V2V communications when infrastructure is > not available: how to know the IP address of the seen vehicle when DNS > is unavailable. If these comms are tactical, I would go to something more like 802.11 ad-ho= c network, and do the comms at layer 2. Alternatively, the vehicle can use = its assigned IPv6 /64 prefix (which need not be related to anything specifi= c like a VIN), and then use MANET. Seems built to order for MANET, no? > Other requirement of using parts of the VIN would be remote software > update: extract the field of the VIN which represents Manufacturer ID, > make an IPv6 multicast group of it, and send the update accordingly. For that, I would way prefer using the VIN as part of a DNS name, which is = then mapped to the IP address of the vehicle. This makes the problem more a= menable to flexible solutions, like allowing the IP address prefix to be ch= anged periodically, or allowing the vehicle ID to be associated in any numb= er of ways, other than just a VIN. By the way, this vehicle application of IPv6 is another example that makes = me kringe about the waste of even IPv6 address space, when we continue to d= iscourage the use of longer than 64-bit prefixes. Bert >=20 > These are just ideas having been floated in various contexts. >=20 > VIN-to-IPv6-InterfaceIdentifier is just one little thing which could or > not could not work. >=20 > Alex From albert.e.manfredi@boeing.com Thu Apr 4 13:22:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D746021F8C5D for ; Thu, 4 Apr 2013 13:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KDZnFmoVYpT for ; Thu, 4 Apr 2013 13:22:45 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1F721F8C16 for ; Thu, 4 Apr 2013 13:22:45 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r34KNG3J005225 for ; Thu, 4 Apr 2013 13:23:16 -0700 Received: from XCH-PHX-104.sw.nos.boeing.com (xch-phx-104.sw.nos.boeing.com [137.136.238.7]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r34KNFaU005214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 4 Apr 2013 13:23:16 -0700 Received: from XCH-BLV-509.nw.nos.boeing.com (137.136.239.139) by XCH-PHX-104.sw.nos.boeing.com (137.136.238.7) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 4 Apr 2013 13:22:43 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.40]) by XCH-BLV-509.nw.nos.boeing.com ([169.254.9.60]) with mapi id 14.02.0328.011; Thu, 4 Apr 2013 13:22:43 -0700 From: "Manfredi, Albert E" To: Alexandru Petrescu Subject: RE: I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMV4S/XzcrpBVwE61HWagdH48z5jGfUrQ Date: Thu, 4 Apr 2013 20:22:43 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648101E660@XCH-PHX-503.sw.nos.boeing.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <021E64FECA7E5A4699562F4E6671648101E304@XCH-PHX-503.sw.nos.boeing.com> <515DBF5E.2050809@gmail.com> In-Reply-To: <515DBF5E.2050809@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:22:46 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > For one, homenets don't move or at least not as fast as cars. A > homenet > may change its attachment every year or so, whereas a car may change it > every 10 minutes or so. Just as a side FYI, my homenet attachment IP changes every time I reboot th= e ADSL modem. So even this would not matter greatly, *if* the unique ID of = a car were a DNS entry, rather than hardcoded in the IP address in any way. Your point about having multiple IPv6 subnets (prefixes) inside the car is = a good one. But it can be solved like it is for home nets, as long as we do= n't run out of the shortened prefixes we're creating. Side note: Seems to me, with new applications like these IoT concepts (which are nothi= ng new, but promise way more addressable hosts than we might have expected = in the 1990s when IPv6 was invented), or vehicles, that allowing for someth= ing like 112-bit prefixes would be a good thing. You still get 16-bit IIDs,= way more than you are likely to need in a single in-car subnet, and you ca= n assign the individual car a 96-bit prefix. Giving each car the possibilit= y of 64K subnets, while wasting far less address space. I kringe at wanton waste. Bert From brian@innovationslab.net Thu Apr 4 13:40:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8815421F8D05 for ; Thu, 4 Apr 2013 13:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QpB6xqrDkrE for ; Thu, 4 Apr 2013 13:40:20 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1C32221F8D0D for ; Thu, 4 Apr 2013 13:40:20 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EE970880CC; Thu, 4 Apr 2013 13:40:19 -0700 (PDT) Received: from clemson.mtw.jhu.edu (unknown [128.220.159.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8E66A14000C; Thu, 4 Apr 2013 13:40:19 -0700 (PDT) Message-ID: <515DE537.8020308@innovationslab.net> Date: Thu, 04 Apr 2013 16:40:23 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: 6man WG , draft-ietf-6man-addr-select-opt@tools.ietf.org Subject: DHC Review of draft-ietf-6man-addr-select-opt References: <513E28D9.5050303@innovationslab.net> In-Reply-To: <513E28D9.5050303@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dhc-chairs@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:40:20 -0000 All, Given the involvement of DHCPv6 in this draft, I requested a review by the DHC WG. The following is the feedback received. I would like to see these issues resolved soon and encourage the authors to engage the DHC reviewers as needed. Regards, Brian ---- There was a request from an Int Area Directory to have "dhcp" review of the draft-ietf-6man-addr-select-opt document. Based on a review by Ted Lemon, Tomek Mrugalski, and Bernie Volz, the following issues were raised: 1. The text regarding the prefix in the OPTION_ADDRSEL_TABLE option needs to be improved - it currently allows someone to send all 16 octets rather than the "minimum" required - int(prefix-len+7)/8). Please see http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guideline, 5.3. Option with IPv6 prefix. 2. Section 3 should be dropped. This is a standard "other configuration option" and the client and server requirements for these are best left to RFC 3315. The current text has some mistakes and omissions if it were to duplicate what RFC 3315 already explains, and doing so risks inconsistencies, omissions, or conflicts which are best avoided. From Ted.Lemon@nominum.com Thu Apr 4 19:07:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32AC21F967A; Thu, 4 Apr 2013 19:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7s+EdJjxb7t; Thu, 4 Apr 2013 19:07:50 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 84CB721F9644; Thu, 4 Apr 2013 19:07:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUV4x9rv1hcOJY0jWBoVJ1ivTv/s8crRJ@postini.com; Thu, 04 Apr 2013 19:07:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E3B261B8E26; Thu, 4 Apr 2013 19:07:49 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D974919005D; Thu, 4 Apr 2013 19:07:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 19:07:49 -0700 From: Ted Lemon To: "" Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMIRmAL55WRTfvUStGNkrMagsAZjFnGEAgAAbHwCAABEOgIABBfYAgAACrYD//+jy0IAAnukA Date: Fri, 5 Apr 2013 02:07:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751326E3@mbx-01.win.nominum.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com><515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com><515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca><8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com><7858.1365038000@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> <301F74C7B05D4BA6A8258AFA491FD252@SRA4> <8D23D4052ABE7A4490E77B1A012B630775131DEA@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A14CDC31F8F914498B2CA18D8F280AE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 02:07:52 -0000 On Apr 4, 2013, at 7:44 PM, Richard Roy wrote: > [RR>] As I am sure you know, privacy is a cross-layer issue. Any layer t= hat > compromises privacy, compromises it for the user/ITS station. That said, > FNTP/WSMP replace the IP layer with a different albeit null) networking > protocol (essentially a simple port mapping protocol that has as few as 3 > bytes of protocol "overhead") designed to be small and efficient and > tailored to the simple single-hop broadcast over capacity constrained RF > channels. So that possibly makes sense internally to the car, although possibly not. = It doesn't make a lot of sense to me between cars, except perhaps in the = most restricted applications. When you talk about capacity constrained RF= channels, it sounds like you're talking about car-to-car traffic, or car-t= o-infrastructure traffic. But this constrained port mapping protocol soun= ds way too restrictive for either of those contexts. From rogerj@gmail.com Thu Apr 4 22:41:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DFE21F96C5; Thu, 4 Apr 2013 22:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nXWIjoDeo-b; Thu, 4 Apr 2013 22:41:19 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C121F96C4; Thu, 4 Apr 2013 22:41:19 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id ef5so3319709obb.41 for ; Thu, 04 Apr 2013 22:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7poPi5cN+cR2OkCP/0ihOxUv8r+9TCmZtl6KUKEQKRs=; b=q+uCnMqHQuklRcN3CW7u4451jRpuVAT96muwaKDZgrWlF2cVnz4Phgrlt7O/r6v8fX SU9v1ErNoB2NOGplk8SxkvXC9MI3+AM7DrR0XN7k33RsvCdRT98BgRgeIY7AyT4HktRX jZ/5kmVRXeAnaRu+NYAFUhAmTb/eGx3SawFtKI9vp6Ok6SfSi6iuOVJsXrMnXarL41w9 LB0FhkTBkRua5dtgboRJh0SWbXF1EzON7MRQ3EtqCuvv4b7dzXAIEp3IeXqDreSomuTj IacfrW2YxrE1Qoz+mN1ytTwHA90p3AIL68S6DO2ru2+C7Cf9BT0juYFX2aAl+wL+0/I0 r1+A== MIME-Version: 1.0 X-Received: by 10.182.119.72 with SMTP id ks8mr6986524obb.23.1365140479120; Thu, 04 Apr 2013 22:41:19 -0700 (PDT) Received: by 10.76.153.132 with HTTP; Thu, 4 Apr 2013 22:41:18 -0700 (PDT) In-Reply-To: <7858.1365038000@sandelman.ca> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> Date: Fri, 5 Apr 2013 07:41:18 +0200 Message-ID: Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Michael Richardson , 6man , "" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 05:41:20 -0000 On Thu, Apr 4, 2013 at 3:13 AM, Michael Richardson wrote: > If I can derive the VIN from the prefix, I agree that it helps identify > the vehicle, but not really. If any of this stuff is going to be > useful, there will already be a collision avoidance protocol that will > tell each car (even when they are parked) where the other vehicles are, > so that they can be avoided. > > If I can rederive the prefix from the VIN, then it seems we also have > problems. > > What I'm saying is that I don't > think that there are *new* > privacy problems here. it's nothing really new with VIN's and IPv6, it's more that we again was on the way of doing what has been done before and considered a not so good idea. Doing 1 to 1 match between a hardware address and an IPv6 address, and add meaning into the IPv6 address instead of treating it for what it is, just an address that should be generated somehow other than directly from a hardware address. That it also has a privacy side issue with it don't make it any better. Plenty of suggestion on how that can be used have been mention. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From brian.e.carpenter@gmail.com Thu Apr 4 23:53:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C2D21F84FD for ; Thu, 4 Apr 2013 23:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgVowKxeF6-G for ; Thu, 4 Apr 2013 23:53:40 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 90AFC21F84CD for ; Thu, 4 Apr 2013 23:53:35 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id f12so3347755wgh.34 for ; Thu, 04 Apr 2013 23:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n/uVsBM+R6iba1z4vB3NuEZXuzfqTEr2POuQ6RtMevw=; b=kZvFNXF0/SgI9txOgsm59uS/cqppywdMO9db2gU/CCtsd3AZZLiqF+FbbUQF8mZqet w9twaWsgIc49jWHS5lg/J9UfCAMT07vCDGrdaZE4G2GRyEeiO9TUFRLXmRRp2LDkJN9x sfJ3Q+P3KZMKC7NKfvlPNfHBWwo7FtCxSN70cs/tpwDyn6DjI8m+IVHA6c8U2gXCnB2T wlJZKOamh99UBaAob9pUpLPdAXIVOPVk/vdLchWp2hFcpXQbfW7TLqoD3+PTNQuJwLvY INgD7WQEffwNOrbYns2MRdP4xaDFCr/wFNm+6xhQKV7BFuSWUm1ygwurEPUnI7hVOzRz VtBg== X-Received: by 10.194.93.68 with SMTP id cs4mr14166590wjb.17.1365144814667; Thu, 04 Apr 2013 23:53:34 -0700 (PDT) Received: from [192.168.1.65] (host-84-13-238-122.opaltelecom.net. [84.13.238.122]) by mx.google.com with ESMTPS id bq19sm2020012wib.7.2013.04.04.23.53.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 23:53:33 -0700 (PDT) Message-ID: <515E74F7.9040504@gmail.com> Date: Fri, 05 Apr 2013 07:53:43 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Frederic Sowa Subject: Re: link local address handling while changing hw address of interface References: <20130404175150.GC23056@order.stressinduktion.org> In-Reply-To: <20130404175150.GC23056@order.stressinduktion.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 06:53:41 -0000 On 04/04/2013 18:51, Hannes Frederic Sowa wrote: > Hello! > > What is the proposed action if the hardware address of an interface is > changed regarding link-local addresses while the interface is up? I see > a few possibilities here but have not yet found an answer in the rfcs: > > a) generate a new link-local interface address in addition to the old one > b) drop the old one and generate a new one > c) don't change any addresses (this is e.g. current behavior in linux) > > I would be happy if you could give me some pointers. Does it matter? It seems that all three will work properly. c) will surely only apply until the interface is restarted; then you will get b) automatically. Brian From Francis.Dupont@fdupont.fr Fri Apr 5 02:30:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5142721F96FC for ; Fri, 5 Apr 2013 02:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6g4rZCNSNST for ; Fri, 5 Apr 2013 02:30:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 5464B21F96A0 for ; Fri, 5 Apr 2013 02:30:22 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r359UKX3072730; Fri, 5 Apr 2013 11:30:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201304050930.r359UKX3072730@givry.fdupont.fr> From: Francis Dupont To: Brian E Carpenter Subject: Re: link local address handling while changing hw address of interface In-reply-to: Your message of Fri, 05 Apr 2013 07:53:43 BST. <515E74F7.9040504@gmail.com> Date: Fri, 05 Apr 2013 11:30:20 +0200 Sender: Francis.Dupont@fdupont.fr Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 09:30:23 -0000 In your previous mail you wrote: > On 04/04/2013 18:51, Hannes Frederic Sowa wrote: > > Hello! > > > > What is the proposed action if the hardware address of an interface is > > changed regarding link-local addresses while the interface is up? I see > > a few possibilities here but have not yet found an answer in the rfcs: > > > > a) generate a new link-local interface address in addition to the old one > > b) drop the old one and generate a new one > > c) don't change any addresses (this is e.g. current behavior in linux) > > > > I would be happy if you could give me some pointers. > > Does it matter? It seems that all three will work properly. => I fully agree: RFCs are only about link-local interface ID generation and as soon as it works no detail really matter. > c) will surely only apply until the interface is restarted; then you > will get b) automatically. => note the "restart" is OS dependent. On OSs where the IID is generated just after board initialization (BSDs for instance) it gives c) which is IMHO a good solution (simple and, stable). Regards Francis.Dupont@fdupont.fr PS: in conclusion this is "implementation dependent" and there is no (not yet?) a good reason to change this. From andrewmcgr@gmail.com Fri Apr 5 06:54:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1540421F9456 for ; Fri, 5 Apr 2013 06:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc8c-VWdWDkk for ; Fri, 5 Apr 2013 06:53:58 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 98DAB21F973C for ; Fri, 5 Apr 2013 06:53:53 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w20so3816624lbh.32 for ; Fri, 05 Apr 2013 06:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=p34NUWrwJhYy6R4HI58kIVj5DxSGLJBgiXoDjXX+XN8=; b=rwna8OUxO67b3k88xFVHH0NBnnt6jXj0a8CyBVhYRLZYfqCGUw5JxT/QZsW8PH37Jf 311MyBM+DDmcDLCjbQ8JYAx1YNFn+7WpHD70FHxdmx5ZhhovhYvPYsdO/lXAHXBEacLv WoYvkrDY01jsezG5QCPf6MPEJ6zV4fSg+dq9zKfkF9hBuzMDvztCDZ0U7Jwvnphm36u+ 9xz2r6QxnBEXpqd8Lhbq7svag5Hh7yNabC6pvFSisiLjgq0lBEH0yyLv6K83mAeyNBws UnN/xPeGkBIDVP7JvkyS4QUjfIbuXoS1xx98VBxAUBQ5b/Iv205jT60d+ngROFL1sRI7 KaTw== MIME-Version: 1.0 X-Received: by 10.112.133.137 with SMTP id pc9mr6077945lbb.74.1365170029256; Fri, 05 Apr 2013 06:53:49 -0700 (PDT) Received: by 10.112.8.5 with HTTP; Fri, 5 Apr 2013 06:53:48 -0700 (PDT) Received: by 10.112.8.5 with HTTP; Fri, 5 Apr 2013 06:53:48 -0700 (PDT) In-Reply-To: <20130404175150.GC23056@order.stressinduktion.org> References: <20130404175150.GC23056@order.stressinduktion.org> Date: Sat, 6 Apr 2013 00:53:48 +1100 Message-ID: Subject: Re: link local address handling while changing hw address of interface From: Andrew McGregor To: Hannes Frederic Sowa Content-Type: multipart/alternative; boundary=047d7b3439a4a6e5e004d99d6a71 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 13:54:01 -0000 --047d7b3439a4a6e5e004d99d6a71 Content-Type: text/plain; charset=ISO-8859-1 B) is usually correct, although this depends on the semantics of the lower layer in question. If it is Ethernet, by changing the MAC address, you have made a new interface and so the old address end point has gone away. It is usually best to drop the link and restart layer 2 at that point, as any switch you are connected to will flush the necessary tables at that point, giving the best chance of being left in a working state. Deprecating the link local is therefore pointless, and the Linux behaviour is simply wrong. Andrew. On 5 Apr 2013 04:54, "Hannes Frederic Sowa" wrote: > Hello! > > What is the proposed action if the hardware address of an interface is > changed regarding link-local addresses while the interface is up? I see > a few possibilities here but have not yet found an answer in the rfcs: > > a) generate a new link-local interface address in addition to the old one > b) drop the old one and generate a new one > c) don't change any addresses (this is e.g. current behavior in linux) > > I would be happy if you could give me some pointers. > > Thanks, > > Hannes > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b3439a4a6e5e004d99d6a71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

B) is usually correct, although this depends on the semantic= s of the lower layer in question. If it is Ethernet, by changing the MAC ad= dress, you have made a new interface and so the old address end point has g= one away. It is usually best to drop the link and restart layer 2 at that p= oint, as any switch you are connected to will flush the necessary tables at= that point, giving the best chance of being left in a working state. Depre= cating the link local is therefore pointless, and the Linux behaviour is si= mply wrong.

Andrew.

On 5 Apr 2013 04:54, "Hannes Frederic Sowa&= quot; <hannes@stressindukt= ion.org> wrote:
Hello!

What is the proposed action if the hardware address of an interface is
changed regarding link-local addresses while the interface is up? I see
a few possibilities here but have not yet found an answer in the rfcs:

a) generate a new link-local interface address in addition to the old one b) drop the old one and generate a new one
c) don't change any addresses (this is e.g. current behavior in linux)<= br>
I would be happy if you could give me some pointers.

Thanks,

=A0 Hannes

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--047d7b3439a4a6e5e004d99d6a71-- From brian.e.carpenter@gmail.com Fri Apr 5 07:20:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1921F97AD for ; Fri, 5 Apr 2013 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.168 X-Spam-Level: X-Spam-Status: No, score=-101.168 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU-S8Xv-1AWv for ; Fri, 5 Apr 2013 07:20:10 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id EA00821F97AC for ; Fri, 5 Apr 2013 07:20:09 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so640596wib.8 for ; Fri, 05 Apr 2013 07:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/jqNpo/M04rwnXzJyasiCc2lSG5qMu011YNNqWVU7Wk=; b=RmR1Ch5dQoixN3als7wBNaBfrnmOtN3uqQiaoEvn3PeQbG7Q2BDgvAZ+8rN37tqg4z KMhKWU21KCG2g/a6wd/Pqjed/AZICPCazvsAcf4OQOtV3E6PlvIh8IysYOOxdzS7KZkP MALw6oFRYe09wm5793YWVqGn9rGh4q+fBLPpRF0ENFQgq9MHkOv77c9n6QolQvISFv1g ceGQ0Iw9KZzehtQZyr73Z4AEcXaNcu0axIEz7LParO1Ixmj23fLH7tevLd8OaTvZy1US /jbn+qhMMgLP+C1HElanTqEVOVPhPR4geDaQhU6RasosbN/lkN3of1N7wuvJR1NOuyXO YNnw== X-Received: by 10.194.222.3 with SMTP id qi3mr16908425wjc.28.1365171605056; Fri, 05 Apr 2013 07:20:05 -0700 (PDT) Received: from [192.168.1.65] (host-84-13-238-122.opaltelecom.net. [84.13.238.122]) by mx.google.com with ESMTPS id k5sm4556081wiy.5.2013.04.05.07.20.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 07:20:04 -0700 (PDT) Message-ID: <515EDD9E.1060406@gmail.com> Date: Fri, 05 Apr 2013 15:20:14 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew McGregor Subject: Re: link local address handling while changing hw address of interface References: <20130404175150.GC23056@order.stressinduktion.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 14:20:11 -0000 On 05/04/2013 14:53, Andrew McGregor wrote: > B) is usually correct, although this depends on the semantics of the lower > layer in question. If it is Ethernet, by changing the MAC address, you have > made a new interface and so the old address end point has gone away. At layer 2, yes, but you haven't done anything at layer 3, and NUD/ND will pick up the new layer3:layer2 relationship. > It is > usually best to drop the link and restart layer 2 at that point, as any > switch you are connected to will flush the necessary tables at that point, A layer 2 switch will do its thing, but that doesn't affect layer 3. > giving the best chance of being left in a working state. Deprecating the > link local is therefore pointless, and the Linux behaviour is simply wrong. It's just a bit lazy, as far as I can see. Brian > > Andrew. > On 5 Apr 2013 04:54, "Hannes Frederic Sowa" > wrote: > >> Hello! >> >> What is the proposed action if the hardware address of an interface is >> changed regarding link-local addresses while the interface is up? I see >> a few possibilities here but have not yet found an answer in the rfcs: >> >> a) generate a new link-local interface address in addition to the old one >> b) drop the old one and generate a new one >> c) don't change any addresses (this is e.g. current behavior in linux) >> >> I would be happy if you could give me some pointers. >> >> Thanks, >> >> Hannes >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From huitema@microsoft.com Fri Apr 5 08:36:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46021F9831 for ; Fri, 5 Apr 2013 08:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zybKozGSGyno for ; Fri, 5 Apr 2013 08:36:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5437521F982D for ; Fri, 5 Apr 2013 08:36:00 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.204) by BY2FFO11HUB011.protection.gbl (10.1.14.82) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 5 Apr 2013 15:35:52 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 5 Apr 2013 15:35:52 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.149]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 5 Apr 2013 15:35:43 +0000 From: Christian Huitema To: Brian E Carpenter , Andrew McGregor Subject: RE: link local address handling while changing hw address of interface Thread-Topic: link local address handling while changing hw address of interface Thread-Index: AQHOMV1zbNbnWLlkoE+wY6EnvMThXJjHp0MAgAAHYgCAABPgkA== Date: Fri, 5 Apr 2013 15:35:43 +0000 Message-ID: References: <20130404175150.GC23056@order.stressinduktion.org> <515EDD9E.1060406@gmail.com> In-Reply-To: <515EDD9E.1060406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(47976001)(79102001)(65816001)(55846006)(46102001)(31966008)(33656001)(50986001)(44976002)(76482001)(66066001)(81342001)(23756002)(63696002)(59766001)(54316002)(4396001)(81542001)(69226001)(77982001)(56776001)(56816002)(51856001)(47736001)(74662001)(80022001)(50466001)(16406001)(47446002)(20776003)(54356001)(49866001)(47776003)(53806001)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB011; H:TK5EX14MLTC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08076ABC99 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:36:01 -0000 > At layer 2, yes, but you haven't done anything at layer 3, and NUD/ND wil= l pick up the new layer3:layer2 relationship. There is also a privacy angle to this. Suppose that a visitor to a caf=E9 c= hanges their MAC address in order to avoid tracking. Keeping the same IP ad= dresses would somewhat defeat the purpose. Of course, there is always a way= to use "ipconfig renew" or some equivalent command, but you have a race co= ndition between "starting to use the new MAC" and "removing the old address= ." The only way to address that condition is to make MAC change and address= renewal an atomic operation. -- Christian Huitema From sofiane.imadali.ietf@gmail.com Fri Apr 5 08:45:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB6621F97C3; Fri, 5 Apr 2013 08:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiB0lzLpkoMe; Fri, 5 Apr 2013 08:45:55 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3921F97BF; Fri, 5 Apr 2013 08:45:54 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so3553088lab.8 for ; Fri, 05 Apr 2013 08:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=3PSWY+Qo05SCm1h4gZTefwqZxxkGb0q9nDxivpAxzP0=; b=C03p3OZcpjcAR7Wo1cTs+1h4XJwq7v81xvT8aYscpHm2840MrAlJuYCClQRsVK/xFs w92ovZ2r7EiBd5nPZtHo+Qdch+kYctScAA28LUrn5Avlc2ScJBsX5n9fGECNUUDL9m5D L47WQ+jYrUBjUYaMVrxochJl5jeyXc0RFS84pOI6vhqSb4wxy5jPNWhW6y21NteiN3yN BfP5Ljz2ltecX1J6uIhrtMuvalxj6PEHhZZmFtyJVUuTimRoKHkFoLgj5SqC8BIOkTDU /6K9Am5/Md+qiKkWYynXGCXwBkc6Eec/wEs7CSuSM1+/rsx24sem6XYDeuXS8mqGV2Oh JoIw== MIME-Version: 1.0 X-Received: by 10.152.20.193 with SMTP id p1mr518087lae.33.1365176753619; Fri, 05 Apr 2013 08:45:53 -0700 (PDT) Received: by 10.152.127.6 with HTTP; Fri, 5 Apr 2013 08:45:53 -0700 (PDT) In-Reply-To: References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> Date: Fri, 5 Apr 2013 17:45:53 +0200 Message-ID: Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt From: sofiane Imadali To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:45:56 -0000 Hi, On Fri, Apr 5, 2013 at 7:41 AM, Roger J=F8rgensen wrote: > On Thu, Apr 4, 2013 at 3:13 AM, Michael Richardson > wrote: > > >> If I can derive the VIN from the prefix, I agree that it helps identify >> the vehicle, but not really. If any of this stuff is going to be >> useful, there will already be a collision avoidance protocol that will >> tell each car (even when they are parked) where the other vehicles are, >> so that they can be avoided. >> >> If I can rederive the prefix from the VIN, then it seems we also have >> problems. >> >> What I'm saying is that I don't >> think that there are *new* >> privacy problems here. > > it's nothing really new with VIN's and IPv6, it's more that we again > was on the way of doing what has been done before and considered a not > so good idea. Doing 1 to 1 match between a hardware address and an > IPv6 address, and add meaning into the IPv6 address instead of > treating it for what it is, just an address that should be generated > somehow other than directly from a hardware address. > *Concerning the Interface ID part* I guess you're referring to the EUI-64 (MAC) -> IPv6 address. While that mapping (L2->L3 to form a L3 address) is clearly wrong (tying one *interface* identifier to the whole *prefix* with no notion of the *endpoint ID*, please have a look at Saltzer and Soch discussions about naming and addressing and the comments of John day among others), you could consider the IID generated from the VIN as a *Site Identifier*. The fact that it is similar and fits in the same IID part of the IPv6 address does not mean they map the same way. Our mapping could be used with more than one prefix as it does not relate to one interface. In a multi-homing scenario (3GPP + 11p) this could be useful. > That it also has a privacy side issue with it don't make it any > better. Plenty of suggestion on how that can be used have been > mention. > > *Concerning the prefix generation part* The privacy concerns are tied to the address scope used with your ID (the ID being the information you don't want to give). You can have a look at : http://tools.ietf.org/html/draft-brim-mobility-and-privacy-01 for more information. - With the ULA scope (*local* with a border router *to be defined*), the VIN-based ULA does not change the privacy concerns of RFC 4193 if defined internally, meaning that the Mobile Router is a border router. This is *exacltly* what our draft says. - When trying to define a larger scope, our draft says it is possible in the exact same way that RFC 4193 does: by exchanging the routes among the participants. Meaning, two peers with two ULA prefixes could exchange the routes and start communicating. Policy could be installed in order not to allow such exchanges to occur between random unknown vehicles. In our testing, we assume a closed loop under the control of one operator. - The case where global communications based on such prefixes traverse the infrastructure *are not defined in our draft*. Again, our draft has the same RFC 4193 security concerns but addresses the collisions problems related to the random-generation method of the prefix in a vehicular only context and assures the generation of a collision-free Provider-Independent addressing space. The argument that *ties the privacy to the ID* and *not to the scope of the addresses (actual definition of provacy)* could be addressed by one-way hashing a part of the VIN. Using this approach results in a randomization of certain parts (or all) of the VIN before mapping into IPv6 addresses. *We'll obviously lose the collision-free characteristic of this addressing space which can be guaranteed only by the use of bijective conversion methods*. The modelisation of the tussle between uniqueness requirements and privacy concerns (dilemma) by the use of VIN addressing is an ongoing work. Sofiane From alexandru.petrescu@gmail.com Fri Apr 5 08:55:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6727E21F981C for ; Fri, 5 Apr 2013 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLHwOIu73BpE for ; Fri, 5 Apr 2013 08:55:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 691D221F97AE for ; Fri, 5 Apr 2013 08:55:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r35FtWRF026752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Apr 2013 17:55:32 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r35FtV3a012445; Fri, 5 Apr 2013 17:55:31 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r35FtU4v028805; Fri, 5 Apr 2013 17:55:31 +0200 Message-ID: <515EF3F2.7000608@gmail.com> Date: Fri, 05 Apr 2013 17:55:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <021E64FECA7E5A4699562F4E6671648101E304@XCH-PHX-503.sw.nos.boeing.com> <515DBF5E.2050809@gmail.com> <021E64FECA7E5A4699562F4E6671648101E660@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101E660@XCH-PHX-503.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:55:37 -0000 Le 04/04/2013 22:22, Manfredi, Albert E a écrit : >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] > >> For one, homenets don't move or at least not as fast as cars. A >> homenet may change its attachment every year or so, whereas a car >> may change it every 10 minutes or so. > > Just as a side FYI, my homenet attachment IP changes every time I > reboot the ADSL modem. So even this would not matter greatly, *if* > the unique ID of a car were a DNS entry, rather than hardcoded in the > IP address in any way. When a homenet boots up in may need to use a Network Access Identifier (NAI) or a MAC address maybe to request the same IP address from the provider. With vehicles, this would mean to make the VIN (Vehicle Identification Number) to be that NAI - a conversion from VIN to NAI like @example.com. Whereas in a homenet it may be appropriate that a DNS Server be present, it may be less likely that a DNS Server is present in a vehicle. I haven't seen one, but one may put one DNS Server in a vehicle. Whereas the friendly applications are sensitive to the advice to _not_ hardcode the IP address of the Server, the preliminary yet futuristic in-vehicle applications often hardcode the IP address of the Server. And that for a good reason: it may be that the DNS is not reachable. When migrating the large number of applications in a vehicle from IPv4 to IPv6 one already faces first very simple problems like what addresses to put there, or is the IPv6 stack available for that small CPU. The advice to _always_ use DNS is just an additional requirement on top of others. A DNS in a vehicle may also put significant unknowns with respect to the DNS64 deployed by the cellular operator. > Your point about having multiple IPv6 subnets (prefixes) inside the > car is a good one. But it can be solved like it is for home nets, as > long as we don't run out of the shortened prefixes we're creating. I agree. Some argument says that there may be little if at all risk of running out of these shortened prefixes. But other arguments suggest we'd better lengthen the prefix length instead of shortening it. > Side note: > > Seems to me, with new applications like these IoT concepts (which are > nothing new, but promise way more addressable hosts than we might > have expected in the 1990s when IPv6 was invented), or vehicles, that > allowing for something like 112-bit prefixes would be a good thing. I think so too. Prefix of length 112bit could be made to to work with SLAAC and Ethernet. 2^64 hosts on a single IPv6 subnet will probably never be supported by any single link layer. Also, the IoT and its keen M2M concepts often consider that they're very small and less powerful machines in terms of CPU, yet often with more than one IP interfaces (i.e. they're dumb Routers). These devices need small software implementations of protocol. Yet for the simplest tasks - get an IP address, a delegated prefix, a default route - the IPv6 landscape requires such a device to use both ND and DHCP. This is a disconnect. The results look strange if looked at from IETF perspective. For example, a small 'mobile IPv6 hotspot' deployed on cellular does some things which IETF documents dont ack. I wonder whether homenet people consider that the prefix to be delivered to a homenet could be longer than /64 (i.e. /65 or /66). > You still get 16-bit IIDs, way more than you are likely to need in a > single in-car subnet, and you can assign the individual car a 96-bit > prefix. Giving each car the possibility of 64K subnets, while > wasting far less address space. Makes sense to me. > I kringe at wanton waste. Yes, seems as intentional waste. Alex > > Bert > > > From markzzzsmith@yahoo.com.au Fri Apr 5 14:57:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A991021F98A1 for ; Fri, 5 Apr 2013 14:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeRgfyL+eUKD for ; Fri, 5 Apr 2013 14:57:34 -0700 (PDT) Received: from nm26.bullet.mail.bf1.yahoo.com (nm26.bullet.mail.bf1.yahoo.com [98.139.212.185]) by ietfa.amsl.com (Postfix) with ESMTP id B8A7D21F98C4 for ; Fri, 5 Apr 2013 14:57:34 -0700 (PDT) Received: from [98.139.212.144] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 05 Apr 2013 21:57:34 -0000 Received: from [98.139.212.210] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 05 Apr 2013 21:57:33 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 05 Apr 2013 21:57:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 821221.74068.bm@omp1019.mail.bf1.yahoo.com Received: (qmail 93300 invoked by uid 60001); 5 Apr 2013 21:57:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1365199053; bh=uTh7iJcCNLvLlDaqf7EsjwFnt2DtBlndkB9IeNSc/vw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fBlDgkCcNSlFn6vmTEiy0jQx2Oe1TfZCP84w7WtMB/BkMCPCnXCAACMRzOR3gFIGGDzmZwtlmVluy+H+EedG5AcDWVtbNEMTfskDBh++qZ5UJp8ZbVQ8dvKgjBaSUsvZc/7lxq9CPtR5WF7qywwJQ7Lcwj347epSqQZA51LsZgA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xYabHJf/1NjetdeuTKDuTxhYMtng4BQZGOw2YTx0sXodkS27Dc9LicuIR5h5qCxqlcmx2DYpSKF4y/kaLFDy5cacgwGQO299ZOTOVy53Nfs8XiXWp0nPadwnrJ8qTLv8E1zP8iWFqePSM2arHXGd8sWFhuU4j+lAZzyjtb03Mus=; X-YMail-OSG: __QYfZwVM1kVSJFGMCgk8ViBUskuQeveVlvkTpg40jJ6.go HrtX0KADTb1tcCpt6sVGz Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Fri, 05 Apr 2013 14:57:33 PDT X-Rocket-MIMEInfo: 002.001, CgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAbWljcm9zb2Z0LmNvbT4KPlRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPjsgQW5kcmV3IE1jR3JlZ29yIDxhbmRyZXdtY2dyQGdtYWlsLmNvbT4gCj5DYzogImlwdjZAaWV0Zi5vcmciIDxpcHY2QGlldGYub3JnPiAKPlNlbnQ6IFNhdHVyZGF5LCA2IEFwcmlsIDIwMTMgMjozNSBBTQo.U3ViamVjdDogUkU6IGxpbmsgbG9jYWwgYWRkcmVzcyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <20130404175150.GC23056@order.stressinduktion.org> <515EDD9E.1060406@gmail.com> Message-ID: <1365199053.86070.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Fri, 5 Apr 2013 14:57:33 -0700 (PDT) From: Mark Smith Subject: Re: link local address handling while changing hw address of interface To: Christian Huitema , Brian E Carpenter , Andrew McGregor In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 21:57:35 -0000 =0A=0A=0A>________________________________=0A> From: Christian Huitema =0A>To: Brian E Carpenter ;= Andrew McGregor =0A>Cc: "ipv6@ietf.org" =0A>Sent: Saturday, 6 April 2013 2:35 AM=0A>Subject: RE: link local ad= dress handling while changing hw address of interface=0A> =0A>> At layer 2,= yes, but you haven't done anything at layer 3, and NUD/ND will pick up the= new layer3:layer2 relationship.=0A>=0A>There is also a privacy angle to th= is. Suppose that a visitor to a caf=E9 changes their MAC address in order t= o avoid tracking. Keeping the same IP addresses would somewhat defeat the p= urpose. Of course, there is always a way to use "ipconfig renew" or some eq= uivalent command, but you have a race condition between "starting to use th= e new MAC" and "removing the old address." The only way to address that con= dition is to make MAC change and address renewal an atomic operation.=0A>= =0A>=0A>Some of the modern wired network cards can support multiple unicast= destination addresses, mainly to support virtualisation if I understand co= rrectly, although I'm not sure about any 802.11 cards. An interesting idea = would be to utilise this capability to cover a transition period between an= old MAC address to a new one for privacy reasons. Alternatively most, if n= ot all NICs could be put into promiscuous mode during this transition perio= d to support receiving traffic for the old as well as new MAC address.=0A>= =0A>Given the recent use of Wifi MAC addresses to supposedly uniquely track= visitors to a store, and the far worse than expected level of MAC address = global uniqueness that HD Moore discovered, I'd be inclined to start lookin= g at periodically changing my MAC address in public arenas.=0A>=0A>=0A>Rega= rds,=0A>Mark.=0A> From Francis.Dupont@fdupont.fr Sun Apr 7 05:21:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314C821F8EC1 for ; Sun, 7 Apr 2013 05:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66PU088UfRsQ for ; Sun, 7 Apr 2013 05:21:17 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 830D221F8DD6 for ; Sun, 7 Apr 2013 05:21:17 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r37CLF5L056989; Sun, 7 Apr 2013 14:21:15 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201304071221.r37CLF5L056989@givry.fdupont.fr> From: Francis Dupont To: Andrew McGregor Subject: Re: link local address handling while changing hw address of interface In-reply-to: Your message of Sat, 06 Apr 2013 00:53:48 +1100. Date: Sun, 07 Apr 2013 14:21:15 +0200 Sender: Francis.Dupont@fdupont.fr Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:21:18 -0000 In your previous mail you wrote: > B) is usually correct, although this depends on the semantics of the lower > layer in question. If it is Ethernet, by changing the MAC address, you have > made a new interface and so the old address end point has gone away. It is > usually best to drop the link and restart layer 2 at that point, as any > switch you are connected to will flush the necessary tables at that point, > giving the best chance of being left in a working state. Deprecating the > link local is therefore pointless, and the Linux behaviour is simply wrong. => I deeply disagree: you assume a binding between layers 2 and 3, in particular between addresses, which does *not* exist. There is no issue to use any legal link-local address on a particular Ethernet device, and this is fully independent of the MAC address. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sun Apr 7 05:25:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB8921F8EE1 for ; Sun, 7 Apr 2013 05:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY3DPIIR8n1W for ; Sun, 7 Apr 2013 05:25:53 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4221F8EFC for ; Sun, 7 Apr 2013 05:25:53 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r37CPqa0057246; Sun, 7 Apr 2013 14:25:52 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201304071225.r37CPqa0057246@givry.fdupont.fr> From: Francis Dupont To: Christian Huitema Subject: Re: link local address handling while changing hw address of interface In-reply-to: Your message of Fri, 05 Apr 2013 15:35:43 -0000. Date: Sun, 07 Apr 2013 14:25:52 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:25:54 -0000 In your previous mail you wrote: > The only way to address that condition is to make MAC change and address > renewal an atomic operation. => in fact it is not required to be really atomic, only to seem to be atomic for an external observer (i.e., it is enough to shutdown the NIC during the operation). Regards Francis.Dupont@fdupont.fr From joelja@bogus.com Sun Apr 7 08:08:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DAD21F8EA5; Sun, 7 Apr 2013 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO48b63zmSdk; Sun, 7 Apr 2013 08:08:10 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 297A021F8E7D; Sun, 7 Apr 2013 08:08:10 -0700 (PDT) Received: from joels-MacBook-Air.local (23-24-206-43-static.hfc.comcastbusiness.net [23.24.206.43]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r37F84tY037599 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 7 Apr 2013 15:08:05 GMT (envelope-from joelja@bogus.com) Message-ID: <51618BCC.7070800@bogus.com> Date: Sun, 07 Apr 2013 08:07:56 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Ted Lemon , "" Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com><515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com><515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca><8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com><7858.1365038000@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> <301F74C7B05D4BA6A8258AFA491FD252@SRA4> <8D23D4052ABE7A4490E77B1A012B630775131DEA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751326E3@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751326E3@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 07 Apr 2013 15:08:08 +0000 (UTC) Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 15:08:11 -0000 On 4/4/13 7:07 PM, Ted Lemon wrote: > On Apr 4, 2013, at 7:44 PM, Richard Roy wrote: >> [RR>] As I am sure you know, privacy is a cross-layer issue. Any layer that >> compromises privacy, compromises it for the user/ITS station. That said, >> FNTP/WSMP replace the IP layer with a different albeit null) networking >> protocol (essentially a simple port mapping protocol that has as few as 3 >> bytes of protocol "overhead") designed to be small and efficient and >> tailored to the simple single-hop broadcast over capacity constrained RF >> channels. > So that possibly makes sense internally to the car, although possibly not. It doesn't make a lot of sense to me between cars, except perhaps in the most restricted applications. When you talk about capacity constrained RF channels, it sounds like you're talking about car-to-car traffic, or car-to-infrastructure traffic. But this constrained port mapping protocol sounds way too restrictive for either of those contexts. neither 802.11p or generic wifi are particularly capacity constrained. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From Ted.Lemon@nominum.com Sun Apr 7 08:24:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571F821F84E2; Sun, 7 Apr 2013 08:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze9lAdZyqATf; Sun, 7 Apr 2013 08:24:10 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6121F84D9; Sun, 7 Apr 2013 08:24:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUWGPki29kKSdRUEKZ+IKTAatXPF4h9oM@postini.com; Sun, 07 Apr 2013 08:24:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2A7D11B88A2; Sun, 7 Apr 2013 08:24:02 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 195FD19005D; Sun, 7 Apr 2013 08:24:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 08:24:02 -0700 From: Ted Lemon To: joel jaeggli Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Topic: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt Thread-Index: AQHOMIRmAL55WRTfvUStGNkrMagsAZjFnGEAgAAbHwCAABEOgIABBfYAgAACrYD//+jy0IAAnukAgAP+ogCAAAR+gA== Date: Sun, 7 Apr 2013 15:24:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775136E12@mbx-01.win.nominum.com> References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com><515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com><515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca><8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com><7858.1365038000@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130BFC@mbx-01.win.nominum.com> <301F74C7B05D4BA6A8258AFA491FD252@SRA4> <8D23D4052ABE7A4490E77B1A012B630775131DEA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751326E3@mbx-01.win.nominum.com> <51618BCC.7070800@bogus.com> In-Reply-To: <51618BCC.7070800@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <67AF95556329314BB3EACB61DAA7870C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 15:24:11 -0000 On Apr 7, 2013, at 11:07 AM, joel jaeggli wrote: >> So that possibly makes sense internally to the car, although possibly no= t. It doesn't make a lot of sense to me between cars, except perhaps in t= he most restricted applications. When you talk about capacity constrained= RF channels, it sounds like you're talking about car-to-car traffic, or ca= r-to-infrastructure traffic. But this constrained port mapping protocol s= ounds way too restrictive for either of those contexts. > neither 802.11p or generic wifi are particularly capacity constrained. Right, I have subsequently learned that in fact there is work being done to= use wireless inside the car to save on wiring. This probably still has p= rivacy implications, since the RF shielding on the car is likely not good e= nough to completely prevent snooping, but if the identifiers being used are= this constrained, it may not be a significant issue. From andrewmcgr@gmail.com Sun Apr 7 16:13:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F9421F8FA4 for ; Sun, 7 Apr 2013 16:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO+GdbiOzUOo for ; Sun, 7 Apr 2013 16:13:30 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 057A721F8F9D for ; Sun, 7 Apr 2013 16:13:29 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id el20so328714lab.23 for ; Sun, 07 Apr 2013 16:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JXgYQSXXDQ3+NUa1gpFVYXkRyneUMl6qAmILMiMSKo0=; b=ILHS5j6pkt/E6fCvpgOfHIqY9VBI0gwx8nUQ9ZTmb0TonBzGJ++IwRvKVohHqEDFpQ WjXiaSaUtz7324HYcqX7vWe/k06uD/BEi0oW/TvwFmRz1NZxFNadmm5Q2hbq2eis9dpj 6+8c73+YqSm2dZUOhoXhtP1CDNQMPsVcxjwQzPjClT4mvhM2mXeZ6OIjFHJjlIa1ujCb igAkQoIxPysbZVsgLMvsfhpqAY8KnDg7DzMUkWYgOpNKvobv7YyC1daVZE9W90cI2MBO GCd4ItIsRAb5jHYFkhkf8q/15PdFxrEffebgs3Efc+7RQ/yrArPMY5Qw6y3dtQ5Y7oyT YJ7Q== MIME-Version: 1.0 X-Received: by 10.152.115.196 with SMTP id jq4mr10555292lab.53.1365376408866; Sun, 07 Apr 2013 16:13:28 -0700 (PDT) Received: by 10.112.8.5 with HTTP; Sun, 7 Apr 2013 16:13:28 -0700 (PDT) In-Reply-To: <201304071221.r37CLF5L056989@givry.fdupont.fr> References: <201304071221.r37CLF5L056989@givry.fdupont.fr> Date: Mon, 8 Apr 2013 09:13:28 +1000 Message-ID: Subject: Re: link local address handling while changing hw address of interface From: Andrew McGregor To: Francis Dupont Content-Type: multipart/alternative; boundary=001a11c34c90d5d32b04d9cd77fd Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 23:13:31 -0000 --001a11c34c90d5d32b04d9cd77fd Content-Type: text/plain; charset=ISO-8859-1 There is an issue with using a MAC-based link local address on an interface that does not have that MAC address, which is that any other interface using that MAC that turns up is going to fail DAD. Normally this will be another interface on the same device, but even then it can be an issue. Therefore it is better guidance to say that one should simply change link locals at the time one changes the MAC address... not necessarily to a MAC-derived address, but it is impolite to continue to use the old link local. On Sun, Apr 7, 2013 at 10:21 PM, Francis Dupont wrote: > In your previous mail you wrote: > > > B) is usually correct, although this depends on the semantics of the > lower > > layer in question. If it is Ethernet, by changing the MAC address, you > have > > made a new interface and so the old address end point has gone away. It > is > > usually best to drop the link and restart layer 2 at that point, as any > > switch you are connected to will flush the necessary tables at that > point, > > giving the best chance of being left in a working state. Deprecating the > > link local is therefore pointless, and the Linux behaviour is simply > wrong. > > => I deeply disagree: you assume a binding between layers 2 and 3, in > particular between addresses, which does *not* exist. There is no issue > to use any legal link-local address on a particular Ethernet device, > and this is fully independent of the MAC address. > > Regards > > Francis.Dupont@fdupont.fr > --001a11c34c90d5d32b04d9cd77fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There is an issue with using a MAC-based link local addres= s on an interface that does not have that MAC address, which is that any ot= her interface using that MAC that turns up is going to fail DAD. =A0Normall= y this will be another interface on the same device, but even then it can b= e an issue. =A0Therefore it is better guidance to say that one should simpl= y change link locals at the time one changes the MAC address... not necessa= rily to a MAC-derived address, but it is impolite to continue to use the ol= d link local.


On Sun, Apr 7= , 2013 at 10:21 PM, Francis Dupont <Francis.Dupont@fdupont.fr&= gt; wrote:
=A0In your previous mail y= ou wrote:

> =A0B) is usually correct, although this depend= s on the semantics of the lower
> =A0layer in question. If it is Ethernet, by changing the MAC address, = you have
> =A0made a new interface and so the old address end point has gone away= . It is
> =A0usually best to drop the link and restart layer 2 at that point, as= any
> =A0switch you are connected to will flush the necessary tables at that= point,
> =A0giving the best chance of being left in a working state. Deprecatin= g the
> =A0link local is therefore pointless, and the Linux behaviour is simpl= y wrong.

=3D> I deeply disagree: you assume a binding between layers 2 and = 3, in
particular between addresses, which does *not* exist. There is no issue
to use any legal link-local address on a particular Ethernet device,
and this is fully independent of the MAC address.

Regards

Francis.Dupont@fdupont.fr<= br>

--001a11c34c90d5d32b04d9cd77fd-- From simon.perreault@viagenie.ca Mon Apr 8 01:19:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81B521F9033 for ; Mon, 8 Apr 2013 01:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mcusBLyo0HV for ; Mon, 8 Apr 2013 01:19:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 14ED521F8DE4 for ; Mon, 8 Apr 2013 01:19:26 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7d32:8713:30f2:f934]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C258F414FD for ; Mon, 8 Apr 2013 04:18:55 -0400 (EDT) Message-ID: <51627DBC.9090701@viagenie.ca> Date: Mon, 08 Apr 2013 10:20:12 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: link local address handling while changing hw address of interface References: <201304071221.r37CLF5L056989@givry.fdupont.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 08:19:29 -0000 Le 2013-04-08 01:13, Andrew McGregor a écrit : > There is an issue with using a MAC-based link local address on an > interface that does not have that MAC address, which is that any other > interface using that MAC that turns up is going to fail DAD. Normally > this will be another interface on the same device, but even then it can > be an issue. Therefore it is better guidance to say that one should > simply change link locals at the time one changes the MAC address... not > necessarily to a MAC-derived address, but it is impolite to continue to > use the old link local. What if I *want* to keep the address? For example, what if I want to preserve established TCP sessions? I think once you start playing with MAC addresses, you are expected to know what you're doing. Both generating a new address and keeping the old one can be desirable depending on what you want to accomplish. I don't see any value in a generic recommendation here, beyond the usual "this may void your warranty". ;) Simon From alexandru.petrescu@gmail.com Mon Apr 8 02:47:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447E921F9330; Mon, 8 Apr 2013 02:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWw0A-4pD9ei; Mon, 8 Apr 2013 02:47:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4F31121F91C4; Mon, 8 Apr 2013 02:47:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r389l7q2001237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Apr 2013 11:47:07 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r389l6S2003595; Mon, 8 Apr 2013 11:47:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r389l2rK008744; Mon, 8 Apr 2013 11:47:06 +0200 Message-ID: <51629216.8010206@gmail.com> Date: Mon, 08 Apr 2013 11:47:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <021E64FECA7E5A4699562F4E6671648101E44F@XCH-PHX-503.sw.nos.boeing.com> <515DB606.5070003@gmail.com> <021E64FECA7E5A4699562F4E6671648101E633@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648101E633@XCH-PHX-503.sw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 09:47:13 -0000 Le 04/04/2013 21:56, Manfredi, Albert E a écrit : >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] > >> Some applications involving the use of VIN may have been >> discussed. >> >> One requirement may come from V2V communications when >> infrastructure is not available: how to know the IP address of the >> seen vehicle when DNS is unavailable. > > If these comms are tactical, I would go to something more like > 802.11 ad-hoc network, and do the comms at layer 2. YEs, the link between egress WiFi interfaces of each vehicle (not their ingress WiFi interfaces - in-car), could form a typical 802.11 ad-hoc network. The communications on that link may be layer but could also be IP. > Alternatively, the vehicle can use its assigned IPv6 /64 prefix > (which need not be related to anything specific like a VIN), A /64 inside a vehicle may not be used to be assigned on the link _between_ vehicles, because there is a Router between the inside and the outside of the vehicle. This inside-vehicle prefix could be 'announced' to the other vehicle, but not assigned on that adhoc network. About the non-VIN aspect: the inside-vehicle IPv6 /64 prefix may indeed be tightly related to that vehicle, without using VIN. For example, it could be dynamically configured using DHCP: the MR in vehicle runs Mobile IP and then executes DHCP Prefix Delegation to its Home Agent. The prefix thus obtained is for that particular vehicle. When doing so, one may be interested to dynamicall configure always same prefix for that particular vehicle. That could be realized by using MAC address: do DHCP and put the MAC address of the requesting interface. But many egress interfaces (such as LTE) don't have MAC addresses. One may then put a NAI (Network Access Identifier). But NAI is under the form "user@example.com". But here there is no particular human user - it's the MR of a car (Mobile Router). Otherwise, one may do an address plan for all vehicles of one manufacturer and stamp the IPv6 /64 into one vehicle. That poses some questions about revoking addresses after 10year use, or whether they are Provider-Independent or Provider-Dependent. > and then use MANET. Seems built to order for MANET, no? In general yes, it looks much as MANET is well adapted for this vehicle-to-vehicle communications. However, there may be some difficulties that could be analyzed (which MANET protocol? and how does it do address configuration?). >> Other requirement of using parts of the VIN would be remote >> software update: extract the field of the VIN which represents >> Manufacturer ID, make an IPv6 multicast group of it, and send the >> update accordingly. > > For that, I would way prefer using the VIN as part of a DNS name, > which is then mapped to the IP address of the vehicle. This makes > the problem more amenable to flexible solutions, like allowing the > IP address prefix to be changed periodically, or allowing the vehicle > ID to be associated in any number of ways, other than just a VIN. I tend to agree. A solution could be devised where the VIN may be mapped into a DNS name and make place for more flexible solutions. There may also be some problems with relying on DNS when the vehicle is disconnected from the infrastructure. Or have a DNS server in a vehicle but make sure it's disconnected very often ('autonomous' mode of operation). I am not sure how this could be made to work. > By the way, this vehicle application of IPv6 is another example that > makes me kringe about the waste of even IPv6 address space, when we > continue to discourage the use of longer than 64-bit prefixes. I agree. I think address planning should consider avoid potential waste, and the way in which vehicle industry looks at vehicle lifetime planning (which is different than the typical computer lifetime planning). Alex > Bert > >> >> These are just ideas having been floated in various contexts. >> >> VIN-to-IPv6-InterfaceIdentifier is just one little thing which >> could or not could not work. >> >> Alex > > From alexandru.petrescu@gmail.com Mon Apr 8 04:52:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5A21F93F9 for ; Mon, 8 Apr 2013 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUosjFzHRQGg for ; Mon, 8 Apr 2013 04:52:04 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 06C3721F93EE for ; Mon, 8 Apr 2013 04:52:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r38Bq0rG015471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Apr 2013 13:52:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r38Bq0lY018397 for ; Mon, 8 Apr 2013 13:52:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r38BpubE027352 for ; Mon, 8 Apr 2013 13:52:00 +0200 Message-ID: <5162AF5C.10104@gmail.com> Date: Mon, 08 Apr 2013 13:51:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 11:52:05 -0000 Le 05/04/2013 07:41, Roger Jørgensen a écrit : > On Thu, Apr 4, 2013 at 3:13 AM, Michael Richardson > wrote: > >> If I can derive the VIN from the prefix, I agree that it helps >> identify the vehicle, but not really. If any of this stuff is >> going to be useful, there will already be a collision avoidance >> protocol that will tell each car (even when they are parked) where >> the other vehicles are, so that they can be avoided. >> >> If I can rederive the prefix from the VIN, then it seems we also >> have problems. >> >> What I'm saying is that I don't think that there are *new* privacy >> problems here. > > it's nothing really new with VIN's and IPv6, it's more that we again > was on the way of doing what has been done before and considered a > not so good idea. Ok. There are now the Privacy Extensions to SLAAC. But does that mean that the non-privacy addresses (i.e. a typical MAC-derived IID) are forbidden? I wouldnt think so, no? > Doing 1 to 1 match between a hardware address and an IPv6 address, > and add meaning into the IPv6 address instead of treating it for > what it is, just an address that should be generated somehow other > than directly from a hardware address. Ok. Sounds reasonable. Especially with IPv4: it's just a number. Although practice sees the .1 be the default router, or .254 for that matter, or other extreme of a subnet range. And, as with IPv4, in IPv6 there exist particular meanings to some addresses: the prefix fe80, the prefix ff, the ug bits, the fffe inner 16bits of an EUI-64, the anycast Interface ID, to name a few. Is there a privacy risk of knowing that that src addresses watches the movie on that particular IPv6 multicast group? With the VIN-IID proposal (not the VIN-ULA prefix proposal), we dont quite propose 1:1 mapping, but a selection of VIN fields to map into an IID. A full 1:1 mapping VIN-IID is not possible because one is 78bits the other is 64bits. (and yes, the proposed mapping may have issues with a particular privacy risk, and it may help with some applications.) > That it also has a privacy side issue with it don't make it any > better. Plenty of suggestion on how that can be used have been > mention. Right. To avoid the particular privacy risk of reverse mapping IID-VIN, one may use the output of a hash of the VIN. That would be ok to respect privacy, yet it would disallow the applications which may need this reverse mapping. Alex From internet-drafts@ietf.org Mon Apr 8 07:26:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC3721F9782; Mon, 8 Apr 2013 07:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4boh40hVEo8; Mon, 8 Apr 2013 07:26:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AFD21F94FF; Mon, 8 Apr 2013 07:26:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-multicast-addr-arch-update-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408142606.2321.6821.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 07:26:06 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:26:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Updates to the IPv6 Multicast Addressing Architecture Author(s) : Mohamed Boucadair Stig Venaas Filename : draft-ietf-6man-multicast-addr-arch-update-00.txt Pages : 5 Date : 2013-04-08 Abstract: This document updates the IPv6 multicast addressing architecture by defining the 17-20 reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306, RFC 4607 and RFC 4291. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From swb@internet2.edu Mon Apr 8 07:54:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C321F975B for ; Mon, 8 Apr 2013 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqySN9EK+wHk for ; Mon, 8 Apr 2013 07:54:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 448B321F975D for ; Mon, 8 Apr 2013 07:54:36 -0700 (PDT) Received: from mail39-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE012.bigfish.com (10.3.207.134) with Microsoft SMTP Server id 14.1.225.23; Mon, 8 Apr 2013 14:54:35 +0000 Received: from mail39-am1 (localhost [127.0.0.1]) by mail39-am1-R.bigfish.com (Postfix) with ESMTP id 3223A2C02E9; Mon, 8 Apr 2013 14:54:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.5; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0811HT002.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 8 X-BigFish: S8(zzbb2dI98dIzz1f42h1fc6h1d77h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1b1cn1b1bi1155h) Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1 (MessageSwitch) id 1365432873485705_1377; Mon, 8 Apr 2013 14:54:33 +0000 (UTC) Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.238]) by mail39-am1.bigfish.com (Postfix) with ESMTP id 6A86CE0052; Mon, 8 Apr 2013 14:54:33 +0000 (UTC) Received: from BL2PRD0811HT002.namprd08.prod.outlook.com (157.56.241.5) by AM1EHSMHS019.bigfish.com (10.3.207.157) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Apr 2013 14:54:33 +0000 Received: from swbi2mbp.local (98.79.94.25) by pod51019.outlook.com (10.255.107.165) with Microsoft SMTP Server (TLS) id 14.16.287.8; Mon, 8 Apr 2013 14:54:29 +0000 Message-ID: <5162DA25.4070508@internet2.edu> Date: Mon, 8 Apr 2013 10:54:29 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <5162AF5C.10104@gmail.com> In-Reply-To: <5162AF5C.10104@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [98.79.94.25] X-OriginatorOrg: internet2.edu Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:54:37 -0000 On 04/08/13 07:51, Alexandru Petrescu allegedly wrote: > Right. To avoid the particular privacy risk of reverse mapping IID-VIN, > one may use the output of a hash of the VIN. That would be ok to > respect privacy, yet it would disallow the applications which may need > this reverse mapping. Nothing should try to go from IP address (topological locator) to any sort of identifier. If you need that, use a higher layer protocol. From alexandru.petrescu@gmail.com Mon Apr 8 08:00:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB8021F93E6 for ; Mon, 8 Apr 2013 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.197 X-Spam-Level: X-Spam-Status: No, score=-10.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn6yGxbALRM1 for ; Mon, 8 Apr 2013 08:00:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7B21F91F1 for ; Mon, 8 Apr 2013 08:00:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r38F0CoK008788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Apr 2013 17:00:12 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r38F0BeG012082; Mon, 8 Apr 2013 17:00:12 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r38F0BGY032470; Mon, 8 Apr 2013 17:00:11 +0200 Message-ID: <5162DB7B.2050000@gmail.com> Date: Mon, 08 Apr 2013 17:00:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Brim Subject: Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt References: <515733A5.8080509@gmail.com> <5157C8CF.1060503@si6networks.com> <515AFF7A.80102@gmail.com> <515BC0DA.6040203@si6networks.com> <515C2CFF.3060809@gmail.com> <28368.1365004823@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775130626@mbx-01.win.nominum.com> <7858.1365038000@sandelman.ca> <5162AF5C.10104@gmail.com> <5162DA25.4070508@internet2.edu> In-Reply-To: <5162DA25.4070508@internet2.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 15:00:17 -0000 X-List-Received-Date: Mon, 08 Apr 2013 15:00:17 -0000 Le 08/04/2013 16:54, Scott Brim a écrit : > On 04/08/13 07:51, Alexandru Petrescu allegedly wrote: >> Right. To avoid the particular privacy risk of reverse mapping >> IID-VIN, one may use the output of a hash of the VIN. That would >> be ok to respect privacy, yet it would disallow the applications >> which may need this reverse mapping. > > Nothing should try to go from IP address (topological locator) to > any sort of identifier. If you need that, use a higher layer > protocol. Scott - yes, in principle I largely agree. Except that there may exist some minor exceptions: e.g. the identifier of a multicast group. For example: the group of all vehicles of one particular manufacturer. The group of all vehicles in a particular area. Maybe this is also about being a higher layer protocol. Alex From brian@innovationslab.net Mon Apr 8 08:14:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA94F21F97CD for ; Mon, 8 Apr 2013 08:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyTZopbR9ZKD for ; Mon, 8 Apr 2013 08:14:31 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC1421F97CC for ; Mon, 8 Apr 2013 08:14:31 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6BC5088133; Mon, 8 Apr 2013 07:47:38 -0700 (PDT) Received: from clemson.local (unknown [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id F31F014000D; Mon, 8 Apr 2013 07:47:37 -0700 (PDT) Message-ID: <5162D861.5080006@innovationslab.net> Date: Mon, 08 Apr 2013 10:46:57 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-6man-stable-privacy-addresses@tools.ietf.org Subject: AD Evaluation: draft-ietf-6man-stable-privacy-addresses Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 15:14:32 -0000 All, I have performed by AD review of draft-ietf-6man-stable-privacy-addresses. For the most part, this is a well-written document. I only have a few comments that should be resolved prior to moving this to IETF Last Call... 1. Section 1 : I understand that the fourth paragraph is indented since it is quoting from another document. I do not see why the fifth paragraph is indented. The same confusion exists for the second paragraph of Section 3. 2. Section 3 : * The PRF is fed several variables in order to generate a random number. I appreciate that the issues with different identifiers being generated for the same prefix due to varying values of DAD_Counter are discussed (Section 4). What is missing is discussion of when the Interface_Index value changes. On many systems, the value returned via the socket APIs is based on the ifIndex value assigned to the interface. There are a variety of situations where the ifIndex can change within a system and these should be mentioned. This can impact design goal #2. * What are the assumptions on this algorithm with respect to multi-homed devices that could have different network interfaces available to attach to the same network? For example, if I have a quad-port network card, I could attach to a network via eth0 and get an identifier for prefix X. The next time I attach to that network, I use eth2 and I will not get the same identifier even though I still get a PIO containing prefix X. This issue directly contradicts design goal #1. 3. I think it would be good to explicitly state that this IID generation mechanism is incrementally deployable since there are no interoperability issues with IID generation. Regards, Brian From markzzzsmith@yahoo.com.au Mon Apr 8 14:30:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C052B21F8FED for ; Mon, 8 Apr 2013 14:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLrGLYK+IhJF for ; Mon, 8 Apr 2013 14:30:12 -0700 (PDT) Received: from nm2-vm0.bullet.mail.bf1.yahoo.com (nm2-vm0.bullet.mail.bf1.yahoo.com [98.139.213.127]) by ietfa.amsl.com (Postfix) with SMTP id 92EBB21F901A for <6man@ietf.org>; Mon, 8 Apr 2013 14:30:11 -0700 (PDT) Received: from [98.139.215.143] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 08 Apr 2013 21:30:10 -0000 Received: from [98.139.212.201] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 08 Apr 2013 21:30:10 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 08 Apr 2013 21:30:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 691569.26985.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 99838 invoked by uid 60001); 8 Apr 2013 21:30:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1365456610; bh=L7yaymN3cCZCpXdgNRV9a2LbQpITxyL8ng3NG308Uss=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=E7iLkG+lKNEL6nYiNsnwPP6hmSdvTI11xYBt/WA3ET+s5iDt4g40GFJLLjcjt8HT4X5QbJUY63GjOD13DBlPIboY/jfc8A6R+3HL7VeFBRq5/MFOuAp4e8JE1i6wlPsmuvkpfzHEDXTBXYtbjsqMzy7hPuo54wbbvfq1aPAa0mA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BEc36rUFueangEBhp5snXwe62zMWvFZnW4s3tMCvrpbFgt/DBezvOr7/VNkiLof3WX7qy85m4qG0H+kbgKvHckalGLM/C9/SJQYkQYeUhwWj9UD8FAxkr0/rPSoB16B4Zd/z7zCplqAIqiaal5xzlDvk82e+GHZSoEUpPi2WtV8=; X-YMail-OSG: kt_fp6gVM1nnW86llgIfa0UV7Muy8eOQyt9Gt8HGc8HCAR6 SGjXwMwnaZFij0FZaffRaNDdvLI9pdqdBOQ.zsp7P8IUuMt8VZVHVcl3m3XQ _RC48nb3U1CTViseWNAPRrZFeX8qxNBJPh0IVgcCFjXeE_4Mzn6ynG2y54TC iGY_W4G4FKalIi16CiGeJHD0er7Cu5JN6kGuqWOLxjHTqlJCCX0PobV5zIFP m5RAqCFG3LlqKbZ4V5BscASBPeKkcSArw15Eu5iraVgmyYF0a7EZfsePog7b G88oclZZ_RGpf.Yr7agnOF7ZsT9QKHExIcv1H5ExWmLRa5PEe05MWzFuK7Bc Iv3Ain0Bux8P2H6pzyCp5xUGcCMNlFKY8nSKZGI0qboAK4Xyf4Ey90F5sQgq BNSDFD7F3C8kKwlflMb8tsJgtn4yYxpUVECwo80yBzzeQpFIF89S5rHRkFLe 4kOeLmY2Fpiv_VqR6PapnWS_Vx7tQcl4EYJ.hKNUrTjLgk4ws6xL3OaATOk2 8Sn75scYyXQC40Suc6XQrAZbzuj2LOvizKq8Ef1WQiQOanYfwNN.q1_2BH56 o25lXg10BaMa3CcKMHV9R60hXCh4oogY2fC9UMgg8HnYDoGQKf.2LWONWEDS tYUNAdnEYaXjly.tPiECtoYT06LCmSYCUb52sYZilYbue5kNzwA-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Mon, 08 Apr 2013 14:30:10 PDT X-Rocket-MIMEInfo: 002.001, SGnCoFRvZXJsZXNzLAoKU29ycnkgbm90IHRvIGdldCBiYWNrIHRvIHlvdSBzb29uZXIsIGEgYml0IHRpbWUgY29uc3RyYWluZWQgYXQgdGhlIG1vbWVudC4KClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4KCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBUb2VybGVzcyBFY2tlcnQgPGVja2VydEBjaXNjby5jb20.Cj4gVG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6ICJzYXJpa2F5YUBpZWVlLm9yZyIgPHNhcmlrYXkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130401205621.GG23316@cisco.com> Message-ID: <1365456610.93221.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Mon, 8 Apr 2013 14:30:10 -0700 (PDT) From: Mark Smith Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" To: Toerless Eckert MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mboned@ietf.org" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 21:30:13 -0000 Hi=A0Toerless,=0A=0ASorry not to get back to you sooner, a bit time constra= ined at the moment.=0A=0AThanks very much for your review and comments.=0A= =0A----- Original Message -----=0A> From: Toerless Eckert =0A> To: Mark Smith =0A> Cc: "sarikaya@ieee.org= " ; Dave Thaler ; "mboned@ietf.or= g" ; "6man@ietf.org" <6man@ietf.org>=0A> Sent: Tuesday, 2 = April 2013 7:56 AM=0A> Subject: Re: [MBONED] "MLDv2 Procedures for Link-Lay= er Unicast Delivery of Multicast"=0A> =0A> Bunch of comments...=0A> =0A> 1.= What Mark is proposing is being done AFAIK in a variety of products on the= =0A> market,=0A> =A0=A0 for example as the "multicast to unicast" eleement= of Cisco =0A> VideoStream =0A> =A0=A0 and i think other vendors do this as= well. Not sure about IPv6 though, =0A> i've only seen=0A> =A0=A0 it in IPv= 4.=0A>=A0=0A=0A=0AThat's good to know, I'd say it shows the idea is both fe= asible, useful and deployable.=0A=0AI found the following, which was a reas= onable overview:=0A=0Ahttp://www.cisco.com/en/US/prod/collateral/wireless/p= s6302/ps8322/ps10315/ps10325/white_paper_c11-577721.html=0A=0ADale Carder a= lso pointed off list that Aruba Networks do the same thing (under=A0Dynamic= Multicast Optimization):=0A=0Ahttp://www.arubanetworks.com/vrd/80211nnetwo= rksvrd/wwhelp/wwhimpl/common/html/wwhelp.htm#href=3DChap4_AdaptRadioMgmt.ht= ml&single=3Dtrue=0A=0A> 2. I am always getting annoyed when IPv6 bigots oop= s: fans unnecessarily =0A> constraining=0A> =A0=A0 solutions to IPv6 only e= ven though they equally apply to IPv4 and, in the =0A> case=0A> =A0=A0 of I= P multicast when its clear that the mayority of use for a while will =0A> s= till be=0A> =A0=A0 IPv4. Its already bad enough that RFC6085 was written on= ly for IPv6 instead =0A> of=0A> =A0=A0 for IPv4 and IPv6. It would be lovel= y if Marks draft could be modified to =0A> cover=0A> =A0=A0 both IPv4 and I= Pv6. I can't remember that RFC6085 was given for review to =0A> MBoned,=0A>= =A0=A0 or else i'd hae made that comment for it as well. But see 1: in pra= ctice =0A> existing=0A> =A0=A0 IPv4 host stacks will wwell receive DMAC-uni= cast IP multicast packets due to =0A> the=0A> =A0=A0 fundamental separation= of L3 and L2 in the architecture of most host stacks.=0A>=A0=0A=0AI initia= lly limited the topic to IPv6, because I knew IPv6 had the functions necess= ary i.e. MLDv2 and IPv6 ND NUD. That being said, Carston has since pointed = out that RFC4861 says that NUD is only supposed to be done for unicast traf= fic, but not multicast traffic. That would be talking about layer 3 unicast= vs layer 3 multicast. To accommodate the use of NUD for what is proposed h= ere, RFC4861 would have to be slightly updated to apply NUD to link-layer u= nicast of layer 3 multicast.=0A=0AAs for IPv4, that was something I was goi= ng to investigate. IGMPv3 would support this, the missing bit is an ARP equ= ivalent of NUD. As far as I'm aware (although I haven't done much research = yet), there is no RFC that specifies "ARP NUD". I have found that RFC1122 "= 2.3.2.1 =A0ARP Cache Validation" does specify that Unicast polling of a nei= ghbor using point-to-point ARPs can be use to check ARP cache entry validit= y. Also in passing I've noticed that Linux's implementation of ARP seems to= use the states that it's IPv6 ND implementation uses, but I haven't yet ve= rified that the behaviour is exactly the same. In other words, I think it i= s highly likely it can be applied to IPv4, but I wanted to see if "ARP NUD"= was both permitted and also described somewhere. The follow on question is= whether that description would have updated similarly to RFC4861.=0A=0A> 3= . I think a key eleemnt of the draft that should be made more clear in the= =A0=0A=0A> description is=0A> =A0=A0 that this mechanism is meant to be inc= rementally dpeloyable such that the =0A> mayority=0A> =A0=A0 of devices on = the (wireless) L2 domain do not have to be changed at all, and =0A> that=0A= > =A0=A0 the only expection against them is 2. (RFC6085 or equivalent for I= Pv4).=0A>=A0=0A=0AI've realised through the discussion over the last few da= ys that I need to separate out and make more clear some of these points. Th= is first version was mainly to "throw it at the wall and see if it sticks."= =0A=0A> =A0=A0 To achieve this, the only requirement is to run IGMPv3/MLDv2= , inhibit =0A> MLDv1/IGMPv1v2,=0A> =A0=A0 and a device that wants to send m= ulticast as unicast into the L2 domain needs =0A> to=0A> =A0=A0 perform exp= licit tracking of the membership reports to know whom to send =0A> unicast = copies to. =0A>=A0=0A> =A0=A0 And then there are optimizations such as RFC4= 861 which should be optional.=0A=0A>=A0=0A=0AThe reason I though to use NUD= to track the presence of the neighbors was that neighbor presence discover= y is necessary to resolve the layer 2 information for the link-local MLDv2 = source addresses, and NUD was tracking and verifying individual neighbors i= ndependently.=0A=0ABy default, MLDv2 general queries are only sent around e= very 2 minutes, and there isn't any reliability for that and the responses,= meaning that if a query isn't received due to packet loss, or any of the r= eports are lost due to packet loss, the next opportunity to discover contin= ued listener presence is in around 2 minutes time. So in the case of a sing= le packet being lost, that might mean traffic is being sent to a non-existe= nt listener for up to 4 minutes, which I think is getting a bit too close t= o the typical 5 minute aging of learned MAC addresses in switches.=A0=0A=0A= NUD will probe by default around every 30 seconds, and if it gets no respon= se, will retransmit the probe around once a second. So it'd be much quicker= and more reliable at detecting that the listener has disappeared than usin= g MLDv2 General Queries. As MLDv2 General Queries are going to occur anyway= , one optimisation that has occurred to me is that the corresponding report= s from the listeners could be used as the evidence to Neighbor Discovery th= at the listener still exists, as a General Query and the corresponding repo= rts are a two way transaction. The NUD probe could then be delayed for anot= her 30 seconds. One drawback of this idea though would be that it would sta= rt roughly synchronising when NUD probes to all the listeners starts.=0A=0A= So I think using NUD (perhaps with MLDv2 GQ/Report hints) would be a better= mechanism to use to track listener presence.=0A=0A> =A0=A0 But having said= all this, the fact that this can be done as a local =0A> implementation=0A= > =A0=A0 optimization in a device sending IP multicast into the L2 domain (= whether =0A> thats=0A> =A0=A0 a router, switch, host or whatever), it also = means that this mechanism does =0A> not=0A> =A0=A0 need to change any proto= col signaling, and therefore the question is whether =0A> this=0A> =A0=A0 c= an be standards track or just be informational.=0A>=A0=0A=0AI'd think stand= ards track due to the minor change required to RFC4861.=0A=0AI'm not sure w= hat happens with IPv4, as I haven't found an RFC describing "ARP NUD".=0A= =0A> 4. I don't particularily think that the operating models presented and= the =0A> first=0A> =A0=A0 sentence of the abstract are correct. Sending L2= (wireless) multicast has a =0A> lot of=0A> =A0=A0 benefits, and it has a l= ot of downsides. It totally depends on what you try =0A> to achieve.=0A>=A0= =0A=0AThat's why I used "may".=0A=0ALink layer multicasts should be used wh= en they're better than what I've described. However, when link-layer multic= asts are not going to perform as well as replication and link-layer unicast= s, or when some of the other differences of replication and link-layer unic= ast are beneficial (i.e., better data confidentiality, better battery life = on mobile devices like tablets, smartphones etc.), then what is described c= ould be used.=0A=0AThe operating models were really just to highlight that = not only could it be done on a per-group basis, but might also be useful to= adopt for all groups on an interface, which may be a useful default model = for an 802.11 interface.=0A=0A> =A0=A0 It is clear that 802.11 is particula= rily challenged with native L2 multicast =0A> because=0A> =A0=A0 they never= defined a good resilience scheme as for unicast but so far not for =0A> mu= lticast.=0A> =A0=A0 Hopefully this will get fixed sometime. As long as that= s not the case we =0A> definitely=0A> =A0=A0 have to tke this into account = as a constraint, but it would be good to =0A> explain the=0A> =A0=A0 situat= ion correctly in the doc.=0A>=A0=0A=0AWhile I agree the doc is light on ref= erenced evidence, I think it still describes the situation correctly, becau= se I've done experiments of my own, and have seen bad multicast video over = wifi, and have seen multicast traffic impact unicast performance.=A0=0A=0A>= =A0=A0 Wrt. the operational model, i could easily see that one wold start = out with =0A> unicasting,=0A> =A0=A0 but then change over to multicasting f= or a particular group/channel when the=0A> =A0=A0 total number of receivers= tracked and bandwidth sent over the group/channel =0A> is too large.=0A=0A= I can't think of a situation when falling back to multicast after using rep= licated link-layer unicast would be useful. I consider what I've described = to be an alternative to link-layer multicast, to be used when either it is = either known or likely from the outset that link-layer multicast will be in= adequate, or when replication and link-layer unicast provides some useful a= dvantages over link-layer multicast. Falling back to link-layer multicast w= ouldn't solve the replication and link-layer unicast performance problems i= f they've occurred (otherwise, use multicast in the first place), or would = eliminate the useful advantages that replication and link-layer unicast pro= vided.=0A=0AI know it is possible to tune 802.11 to provide better multicas= t performance, however I understand that that tuning requires changing sett= ings on all of the AP clients, as well as possibly on the AP, and if one ne= w client which isn't tuned joins the link, performance drops back to before= any tuning took place. This tuning would be beyond the capability of most = residential home users.=0A=0AAnother thought I've had is that as wired swit= ches are doing this type of packet replication and effectively link-layer u= nicasting out their individual ports, perhaps in the future the hardware do= ing this could also be adapted to increase the performance of replication a= nd link-layer unicasting over 802.11.=0A=0A=0A> =A0=A0 You may also limit I= P multicast to a particular bitrate, so if a specific =0A> receiver=0A> =A0= =A0 can not support that bitrate, it would need to get unicast, and then th= at =0A> unicast=0A> =A0=A0 might need to be rate-limited so that the receiv= er downspeeds (assuming it is=0A> =A0=A0 using ALC which it really should).= I am not aware if any product embodies =0A> =A0=A0 this dyanmicac switchin= g, i am just saying it sounds logical to me ;-)=0A>=A0=0A=0AThis generally = sounds to me to be above layer 3 (and the interface to layer 2) and be in t= he domain of either things like RSVP, or applications/protocols that alread= y provide reliable multicast, mainly because I think it is necessary for th= e receiver to indicate to the sender success or failure of packet delivery.= =0A=0AIt could be done also be done on a link layer level, and I understand= that 802.11 probably has enough mechanisms to be able to do this (e.g. ack= nowledgements and retransmissions). However, while 802.11 is the most likel= y use case for what I've described, I think there are benefits in keeping i= t generic, and applicable to any current or future link-layers which suppor= t both multicast and unicast transmission. For example, multicast over wire= d ethernet is (usually?) going to outperform replication and link-layer uni= cast (although, as a few people have pointed out off-list, switches are in = effect doing replicating and link unicasting to emulate broadcast/multicast= behaviour), however the other benefits may mean it is preferable to use wh= at I've described instead of link-layer multicast.=0A=0A=0A> =A0=A0 So, giv= en how many policies there could be to improve behavior of multicast =0A> o= ver=0A> =A0=A0 wireless, i think it would be more appropriate to make this = draft =0A> informational=0A> =A0=A0 and collect/document/discss these possi= ble policies. Its not as if a specific =0A> individual=0A> =A0=A0 policy se= ems to be ubiquoutously preferrable, and given how its all local =0A> polic= y on the=0A> =A0=A0 device sending into the wireless L2, it doesn't seem to= be the right =0A> place for a=0A> =A0=A0 standard track doc. Going informa= tional does hopefully not make a difference =0A> for =0A> =A0=A0 this doc b= eing useful, because whether its standards track or not, customers =0A> wil= l hopefully =0A> =A0=A0 put it into RFPs against their wireless equipment. = Which also means its a =0A> good idea=0A> =A0=A0 in these type of documents= to give sticky names to individual functions such =0A> as=0A> =A0=A0 diffe= rent type of policies or optimizations, so customes in RFPs can refer to = =0A> those=0A> =A0=A0 sticky names (or section numbers).=0A> =0A> 5. Not be= ing really a protocol extension but logically device-local improvements =0A= > with=0A> =A0=A0 a bunch of policies possible makes it also a good candida= te for MBoned as =0A> opposed to a=0A> =A0=A0 protocol group (i think... ).= =0A>=A0=0A=0A=0AThanks again.=0A=0ABest regards,=0AMark.=0A=0A> Cheers=0A> = =A0 =A0 Toerless=0A> =0A> =A0=A0 tracking of =0A> =A0=A0 that it is consist= ing purely of mechanisms that the accss-point type device =0A> in a=0A> =A0= =0A> =0A> On Fri, Mar 29, 2013 at 03:18:06PM -0700, Mark Smith wrote:=0A>>= =A0 Hi Behcet,=0A>> =0A>>=A0 Thanks for your review and comments.=0A>> =0A>= > =0A>> =0A>>=A0 >________________________________=0A>>=A0 > From: Behcet S= arikaya =0A>>=A0 >To: Dave Thaler =0A>>=A0 >Cc: Mark Smith ; =0A> "6man@iet= f.org" <6man@ietf.org>; "mboned@ietf.org" =0A> =0A>>=A0 >= Sent: Saturday, 30 March 2013 8:33 AM=0A>>=A0 >Subject: Re: [MBONED] "MLDv2= Procedures for Link-Layer Unicast =0A> Delivery of Multicast"=0A>>=A0 > = =0A>>=A0 >=0A>>=A0 >Hi Mark,=0A>>=A0 >=0A>>=A0 >I read your draft. =0A>>=A0= >First of all I think you misunderstood RFC 6085 and based on a wrong =0A>= assumption you developed your solution.=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >What = specifically do you think I've misunderstood? I was involved =0A> in some o= f the conversations about that RFC while it was an ID, and all I think =0A>= it really is fundamentally saying is that an IPv6 packet with a multicast = IPv6 =0A> destination address isn't required to have a link-layer multicast= =0A> destination address - it can be a link-layer unicast destination addr= ess if =0A> useful or necessary.=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A= >>=A0 >=A0I suggest you take a look at =0A> http://tools.ietf.org/html/draf= t-sarikaya-netext-pmipv6-shared-link-01=0A>>=A0 >on Netext for PMIPv6.=0A>>= =A0 >=0A>>=A0 >=0A>>=A0 >I'll have a read.=0A>>=A0 >=0A>>=A0 >I believe tha= t we should use multicast delivery as much as possible on =0A> the downlink= if the link is a shared link.=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A>>= =A0 >I agree with using multicast as much as possible to reduce duplicate = =0A> packets sent over the network. The proposal here is to use packet repl= ication =0A> and link-layer unicasts when doing so would either exceed the = performance of =0A> link-layer multicast and/or overcome the negative effec= ts of link-layer =0A> multicast, such as when larger volumes of multicast t= raffic impact unicast =0A> performance on the same link. Both of these issu= es occur on 802.11 links when =0A> there volume of multicast traffic is in = the order of a few megabits (or less, =0A> I've been testing with around 2.= 5 Mbps of video)=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >The main use case I've been t= hinking about (which I'll make =0A> more obvious in the next revision), is = a multicast IPTV service scenario towards =0A> a residential customer, wher= e the residential customer has a 802.11 network in =0A> their home rather t= han a wired one. IPv6 multicast/link-layer multicast would be =0A> used all= the way from the multicast source servers, across the service provider =0A= > network, up until the CPE in the residential customers' homes, gaining th= e =0A> efficiencies of multicast. However, the CPE in the customer's house = would =0A> then use IPv6 multicast/link-layer unicast of the IPTV traffic o= ver the 802.11 =0A> link to the customers end-hosts, saving them having to = put in wired =0A> infrastructure, or resorting to buying ethernet over powe= r devices to make their =0A> power cabling their wired infrastructure. Note= that there is still a low level =0A> of link-layer multicast traffic in th= e customers home, for RAs, ND, MLDv2 =0A> messages, DHCPv6, etc.. This prop= osal is not eliminating=0A>> =A0 link-layer multicasts, just reducing them = where possible and where useful.=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >That's not to= say this proposal is only useful in an 802.11 =0A> scenario. It could be u= sed in any scenario where packet replication and =0A> link-layer unicasting= would provide useful benefits over link-layer multicasts. =0A> It generall= y increases the data confidentiality of the multicast IPv6 traffic, =0A> an= d may help increase battery life of some devices.=0A>>=A0 >=0A>>=A0 >=0A>>= =A0 >Thanks very much,=0A>>=A0 >Mark.=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A>>=A0= >Regards,=0A>>=A0 >=0A>>=A0 >Behcet=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A>>=A0 = >=0A>>=A0 >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler =0A> wrote:=0A>>=A0 >=0A>>=A0 >http://tools.ietf.org/html/draft-thaler= -ngtrans-6to4-multicast=0A>>=A0 >>is work we did back in 2000 on this same = topic. =A0 At the time, the =0A> draft is written from=0A>>=A0 >>the perspe= ctive of the 6to4 NBMA link, but the topic was discussed =0A> (specifically= by those=0A>>=A0 >>in the acknowledgements section, and to a lesser extent= by the =0A> ngtrans WG as a whole)=0A>>=A0 >>as being more generally appli= cable.=0A>>=A0 >>=0A>>=A0 >>There wasn't significant interest at the time a= nd so the work =0A> was dropped=0A>>=A0 >>rather than updating the spec to = use generic language.=0A>>=A0 >>=0A>>=A0 >>The same concept as in the above= was however then used in 2001 in=0A>>=A0 >>http://tools.ietf.org/html/draf= t-ietf-mboned-auto-multicast=0A>>=A0 >>(still specific to a particular link= type though), which after 11 =0A> years is now in the IESG :)=0A>>=A0 >>= =0A>>=A0 >>The most relevant WG is MBoneD.=0A>>=A0 >>=0A>>=A0 >>-Dave=0A>>= =A0 >>=0A>>=A0 >>=0A>>=A0 >>> -----Original Message-----=0A>>=A0 >>> From: = ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On =0A> Behalf Of=0A>>= =A0 >>> Mark Smith=0A>>=A0 >>> Sent: Thursday, March 28, 2013 8:22 PM=0A>>= =A0 >>> To: 6man@ietf.org=0A>>=A0 >>> Subject: "MLDv2 Procedures for Link-L= ayer Unicast =0A> Delivery of Multicast"=0A>>=A0 >>>=0A>>=A0 >>> Hi,=0A>>= =A0 >>>=0A>>=A0 >>> The following is inspired by some work I did in around = =0A> 2010/2011 on a=0A>>=A0 >>> multicast TV service, where residential cus= tomers with Wifi =0A> networks=0A>>=A0 >>> suffered from performance proble= ms, and had to be advised to =0A> buy=0A>>=A0 >>> ethernet over power devic= es if they couldn't run wired =0A> ethernet to the STB=0A>>=A0 >>> attached= to their TV.=0A>>=A0 >>>=0A>>=A0 >>> I've done some experiments on my home= wifi network, using =0A> VLC, and=0A>>=A0 >>> switching between multicast = and unicast IPv6 to test the =0A> concept. The wifi=0A>>=A0 >>> performance= issues disappear when the video is delivered via =0A> unicast UDP.=0A>>=A0= >>> (If people want to play with VLC and IPv6 multicast, email me =0A> off= -list, as there=0A>>=A0 >>> are a few issues e.g. the GUI doesn't accept so= me of the =0A> IPv6 multicast=0A>>=A0 >>> parameters that the command line = does).=0A>>=A0 >>>=0A>>=A0 >>> I think there is a possibility the technique= could also be =0A> applied to=0A>>=A0 >>> IGMPv3/ARP, although it depends = on whether ARP has been =0A> implemented=0A>>=A0 >>> in a similar manner to= IPv6 ND (e.g. an ARP equivalent to =0A> NUD). My=0A>>=A0 >>> understanding= is that Linux has implemented ARP this way. =0A> I'll do some more=0A>>=A0= >>> research to verify this.=0A>>=A0 >>>=0A>>=A0 >>> I though I'd post it = to see if there is merit in the idea =0A> and it is worth spending=0A>>=A0 = >>> more of my time on. I looked for a IETF group more suitable to =0A> thi= s, but didn't=0A>>=A0 >>> seem to be able to find one. If there is one, ple= ase let me =0A> know.=0A>>=A0 >>>=0A>>=A0 >>> Review and comments most appr= eciated.=0A>>=A0 >>>=0A>>=A0 >>> Thanks very much,=0A>>=A0 >>> Mark.=0A>>= =A0 >>>=0A>>=A0 >>>=0A>>=A0 >>> ----- Forwarded Message -----=0A>>=A0 >>> >= From: "internet-drafts@ietf.org" =0A> =0A>>=A0 >= >> > To: markzzzsmith@yahoo.com.au=0A>>=A0 >>> > Cc:=0A>>=A0 >>> > Sent: Fr= iday, 29 March 2013 1:45 PM=0A>>=A0 >>> > Subject: New Version Notification= for=0A>>=A0 >>> > draft-smith-mldv2-link-unicast-00.txt=0A>>=A0 >>> >=0A>>= =A0 >>> >=0A>>=A0 >>> > A new version of I-D, =0A> draft-smith-mldv2-link-u= nicast-00.txt=0A>>=A0 >>> > has been successfully submitted by Mark Smith a= nd posted =0A> to the IETF=0A>>=A0 >>> > repository.=0A>>=A0 >>> >=0A>>=A0 = >>> > Filename:=A0=A0=A0 =A0draft-smith-mldv2-link-unicast=0A>>=A0 >>> > Re= vision:=A0=A0=A0 =A000=0A>>=A0 >>> > Title:=A0=A0=A0 =A0=A0=A0 =A0MLDv2 Pro= cedures for Link-Layer Unicast =0A> Delivery of=0A>>=A0 >>> > Multicast=0A>= >=A0 >>> > IPv6=0A>>=A0 >>> > Creation date:=A0=A0=A0 =A02013-03-29=0A>>=A0= >>> > Group:=A0=A0=A0 =A0=A0=A0 =A0Individual Submission=0A>>=A0 >>> > Num= ber of pages: 7=0A>>=A0 >>> > URL:=0A>>=A0 >>> > =0A> http://www.ietf.org/i= nternet-drafts/draft-smith-mldv2-link-unicast-00.=0A>>=A0 >>> > txt=0A>>=A0= >>> > Status:=0A>>=A0 >>> > =0A> http://datatracker.ietf.org/doc/draft-smi= th-mldv2-link-unicast=0A>>=A0 >>> > Htmlized:=0A>>=A0 >>> > =0A> http://too= ls.ietf.org/html/draft-smith-mldv2-link-unicast-00=0A>>=A0 >>> >=0A>>=A0 >>= > >=0A>>=A0 >>> > Abstract:=0A>>=A0 >>> > =A0 =A0Some multi-access link-lay= er technologies typically =0A> not provide=0A>>=A0 >>> > good=0A>>=A0 >>> >= =A0 =A0IPv6 multicast performance, using link-layer =0A> multicasts, when = the=0A>>=A0 >>> > =A0 =A0volume of multicast traffic is significant.=A0 It = would =0A> be possible=0A>>=A0 >>> > to=0A>>=A0 >>> > =A0 =A0replicate and = then link-layer unicast multicast IPv6 =0A> traffic to=0A>>=A0 >>> > =A0 = =A0interested listeners to overcome these link-layer =0A> performance=0A>>= =A0 >>> > =A0 =A0limitations.=A0 This memo describes MLDv2 and IPv6 =0A> ne= ighbor discovery=0A>>=A0 >>> > =A0 =A0procedures to support link-layer unic= ast delivery of =0A> multicast IPv6=0A>>=A0 >>> > =A0 =A0traffic.=0A>>=A0 >= >> >=0A>>=A0 >>> >=0A>>=A0 >>> >=0A>>=A0 >>> >=0A>>=A0 >>> >=0A>>=A0 >>> > = The IETF Secretariat=0A>>=A0 >>> >=0A>>=A0 >>> =0A> -----------------------= ---------------------------------------------=0A>>=A0 >>> IETF IPv6 working= group mailing list=0A>>=A0 >>> ipv6@ietf.org=0A>>=A0 >>> Administrative Re= quests: =0A> https://www.ietf.org/mailman/listinfo/ipv6=0A>>=A0 >>> =0A> --= ------------------------------------------------------------------=0A>>=A0 = >>_______________________________________________=0A>>=A0 >>MBONED mailing = list=0A>>=A0 >>MBONED@ietf.org=0A>>=A0 >>https://www.ietf.org/mailman/listi= nfo/mboned=0A>>=A0 >>=0A>>=A0 >=0A>>=A0 >=0A>>=A0 >=0A>>=A0 _______________= ________________________________=0A>>=A0 MBONED mailing list=0A>>=A0 MBONED= @ietf.org=0A>>=A0 https://www.ietf.org/mailman/listinfo/mboned=0A> =0A> -- = =0A> ---=0A> Toerless Eckert, eckert@cisco.com=0A> Cisco NSSTG Systems & Te= chnology Architecture=0A> SDN: Let me play with the network, mommy!=0A> From fgont@si6networks.com Mon Apr 8 23:28:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5390621F8FFA for ; Mon, 8 Apr 2013 23:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkEV+CqCtENC for ; Mon, 8 Apr 2013 23:28:13 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7E21F8FE8 for ; Mon, 8 Apr 2013 23:28:12 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UPS2G-0003Tu-R9; Tue, 09 Apr 2013 08:28:05 +0200 Message-ID: <5163B4ED.70207@si6networks.com> Date: Tue, 09 Apr 2013 03:27:57 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian Haberman Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> In-Reply-To: <5162D861.5080006@innovationslab.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 06:28:15 -0000 Hi, Brian, Thanks so much for the review! -- Please find my comments in-line... On 04/08/2013 11:46 AM, Brian Haberman wrote: > 1. Section 1 : I understand that the fourth paragraph is indented since > it is quoting from another document. I do not see why the fifth > paragraph is indented. The same confusion exists for the second > paragraph of Section 3. Indented ṕararagraphs, unless otherwise noted, are parenthetical notes, rather than quotes from other documents (i.e., text that provides additional information, but that you may skip reading if you want). > 2. Section 3 : > > * The PRF is fed several variables in order to generate a random number. > I appreciate that the issues with different identifiers being generated > for the same prefix due to varying values of DAD_Counter are discussed > (Section 4). What is missing is discussion of when the Interface_Index > value changes. On many systems, the value returned via the socket APIs > is based on the ifIndex value assigned to the interface. There are a > variety of situations where the ifIndex can change within a system and > these should be mentioned. This can impact design goal #2. HOw about the following text: "The Interface Index is expected to remain constant across system reboots and other events. However, we note that it might change upon removal of a network interface (typically one with a smaller value for the Interface Index, when such naming scheme is used). When such Interface Index changes occur, the IPv6 addresses resulting from this algorithm for an interface index is likely to change, thus affecting the stability property of this approach. We note that we expect these scenarios to be unusual." Maybe in the corresponding "bullet"? Or right after the paragraph that says "Including the SLAAC prefix in the PRF computation causes the..."? > * What are the assumptions on this algorithm with respect to multi-homed > devices that could have different network interfaces available to attach > to the same network? For example, if I have a quad-port network card, I > could attach to a network via eth0 and get an identifier for prefix X. > The next time I attach to that network, I use eth2 and I will not get > the same identifier even though I still get a PIO containing prefix X. > This issue directly contradicts design goal #1. This algorithm aims to produce stable addresses for each interface. SO as long as the same interface gets the same addresses, the algorithm is achieving it's goal. > 3. I think it would be good to explicitly state that this IID generation > mechanism is incrementally deployable since there are no > interoperability issues with IID generation. Good point. How about adding this to the Intro, right after the para that starts with "This document specifies a method to generate interface identifiers...": "We note that this method is is incrementally deployable, since it doesn't pose any interoperability implications when deployed on networks where other nodes do not implement or employ it". ? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Francis.Dupont@fdupont.fr Tue Apr 9 00:40:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD8E21F900F for ; Tue, 9 Apr 2013 00:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riwSw1dSJLFy for ; Tue, 9 Apr 2013 00:40:38 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id B680A21F8F69 for ; Tue, 9 Apr 2013 00:40:37 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r397eZjs015360; Tue, 9 Apr 2013 09:40:35 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201304090740.r397eZjs015360@givry.fdupont.fr> From: Francis Dupont To: Andrew McGregor Subject: Re: link local address handling while changing hw address of interface In-reply-to: Your message of Mon, 08 Apr 2013 09:13:28 +1000. Date: Tue, 09 Apr 2013 09:40:35 +0200 Sender: Francis.Dupont@fdupont.fr Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:40:38 -0000 In your previous mail you wrote: > There is an issue with using a MAC-based link local address on an interface > that does not have that MAC address, which is that any other interface > using that MAC that turns up is going to fail DAD. Normally this will be > another interface on the same device, but even then it can be an issue. > Therefore it is better guidance to say that one should simply change link > locals at the time one changes the MAC address... not necessarily to a > MAC-derived address, but it is impolite to continue to use the old link > local. => I still believe you assume too much about layer 2 (MAC) and layer 3 (IPv6) address relationship. The worst which can happen is "impolite" and of course when you mess the MAC addressing you can't expect address generation based on MAC will still work without conflict. BTW a MAC address is attached to a device according to the IEEE spec, not to an interface, so there is at least one computer vendor who interprets device as the whole computer, not a NIC... Regards Francis.Dupont@fdupont.fr PS: the only point IMHO could be standardized (as a BCP) is to use interface IDs not based on MACs when there are some interests to change a MAC (it seems common sense, i.e., no need to provide long explanations). And implementations should give an easy way to do this (from my past experience this could be more critical). From brian@innovationslab.net Tue Apr 9 08:21:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3701321F93C8 for ; Tue, 9 Apr 2013 08:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTfA+iENQtu9 for ; Tue, 9 Apr 2013 08:21:46 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 56B9621F8526 for ; Tue, 9 Apr 2013 08:21:46 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6FB5688114; Tue, 9 Apr 2013 08:21:40 -0700 (PDT) Received: from clemson.mtw.jhu.edu (unknown [128.220.159.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id F363814000D; Tue, 9 Apr 2013 08:21:39 -0700 (PDT) Message-ID: <51643205.3000903@innovationslab.net> Date: Tue, 09 Apr 2013 11:21:41 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fernando Gont Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> In-Reply-To: <5163B4ED.70207@si6networks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:21:47 -0000 On 4/9/13 2:27 AM, Fernando Gont wrote: > Hi, Brian, > > Thanks so much for the review! -- Please find my comments in-line... > > > On 04/08/2013 11:46 AM, Brian Haberman wrote: >> 1. Section 1 : I understand that the fourth paragraph is indented since >> it is quoting from another document. I do not see why the fifth >> paragraph is indented. The same confusion exists for the second >> paragraph of Section 3. > > Indented ṕararagraphs, unless otherwise noted, are parenthetical notes, > rather than quotes from other documents (i.e., text that provides > additional information, but that you may skip reading if you want). > > We have had this discussion before... I am not a fan of these parenthetical notes, but to each his own. > >> 2. Section 3 : >> >> * The PRF is fed several variables in order to generate a random number. >> I appreciate that the issues with different identifiers being generated >> for the same prefix due to varying values of DAD_Counter are discussed >> (Section 4). What is missing is discussion of when the Interface_Index >> value changes. On many systems, the value returned via the socket APIs >> is based on the ifIndex value assigned to the interface. There are a >> variety of situations where the ifIndex can change within a system and >> these should be mentioned. This can impact design goal #2. > > HOw about the following text: > > "The Interface Index is expected to remain constant across system > reboots and other events. However, we note that it might change upon > removal of a network interface (typically one with a smaller value for > the Interface Index, when such naming scheme is used). When such > Interface Index changes occur, the IPv6 addresses resulting from this > algorithm for an interface index is likely to change, thus affecting the > stability property of this approach. We note that we expect these > scenarios to be unusual." > I don't like "likely to change". In what cases would a change to an input value *not* change the output of the PRF? Additionally, I will note that this scenario may not be as unusual as you think. For example, the ifIndex on some Cisco gear will change enough that IOS has a configuration command to make it stable. > > Maybe in the corresponding "bullet"? Or right after the paragraph that > says "Including the SLAAC prefix in the PRF computation causes the..."? > > The latter would be preferable, but it raises another question. If there is discussion on input values changing in section 3, the text on the impact of DAD_Counter changes in section 4 should probably be moved to section 3. > > >> * What are the assumptions on this algorithm with respect to multi-homed >> devices that could have different network interfaces available to attach >> to the same network? For example, if I have a quad-port network card, I >> could attach to a network via eth0 and get an identifier for prefix X. >> The next time I attach to that network, I use eth2 and I will not get >> the same identifier even though I still get a PIO containing prefix X. >> This issue directly contradicts design goal #1. > > This algorithm aims to produce stable addresses for each interface. SO > as long as the same interface gets the same addresses, the algorithm is > achieving it's goal. > Then something needs to be said in the document about this limitation. This approach does not create stable addresses *per prefix*. > > >> 3. I think it would be good to explicitly state that this IID generation >> mechanism is incrementally deployable since there are no >> interoperability issues with IID generation. > > Good point. > > How about adding this to the Intro, right after the para that starts > with "This document specifies a method to generate interface > identifiers...": > > "We note that this method is is incrementally deployable, since it > doesn't pose any interoperability implications when deployed on networks > where other nodes do not implement or employ it". > > ? The above is fine as long as you remove the redundant "is". Regards, Brian From internet-drafts@ietf.org Tue Apr 9 10:48:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F63F21F93CB; Tue, 9 Apr 2013 10:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.301 X-Spam-Level: X-Spam-Status: No, score=-101.301 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNBvwlxJSb8S; Tue, 9 Apr 2013 10:48:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F058D21F9130; Tue, 9 Apr 2013 10:48:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-dad-proxy-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409174845.2651.57733.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 10:48:45 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:48:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Duplicate Address Detection Proxy Author(s) : Fabio Costa Jean-Michel Combes Xavier Pougnard Hongyu Li Filename : draft-ietf-6man-dad-proxy-07.txt Pages : 15 Date : 2013-04-09 Abstract: The document describes a proxy based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-dad-proxy-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kauer@biplane.com.au Tue Apr 9 15:11:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB17921F9958 for ; Tue, 9 Apr 2013 15:11:36 -0700 (PDT) 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=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmHIuGeUANmG for ; Tue, 9 Apr 2013 15:11:36 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id D5B7321F9616 for ; Tue, 9 Apr 2013 15:11:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0BAJKRZFGWZX+7/2dsb2JhbAANRIM8RMBzgS2DEwEBAQSBCQsYLlcZiBurHpNcjxsWgysDiEaPVIpViDY Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 10 Apr 2013 07:41:33 +0930 Message-ID: <1365545491.28058.311.camel@karl> Subject: Re: I-D Action: draft-ietf-6man-dad-proxy-07.txt From: Karl Auer To: ipv6@ietf.org Date: Wed, 10 Apr 2013 08:11:31 +1000 In-Reply-To: <20130409174845.2651.57733.idtracker@ietfa.amsl.com> References: <20130409174845.2651.57733.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:11:36 -0000 On Tue, 2013-04-09 at 10:48 -0700, internet-drafts@ietf.org wrote: > Abstract: > The document describes a proxy based mechanism [...] > Based on the DAD signalling, the first hop router > stores in a Binding Table all known IPv6 addresses used on a point- > to-multipoint domain (e.g. VLAN). When a node performs DAD for an > address already used by another node, the first hop router replies > instead of this last one. Coming late to this but - DAD NS frames are sent to solicited node multicast addresses, so how is the first hop router seeing them? IPv6-aware (MLD snooping) switches won't forward the DAD NS frames except to members of the SNM group...? What am I missing? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From fgont@si6networks.com Tue Apr 9 18:40:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58D221F992C for ; Tue, 9 Apr 2013 18:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOT1Y6ZR72Na for ; Tue, 9 Apr 2013 18:40:34 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9975D21F9924 for ; Tue, 9 Apr 2013 18:40:34 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UPk1T-0007V5-6i; Wed, 10 Apr 2013 03:40:27 +0200 Message-ID: <5164C303.1090209@si6networks.com> Date: Tue, 09 Apr 2013 22:40:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian Haberman Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> In-Reply-To: <51643205.3000903@innovationslab.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 01:40:35 -0000 Hi, Brian, On 04/09/2013 12:21 PM, Brian Haberman wrote: >> On 04/08/2013 11:46 AM, Brian Haberman wrote: >>> 1. Section 1 : I understand that the fourth paragraph is indented since >>> it is quoting from another document. I do not see why the fifth >>> paragraph is indented. The same confusion exists for the second >>> paragraph of Section 3. >> >> Indented ṕararagraphs, unless otherwise noted, are parenthetical notes, >> rather than quotes from other documents (i.e., text that provides >> additional information, but that you may skip reading if you want). > > We have had this discussion before... I am not a fan of these > parenthetical notes, but to each his own. I wasn't arguing in favor of them, but rather explaining what they were. (FWIW, these notes predate our "discussion" on the subject... and, in all fairness, you're not the first one to not like them :-) ). I'll try to incorporate them into the main body -- fwiw, the reason for which I including those paragraphs as such (parenthetical notes), is so that the reader that is not interested in those details can easily skip them. >> HOw about the following text: >> >> "The Interface Index is expected to remain constant across system >> reboots and other events. However, we note that it might change upon >> removal of a network interface (typically one with a smaller value for >> the Interface Index, when such naming scheme is used). When such >> Interface Index changes occur, the IPv6 addresses resulting from this >> algorithm for an interface index is likely to change, thus affecting the >> stability property of this approach. We note that we expect these >> scenarios to be unusual." > > I don't like "likely to change". Yep, that was stupid -- how about s/for an interface index is likely to change/for an interface will change/? > Additionally, I will note that this scenario may not be as unusual as > you think. For example, the ifIndex on some Cisco gear will change > enough that IOS has a configuration command to make it stable. what's the "event" upon which the interface index will change? "Interface removal", as in the suggested text, or something else? If that's the case, I'd not expect that to happen frequently -- and even less for hosts/servers doing SLAAC (those routers are more likely using statically-configured addresses). Anyway... should I add something along this lines of: "Some implementations are known to provide configuration knobs to set the Interface Index for a given interface. This could be leveraged to prevent maintain the same Interface Index for an interface when e.g. the removal of a network interface causes Interface Indexes to change" ? >> Maybe in the corresponding "bullet"? Or right after the paragraph that >> says "Including the SLAAC prefix in the PRF computation causes the..."? >> > > The latter would be preferable, but it raises another question. If > there is discussion on input values changing in section 3, the text on > the impact of DAD_Counter changes in section 4 should probably be moved > to section 3. Me, I have no objections against that. I should note that DAD_Counter is described in Section 4 because that section is the subject of a whole topic. I guess we have two options: 1) Add a small sentence pointing to Section 4, or, 2) Move Section 4 into Section 3. I'd probably go with 1), but wouldn't bother doing 2). -- Please pick one, and I'll apply it. >>> * What are the assumptions on this algorithm with respect to multi-homed >>> devices that could have different network interfaces available to attach >>> to the same network? For example, if I have a quad-port network card, I >>> could attach to a network via eth0 and get an identifier for prefix X. >>> The next time I attach to that network, I use eth2 and I will not get >>> the same identifier even though I still get a PIO containing prefix X. >>> This issue directly contradicts design goal #1. >> >> This algorithm aims to produce stable addresses for each interface. SO >> as long as the same interface gets the same addresses, the algorithm is >> achieving it's goal. >> > > Then something needs to be said in the document about this limitation. > This approach does not create stable addresses *per prefix*. This is my rationale: The internet architecture has no concept/namespace for "node". So, from a practical point of view, different network interfaces all look like different nodes (in the same way that you cannot use any of your addresses for the same TCP connection, etc.). That aside, you could also have the case where the same node connects to the same network with two NICs, at the same time. In such scenario, you're forced to have each NIC get a different IPv6 address. -- In a scenario such as this, each NIC will get the same address (both in this case and also when the node connects to that network with a single interface). So I'd argue that this is a desired property, rather than a drawback. >>> 3. I think it would be good to explicitly state that this IID generation >>> mechanism is incrementally deployable since there are no >>> interoperability issues with IID generation. >> >> Good point. >> >> How about adding this to the Intro, right after the para that starts >> with "This document specifies a method to generate interface >> identifiers...": >> >> "We note that this method is is incrementally deployable, since it >> doesn't pose any interoperability implications when deployed on networks >> where other nodes do not implement or employ it". >> >> ? > > The above is fine as long as you remove the redundant "is". Great. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian@innovationslab.net Wed Apr 10 15:02:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED34421F8E94 for ; Wed, 10 Apr 2013 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DTnbWYZKnRm for ; Wed, 10 Apr 2013 15:01:59 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C756121F8E79 for ; Wed, 10 Apr 2013 15:01:59 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BE8C68810A; Wed, 10 Apr 2013 15:01:59 -0700 (PDT) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 213EE14000C; Wed, 10 Apr 2013 15:01:59 -0700 (PDT) Message-ID: <5165E156.5070202@innovationslab.net> Date: Wed, 10 Apr 2013 18:01:58 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fernando Gont Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> <5164C303.1090209@si6networks.com> In-Reply-To: <5164C303.1090209@si6networks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 22:02:01 -0000 On 4/9/13 9:40 PM, Fernando Gont wrote: > Hi, Brian, > > On 04/09/2013 12:21 PM, Brian Haberman wrote: >>> On 04/08/2013 11:46 AM, Brian Haberman wrote: >>>> 1. Section 1 : I understand that the fourth paragraph is indented since >>>> it is quoting from another document. I do not see why the fifth >>>> paragraph is indented. The same confusion exists for the second >>>> paragraph of Section 3. >>> >>> Indented ṕararagraphs, unless otherwise noted, are parenthetical notes, >>> rather than quotes from other documents (i.e., text that provides >>> additional information, but that you may skip reading if you want). >> >> We have had this discussion before... I am not a fan of these >> parenthetical notes, but to each his own. > > I wasn't arguing in favor of them, but rather explaining what they were. > (FWIW, these notes predate our "discussion" on the subject... and, in > all fairness, you're not the first one to not like them :-) ). > > I'll try to incorporate them into the main body -- fwiw, the reason for > which I including those paragraphs as such (parenthetical notes), is so > that the reader that is not interested in those details can easily skip > them. > > >>> HOw about the following text: >>> >>> "The Interface Index is expected to remain constant across system >>> reboots and other events. However, we note that it might change upon >>> removal of a network interface (typically one with a smaller value for >>> the Interface Index, when such naming scheme is used). When such >>> Interface Index changes occur, the IPv6 addresses resulting from this >>> algorithm for an interface index is likely to change, thus affecting the >>> stability property of this approach. We note that we expect these >>> scenarios to be unusual." >> >> I don't like "likely to change". > > Yep, that was stupid -- how about s/for an interface index is likely to > change/for an interface will change/? > That should be fine. > >> Additionally, I will note that this scenario may not be as unusual as >> you think. For example, the ifIndex on some Cisco gear will change >> enough that IOS has a configuration command to make it stable. > > what's the "event" upon which the interface index will change? > "Interface removal", as in the suggested text, or something else? My understanding is that some devices assign an ifIndex when the device is activated (e.g., at boot time). Since device activation is non-deterministic, an interface can get assigned a different ifIndex each time it boots. To deal with this behavior, IOS has a "persist" command that keeps state about each interfaces initial ifIndex. > > If that's the case, I'd not expect that to happen frequently -- and even > less for hosts/servers doing SLAAC (those routers are more likely using > statically-configured addresses). See above. I am not sure to what extent other platforms have a similar issue. > > Anyway... should I add something along this lines of: > "Some implementations are known to provide configuration knobs to set > the Interface Index for a given interface. This could be leveraged to > prevent maintain the same Interface Index for an interface when e.g. the > removal of a network interface causes Interface Indexes to change" > > ? > That should be sufficient. > >>> Maybe in the corresponding "bullet"? Or right after the paragraph that >>> says "Including the SLAAC prefix in the PRF computation causes the..."? >>> >> >> The latter would be preferable, but it raises another question. If >> there is discussion on input values changing in section 3, the text on >> the impact of DAD_Counter changes in section 4 should probably be moved >> to section 3. > > Me, I have no objections against that. I should note that DAD_Counter is > described in Section 4 because that section is the subject of a whole > topic. I guess we have two options: > > 1) Add a small sentence pointing to Section 4, or, > 2) Move Section 4 into Section 3. > > I'd probably go with 1), but wouldn't bother doing 2). -- Please pick > one, and I'll apply it. > Option (1) should be fine as long as that sentence in section 3 raises awareness that DAD_Counter can change. > >>>> * What are the assumptions on this algorithm with respect to multi-homed >>>> devices that could have different network interfaces available to attach >>>> to the same network? For example, if I have a quad-port network card, I >>>> could attach to a network via eth0 and get an identifier for prefix X. >>>> The next time I attach to that network, I use eth2 and I will not get >>>> the same identifier even though I still get a PIO containing prefix X. >>>> This issue directly contradicts design goal #1. >>> >>> This algorithm aims to produce stable addresses for each interface. SO >>> as long as the same interface gets the same addresses, the algorithm is >>> achieving it's goal. >>> >> >> Then something needs to be said in the document about this limitation. >> This approach does not create stable addresses *per prefix*. > > This is my rationale: > The internet architecture has no concept/namespace for "node". So, from > a practical point of view, different network interfaces all look like > different nodes (in the same way that you cannot use any of your > addresses for the same TCP connection, etc.). > > That aside, you could also have the case where the same node connects to > the same network with two NICs, at the same time. In such scenario, > you're forced to have each NIC get a different IPv6 address. -- In a > scenario such as this, each NIC will get the same address (both in this > case and also when the node connects to that network with a single > interface). Whoa... If two NICs on the same system connect to the same link, they can't get the same address. Those two interfaces *should* have different ifIndex values being fed into the PRF. My comment above was meant to simply point out that these addresses are per prefix/interface combination. That's all. Regards, Brian > > So I'd argue that this is a desired property, rather than a drawback. > > >>>> 3. I think it would be good to explicitly state that this IID generation >>>> mechanism is incrementally deployable since there are no >>>> interoperability issues with IID generation. >>> >>> Good point. >>> >>> How about adding this to the Intro, right after the para that starts >>> with "This document specifies a method to generate interface >>> identifiers...": >>> >>> "We note that this method is is incrementally deployable, since it >>> doesn't pose any interoperability implications when deployed on networks >>> where other nodes do not implement or employ it". >>> >>> ? >> >> The above is fine as long as you remove the redundant "is". > > Great. > > Thanks! > > Best regards, > From fernando@gont.com.ar Thu Apr 11 02:23:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34D321F8E9A for ; Thu, 11 Apr 2013 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12KDOc+yUKvI for ; Thu, 11 Apr 2013 02:22:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4E66B21F8E96 for ; Thu, 11 Apr 2013 02:22:55 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UQDiM-0003H7-0k; Thu, 11 Apr 2013 11:22:48 +0200 Message-ID: <5166661F.9010909@gont.com.ar> Date: Thu, 11 Apr 2013 04:28:31 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian Haberman Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> <5164C303.1090209@si6networks.com> <5165E156.5070202@innovationslab.net> In-Reply-To: <5165E156.5070202@innovationslab.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Fernando Gont , 6man WG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 09:23:12 -0000 Hi, Brian, On 04/10/2013 07:01 PM, Brian Haberman wrote: >>> Additionally, I will note that this scenario may not be as unusual as >>> you think. For example, the ifIndex on some Cisco gear will change >>> enough that IOS has a configuration command to make it stable. >> >> what's the "event" upon which the interface index will change? >> "Interface removal", as in the suggested text, or something else? > > My understanding is that some devices assign an ifIndex when the device > is activated (e.g., at boot time). Since device activation is > non-deterministic, an interface can get assigned a different ifIndex > each time it boots. To deal with this behavior, IOS has a "persist" > command that keeps state about each interfaces initial ifIndex. I've not experienced that myself. That said, I'd probably argue that such changes are probably annoying for there reasons: I guess that if the interface index changes, so does the usual suffix in the interface name (e.g. ethN, wlanN) -- hence delaying with link-local addresses would become more painful than necessary. >> If that's the case, I'd not expect that to happen frequently -- and even >> less for hosts/servers doing SLAAC (those routers are more likely using >> statically-configured addresses). > > See above. I am not sure to what extent other platforms have a similar > issue. I've not experienced this in Windows, *BSD, or Linux, at least. >>>> Maybe in the corresponding "bullet"? Or right after the paragraph that >>>> says "Including the SLAAC prefix in the PRF computation causes the..."? >>>> >>> >>> The latter would be preferable, but it raises another question. If >>> there is discussion on input values changing in section 3, the text on >>> the impact of DAD_Counter changes in section 4 should probably be moved >>> to section 3. >> >> Me, I have no objections against that. I should note that DAD_Counter is >> described in Section 4 because that section is the subject of a whole >> topic. I guess we have two options: >> >> 1) Add a small sentence pointing to Section 4, or, >> 2) Move Section 4 into Section 3. >> >> I'd probably go with 1), but wouldn't bother doing 2). -- Please pick >> one, and I'll apply it. > > Option (1) should be fine as long as that sentence in section 3 raises > awareness that DAD_Counter can change. Done. >>> Then something needs to be said in the document about this limitation. >>> This approach does not create stable addresses *per prefix*. >> >> This is my rationale: >> The internet architecture has no concept/namespace for "node". So, from >> a practical point of view, different network interfaces all look like >> different nodes (in the same way that you cannot use any of your >> addresses for the same TCP connection, etc.). >> >> That aside, you could also have the case where the same node connects to >> the same network with two NICs, at the same time. In such scenario, >> you're forced to have each NIC get a different IPv6 address. -- In a >> scenario such as this, each NIC will get the same address (both in this >> case and also when the node connects to that network with a single >> interface). > > Whoa... If two NICs on the same system connect to the same link, they > can't get the same address. Those two interfaces *should* have > different ifIndex values being fed into the PRF. Exactly. my pint was that this is the very reason for which one cannot expect two different NICs to get the same IPv6 addresses when they connect (separately) to the same network. > My comment above was meant to simply point out that these addresses are > per prefix/interface combination. That's all. Agreed. Should I tweak the document n any way regarding this? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian@innovationslab.net Thu Apr 11 07:42:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3221F8EFD for ; Thu, 11 Apr 2013 07:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShRgIf3u-DyO for ; Thu, 11 Apr 2013 07:42:53 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id E613021F87D2 for ; Thu, 11 Apr 2013 07:42:53 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D85FD8812C; Thu, 11 Apr 2013 07:42:53 -0700 (PDT) Received: from clemson.wireless.jhu.edu (unknown [128.220.159.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 59E9A14000C; Thu, 11 Apr 2013 07:42:53 -0700 (PDT) Message-ID: <5166CBEC.80502@innovationslab.net> Date: Thu, 11 Apr 2013 10:42:52 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fernando Gont Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> <5164C303.1090209@si6networks.com> <5165E156.5070202@innovationslab.net> <5166661F.9010909@gont.com.ar> In-Reply-To: <5166661F.9010909@gont.com.ar> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Fernando Gont , 6man WG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:42:54 -0000 On 4/11/13 3:28 AM, Fernando Gont wrote: >>> That aside, you could also have the case where the same node connects to >>> the same network with two NICs, at the same time. In such scenario, >>> you're forced to have each NIC get a different IPv6 address. -- In a >>> scenario such as this, each NIC will get the same address (both in this >>> case and also when the node connects to that network with a single >>> interface). >> >> Whoa... If two NICs on the same system connect to the same link, they >> can't get the same address. Those two interfaces *should* have >> different ifIndex values being fed into the PRF. > > Exactly. my pint was that this is the very reason for which one cannot > expect two different NICs to get the same IPv6 addresses when they > connect (separately) to the same network. > > >> My comment above was meant to simply point out that these addresses are >> per prefix/interface combination. That's all. > > Agreed. Should I tweak the document n any way regarding this? > I think it would be useful to add a sentence or two that points out that the generated address could be different *for the same prefix* if the device connects over a different physical interface. Regards, Brian From markzzzsmith@yahoo.com.au Thu Apr 11 13:04:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA4921F8AB2 for ; Thu, 11 Apr 2013 13:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK7ATBQ+4SqU for ; Thu, 11 Apr 2013 13:04:36 -0700 (PDT) Received: from nm37-vm5.bullet.mail.bf1.yahoo.com (nm37-vm5.bullet.mail.bf1.yahoo.com [72.30.238.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5621F89D3 for ; Thu, 11 Apr 2013 13:04:36 -0700 (PDT) Received: from [98.139.212.151] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 11 Apr 2013 20:04:35 -0000 Received: from [98.139.212.225] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Apr 2013 20:04:35 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 11 Apr 2013 20:04:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 846294.7236.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 22617 invoked by uid 60001); 11 Apr 2013 20:04:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1365710675; bh=NPicspV6WlDIEabKE7nwz9WChtjew527F2H54e1GCSk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Pdb/yOy3lJTbVVw7ud/R0jgrp2MpSsvWY+D+DfKu40RGzT/CdrkUPhrNQOLNIZ+ovM9R+XeXiO8hfECGm7baGIoeD60P8LxE9Tc9qSlwQuV7lzKz+6BUyf0jOLb1XFpipnQ5gjVQ/koFPpl4LrrlOxH/XwHnn6/KdR9xYezBKlw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ICRq/RAM/R1EvB486sa5N6sY5asdvApogxIFD+D1Rrxkc0O+HIemFfE6W894ZKsk8e6c3GQ1Sguv1SI2R0S3dr5CQC+eslOjBEZBcMZ4rmjXLMIY68u1kfSzqcx636X7nebdvXG6h3wb/NPcdPC4XPIFloXdZGOtJBhM5BuzVOg=; X-YMail-OSG: pKJYL.YVM1mWKp40Ly.145vr6eE6VIThK_dOcacDZnn83oa abbYvb8aNlwzOGed5UU1z Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Thu, 11 Apr 2013 13:04:35 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPgo.VG86IEJyaWFuIEhhYmVybWFuIDxicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ.IAo.Q2M6IDZtYW4gQ2hhaXJzIDw2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc.OyBkcmFmdC1pZXRmLTZtYW4tc3RhYmxlLXByaXZhY3ktYWRkcmVzc2VzQHRvb2wBMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> <5164C303.1090209@si6networks.com> <5165E156.5070202@innovationslab.net> <5166661F.9010909@gont.com.ar> Message-ID: <1365710675.22071.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Thu, 11 Apr 2013 13:04:35 -0700 (PDT) From: Mark Smith Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses To: Fernando Gont , Brian Haberman In-Reply-To: <5166661F.9010909@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Fernando Gont , 6man WG , "draft-ietf-6man-stable-privacy-addresses@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 20:04:37 -0000 Hi,=0A=0A=0A=0A>________________________________=0A> From: Fernando Gont =0A>To: Brian Haberman =0A>C= c: 6man Chairs <6man-chairs@tools.ietf.org>; Fernando Gont ; 6man WG ; draft-ietf-6man-stable-privacy-addresses@= tools.ietf.org =0A>Sent: Thursday, 11 April 2013 5:28 PM=0A>Subject: Re: AD= Evaluation: draft-ietf-6man-stable-privacy-addresses=0A> =0A>=0A>Hi, Brian= ,=0A>=0A>On 04/10/2013 07:01 PM, Brian Haberman wrote:=0A>>>> Additionally,= I will note that this scenario may not be as unusual as=0A>>>> you think.= =A0 For example, the ifIndex on some Cisco gear will change=0A>>>> enough t= hat IOS has a configuration command to make it stable.=0A>>>=0A>>> what's t= he "event" upon which the interface index will change?=0A>>> "Interface rem= oval", as in the suggested text, or something else?=0A>> =0A>> My understan= ding is that some devices assign an ifIndex when the device=0A>> is activat= ed (e.g., at boot time).=A0 Since device activation is=0A>> non-determinist= ic, an interface can get assigned a different ifIndex=0A>> each time it boo= ts.=A0 To deal with this behavior, IOS has a "persist"=0A>> command that ke= eps state about each interfaces initial ifIndex.=0A>=0A>I've not experience= d that myself. That said, I'd probably argue that=0A>such changes are proba= bly annoying for there reasons: I guess that if=0A>the interface index chan= ges, so does the usual suffix in the interface=0A>name (e.g. ethN, wlanN) -= - hence delaying with link-local addresses=0A>would become more painful tha= n necessary.=0A>=0A>=0A>A number of years ago this happened with Linux. IIR= C, it was related to changing the default order of device driver loading, o= r changing from sequential loading of device drivers to parallel loading. T= hat reordered the interface numbering and therefore the names, which people= didn't like. The solution at the time was to use the interface MAC address= to assign interfaces persistent names by renaming the interfaces late in t= he initialisation stage. I don't remember reference to resetting ifindexes.= =A0=0A>=0A>=0A>One thing that may also influence this draft is that interf= aces may be added to the system after it has booted. For example, I carry a= round a couple of USB/Ethernet adaptors that I'll add to my laptop if I nee= d them for troubleshooting (and with my new laptop being wifi only, just to= connect to a wired network), and I may not know if I'll need them when I b= oot my laptop. I also have a 3G mobile dongle that I occasionally use. I'm = pretty sure Linux allocates ifindex values sequentially as the driver is lo= aded, so what ifindex values these dynamic interfaces gets is not going to = be consistent and persistent.=0A>=0A>Regards,=0A>Mark. From fgont@si6networks.com Thu Apr 11 19:36:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6B21F8689 for ; Thu, 11 Apr 2013 19:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk9c7rZ2cm3z for ; Thu, 11 Apr 2013 19:36:36 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 90EF921F8675 for ; Thu, 11 Apr 2013 19:36:36 -0700 (PDT) Received: from [186.134.20.234] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UQTqj-0004dt-TQ; Fri, 12 Apr 2013 04:36:26 +0200 Message-ID: <51677320.7090505@si6networks.com> Date: Thu, 11 Apr 2013 23:36:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian Haberman Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> <5164C303.1090209@si6networks.com> <5165E156.5070202@innovationslab.net> <5166661F.9010909@gont.com.ar> <5166CBEC.80502@innovationslab.net> In-Reply-To: <5166CBEC.80502@innovationslab.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 02:36:37 -0000 On 04/11/2013 11:42 AM, Brian Haberman wrote: >>> My comment above was meant to simply point out that these addresses are >>> per prefix/interface combination. That's all. >> >> Agreed. Should I tweak the document n any way regarding this? > > I think it would be useful to add a sentence or two that points out that > the generated address could be different *for the same prefix* if the > device connects over a different physical interface. I did a minor tweak in the Intro, which notes this. I've posted a rev that hopefully addresses all your comments -- so this one would be ready to ship. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Thu Apr 11 19:37:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4412121F86B7; Thu, 11 Apr 2013 19:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II2y0ea4RIMe; Thu, 11 Apr 2013 19:37:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E6221F83DF; Thu, 11 Apr 2013 19:37:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130412023721.3495.77254.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2013 19:37:21 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 02:37:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : A method for Generating Stable Privacy-Enhanced Addresse= s with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-06.txt Pages : 18 Date : 2013-04-11 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Fri Apr 12 01:44:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB6D21F8D82 for ; Fri, 12 Apr 2013 01:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pOvAnKhbjVC for ; Fri, 12 Apr 2013 01:44:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7113121F8D86 for ; Fri, 12 Apr 2013 01:44:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4C690264483 for ; Fri, 12 Apr 2013 10:44:36 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 25FE34C066 for ; Fri, 12 Apr 2013 10:44:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 12 Apr 2013 10:44:36 +0200 From: To: "ipv6@ietf.org" Date: Fri, 12 Apr 2013 10:44:35 +0200 Subject: RE: I-D Action: draft-ietf-6man-multicast-addr-arch-update-00.txt Thread-Topic: I-D Action: draft-ietf-6man-multicast-addr-arch-update-00.txt Thread-Index: Ac40ZQ25g5mzUkC8TQuytGvV7wnoIgC8kUdA Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7BFB6@PUEXCB1B.nanterre.francetelecom.fr> References: <20130408142606.2321.6821.idtracker@ietfa.amsl.com> In-Reply-To: <20130408142606.2321.6821.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 08:44:38 -0000 Dear all, The content of draft-ietf-6man-multicast-addr-arch-update-00 is the same as= what we had in draft-boucadair-*.=20 We would like to prepare a new version. If you have any comment, suggestion= , etc., please share it on the list or direct you mail to Stig an myself. Thanks. Cheers, Med >-----Message d'origine----- >De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] >De la part de internet-drafts@ietf.org >Envoy=E9=A0: lundi 8 avril 2013 16:26 >=C0=A0: i-d-announce@ietf.org >Cc=A0: ipv6@ietf.org >Objet=A0: I-D Action: draft-ietf-6man-multicast-addr-arch-update-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IPv6 Maintenance Working Group of the >IETF. > > Title : Updates to the IPv6 Multicast Addressing >Architecture > Author(s) : Mohamed Boucadair > Stig Venaas > Filename : draft-ietf-6man-multicast-addr-arch-update-00.txt > Pages : 5 > Date : 2013-04-08 > >Abstract: > This document updates the IPv6 multicast addressing architecture by > defining the 17-20 reserved bits as generic flag bits. The document > provides also some clarifications related to the use of these flag > bits. > > This document updates RFC 3956, RFC 3306, RFC 4607 and RFC 4291. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-updat= e > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-00 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From brian@innovationslab.net Fri Apr 12 06:52:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA01821F8A85 for ; Fri, 12 Apr 2013 06:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rOQpHwlzF+R for ; Fri, 12 Apr 2013 06:52:03 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70821F8A3F for ; Fri, 12 Apr 2013 06:52:02 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 42FA188110 for ; Fri, 12 Apr 2013 06:52:02 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0E8D414000C for ; Fri, 12 Apr 2013 06:52:01 -0700 (PDT) Message-ID: <51681182.9000303@innovationslab.net> Date: Fri, 12 Apr 2013 09:52:02 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-dad-proxy-07.txt References: <20130409174845.2651.57733.idtracker@ietfa.amsl.com> <1365545491.28058.311.camel@karl> In-Reply-To: <1365545491.28058.311.camel@karl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:52:04 -0000 Hi Karl, On 4/9/13 6:11 PM, Karl Auer wrote: > On Tue, 2013-04-09 at 10:48 -0700, internet-drafts@ietf.org wrote: >> Abstract: >> The document describes a proxy based mechanism [...] >> Based on the DAD signalling, the first hop router >> stores in a Binding Table all known IPv6 addresses used on a point- >> to-multipoint domain (e.g. VLAN). When a node performs DAD for an >> address already used by another node, the first hop router replies >> instead of this last one. > > Coming late to this but - DAD NS frames are sent to solicited node > multicast addresses, so how is the first hop router seeing them? > IPv6-aware (MLD snooping) switches won't forward the DAD NS frames > except to members of the SNM group...? > > What am I missing? The proxy would have to maintain a list of nodes being proxied. In that case, the proxy can join the solicited-node multicast address for those nodes. Regards, Brian From iesg-secretary@ietf.org Fri Apr 12 08:34:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A994021F8C69; Fri, 12 Apr 2013 08:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+PyUt11pi2R; Fri, 12 Apr 2013 08:34:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0614421F8A91; Fri, 12 Apr 2013 08:34:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 08:34:53 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:34:55 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri Apr 12 08:34:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BABB21F8D28 for ; Fri, 12 Apr 2013 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH5pcHFznoDT; Fri, 12 Apr 2013 08:34:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2275221F8B65; Fri, 12 Apr 2013 08:34:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA Subject: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-6man-stable-privacy-addresses X-IETF-Draft-revision: 06 Message-ID: <20130412153454.14361.49100.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 08:34:54 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:34:55 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri Apr 12 09:13:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E6921F8EB5; Fri, 12 Apr 2013 09:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np3lyZl+SLta; Fri, 12 Apr 2013 09:13:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE45321F8EBE; Fri, 12 Apr 2013 09:13:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Duplicate Address Detection Proxy' to Proposed Standard (draft-ietf-6man-dad-proxy-07.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130412161324.7236.74335.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 09:13:24 -0700 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:13:26 -0000 The IESG has approved the following document: - 'Duplicate Address Detection Proxy' (draft-ietf-6man-dad-proxy-07.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ Technical Summary The document describes a proxy based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. Working Group Summary The working group has reviewed and discussed this draft, feel it solves a relevant problem, and supports it becoming a standard. Document Quality This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Personnel Bob Hinden is the Document Shepherd. Brian Haberman is the Responsible Area Director. RFC Editor Note OLD: When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. NEW: When a node performs DAD for an address already used by another node, the first hop router defends the address rather than the device using the address. From iesg-secretary@ietf.org Fri Apr 12 09:13:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1321F8EB7 for ; Fri, 12 Apr 2013 09:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSfn9z0wGg5l; Fri, 12 Apr 2013 09:13:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0612421F8ECC; Fri, 12 Apr 2013 09:13:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA Subject: Protocol Action: 'Duplicate Address Detection Proxy' to Proposed Standard (draft-ietf-6man-dad-proxy-07.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-6man-dad-proxy X-IETF-Draft-revision: 07 Message-ID: <20130412161324.7236.92587.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 09:13:24 -0700 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:13:26 -0000 The IESG has approved the following document: - 'Duplicate Address Detection Proxy' (draft-ietf-6man-dad-proxy-07.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ Technical Summary The document describes a proxy based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. Working Group Summary The working group has reviewed and discussed this draft, feel it solves a relevant problem, and supports it becoming a standard. Document Quality This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Personnel Bob Hinden is the Document Shepherd. Brian Haberman is the Responsible Area Director. RFC Editor Note OLD: When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. NEW: When a node performs DAD for an address already used by another node, the first hop router defends the address rather than the device using the address. From kauer@biplane.com.au Fri Apr 12 16:01:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8F21F8EB7 for ; Fri, 12 Apr 2013 16:01:09 -0700 (PDT) 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=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcLTKspCEXNJ for ; Fri, 12 Apr 2013 16:01:09 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7321F8E9E for ; Fri, 12 Apr 2013 16:01:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAGeRaFGWZX+7/2dsb2JhbAANQ4M8RMEggSKDEwEBAQSBCQsYLlcZiBupJZM5jx4WgysDiEuPWIpXiDY Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 13 Apr 2013 08:31:06 +0930 Message-ID: <1365807664.3293.250.camel@karl> Subject: Re: I-D Action: draft-ietf-6man-dad-proxy-07.txt From: Karl Auer To: ipv6@ietf.org Date: Sat, 13 Apr 2013 09:01:04 +1000 In-Reply-To: <51681182.9000303@innovationslab.net> References: <20130409174845.2651.57733.idtracker@ietfa.amsl.com> <1365545491.28058.311.camel@karl> <51681182.9000303@innovationslab.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 23:01:10 -0000 On Fri, 2013-04-12 at 09:52 -0400, Brian Haberman wrote: > > Coming late to this but - DAD NS frames are sent to solicited node > > multicast addresses, so how is the first hop router seeing them? > > What am I missing? > > The proxy would have to maintain a list of nodes being proxied. In that > case, the proxy can join the solicited-node multicast address for those > nodes. I'm still missing something then. How does the BNG build the list? I just re-read the draft and can see no mechanisms mentioned except snooping on DAD (which won't work except unless the proxy is already listening on the relevant SNMA) and unsolicited NAs. Nor is there any statement in the draft (for example in the "data structures" section, 4.1) that the proxy should join any solicited node multicast groups. Solicited node multicast addresses are mentioned in only two places: In section 3.1, which describes DAD in a misleadingly rather vague way under the circumstances (DAD packets go to "other nodes on the same link"), and in section 4.2.2 only in a negative sense (a case where a packet "other than a solicited Neighbor Advertisement" is received). Apologies if I'm missing something really obvious. Humbly asking for enlightenment :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From fgont@si6networks.com Fri Apr 12 21:01:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3725921F8E5C for ; Fri, 12 Apr 2013 21:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9yGIZ2uo8lq for ; Fri, 12 Apr 2013 21:01:18 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9144221F8E5A for ; Fri, 12 Apr 2013 21:01:18 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UQre1-0000eo-V0; Sat, 13 Apr 2013 06:01:07 +0200 Message-ID: <5168D85F.5010703@si6networks.com> Date: Sat, 13 Apr 2013 01:00:31 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Smith Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> <5164C303.1090209@si6networks.com> <5165E156.5070202@innovationslab.net> <5166661F.9010909@gont.com.ar> <1365710675.22071.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1365710675.22071.YahooMailNeo@web142506.mail.bf1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Brian Haberman , 6man WG , Fernando Gont , "draft-ietf-6man-stable-privacy-addresses@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 04:01:19 -0000 Hi, Mark, On 04/11/2013 05:04 PM, Mark Smith wrote: >> A number of years ago this happened with Linux. IIRC, it was >> related to changing the default order of device driver loading, or >> changing from sequential loading of device drivers to parallel >> loading. That reordered the interface numbering and therefore the >> names, which people didn't like. It's not surprising that people didn't like it :-) -- e.g., if you have per-interface fw rules, this breaks everything. > The solution at the time was to >> use the interface MAC address to assign interfaces persistent names >> by renaming the interfaces late in the initialisation stage. mm.. not sure hat you mean... >> One thing that may also influence this draft is that interfaces may >> be added to the system after it has booted. For example, I carry >> around a couple of USB/Ethernet adaptors that I'll add to my laptop >> if I need them for troubleshooting (and with my new laptop being >> wifi only, just to connect to a wired network), and I may not know >> if I'll need them when I boot my laptop. Well, if you add the card once the device has been bootstrapped, that shouldn't break the sequence of IID -- i.e., the USB/Ethernet adaptor would get an IfInndex that is larger than all existing IfIndexes... >> I also have a 3G mobile >> dongle that I occasionally use. I'm pretty sure Linux allocates >> ifindex values sequentially as the driver is loaded, so what >> ifindex values these dynamic interfaces gets is not going to be >> consistent and persistent. If you always connect these cards in the same sequence, why shouldn't them? P.S.: In any case, I've tweaked the I-D to essentially say that "the IfIndex might change if network interfaces are installed or removed". Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jeanmichel.combes@gmail.com Mon Apr 15 04:30:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6180421F936D for ; Mon, 15 Apr 2013 04:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMSceIfAbq-z for ; Mon, 15 Apr 2013 04:30:54 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD4F21F934C for ; Mon, 15 Apr 2013 04:30:54 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so1430929wgh.1 for ; Mon, 15 Apr 2013 04:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tLDzFpH5BwX0uRZNM/4EuxOEsREVrEx+7TJYvfUtVhI=; b=f9tSCVm+0kvrDLqoIq2IPLJslvwu4j0xuHO9St2HmvlSLFC6JZdb7XCdIs5syUlT2h D8huw5fHC9ePSDb942b0LA1XZ85oxehLJ2oza/YkHlSR43Ya9XXffHgc8DqqfYlT2sfE V3L8tV/Fqb+CF/bL1vvip6buP6cziBsDZFzNtbc1lbFEACqKG6ot9r4n0vfP+gRWL1iS sStMivSAspGDfG2+fW6SXP/oWLbtZOG/KFAsNe4VV14TuK7LiRy0sTTT6FOEwWX74Pw6 0qjDRn24KxEzz1ShC2wdteXj+UZJ72CZmACSelB6ESS8OmS6NQtuPCEZJAOEyW2upONv TT5g== MIME-Version: 1.0 X-Received: by 10.194.220.37 with SMTP id pt5mr31306208wjc.16.1366025453318; Mon, 15 Apr 2013 04:30:53 -0700 (PDT) Received: by 10.194.234.66 with HTTP; Mon, 15 Apr 2013 04:30:53 -0700 (PDT) In-Reply-To: <1365545491.28058.311.camel@karl> References: <20130409174845.2651.57733.idtracker@ietfa.amsl.com> <1365545491.28058.311.camel@karl> Date: Mon, 15 Apr 2013 13:30:53 +0200 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-dad-proxy-07.txt From: Jean-Michel Combes To: Karl Auer Content-Type: multipart/alternative; boundary=001a11c1b648e63a9404da649501 Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 11:30:55 -0000 --001a11c1b648e63a9404da649501 Content-Type: text/plain; charset=ISO-8859-1 Hi Karl, in a VLAN N:1 architecture with "split-horizon" forwarding scheme, all IP flows are forwarded through the BNG. So, the BNG is able to see them. Best regards, JMC. 2013/4/10 Karl Auer > On Tue, 2013-04-09 at 10:48 -0700, internet-drafts@ietf.org wrote: > > Abstract: > > The document describes a proxy based mechanism [...] > > Based on the DAD signalling, the first hop router > > stores in a Binding Table all known IPv6 addresses used on a point- > > to-multipoint domain (e.g. VLAN). When a node performs DAD for an > > address already used by another node, the first hop router replies > > instead of this last one. > > Coming late to this but - DAD NS frames are sent to solicited node > multicast addresses, so how is the first hop router seeing them? > IPv6-aware (MLD snooping) switches won't forward the DAD NS frames > except to members of the SNM group...? > > What am I missing? > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11c1b648e63a9404da649501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Karl,

in a VLAN N:1 archite= cture with "split-horizon" forwarding scheme, all IP flows are fo= rwarded through the BNG. So, the BNG is able to see them.

Best= regards,

JMC.


2013/4/10 Karl Auer <kauer@biplane.com.au>
=
On Tue, 2013-04-09 at 10:48 -0700, internet-drafts@ietf.org wrote:
> Abstract:
> =A0 =A0The document describes a proxy based mechanism [...]
> =A0 =A0Based on the DAD signalling, the first hop ro= uter
> =A0 =A0stores in a Binding Table all known IPv6 addresses used on a po= int-
> =A0 =A0to-multipoint domain (e.g. =A0VLAN). =A0When a node performs DA= D for an
> =A0 =A0address already used by another node, the first hop router repl= ies
> =A0 =A0instead of this last one.

Coming late to this but - DAD NS frames are sent to solicited node multicast addresses, so how is the first hop router seeing them?
IPv6-aware (MLD snooping) switches won't forward the DAD NS frames
except to members of the SNM group...?

What am I missing?

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au= )
http://www.bi= plane.com.au/kauer
http://twitter.co= m/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--001a11c1b648e63a9404da649501-- From markzzzsmith@yahoo.com.au Wed Apr 17 14:00:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3514A21E80C7 for ; Wed, 17 Apr 2013 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jgein6c-M9gz for ; Wed, 17 Apr 2013 14:00:54 -0700 (PDT) Received: from nm17-vm0.bullet.mail.bf1.yahoo.com (nm17-vm0.bullet.mail.bf1.yahoo.com [98.139.213.157]) by ietfa.amsl.com (Postfix) with SMTP id CB03221E80C8 for ; Wed, 17 Apr 2013 14:00:53 -0700 (PDT) Received: from [98.139.212.150] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 21:00:53 -0000 Received: from [98.139.212.225] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 21:00:53 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 21:00:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 226624.92159.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 26896 invoked by uid 60001); 17 Apr 2013 21:00:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1366232452; bh=0Zxxkd2pnsUHcrsNg4R87qb9LQNgrQkQA9ITwIGo34U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=idw4TRcej4EWLHSr0UC94cuMzY3KP0pXJL7f0xIpDfT2XYGbX7r1Co3IVCAQ+9Oys4JUVsvEmxCzL2GZDnuJdk3JdpM9tpJr5GY9ibepIiu9tmzGN+Yzqw89VrHTSD/J+72tWZVrZO+iHlQ3rRs8IBFyO4JCVVPCQoqWbPaJMe8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=h+shSswzYFU45dj0ZeIeex4M/dE8OVjZA1idfvjRQetaKX82FF8NufjIAOfrX3gohsOZs/0RlUcCimg0PcYM8cyXaCZEZIeb5SfRkyP8wC3/oruulrxdSAAhRD5Kak8VlhmgzWNnZldz2MZMTNiF5yJPz2Oibw0hlSaF44K3x6s=; X-YMail-OSG: 5rgYWJgVM1mPmKRP4AWbazdpy.s2nZgcuJlD9P0aRoi8IYB e_1nf6uTJWoeLLTm4oWwoAAYTg6cKzOu63HgMGIRWr6dYyMeCPrkTrYtvCHh Q6ikjh69fo.1wYBRiXFK2Kdybi5CI31pzD4oDlkZbA2glRbUpNABj0mFgpw3 Hem8fdjmw3838Ej5m4JRQcoxCd0MZkELc0jeF1P5SV2.yHK5LWF8c5f1IFar e.BNw5pheQU07Zs0WnIuoTpRFncmWc9ObIRoyyytEW7c2oYuWrUjrcv.QcZn mOXNSAwZ6rMrrq2NSKKIdcKUM0dEIdrunKfNw17_WYwic_03QOfH0O0WEaSC AnsGxic2R3DMzuLVgsQiGe5I2ObhbsXSUvMyM5gqOU6_SrYTTIFow_9MPR3W AHps8NUfDE12iAJi8LpLiTkJoDQo3yqXiFCZufBxQXJ2fFuSzo_jsReM7OoJ 6xXQLFuDo.VAKBee9CJZgPnQ89Sp546EQJqVqJXJsNss9n0AY2SsLPR_a1BJ am5SoXnWio13mc3ig09MCq0x49lLftwXUST7AlKsicdeGnHbvi5Aa.dKGQol GREqVaPwXIQ_YNr49SVx9j5aNPDu83aVZjt8RgWxiZBLmVNH_4Ci2SO.HOuK P.tSOrlok.BNYNVI7BMXceg-- Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Wed, 17 Apr 2013 14:00:52 PDT X-Rocket-MIMEInfo: 002.001, SGkgRmVybmFuZG8sCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCgo.IEZyb206IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4KPiBUbzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBDYzogRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI.OyBCcmlhbiBIYWJlcm1hbiA8YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PjsgNm1hbiBDaGFpcnMgPDZtYW4tY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz47ICIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <5162D861.5080006@innovationslab.net> <5163B4ED.70207@si6networks.com> <51643205.3000903@innovationslab.net> <5164C303.1090209@si6networks.com> <5165E156.5070202@innovationslab.net> <5166661F.9010909@gont.com.ar> <1365710675.22071.YahooMailNeo@web142506.mail.bf1.yahoo.com> <5168D85F.5010703@si6networks.com> Message-ID: <1366232452.26673.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Wed, 17 Apr 2013 14:00:52 -0700 (PDT) From: Mark Smith Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses To: Fernando Gont In-Reply-To: <5168D85F.5010703@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Brian Haberman , 6man WG , Fernando Gont , "draft-ietf-6man-stable-privacy-addresses@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 21:00:55 -0000 Hi Fernando,=0A=0A----- Original Message -----=0A=0A> From: Fernando Gont <= fgont@si6networks.com>=0A> To: Mark Smith =0A> C= c: Fernando Gont ; Brian Haberman ; 6man Chairs <6man-chairs@tools.ietf.org>; 6man WG ;= "draft-ietf-6man-stable-privacy-addresses@tools.ietf.org" =0A> Sent: Saturday, 13 April 2013= 2:00 PM=0A> Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-add= resses=0A> =0A> Hi, Mark,=0A> =0A> On 04/11/2013 05:04 PM, Mark Smith wrote= :=0A>>> A number of years ago this happened with Linux. IIRC, it was=0A>>>= related to changing the default order of device driver loading, or=0A>>> = changing from sequential loading of device drivers to parallel=0A>>> load= ing. That reordered the interface numbering and therefore the=0A>>> names,= which people didn't like.=0A> =0A> It's not surprising that people didn't = like it :-) -- e.g., if you have=0A> per-interface fw rules, this breaks ev= erything.=0A>=A0=0A=0AI encountered it because I had a box I'd setup for pa= cket capturing with multiple interfaces. The sticky labels on the back of i= t stopped matching up :-(=0A=0A> =0A>> The solution at the time was to=0A>= >> use the interface MAC address to assign interfaces persistent names=0A>= >> by renaming the interfaces late in the initialisation stage.=0A> =0A> m= m.. not sure hat you mean...=0A>=A0=0A=0AThe Linux kernel has an device eve= nt messaging system where kernel events generate messages that can be proce= ssed by user space. Using the "udev" daemon, that can execute various actio= ns and/or scripts. So when a new network interface was added, a rule could = be set to match on it's MAC address. If the MAC address matched, one of the= available actions was to rename the interface. You can see some examples o= f these types of udev rules at:=0A=0Ahttps://wiki.archlinux.org/index.php/N= etwork_Configuration#Udev_rule=0A=0A=0A> =0A> =0A>>> One thing that may al= so influence this draft is that interfaces may=0A>>> be added to the syste= m after it has booted. For example, I carry=0A>>> around a couple of USB/E= thernet adaptors that I'll add to my laptop=0A>>> if I need them for troub= leshooting (and with my new laptop being=0A>>> wifi only, just to connect = to a wired network), and I may not know=0A>>> if I'll need them when I boo= t my laptop.=0A> =0A> Well, if you add the card once the device has been bo= otstrapped, that=0A> shouldn't break the sequence of IID -- i.e., the USB/E= thernet adaptor=0A> would get an IfInndex that is larger than all existing = IfIndexes...=0A>=A0=0A=0ATrue, however the ifindex may not be the same for = that USB/Ethernet adaptor as what it was last time it was installed. It's i= nterface name might be though, because of e.g. the udev system.=0A=0A> =0A>= >> I also have a 3G mobile=0A>>> dongle that I occasionally use. I'm pret= ty sure Linux allocates=0A>>> ifindex values sequentially as the driver is= loaded, so what=0A>>> ifindex values these dynamic interfaces gets is not= going to be=0A>>> consistent and persistent.=0A> =0A> If you always conne= ct these cards in the same sequence, why shouldn't them?=0A>=A0=0A=0AI'd ex= pect them to. Of course I don't always connect them in sequence or connect = them all at once.=0A=0A> P.S.: In any case, I've tweaked the I-D to essenti= ally say that "the=0A> IfIndex might change if network interfaces are insta= lled or removed".=0A>=A0=0A=0AGreat.=0A=0ABest regards,=0AMark.=0A=0A> Than= ks!=0A> =0A> Best regards,=0A> -- =0A> Fernando Gont=0A> SI6 Networks=0A> e= -mail: fgont@si6networks.com=0A> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 = E3C4 AE25 0D55 1D4E 7492=0A> From markzzzsmith@yahoo.com.au Thu Apr 18 02:57:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78A621F8BC5 for ; Thu, 18 Apr 2013 02:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oko2f+YHiSZ for ; Thu, 18 Apr 2013 02:57:49 -0700 (PDT) Received: from nm5.bullet.mail.bf1.yahoo.com (nm5.bullet.mail.bf1.yahoo.com [98.139.212.164]) by ietfa.amsl.com (Postfix) with SMTP id 082A321F8B35 for <6man@ietf.org>; Thu, 18 Apr 2013 02:57:45 -0700 (PDT) Received: from [98.139.212.146] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2013 09:57:45 -0000 Received: from [98.139.212.218] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2013 09:57:45 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 18 Apr 2013 09:57:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 392526.1458.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 96819 invoked by uid 60001); 18 Apr 2013 09:57:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1366279065; bh=kvr11Qmz6ZfFv1ifjzAeEWiu3jn4OHWDD6+npkqVY5s=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VypezaaazeeZkVc+14W335ghKIGZx2N6gE4fEtpF+48rb1sAsIKGFSpIJDkCwFWlYksZXbG3vlCxq3QxNOemU+/j/KFWc/3mqUnQ+wt7yhj+NPVOGqa7ns8aotFd7t8Kw2vU+WEyskeqsRYdJMduChYyTKDrEdSUbe8wyD710GU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D9yrKOGRGVbRNQO36OR8jK5vlMT9732Cz40c3MXZCW2Mwb57pNxfnDua8kD3Inqvt3FpeL7butJUkuT0JH9uuxE5otYKno5JTyD/zcM/12bCmjSJEGkCpdeHj/XqSbRQSCsr7Nkuif6uQiipexvl4/xQRwYeM3IuRGX8mW4ILqY=; X-YMail-OSG: zOb3RewVM1k7dbV2OMg0MiQJXl4e89NFTf_x083AqZODzB. yMoiM7PiqCCA.F_6inyfi5NW_b2B3vmeLCNhxRz.n6_g9UEWhsshRS6j1d0w CLRUA44czdZdHfrSZlmTTbnDY_mpzYlRy8d9ambFeGe3Fx3v.IYLnv1cswYj ylSz8W52EO6_o2Q.7ntGz.B2E0wbyTUmjLuZW10g6ssyu6D7pH86uIKCxKLt oy2jJvg2lRhHLOcteewrIazCwgeNxhZtbJc1O.wlcx.Z3roSDEi6VRJWbZlR yGyirnE2Njpbif1KTSg.1qzcFjEUgSVzzTS56UFEQV6CGNWUmsU0NPbTcj9e N5XsQZkHbE0UhfGle41usIWE9eLsJ.za5gUiHenO2xnfjbt7D5hFjbKVEM1F ONNyU7qTkoJOfTwUbIFGpNp29_iumnxUoRK5JEi7WzrjHhr1eCtmLQcF3lRg WJ7V9Ps429oVn6WUMlsF6nXkCrPu4sKlaV3IXhWnsKEPpbH0NY455g5lV6Ww DjkGmAE4az5b99XeytKDcHARr Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Thu, 18 Apr 2013 02:57:45 PDT X-Rocket-MIMEInfo: 002.001, SGkgUmF5LAoKVmVyeSBzb3JyeSBub3QgdG8gZ2V0IGJhY2sgdG8geW91IHNvb25lci4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBmdXJ0aGVyIHJldmlldyBhbmQgY29tbWVudHMuCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IFJheSBIdW50ZXIgPHY2b3BzQGdsb2Jpcy5uZXQ.Cj4gVG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6ICI2bWFuQGlldGYub3JnIiA8Nm1hbkBpZXRmLm9yZz4KPiBTZW50OiBGcmlkYXksIDI5IE1hcmNoIDIwMTMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <20130220191455.12104.7080.idtracker@ietfa.amsl.com> <1361388340.55779.YahooMailNeo@web142504.mail.bf1.yahoo.com> <515468D2.3050300@globis.net> Message-ID: <1366279065.96525.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 18 Apr 2013 02:57:45 -0700 (PDT) From: Mark Smith Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt To: Ray Hunter In-Reply-To: <515468D2.3050300@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 09:57:50 -0000 Hi Ray,=0A=0AVery sorry not to get back to you sooner. Thank you very much = for your further review and comments.=0A=0A=0A----- Original Message -----= =0A> From: Ray Hunter =0A> To: Mark Smith =0A> Cc: "6man@ietf.org" <6man@ietf.org>=0A> Sent: Friday, 29 M= arch 2013 2:59 AM=0A> Subject: Re: Fw: New Version Notification for draft-s= mith-6man-mitigate-nd-cache-dos-slnd-06.txt=0A> =0A> I have finally got aro= und to giving this draft a proper review. rfc6583=0A> is an important conce= rn for me and my customers.=0A> =0A> IMHO I think the changes that have bee= n made for this version are major=0A> improvements, and that the draft now = does a very good job of describing=0A> a practical trade-off of giving up a= few features of ND in order to=0A> protect against an off-link attack, wit= hout having to change neighboring=0A> implementations.=0A> =0A> One remaini= ng concern is whether the change-over from normal to attack=0A> mode (and b= ack) might not cause problems.=0A>=A0=0A=0AI have incorporated methods to c= ope with receiving Neighbor Advertisments that are received after a switch = from stateful to stateless mode (i.e. update an neighbor cache entry if it = exists), or from stateless mode to stateful mode (have a count down timer t= o accept Neighbor Advertisements for a period after going to stateful mode,= as the Neighbor Solicitation was sent without creating state in stateless = mode.)=0A=0AAre there any other situations that have been missed, or improv= ements in this area that wouldn't require exploitable state?=0A=0A> IMVHO T= he only other option I have seen so far of how this could be=0A> significan= tly improved, whilst still maintaining the advantages of=0A> SLAAC, would b= e to change ND to a registration-type protocol, such as=0A> adopting the mo= del used by 6LoWPAN-ND-Optimization (rfc6775).=0A>=A0=0A=0AAgree. This prop= osal could serve as a mitigation, along with the other methods and improvem= ents mentioned in RFC6583, while a registration protocol is developed and d= eployed.=0A=0AI'll need to find some time to go through your editorial comm= ents in the near future.=0A=0AThanks again for your review and comments. Ve= ry much appreciated.=0A=0A=0ABest regards,=0AMark.=0A=0A> best regards,=0A>= RayH=0A> =0A> =0A> Editorial comments=0A> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=0A> =0A> Section 1.=0A> s/prevent this Neighbor Di= scovery DoS Attack./prevent this Neighbor=0A> Discovery DoS Attack when mou= nted from off-link./=0A> =0A> You reference rfc3756, which is absolutely co= rrect. But rfc6583 provides=0A> additional details and should therefore pro= bably (also) be referenced.=0A> =0A> s/advantage of hosts'/advantage of the= end hosts'/=0A> =0A> This is really for mitigating off-link attacks so I s= uggest 'router'=0A> rather than 'node'? An onlink attack to overflow the st= ate table of the=0A> neighbor presence information for known neighbors was = already possible=0A> (via multicast) and will now also be possible by unica= st during SLNDP,=0A> so that isn't any improvement.=0A> =0A> s/This method = would be used when a node's neighbor presence discovery=0A> state capacity = reaches a medium to high threshold of use, suggesting a=0A> Neighbor Discov= ery DoS Attack is occurring./This method would be used=0A> when a router's = neighbor presence discovery state capacity reaches a=0A> medium to high thr= eshold of use, suggesting a Neighbor Discovery DoS=0A> Attack is occurring.= /=0A> =0A> s/NPD is a worthwhile compromise when a Neighbor Discovery DoS= =0A> Attack/NPD is a worthwhile compromise when a Neighbor Discovery DoS=0A= > Attack appears to be occurring from off-link/=0A> =0A> =0A> s/By making t= he NPD process stateless, hosts and routers would be=0A> protected against = a Neighbor Discovery DoS Attack launched from a host=0A> against itself/=0A= > =0A> I disagree with this statement. An attacker who is on-link or on-hos= t=0A> can still overflow any state table that registers known neighbors wit= h=0A> gratuitous unsolicited entries that are no longer protected from havi= ng=0A> first to have been solicited. The problem of too much state has been= =0A> moved: it hasn't been solved.=0A> =0A> Was the intention to say /By ma= king the NPD process stateful in RFC4861,=0A> hosts and routers are protect= ed against a Neighbor Discovery DoS Attack=0A> launched from a host against= itself, or launched against a local router=0A> or neighboring node/?=0A> = =0A> s/not assured of success./not assured of success, especially when plac= ed=0A> under high load./=0A> =0A> Section 5.1=0A> =0A> s/five variables are= maintained:/=0A> five notional variables are maintained for the purpose of= defining the=0A> algortihm:=0A>

These variables do not have to be made = visible to other nodes, and=0A> are implementation dependent./=0A> =0A> s/I= t is expressed as a percentage/It is expressed as a percentage for=0A> the = purposes of defining the algorithm/=0A> =0A> s/It is a per-interface variab= le/It should be a per-interface variable/=0A> =0A> Section 5.2=0A> s/is for= warded out the link-layer interface to its destination./is=0A> forwarded ou= t the link-layer interface to its destination, as defined in=0A> RFC4861./= =0A> =0A> s/traditional stateful NPD is performed for the packet's=0A> dest= ination./traditional stateful NPD is performed for the packet's=0A> destina= tion, as defined in RFC4861./=0A> =0A> s/The packet is then discarded./The = inbound packet that triggered SLNPD=0A> may then be discarded in order to p= reserve local storage, or it may be=0A> retained in a queue for later trans= mission when the SLNDP process=0A> successfully completes. The queue should= preferably be limited and=0A> reserved for packets that triggered SLNDP./= =0A> =0A> Section 5.3.1=0A> =0A> s//The determination of trust is made base= d on/The determination of=0A> trust could be made based on=0A> =0A> Section= 5.3.1.1.=0A> =0A> s/The source address of the packet that has triggered th= e NPD process=0A> can be used to/The source address of the packet that has = triggered the=0A> NPD process may be used to/=0A> =0A> =0A> Section 5.3.1.1= .1.=0A> Suggest removing the paragraph on ULA. We don't yet truly know how = ULA=0A> will be used.=0A> =0A> =0A> =0A> =0A> Mark Smith wrote:=0A>> Hi,= =0A>> =0A>> Here is a new version of my "Stateless ND" draft, although a = =0A> significant amount of it has changed.=0A>> =0A>> During an off-list d= iscussion with Ray Hunter, I came realise that calling =0A> it "Stateless N= D" was too general, as it implied that all of the ND =0A> functions were be= ing made stateless. I realised that what I was actually =0A> describing was= making the discovery of the presence of neighbors (which I've =0A> called = "Neighbor Presence Discovery") stateless when a ND DoS Attack =0A> appeared= to be occurring. Consequently I needed to rewrite a fair bit of the =0A> t= ext describing the problem.=0A>> =0A>> The other changes are -=0A>> =0A>> = =A0 =A0 o=A0 don't ignore Neighbor Advertisements that may be part of a=0A= >> =A0 =A0 =A0 =A0 previous stateful neighbor discovery transaction=0A>> = =A0 =0A>> =A0 =A0 o=A0 use a count down timer to allow outstanding SLNPD t= ransactions to=0A>> =A0 =A0 =A0 =A0 complete=0A>> =A0 =0A>> =A0 =A0 o=A0 m= ention issues regarding trusting packet attributes=0A>> =0A>> My thanks to= the reviewers. Further review welcome and appreciated.=0A>> =0A>> Regards= ,=0A>> Mark.=0A>> =0A>> =0A>> ----- Forwarded Message -----=0A>>> From: = "internet-drafts@ietf.org" =0A> =0A>>> To: markz= zzsmith@yahoo.com.au=0A>>> Cc: =0A>>> Sent: Thursday, 21 February 2013 6:= 14 AM=0A>>> Subject: New Version Notification for =0A> draft-smith-6man-mi= tigate-nd-cache-dos-slnd-06.txt=0A>>> =0A>>> =0A>>> A new version of I-D, = =0A> draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt=0A>>> has been suc= cessfully submitted by Mark Smith and posted to the=0A>>> IETF repository.= =0A>>> =0A>>> Filename:=A0 =A0 draft-smith-6man-mitigate-nd-cache-dos-sln= d=0A>>> Revision:=A0 =A0 06=0A>>> Title:=A0 =A0 =A0 =A0 Mitigating IPv6= Neighbor Discovery DoS Attack Using =0A> Stateless =0A>>> Neighbor Presen= ce Discovery=0A>>> Creation date:=A0 =A0 2013-02-20=0A>>> Group:=A0 =A0 = =A0 =A0 Individual Submission=0A>>> Number of pages: 14=0A>>> URL:=A0 = =A0 =A0 =A0 =A0 =A0 =0A>>> =0A> http://www.ietf.org/internet-drafts/draft-s= mith-6man-mitigate-nd-cache-dos-slnd-06.txt=0A>>> Status:=A0 =A0 =A0 =A0 = =A0 =0A>>> =0A> http://datatracker.ietf.org/doc/draft-smith-6man-mitigate-n= d-cache-dos-slnd=0A>>> Htmlized:=A0 =A0 =A0 =A0 =0A>>> =0A> http://tools.i= etf.org/html/draft-smith-6man-mitigate-nd-cache-dos-slnd-06=0A>>> Diff:=A0= =A0 =A0 =A0 =A0 =A0 =0A>>> =0A> http://www.ietf.org/rfcdiff?url2=3Daft-smi= th-6man-mitigate-nd-cache-dos-slnd-06=0A>>> =0A>>> Abstract:=0A>>> =A0 =A0= One of the functions of IPv6 Neighbor Discovery is to discover=0A>>> =A0 = =A0 whether a specified neighbor is present.=A0 During the neighbor=0A>>> = =A0 =A0 presence discovery process state is created.=A0 A node's capacity = =0A> for=0A>>> =A0 =A0 this state can be intentionally exhausted to perform= a denial of=0A>>> =A0 =A0 service attack, known as the "Neighbor Discovery= DoS =0A> Attack".=A0 This=0A>>> =A0 =A0 memo proposes a stateless form of = neighbor presence discovery to=0A>>> =A0 =A0 prevent this Neighbor Discover= y DoS Attack.=0A>>> =0A>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =0A> =A0 =A0 =A0 =A0 =0A>>> =A0 =0A>>> =0A>>> =0A>>> = The IETF Secretariat=0A>>> =0A>> =0A> From lear@cisco.com Sun Apr 21 23:20:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4EA21F863B; Sun, 21 Apr 2013 23:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoTY3ldtvZkj; Sun, 21 Apr 2013 23:20:20 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9455F21F8630; Sun, 21 Apr 2013 23:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3556; q=dns/txt; s=iport; t=1366611619; x=1367821219; h=message-id:date:from:mime-version:to:subject; bh=erRVKyMmVdZ0BvYjA1uoZSt2jrb8CRHthL/IJ+0DsI0=; b=f9ePuzyI+H4A6dny9wq7+X0Kq46uneNgd9ycoy9dqVOzWn9COzpFwGv6 FCeZQsTOu64scPEXrLzGMjDZikHLhjYOndh7ZdmxP6xIcCqy5i/QgpXcS cnEsXrWb4XNgs0TvgDntnaam3VP9CE7W5WO7LMVgEoCNe0qI6SvK/BebD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwGADnWdFGQ/khM/2dsb2JhbAAWOYMGg2eFXrh0FnSCSVUaBh0WCwILAwIBAgFLAQwIAQGIEIwyghGbB5FukXqBEwOXFZEagw46 X-IronPort-AV: E=Sophos;i="4.87,524,1363132800"; d="scan'208,217";a="13468483" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 22 Apr 2013 06:20:17 +0000 Received: from ams3-vpn-dhcp5433.cisco.com (ams3-vpn-dhcp5433.cisco.com [10.61.85.56]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3M6KFGJ022230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 06:20:15 GMT Message-ID: <5174D69F.6090300@cisco.com> Date: Mon, 22 Apr 2013 08:20:15 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF Discussion , draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, Bob Hinden , 6man@ietf.org Subject: last call comments for draft-ietf-6man-stable-privacy-addresses-06 X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------030704070505080302060200" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 06:20:21 -0000 This is a multi-part message in MIME format. --------------030704070505080302060200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit In the process of doing the apps area review, I came across some points that were not related to applications. The basis for these comments is precisely the sentiment that Russ Housley expressed, which is that the specification is done when there is no more to remove. With this document, I wonder if quite a bit could be removed. Specifically, a great deal of discussion goes into the PRF involving DAD counters, etc, when all that is needed is a suitable PRF. The draft in fact says this in Section 3 after an explanation of the inputs. Any PRF that follows the guidelines of RFC 4086 should do fine and not cause interoperability OR security problems. Put simply, you are over-specifying the RID and derive no benefit from doing so. Also, the following text in section 3 Page 7 is contorted: This means that this document does not formally obsolete or deprecate any of the existing algorithms to generate Interface IDs (e.g. such as that specified in [RFC2464]). However, those IPv6 implementations that employ this specification must generate all of their "stable" addresses as specified in this document. My suggestion is to simplify remove it as it is self-evident. Finally, this algorithm requires that the resultant host portion be 64 bits. Is that necessary? Eliot --------------030704070505080302060200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

In the process of doing the apps area review, I came across some points that were not related to applications.  The basis for these comments is precisely the sentiment that Russ Housley expressed, which is that the specification is done when there is no more to remove.  With this document, I wonder if quite a bit could be removed.

Specifically, a great deal of discussion goes into the PRF involving DAD counters, etc, when all that is needed is a suitable PRF.  The draft in fact says this in Section 3 after an explanation of the inputs.  Any PRF that follows the guidelines of RFC 4086 should do fine and not cause interoperability OR security problems.  Put simply, you are over-specifying the RID and derive no benefit from doing so.

Also, the following text in section 3 Page 7 is contorted:

      This means that this document does not formally obsolete or
      deprecate any of the existing algorithms to generate Interface IDs
      (e.g. such as that specified in [RFC2464]).  However, those IPv6
      implementations that employ this specification must generate all
      of their "stable" addresses as specified in this document.

My suggestion is to simplify remove it as it is self-evident.

Finally, this algorithm requires that the resultant host portion be 64 bits.  Is that necessary?

Eliot

--------------030704070505080302060200-- From rja.lists@gmail.com Mon Apr 22 06:34:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2347F21F85EB; Mon, 22 Apr 2013 06:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWOLa8nslCuq; Mon, 22 Apr 2013 06:34:29 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1823421F85DB; Mon, 22 Apr 2013 06:34:29 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id w7so677079qeb.17 for ; Mon, 22 Apr 2013 06:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:date:subject :to:message-id:mime-version:x-mailer; bh=1fmZLISU/2RbJBp90NokR6hruDQFJCVLgEYkCYgfPaE=; b=rj2sFocu6QagHrBYaHOjVyNAEtjQn1+hxsPYrAgEGJHzeWdnXa3PJojUFIW1K6ScKT GZvG5eqUtuX+RL0vBuQorIlLEIpwfXnYEErknBzcoQR0JcsRKkPbhqNQa2LhXlAMs1ar v5rW5Dvuv2/HUL5QVX7SVf2HnlvIKGVfU5pow5zUfKwIJnKdQf2h0JuiBS5fMKv58sZp D3GLS2l5fihxjtJ/S4DpkU4E6z6GlUrnaM9fh1Y5IFd1v+gjLmOqdPe+glV2u5FbG9vt oKkmIyNJgl7C8UQ+3eJ/5PDihB9/zjisZHXPuFxm7pyk5A7LA5sMRDic6BMH8F6I8I4S DLEA== X-Received: by 10.224.11.200 with SMTP id u8mr22390522qau.76.1366637668604; Mon, 22 Apr 2013 06:34:28 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id 10sm28246390qax.13.2013.04.22.06.34.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 06:34:28 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Apr 2013 09:34:26 -0400 Subject: last call comments for draft-ietf-6man-stable-privacy-addresses-06 To: ipv6@ietf.org, ietf@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:34:30 -0000 Earlier, Eliot Lear wrote: % Put simply, you are over-specifying the RID=20 % and derive no benefit from doing so. There is benefit to implementers in having a specific example that is known to meet the requirements of this specification. This benefit also accrues to users, as implementers are more likely to correctly implement when giving a specific example that they may reuse. % Also, the following text in section 3 Page 7 is contorted: % %> This means that this document does not formally obsolete or %> deprecate any of the existing algorithms to generate Interface IDs %> (e.g. such as that specified in [RFC2464]).=C2 However, those IPv6 %> implementations that employ this specification must generate all %> of their "stable" addresses as specified in this document. % % My suggestion is to simplify remove it as it is self-evident. It would reduce consensus within the WG and the IETF as a whole to remove that text -- as it clarifies that other mechanisms for generating such IDs are not affected by this specification. Text to this effect was specifically requested by various WG=20 participants, precisely because it is not "self-evident" and=20 instead was confusing. % Finally, this algorithm requires that the resultant host=20 % portion be 64 bits. Is that necessary? Yes, it is required, for technical reasons relating to multiple IPv6-related standards-track RFCs. I oppose Eliot's proposed edits on grounds that they would reduce the clarity of the specification and also would reduce IETF and WG consensus about this specification. Yours, Ran From hartmans@mit.edu Mon Apr 22 06:57:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7248611E80A5; Mon, 22 Apr 2013 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pv7CpKQ0cgO; Mon, 22 Apr 2013 06:57:02 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9B11E809C; Mon, 22 Apr 2013 06:57:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C971E20218; Mon, 22 Apr 2013 09:55:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9CT_VbNWm-M; Mon, 22 Apr 2013 09:55:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 22 Apr 2013 09:55:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2AD8F4499; Mon, 22 Apr 2013 09:56:59 -0400 (EDT) From: Sam Hartman To: RJ Atkinson Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: Date: Mon, 22 Apr 2013 09:56:59 -0400 In-Reply-To: (RJ Atkinson's message of "Mon, 22 Apr 2013 09:34:26 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipv6@ietf.org, ietf@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:57:03 -0000 >>>>> "RJ" == RJ Atkinson writes: RJ> I oppose Eliot's proposed edits on grounds that they would RJ> reduce the clarity of the specification and also would reduce RJ> IETF and WG consensus about this specification. Ran, I just checked, and you don't seem to be a 6man chair. We generally ask chairs, not involved participants to judge WG consensus and ADs to judge IETF consensus. So, I think what you're saying boils down to you disagree with Eliot because you believe his comments would reduce clarity. You believe others within the WG and outside the WG are likely to agree with you. That's all fine and is valuable to contribute. However, I don't think it promotes open and honest technical discussion when participants try to call consensus. Thanks for considering my input. From mrex@sap.com Mon Apr 22 07:32:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7321F90CC; Mon, 22 Apr 2013 07:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqZfd++V91Gx; Mon, 22 Apr 2013 07:32:44 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F721F90BB; Mon, 22 Apr 2013 07:32:44 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r3MEWgTj022777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Apr 2013 16:32:42 +0200 (MEST) Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 In-Reply-To: To: Sam Hartman Date: Mon, 22 Apr 2013 16:32:42 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130422143242.B6C5E1A6C7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out X-Mailman-Approved-At: Mon, 22 Apr 2013 07:47:52 -0700 Cc: ipv6@ietf.org, RJ Atkinson , ietf@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 14:32:45 -0000 Sam Hartman wrote: > > RJ Atkinson writes: > > > RJ> I oppose Eliot's proposed edits on grounds that they would > RJ> reduce the clarity of the specification and also would reduce > RJ> IETF and WG consensus about this specification. > > Ran, I just checked, and you don't seem to be a 6man chair. We > generally ask chairs, not involved participants to judge WG consensus > and ADs to judge IETF consensus. > > So, I think what you're saying boils down to you disagree with Eliot > because you believe his comments would reduce clarity. You believe > others within the WG and outside the WG are likely to agree with you. > That's all fine and is valuable to contribute. > > However, I don't think it promotes open and honest technical discussion > when participants try to call consensus. > Thanks for considering my input. This applies not only to individuals alleging "consensus", but in just the same way to WG chairs, ADs and the IESG to allege "consensus" for a change without performing a consensus call that properly lists options and their tradeoffs. The only exception is, that IETF leadership (WG chairs, AD, IESG) could assert their leadership privilege to make a specific choice. In this case, however, they should label it as such (a leadership decision). For resolving issues that individuals have with leadership decisions, there is the appeals process. -Martin From fgont@si6networks.com Mon Apr 22 09:06:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F61521F9154; Mon, 22 Apr 2013 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K+DDE5wmScR; Mon, 22 Apr 2013 09:06:17 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D4F6521F90A1; Mon, 22 Apr 2013 09:06:13 -0700 (PDT) Received: from [201.157.17.130] (helo=[172.20.4.229]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UUJFn-0001rG-GZ; Mon, 22 Apr 2013 18:06:09 +0200 Message-ID: <51755FE9.9060809@si6networks.com> Date: Mon, 22 Apr 2013 11:06:01 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eliot Lear Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <5174D69F.6090300@cisco.com> In-Reply-To: <5174D69F.6090300@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man@ietf.org, Bob Hinden , IETF Discussion X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:06:17 -0000 Hi, Eliot, On 04/22/2013 01:20 AM, Eliot Lear wrote: > In the process of doing the apps area review, I came across some points > that were not related to applications. The basis for these comments is > precisely the sentiment that Russ Housley expressed, which is that the > specification is done when there is no more to remove. I'd probaby disagree with such statement. One thing is removing tuff from the mechanism or algorithm that you're standardizing, in the hopes of keeping it simple (this one I'd agree with). Another is removing text from specifications, which essentially means that the gut implementing the spec has more to figure out by himself, and hence more chances for failures. > With this > document, I wonder if quite a bit could be removed. > > Specifically, a great deal of discussion goes into the PRF involving DAD > counters, etc, when all that is needed is a suitable PRF. Not sure what you mean...What's thetext that you think could/should be removed? > The draft in > fact says this in Section 3 after an explanation of the inputs. Any PRF > that follows the guidelines of RFC 4086 should do fine and not cause > interoperability OR security problems. If you're referring to the text that explains why we're not mandating any specific PRF, that text is there because the issue was raisen in the wg, > Also, the following text in section 3 Page 7 is contorted: > > This means that this document does not formally obsolete or > deprecate any of the existing algorithms to generate Interface IDs > (e.g. such as that specified in [RFC2464]). However, those IPv6 > implementations that employ this specification must generate all > of their "stable" addresses as specified in this document. > > My suggestion is to simplify remove it as it is self-evident. What's the part that is evident? The one about not deprecating existing algorithms? -- Because the other ne certainly isn't: if you're going to use this algorithm for generating addresses *in addition* to those generated by traditional SLAAC, then this document wouldn't mitigate address-scanning attacks. > Finally, this algorithm requires that the resultant host portion be 64 > bits. Is that necessary? Well, yes- If the PRF produces a bit string larger than 64 bits, and you say nothing about how you grab the IID, then the algorithm is underspecified. The easier it is for a developer to go through this document and come up with an implementation, the better. The more the open questions, the worse. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From lear@cisco.com Mon Apr 22 09:22:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7771621F8FC7; Mon, 22 Apr 2013 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.999 X-Spam-Level: X-Spam-Status: No, score=-110.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxvvym8DNJOI; Mon, 22 Apr 2013 09:22:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A28F021F854E; Mon, 22 Apr 2013 09:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4529; q=dns/txt; s=iport; t=1366647749; x=1367857349; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=suwTD0aVilDPZlmCy+liXde/jU0gjKXbBIo+XYm5oaE=; b=I4+iRL/Ce7bQkhI6bFb4/TKEUBoNqxSUMphJ58F0iGpaPk9TUj2iYshs vhMMjaZXuseTHpSB/x5+/AP0Issn2C8CS55pSnJQWdXJHnTVFPhCjgJmN WOOlcTyCi+1k/pfIRkfsg+iLY8irBwuJSBdYXQ5bD7gIHP3AE6vC3CNRk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAKtidVGQ/khL/2dsb2JhbABPgwaDZ7pngmqBBhZ0gh8BAQEDASNVARALDgoCAgUWCwICCQMCAQIBRQYNAQcBAYgKBqpBkQqBI44cB4I0gRMDlxWRGoMOOg X-IronPort-AV: E=Sophos;i="4.87,527,1363132800"; d="scan'208";a="153145297" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2013 16:22:27 +0000 Received: from ams3-vpn-dhcp5433.cisco.com (ams3-vpn-dhcp5433.cisco.com [10.61.85.56]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3MGMO2s009406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 16:22:25 GMT Message-ID: <517563C0.6000508@cisco.com> Date: Mon, 22 Apr 2013 18:22:24 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fernando Gont Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> In-Reply-To: <51755FE9.9060809@si6networks.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man@ietf.org, Bob Hinden , IETF Discussion X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:22:30 -0000 Hi Fernando, Thanks very much for your response. On 4/22/13 6:06 PM, Fernando Gont wrote: > Hi, Eliot, > > On 04/22/2013 01:20 AM, Eliot Lear wrote: >> In the process of doing the apps area review, I came across some points >> that were not related to applications. The basis for these comments is >> precisely the sentiment that Russ Housley expressed, which is that the >> specification is done when there is no more to remove. > I'd probaby disagree with such statement. One thing is removing tuff > from the mechanism or algorithm that you're standardizing, in the hopes > of keeping it simple (this one I'd agree with). Another is removing text > from specifications, which essentially means that the gut implementing > the spec has more to figure out by himself, and hence more chances for > failures. Fair point, of course. > > >> With this >> document, I wonder if quite a bit could be removed. >> >> Specifically, a great deal of discussion goes into the PRF involving DAD >> counters, etc, when all that is needed is a suitable PRF. > Not sure what you mean...What's thetext that you think could/should be > removed? Sorry I wasn't clear: what is the benefit of specifying the algorithm, when simply popping out another PRF will in just about any instance do the job (unless you are reinitializing the PRF with the same seed)? > > >> The draft in >> fact says this in Section 3 after an explanation of the inputs. Any PRF >> that follows the guidelines of RFC 4086 should do fine and not cause >> interoperability OR security problems. > If you're referring to the text that explains why we're not mandating > any specific PRF, that text is there because the issue was raisen in the wg, Ok. So what I gather is that there was a negotiation within the WG and that the algorithm is optional. Ok. From an outside point of view, I didn't need to know that, and the question is what was the value of still specifying the PRF. I think Ran Atkinson answered that. He feels he wants a fully specified algorithm from which to start. Ok. My only response is that I don't understand the need (generating 64 bits that aren't the same shouldn't be that hard), but if the WG really believes there is one, okay. > > >> Also, the following text in section 3 Page 7 is contorted: >> >> This means that this document does not formally obsolete or >> deprecate any of the existing algorithms to generate Interface IDs >> (e.g. such as that specified in [RFC2464]). However, those IPv6 >> implementations that employ this specification must generate all >> of their "stable" addresses as specified in this document. >> >> My suggestion is to simplify remove it as it is self-evident. > What's the part that is evident? The one about not deprecating existing > algorithms? -- Because the other ne certainly isn't: if you're going to > use this algorithm for generating addresses *in addition* to those > generated by traditional SLAAC, then this document wouldn't mitigate > address-scanning attacks. How would an IPv6 implementation employing this specification vary from this specification in a way you or the working group would find objectionable? Also, did you mean "MUST"? If not, this language is all the more confusing and I don't know what you mean. >> Finally, this algorithm requires that the resultant host portion be 64 >> bits. Is that necessary? > Well, yes- If the PRF produces a bit string larger than 64 bits, and > you say nothing about how you grab the IID, then the algorithm is > underspecified. > > The easier it is for a developer to go through this document and come up > with an implementation, the better. The more the open questions, the worse. > I think we are underestimating our developers but if the working group feels differently, okay. I asked the above question because it is at least conceivable that at some point host portion != 64 bits and this is the only place in the document where the requirement is stated. Yes, screwing with the 64 bit boundary today is bound to cause all sorts of breakage. I'm not thinking of today but the future. And yes, another argument would be that there isn't enough address space for this to be effectively private. Those are two different issues, but fixing the boundary here reminds me of mistakes we made with IPv4 way back when. In this day and age we're talking about a lot more cleanup later. Eliot From mstjohns@comcast.net Mon Apr 22 09:03:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DE211E80D2 for ; Mon, 22 Apr 2013 09:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PisIcZ5t9E8g for ; Mon, 22 Apr 2013 09:03:28 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id D3DE611E80D1 for ; Mon, 22 Apr 2013 09:03:27 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id SzNw1l0031ZXKqc5143T7A; Mon, 22 Apr 2013 16:03:27 +0000 Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta21.westchester.pa.mail.comcast.net with comcast id T43S1l00K2kB7pQ3h43TUU; Mon, 22 Apr 2013 16:03:27 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Apr 2013 12:03:26 -0400 To: Sam Hartman ,RJ Atkinson From: Michael StJohns Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366646607; bh=L/XlzKU4ZMm42Jvw4rHPda4ti69ZrUYXtiulkb0Lx8M=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=K/HZgrbezpq05uFnqKa/lkJHnxprAOMLt8+xxbXp6eH8wsuOSAxVu/nyBwCZ42vda qY2/JZPHmVH+Io/L5z1iSaYvvboAsYxSeBQHPMl+PE9PGUg9Qd3AcKTVLuJ//U4RU/ ZXdc5+gdTsZ7kKbE7V/0e9arGP4NiDBxfaLU/zoZ/uTUGGWfDK67sjQGkEM6WKew8Y PC5L0YQQZxr3R55H90YvH0c/iN6VVdOsRR/Jpcnuk1jVUOuMoxBVEYrPlbsYnbseKc ZLuYpqnprl+1JBL/sajKn2dEfNM/5a81YkTsCGxqMF13w7WqCqqBx1pbSQDkXCe8Ol LYFp05sjVZpXw== Message-Id: <20130422160327.D3DE611E80D1@ietfa.amsl.com> X-Mailman-Approved-At: Mon, 22 Apr 2013 09:40:58 -0700 Cc: ipv6@ietf.org, ietf@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:03:28 -0000 At 09:56 AM 4/22/2013, Sam Hartman wrote: >>>>>> "RJ" == RJ Atkinson writes: > > > RJ> I oppose Eliot's proposed edits on grounds that they would > RJ> reduce the clarity of the specification and also would reduce > RJ> IETF and WG consensus about this specification. > >Ran, I just checked, and you don't seem to be a 6man chair. We >generally ask chairs, not involved participants to judge WG consensus >and ADs to judge IETF consensus. Bovine dung. Or more politely - nonsense. Participants judge WG consensus all the time. Occasionally WG chairs will "declare" consensus to more the process forward, but that's rarer than the normal group think. >So, I think what you're saying boils down to you disagree with Eliot >because you believe his comments would reduce clarity. You believe >others within the WG and outside the WG are likely to agree with you. >That's all fine and is valuable to contribute. > >However, I don't think it promotes open and honest technical discussion >when participants try to call consensus. >Thanks for considering my input. And I don't think it promotes open and honest technical discussion when you attack "standing" of a participant who *has* participated in the formation of a document to take an action, ask a question, or make a comment, rather than addressing the substance of the comment(s) made by that participant. It's unclear from what you wrote that you considered the substance of Ran's comment. What he wrote was: >It would reduce consensus within the WG and the IETF as a whole >to remove that text -- as it clarifies that other mechanisms for >generating such IDs are not affected by this specification. > >Text to this effect was specifically requested by various WG >participants, precisely because it is not "self-evident" and >instead was confusing. What *I* heard was: "Elliot, the section you want to remove was added specifically through working group discussion to gain consensus for the document". Assuming that I understood that was what he meant, and that it represents the reality of the process, Ran drawing the conclusion that removing that text would tend to "reduce consensus" seems to be a reasonable one and targeted specifically at the edit. Mike From pkern@simplex.0x539.de Mon Apr 22 11:04:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A607421F8E7B; Mon, 22 Apr 2013 11:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS-ObG8-j21m; Mon, 22 Apr 2013 11:04:33 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CC121F8C0C; Mon, 22 Apr 2013 11:04:32 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UUL6J-0007jS-I3; Mon, 22 Apr 2013 20:04:27 +0200 Received: from f053213015.adsl.alicedsl.de ([78.53.213.15] helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UUL6K-00073G-Lf; Mon, 22 Apr 2013 20:04:28 +0200 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UUL6J-000362-A9; Mon, 22 Apr 2013 20:04:27 +0200 Date: Mon, 22 Apr 2013 20:04:27 +0200 From: Philipp Kern To: Eliot Lear Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 Message-ID: <20130422180427.GA11207@simplex.0x539.de> References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <517563C0.6000508@cisco.com> Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man@ietf.org, IETF Discussion X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 18:04:34 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Eliot, am Mon, Apr 22, 2013 at 06:22:24PM +0200 hast du folgendes geschrieben: > I asked the above question because it is at least conceivable that at > some point host portion != 64 bits and this is the only place in the > document where the requirement is stated. Yes, screwing with the 64 > bit boundary today is bound to cause all sorts of breakage. I'm not > thinking of today but the future. And yes, another argument would be > that there isn't enough address space for this to be effectively > private. Those are two different issues, but fixing the boundary here > reminds me of mistakes we made with IPv4 way back when. In this day > and age we're talking about a lot more cleanup later. especially as there are already existing RFCs that are flexible in the boundaries. Oddly RFC 4862 IPv6 Stateless Address Autoconfiguration is one of them (e.g., 5.3, the creation of the link-layer address), which is pretty much fixed by implementations to operate at the 64 bit boundary. Granted, that's mostly when dealing with Ethernet-based infrastructures and the document does explain that the length of the interface identifier depends on the link type (5.5.3 d). Kind regards Philipp Kern --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJRdXurAAoJEERuJUU10FbsdRsIAJMl6z/b13cRO8bO3hsow2yB YY93unNo3RFSpsdSWVlauLTKtzUL8J40Gm/Xmupkpv2pvZxeMH3XHBfDuc1JhH16 /Npy7uTGHs4YYzcILJ71mccMWXMg86pIH52Z3tUjSk+/vu7rhlfT+52P8SUZhMR0 tHbGB6FETkUH9msdrWI6JMxsO4fSPcmedS+Qzm3AYVF9IKcQvHgj/tAT3GqhmWrC 8c/g1tyYGNJI1lSovGuebk5dHO17kLqv+qjp++dlBHQVHWJCK/Rbcgzdou2Y5cjn khjPP57liZqGPebRUcgUx8093PNWvqmysYdxBr3EEYTFkYtN94nJ80SkNK1HjGQ= =vPBF -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From fgont@si6networks.com Mon Apr 22 12:23:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418DA11E80ED; Mon, 22 Apr 2013 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mWnbB-In4Zp; Mon, 22 Apr 2013 12:23:20 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE7B21F9193; Mon, 22 Apr 2013 12:23:20 -0700 (PDT) Received: from [201.157.17.130] (helo=[172.20.4.229]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UUMKY-0006Vt-Vs; Mon, 22 Apr 2013 21:23:15 +0200 Message-ID: <51758E1F.80803@si6networks.com> Date: Mon, 22 Apr 2013 14:23:11 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eliot Lear Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> In-Reply-To: <517563C0.6000508@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man@ietf.org, Bob Hinden , IETF Discussion X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:23:21 -0000 Hi, Eliot, On 04/22/2013 11:22 AM, Eliot Lear wrote: >>> With this >>> document, I wonder if quite a bit could be removed. >>> >>> Specifically, a great deal of discussion goes into the PRF involving DAD >>> counters, etc, when all that is needed is a suitable PRF. >> Not sure what you mean...What's thetext that you think could/should be >> removed? > > Sorry I wasn't clear: what is the benefit of specifying the algorithm, > when simply popping out another PRF will in just about any instance do > the job (unless you are reinitializing the PRF with the same seed)? There seems to be a disconnect here: We want an algorithm that, roughly speaking, whenever you connect to the same network, gives you the same address. But such address should be different for each network you connect to. The question here is: How do you achieve that? You might argue that, clearly, the autoconf prefix needs to be part of the seed (I'd personally not expect developers to figure this one out). But there are more issues. e.g., say that my node has to network interfaces. If I use both of them to connect to the same network, the address they get should be different (but still have the same properties stated above). How do you achieve that? -- Well, yu need *something* that changes from one interface to another. But even if you figure *something* you mght use for that it might be non-optimal. -- for example, if you use the MAC address, then your address changes if you replace the NIC. If you use the interface index, it doesn't. At the end of the day, the devil lies in the small details. And I'd argue that if it had all been that obvious, it'd have been done before. >>> The draft in >>> fact says this in Section 3 after an explanation of the inputs. Any PRF >>> that follows the guidelines of RFC 4086 should do fine and not cause >>> interoperability OR security problems. >> If you're referring to the text that explains why we're not mandating >> any specific PRF, that text is there because the issue was raisen in the wg, > > Ok. So what I gather is that there was a negotiation within the WG and > that the algorithm is optional. The "negotiation" was that this dspec does not replace the traditional slaac algorithm that, in the case of Ethernet, embeds IEEE identifers in the Interface ID. > Ok. From an outside point of view, I > didn't need to know that, and the question is what was the value of > still specifying the PRF. I think Ran Atkinson answered that. He feels > he wants a fully specified algorithm from which to start. Ok. My only > response is that I don't understand the need (generating 64 bits that > aren't the same shouldn't be that hard), but if the WG really believes > there is one, okay. We're not just "randomizing" the addresses. The are *constant* within each network, but change across networks. >>> Also, the following text in section 3 Page 7 is contorted: >>> >>> This means that this document does not formally obsolete or >>> deprecate any of the existing algorithms to generate Interface IDs >>> (e.g. such as that specified in [RFC2464]). However, those IPv6 >>> implementations that employ this specification must generate all >>> of their "stable" addresses as specified in this document. >>> >>> My suggestion is to simplify remove it as it is self-evident. >> What's the part that is evident? The one about not deprecating existing >> algorithms? -- Because the other ne certainly isn't: if you're going to >> use this algorithm for generating addresses *in addition* to those >> generated by traditional SLAAC, then this document wouldn't mitigate >> address-scanning attacks. > > How would an IPv6 implementation employing this specification vary from > this specification in a way you or the working group would find > objectionable? If, for the same interface you employ this algorithm *and* the traditional SLAAC algorithm, that's objectionable. > Also, did you mean "MUST"? If not, this language is all > the more confusing and I don't know what you mean. Yes, I meant "MUST". -- I will fix this. >>> Finally, this algorithm requires that the resultant host portion be 64 >>> bits. Is that necessary? >> Well, yes- If the PRF produces a bit string larger than 64 bits, and >> you say nothing about how you grab the IID, then the algorithm is >> underspecified. >> >> The easier it is for a developer to go through this document and come up >> with an implementation, the better. The more the open questions, the worse. > > I think we are underestimating our developers but if the working group > feels differently, okay. I don't think so. Lots of folks code on so many different areas, that it'd be unrealistic to expect them to figure everything out by themselves. Yes, there are some smart folks that can figure a lot by themselves... but that's the exception rather than the rule. And even if they were all that smart, we want to make their lives easier: the less they have to figure out by themselves, the better. > I asked the above question because it is at > least conceivable that at some point host portion != 64 bits and this is > the only place in the document where the requirement is stated. Yes, > screwing with the 64 bit boundary today is bound to cause all sorts of > breakage. My understanding is that we're all set for 64-bit identifiers -- with the exception of point to point links where subnets < 64 bits are allowed (fro the most part, as a workaround to buggy implementations that are vulnerable to NCE attacks). > I'm not thinking of today but the future. And yes, another > argument would be that there isn't enough address space for this to be > effectively private. Those are two different issues, but fixing the > boundary here reminds me of mistakes we made with IPv4 way back when. > In this day and age we're talking about a lot more cleanup later. I guess this raises a more fundamental question with respect to whether we want 64-bit identifiers to be the standard, or not. A compromise might be to add a *parenthetical* note such as: "The current IPv6 Addressing architecture defines Interface-Identifiers to be 64 bits long, hence the low-order 64-bits of F() are employed for the Interface-ID. Were the IPv6 Addressing Architecture updated to allow any arbitrary length for the Interface ID, an implementation would need to be prepared to select as many bits from F() (rather than the fixed 64-bits specified above) for the Interface ID, such that an Interface ID of appropriate length is obtained" I'd personally have no issues with that *if* the wg agrees. But I wouldn't want to remove the text on grabbing the low-order 64-bits, since that's makes the spec more clear for the current times. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From markzzzsmith@yahoo.com.au Mon Apr 22 13:07:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E500721E80D3 for ; Mon, 22 Apr 2013 13:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSA64ZyqMTRM for ; Mon, 22 Apr 2013 13:07:56 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with SMTP id 2BCD221E80D0 for <6man@ietf.org>; Mon, 22 Apr 2013 13:07:56 -0700 (PDT) Received: from [98.139.215.143] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 22 Apr 2013 20:07:55 -0000 Received: from [98.139.212.248] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 22 Apr 2013 20:07:55 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 22 Apr 2013 20:07:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 547330.4503.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 23424 invoked by uid 60001); 22 Apr 2013 20:07:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1366661275; bh=YyPd6jZbRH2AfgZES2i9SO27DVZr6de+ZveDZJk8D+U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xbj9DcfAehdPNAeJ9stWStE11Vd9UPQ1IcU1XPbkMQQwT1FTliIGs/1DXgyym2pw8PGFlflMk0jPLeQtjGgBeiocDUCCO752Qlf22hIz+9UCU5Wb2DBSmjAw7L4mWG9j6/Qt+oGqQrcnvUyXJeXNISHObrFYQQRwnDdxhIZMPYk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YbiDl0iQVbUIsok14FGiuLGHG6IJzltnUeYViU42zfdmfX8C9p6ErzQS+Jh6upbVNsy3EobvkPsuSfFrLjBviyxhJqzUXxgwDpEdisgrPI0jloZHjgZWwG9DoHYpsXe3C3kw66LIG01zrGU/nFIvUshjCqlPTkzYTmJlSHiP1qA=; X-YMail-OSG: VwG2_egVM1ks8XysOM0LAt2Wki2Z9UEnPrj2gyVr.k9B1eP brB53BzEdA.A5iq0- Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Mon, 22 Apr 2013 13:07:54 PDT X-Rocket-MIMEInfo: 002.001, CgpIaSwKCjxzbmlwPgoKPiAKPj4gIEknbSBub3QgdGhpbmtpbmcgb2YgdG9kYXkgYnV0IHRoZSBmdXR1cmUuwqAgQW5kIHllcywgYW5vdGhlcgo.PiAgYXJndW1lbnQgd291bGQgYmUgdGhhdCB0aGVyZSBpc24ndCBlbm91Z2ggYWRkcmVzcyBzcGFjZSBmb3IgdGhpcyB0byBiZQo.PiAgZWZmZWN0aXZlbHkgcHJpdmF0ZS7CoCBUaG9zZSBhcmUgdHdvIGRpZmZlcmVudCBpc3N1ZXMsIGJ1dCBmaXhpbmcgdGhlCj4.ICBib3VuZGFyeSBoZXJlIHJlbWluZHMgbWUgb2YgbWlzdGFrZXMgd2UgbWFkZSB3aXRoIElQdjQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> <51758E1F.80803@si6networks.com> Message-ID: <1366661274.23349.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Mon, 22 Apr 2013 13:07:54 -0700 (PDT) From: Mark Smith Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 To: Fernando Gont , Eliot Lear In-Reply-To: <51758E1F.80803@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org" , "6man@ietf.org" <6man@ietf.org>, Bob Hinden , IETF Discussion X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:07:57 -0000 =0A=0AHi,=0A=0A=0A=0A> =0A>> I'm not thinking of today but the futur= e.=A0 And yes, another=0A>> argument would be that there isn't enough addr= ess space for this to be=0A>> effectively private.=A0 Those are two differ= ent issues, but fixing the=0A>> boundary here reminds me of mistakes we ma= de with IPv4 way back when. =0A>> In this day and age we're talking about = a lot more cleanup later.=0A> =0A> I guess this raises a more fundamental q= uestion with respect to whether=0A> we want 64-bit identifiers to be the st= andard, or not.=0A> =0A> A compromise might be to add a *parenthetical* not= e such as:=0A> =0A> "The current IPv6 Addressing architecture defines Inter= face-Identifiers=0A> to be 64 bits long, hence the low-order 64-bits of F()= are employed for=0A> the Interface-ID. Were the IPv6 Addressing Architectu= re updated to allow=0A> any arbitrary length for the Interface ID, an imple= mentation would need=0A> to be prepared to select as many bits from F() (ra= ther than the fixed=0A> 64-bits specified above) for the Interface ID, such= that an Interface ID=0A> of appropriate length is obtained"=0A> =0A> I'd p= ersonally have no issues with that *if* the wg agrees. But I=0A> wouldn't w= ant to remove the text on grabbing the low-order 64-bits,=0A> since that's = makes the spec more clear for the current times.=0A>=A0=0A=0AWhile this par= t of RFC4291 should make the 64 bit statements safe:=0A=0A"For all unicast = addresses, except those that start with the binary=0A=A0 =A0value 000, Inte= rface IDs are required to be 64 bits long and to be=0A=A0 =A0constructed in= Modified EUI-64 format."=0A=0AThe /127 prefix length RFC changed that, so = I'd suggest it might be safer to generalise and say take the number of bits= from the hash that correspond to the IID length in use, and then reference= 64 bit IIDs as an example.=0A=0A=0ARegards,=0AMark. From lear@cisco.com Mon Apr 22 13:31:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FE121E80AF; Mon, 22 Apr 2013 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.885 X-Spam-Level: X-Spam-Status: No, score=-110.885 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nd8AYzJduxY; Mon, 22 Apr 2013 13:31:11 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id D21C321E8053; Mon, 22 Apr 2013 13:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=942; q=dns/txt; s=iport; t=1366662664; x=1367872264; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mNe8CJ4TRo5UM1CLP3+NilFSACAkaRfZrSKW+BUkiiQ=; b=CrWu3dVKCpm3vnqaFiDuOpiAdvyi4q3L9FE+TuddRscoFWstqIkeV7ao ZwVKWXUuivGVJ7x7/i4pXhZXyJIhZTwImC6RDMdO96628ZV/iLhIJhLbo 8t/V6RWMnmwZgCHcXByDwYkLsaisXsVaD9GtK34toeT0mPXer9ebWMTfz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAP+cdVGQ/khM/2dsb2JhbABQgwaDZ71agQYWdIIfAQEBAwEjVQEQCw4KAgIFFgsCAgkDAgECAUUGDQEHAQGICgaqW5ElgSOOHAdjgVGBEwOXFZEagn8POg X-IronPort-AV: E=Sophos;i="4.87,529,1363132800"; d="scan'208";a="13484189" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 22 Apr 2013 20:31:01 +0000 Received: from ams3-vpn-dhcp5433.cisco.com (ams3-vpn-dhcp5433.cisco.com [10.61.85.56]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3MKUxu7025898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 20:30:59 GMT Message-ID: <51759E03.4030208@cisco.com> Date: Mon, 22 Apr 2013 22:30:59 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fernando Gont Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> <51758E1F.80803@si6networks.com> In-Reply-To: <51758E1F.80803@si6networks.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man@ietf.org, Bob Hinden , IETF Discussion X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:31:12 -0000 H Fernando, On 4/22/13 9:23 PM, Fernando Gont wrote: > > There seems to be a disconnect here: > > We want an algorithm that, roughly speaking, whenever you connect to the > same network, gives you the same address. But such address should be > different for each network you connect to. Thank you, and yes there was a disconnect. Indeed now I get it. For some reason I had assumed that you meant for some short period of time, but the algorithm is clearly aimed at longer periods of time (e.g., across reboots). Given that, the inputs the WG has stated seem perfectly reasonable. >> How would an IPv6 implementation employing this specification vary from >> this specification in a way you or the working group would find >> objectionable? > If, for the same interface you employ this algorithm *and* the > traditional SLAAC algorithm, that's objectionable. Right. With you now. Thanks again... Eliot From Anders_Brandt@sigmadesigns.com Tue Apr 23 06:47:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6403221F96D6; Tue, 23 Apr 2013 06:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+BFnZCT7RJj; Tue, 23 Apr 2013 06:47:10 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4B09121F96D2; Tue, 23 Apr 2013 06:47:07 -0700 (PDT) From: Anders Brandt To: "6lowpan@ietf.org" <6lowpan@ietf.org>, "ipv6@ietf.org" Subject: New Version Notification for draft-brandt-6man-lowpanz-01.txt Thread-Topic: New Version Notification for draft-brandt-6man-lowpanz-01.txt Thread-Index: AQHOQCicP3oGRKV6UUavT1IJh4zwBJjj0TEw Date: Tue, 23 Apr 2013 13:47:04 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD20E0676F@cph-ex1> References: <20130423134356.11747.20964.idtracker@ietfa.amsl.com> In-Reply-To: <20130423134356.11747.20964.idtracker@ietfa.amsl.com> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 13:47:12 -0000 QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJyYW5kdC02bWFuLWxvd3BhbnotMDEudHh0IGhh cyBiZWVuIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0 LWJyYW5kdC02bWFuLWxvd3BhbnoNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFRyYW5zbWlzc2lv biBvZiBJUHY2IHBhY2tldHMgb3ZlciBJVFUtVCBHLjk5NTkgTmV0d29ya3MNCkNyZWF0aW9uIGRh dGU6CSAyMDEzLTA0LTIyDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBv ZiBwYWdlczogMTQNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFuei0wMS50eHQNClN0YXR1czogICAgICAg ICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1icmFuZHQtNm1hbi1sb3dw YW56DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJy YW5kdC02bWFuLWxvd3BhbnotMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFuei0wMQ0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBmcmFtZSBmb3JtYXQgZm9yIHRyYW5zbWlz c2lvbiBvZiBJUHY2DQogICBwYWNrZXRzIGFuZCBhIG1ldGhvZCBvZiBmb3JtaW5nIElQdjYgbGlu ay1sb2NhbCBhZGRyZXNzZXMgYW5kDQogICBzdGF0ZWxlc3NseSBhdXRvY29uZmlndXJlZCBJUHY2 IGFkZHJlc3NlcyBvbiBJVFUtVCBHLjk5NTkgbmV0d29ya3MuDQoNCg0KQ2hlZXJzLA0KICBBbmRl cnMgQnJhbmR0DQo= From huitema@microsoft.com Tue Apr 23 09:42:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D856021F972D; Tue, 23 Apr 2013 09:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7HWCAodo+q1; Tue, 23 Apr 2013 09:42:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id B176C21F972B; Tue, 23 Apr 2013 09:42:50 -0700 (PDT) Received: from BL2FFO11HUB020.protection.gbl (10.173.160.112) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.675.0; Tue, 23 Apr 2013 16:42:49 +0000 Received: from BL2FFO11FD013.protection.gbl (10.173.161.201) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.675.0; Tue, 23 Apr 2013 16:42:48 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Tue, 23 Apr 2013 16:42:48 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Tue, 23 Apr 2013 16:41:44 +0000 From: Christian Huitema To: Fernando Gont , Eliot Lear Subject: RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06 Thread-Topic: last call comments for draft-ietf-6man-stable-privacy-addresses-06 Thread-Index: AQHOPyGOslmR5sKVOkuNgHIrtQl435jiaE2AgAAElACAADKDgIABYycg Date: Tue, 23 Apr 2013 16:41:43 +0000 Message-ID: References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> <51758E1F.80803@si6networks.com> In-Reply-To: <51758E1F.80803@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(51856001)(56816002)(55846006)(69226001)(44976003)(47976001)(31966008)(65816001)(23676002)(54356001)(63696002)(33656001)(53806001)(4396001)(47446002)(50986001)(74662001)(81542001)(80022001)(621065001)(59766001)(47776003)(74502001)(73894001)(79102001)(20776003)(46102001)(77982001)(16406001)(56776001)(6806003)(76482001)(66066001)(49866001)(47736001)(81342001)(50466001)(54316002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Forefront-PRVS: 08252193F3 X-OriginatorOrg: microsoft.onmicrosoft.com Cc: "draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org" , "6man@ietf.org" <6man@ietf.org>, Bob Hinden , IETF Discussion X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:42:52 -0000 Pj4gU29ycnkgSSB3YXNuJ3QgY2xlYXI6IHdoYXQgaXMgdGhlIGJlbmVmaXQgb2Ygc3BlY2lmeWlu ZyB0aGUgYWxnb3JpdGhtLCANCj4+IHdoZW4gc2ltcGx5IHBvcHBpbmcgb3V0IGFub3RoZXIgUFJG IHdpbGwgaW4ganVzdCBhYm91dCBhbnkgaW5zdGFuY2UgZG8gDQo+PiB0aGUgam9iICh1bmxlc3Mg eW91IGFyZSByZWluaXRpYWxpemluZyB0aGUgUFJGIHdpdGggdGhlIHNhbWUgc2VlZCk/DQo+DQo+ IFRoZXJlIHNlZW1zIHRvIGJlIGEgZGlzY29ubmVjdCBoZXJlOg0KPg0KPiBXZSB3YW50IGFuIGFs Z29yaXRobSB0aGF0LCByb3VnaGx5IHNwZWFraW5nLCB3aGVuZXZlciB5b3UgY29ubmVjdCB0byB0 aGUgc2FtZSBuZXR3b3JrLCBnaXZlcyB5b3UgdGhlIHNhbWUgYWRkcmVzcy4gQnV0IHN1Y2ggYWRk cmVzcyBzaG91bGQgYmUgZGlmZmVyZW50IGZvciBlYWNoIG5ldHdvcmsgeW91IGNvbm5lY3QgdG8u DQo+IA0KPiBUaGUgcXVlc3Rpb24gaGVyZSBpczogSG93IGRvIHlvdSBhY2hpZXZlIHRoYXQ/DQo+ DQo+IFlvdSBtaWdodCBhcmd1ZSB0aGF0LCBjbGVhcmx5LCB0aGUgYXV0b2NvbmYgcHJlZml4IG5l ZWRzIHRvIGJlIHBhcnQgb2YgdGhlIHNlZWQgKEknZCBwZXJzb25hbGx5IG5vdCBleHBlY3QgZGV2 ZWxvcGVycyB0byBmaWd1cmUgdGhpcyBvbmUgb3V0KS4NCg0KVGhpcyBpcyB0aGUga2luZCBvZiBh dHRpdHVkZSB0aGF0IHJlYWxseSBkb2VzIG5vdCBnbyB3ZWxsIHdpdGggYWN0dWFsIGRldmVsb3Bl cnMuIFlvdSBhcmUgYmFzaWNhbGx5IHNheWluZyB0aGF0IHlvdSBleHBlY3QgZGV2ZWxvcGVycyB0 byBiZSB0b28gZHVtYiB0byB1bmRlcnN0YW5kIHdoYXQgdGhleSBhcmUgZG9pbmcsIGFuZCB0aHVz IHlvdSBmZWVsIGNvbXBlbGxlZCB0byBzcGVjaWZ5IGFuIGFsZ29yaXRobSBpbiBpdHMgbW9zdCBt aW51dGUgZGV0YWlscywgZXZlbiB0aG91Z2ggdGhlcmUgYXJlIGRvemVucyBvZiBlcXVhbGx5IGdv b2Qgd2F5cyB0byBhY2hpZXZlIHRoZSBzYW1lIHJlc3VsdC4gVGhlIG5ldCByZXN1bHQgb2Ygc3Vj aCBvdmVyLXNwZWNpZmljYXRpb24gaXMgdGhhdCBkZXZlbG9wZXJzIHdpbGwgZGlzY2FyZCB0aGUg c3BlYyBhcyBhcnJvZ2FudCwgYW5kIGltcGxlbWVudCB3aGF0IHRoZXkgZmVsbCBsaWtlIGltcGxl bWVudGluZy4gDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0K From huitema@microsoft.com Tue Apr 23 11:00:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2321F9629 for ; Tue, 23 Apr 2013 11:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrKVppHHdpMO for ; Tue, 23 Apr 2013 11:00:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF2421F9627 for ; Tue, 23 Apr 2013 11:00:27 -0700 (PDT) Received: from BL2FFO11FD025.protection.gbl (10.173.161.203) by BL2FFO11HUB012.protection.gbl (10.173.161.118) with Microsoft SMTP Server (TLS) id 15.0.675.0; Tue, 23 Apr 2013 17:56:05 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD025.mail.protection.outlook.com (10.173.161.104) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Tue, 23 Apr 2013 17:56:04 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Tue, 23 Apr 2013 17:55:51 +0000 From: Christian Huitema To: Fernando Gont Subject: RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06 Thread-Topic: last call comments for draft-ietf-6man-stable-privacy-addresses-06 Thread-Index: AQHOP15AmJeRabuWb0mZCsaFLdinaJjihbgAgAAeFQCAABByAIABToYAgAACAJCAAA+rAIAAAEhw Date: Tue, 23 Apr 2013 17:55:50 +0000 Message-ID: References: <6.2.5.6.2.20130422081720.0db4ca38@resistor.net> <51759238.8000306@si6networks.com> <6.2.5.6.2.20130422125704.0d551178@resistor.net> <5176B8A2.40809@si6networks.com> <5176C774.7080300@si6networks.com> In-Reply-To: <5176C774.7080300@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52034002)(51704004)(189002)(199002)(59766001)(46102001)(80022001)(66066001)(81542001)(76482001)(47736001)(50986001)(69226001)(20776003)(74662001)(56776001)(65816001)(54316002)(49866001)(31966008)(47776003)(47976001)(81342001)(47446002)(16406001)(46406003)(74502001)(4396001)(56816002)(51856001)(77982001)(53806001)(54356001)(44976003)(63696002)(50466001)(33656001)(6806003)(23726002)(79102001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB012; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08252193F3 Cc: RJ Atkinson , "IETF IPv6 Mailing List \(ipv6@ietf.org\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:00:29 -0000 > > And I would > > observe that the DAD problem cannot be solved ina reliable way. > > Could you please elaborate? (Moving to the ipv6 mailing list, as this is way too detailed for the main = IETF list.) The goal is to use the same address when repeatedly visiting the same netwo= rk. However, since we are using random numbers, we do not have guarantees t= hat these addresses will not collide. Suppose that two hosts, A and B, want= to use the same "colliding" addresses. If A connects first, B will have to= use a fallback address. If B connects first, it will be A's turn to use a = fallback address. That means that, given collisions, we fundamentally canno= t guarantee that "the same host will always have the same address on the sa= me network." Your draft attempts to make the fallback predictable, by incorporating a DA= D counter in the seeds of your nominal algorithm. But that means redefining= the solution a only a guarantee that "the visiting host will have one of t= he same 2 or 3 addresses on the visited network." I am not sure it is worth= the additional complexity, by opposition to just saying, "in case of colli= sion, pick a new number." By the way, there are many issues relate to privacy and mobility, and I am = not sure that we can address them. Suppose that, as an attacker, I want to = know the correspondence between a visiting host, identified by a particular= MAC address, and the IPv6 address that this host use when "at home." I can= somehow get control of a hot spot that the target host will visit. Then I = can instruct the hot spot to announce in RA the very same prefix as the tar= get's home network. Voila, the host will start doing DAD with their home ne= twork IPv6 address... -- Christian Huitema From fgont@si6networks.com Tue Apr 23 11:38:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6221F9751 for ; Tue, 23 Apr 2013 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPDhi82CS+LO for ; Tue, 23 Apr 2013 11:38:02 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 051CA21F9756 for ; Tue, 23 Apr 2013 11:38:01 -0700 (PDT) Received: from [186.134.53.35] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UUi6B-0007wM-ED; Tue, 23 Apr 2013 20:37:51 +0200 Message-ID: <5176D4F9.8020203@si6networks.com> Date: Tue, 23 Apr 2013 13:37:45 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Huitema Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <6.2.5.6.2.20130422081720.0db4ca38@resistor.net> <51759238.8000306@si6networks.com> <6.2.5.6.2.20130422125704.0d551178@resistor.net> <5176B8A2.40809@si6networks.com> <5176C774.7080300@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson , "IETF IPv6 Mailing List \(ipv6@ietf.org\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:38:02 -0000 On 04/23/2013 12:55 PM, Christian Huitema wrote: >>> And I would observe that the DAD problem cannot be solved ina >>> reliable way. >> >> Could you please elaborate? > > (Moving to the ipv6 mailing list, as this is way too detailed for the > main IETF list.) > > The goal is to use the same address when repeatedly visiting the same > network. However, since we are using random numbers, we do not have > guarantees that these addresses will not collide. Suppose that two > hosts, A and B, want to use the same "colliding" addresses. If A > connects first, B will have to use a fallback address. If B connects > first, it will be A's turn to use a fallback address. That means > that, given collisions, we fundamentally cannot guarantee that "the > same host will always have the same address on the same network." Agreed. But we have 64-bit Interface IDs. If you get collisions, and you get the nodes connecting in different sequences... well... call that "bad luck" ;-) At the end of the day, you cannot guarantee that because the TCP checksum is valid and e.g. the Ethernet CRC is valid, the data being transferred does not contain across, either. And you cannot guarantee that packet have a limited lifetime on a network (after all, nothing is taking into account the time it takes for the packet to be put in the network, and travel from one router to another), and.... > Your draft attempts to make the fallback predictable, by > incorporating a DAD counter in the seeds of your nominal algorithm. > But that means redefining the solution a only a guarantee that "the > visiting host will have one of the same 2 or 3 addresses on the So you're implying that on a given network, there might be e.g. three collisions. What would be the probability of that from happening? > By the way, there are many issues relate to privacy and mobility, and > I am not sure that we can address them. Suppose that, as an attacker, > I want to know the correspondence between a visiting host, identified > by a particular MAC address, and the IPv6 address that this host use > when "at home." I can somehow get control of a hot spot that the > target host will visit. Then I can instruct the hot spot to announce > in RA the very same prefix as the target's home network. Voila, the > host will start doing DAD with their home network IPv6 address... That assumes that the nodes uses the same network interface to access its home network and your compromised hotspot, and that, if Network IDs are employed for F(), you know what's the Network ID in use at home. At the point you get to this kind of attack ascenario, and *if* it is a concern, you may need some additional mitigations (e.g., SEND or the like). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Apr 23 12:03:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC2421F96EB for ; Tue, 23 Apr 2013 12:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-iwQM4MRyih for ; Tue, 23 Apr 2013 12:03:05 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8323F21F96CE for ; Tue, 23 Apr 2013 12:03:05 -0700 (PDT) Received: from [186.134.53.35] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UUiUR-00006q-57; Tue, 23 Apr 2013 21:02:55 +0200 Message-ID: <5176DAD8.2010703@si6networks.com> Date: Tue, 23 Apr 2013 14:02:48 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Huitema Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <6.2.5.6.2.20130422081720.0db4ca38@resistor.net> <51759238.8000306@si6networks.com> <6.2.5.6.2.20130422125704.0d551178@resistor.net> <5176B8A2.40809@si6networks.com> <5176C774.7080300@si6networks.com> <5176D4F9.8020203@si6networks.com> In-Reply-To: <5176D4F9.8020203@si6networks.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson , "IETF IPv6 Mailing List \(ipv6@ietf.org\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 19:03:06 -0000 On 04/23/2013 01:37 PM, Fernando Gont wrote: > On 04/23/2013 12:55 PM, Christian Huitema wrote: >>>> And I would observe that the DAD problem cannot be solved ina >>>> reliable way. >>> >>> Could you please elaborate? >> >> (Moving to the ipv6 mailing list, as this is way too detailed for the >> main IETF list.) >> >> The goal is to use the same address when repeatedly visiting the same >> network. However, since we are using random numbers, we do not have >> guarantees that these addresses will not collide. Suppose that two >> hosts, A and B, want to use the same "colliding" addresses. If A >> connects first, B will have to use a fallback address. If B connects >> first, it will be A's turn to use a fallback address. That means >> that, given collisions, we fundamentally cannot guarantee that "the >> same host will always have the same address on the same network." > > Agreed. But we have 64-bit Interface IDs. If you get collisions, and you > get the nodes connecting in different sequences... well... call that > "bad luck" ;-) > > At the end of the day, you cannot guarantee that because the TCP > checksum is valid and e.g. the Ethernet CRC is valid, the data being > transferred does not contain across, either. s/across/errors/ -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Apr 23 14:42:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25B021F9349; Tue, 23 Apr 2013 14:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHPsLRfp401c; Tue, 23 Apr 2013 14:42:11 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6234E21F933F; Tue, 23 Apr 2013 14:42:10 -0700 (PDT) Received: from [186.134.53.35] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UUkyQ-0003vl-0b; Tue, 23 Apr 2013 23:42:02 +0200 Message-ID: <51770022.3050401@si6networks.com> Date: Tue, 23 Apr 2013 16:41:54 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Huitema Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> <51758E1F.80803@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org>, IETF Discussion , Eliot Lear , Bob Hinden , Fernando Gont , "draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:42:12 -0000 On 04/23/2013 11:41 AM, Christian Huitema wrote: >> You might argue that, clearly, the autoconf prefix needs to be part >> of the seed (I'd personally not expect developers to figure this >> one out). > > This is the kind of attitude that really does not go well with actual > developers. You are basically saying that you expect developers to be > too dumb to understand what they are doing, You're misreading me. I'm saying that developers work across across many different areas and are busy people, and I cannot expect them to figure out stuff what *we* were lazy or dumb enough to leave unspecified. If I'm the guy producing a spec, my goal is to produce a spec that is clear as possible, and only leave open those bits that are necessary to leave open. > and thus you feel > compelled to specify an algorithm in its most minute details, even That's incorrect. For instance, that's why we don't mandate a specific PRF: because for that particular case, developers are in a better position of judging what's the best PRF to use. > though there are dozens of equally good ways to achieve the same > result. So far you have only mentioned one (recording the Prefix/IIDs pairs), which IMHO is not elegant. Any others? FWIW, you'll realize that e.g. RFC 4941 has even more detail than this spec. > The net result of such over-specification is that developers > will discard the spec as arrogant, and implement what they fell like > implementing. I cannot control people's thoughts. However, I'd say that I'm fairly well-known for socializing stuff among developers, well-before a document is published as an RFC. Much of the work that I've done over these years have resulted in patches from a variety of OSes, because I cared to discuss them with developers. Of course, documents that I've authored have benefited from input from developers during that discussion process. (Not to mention that the contents of the documents I've written have generally been very influenced by the input of a number of participants... anyone who has ever sent me feedback on a document I've authored/co-authored knows I do my best to address all feedback, no matter whether that implies re-writing large portions of the document in question.) Make the spec as clear as possible save time and energy on all sides. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From huitema@microsoft.com Tue Apr 23 17:46:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BA721F937B; Tue, 23 Apr 2013 17:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhNI8O6T2JzK; Tue, 23 Apr 2013 17:46:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id A9DDF21F89DB; Tue, 23 Apr 2013 17:46:21 -0700 (PDT) Received: from BL2FFO11FD028.protection.gbl (10.173.161.204) by BL2FFO11HUB039.protection.gbl (10.173.160.245) with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 24 Apr 2013 00:46:20 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD028.mail.protection.outlook.com (10.173.161.107) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 24 Apr 2013 00:46:20 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Wed, 24 Apr 2013 00:45:12 +0000 From: Christian Huitema To: Fernando Gont Subject: RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06 Thread-Topic: last call comments for draft-ietf-6man-stable-privacy-addresses-06 Thread-Index: AQHOPyGOslmR5sKVOkuNgHIrtQl435jiaE2AgAAElACAADKDgIABYycggABV7wCAADE0IA== Date: Wed, 24 Apr 2013 00:45:12 +0000 Message-ID: References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> <51758E1F.80803@si6networks.com> <51770022.3050401@si6networks.com> In-Reply-To: <51770022.3050401@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(23726002)(49866001)(50986001)(33656001)(6806003)(47736001)(16406001)(4396001)(47976001)(55846006)(56816002)(76482001)(66066001)(50466001)(47776003)(44976003)(53806001)(63696002)(20776003)(81342001)(56776001)(46406003)(74502001)(51856001)(69226001)(79102001)(54356001)(81542001)(80022001)(47446002)(46102001)(74662001)(54316002)(59766001)(77982001)(31966008)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB039; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0826B2F01B Cc: "draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org" , "6man@ietf.org" <6man@ietf.org>, Bob Hinden , IETF Discussion , Eliot Lear X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:46:24 -0000 > If I'm the guy producing a spec, my goal is to produce a spec that is cle= ar as possible, and only leave open those bits that are necessary to leave = open. Well, that might work for internal specs when you are managing a project, b= ut that's probably not the right way to approach standards. A standard, bei= ng the rules of the network, shall only constrain what must be constrained = for interoperability.=20 All implementations are tradeoffs. Developers will necessarily make them, b= ased on the different resource, priorities, usage scenarios. It is much bet= ter to explain to give clear guidelines than to merely mandate an implement= ation. -- Christian Huitema From fgont@si6networks.com Tue Apr 23 18:28:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7821F931E; Tue, 23 Apr 2013 18:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Igu+3NE-ZqZ; Tue, 23 Apr 2013 18:28:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 07C0F21F910E; Tue, 23 Apr 2013 18:28:55 -0700 (PDT) Received: from [186.134.53.35] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UUoVo-0002ly-A7; Wed, 24 Apr 2013 03:28:44 +0200 Message-ID: <51773526.9010605@si6networks.com> Date: Tue, 23 Apr 2013 20:28:06 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Huitema Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06 References: <5174D69F.6090300@cisco.com> <51755FE9.9060809@si6networks.com> <517563C0.6000508@cisco.com> <51758E1F.80803@si6networks.com> <51770022.3050401@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org" , "6man@ietf.org" <6man@ietf.org>, Bob Hinden , IETF Discussion , Eliot Lear X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 01:28:56 -0000 On 04/23/2013 07:45 PM, Christian Huitema wrote: >> If I'm the guy producing a spec, my goal is to produce a spec that >> is clear as possible, and only leave open those bits that are >> necessary to leave open. > > Well, that might work for internal specs when you are managing a > project, but that's probably not the right way to approach standards. That probably depends on *what* you're specifying (please see below). > A standard, being the rules of the network, shall only constrain what > must be constrained for interoperability. This document is not about a rule of the network, but about a local policy. Therefore, by definition, as long as the address you select is unique, nothing in this document will affect interoperability. > All implementations are tradeoffs. Developers will necessarily make > them, based on the different resource, priorities, usage scenarios. > It is much better to explain to give clear guidelines than to merely > mandate an implementation. We probably have different views here. We're not mandating an implementation (e.g., we're not mandating any specific PRF for F(), nor how you store addresses in memory if you do store them). I see the algorithm in this document as giving more room for tradeoffs to developers than RFC4941, and the same room for tradeoffs as e.g. RFC6528. Based on the above, me, I don't find the idea of re-writing the I-D compelling -- particularly at this point in time. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From sm@elandsys.com Tue Apr 23 15:13:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00CF21F95F0; Tue, 23 Apr 2013 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKcNAsPj1YfF; Tue, 23 Apr 2013 15:13:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8F621F95EF; Tue, 23 Apr 2013 15:13:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3NMDitk000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Apr 2013 15:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366755236; bh=ERwTH1BDUoIwteito5UjHnWnKq8R0tt7UbjWvIG8DME=; h=Date:To:From:Subject:Cc; b=sEO/9UCyByAdGiifx27EhOfcsubOc4NJRGV1111rqaXw3IWbjGThmDI77RM4TlD9R bviA2IKnsUYEDn0BU1pBmTeSfvrUlpjggRunpBcF67KOL2baJWINtOM8ZWEdgzoVIW 95ywRudMOdM3tQLNPPIRUyalFi3u9PJnzSAwTSp8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366755236; i=@elandsys.com; bh=ERwTH1BDUoIwteito5UjHnWnKq8R0tt7UbjWvIG8DME=; h=Date:To:From:Subject:Cc; b=OpokPEwc0KhO3dOnAYeFG+rC4OZLM4iEjidw8rHgUcGXRA4SGwEkCG8L+nqrHNABR Wn8yLv6u/XNG+Lic0YJX7F+vjhLyHQsbVgLO3GmHlZZWjSoxKyBpHWr5YZOHvGXlvZ lpJFyLMdimsndSn1X6qqIjkRMNYzFyYOSmI1D1/Q= Message-Id: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Apr 2013 14:59:58 -0700 To: ipv6@ietf.org From: S Moonesamy Subject: IPv4 mapped IPv6 addresses Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 23 Apr 2013 23:55:58 -0700 Cc: spfbis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 22:13:58 -0000 Hello, Section 5 of draft-ietf-spfbis-4408bis-14 has the following text: 'When any mechanism fetches host addresses to compare with , when is an IPv4, "A" records are fetched; when is an IPv6 address, "AAAA" records are fetched. SPF implementations on IPv6 servers need to handle both "AAAA" and "A" secords, for clients on IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only listed in an SPF record using the "ip4" mechanism.' Is the text about "IPv4 mapped IPv6 addresses" correct? Regards, S. Moonesamy (as document shepherd) From simon.perreault@viagenie.ca Wed Apr 24 01:31:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7032621F8F0F; Wed, 24 Apr 2013 01:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHf5dI+-F79g; Wed, 24 Apr 2013 01:31:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id F033221F8E9A; Wed, 24 Apr 2013 01:31:05 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2346E40432; Wed, 24 Apr 2013 04:31:05 -0400 (EDT) Message-ID: <51779847.6060608@viagenie.ca> Date: Wed, 24 Apr 2013 10:31:03 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy Subject: Re: IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 08:31:06 -0000 Le 2013-04-23 23:59, S Moonesamy a écrit : > Section 5 of draft-ietf-spfbis-4408bis-14 has the following text: > > 'When any mechanism fetches host addresses to compare with , when > is an IPv4, "A" records are fetched; when is an IPv6 > address, "AAAA" records are fetched. SPF implementations on IPv6 > servers need to handle both "AAAA" and "A" secords, for clients on > IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only > listed in an SPF record using the "ip4" mechanism.' > > Is the text about "IPv4 mapped IPv6 addresses" correct? I, for one, have no idea what a "client on IPv4-mapped IPv6 address" might be. So the text doesn't look correct to me. If you describe in a little bit more detail what the intent is, we can help you reformulate. Simon From simon.perreault@viagenie.ca Wed Apr 24 04:33:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF7521F8EF2; Wed, 24 Apr 2013 04:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCi4F3UE9JBq; Wed, 24 Apr 2013 04:33:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B721F8EEB; Wed, 24 Apr 2013 04:33:24 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A67D040432; Wed, 24 Apr 2013 07:33:23 -0400 (EDT) Message-ID: <5177C301.1090605@viagenie.ca> Date: Wed, 24 Apr 2013 13:33:21 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy Subject: Re: IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <51779847.6060608@viagenie.ca> <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 11:33:25 -0000 Le 2013-04-24 11:54, S Moonesamy a écrit : > Hi Simon, > At 01:31 24-04-2013, Simon Perreault wrote: >> I, for one, have no idea what a "client on IPv4-mapped IPv6 address" >> might be. So the text doesn't look correct to me. >> >> If you describe in a little bit more detail what the intent is, we can >> help you reformulate. > > Thanks for feedback. > > For context the text is in the ninth paragraph of Section 5 of > draft-ietf-spfbis-4408bis-14. I'll rewrite the text as follows: > > SPF implementations on IPv6 servers need to handle both "AAAA" and > "A" DNS records, for SMTP clients on IPv4 mapped IPv6 addresses > [RFC4291]. I'm sorry, I've read section 5 and that still doesn't make sense to me. > The intent seems to be about an IPv4 host (client) connecting to an IPv6 > host (server). How does that work? Is there a NAT46 in between? > The IPv6 host matches the source IP address of the TCP > connection against a list which may contain IPv4 mapped IPv6 addresses. > Does that make sense or it is easier to forget about "IPv4 mapped IPv6 > addresses"? As IPv4-mapped IPv6 addresses do not go on the wire, this still doesn't make sense to me! IPv4-mapped IPv6 addresses have two uses: 1) They are used internally on a single host, between a userland app and the kernel, to represent IPv4 addresses using an IPv6-only socket. The address never leaves the host. It can be considered an implementation detail. They are most useful when porting an IPv4-only app to dual-stack. Newer applications should never use IPv4-mapped IPv6 addresses, and it is good practice to disable them explicitly. 2) In various signalling protocols, to represent an IPv4 address in an IPv6 address field. This is protocol-specific. It is used only for signalling, never as actual addresses in IPv6 packet headers. At this point, I'm guessing that it would be better to forget about IPv4-mapped IPv6 addresses, although I still don't understand exactly what your intent is. Simon From sm@elandsys.com Wed Apr 24 02:58:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45AF21F8EB2; Wed, 24 Apr 2013 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pgkWqHHkwh5; Wed, 24 Apr 2013 02:58:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 344AF21F8EB1; Wed, 24 Apr 2013 02:58:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3O9wFmw024324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 02:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366797508; bh=DK/yUX072NwD7REUE6MXD09gEWPLq7M8DyAD4lPIV54=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VCucx4icCnHACFqIjLrFKFdJzA7ym8STWrUnrhzcA/Ee1uh3Y50JT2gTK5Fvh3jRW d1LUCpjTkQSewSWD4WnY0rWH+pSV6Qo4i0BRRWlCdKfLLMzSBUir5LOl5M/PajTwDV c2s8k5XYC/Od/AbIsnQvbQg7uNOH9p5d3E0QL6bQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366797508; i=@elandsys.com; bh=DK/yUX072NwD7REUE6MXD09gEWPLq7M8DyAD4lPIV54=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=t7oSpLtuCw5bKlrYaBiYY6wI9B+qdUupWPkEHFj+v2m6iUwcxE0tRiLvnX9R5EJtM oBDhQesVd12wHVwDEr/7yLE+noYY6bv6ofU9ihl8rZhf+0CtsDKmLH75pJYj1AqSwa WbP+xnZUmaZBBCjT27jh4rZKNVNjZmhOJIaEx3bw= Message-Id: <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 02:54:03 -0700 To: Simon Perreault From: S Moonesamy Subject: Re: IPv4 mapped IPv6 addresses In-Reply-To: <51779847.6060608@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <51779847.6060608@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 24 Apr 2013 07:30:24 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 09:58:30 -0000 Hi Simon, At 01:31 24-04-2013, Simon Perreault wrote: >I, for one, have no idea what a "client on IPv4-mapped IPv6 address" >might be. So the text doesn't look correct to me. > >If you describe in a little bit more detail what the intent is, we >can help you reformulate. Thanks for feedback. For context the text is in the ninth paragraph of Section 5 of draft-ietf-spfbis-4408bis-14. I'll rewrite the text as follows: SPF implementations on IPv6 servers need to handle both "AAAA" and "A" DNS records, for SMTP clients on IPv4 mapped IPv6 addresses [RFC4291]. The intent seems to be about an IPv4 host (client) connecting to an IPv6 host (server). The IPv6 host matches the source IP address of the TCP connection against a list which may contain IPv4 mapped IPv6 addresses. Does that make sense or it is easier to forget about "IPv4 mapped IPv6 addresses"? Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Wed Apr 24 07:12:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6221F931E; Wed, 24 Apr 2013 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93y8yvLKv82E; Wed, 24 Apr 2013 07:12:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DF021F930C; Wed, 24 Apr 2013 07:12:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OEC4EM006081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 07:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366812736; bh=kul8m3yeaAYVHbM+Uil0SXukBuZczkd772D54CPddUc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1huPtUqBmCU4Ika10ML9IcO8I7E4yqZN+zn00LQeb3zROnsKgEa7+QDpiWgXE8VUg dz8qLHz676ruH5sdbfGgCCf7u0eHPjhIMeUIjM2Lpdoave/MO++Ta3X2VITK47zJz6 1PhCfCa5mh9AactC+77nQFWjcqWc1yQccCZIEzKc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366812736; i=@elandsys.com; bh=kul8m3yeaAYVHbM+Uil0SXukBuZczkd772D54CPddUc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jWRVJWpiB8tsB5v0o8lpFyz9lv1aCwGZHEzhgbipeuinI1EsxxwUxyFZPq1SJkjER vcQwW6P0unToe1yw+J4+nYYCn4o0lMkMafmhbSPAzS9TXAvQqJEyMXDzaH+JF2HuPZ FRsfTlBR0/HYUDA+pDUB3UkQXZ9tPE6GFSKaaaOA= Message-Id: <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 07:04:55 -0700 To: Simon Perreault From: S Moonesamy Subject: Re: IPv4 mapped IPv6 addresses In-Reply-To: <5177C301.1090605@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <51779847.6060608@viagenie.ca> <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> <5177C301.1090605@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 24 Apr 2013 07:30:24 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:12:18 -0000 Hi Simon, At 04:33 24-04-2013, Simon Perreault wrote: >I'm sorry, I've read section 5 and that still doesn't make sense to me. I share your opinion. >How does that work? Is there a NAT46 in between? That question was never discussed within the working group. My guess is that there would have to be a transition mechanism in between for that to work. >As IPv4-mapped IPv6 addresses do not go on the wire, this still >doesn't make sense to me! I should have explained it better; the IPv4-mapped IPv6 address does not go over the wire. >IPv4-mapped IPv6 addresses have two uses: > >1) They are used internally on a single host, between a userland app >and the kernel, to represent IPv4 addresses using an IPv6-only >socket. The address never leaves the host. It can be considered an >implementation detail. They are most useful when porting an >IPv4-only app to dual-stack. Newer applications should never use >IPv4-mapped IPv6 addresses, and it is good practice to disable them explicitly. > >2) In various signalling protocols, to represent an IPv4 address in >an IPv6 address field. This is protocol-specific. It is used only >for signalling, never as actual addresses in IPv6 packet headers. > >At this point, I'm guessing that it would be better to forget about >IPv4-mapped IPv6 addresses, although I still don't understand >exactly what your intent is. Thanks for the explanation. The intent was to ask the IPv6 Maintenance working group to review the text. I'll follow your guess as it makes sense to me. By the way you will be credited in the document shepherd write-up for your feedback. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Wed Apr 24 07:27:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1672C21F9195; Wed, 24 Apr 2013 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTTuA11jEYxn; Wed, 24 Apr 2013 07:26:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 93AFC21F90EB; Wed, 24 Apr 2013 07:26:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 52A9120E40FD; Wed, 24 Apr 2013 10:26:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366813617; bh=Rl4HLG+bzP6Pn1vCDO/2KPZFFC8ZVDasMipdndTcHUw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g/KNqeO9oOXq3tpbOtoWoHu19ICE9X6wiSEkQa015hJk8ZGi4PBszbexOxysV7xYB lu5lLtb6nsARv6q3jGQZqRdxRT8nIVhCheL8iwuuUxBjVUQNhVbb4DhybXXGzzN6cj J00IybM4d4UBpKRXIZwxlOUnxXdtYBz+eaYWyPhY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3701420E4076; Wed, 24 Apr 2013 10:26:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, Simon Perreault Subject: Re: [spfbis] IPv4 mapped IPv6 addresses Date: Wed, 24 Apr 2013 10:26:54 -0400 Message-ID: <1806292.8gPQCWSlJz@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177C301.1090605@viagenie.ca> <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 24 Apr 2013 07:30:24 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:27:00 -0000 On Wednesday, April 24, 2013 07:04:55 AM S Moonesamy wrote: > Hi Simon, > > At 04:33 24-04-2013, Simon Perreault wrote: > >I'm sorry, I've read section 5 and that still doesn't make sense to me. > > I share your opinion. > > >How does that work? Is there a NAT46 in between? > > That question was never discussed within the working group. My guess > is that there would have to be a transition mechanism in between for > that to work. > > >As IPv4-mapped IPv6 addresses do not go on the wire, this still > >doesn't make sense to me! > > I should have explained it better; the IPv4-mapped IPv6 address does > not go over the wire. > > >IPv4-mapped IPv6 addresses have two uses: > > > >1) They are used internally on a single host, between a userland app > >and the kernel, to represent IPv4 addresses using an IPv6-only > >socket. The address never leaves the host. It can be considered an > >implementation detail. They are most useful when porting an > >IPv4-only app to dual-stack. Newer applications should never use > >IPv4-mapped IPv6 addresses, and it is good practice to disable them > >explicitly. > > > >2) In various signalling protocols, to represent an IPv4 address in > >an IPv6 address field. This is protocol-specific. It is used only > >for signalling, never as actual addresses in IPv6 packet headers. > > > >At this point, I'm guessing that it would be better to forget about > >IPv4-mapped IPv6 addresses, although I still don't understand > >exactly what your intent is. > > Thanks for the explanation. The intent was to ask the IPv6 > Maintenance working group to review the text. I'll follow your guess > as it makes sense to me. By the way you will be credited in the > document shepherd write-up for your feedback. It was discussed. The case here is #2. In SPF there are various mechanisms that can be used in an SPF record to identify sources from which mail is authorized. Two of these mechanisms directly specify IP addresses. "ip4" is used to specify IPv4 addresses and "ip6" is used to specify IPv6 addresses (that's a design decision that was made in 2003, so it is what it is). The intent of the text was to communicate that if the SPF verification process (which could possibly be running in any internet networking environment you might think of) were presented with an IPv4-mapped IPv6 address, the correct way to check if that address is authorized is using the IPv4 part of the address to check against an "ip4" mechanism. I hope that clarifies the intent. If that makes sense, I would really appreciate suggestions as a better way to word it. Scott K (4408bis editor) From simon.perreault@viagenie.ca Wed Apr 24 07:56:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76B21F91BC; Wed, 24 Apr 2013 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk8g+eVAeIen; Wed, 24 Apr 2013 07:56:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D51021F9380; Wed, 24 Apr 2013 07:56:37 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 971A0469F3; Wed, 24 Apr 2013 10:56:34 -0400 (EDT) Message-ID: <5177F2A1.304@viagenie.ca> Date: Wed, 24 Apr 2013 16:56:33 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman Subject: Re: [spfbis] IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177C301.1090605@viagenie.ca> <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> In-Reply-To: <1806292.8gPQCWSlJz@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:56:57 -0000 Le 2013-04-24 16:26, Scott Kitterman a écrit : > The case here is #2. In SPF there are various mechanisms that can be used in > an SPF record to identify sources from which mail is authorized. Two of these > mechanisms directly specify IP addresses. "ip4" is used to specify IPv4 > addresses and "ip6" is used to specify IPv6 addresses (that's a design > decision that was made in 2003, so it is what it is). > > The intent of the text was to communicate that if the SPF verification process > (which could possibly be running in any internet networking environment you > might think of) were presented with an IPv4-mapped IPv6 address, the correct > way to check if that address is authorized is using the IPv4 part of the > address to check against an "ip4" mechanism. > > I hope that clarifies the intent. Very clear. One problem I can think of: What is the effect of specifying IPv4-mapped IPv6 addresses in "ip6" SPF data? Or through a AAAA DNS record that the SPF "ip6" process looks up? If an SPF process that checks an IPv4-mapped IPv6 address uses exclusively the "ip4" SPF data, then IPv4-mapped IPv6 addresses in "ip6" data would be ignored. I would consider that surprising. For example, I would expect an SPF rule producing ::ffff:0.0.0.0/96 to apply to all IPv4-mapped IPv6 addresses, but it would simply get ignored. Generally you want to treat IPv4-mapped IPv6 addresses like regular, opaque IPv6 addresses unless you have good and specific reasons not to do so. Simon From spf2@kitterman.com Wed Apr 24 08:09:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5A921F89B2; Wed, 24 Apr 2013 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi5r41EhLfkc; Wed, 24 Apr 2013 08:09:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5721F8793; Wed, 24 Apr 2013 08:09:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6726120E40FD; Wed, 24 Apr 2013 11:09:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366816167; bh=ZKhVP4U3Z+bijTcZ8vTxeRR7hdG5N2q5LEN1eev+LxE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZluOPRibcA0cABRzGF8/DuRRZHCPABfZmfX2L/TapsV/3rLU9A5SlCMhheH3RuLKv uKiZrk9qMdO2koPriiM/7medGP+UlnyZoHRYzn51TTnnwPAyjv+3BqlMc0zJyxFwxg 8J71MROHKO2/M3XGo05CEIsMt7kLnQN+M15NOYlk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4C3C520E4076; Wed, 24 Apr 2013 11:09:26 -0400 (EDT) From: Scott Kitterman To: Simon Perreault , spfbis@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses Date: Wed, 24 Apr 2013 11:09:26 -0400 Message-ID: <1607352.HJyrPRpzgN@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <5177F2A1.304@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 24 Apr 2013 08:12:06 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 15:09:29 -0000 On Wednesday, April 24, 2013 04:56:33 PM Simon Perreault wrote: > Le 2013-04-24 16:26, Scott Kitterman a =E9crit : > > The case here is #2. In SPF there are various mechanisms that can = be used > > in an SPF record to identify sources from which mail is authorized.= Two > > of these mechanisms directly specify IP addresses. "ip4" is used t= o > > specify IPv4 addresses and "ip6" is used to specify IPv6 addresses > > (that's a design decision that was made in 2003, so it is what it i= s). > >=20 > > The intent of the text was to communicate that if the SPF verificat= ion > > process (which could possibly be running in any internet networking= > > environment you might think of) were presented with an IPv4-mapped = IPv6 > > address, the correct way to check if that address is authorized is = using > > the IPv4 part of the address to check against an "ip4" mechanism. > >=20 > > I hope that clarifies the intent. >=20 > Very clear. >=20 > One problem I can think of: >=20 > What is the effect of specifying IPv4-mapped IPv6 addresses in "ip6" = SPF > data? Or through a AAAA DNS record that the SPF "ip6" process looks u= p? > If an SPF process that checks an IPv4-mapped IPv6 address uses > exclusively the "ip4" SPF data, then IPv4-mapped IPv6 addresses in "i= p6" > data would be ignored. I would consider that surprising. For example,= I > would expect an SPF rule producing ::ffff:0.0.0.0/96 to apply to all > IPv4-mapped IPv6 addresses, but it would simply get ignored. >=20 > Generally you want to treat IPv4-mapped IPv6 addresses like regular, > opaque IPv6 addresses unless you have good and specific reasons not t= o > do so. My initial thought is you should have put that in an "ip4" mechanism. = Other=20 way around (which is the concern that caused the text to be added) if t= he=20 IPv4-mapped addresses are treated as IPv6 addresses, then senders who o= nly=20 used IPv4 might have to dual publish any IPv4 addresses in both "ip4" a= nd=20 "ip6" mechanisms. That's bad in many ways. The goal was to try and cover this case in a way that it was clear that= this=20 was the reciever's problem to sort out and the sender didn't have to do= uble=20 publish, just in case (I've seen people do this). Suggestions? Scott K From simon.perreault@viagenie.ca Wed Apr 24 08:15:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEF721F8FA4; Wed, 24 Apr 2013 08:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us2l38P-kygQ; Wed, 24 Apr 2013 08:15:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8721F8EB9; Wed, 24 Apr 2013 08:15:39 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5D05E4044A; Wed, 24 Apr 2013 11:15:38 -0400 (EDT) Message-ID: <5177F719.3050209@viagenie.ca> Date: Wed, 24 Apr 2013 17:15:37 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman Subject: Re: [spfbis] IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> <1607352.HJyrPRpzgN@scott-latitude-e6320> In-Reply-To: <1607352.HJyrPRpzgN@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 15:15:39 -0000 Le 2013-04-24 17:09, Scott Kitterman a écrit : > On Wednesday, April 24, 2013 04:56:33 PM Simon Perreault wrote: > My initial thought is you should have put that in an "ip4" mechanism. Other > way around (which is the concern that caused the text to be added) if the > IPv4-mapped addresses are treated as IPv6 addresses, then senders who only > used IPv4 might have to dual publish any IPv4 addresses in both "ip4" and > "ip6" mechanisms. That's bad in many ways. I guess I just don't understand where those IPv4-mapped IPv6 addresses that the SPF process needs to check are coming from. An example would be very helpful. > The goal was to try and cover this case in a way that it was clear that this > was the reciever's problem to sort out and the sender didn't have to double > publish, just in case (I've seen people do this). Yeah, this is bad. Variants arise in many situations. Usually it is solved by treating IPv6 addresses as opaque and not giving any special meaning to the IPv4-mapped prefix. Simon From pkern@simplex.0x539.de Wed Apr 24 09:10:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919A621F84A6; Wed, 24 Apr 2013 09:10:09 -0700 (PDT) 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=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3egbCmZxf7h0; Wed, 24 Apr 2013 09:10:09 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 027DD21F8DCF; Wed, 24 Apr 2013 09:10:08 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UV2GZ-0002it-Ll; Wed, 24 Apr 2013 18:09:55 +0200 Received: from [2001:470:720c:0:793a:99a:aedc:c0c3] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UV2Ga-0007yu-Tk; Wed, 24 Apr 2013 18:09:57 +0200 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UV2GY-0000LV-Er; Wed, 24 Apr 2013 18:09:54 +0200 Date: Wed, 24 Apr 2013 18:09:54 +0200 From: Philipp Kern To: Simon Perreault Subject: Re: [spfbis] IPv4 mapped IPv6 addresses Message-ID: <20130424160954.GA31835@simplex.0x539.de> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> <1607352.HJyrPRpzgN@scott-latitude-e6320> <5177F719.3050209@viagenie.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <5177F719.3050209@viagenie.ca> Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: spfbis@ietf.org, ipv6@ietf.org, Scott Kitterman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:10:09 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Simon, am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben: > I guess I just don't understand where those IPv4-mapped IPv6 > addresses that the SPF process needs to check are coming from. An > example would be very helpful. on Linux, if you set bindv6only to 0 and set up a socket listening on AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The source IPs will be mapped into IPv4-mapped IPv6 space. This means that you only need to setup one socket instead of one for v4 and one for v6. > Yeah, this is bad. Variants arise in many situations. Usually it is > solved by treating IPv6 addresses as opaque and not giving any > special meaning to the IPv4-mapped prefix. As above that does not help. If your SPF process is operating in the setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 ruleset. Kind regards Philipp Kern --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJReAPSAAoJEERuJUU10FbskDUH/08k/NZMl7bqrZR7RVpfISkB BZrCriX5lqVgibCmo3Z08iKp+AeCbRTFEkKDqjiirpgCF68fbSlY8mDEzyh3FeFM d6yz9f60SAJolEaQ4d19UKrJdeqHYo1jSwluq1COS8bEYmZLoC1k2bimZdtbaRzM pHm40WRgVsfpyKRkyYlGKlbieVZT8r6EzuRG0TOBdu70zBF9B+BdL9uDAz4nffBN sT+m43f2vVY7wzSCKA/wRdr7UYmPx3asla6C6hxXNT18K5sixARKAFK7aIHu0S3F wTVwH+Vbs5XBLklrxvsb+EdC6hakBr5y0kuWaRCpSctkWSI0RU06KH39U4/L6Jo= =l+vw -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From simon.perreault@viagenie.ca Wed Apr 24 09:27:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5419F21F92C4; Wed, 24 Apr 2013 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwlvsMMnENFD; Wed, 24 Apr 2013 09:27:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A3AAB21F9199; Wed, 24 Apr 2013 09:27:21 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B591A403E5; Wed, 24 Apr 2013 12:27:20 -0400 (EDT) Message-ID: <517807E7.2050005@viagenie.ca> Date: Wed, 24 Apr 2013 18:27:19 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Philipp Kern Subject: Re: [spfbis] IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> <1607352.HJyrPRpzgN@scott-latitude-e6320> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> In-Reply-To: <20130424160954.GA31835@simplex.0x539.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, ipv6@ietf.org, Scott Kitterman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:27:22 -0000 Le 2013-04-24 18:09, Philipp Kern a écrit : > Simon, > > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben: >> I guess I just don't understand where those IPv4-mapped IPv6 >> addresses that the SPF process needs to check are coming from. An >> example would be very helpful. > > on Linux, if you set bindv6only to 0 and set up a socket listening on > AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The > source IPs will be mapped into IPv4-mapped IPv6 space. This means that you > only need to setup one socket instead of one for v4 and one for v6. I know what an IPv4-mapped IPv6 address is. In that case, you should convert IPv4-mapped IPv6 addresses to IPv4 addresses before feeding them to the SPF checker. Just like with any other protocol. >> Yeah, this is bad. Variants arise in many situations. Usually it is >> solved by treating IPv6 addresses as opaque and not giving any >> special meaning to the IPv4-mapped prefix. > > As above that does not help. If your SPF process is operating in the > setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 > ruleset. The SPF process should never see IPv4-mapped IPv6 addresses since the underlying layer needs to convert them to IPv4 addresses. There is nothing specific to the SPF protocol here. Simon From spf2@kitterman.com Wed Apr 24 09:22:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149B621F9418; Wed, 24 Apr 2013 09:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4vO93AbkLd9; Wed, 24 Apr 2013 09:22:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E6E3721F93D8; Wed, 24 Apr 2013 09:22:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1624D20E40FD; Wed, 24 Apr 2013 12:22:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366820574; bh=Qu79qW+IurEfJ/yJSsvP9lWWoTK78drJIme8wIaEb+M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ITsE9Zwn3qe23KEhaltzpSNexEZvLMJAg+tqdhFD6UtF1uYelPnR11oeagjLVFSyS rAIR25xxH57K43roEPVaqmuYruqFgCCmwDhOirhs63Dva/FWWG0/7zwoBVZfVd7vAb oAr/N/tGj+O5BpBa8P4Tb4Kfcxy36vG/etciB6W8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F285420E4076; Wed, 24 Apr 2013 12:22:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses Date: Wed, 24 Apr 2013 12:22:52 -0400 Message-ID: <11888504.3H8g9Q4rip@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130424160954.GA31835@simplex.0x539.de> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 24 Apr 2013 09:31:30 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:22:56 -0000 On Wednesday, April 24, 2013 06:09:54 PM Philipp Kern wrote: > Simon, > > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben: > > I guess I just don't understand where those IPv4-mapped IPv6 > > addresses that the SPF process needs to check are coming from. An > > example would be very helpful. > > on Linux, if you set bindv6only to 0 and set up a socket listening on > AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The > source IPs will be mapped into IPv4-mapped IPv6 space. This means that you > only need to setup one socket instead of one for v4 and one for v6. > > > Yeah, this is bad. Variants arise in many situations. Usually it is > > solved by treating IPv6 addresses as opaque and not giving any > > special meaning to the IPv4-mapped prefix. > > As above that does not help. If your SPF process is operating in the > setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 > ruleset. That sounds right. Apparently I fail at describing it though. Going back to the current text in the document: Section 5 of draft-ietf-spfbis-4408bis-14: 'When any mechanism fetches host addresses to compare with , when is an IPv4, "A" records are fetched; when is an IPv6 address, "AAAA" records are fetched. SPF implementations on IPv6 servers need to handle both "AAAA" and "A" secords, for clients on IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only listed in an SPF record using the "ip4" mechanism.' I'd appreciate suggestions on making it clearer. Thanks, Scott K From simon.perreault@viagenie.ca Wed Apr 24 09:50:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1102521F937D for ; Wed, 24 Apr 2013 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX5YEfS9Y3aH for ; Wed, 24 Apr 2013 09:50:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 066DE21F9305 for ; Wed, 24 Apr 2013 09:50:54 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6E364403E5 for ; Wed, 24 Apr 2013 12:50:53 -0400 (EDT) Message-ID: <51780D6C.1070000@viagenie.ca> Date: Wed, 24 Apr 2013 18:50:52 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> <11888504.3H8g9Q4rip@scott-latitude-e6320> In-Reply-To: <11888504.3H8g9Q4rip@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:50:55 -0000 Le 2013-04-24 18:22, Scott Kitterman a écrit : >> on Linux, if you set bindv6only to 0 and set up a socket listening on >> AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The >> source IPs will be mapped into IPv4-mapped IPv6 space. This means that you >> only need to setup one socket instead of one for v4 and one for v6. > > That sounds right. Apparently I fail at describing it though. Going back to > the current text in the document: > > Section 5 of draft-ietf-spfbis-4408bis-14: > > 'When any mechanism fetches host addresses to compare with , when > is an IPv4, "A" records are fetched; when is an IPv6 > address, "AAAA" records are fetched. SPF implementations on IPv6 > servers need to handle both "AAAA" and "A" secords, for clients on > IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only > listed in an SPF record using the "ip4" mechanism.' This is very wrong. IPv4-mapped IPv6 addresses resulting from the use of AF_INET6 sockets with bindv6only=0 are an *implementation detail*. The draft should focus exclusively on externally-observable behaviour. Since there is no IPv4-mapped IPv6 address anywhere in the packets, you should not say anything at all. Doing otherwise is just creating confusion. Simon From simon.perreault@viagenie.ca Wed Apr 24 09:52:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE621F9425; Wed, 24 Apr 2013 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK6pQ3o2fdDO; Wed, 24 Apr 2013 09:52:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A5D2A21F9424; Wed, 24 Apr 2013 09:52:34 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1A2B2403E5; Wed, 24 Apr 2013 12:52:28 -0400 (EDT) Message-ID: <51780DCC.7020802@viagenie.ca> Date: Wed, 24 Apr 2013 18:52:28 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman Subject: Re: [spfbis] IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> In-Reply-To: <1620648.vNPTWAe3vH@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:52:42 -0000 X-List-Received-Date: Wed, 24 Apr 2013 16:52:42 -0000 Le 2013-04-24 18:46, Scott Kitterman a écrit : > So from your perspective, we could remove that guidance and replace it with > something along the lines of: > > Check_host() [that's our generic SPF validation function name we use in the > document] should never see IPv4-mapped IPv6 addresses. The underlying layer > needs to convert them to IPv4 addresses. > > Is that about right? Yes, that's perfect. Now, there's nothing specific to SPF here, but I don't know of any general guidelines that you could reference, so feel free to go ahead with that. Simon From spf2@kitterman.com Wed Apr 24 09:46:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E3721F8F4F; Wed, 24 Apr 2013 09:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzMCC8QNodtJ; Wed, 24 Apr 2013 09:46:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF9B821F8F12; Wed, 24 Apr 2013 09:46:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4DCB620E40FD; Wed, 24 Apr 2013 12:46:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366821990; bh=TmeCz1PzH6Ek36ldCvqRu4ZPNrf2eUVDjkh2d4zeD5I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qE0+hgi1x3lSCkAD0O5QY6rgGcc74o8V8fTtcIeDN+v6QnrnH1fzMd04Z6DJfC+rc +NCuJCxUZ2sHZ1jHct3yXzi4Obbtm8kJO3+BbMXstjfBJtxKoUXNUa/woWkGY/ERIC MtTModMm+/qkuU3R7I5nwWAFuQPVqikDeI29dEyo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3801620E4076; Wed, 24 Apr 2013 12:46:29 -0400 (EDT) From: Scott Kitterman To: Simon Perreault Subject: Re: [spfbis] IPv4 mapped IPv6 addresses Date: Wed, 24 Apr 2013 12:46:28 -0400 Message-ID: <1620648.vNPTWAe3vH@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517807E7.2050005@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 24 Apr 2013 09:53:21 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:46:31 -0000 On Wednesday, April 24, 2013 06:27:19 PM Simon Perreault wrote: > Le 2013-04-24 18:09, Philipp Kern a =E9crit : > > Simon, > >=20 > > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrie= ben: > >> I guess I just don't understand where those IPv4-mapped IPv6 > >> addresses that the SPF process needs to check are coming from. An > >> example would be very helpful. > >=20 > > on Linux, if you set bindv6only to 0 and set up a socket listening = on > > AF_INET6 you are able to receive IPv4 connections to that IPv6 sock= et. The > > source IPs will be mapped into IPv4-mapped IPv6 space. This means t= hat you > > only need to setup one socket instead of one for v4 and one for v6.= >=20 > I know what an IPv4-mapped IPv6 address is. >=20 > In that case, you should convert IPv4-mapped IPv6 addresses to IPv4 > addresses before feeding them to the SPF checker. Just like with any > other protocol. >=20 > >> Yeah, this is bad. Variants arise in many situations. Usually it i= s > >> solved by treating IPv6 addresses as opaque and not giving any > >> special meaning to the IPv4-mapped prefix. > >=20 > > As above that does not help. If your SPF process is operating in th= e > > setup above, IPv4-mapped IPv6 space needs to be treated with the IP= v4 > > ruleset. >=20 > The SPF process should never see IPv4-mapped IPv6 addresses since the= > underlying layer needs to convert them to IPv4 addresses. There is > nothing specific to the SPF protocol here. So from your perspective, we could remove that guidance and replace it = with=20 something along the lines of: Check_host() [that's our generic SPF validation function name we use in= the=20 document] should never see IPv4-mapped IPv6 addresses. The underlying = layer=20 needs to convert them to IPv4 addresses. Is that about right? Phil? Scott K From tom.taylor.stds@gmail.com Wed Apr 24 09:57:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C79B21F8B07; Wed, 24 Apr 2013 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxq-vcQ244+a; Wed, 24 Apr 2013 09:57:17 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85221F95A0; Wed, 24 Apr 2013 09:57:17 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1727907obq.31 for ; Wed, 24 Apr 2013 09:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QGHvGaWytNMn/6zT5Vh7YpQUvXuOrpM+SV7SaeBSX4M=; b=fLbLccgxEuXUV1Ytqi+yhQVyRx/34oICpTpOtmtQ4MeqZXH8AALPWfsc5NGWJRQHgY Re1QdNvjdYxpj3+QlJRw8TOFQwrVlJl91HHcmF/hgUBdjRdI1wOFLY1ZjjWdcoNtiUVU eXR+wB2jpzr77k4L4hv0jheWZynDKZnlvCnumAelWS3odIw2X3MDC15GBspG6BX/cEwT jUOpFY2E5HtuElvT3+TBL1PXM50YD/MWxDab+r90Tw8sL+Suf25WkdafVnJ4CXKAJCI6 YkMFQ+YkGwoL/c0BfTjMJyGRZ7Te2ybxl6HrmwpwdrXGiwqcINdoQ3805KJiB0fSJ2kv Ba5w== X-Received: by 10.60.160.165 with SMTP id xl5mr7430895oeb.61.1366822636861; Wed, 24 Apr 2013 09:57:16 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPSA id do4sm1553627oeb.0.2013.04.24.09.57.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 09:57:16 -0700 (PDT) Message-ID: <51780EEC.4000205@gmail.com> Date: Wed, 24 Apr 2013 12:57:16 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman Subject: Re: [spfbis] IPv4 mapped IPv6 addresses References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> <11888504.3H8g9Q4rip@scott-latitude-e6320> In-Reply-To: <11888504.3H8g9Q4rip@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:57:18 -0000 Could I suggest the following: - Keep the first sentence unchanged. - Then: SPF implementations on IPv6 servers need to handle both "AAAA" and "A" records. This is because clients on IPv4 mapped IPv6 addresses [RFC4291] will appear to the SPF implementation as IPv4 clients. Complementarily to this, SPF records for such clients must contain only IPv4 addresses. On 24/04/2013 12:22 PM, Scott Kitterman wrote: > On Wednesday, April 24, 2013 06:09:54 PM Philipp Kern wrote: ... >> As above that does not help. If your SPF process is operating in the >> setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 >> ruleset. > > That sounds right. Apparently I fail at describing it though. Going back to > the current text in the document: > > Section 5 of draft-ietf-spfbis-4408bis-14: > > 'When any mechanism fetches host addresses to compare with , when > is an IPv4, "A" records are fetched; when is an IPv6 > address, "AAAA" records are fetched. SPF implementations on IPv6 > servers need to handle both "AAAA" and "A" secords, for clients on > IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only > listed in an SPF record using the "ip4" mechanism.' > > I'd appreciate suggestions on making it clearer. > > Thanks, > > Scott K > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From pkern@simplex.0x539.de Wed Apr 24 11:51:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023C121F8EF5; Wed, 24 Apr 2013 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFY5ddIPMb0L; Wed, 24 Apr 2013 11:51:07 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id DE02121F8EC9; Wed, 24 Apr 2013 11:51:01 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UV4lp-0005WB-43; Wed, 24 Apr 2013 20:50:21 +0200 Received: from [2001:470:720c:0:793a:99a:aedc:c0c3] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UV4lb-0008Lz-B3; Wed, 24 Apr 2013 20:50:07 +0200 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UV4la-0002F2-2z; Wed, 24 Apr 2013 20:50:06 +0200 Date: Wed, 24 Apr 2013 20:50:05 +0200 From: Philipp Kern To: Scott Kitterman Subject: Re: [spfbis] IPv4 mapped IPv6 addresses Message-ID: <20130424185005.GB8393@simplex.0x539.de> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> <3088486.LRMBpqBOZF@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3088486.LRMBpqBOZF@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: spfbis@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:51:11 -0000 On Wed, Apr 24, 2013 at 12:55:19PM -0400, Scott Kitterman wrote: > Thanks. I'll use that unless Phil responds and it turns out you two need to > argue some more. I don't think so, that seems fine. ;-) Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists somewhere already. Kind regards Philipp Kern From spf2@kitterman.com Wed Apr 24 09:55:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2832421F8B07; Wed, 24 Apr 2013 09:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysfJaB-1-myv; Wed, 24 Apr 2013 09:55:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33B21F8793; Wed, 24 Apr 2013 09:55:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A45720E40FD; Wed, 24 Apr 2013 12:55:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366822520; bh=EZovo0k3YZc2bzC4lnc1l2QWXKtM/n7YmWgvsxFtY3s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GeJMnLhXWDJIjY/tXjuRZsfG3ePLkJ0RRPTgl0qbNAKL8P3QxfaXPNg+xuRfNHadz n5kW9/7m8GK2+Knzby3HK1eyC54bnIwCBJ4aeDfn/pH9la7yIrdTUUyqtWZ27vu9FR 5Yf+41GCo4SCdlarfcCdzsi7FtDVBBpePSf+gwoQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7912920E4076; Wed, 24 Apr 2013 12:55:20 -0400 (EDT) From: Scott Kitterman To: Simon Perreault , spfbis@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses Date: Wed, 24 Apr 2013 12:55:19 -0400 Message-ID: <3088486.LRMBpqBOZF@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51780DCC.7020802@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 24 Apr 2013 13:01:43 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 16:55:23 -0000 On Wednesday, April 24, 2013 06:52:28 PM Simon Perreault wrote: > Le 2013-04-24 18:46, Scott Kitterman a =E9crit : > > So from your perspective, we could remove that guidance and replace= it > > with > > something along the lines of: > >=20 > > Check_host() [that's our generic SPF validation function name we us= e in > > the > > document] should never see IPv4-mapped IPv6 addresses. The underly= ing > > layer needs to convert them to IPv4 addresses. > >=20 > > Is that about right? >=20 > Yes, that's perfect. >=20 > Now, there's nothing specific to SPF here, but I don't know of any > general guidelines that you could reference, so feel free to go ahead= > with that. Thanks. I'll use that unless Phil responds and it turns out you two ne= ed to=20 argue some more. Scott K From superuser@gmail.com Wed Apr 24 11:10:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413C821F89D8; Wed, 24 Apr 2013 11:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbO9Osb21t6b; Wed, 24 Apr 2013 11:10:39 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36C21F8976; Wed, 24 Apr 2013 11:10:39 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id l13so7677067wie.16 for ; Wed, 24 Apr 2013 11:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ba8cvBvljJ0I+Lc8i6w0UiQFV/3IQL0JAqD+Hzi/Z5E=; b=VWTo0AuegogLUtKJDMZgNwypS5EBNf/DZTtuILvcslOwS0XU+0wOdCHTT2hsmGKTAm 73NTUaGOl9mht+a5xRzjwGjQj5tE92rp2hN2vMhWIP15Ynhhugd/tXTLIFDuPr3wVA2u ttaPFD25hyBvPNh75S8niZMpWNZqake1B35cWeGrgATdz83gqZc66EkYnG06S2tKs14E i/ckpPqocC2TLvxsnuwvzgZDOQahKaKdMqs8wtQHC3qktmwIeTofLkUdqcmLLZjKI0Ru +737ip1JEIzEDf5G/AvSvqnkbrpw/BFQ1/eLZBIPARWILoZB6KEVzJE1Z4E70XO/+Wca idVw== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr6988662wib.20.1366827036675; Wed, 24 Apr 2013 11:10:36 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 11:10:36 -0700 (PDT) In-Reply-To: <51780DCC.7020802@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> Date: Wed, 24 Apr 2013 11:10:36 -0700 Message-ID: Subject: Re: [spfbis] IPv4 mapped IPv6 addresses From: "Murray S. Kucherawy" To: Simon Perreault Content-Type: multipart/alternative; boundary=f46d043c094efd937a04db1f376d X-Mailman-Approved-At: Wed, 24 Apr 2013 13:01:43 -0700 Cc: "spfbis@ietf.org" , ipv6@ietf.org, Scott Kitterman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:10:40 -0000 --f46d043c094efd937a04db1f376d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 24, 2013 at 9:52 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2013-04-24 18:46, Scott Kitterman a =E9crit : > > So from your perspective, we could remove that guidance and replace it >> with >> something along the lines of: >> >> Check_host() [that's our generic SPF validation function name we use in >> the >> document] should never see IPv4-mapped IPv6 addresses. The underlying >> layer >> needs to convert them to IPv4 addresses. >> >> Is that about right? >> > > Yes, that's perfect. > > Now, there's nothing specific to SPF here, but I don't know of any genera= l > guidelines that you could reference, so feel free to go ahead with that. > > I like this, but I would change "needs" to "is expected". (And be careful with "should".) -MSK --f46d043c094efd937a04db1f376d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 9:52 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2013-04-24 18:= 46, Scott Kitterman a =E9crit :

So from your perspective, we could remove that guidance and replace it with=
something along the lines of:

Check_host() [that's our generic SPF validation function name we use in= the
document] should never see IPv4-mapped IPv6 addresses. =A0The underlying la= yer
needs to convert them to IPv4 addresses.

Is that about right?

Yes, that's perfect.

Now, there's nothing specific to SPF here, but I don't know of any = general guidelines that you could reference, so feel free to go ahead with = that.


I like this, but I would= change "needs" to "is expected".=A0 (And be careful wi= th "should".)

-MSK

--f46d043c094efd937a04db1f376d-- From internet-drafts@ietf.org Wed Apr 24 21:18:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6E221F9399; Wed, 24 Apr 2013 21:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtXqTRPYjE-o; Wed, 24 Apr 2013 21:18:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4345321F937D; Wed, 24 Apr 2013 21:18:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-impatient-nud-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425041812.5443.66220.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 21:18:12 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 04:18:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Neighbor Unreachability Detection is too impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-06.txt Pages : 9 Date : 2013-04-24 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor, for instance when there are multiple default routers, since it allows the host to switch to the alternative neighbor in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternative neighbors, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-impatient-nud-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Apr 25 01:32:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F421F9433; Thu, 25 Apr 2013 01:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85uJ8F-R098w; Thu, 25 Apr 2013 01:32:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE1B21F93DA; Thu, 25 Apr 2013 01:32:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425083231.9382.85037.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 01:32:31 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 08:32:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-addr-select-opt-09.txt Pages : 10 Date : 2013-04-25 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From n@arifumi.net Thu Apr 25 01:36:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA0A21F92BD for ; Thu, 25 Apr 2013 01:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7FNLv7jlc88 for ; Thu, 25 Apr 2013 01:36:45 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55021F93D8 for ; Thu, 25 Apr 2013 01:36:45 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id 10so1670208pdi.1 for ; Thu, 25 Apr 2013 01:36:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=75dhnyvZ8mdXtE1yYTYlqFF64DWyg9gBqF+Iid7SUEk=; b=ATVR9rDNff+PACLLJoV3owbrEHF2DmvqvA02ct5BfVL4ksCRpwnj/OvQYgZAPin+4f YSQuxKlSM8yrz339qy7FN/h2K3Y3ZqOa4ucEPeQSTc4hqirLw+4tOnqvyb9VXu+cEHwW c/Z3z5geiCvXmp92cPgFfYaV9Nw6l7W8H9e2mKXnHMbWCnSnPh0B36g8rYS/u8gwA1XG wtYMOyG3R65sQX6Cw+RuNQ2ahq60RqgMrnsZAbEjpm036fihPah50ZN59SEXnkP18viy ae7ZgMJoFNs1044x32grNdb8mK35UWmwRzlhG9htM1mB4X2TDIm7aWCsTptvliiY+AG3 yfAg== MIME-Version: 1.0 X-Received: by 10.68.252.201 with SMTP id zu9mr35699944pbc.119.1366879005409; Thu, 25 Apr 2013 01:36:45 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.117.208 with HTTP; Thu, 25 Apr 2013 01:36:45 -0700 (PDT) X-Originating-IP: [192.47.162.190] In-Reply-To: <515DE537.8020308@innovationslab.net> References: <513E28D9.5050303@innovationslab.net> <515DE537.8020308@innovationslab.net> Date: Thu, 25 Apr 2013 17:36:45 +0900 X-Google-Sender-Auth: NZ3EWd20d2_m1Qm0ph5E1k308i0 Message-ID: Subject: Re: DHC Review of draft-ietf-6man-addr-select-opt From: Arifumi Matsumoto To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b16382d91925d04db2b51c2 X-Gm-Message-State: ALoCoQkfaY6H4R9+17QsY+UzJGa3ydClbgZwWbLS1vhg7aLe/Iyw4/T5trCbqmz/732jlm1aksmt Cc: "dhc-chairs@tools.ietf.org" , "draft-ietf-6man-addr-select-opt@tools.ietf.org" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 08:36:46 -0000 --047d7b16382d91925d04db2b51c2 Content-Type: text/plain; charset=ISO-8859-1 All, I compiled the suggested changes. Thanks. ----- A new version of I-D, draft-ietf-6man-addr-select- opt-09.txt has been successfully submitted by Arifumi Matsumoto and posted to the IETF repository. Filename: draft-ietf-6man-addr-select-opt Revision: 09 Title: Distributing Address Selection Policy using DHCPv6 Creation date: 2013-04-25 Group: 6man Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-09.txt Status: http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt Htmlized: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-09 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. 2013/4/5 Brian Haberman > All, > Given the involvement of DHCPv6 in this draft, I requested a review > by the DHC WG. The following is the feedback received. I would like to > see these issues resolved soon and encourage the authors to engage the DHC > reviewers as needed. > > Regards, > Brian > > ---- > > There was a request from an Int Area Directory to have "dhcp" review of > the draft-ietf-6man-addr-select-**opt document. Based on a review by Ted > Lemon, Tomek Mrugalski, and Bernie Volz, the following issues were raised: > > > 1. The text regarding the prefix in the OPTION_ADDRSEL_TABLE option needs > to be improved - it currently allows someone to send all 16 octets rather > than the "minimum" required - int(prefix-len+7)/8). Please see > http://datatracker.ietf.org/**doc/draft-ietf-dhc-option-**guideline, > 5.3. Option with IPv6 prefix. > > 2. Section 3 should be dropped. This is a standard "other configuration > option" and the client and server requirements for these are best left to > RFC 3315. The current text has some mistakes and omissions if it were to > duplicate what RFC 3315 already explains, and doing so risks > inconsistencies, omissions, or conflicts which are best avoided. > ------------------------------**------------------------------**-------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6 > ------------------------------**------------------------------**-------- > --047d7b16382d91925d04db2b51c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I compiled the suggested chang= es.

Thanks.

-----
A new version = of I-D, draft-ietf-6man-addr-select-
opt-09.txt
has been successfully submitted by Arifumi Matsumoto and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-6man-addr-select-opt
Revision: =A0 =A0 =A0 =A009
Title: =A0 =A0 =A0 =A0 =A0 Distributing Address Selection Policy using DHCP= v6
Creation date: =A0 2013-04-25
Group: =A0 =A0 =A0 =A0 =A0 6man
Number of pages: 10
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.= org/internet-drafts/draft-ietf-6man-addr-select-opt-09.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/d= oc/draft-ietf-6man-addr-select-opt
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-= ietf-6man-addr-select-opt-09
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-09

Abstract:
=A0 =A0RFC 6724 defines default address selection mechanisms for IPv6 that<= br> =A0 =A0allow nodes to select an appropriate address when faced with multipl= e
=A0 =A0source and/or destination addresses to choose between. =A0The RFC 67= 24
=A0 =A0allowed for the future definition of methods to administratively
=A0 =A0configure the address selection policy information. =A0This document=
=A0 =A0defines a new DHCPv6 option for such configuration, allowing a site<= br> =A0 =A0administrator to distribute address selection policy overriding the<= br> =A0 =A0default address selection parameters and policy table, and thus
=A0 =A0control the address selection behavior of nodes in their site.


2013/4/5 Brian Haberman <brian@innovationsla= b.net>
All,
=A0 =A0 =A0Given the involvement of DHCPv6 in this draft, I requested a rev= iew by the DHC WG. =A0The following is the feedback received. =A0I would li= ke to see these issues resolved soon and encourage the authors to engage th= e DHC reviewers as needed.

Regards,
Brian

----

There was a request from an Int Area Directory to have "dhcp" rev= iew of the draft-ietf-6man-addr-select-opt document. Based on a revi= ew by Ted Lemon, Tomek Mrugalski, and Bernie Volz, the following issues wer= e raised:


1. The text regarding the prefix in the OPTION_ADDRSEL_TABLE option needs t= o be improved - it currently allows someone to send all 16 octets rather th= an the "minimum" required - int(prefix-len+7)/8). Please see http://datatracker.ietf.org/doc/draft-ietf-dhc-option= -guideline, 5.3. Option with IPv6 prefix.

2. Section 3 should be dropped. This is a standard "other configuratio= n option" and the client and server requirements for these are best le= ft to RFC 3315. The current text has some mistakes and omissions if it were= to duplicate what RFC 3315 already explains, and doing so risks inconsiste= ncies, omissions, or conflicts which are best avoided.
-------------------------------------------------------------= -------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------

--047d7b16382d91925d04db2b51c2-- From fgont@si6networks.com Thu Apr 25 07:01:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBBE21F93E8 for ; Thu, 25 Apr 2013 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnrGIPhUcNRQ for ; Thu, 25 Apr 2013 07:01:36 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2A07A21F9374 for <6man@ietf.org>; Thu, 25 Apr 2013 07:01:35 -0700 (PDT) Received: from [186.134.41.225] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UVMjk-0006qV-Jb; Thu, 25 Apr 2013 16:01:24 +0200 Message-ID: <5179372C.7000808@si6networks.com> Date: Thu, 25 Apr 2013 09:01:16 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org> Subject: LC comments on stable-privacy-addresses: Interface Index vs. name X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, RJ Atkinson , Brian Haberman , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 14:01:36 -0000 Folks, During IETF LC, a couple of folks noted that Interface Indexes might not be stable. I added some text on the subject to my working copy (mostly based on the discussion with Brian Haberman and Mark Smith), but the issue came up again (Tom Petch commented on the subject). Since the raison d'etre for including the Interface Index in F() is to differentiate between multiple interfaces connecting to the same network, either the Interface Index or the Interface Name could be used. So far, these are the pros/cons of each: * Interface Index: Including this one would be ideal, since it's simply a small number that identifies the interface, and does not really depend on the NIC vendor, etc. However, as noted above, in some implementations it might be unstable (i.e., vary when the system is bootstrapped). * Interface name: This one has the pro that is stable, even on systems in which the Interface Index is not. However, on some systems (e.g. BSDs) the Interface name depends on the NIC vendor, which means that if a NIC is replaced with another from a different vendor, the Interface name is likely to change, and therefore the resulting address will change. My take would be to replace "Interface Index" in the expression with an abstract "Interface_ID", and then explain that "Interfae_ID" can be either the Interface Index or the Interface name, and include some of the text above (explaining why an implementation might want to include one or the other -- i.e., if your Interface Indexes are stable, use them. Else use the Interface name). Thoughts? Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From iesg-secretary@ietf.org Thu Apr 25 08:04:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B1D21F8E87; Thu, 25 Apr 2013 08:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCM-dLL4hO+S; Thu, 25 Apr 2013 08:04:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6084821F8B07; Thu, 25 Apr 2013 08:04:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Neighbor Unreachability Detection is too impatient) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Sender: Message-ID: <20130425150452.13496.74796.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 08:04:52 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 15:04:53 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Neighbor Unreachability Detection is too impatient' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor, for instance when there are multiple default routers, since it allows the host to switch to the alternative neighbor in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternative neighbors, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/ballot/ No IPR declarations have been submitted directly on this I-D. From huitema@microsoft.com Thu Apr 25 08:44:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A68821F8536 for ; Thu, 25 Apr 2013 08:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+PzxiAfOfCI for ; Thu, 25 Apr 2013 08:44:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5446321F843F for <6man@ietf.org>; Thu, 25 Apr 2013 08:44:19 -0700 (PDT) Received: from BY2FFO11FD004.protection.gbl (10.1.15.203) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 15:42:02 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 15:42:02 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 15:41:36 +0000 From: Christian Huitema To: Fernando Gont , "6man@ietf.org" <6man@ietf.org> Subject: RE: LC comments on stable-privacy-addresses: Interface Index vs. name Thread-Topic: LC comments on stable-privacy-addresses: Interface Index vs. name Thread-Index: AQHOQb150Xk30MNB/UStZkr/hUGQNpjnEaJA Date: Thu, 25 Apr 2013 15:41:36 +0000 Message-ID: References: <5179372C.7000808@si6networks.com> In-Reply-To: <5179372C.7000808@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(81342001)(76482001)(77982001)(53806001)(65816001)(79102001)(59766001)(74366001)(47446002)(46102001)(44976003)(56816002)(54316002)(55846006)(80022001)(51856001)(50466002)(81542001)(63696002)(6806003)(50986001)(47736001)(69226001)(20776003)(16406001)(49866001)(47976001)(4396001)(31966008)(54356001)(33656001)(66066001)(23726002)(74662001)(46406003)(56776001)(74502001)(47776003); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , RJ Atkinson , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 15:44:20 -0000 > My take would be to replace "Interface Index" in the expression with an a= bstract "Interface_ID", and then explain that "Interfae_ID" can be either t= he=20 > Interface Index or the Interface name, and include some of the text above= (explaining why an implementation might want to include one or the other -= - i.e.,=20 > if your Interface Indexes are stable, use them. Else use the Interface na= me). I suggest that you just leave the choice to developers, based on the tradeo= ffs necessary for their particular implementations. I can see cases where I= would just use the MAC address, and others where the proper tradeoff is to= use nothing at all.=20 Just explain what the possible objectives are: 1) Stable address until reboot, versus forever 2) Stable address as long as the same MAC is used, versus stable address ev= en if cards are swapped 3) System design for multi homing, versus system design with just one netwo= rk connection It is unlikely that a single implementation will fit all cases. -- Christian Huitema From v6ops@globis.net Thu Apr 25 09:21:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6D321F94A4 for ; Thu, 25 Apr 2013 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeOxNLDOl1Yl for ; Thu, 25 Apr 2013 09:21:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4700221F873D for <6man@ietf.org>; Thu, 25 Apr 2013 09:21:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5C5E4870099; Thu, 25 Apr 2013 18:21:12 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwg2+39CADUa; Thu, 25 Apr 2013 18:21:12 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 31ECF87006F; Thu, 25 Apr 2013 18:21:12 +0200 (CEST) Message-ID: <517957F1.6060802@globis.net> Date: Thu, 25 Apr 2013 18:21:05 +0200 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Fernando Gont Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> In-Reply-To: <5179372C.7000808@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 16:21:29 -0000 Fernando Gont wrote: > Folks, > > During IETF LC, a couple of folks noted that Interface Indexes might not > be stable. > > I added some text on the subject to my working copy (mostly based on the > discussion with Brian Haberman and Mark Smith), but the issue came up > again (Tom Petch commented on the subject). > > Since the raison d'etre for including the Interface Index in F() is to > differentiate between multiple interfaces connecting to the same > network, either the Interface Index or the Interface Name could be used. > So far, these are the pros/cons of each: > > * Interface Index: Including this one would be ideal, since it's simply > a small number that identifies the interface, and does not really depend > on the NIC vendor, etc. However, as noted above, in some implementations > it might be unstable (i.e., vary when the system is bootstrapped). > > * Interface name: This one has the pro that is stable, even on systems > in which the Interface Index is not. However, on some systems (e.g. > BSDs) the Interface name depends on the NIC vendor, which means that if > a NIC is replaced with another from a different vendor, the Interface > name is likely to change, and therefore the resulting address will change. > > > My take would be to replace "Interface Index" in the expression with an > abstract "Interface_ID", and then explain that "Interfae_ID" can be > either the Interface Index or the Interface name, and include some of > the text above (explaining why an implementation might want to include > one or the other -- i.e., if your Interface Indexes are stable, use > them. Else use the Interface name). > > Thoughts? > > Thanks! Since both "Interface_Index" and "Interface name" are anyway both implementation dependent, why would you need to precisely standardise the exact meaning, or the exact source of the information? AFAICS this wouldn't significantly affect inter-op, or protocol operation. I therefore agree with your proposal that the text should define an abstract "Interface_ID" and suggest that you define "an Interface_ID is an implementation-dependent identifier associated with a particular interface on the local node, which is generally invariant over the long-term and over system reboots. The Interface_ID may be used to assist efficient generation of unique stable-privacy-addresses, especially in situations where multiple interfaces on a single node may be configured using the same L3 Prefix. If the Interface_ID does change for whatever reason, this would obviously undermine the time-invariance of the resulting stable-privacy-addresses." I don't think you need any more guidance than that. regards, RayH From fgont@si6networks.com Thu Apr 25 09:47:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E577821F9644 for ; Thu, 25 Apr 2013 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5BYnG2kAQHs for ; Thu, 25 Apr 2013 09:47:51 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 37A9621F94B1 for <6man@ietf.org>; Thu, 25 Apr 2013 09:47:50 -0700 (PDT) Received: from [186.134.41.225] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UVPKi-0002Nr-Gg; Thu, 25 Apr 2013 18:47:44 +0200 Message-ID: <51795E29.9070106@si6networks.com> Date: Thu, 25 Apr 2013 11:47:37 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ray Hunter Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> In-Reply-To: <517957F1.6060802@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 16:47:52 -0000 Hi, Ray, On 04/25/2013 11:21 AM, Ray Hunter wrote: > Since both "Interface_Index" and "Interface name" are anyway both > implementation dependent, why would you need to precisely standardise > the exact meaning, or the exact source of the information? AFAICS this > wouldn't significantly affect inter-op, or protocol operation. Their implementation (e.g. namespace) are implementation-dependent. Their properties may not. I don't care about the source of information as long as it meets the goal. Ideally, the I-D: * Should be constant across system bootstrap sequences * Should be different for each network interface * Should not change when the NIC is replaced The first to properties are needed for the "stability" properties of this scheme. The last one is needed such that the IPv6 address doesn't change when a NIC is replaced (I hear lots of people do not use SLAAC because of this). > I therefore agree with your proposal that the text should define an > abstract "Interface_ID" and suggest that you define "an Interface_ID is > an implementation-dependent identifier associated with a particular > interface on the local node, which is generally invariant over the > long-term and over system reboots. The Interface_ID may be used to > assist efficient generation of unique stable-privacy-addresses, > especially in situations where multiple interfaces on a single node may > be configured using the same L3 Prefix. If the Interface_ID does change > for whatever reason, this would obviously undermine the time-invariance > of the resulting stable-privacy-addresses." > > I don't think you need any more guidance than that. If you say just that, many will wonder "Ok, so what should I use for the Interface_ID?". So I'd probably list the three properties I mentioned above, and (non-normatively) note that the Interface Index or the Interface name could be used for this purpose... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Apr 25 09:50:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0068A21F963C for ; Thu, 25 Apr 2013 09:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh3PqmmHjiqi for ; Thu, 25 Apr 2013 09:50:16 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 60FE521F8DA6 for <6man@ietf.org>; Thu, 25 Apr 2013 09:50:16 -0700 (PDT) Received: from [186.134.41.225] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UVPN6-0002Um-Qz; Thu, 25 Apr 2013 18:50:13 +0200 Message-ID: <51795EBF.1080203@si6networks.com> Date: Thu, 25 Apr 2013 11:50:07 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Huitema Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 16:50:17 -0000 Hi, Christian, Thanks so much for your feedback! Please find my comments in-line... On 04/25/2013 10:41 AM, Christian Huitema wrote: >> My take would be to replace "Interface Index" in the expression >> with an abstract "Interface_ID", and then explain that >> "Interfae_ID" can be either the Interface Index or the Interface >> name, and include some of the text above (explaining why an >> implementation might want to include one or the other -- i.e., if >> your Interface Indexes are stable, use them. Else use the Interface >> name). > > I suggest that you just leave the choice to developers, based on the > tradeoffs necessary for their particular implementations. Yep, that's what I meant above. > I can see > cases where I would just use the MAC address, and others where the > proper tradeoff is to use nothing at all. I believe that using the MAC address would break the useful property that addresses do not depend on the underlying link-layer address (i.e., the IPv6 address does not change when the NIC is replaced). -- see my response to Ray Hunter. > Just explain what the possible objectives are: > > 1) Stable address until reboot, versus forever > > 2) Stable address as long as the same MAC is used, versus stable > address even if cards are swapped > > 3) System design for multi homing, versus system design with just one > network connection We really need: * Stable forever * Stable even if cards are swapped * Multi-homing is *not* a special case In particular, I'd really want people to know what they get when they use this. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From markzzzsmith@yahoo.com.au Thu Apr 25 14:13:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B3D21F868B for ; Thu, 25 Apr 2013 14:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7-7ZQPV4ZPR for ; Thu, 25 Apr 2013 14:13:33 -0700 (PDT) Received: from nm37-vm4.bullet.mail.bf1.yahoo.com (nm37-vm4.bullet.mail.bf1.yahoo.com [72.30.238.204]) by ietfa.amsl.com (Postfix) with ESMTP id 83A0A21F8618 for <6man@ietf.org>; Thu, 25 Apr 2013 14:13:30 -0700 (PDT) Received: from [98.139.215.143] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2013 21:13:29 -0000 Received: from [98.139.212.216] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2013 21:13:29 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 25 Apr 2013 21:13:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 465567.83113.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 85526 invoked by uid 60001); 25 Apr 2013 21:13:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1366924409; bh=h5cqwIAEHPZTLJOaNl4dh7ZjcRVqKQvP00bBYbR0ikM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GAp2q01CeEV2gDqSUFJ4Wncs9PillyknFIGUGL5vO8qBFxB4yTHwVbjrXt3tVuhHr5DbPYo1u+3WUFqBTUp8E1LMnrkZ7KpccvSFuwjMpq7+inkuxcOVtvvIkCAhkLZDhXIpF4NMqH9VsNHs2AHEYB9930c654qiPNt2q97QItQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ej/wpoCZiTvu3eEmPvqGZQjQaa/+SNyLisgaH+lniu53CTeIYAxCXro8M4uwmudqhAU1/W5kCHFgNobwzLxNO6XtW7u6sD2qJHCJ2lpXpCVi2wapQ/n6BNNVN/wDvabvDLNl8qHH4oiq1Qsz7NvM1e6QyS+1ufzLhW4c0NPdAyQ=; X-YMail-OSG: DGcybFEVM1mOCTrbhV40ftgz5Hs9bPnL.D6EPWS.jUn9na1 LxWqoMic09XGqoQswOWCgUpfRc5nD4yWde6lED9smFIatMzs.KqPY6MLPR3g .3gSb79QKl80BPBc9g6msCa949HyrLK4uKCe3YYcKqjY1rrLukGywrnrVjcY RAw5PHITcsBk7RtcMdXTNixnxLZrKRU0qgby2B3C9OQaG1UVkDeVAYyZjeQU JhZ_gr.Ee6RH77_Tmfa_7M85zWZcIKPxM0IWw16uiOa9WwNoKBNyRtuA3XdI .7AGbfUbjuFfeviV5dfzLsgD3dAi6Z74okdmc1qBi2xrMbH6CeiNQ0wFCq3e QDW1sf6ktkBSuP7M8QaMOtAQaJWKb.mPFyrG2w5oS6NpAwnCT8AbHOfTv6sn qHUZcykiqo5H2_SMFdtLglJre2gRgQJZ88qLp.uhEBsHAI6C8Ejje4QP0CTL ocW6CS_T1Gu9RsKGU6wlkMn_RMOXB3SQLtxXQbYb9YmPgFKZ0cs02zm1WFB7 WHvW8QmhTtEgYkn275aN1fygalPLCPA-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 25 Apr 2013 14:13:29 PDT X-Rocket-MIMEInfo: 002.001, SGkgRmVybmFuZG8sCgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPgo.VG86IFJheSBIdW50ZXIgPHY2b3BzQGdsb2Jpcy5uZXQ.IAo.Q2M6ICI2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgPDZtYW4tY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgQnJpYW4gSGFiZXJtYW4gPGJyaWFuQGlubm92YXRpb25zbGFiLm5ldD47ICI2bWFuQGlldGYub3JnIiA8Nm1hbkBpZXRmLm9yZz47IFJKIEF0a2luc29uIDxyamEubGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> Message-ID: <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 25 Apr 2013 14:13:29 -0700 (PDT) From: Mark Smith Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name To: Fernando Gont , Ray Hunter In-Reply-To: <51795E29.9070106@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:13:34 -0000 Hi Fernando,=0A=0A=0A>________________________________=0A> From: Fernando G= ont =0A>To: Ray Hunter =0A>Cc: "6= man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>; Brian Haberman ; "6man@ietf.org" <6man@ietf.org>; RJ Atkinson ; t.petch =0A>Sent: Friday, 26 Apr= il 2013 2:47 AM=0A>Subject: Re: LC comments on stable-privacy-addresses: In= terface Index vs. name=0A> =0A>=0A>Hi, Ray,=0A>=0A>On 04/25/2013 11:21 AM, = Ray Hunter wrote:=0A>> Since both "Interface_Index" and "Interface name" ar= e anyway both=0A>> implementation dependent, why would you need to precisel= y standardise=0A>> the exact meaning, or the exact source of the informatio= n? AFAICS this=0A>> wouldn't significantly affect inter-op, or protocol ope= ration.=0A>=0A>Their implementation (e.g. namespace) are implementation-dep= endent.=0A>Their properties may not.=0A>=0A>I don't care about the source o= f information as long as it meets the=0A>goal. Ideally, the I-D:=0A>=0A>* S= hould be constant across system bootstrap sequences=0A>* Should be differen= t for each network interface=0A>* Should not change when the NIC is replace= d=0A>=0A=0AI think listing those desired properties would be useful, and th= en describing examples of actual interface identifiers that would qualify i= f available e.g., persistent ifindex values or persistent interface names.= =A0=0A=0AOne thing that has occurred to me is the interface identifier stab= ility you're looking for would probably be provided by deriving the interfa= ce ID from the system connector that is used to attach the network interfac= e to the system e.g. the PCI slot information. A swap of a failed interface= , despite changing the MAC address, will retain the same interface ID.=A0= =0A=0AThis gets a bit interesting when thinking about the USB NIC situation= . Plugging the USB NIC into different USB slots would change the interface = ID if the slot is used to assign it a persistent interface ID. OTOH, the MA= C address and other properties of the USB NIC (such as USB serial number if= it has one) would be constant, so they could be used to create a persisten= t interface ID for your purposes, despite the different USB slot used to at= tach it to the system. Perhaps that means different buses and/or connectors= would need different policies on interface ID assignment, and that could b= e mentioned in your Draft.=0A=0AAs another example of a convention, it seem= s that Fedora has adopted a convention of naming wired ethernet interfaces = based on whether they're attached to the motherboard (e.g, em0) or a PCI sl= ot / port and then virtual function if it has one (e.g. p4p1), so they're p= ersistent across boots or replacement. Yet they don't apply that to PCI att= ached wifi interfaces, which are still called wlanX.=0A=0AYou might also wa= nt to briefly cover persistent interface IDs for virtual interfaces e.g, br= idge virtual interfaces. Their only constant identifier may be their name -= under Linux for example, they seem to use the lowest numeric MAC address o= f the member interfaces, which can change if a new interface is added or th= e lowest MAC address interface is removed.=0A=0A=0A=0ARegards,=0AMark= . From fgont@si6networks.com Thu Apr 25 16:43:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87D921F96CD for ; Thu, 25 Apr 2013 16:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbdod+rZPSMA for ; Thu, 25 Apr 2013 16:43:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 18C2721F91A3 for <6man@ietf.org>; Thu, 25 Apr 2013 16:43:41 -0700 (PDT) Received: from [186.134.41.225] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UVVok-00059A-KS; Fri, 26 Apr 2013 01:43:11 +0200 Message-ID: <5179B5D7.9000100@si6networks.com> Date: Thu, 25 Apr 2013 20:01:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Smith Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Ray Hunter , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:43:42 -0000 Hi, Mark, Thanks so much for your feedback! -- Please find my comments in-line.... On 04/25/2013 06:13 PM, Mark Smith wrote: > > I think listing those desired properties would be useful, and then > describing examples of actual interface identifiers that would > qualify if available e.g., persistent ifindex values or persistent > interface names. Will do -- I'm now thinking whether I should add one subsection per argument ("secret key, network_id", etc.), or whether I should list such properties in the hanging-text list, or in the prose below the expression -- thoughts? > One thing that has occurred to me is the interface identifier > stability you're looking for would probably be provided by deriving > the interface ID from the system connector that is used to attach the > network interface to the system e.g. the PCI slot information. A swap > of a failed interface, despite changing the MAC address, will retain > the same interface ID. My undestanding was tht that was how interface indexes were generated -- but, aparently, they aren't. > This gets a bit interesting when thinking about the USB NIC > situation. Plugging the USB NIC into different USB slots would change > the interface ID if the slot is used to assign it a persistent > interface ID. I'd argue that this would be a desirable property. My view is that from a logical point of view, a NIC attached to a different port is a different interface, and hence it should get a different IPv6 address. (after all, if swapping a NIC should not result in a different IPv6 addresses, then this method should not try to generate the same IPv6 address when the same NIC is "detected"). > OTOH, the MAC address and other properties of the USB > NIC (such as USB serial number if it has one) would be constant, so > they could be used to create a persistent interface ID for your > purposes, despite the different USB slot used to attach it to the > system. Perhaps that means different buses and/or connectors would > need different policies on interface ID assignment, and that could be > mentioned in your Draft. I'd prefer that the IPv6 address is not bound to any serial number of MAC address. That of having the resulting IPv6 addresses being independent of the underlying media is an interesting property. > As another example of a convention, it seems that Fedora has adopted > a convention of naming wired ethernet interfaces based on whether > they're attached to the motherboard (e.g, em0) or a PCI slot / port > and then virtual function if it has one (e.g. p4p1), so they're > persistent across boots or replacement. Yet they don't apply that to > PCI attached wifi interfaces, which are still called wlanX. Yep, that's why using the interface name, *for these systems* might be more appropriate. However, the interface names on *BSD seem to depend on the vendor name... and hence would vary if a NIC is replaced with another NIC from a different vendor. > You might also want to briefly cover persistent interface IDs for > virtual interfaces e.g, bridge virtual interfaces. Their only > constant identifier may be their name - under Linux for example, they > seem to use the lowest numeric MAC address of the member interfaces, > which can change if a new interface is added or the lowest MAC > address interface is removed. mmm... not sure what you mean. -- Could you please elaborate? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Thu Apr 25 23:32:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70EE21F97E0 for ; Thu, 25 Apr 2013 23:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRucEyDF5FmV for ; Thu, 25 Apr 2013 23:32:45 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50821F97D2 for <6man@ietf.org>; Thu, 25 Apr 2013 23:32:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B5D538700DE; Fri, 26 Apr 2013 08:32:29 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQMhBy1Tz8jR; Fri, 26 Apr 2013 08:32:29 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8578F87006F; Fri, 26 Apr 2013 08:32:29 +0200 (CEST) Message-ID: <517A1F77.7060206@globis.net> Date: Fri, 26 Apr 2013 08:32:23 +0200 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Mark Smith Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Fernando Gont , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 06:32:46 -0000 > Mark Smith > 25 April 2013 23:13 > Hi Fernando, > > > > I think listing those desired properties would be useful, and then > describing examples of actual interface identifiers that would qualify > if available e.g., persistent ifindex values or persistent interface > names. > > One thing that has occurred to me is the interface identifier > stability you're looking for would probably be provided by deriving > the interface ID from the system connector that is used to attach the > network interface to the system e.g. the PCI slot information. A swap > of a failed interface, despite changing the MAC address, will retain > the same interface ID. > This gets a bit interesting when thinking about the USB NIC situation. > Plugging the USB NIC into different USB slots would change the > interface ID if the slot is used to assign it a persistent interface > ID. OTOH, the MAC address and other properties of the USB NIC (such as > USB serial number if it has one) would be constant, so they could be > used to create a persistent interface ID for your purposes, despite > the different USB slot used to attach it to the system. Perhaps that > means different buses and/or connectors would need different policies > on interface ID assignment, and that could be mentioned in your Draft. Slippery slope to a rat hole. Spent 20+ years configuring various networking devices, and had various run ins with SNMP ifName, ifIdent, cbQosObjectsIndex etc. (which are similar concepts). IMHO There isn't a single best model. - People might want to maintain the stable-privacy-address even though the physical slot changes. - An operator might want to move the configuration to another physical or logical interface due to a fault in the original interface but maintain config (in which case ifDescr would be a better source of differentiation). - An operator might want to configure up another interface that mirrors the first for hot standby on hardware failure. - Device may not support the concept of interface_ID. - Interface may not have a MAC address. - May be multiple sub-interfaces configured on one physical interface. - Single interface devices without a removable NIC don't need to incorporate the interface_ID at all: there's no gain (so it is only a "MAY") - Devices without permanent storage may find it impossible to maintain an interface_ID other than the MAC address, yet want a stable-privacy-address. - Devices may have their permanent storage wiped. I still prefer the text I proposed blow (although feel free to improve it) "an Interface_ID is an implementation-dependent identifier associated with a particular interface on the local node, which is generally time invariant over the long-term and over system reboots. The Interface_ID may be used to assist efficient generation of unique stable-privacy-addresses, especially in situations where multiple interfaces on a single node may be configured using the same L3 Prefix. If the Interface_ID does change for whatever reason, this would obviously undermine the time-invariance of the resulting stable-privacy-addresses." > > As another example of a convention, it seems that Fedora has adopted a > convention of naming wired ethernet interfaces based on whether > they're attached to the motherboard (e.g, em0) or a PCI slot / port > and then virtual function if it has one (e.g. p4p1), so they're > persistent across boots or replacement. Yet they don't apply that to > PCI attached wifi interfaces, which are still called wlanX. > > You might also want to briefly cover persistent interface IDs for > virtual interfaces e.g, bridge virtual interfaces. Their only constant > identifier may be their name - under Linux for example, they seem to > use the lowest numeric MAC address of the member interfaces, which can > change if a new interface is added or the lowest MAC address interface > is removed. > > > > Regards, > Mark. > Fernando Gont > 25 April 2013 18:47 > Hi, Ray, > > On 04/25/2013 11:21 AM, Ray Hunter wrote: >> Since both "Interface_Index" and "Interface name" are anyway both >> implementation dependent, why would you need to precisely standardise >> the exact meaning, or the exact source of the information? AFAICS this >> wouldn't significantly affect inter-op, or protocol operation. > > Their implementation (e.g. namespace) are implementation-dependent. > Their properties may not. > > I don't care about the source of information as long as it meets the > goal. Ideally, the I-D: > > * Should be constant across system bootstrap sequences > * Should be different for each network interface > * Should not change when the NIC is replaced > > The first to properties are needed for the "stability" properties of > this scheme. The last one is needed such that the IPv6 address doesn't > change when a NIC is replaced (I hear lots of people do not use SLAAC > because of this). > > > >> I therefore agree with your proposal that the text should define an >> abstract "Interface_ID" and suggest that you define "an Interface_ID is >> an implementation-dependent identifier associated with a particular >> interface on the local node, which is generally invariant over the >> long-term and over system reboots. The Interface_ID may be used to >> assist efficient generation of unique stable-privacy-addresses, >> especially in situations where multiple interfaces on a single node may >> be configured using the same L3 Prefix. If the Interface_ID does change >> for whatever reason, this would obviously undermine the time-invariance >> of the resulting stable-privacy-addresses." >> >> I don't think you need any more guidance than that. > > If you say just that, many will wonder "Ok, so what should I use for the > Interface_ID?". So I'd probably list the three properties I mentioned > above, and (non-normatively) note that the Interface Index or the > Interface name could be used for this purpose... > > Thanks, > Ray Hunter > 25 April 2013 18:21 > Since both "Interface_Index" and "Interface name" are anyway both > implementation dependent, why would you need to precisely standardise > the exact meaning, or the exact source of the information? AFAICS this > wouldn't significantly affect inter-op, or protocol operation. > > I therefore agree with your proposal that the text should define an > abstract "Interface_ID" and suggest that you define "an Interface_ID is > an implementation-dependent identifier associated with a particular > interface on the local node, which is generally invariant over the > long-term and over system reboots. The Interface_ID may be used to > assist efficient generation of unique stable-privacy-addresses, > especially in situations where multiple interfaces on a single node may > be configured using the same L3 Prefix. If the Interface_ID does change > for whatever reason, this would obviously undermine the time-invariance > of the resulting stable-privacy-addresses." > > I don't think you need any more guidance than that. > > regards, > RayH > ------------------------------------------------------------------------ From ietfc@btconnect.com Fri Apr 26 01:22:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E63421F97DA for ; Fri, 26 Apr 2013 01:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgUspUsk-jKP for ; Fri, 26 Apr 2013 01:21:52 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id BE75921F97F9 for <6man@ietf.org>; Fri, 26 Apr 2013 01:21:44 -0700 (PDT) Received: from mail52-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE020.bigfish.com (10.243.66.83) with Microsoft SMTP Server id 14.1.225.23; Fri, 26 Apr 2013 08:21:40 +0000 Received: from mail52-co1 (localhost [127.0.0.1]) by mail52-co1-R.bigfish.com (Postfix) with ESMTP id 4F8036003B5; Fri, 26 Apr 2013 08:21:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz9371I103dK542I1432I1418I62a3Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275bh8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch304l1d11m1155h) Received: from mail52-co1 (localhost.localdomain [127.0.0.1]) by mail52-co1 (MessageSwitch) id 1366964498739878_16028; Fri, 26 Apr 2013 08:21:38 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.253]) by mail52-co1.bigfish.com (Postfix) with ESMTP id B1B14A4005A; Fri, 26 Apr 2013 08:21:38 +0000 (UTC) Received: from AMSPRD0711HT003.eurprd07.prod.outlook.com (157.56.250.181) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 26 Apr 2013 08:21:38 +0000 Received: from DB3PRD0210HT002.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.242.14.164) with Microsoft SMTP Server (TLS) id 14.16.293.5; Fri, 26 Apr 2013 08:21:38 +0000 Message-ID: <008401ce4256$6205efe0$4001a8c0@gateway.2wire.net> From: t.petch To: Fernando Gont , <6man@ietf.org> References: <5179372C.7000808@si6networks.com> Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name Date: Fri, 26 Apr 2013 09:16:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-FOPE-CRA-SourceIpAddress: 157.56.250.181 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: rja.lists@gmail.com X-FOPE-BFA-RECEIVER: brian@innovationslab.net X-FOPE-BFA-RECEIVER: 6man-chairs@tools.ietf.org X-FOPE-BFA-RECEIVER: fgont@si6networks.com X-FOPE-BFA-RECEIVER: 6man@ietf.org X-OriginatorOrg: btconnect.com Cc: 6man-chairs@tools.ietf.org, Brian Haberman , RJ Atkinson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 08:22:04 -0000 ---- Original Message ----- From: "Fernando Gont" To: <6man@ietf.org> Cc: <6man-chairs@tools.ietf.org>; "RJ Atkinson" ; "Brian Haberman" ; "t.petch" Sent: Thursday, April 25, 2013 3:01 PM > Folks, > > During IETF LC, a couple of folks noted that Interface Indexes might not > be stable. > > I added some text on the subject to my working copy (mostly based on the > discussion with Brian Haberman and Mark Smith), but the issue came up > again (Tom Petch commented on the subject). > > Since the raison d'etre for including the Interface Index in F() is to > differentiate between multiple interfaces connecting to the same > network, either the Interface Index or the Interface Name could be used. > So far, these are the pros/cons of each: > > * Interface Index: Including this one would be ideal, since it's simply > a small number that identifies the interface, and does not really depend > on the NIC vendor, etc. However, as noted above, in some implementations > it might be unstable (i.e., vary when the system is bootstrapped). > > * Interface name: This one has the pro that is stable, even on systems > in which the Interface Index is not. However, on some systems (e.g. > BSDs) the Interface name depends on the NIC vendor, which means that if > a NIC is replaced with another from a different vendor, the Interface > name is likely to change, and therefore the resulting address will change. > > My take would be to replace "Interface Index" in the expression with an > abstract "Interface_ID", and then explain that "Interfae_ID" can be > either the Interface Index or the Interface name, and include some of > the text above (explaining why an implementation might want to include > one or the other -- i.e., if your Interface Indexes are stable, use > them. Else use the Interface name). > > Thoughts? Mmm I think that there is a tension in I-Ds such as this between the purist IETF approach - if it does not impact interoperability, then it has no place in an IETF RFC - and the pragmatic - end users want a simple set of rules to follow that just work without having to understand the ins and outs of standard making (I have met a lot of the latter outside the IETF). One compromise is to put the pragmatic in a non-Normative Appendix. 'if your Interface Indexes are stable'? I imagine most people assume that they are (even if the choice of values made by a manufacturer seems bizarre). I have encountered this several times but even so, might have forgotten if it had not surfaced on netmod last month. So do we then explain which systems may have unstable addresses? So yes, I like an abstract Interface_ID but it needs some explanation, best in an Appendix, but how far we go into unstable indices, I am unsure. (I am also unsure how the index value which appears in the API, as referenced in the I-D, relates to the ifIndex value in a MIB - I am familiar with the latter, but do not know enough of IPv6 to know its relationship to the former). Tom Petch > > Thanks! > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian@innovationslab.net Fri Apr 26 08:34:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B910A21F9924 for ; Fri, 26 Apr 2013 08:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XQx33fFzO-p for ; Fri, 26 Apr 2013 08:34:44 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5515621F98F5 for ; Fri, 26 Apr 2013 08:34:44 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 43890880A9; Fri, 26 Apr 2013 08:34:44 -0700 (PDT) Received: from 102521176.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C943F13000C; Fri, 26 Apr 2013 08:34:43 -0700 (PDT) Message-ID: <517A9E97.8030904@innovationslab.net> Date: Fri, 26 Apr 2013 11:34:47 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-6man-addr-select-opt@tools.ietf.org, 6man WG , 6man Chairs <6man-chairs@tools.ietf.org> Subject: AD Evaluation: draft-ietf-6man-addr-select-opt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 15:34:44 -0000 Hi all, I have performed my usual AD review of draft-ietf-6man-addr-select-opt prior to it moving towards IETF Last Call. The document is well-written and I only have a few comments. Once we have resolved these, we can move the document along in the publication process... 1. Section 2 * The beginning of this section indicates that the Address Selection option contains zero or more policy table options. It would be good to clarify that sending an Address Selection option with zero policy table options allows the operator to convey the values of the A & P flags. * The descriptions of "precedence" and "label" should probably indicate their direct relationship to the policy table structure in RFC 6724. 2. In section 3, I was expecting better detail in *how* the information in the DHCP options is handled. I am not aware of any other DHCP-provided information that is conditional based on the user's whim. This seems like it could lead to hard to diagnose brokenness. 3. In section 6, I think it is better to point to the actual IANA registry where the options will be documented, rather than the RFC that created the registry. Regards, Brian From sm@resistor.net Sat Apr 27 09:27:58 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECEE21F9708 for ; Sat, 27 Apr 2013 09:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2NuTDwy9boY for ; Sat, 27 Apr 2013 09:27:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C513B21F9706 for ; Sat, 27 Apr 2013 09:27:57 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3RGRVpn024123; Sat, 27 Apr 2013 09:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367080055; bh=kf1ZTZNlbPoU5w4D2bH7dxHbyOx/cr0Yt17147onrvE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DXWaoYd6jz8iP5XGlWrRvwkRz8Zk+37quPQcRHEpMjGZfgr9dBIJuWagMbfSaWZiV nvrTISEGcaL7TD4pZ4WyB+zShMOd2K4ui5vtibhG6+UfLASWlggcUv8hHC3G75cGV6 PXvest8A/K56BN4DVuJQ0gja3kV6kFYsihpGUJu0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1367080055; i=@resistor.net; bh=kf1ZTZNlbPoU5w4D2bH7dxHbyOx/cr0Yt17147onrvE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ey39tL782rAsUfkXvMcN54wFdsLBxGTekjN7MHOa3J/ptpddjkKN4U9VCI9hkmN5T iG5+Gz5sb0ICGr/FX8N0bHmpfF6/n0n1Gd2Ob3wZDeHOPwaSDRR71GUTv22Bkjr0w2 RjM1HGgojr6kLxYKnzJuqJjZXmId3xrJMNKxJ6Fg= Message-Id: <6.2.5.6.2.20130427082657.0b4bbbb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 08:35:34 -0700 To: ipv6@ietf.org From: SM Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard In-Reply-To: <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alissa Cooper X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 16:27:58 -0000 At 14:32 25-04-2013, Alissa Cooper wrote: >One comment and one nit below. [snip] >This implication seems misguided. Providing the ability to track and >correlate the communications of a device that never leaves a single >network is a significant concern. It is one concern among several >that the IEEE-identifier-based mechanism raises, but it is a big one >IMO. This algorithm does not appear to mitigate that concern, so any >implication that it does should be avoided. I would suggest using >"some of the privacy concerns" in place of "most of the privacy >concerns" in the two sections above. Agreed. Regards, -sm P.S. I hope that the 6MAN WG does not ignore Alissa's comment. From sm@resistor.net Sat Apr 27 09:51:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC1321F9832 for ; Sat, 27 Apr 2013 09:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUn6yA1tFXXG for ; Sat, 27 Apr 2013 09:51:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8520221F982D for ; Sat, 27 Apr 2013 09:51:39 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3RGpD35008949; Sat, 27 Apr 2013 09:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367081478; bh=1tAainKF2aO9jfRoPMrAagqj+y0xIvmK3T+I5nvVEuI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xhHoB15uQGWo0I4W1PpRTSMoWYxgRANPYqrUAHPJFGzIke5AtM/AEmvNIfX2s3vl/ F53/RzQKlOvOWaWsIJi0aQnft+P/CfYZlUEHnwnNnxQoGAaweQO9Lvnnwboeqktc9x dTcAxQ1ZHC1h748xz5HDjqJkpUNcGSimbiAYhGFg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1367081478; i=@resistor.net; bh=1tAainKF2aO9jfRoPMrAagqj+y0xIvmK3T+I5nvVEuI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2+EkpYfeqtxppkYByZvf6g/clvfd4JsnAj5D4lEcy7fRT+Kn85om9QKrDf6aAF2HJ aH9pc6t1n6OM31BtfGHj/F6ABLNUjhOp6gyfyRoS393xfEqhrp7eH3fAtYUTSUcnsL vs15sRU1pwhmeG7ABElPDYTwmDEEjz3tON6aWmGg= Message-Id: <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 09:51:05 -0700 To: Fernando Gont From: SM Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard In-Reply-To: <517AD1F1.4090602@si6networks.com> References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alissa Cooper , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 16:51:44 -0000 Hi Fernando, At 12:13 26-04-2013, Fernando Gont wrote: >In some scenarios, that's impossible. Trivial example: If you have a >network with a single host attached to it, no matter whether you change >your address periodically (*), it will be possible to correlate the >hosts' activities. > >(*) That of changing your addresses *periodically* actually helps >correlation. What Alissa suggested is using "some" instead of "most". It's a very small change to the draft. The advantage of doing it is that you can tell a reader that the draft says "some" instead of "most" if there are ever any privacy issues. Regards, -sm From ietf@rozanak.com Sat Apr 27 09:52:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F5A21F9835 for ; Sat, 27 Apr 2013 09:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIzkf-lT67wx for ; Sat, 27 Apr 2013 09:52:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3F91A21F982D for ; Sat, 27 Apr 2013 09:52:19 -0700 (PDT) Received: from kopoli (g225189153.adsl.alicedsl.de [92.225.189.153]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LnPaY-1UyLdH1xqY-00h0yj; Sat, 27 Apr 2013 12:51:59 -0400 From: "Hosnieh Rafiee" To: "'SM'" , References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <6.2.5.6.2.20130427082657.0b4bbbb0@resistor.net> In-Reply-To: <6.2.5.6.2.20130427082657.0b4bbbb0@resistor.net> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Sat, 27 Apr 2013 18:51:46 +0200 Message-ID: <000001ce4367$8720f6a0$9562e3e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxs1Oh6is4EjNGp9KqBUCEn+J12wJTD6xVAwd/AeKWeJMfYA== Content-Language: en-us X-Provags-ID: V02:K0:n0LAivmVNg7WoZzLS2o7/b17bScSH87Jor3qs97OO5c Jr2kduFwGN9i07CpXJtz8B52Njh+fySVNNLRISnKRhaRCJwz29 HdL7keU8rh/2U/F2n5SCLhJgEX5tdU9klvaEUUXLnC1aRgSzaB bJKgyVmmuoBqagOQ4hJsAVSVq139EXlnpT1g80n0vqA3rJpctF GhgjPJocuwypadQUJf6YXMhzDOfcg0pbTKHfkRmCBZGWyJQnUX ouok+3vLqxziF5IvGPZoj5D/cyitfSd4cX4oJitz5yIwBe/Ynh 5Pd3RdoNHdJVpbO5zklVSnzcSA5Bb47R4cyoYMNtsgoc/kD/bo HaMGYVV4kwt9ZrFf66k8= Cc: 'Alissa Cooper' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 16:52:19 -0000 At 14:32 25-04-2013, Alissa Cooper wrote: >One comment and one nit below. [snip] >This implication seems misguided. Providing the ability to track and >correlate the communications of a device that never leaves a single >network is a significant concern. It is one concern among several that >the IEEE-identifier-based mechanism raises, but it is a big one IMO. >This algorithm does not appear to mitigate that concern, so any >implication that it does should be avoided. I would suggest using "some >of the privacy concerns" in place of "most of the privacy concerns" in >the two sections above. >Agreed. I mentioned this comment in the first versions of this draft, but nobody seemed to agree with me at that time so I stopped with the dialogue. Hosnieh From johnsonhammond2@hushmail.com Sat Apr 27 09:48:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F60121F982B for ; Sat, 27 Apr 2013 09:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z-uOjjOYABL for ; Sat, 27 Apr 2013 09:48:14 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 7898021F9825 for ; Sat, 27 Apr 2013 09:48:06 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 032FE580A5 for ; Sat, 27 Apr 2013 16:48:06 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 16:48:05 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id AEAF814DBDE; Sat, 27 Apr 2013 16:48:05 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 12:48:05 -0400 To: ipv6@ietf.org Subject: Biggest Fake Conference in Computer Science From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427164805.AEAF814DBDE@smtp.hushmail.com> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:26:39 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From sm@resistor.net Sat Apr 27 11:38:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03D721F98F1 for ; Sat, 27 Apr 2013 11:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59RAfmNasM6O for ; Sat, 27 Apr 2013 11:38:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE72521F98EE for ; Sat, 27 Apr 2013 11:38:05 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3RIbeVl025304; Sat, 27 Apr 2013 11:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367087865; bh=gN8sqdGgAkJWQupYMannKWSWmuBILtdV4cL/eUjD7E8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yh3bhxM0xGyVySKIOSrBhoupMbtKYFSmIqooszap+DbxSIvKB8WjizILJdh4+ULtt 91KcEHKwCNv0cMLanvAEADFEUDank94jFmRTGjTPRDUC528BxDGf2mAj6mCzojKQXG WnuY1NuS4w9Vm7n0xyivNEX3dVnU1p8pOtrzoX/c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1367087865; i=@resistor.net; bh=gN8sqdGgAkJWQupYMannKWSWmuBILtdV4cL/eUjD7E8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ASZiCpSPPLCHAw8bZH8+4gKwEkngv6sEjU6OwaZ6InR0jMEh62UCJnQKK7vHNhFHg w3ryr8uydIudV8y4iU4wTUNA/D8FC+5tU7AMNu7xLIvC/IiRzxWFIBM/ajD+VPp26o fk6tjcwjkDYx3rTfiYwNNW4z3qdsm4Ny3EaxYB4c= Message-Id: <6.2.5.6.2.20130427112650.0ccb2e60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 11:36:30 -0700 To: Hosnieh Rafiee From: SM Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard In-Reply-To: <000001ce4367$8720f6a0$9562e3e0$@rozanak.com> References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <6.2.5.6.2.20130427082657.0b4bbbb0@resistor.net> <000001ce4367$8720f6a0$9562e3e0$@rozanak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alissa Cooper , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:38:06 -0000 Hi Hosnieh, At 09:51 27-04-2013, Hosnieh Rafiee wrote: >I mentioned this comment in the first versions of this draft, but nobody >seemed to agree with me at that time so I stopped with the dialogue. I gather that would be in the message at http://www.ietf.org/mail-archive/web/ipv6/current/msg16859.html If there are any issues about privacy you could raise them on the ietf-privacy@ietf.org mailing list. Regards, -sm From ietf@rozanak.com Sat Apr 27 12:21:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AD421F98BC for ; Sat, 27 Apr 2013 12:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E28sqQLl1+W for ; Sat, 27 Apr 2013 12:21:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 95F0821F9851 for ; Sat, 27 Apr 2013 12:21:25 -0700 (PDT) Received: from kopoli (g225189153.adsl.alicedsl.de [92.225.189.153]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M0yOt-1UlVX70gk3-00v5VY; Sat, 27 Apr 2013 15:20:42 -0400 From: "Hosnieh Rafiee" To: "'SM'" References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <6.2.5.6.2.20130427082657.0b4bbbb0@resistor.net> <000001ce4367$8720f6a0$9562e3e0$@rozanak.com> <6.2.5.6.2.20130427112650.0ccb2e60@resistor.net> In-Reply-To: <6.2.5.6.2.20130427112650.0ccb2e60@resistor.net> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Sat, 27 Apr 2013 21:20:32 +0200 Message-ID: <000601ce437c$4e5322c0$eaf96840$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxs1Oh6is4EjNGp9KqBUCEn+J12wJTD6xVAwd/AeIB40moIwGHTeWKll1gh+A= Content-Language: en-us X-Provags-ID: V02:K0:SAwIlaCtRZ7zUz10aEmssqN/84sSKQyCn8CRUvhaA5v dZeeP6UHWkMwmvVYe3OOIHKumlowfsKDdhKo/MD5P3gmPV9Xbj aAQ8QR6ycE1U9Jyf37dCpsqUl85opyAg0LlC183utzrXK7Jpv0 xscAxaT3QiC5qM25csLH9NEU2TQCbj4O2Dn1biFdC5weixOU48 kLnjCSgh3B2k5sIiPGsPEA7PdkZszR0QqDufgEqegldlLCKdVp W9u8lqSbd3nHrYWpkZcPFRmAJmlnTj5CsO/6FFqMNHOAKZ66d1 ILIrd074HjrQiWMjytnVb5azlhpn5EcDvdd7hVfVdrcd9f14X7 ngX+PVFihJLGWCYxXWQA= Cc: 'Alissa Cooper' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 19:21:26 -0000 I do not think repeating what I explained before will be of much help. I never received any responses from my last discussions with Fernando so I am not going to continue that discourse. But here is a brief summary of I tried to explain. I agree with the part where he focuses on an algorithm for IID generation, but this will have no effect on privacy so claiming to solve the privacy problem by keeping the same IID for a node in a same network is not true. This means that if I do not use a mobile node, I will generate the same IP address until I receive another prefix from the router. He claims this is good for printers or nodes that need a fixed IP address. He believes that having a different IID from the same router prefix does not help with the privacy. But I strongly disagree with this. During the time that the node has the same IID, I as an attacker can easily track this node and, gain enough information about this node, for later when the node comes with a different router prefix, I have more chance to correlate this node with the previous data I obtained from it while it had the IID with previous router prefix. About having the same IID for some nodes, I think that this is really related to the network policy and has nothing to do to with standards but Is more a deployment issue. Currently some network administrators themselves consider this issue so there is no need to tell them how to do this. Best, Hosnieh -----Original Message----- From: SM [mailto:sm@resistor.net] Sent: Saturday, April 27, 2013 8:37 PM To: Hosnieh Rafiee Cc: Alissa Cooper; ipv6@ietf.org Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Hi Hosnieh, At 09:51 27-04-2013, Hosnieh Rafiee wrote: >I mentioned this comment in the first versions of this draft, but >nobody seemed to agree with me at that time so I stopped with the dialogue. I gather that would be in the message at http://www.ietf.org/mail-archive/web/ipv6/current/msg16859.html If there are any issues about privacy you could raise them on the ietf-privacy@ietf.org mailing list. Regards, -sm From fgont@si6networks.com Sat Apr 27 16:34:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D278521F9921 for ; Sat, 27 Apr 2013 16:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaDlDsTtzMto for ; Sat, 27 Apr 2013 16:34:38 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F921F98DA for ; Sat, 27 Apr 2013 16:34:38 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWEd7-0001Hr-Fe; Sun, 28 Apr 2013 01:34:09 +0200 Message-ID: <517C606A.1070204@si6networks.com> Date: Sat, 27 Apr 2013 20:34:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <6.2.5.6.2.20130427082657.0b4bbbb0@resistor.net> <000001ce4367$8720f6a0$9562e3e0$@rozanak.com> <6.2.5.6.2.20130427112650.0ccb2e60@resistor.net> <000601ce437c$4e5322c0$eaf96840$@rozanak.com> In-Reply-To: <000601ce437c$4e5322c0$eaf96840$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: 'Alissa Cooper' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 23:34:44 -0000 Hosnieh, On 04/27/2013 04:20 PM, Hosnieh Rafiee wrote: > I do not think repeating what I explained before will be of much help. I > never received any responses from my last discussions with Fernando so I am > not going to continue that discourse. FWIW, I responded to your messages. However, most of them did not really have to do with this document. > I agree with the part where he focuses on an algorithm for IID generation, > but this will have no effect on privacy so claiming to solve the privacy > problem by keeping the same IID for a node in a same network is not true. Please read: Dupont, F., Savola, P. 2004. RFC 3041 Considered Harmful. IETF Internet-Draft (draft-dupont-ipv6-rfc3041harmful-05.txt), work in progress. Escudero, A. 2002. PRIVACY EXTENSIONS FOR STATELESS ADDRESS AUTOCONFIGURATION IN IPV6 - ‘REQUIREMENTS FOR UNOBSERVABILITY. RVK02, Stockholm. Available at: http://web.it.kth.se/~aep/PhD/docs/paper3-rvk2002.pdf > This means that if I do not use a mobile node, I will generate the same IP > address until I receive another prefix from the router. If you are a single node on a givn network, changing your address doesn't help much. > He claims this is > good for printers or nodes that need a fixed IP address. I never claimed this. And discussion gets a little bit weird when you argue that people claimed things they didn't. > He believes that > having a different IID from the same router prefix does not help with the > privacy. If you read draft-ietf-6man-stable-privacy-addresses, you'll realize that this method is not meant to be a substitution of RFC4941. We just note that, in some scenarios, it might be good enough. > But I strongly disagree with this. During the time that the node > has the same IID, I as an attacker can easily track this node and, gain > enough information about this node, for later when the node comes with a > different router prefix, I have more chance to correlate this node with the > previous data I obtained from it while it had the IID with previous router > prefix. Not sure what you mean. Please elaborate. > About having the same IID for some nodes, I think that this is really > related to the network policy and has nothing to do to with standards but Is > more a deployment issue. We do care about deployment, don't we? > Currently some network administrators themselves > consider this issue so there is no need to tell them how to do this. huh? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sat Apr 27 16:40:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D4E21F99F2 for ; Sat, 27 Apr 2013 16:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfmDQrUuMQgT for ; Sat, 27 Apr 2013 16:40:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1B73321F99F9 for ; Sat, 27 Apr 2013 16:40:14 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWEif-0001QE-1P; Sun, 28 Apr 2013 01:39:53 +0200 Message-ID: <517C61C3.7060703@si6networks.com> Date: Sat, 27 Apr 2013 20:39:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: SM Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> In-Reply-To: <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alissa Cooper , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 23:40:15 -0000 On 04/27/2013 01:51 PM, SM wrote: > Hi Fernando, > At 12:13 26-04-2013, Fernando Gont wrote: >> In some scenarios, that's impossible. Trivial example: If you have a >> network with a single host attached to it, no matter whether you change >> your address periodically (*), it will be possible to correlate the >> hosts' activities. >> >> (*) That of changing your addresses *periodically* actually helps >> correlation. > > What Alissa suggested is using "some" instead of "most". It's a very > small change to the draft. The advantage of doing it is that you can > tell a reader that the draft says "some" instead of "most" if there are > ever any privacy issues. There are essentially three privacy issues: * main one: IIDs that are constant across networks (this is the one that is very harmful) * second one: correlation of node activities within the same network. In many cases, no matter whether you change your addresses, it won't be solved. * third one: leaking information about the IID, which could allow attackers to guess the addresses of other alive nodes. This document fixes #1 and #3. Regarding #2, it may or may not be "addressed" with RFC 4941. That's why this document says "addresses most privacy issues...". That said, I don't care s/most/some/ -- consider that change done, for instance. -- the meat of the document is elsewhere, and not in that sentence. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From sm@resistor.net Sat Apr 27 17:14:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AE521F98D1 for ; Sat, 27 Apr 2013 17:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcnHfaMO7dZb for ; Sat, 27 Apr 2013 17:14:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968621F9933 for ; Sat, 27 Apr 2013 17:14:43 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3S0EDlP011232; Sat, 27 Apr 2013 17:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367108059; bh=yHX1NY2YyFi6RS1ZGljPUfkALIrze2BgfY1VzlFTiDQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=U2hZt7JTmvJyzIH0Z5jzU5bMn+Ed5ttFkmpwn5lj1bwC3btZmq+HSthAWmWIi1/Mw tKMG4FsIo62uPznoqyRWdjAD2ll+76Bb61SNI4RYeheJi3rGUvZRrEPV0xKYRzHF/g iYzuwJnM+0dFAx93pXE3Gd/gnDw6KKkxBHQNzsUw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1367108059; i=@resistor.net; bh=yHX1NY2YyFi6RS1ZGljPUfkALIrze2BgfY1VzlFTiDQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s0nwR/zwvb/0ZrnwneSc7gvkltRIBTHR4D1qOfGOZtfeSkzl13tG8nYgn0By3ngTc 5r38nyR4FeRylDZnHyrQRyurF+3Z6O7MXb5B69N22CFwsEdF4peWElaVtmAc9PnThe E830hK9VfRVT1rluLcIWGgq2I6+ocgObqtOZFs4k= Message-Id: <6.2.5.6.2.20130427170807.0bfbbec0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 17:13:37 -0700 To: Fernando Gont From: SM Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard In-Reply-To: <517C606A.1070204@si6networks.com> References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <6.2.5.6.2.20130427082657.0b4bbbb0@resistor.net> <000001ce4367$8720f6a0$9562e3e0$@rozanak.com> <6.2.5.6.2.20130427112650.0ccb2e60@resistor.net> <000601ce437c$4e5322c0$eaf96840$@rozanak.com> <517C606A.1070204@si6networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alissa Cooper , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 00:14:44 -0000 Hi Fernando, I owe you an apology as one of the comments I made on this thread may be misinterpreted. You responded to all the comments I read. Regards, -sm From huitema@microsoft.com Sat Apr 27 17:47:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC50121F9905 for ; Sat, 27 Apr 2013 17:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kgxuXIgrMaI for ; Sat, 27 Apr 2013 17:47:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0921F955A for ; Sat, 27 Apr 2013 17:47:12 -0700 (PDT) Received: from BN1AFFO11FD015.protection.gbl (10.58.52.203) by BN1AFFO11HUB028.protection.gbl (10.58.52.138) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sun, 28 Apr 2013 00:47:11 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD015.mail.protection.outlook.com (10.58.52.75) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sun, 28 Apr 2013 00:47:11 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.184]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sun, 28 Apr 2013 00:47:10 +0000 From: Christian Huitema To: Fernando Gont , SM Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Thread-Topic: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Thread-Index: AQHOQ6Cc7Ls6e3k460uwJIOTlLRRMJjqyBKg Date: Sun, 28 Apr 2013 00:47:09 +0000 Message-ID: References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> In-Reply-To: <517C61C3.7060703@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704004)(199002)(189002)(47776003)(63696002)(23726002)(20776003)(74366001)(33656001)(69226001)(81342001)(81542001)(50466002)(16406001)(6806003)(49866001)(47736001)(47976001)(50986001)(56816002)(56776001)(54316002)(77982001)(59766001)(46102001)(46406003)(51856001)(54356001)(53806001)(55846006)(31966008)(4396001)(79102001)(80022001)(65816001)(47446002)(76482001)(74662001)(74502001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB028; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0830866D19 Cc: Alissa Cooper , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 00:47:14 -0000 > There are essentially three privacy issues: > > * main one: IIDs that are constant across networks (this is the one that = is very harmful) I think outlining that issue is perhaps the most important aspect of Fernan= do's draft. The logic of automatic address configuration is that a host get= s an IID, and use the same IID for all network prefixes, or even when roami= ng. That's true if the IID is derived from the MAC address, and also true w= ith RFC 4941. This is indeed a major privacy concern, and solving it is qui= te important. > * second one: correlation of node activities within the same network. In = many cases, no matter whether you change your addresses, it won't be solved= . That's largely true, because hosts leak tons of information on the network = they connect to. The MAC address of course, but also things like host names= in DHCP requests, or even the DNS names queried by the host. Solving that = will require a significant effort. > * third one: leaking information about the IID, which could allow attacke= rs to guess the addresses of other alive nodes. That one is solved by RFC 4941, by this draft, or even by DHCP. I read Fernando's draft as engineering privacy with an exception. The addre= sses are randomized and have many privacy features, but they remain the sam= e in a local context, and are thus very observable in that local context. T= hat's obviously a tradeoff. I see why IT departments would like that featur= e -- but then, they could get the same effect by just deploying a DHCP serv= er. However, in the case of roaming the feature is highly debatable. If a h= ost visits the same network multiple times, should it always reuse the same= ID, or should it get a new identifier each time? It is very easy to argue = that "different each time" has better privacy properties.=20 -- Christian Huitema From fgont@si6networks.com Sat Apr 27 20:44:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8B521F972B for ; Sat, 27 Apr 2013 20:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNOzMDwA8r6T for ; Sat, 27 Apr 2013 20:44:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFF421F9706 for ; Sat, 27 Apr 2013 20:44:51 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWIX9-00083f-HV; Sun, 28 Apr 2013 05:44:17 +0200 Message-ID: <517C9B07.8080807@si6networks.com> Date: Sun, 28 Apr 2013 00:44:07 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Huitema Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alissa Cooper , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 03:44:57 -0000 On 04/27/2013 09:47 PM, Christian Huitema wrote: >> * second one: correlation of node activities within the same >> network. In many cases, no matter whether you change your >> addresses, it won't be solved. > > That's largely true, because hosts leak tons of information on the > network they connect to. The MAC address of course, but also things > like host names in DHCP requests, or even the DNS names queried by > the host. Solving that will require a significant effort. That aside, if there's only one node active in a given network, then changing your address periodically (particularly when you're making that fact known) doesn't help much. >> * third one: leaking information about the IID, which could allow >> attackers to guess the addresses of other alive nodes. > > That one is solved by RFC 4941, by this draft, or even by DHCP. It *is* solved by DHCP, but not by RFC4941: RFC4941 addresses are generated *in addition* to SLAAC addresses. That's why, I'm told, Windows replaces traditional SLAAC addresses with a time-invariant version of RFC4941 - besides *additionally* implementing RFC4941 for temporary addresses. Here we're mitigating address-scanning attacks, while bringing other benefits such as privacy, by removing IIDs that are constant across networks. > I read Fernando's draft as engineering privacy with an exception. The > addresses are randomized and have many privacy features, but they > remain the same in a local context, and are thus very observable in > that local context. That's obviously a tradeoff. I see why IT > departments would like that feature -- but then, they could get the > same effect by just deploying a DHCP server. This document aims to improve the case for SLAAC: There are many scenarios in which SLAAC is desirable, without that meaning that you really want a super cookie in the IPv6 addresses of nodes. Or, put another way, from the pov of the user/host, you don't really want to be trivially traceable even if you connect to a network that uses SLAAC rather than DHCPv6. > However, in the case of > roaming the feature is highly debatable. If a host visits the same > network multiple times, should it always reuse the same ID, or should > it get a new identifier each time? It is very easy to argue that > "different each time" has better privacy properties. Agreed. For instance, draft-ietf-6man-stable-privacy-addresses-06.txt is not a replacement for RFC4941. If you're a roaming node, you probably want RFC4941 enabled (in addition to having draft-ietf-6man-stable-privacy-addresses-06.txt enabled). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Sun Apr 28 02:22:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EAD21F98F7 for ; Sun, 28 Apr 2013 02:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmHE4rL+XJZk for ; Sun, 28 Apr 2013 02:22:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7EB21F98EC for ; Sun, 28 Apr 2013 02:22:24 -0700 (PDT) Received: from kopoli (g231248028.adsl.alicedsl.de [92.231.248.28]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LllMm-1V5RZY0JHM-00ZRJL; Sun, 28 Apr 2013 05:21:58 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> In-Reply-To: <517C9B07.8080807@si6networks.com> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Sun, 28 Apr 2013 11:21:48 +0200 Message-ID: <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxs1Oh6is4EjNGp9KqBUCEn+J12wJTD6xVAsgKG3oBg1eMTwEb04hZApwu0F4BtSxW1ZZECydw Content-Language: en-us X-Provags-ID: V02:K0:zkCtcdCArcH+X1GYaI549b9vLZ8tJZtbWBr/e//KUlU Lozr+VdDsFYAg7bBtmON2x2HSpAhPVehKA8lgovWHN9kCaLxwB yXwCGRk1RtK833qiQVUk7iFDq65W3Xg/6P7fGgAdSb8S9sSMMA pPGEI43VM/Q05HcwdTgDVRVSgLanihLvlrYlf5KA+uU0SFEsz7 uXrrdkjsFBG4GiVdh58VW9vOJtiboOwbaHkxsikuCn/uEMaePc G7+y7oGpjat5nCdjClmcrG5Vxkw1BbpFlo/ZNuq6ahO44RD3NA VY5aS6C+X9yZ/4etTkVz19R7fU4oTbIS93TMXb5YqQ6pgEp2e0 aIEDn065yUgw10nX3uCU= Cc: 'Christian Huitema' , 'Alissa Cooper' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 09:22:25 -0000 On 04/27/2013 04:20 PM, Hosnieh Rafiee wrote: > I do not think repeating what I explained before will be of much help. I > never received any responses from my last discussions with Fernando so I am > not going to continue that discourse. >FWIW, I responded to your messages. However, most of them did not really >have to do with this document. Your answered but your response unfortunately could not address to my concerns. >If you are a single node on a givn network, changing your address >doesn't help much. I think, this is what should be taken into consideration based on the network policy and not something as a "standard" track. Again, I strongly disagree with you. Because you did not solve the privacy within the network and probably not between networks. I had an experiment within the small size network, my attacker node was not within the same network because I did not want to test privacy in layer 2 (MAC address). It was really easier to correlate the data to a node. >I never claimed this. And discussion gets a little bit weird when you >argue that people claimed things they didn't. Your first arguments were about the nodes which want to have a not changeable IP address within the network (during the time they have the same router prefix) and my response to this reason was, this is related to network administrator. If they really want to have a node with a fixed IP address, probably they want it to have a fixed IP address forever and not change after the router prefix changes. They thus set it manually. >If you read draft-ietf-6man-stable-privacy-addresses, you'll realize >that this method is not meant to be a substitution of RFC4941. We just >note that, in some scenarios, it might be good enough. I read both RFCs about IID generation and what I understood is you wanted to have something in between. But in my opinion, your draft does not solve the privacy otherwise we are also talking about a short lifetime for the router prefixes. Because as I explained in my last practical experiment, during the time you have the same IID, I can gather enough information about your node. It has a direct relationship with the lifetime of your IID. But when I could have about 50% information about your node, I have a chance to correlate your later connections with different router prefixes or probably I gathered enough information about the nodes that I am tracking and do not need to track them more after they have different router prefixes. What would be so helpful is you merged both RFCs and replace them instead of having something between that does not really help in privacy. > About having the same IID for some nodes, I think that this is really > related to the network policy and has nothing to do to with standards but Is > more a deployment issue. >We do care about deployment, don't we? What I meant is, standard should address to general issues but in your draft, except the IID generation algorithm, I do not see a general issue. Not having a fixed IID within the network or having it, is a network policy and not a standard document. The privacy is something that some people want to have it and some really do not. A standard document can explain to keep the lifetime of IID for a short period of time but it might not explain that It should be this or that and keep it like this or that. You can recommend them but not focus the whole purpose of your draft on this solution. If a standard document tries to explain everything in more detail then it ties the hands of network administrators. they will thus easily disable this feature in their nodes. There are currently thousands of RFCs that never been implemented or never been used. It is because many of them did not focus on the general solutions. In my opinion it is not a general solution to keep the lifetime of the IID like what you explained in your draft and again I consider it as an issue related to the network policy and not a standard document. So now the question is why we have to go in more detail like this and decide for the administrators about the lifetime of the IID when it is a simple things and related to the network policy? I ask others to judge and discuss about this... I am not going to continue. Hosnieh From ietf@rozanak.com Sun Apr 28 08:30:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F4B21F988A for ; Sun, 28 Apr 2013 08:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsyJnCea5BRg for ; Sun, 28 Apr 2013 08:30:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A945F21F9458 for ; Sun, 28 Apr 2013 08:29:31 -0700 (PDT) Received: from kopoli (g231248028.adsl.alicedsl.de [92.231.248.28]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MPDJY-1US5oB0Jma-004TFO; Sun, 28 Apr 2013 11:28:19 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> In-Reply-To: <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Sun, 28 Apr 2013 17:28:04 +0200 Message-ID: <000001ce4425$02082510$06186f30$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxs1Oh6is4EjNGp9KqBUCEn+J12wJTD6xVAsgKG3oBg1eMTwEb04hZApwu0F4BtSxW1QEwxwsBljr2u3A= Content-Language: en-us X-Provags-ID: V02:K0:LNB3l4SjgY6/X10TubXJJsJTj4KH6TU8PbrlW+NgiEX taCNwuBGuN6U0yOkIk1yGuNKO6/A9K4i66lP5IEnWBeBprfLvf KD9BhGFJjqqPJ2VDnV71jTgvDo4t/CWoLlNXbuziLjhPUj2B2f 15JS5yDwy6k9peKbO2fW9QhDpCQkI2wTHdOTo3h/FhWKMHU/qK Bfags2aG89CIifNiS/JT8Jt9WbLRJCaNc4zkl1c+duxRmRwerz t3gx49Gj0BezERq4jQ7gHb0fTGWfieBHSDms20Z00gpiaZuGZ2 medcPqhtb3lfHXXgzfPQGYnz/kpYybBEhrPbt/VUfvcRz7+ipc 8LQrZ6WJVmiabXy8c8k0= Cc: 'Christian Huitema' , 'Alissa Cooper' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 15:30:32 -0000 >It *is* solved by DHCP, but not by RFC4941: RFC4941 addresses are >generated *in addition* to SLAAC addresses. That's why, I'm told, >Windows replaces traditional SLAAC addresses with a time-invariant >version of RFC4941 - besides *additionally* implementing RFC4941 for >temporary addresses. >Here we're mitigating address-scanning attacks, while bringing other >benefits such as privacy, by removing IIDs that are constant across >networks. The node is still vulnerable to privacy attacks when you have an IID lifetime for the IP address as explained in your draft. Why offer a partial solution to the problem with the implementation of two RFCs?! What needs to be done is write one RFCs to address both issues. This can be done by more generalizing the solution instead of focusing on a small group of people who thinks having the same IID in the same network and changing it just among two networks would solve the privacy problem. It is not really true. As I wrote in the last email, standards documents should pertain to general issues. With respect to your draft, the only general issue that is addressed is that of the IID generation algorithm. Whether or not an IID in a network is fixed or not is a network policy issue and not a standards issue. A standard might suggest that the time frame for the use of an IID should be kept short but nothing more. If more management is needed in the generation of the IID then other approaches can be used other that neighbor discovery. Again, there are thousands of RFCs that have never been implemented or used because they do not focus on general solutions. The lifetime of the IP address should be left to the discretion of the users and not the standard except for explaining the potential dangers inherent in using longer time periods. In the standard, you just need to explain how the implementation should provide a way to use a parameter containing the lifetime. So then the implementation could obtain this value during the installation of this feature. This will generalize the solution and will give a possible way of changing the lifetime based on the network policy so that the whole draft does not focus on something that does not really solve the privacy issue. Hosnieh From brian.e.carpenter@gmail.com Sun Apr 28 13:01:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349621F9858 for ; Sun, 28 Apr 2013 13:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOQdwM5JxSYb for ; Sun, 28 Apr 2013 13:01:13 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id D947221F9855 for ; Sun, 28 Apr 2013 13:01:13 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r10so1017894pdi.21 for ; Sun, 28 Apr 2013 13:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sfcU0BhO2UMwaD5X/h5VVl5gzjQH+MeC5fx56IMxC+Y=; b=WLGDBqV9bBt9CHKDP12bHUBK2wgV4tI2XN2vIOgTbhXVM/QJTmmetYAsKNGBg0l5NX lJOjRJPPfyuVmRC0h6PMB0ri5mgaCZmvDqBvjkd7xORrZBSutsbwPTqKa3t1drGK9qjr CfnMCaqQRrhDVHM1qZyKqh7xdn8eewVG4EaUosdEI30A8iPN3KUjaKy756oielPJ8IK0 b6+wo4wBm1gIVbEsKXDY3nTLIiZYPEoYol4zQjzxdTdA/3fPApiqHCYe6JqeMOciAmj+ hUEviA0p2eBNE8o35nic0XYzim97xbpWnBhYGxwM65iNXvuLZYvah6n1r+8UvDWRWSDc IMLg== X-Received: by 10.68.203.101 with SMTP id kp5mr68953643pbc.16.1367179273557; Sun, 28 Apr 2013 13:01:13 -0700 (PDT) Received: from [192.168.1.64] (122-60-170-151.jetstream.xtra.co.nz. [122.60.170.151]) by mx.google.com with ESMTPSA id t1sm22562192pab.12.2013.04.28.13.01.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 13:01:12 -0700 (PDT) Message-ID: <517D7FFB.9070406@gmail.com> Date: Mon, 29 Apr 2013 08:00:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> In-Reply-To: <000001ce4425$02082510$06186f30$@rozanak.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Fernando Gont' , 'Alissa Cooper' , ipv6@ietf.org, 'Christian Huitema' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 20:01:14 -0000 On 29/04/2013 03:28, Hosnieh Rafiee wrote: > ... Whether or not an IID in a network > is fixed or not is a network policy issue and not a standards issue. You keep saying that, but it's a *host* IID and therefore primarily a host issue. In some cases, hosts are subject to a local policy, but in other cases they are completely autonomous. It's reasonable to have several optional standards for how hosts autonomously create their IID. As has been accepted by Fernando, this draft only solves some aspects of IID-based privacy. So what? That is quite typical of IETF standards. We generally find it more useful to avoid trying to boil the ocean. Brian From ietf@rozanak.com Sun Apr 28 13:14:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955621F9818 for ; Sun, 28 Apr 2013 13:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x3hDxpoUTkl for ; Sun, 28 Apr 2013 13:14:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C9A9D21F97FE for ; Sun, 28 Apr 2013 13:14:24 -0700 (PDT) Received: from kopoli (g231248028.adsl.alicedsl.de [92.231.248.28]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LbdUh-1UuvJn3RUJ-00lI75; Sun, 28 Apr 2013 16:14:04 -0400 From: "Hosnieh Rafiee" To: "'Brian E Carpenter'" References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> In-Reply-To: <517D7FFB.9070406@gmail.com> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Sun, 28 Apr 2013 22:13:52 +0200 Message-ID: <000901ce444c$ed75b2c0$c8611840$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxs1Oh6is4EjNGp9KqBUCEn+J12wJTD6xVAsgKG3oBg1eMTwEb04hZApwu0F4BtSxW1QEwxwsBAp1jerEBbzj+SJYa6P1A Content-Language: en-us X-Provags-ID: V02:K0:HHEb7ftOr2gww+0EeY6iu8Vp1JN68M5IN143h//mwhV bqZXbWOiGJ4AO8R/zcxVdcWObnhSROQeDpwL9IRHCCvhIWWOED ybrWeYYd3TzPjvbE7USOmVGYF3Z8z6WvEIvPNJhr2S860iTIUU GQMzdMsGFPGI0KON/AmaBFCCekXujhXQ8DyHafV1S708RGQc+9 grbMz2U7r+1hHCA5lwQj1eDwwtWs9hlQkRGTITo1+S7tTvBH7M ykVMD+I25yfI9pEFLXqjuhkDd47VaMGSBxEE32CHKMVd1QLM50 v9jNz3jnMyrcDKu5D/VyxIaEN9dYzIWUueFsFOQZkegzB371nZ iElT9DNDjdg4YsJTjftI= Cc: 'Fernando Gont' , 'Alissa Cooper' , ipv6@ietf.org, 'Christian Huitema' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 20:14:25 -0000 Dear Brian, >You keep saying that, but it's a *host* IID and therefore primarily a = host issue. In some cases, hosts are subject to a local policy, but in = other cases they are completely autonomous. It's reasonable to >have = several optional standards for how hosts autonomously create their IID. I agree with what you said that there are several options for = generating IID. I have no problem with that. >As has been accepted by Fernando, this draft only solves some aspects = of IID-based privacy. So what?=20 What I keep saying is this rfc draft does not have any effect on privacy = and everything related to the router prefix.=20 >We generally find it more useful to avoid trying to boil the ocean. We are not boiling the ocean bucket by bucket as you seem to think. What = we are doing is beating a dead horse. Hosnieh From markzzzsmith@yahoo.com.au Sun Apr 28 21:13:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BDD21F99E8 for ; Sun, 28 Apr 2013 21:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgQNf2gVwygR for ; Sun, 28 Apr 2013 21:13:31 -0700 (PDT) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by ietfa.amsl.com (Postfix) with ESMTP id DDC5621F99E5 for <6man@ietf.org>; Sun, 28 Apr 2013 21:13:27 -0700 (PDT) Received: from [98.139.212.149] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2013 04:13:27 -0000 Received: from [98.139.215.254] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2013 04:13:27 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 29 Apr 2013 04:13:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 202125.19872.bm@omp1067.mail.bf1.yahoo.com Received: (qmail 8488 invoked by uid 60001); 29 Apr 2013 04:13:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1367208807; bh=uyrhitKZ4KYKbOCKB/IbtOcqtf3D9KS7Uai3ck6hIvI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i0KHG+LVD9UvNa1DW/Z46cCJzX0vMMXgPlhrtVEO7ESD8AYb/30KnXNHU1r/+fBhu1TEoAVBTn3PIxRFywh55XSyRoIFwnzE/e+IS1WYau0vD1JgXx/LIvW58ntpfp12e84SCXSt8jHL0pV4vgVExOxJ2suXITPE/3aNxhIiT/E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LnuicPHoSKbECt1r0m3wNShhg1Dwww3IWU1VR7etMR5Up8RlTiUADbGBeCLTr0kTrpaoGY1HAuHKdaRqfgJRbaX/jHa1l5EbtGAjLNLJIv9V+NCapdVVjw4S5PDreHTfwMNrxeEsZO8iq3kHXMo44v6MNiSiL6QCgOf/dKkFFfQ=; X-YMail-OSG: sI.iIMUVM1kTUL1co75raP_ldgVwPEWC7QGB4G_iZduHFST vyee6ARTGQKiylZojnbsW32_wFzIbHWYHOBEWTApbYTzkUXlGtwt43MlmSry bSvsPh2rR9JGbW_QpVV8q7xrfWiOUMlyJBsTk_BRYn_IAUI9sJYt5ALcbKj5 r7nUcAHd8Gm7BAmn5kZ3_4up4g8FANpbwjM9dFrsoHt4_kLE4qbr50UqHLqG rSDbTT5ZHeHLl4NLaAzr0xDfZkD4desYLO3Kcb8zY_U6mV8_XAqVeGDN581W 8JLQBuiHOOAr_o30upbJ4vv_.vzacrPmjJmo2sQhzoNOu.PJt0IT0.nrzYl7 tZPswdvKo.psIrvqyZwQiUPjLT1PMYDY2GUiJykUdkHppI5YWMbgSkH08GNL 6zhm4PAPt_60UARySzbcKzUoBx4sxjqcV64D3kKO0QH1jPdCZLnhQD3OYBQG KjTxpt2eeNDpfVC0OCbEb51ZNre1KDBu.hBfoz2q1fHCVPQUEyZlxJX3fcMQ ou1OiNxU- Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Sun, 28 Apr 2013 21:13:26 PDT X-Rocket-MIMEInfo: 002.001, SGkgRmVybmFuZG8sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4KPiBUbzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBDYzogUmF5IEh1bnRlciA8djZvcHNAZ2xvYmlzLm5ldD47ICI2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgPDZtYW4tY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgQnJpYW4gSGFiZXJtYW4gPGJyaWFuQGlubm92YXRpb25zbGFiLm5ldD47ICI2bWFuQGlldGYub3JnIiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> Message-ID: <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Sun, 28 Apr 2013 21:13:26 -0700 (PDT) From: Mark Smith Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name To: Fernando Gont MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Ray Hunter , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 04:13:32 -0000 Hi Fernando,=0A=0A=0A----- Original Message -----=0A> From: Fernando Gont <= fgont@si6networks.com>=0A> To: Mark Smith =0A> C= c: Ray Hunter ; "6man-chairs@tools.ietf.org" <6man-chairs= @tools.ietf.org>; Brian Haberman ; "6man@ietf.org= " <6man@ietf.org>; RJ Atkinson ; t.petch =0A> Sent: Friday, 26 April 2013 9:01 AM=0A> Subject: Re: LC com= ments on stable-privacy-addresses: Interface Index vs.=0Aname=0A> =0A> Hi, = Mark,=0A> =0A> Thanks so much for your feedback! -- Please find my comments= in-line....=0A> =0A> On 04/25/2013 06:13 PM, Mark Smith wrote:=0A>> =0A>>= =A0 I think listing those desired properties would be useful, and then=0A>>= =A0 describing examples of actual interface identifiers that would=0A>>=A0 = qualify if available e.g., persistent ifindex values or persistent=0A>>=A0 = interface names.=0A> =0A> Will do -- I'm now thinking whether I should add = one subsection per=0A> argument ("secret key, network_id", etc.), or whethe= r I should list =0A> such=0A> properties in the hanging-text list, or in th= e prose below the=0A> expression --=A0 thoughts?=0A>=A0=0A=0AI think it mig= ht be influenced by what I've suggested below.=0A=0A> =0A> =0A>>=A0 One thi= ng that has occurred to me is the interface identifier=0A>>=A0 stability yo= u're looking for would probably be provided by deriving=0A>>=A0 the interfa= ce ID from the system connector that is used to attach the=0A>>=A0 network = interface to the system e.g. the PCI slot information. A swap=0A>>=A0 of a = failed interface, despite changing the MAC address, will retain=0A>>=A0 the= same interface ID.=0A> =0A> My undestanding was tht that was how interface= indexes were generated --=0A> but, aparently, they aren't.=0A>=A0=0A=0AI d= on't think it is specifically defined. For example, I understand Linux just= uses an incrementing allocation counter, which is why the order of interfa= ce initialisation or insertion matters. On routers etc., this sort of schem= e also seems to be common, as they also can have a command which enables pe= rsistent indexes, such that they are restored after a reboot, and typically= that defaults to off. I have recently come across a scheme which doesn't s= eem to fit either of these though - the ifindex values are huge numbers, ho= wever they don't seem to be persistent by default, as that has to be enable= d.=0A=0A>=A0=0A=0A> =0A>>=A0 This gets a bit interesting when thinking abou= t the USB NIC=0A>>=A0 situation. Plugging the USB NIC into different USB sl= ots would change=0A>>=A0 the interface ID if the slot is used to assign it = a persistent=0A>>=A0 interface ID.=0A> =0A> I'd argue that this would be a = desirable property. My view is that from=0A> a logical point of view, a NIC= attached to a different port is a=0A> different interface, and hence it sh= ould get a different IPv6 address.=0A> (after all, if swapping a NIC should= not result in a different IPv6=0A> addresses, then this method should not = try to generate the same IPv6=0A> address when the same NIC is "detected").= =0A>=A0=0A=0ASo having thought about it for a few days, I still think it wo= uld be better, by default, to try to provide a stable private address for t= he Interface, regardless of how it is attached to the system.=0A=0AThinking= about a model, I think there are 3 components - the system, the modular ne= twork interface (hot pluggable or not) and the network it is attached to. I= think IPv6 addresses are assigned at the point where the network interface= connects to the network, rather than where the network interface connects = to the system.=0A=0ASo under normal and common circumstances, if the same i= nterface is plugged into the same network, I think it should get the same s= table privacy address, regardless of whether the network interface is plugg= ed into the same or a different system bus connector (e.g, a different USB = port) at the time. I think this would be a bit more consistent with IPv6 ad= dressing model, which says that IPv6 addresses are assigned to interfaces.= =0A=0AI think replacing an interface because it is faulty could be treated = as a special case. Technically the interface is different, and therefore sh= ould get a different stable privacy IPv6 address. However, it is instead in= heriting the stable privacy address of the interface it is replacing. I don= 't think this situation is necessarily indicated just by the new interface = being plugged into the same system bus connector as the old one. It could b= e, however I think that should be enabled by a system switch, similar to ho= w persistent ifindexes are switched on.=0A=0A=0A> =0A> =0A>>=A0 OTOH, the M= AC address and other properties of the USB=0A>>=A0 NIC (such as USB serial = number if it has one) would be constant, so=0A>>=A0 they could be used to c= reate a persistent interface ID for your=0A>>=A0 purposes, despite the diff= erent USB slot used to attach it to the=0A>>=A0 system. Perhaps that means = different buses and/or connectors would=0A>>=A0 need different policies on = interface ID assignment, and that could be=0A>>=A0 mentioned in your Draft.= =0A> =0A> I'd prefer that the IPv6 address is not bound to any serial numbe= r of=0A> MAC address. That of having the resulting IPv6 addresses being=0A>= independent of the underlying media is an interesting property.=0A>=0A=0AW= hat I was thinking here was that these sorts of attributes could be used to= recognise when a new interface or a previously known interface is plugged = into the system. They could be used as inputs (perhaps to a hash) to genera= te a more generic "Link Layer Interface Identifier" value (e.g. a 32 bit on= e) that could then be used as an input into your stable privacy address fun= ction, instead of using the ifindex. These attributes would only include th= ose that are specific to the interface, not ones that are specific to how t= he interface is connected to the system, so that e.g., moving the interface= to a different USB port wouldn't change the stable privacy IPv6 address.= =0A=0AReplacing a faulty interface would mean that the instead of the syste= m using the Link Layer Interface Identifier value that it generates based o= n the new interface's attributes, it instead substitutes the faulty interfa= ce's Link Layer Interface Identifier value into the stable privacy IPv6 add= ress function. It is likely the the system would maintain a database of kno= wn interfaces, and one of the fields would be the substitute Link Layer Int= erface Identifier, used if it has a value. An unknown interface would cause= a new entry to be added to this database.=0A=0AGlobally MAC addresses by t= hemselves theoretically should be the only attribute necessary to generate = a unique Link Layer Interface Identifier, however they're not as unique in = practice. So adding other available network interface similar attributes su= ch as product ID, revision number, date of manufacture, serial number, etc.= , that might also be available would help recognise the same interface.=A0= =0A=A0 =0A> =0A> =0A>>=A0 As another example of a convention, it seems that= Fedora has adopted=0A>>=A0 a convention of naming wired ethernet interface= s based on whether=0A>>=A0 they're attached to the motherboard (e.g, em0) o= r a PCI slot / port=0A>>=A0 and then virtual function if it has one (e.g. p= 4p1), so they're=0A>>=A0 persistent across boots or replacement. Yet they d= on't apply that to=0A>>=A0 PCI attached wifi interfaces, which are still ca= lled wlanX.=0A> =0A> Yep, that's why using the interface name, *for these s= ystems* might be=0A> more appropriate. However, the interface names on *BSD= seem to depend on=0A> the vendor name... and hence would vary if a NIC is = replaced with=0A> another NIC from a different vendor.=0A>=A0=0A=0AAgree. T= his is why I think it would be better to use attributes that are "burnt int= o" the network interface module itself, rather than use attributes that are= either generated by the system (e.g. ifindex, interface name), or properti= es of how the network interface module is attached to the system.=0A=0A> = =0A> =0A>>=A0 You might also want to briefly cover persistent interface IDs= for=0A>>=A0 virtual interfaces e.g, bridge virtual interfaces. Their only= =0A>>=A0 constant identifier may be their name - under Linux for example, t= hey=0A>>=A0 seem to use the lowest numeric MAC address of the member interf= aces,=0A>>=A0 which can change if a new interface is added or the lowest MA= C=0A>>=A0 address interface is removed.=0A> =0A> mmm... not sure what you m= ean. -- Could you please elaborate?=0A>=A0=0A=0ASo these bridge virtual int= erfaces are the interfaces that are where the IPv6 addresses are configured= /assigned, rather than the physical interfaces that are members of the brid= ge. They're dynamic, so they won't necessarily have the same ifindex each t= ime, and their name may be chosen by the system operator at the time the br= idge and the bridge virtual interface is created, and their MAC address can= change dynamically. Is that enough of an explanation?=0A=0ABest regards,= =0AMark. From markzzzsmith@yahoo.com.au Sun Apr 28 21:51:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E764021F9872 for ; Sun, 28 Apr 2013 21:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[AWL=0.300, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vxe-8rAn3qO for ; Sun, 28 Apr 2013 21:51:17 -0700 (PDT) Received: from nm8.bullet.mail.bf1.yahoo.com (nm8.bullet.mail.bf1.yahoo.com [98.139.212.167]) by ietfa.amsl.com (Postfix) with SMTP id 5421F21F98F6 for ; Sun, 28 Apr 2013 21:51:09 -0700 (PDT) Received: from [98.139.212.152] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2013 04:47:26 -0000 Received: from [98.139.212.198] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2013 04:47:26 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 29 Apr 2013 04:47:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 462528.8872.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 75981 invoked by uid 60001); 29 Apr 2013 04:47:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1367210846; bh=Ce68EsmiquXEOITK0ZcvLn7mEmOkXi+GxLqjoD3zpX8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xxwn1CAi8G7TIaOj8uVG3w6uulFfj5y2oZLNy2nPa0H2rMnmCI7JllUTBc8dot31rORJ/L/5I9bx8SVjG+YQio1kjQBpdxIMK+P5TnDFm3nt68AbKOBXARD81gdYyROFwbiYqeS+f1PHdJ/9N3BSJlj98+1+HyMLA78u1nAt+go= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YP2AXYK//bsjZCXNfu7HrhNKj/dQ2Z/NIZ5yNoCb0lNtkoq26PudHOdX59m/GMkf/Q3MQp//oTe75t3kK08oqMo7OKeFG72bPGumn1Cj8RONZJ6Or2GP8xha58CB4ONfsqqHzubx8oi88Sux8e3NlAIs521/ASTh2fomEIgFaTs=; X-YMail-OSG: jC2_zcIVM1lIwZ0.MXOrHVSuGegqPrAvwQ1E1l_mAFtdTH2 B2fKkQGVtEwZDcxS2tlSHLIVLZdYWA37vmVaPAgCzoC3DtithlGhp2_GS3Qu PeW7Sc1qxuV.YJ.ho1pkO92Eq_ZkdS9YmcLqxqjof7a3EK5210AYJvDLlFHW r00RqzyOJgFm6JSXmK4MpqzdD.D18HFxEyNo7yvH0itZfEJn22LkqmFxdWqY 16RbDRrPTWIUD2Bco3YrpPE6a1lyTKQMw2bxtdMeVBMnxh50c105m2FjvAyn 6BYLcQJ4mXQSZnaOIy87Mm3vy358LdH8s5La__ZfH3iC_Pg8uVGkwOZHHyn4 0GdLWRhLv4do8oKMnRyun7RqYH3_574leClmzru_.InPMWm7El0DvyWw7Tvl SxS53X1Gi0DhLVK4bQua1_ymyKhDUJ6B53Dp5G2CW8kdEzogqdooB_wXMxCq GT2rU_N49zfUS6cUL.k0jpt0pdWmYF.r2I6asw.qM.YTP5XUcVAqs8ZnVyCg M68z_mmUm64gksRmxDbBwGWok Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Sun, 28 Apr 2013 21:47:26 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBIb3NuaWVoIFJhZmllZSA8aWV0ZkByb3phbmFrLmNvbT4KPiBUbzogJ0JyaWFuIEUgQ2FycGVudGVyJyA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IENjOiAnRmVybmFuZG8gR29udCcgPGZnb250QHNpNm5ldHdvcmtzLmNvbT47ICdBbGlzc2EgQ29vcGVyJyA8YWNvb3BlckBjZHQub3JnPjsgaXB2NkBpZXRmLm9yZzsgJ0NocmlzdGlhbiBIdWl0ZW1hJyA8aHVpdGVtYUBtaWNyb3NvZnQuY29tPgo.IFNlbnQ6IE1vbmRheSwgMjkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> Message-ID: <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Sun, 28 Apr 2013 21:47:26 -0700 (PDT) From: Mark Smith Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard To: Hosnieh Rafiee , 'Brian E Carpenter' In-Reply-To: <000901ce444c$ed75b2c0$c8611840$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 'Fernando Gont' , 'Alissa Cooper' , "ipv6@ietf.org" , 'Christian Huitema' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 04:51:31 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Hosnieh Rafiee =0A> To: 'Brian E Carpenter' =0A> Cc:= 'Fernando Gont' ; 'Alissa Cooper' = ; ipv6@ietf.org; 'Christian Huitema' =0A> Sent: Mond= ay, 29 April 2013 6:13 AM=0A> Subject: RE: Last Call:=09 (A=0A=09method for Generating Stable Privacy= -Enhanced Addresses with=0A=09IPv6 Stateless Address Autoconfiguration (SLA= AC)) to Proposed Standard=0A> =0A> Dear Brian,=0A> =0A> =0A>> You keep sayi= ng that, but it's a *host* IID and therefore primarily a =0A> host issue. I= n some cases, hosts are subject to a local policy, but in other =0A> cases = they are completely autonomous. It's reasonable to >have several =0A> optio= nal standards for how hosts autonomously create their IID.=0A> =0A> I agree= with what you said=A0 that there are several options for generating IID. I= =0A> have no problem with that.=0A> =0A>> As has been accepted by Fernando= , this draft only solves some aspects of =0A> IID-based privacy. So what? = =0A> =0A> What I keep saying is this rfc draft does not have any effect on = privacy and =0A> everything related to the router prefix. =0A>=A0=0A=0ASo p= rivacy and security are relative, not absolute. I think this provides bette= r privacy compared to the use of MAC addresses for IIDs, but doesn't provid= e as much privacy as RFC4941 addresses. If the level of privacy these stabl= e privacy addresses provides is not adequate, then you don't use them. You = either use RFC4941s, or you choose not to communicate at all.=0A=0ACan you = define the "privacy" you don't think it has any effect on?=A0=0A=0A> =0A>> = We generally find it more useful to avoid trying to boil the ocean.=0A> =0A= > We are not boiling the ocean bucket by bucket as you seem to think. What = we are =0A> doing is beating a dead horse.=0A> =0A> Hosnieh=0A> =0A> ------= --------------------------------------------------------------=0A> IETF IPv= 6 working group mailing list=0A> ipv6@ietf.org=0A> Administrative Requests:= https://www.ietf.org/mailman/listinfo/ipv6=0A> ---------------------------= -----------------------------------------=0A> From brian.e.carpenter@gmail.com Sun Apr 28 22:10:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2C21F9C4A for ; Sun, 28 Apr 2013 22:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we7u708FSIl6 for ; Sun, 28 Apr 2013 22:10:21 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 158CE21F9A92 for <6man@ietf.org>; Sun, 28 Apr 2013 22:10:18 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id 4so3420833pdd.17 for <6man@ietf.org>; Sun, 28 Apr 2013 22:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CdHw/AlmIT8i1a07nQluCXRCaLGjJaUD1tV/OgQmlqY=; b=vaiApZor/5nEAo650QI0WPwM2/1dsrSyMOVVdVFhT0zOv0/gbVcpqEZ0nriyy7KWeL Vh5XL83CU1fc6Oi4s2i0EkiFOETWOdWEUr1aDIDMZ52R4IseWVeDPQflylmezBn04Gex d3DPsS06dHeR1V4cbaryoJuHSC9cXGdqjlwcaITYLAnsCVnYnjnem+VAtExsNA2sYFvn SBJUZNjzvFpzd5EkyGNM+1mfZ54rAc2XQVc+yJFKVy23PfzXJ8qQ4FMnnLrzY+Deg8Rh /7LkXS0QH+7CP0ehFmJhDLqYRk8czKDqSHFtA4CpzZtFJLl4xeqxll70qPsiE8CHhcN0 QDKQ== X-Received: by 10.68.112.196 with SMTP id is4mr70128918pbb.117.1367210417625; Sun, 28 Apr 2013 21:40:17 -0700 (PDT) Received: from [192.168.1.64] (122-60-170-151.jetstream.xtra.co.nz. [122.60.170.151]) by mx.google.com with ESMTPSA id b7sm22322596pba.39.2013.04.28.21.40.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 21:40:16 -0700 (PDT) Message-ID: <517DF9A9.7090008@gmail.com> Date: Mon, 29 Apr 2013 16:40:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Ray Hunter , Fernando Gont , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 05:10:21 -0000 On 29/04/2013 16:13, Mark Smith wrote: ... > I don't think it is specifically defined. For example, I > understand Linux just uses an incrementing allocation > counter, which is why the order of interface initialisation > or insertion matters. On routers etc., this sort of scheme > also seems to be common, as they also can have a command > which enables persistent indexes, such that they are restored > after a reboot, and typically that defaults to off. I have > recently come across a scheme which doesn't seem to fit > either of these though - the ifindex values are huge numbers, As far as anything is defined, they are allowed to be unsigned 32-bit integers (according to [RFC4001] and [RFC3493]). The human-readable Zone Identifier has no length limit afaik. Brian From fgont@si6networks.com Mon Apr 29 03:16:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9E521F99E8 for ; Mon, 29 Apr 2013 03:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALT18ODmHPp4 for ; Mon, 29 Apr 2013 03:16:08 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E8E4D21F99D8 for <6man@ietf.org>; Mon, 29 Apr 2013 03:16:07 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWl6w-0002CX-BY; Mon, 29 Apr 2013 12:15:46 +0200 Message-ID: <517E480C.2040305@si6networks.com> Date: Mon, 29 Apr 2013 07:14:36 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Smith Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Ray Hunter , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 10:16:09 -0000 On 04/29/2013 01:13 AM, Mark Smith wrote: >>> This gets a bit interesting when thinking about the USB NIC >>> situation. Plugging the USB NIC into different USB slots would >>> change the interface ID if the slot is used to assign it a >>> persistent interface ID. >> >> I'd argue that this would be a desirable property. My view is that >> from a logical point of view, a NIC attached to a different port is >> a different interface, and hence it should get a different IPv6 >> address. (after all, if swapping a NIC should not result in a >> different IPv6 addresses, then this method should not try to >> generate the same IPv6 address when the same NIC is "detected"). >> > > So having thought about it for a few days, I still think it would be > better, by default, to try to provide a stable private address for > the Interface, regardless of how it is attached to the system. FWIW, with the path we're following (i.e., we describe desired properties for the IID, but do require any specific source for it). SO if you choose to use the MAC address as the Interface_ID, you'd get what *you* expect. But if I choose to use the interface name as the Interface_ID, I'd get what *I* expect ;-) > Thinking about a model, I think there are 3 components - the system, > the modular network interface (hot pluggable or not) and the network > it is attached to. I think IPv6 addresses are assigned at the point > where the network interface connects to the network, rather than > where the network interface connects to the system. > > So under normal and common circumstances, if the same interface is > plugged into the same network, I think it should get the same stable > privacy address, regardless of whether the network interface is > plugged into the same or a different system bus connector (e.g, a > different USB port) at the time. The "problem" here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this purpose... but the the IPv6 address is tied to the MAC address, and would change upon replacement of the NIC (which is generally undesirable)... > I think this would be a bit more > consistent with IPv6 addressing model, which says that IPv6 addresses > are assigned to interfaces. But from the pov of the IPv6 architecture, "interface" is the attachment point, rather than a specific NIC... > I think replacing an interface because it is faulty could be treated > as a special case. Technically the interface is different, and > therefore should get a different stable privacy IPv6 address. > However, it is instead inheriting the stable privacy address of the > interface it is replacing. I don't think this situation is > necessarily indicated just by the new interface being plugged into > the same system bus connector as the old one. It could be, however I > think that should be enabled by a system switch, similar to how > persistent ifindexes are switched on. If that were the case, you'd be short-circuiting SLAAC altogether... is that what you mean/expect? >>> OTOH, the MAC address and other properties of the USB NIC (such >>> as USB serial number if it has one) would be constant, so they >>> could be used to create a persistent interface ID for your >>> purposes, despite the different USB slot used to attach it to >>> the system. Perhaps that means different buses and/or connectors >>> would need different policies on interface ID assignment, and >>> that could be mentioned in your Draft. >> >> I'd prefer that the IPv6 address is not bound to any serial number >> of MAC address. That of having the resulting IPv6 addresses being >> independent of the underlying media is an interesting property. > > What I was thinking here was that these sorts of attributes could be > used to recognise when a new interface or a previously known > interface is plugged into the system. They could be used as inputs > (perhaps to a hash) to generate a more generic "Link Layer Interface > Identifier" value (e.g. a 32 bit one) that could then be used as an > input into your stable privacy address function, instead of using the > ifindex. The upcoming rev allows for that -- so we'd be fine. FWIW, if you need the same NIC to always get the same address regardless of the system port it is attached to, you should probably use the MAC address as the Interface_ID. OTOH, if you don't want addresses to be tied to any specific NIC, you should something else. > Replacing a faulty interface would mean that the instead of the > system using the Link Layer Interface Identifier value that it > generates based on the new interface's attributes, it instead > substitutes the faulty interface's Link Layer Interface Identifier > value into the stable privacy IPv6 address function. It is likely the > the system would maintain a database of known interfaces, and one of > the fields would be the substitute Link Layer Interface Identifier, > used if it has a value. An unknown interface would cause a new entry > to be added to this database. But.. if that were the goal.. why do you need the database in the first place? You could just have a configuration knob to overwrite the "LL Interface Identifier" with whatever you want (typically th LL address of the NIC you're replacing). However, the whole challenge is having this NIC-independent addresses work automagically. -- Otherwise, you'd just configure the IPv6 address manually, and be done with it. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Apr 29 04:17:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBAA21F9911 for ; Mon, 29 Apr 2013 04:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1-OXXc6aPXl for ; Mon, 29 Apr 2013 04:17:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E114721F98F7 for ; Mon, 29 Apr 2013 04:17:39 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWm5D-0003hr-SB; Mon, 29 Apr 2013 13:17:25 +0200 Message-ID: <517E4916.8090004@si6networks.com> Date: Mon, 29 Apr 2013 07:19:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Smith Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Christian Huitema' , 'Alissa Cooper' , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 11:17:41 -0000 On 04/29/2013 01:47 AM, Mark Smith wrote: >> What I keep saying is this rfc draft does not have any effect on >> privacy and everything related to the router prefix. >> > > So privacy and security are relative, not absolute. I think this > provides better privacy compared to the use of MAC addresses for > IIDs, Exactly. > but doesn't provide as much privacy as RFC4941 addresses. If > the level of privacy these stable privacy addresses provides is not > adequate, then you don't use them. You either use RFC4941s, or you > choose not to communicate at all. Actually, if you use RFC4941, you probably want to use stable privacy addresses to replace the traditional SLAAC addresses (or else you'd be subject of the issues described in the Appendix of draft-ietf-6man-stable-privacy-addresses) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Mon Apr 29 07:23:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5D721F9DC8 for ; Mon, 29 Apr 2013 07:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-GXkaNHQsBJ for ; Mon, 29 Apr 2013 07:23:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0467321F9D92 for ; Mon, 29 Apr 2013 07:23:34 -0700 (PDT) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MU0ZF-1U6nn82gFd-00Qj8R; Mon, 29 Apr 2013 10:23:30 -0400 From: "Hosnieh Rafiee" To: "'Mark Smith'" References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Mon, 29 Apr 2013 16:23:20 +0200 Message-ID: <000301ce44e5$1f4e5570$5deb0050$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxs1Oh6is4EjNGp9KqBUCEn+J12wJTD6xVAsgKG3oBg1eMTwEb04hZApwu0F4BtSxW1QEwxwsBAp1jerEBbzj+SAFjLGhuAdg4OQ6WAcvBEA== Content-Language: en-us X-Provags-ID: V02:K0:+we698VtzliMLj1CfiNpT8AlkAUlySvR3LJrftPzTPL BmH13d7EO5fD7oA/AbYmIRE0zBla3gMXEAa6iQIxodtyRkbXQr QZlBSmhYXSMrGQsVfshKfmUrTIkOFzOBeJzXpL+4ww4fe2Xqjv MjY19nb8BW0FqlkAYkNu8C6j8cubgcZgEfR92t17aq62NsTggZ 8B5tRQHcNWmwWZ0NlQRCQyKekhpb1FijUwCkkzVGByXYmWvDKk swTJJWNsdTiQ3mX6DesMmXhItGfzH6ZGhPZkCsZh5CSLg0phL+ FDV0OI47JZqbQgp5/Zw+rzJ7nFJChYX6csiR8Zy7bxCtaReRoG cUcY9DY9aBQZyg//8bec= Cc: 'Fernando Gont' , 'Alissa Cooper' , ipv6@ietf.org, 'Christian Huitema' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:23:38 -0000 Dear Mark >So privacy and security are relative, not absolute. I think this provides better privacy compared to the use of MAC addresses for IIDs Unfortunately that answer is not exactly true. As I explained in my last messages, it is really related to the lifetime of the router prefix. In reality, if you do not change it within a short period of time, like when a MAC address is used, then an attacker will be able to obtain enough information about this node in order to prepare attacks against during the time they use the same IID. Then later, the attacker will have the opportunity to follow his victim when he goes to a new network using the information he obtained earlier. This means that changing the IP address now will be of no use . This is why I do not see how privacy is enhanced in any way with this way of IID generation and I keep reiterating that what this draft states about also providing privacy is not true. This draft is just about the generation of IID in a manner not based on MAC addresses and offers nothing of value concerning privacy issues. Privacy and security are relative, that is true. But the way he wants to maintain privacy is like someone who hides his head in a hole hoping that nobody will see him. I do not call this privacy. Privacy is relative when you make as much effort as possible to keep the data confidential. If some ingenious attackers can come up with new approaches to find your data, then this is not your fault. I mean by this that if one wants to claim that he has enhanced privacy, then he will have had to do everything possible to prevent the currently known privacy attacks. But if you cannot accomplish that in your solution, then you should not mislead readers by saying that your solution does.. This is because privacy is like a bottle of water, where your information is the water inside this bottle. It makes no difference whether you do not close the tap or just don't close it as tightly as you should (like this draft), The bottle will leak water, and for some attackers even a few drops is all they need to initiate further attacks which can result in much damage to the prey. So, if a draft claim to have privacy, it cannot just say I will consider just this part of privacy not others. This is why I suggested to him to just let the users decide on the lifetime for their IP address when they want to install this feature. In this case, he does not try to do anything about that bottle; the aim of the draft is not about privacy but a randomized IID. That way no one will have any expectations for privacy. So, what I am saying here is that having a big title which alludes to privacy enhancements does not make sense. > Can you define the "privacy" you don't think it has any effect on? I have already answered this by what I said in my prior sentence. Best, Hosnieh From huitema@microsoft.com Mon Apr 29 08:04:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B2821F9E16 for ; Mon, 29 Apr 2013 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63Z7-qaZbKYs for ; Mon, 29 Apr 2013 08:04:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 87FED21F9E13 for <6man@ietf.org>; Mon, 29 Apr 2013 08:04:30 -0700 (PDT) Received: from BY2FFO11FD020.protection.gbl (10.1.15.204) by BY2FFO11HUB020.protection.gbl (10.1.14.140) with Microsoft SMTP Server (TLS) id 15.0.675.0; Mon, 29 Apr 2013 15:04:22 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 29 Apr 2013 15:04:22 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.184]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 29 Apr 2013 15:03:41 +0000 From: Christian Huitema To: Fernando Gont , Mark Smith Subject: RE: LC comments on stable-privacy-addresses: Interface Index vs. name Thread-Topic: LC comments on stable-privacy-addresses: Interface Index vs. name Thread-Index: AQHOQb150Xk30MNB/UStZkr/hUGQNpjsnHqBgABkvgCAAE+jUA== Date: Mon, 29 Apr 2013 15:03:41 +0000 Message-ID: References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> In-Reply-To: <517E480C.2040305@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(49866001)(4396001)(77982001)(46406003)(59766001)(51856001)(63696002)(54316002)(47736001)(69226001)(47776003)(56776001)(81342001)(20776003)(81542001)(6806003)(53806001)(47976001)(16406001)(23726002)(50466002)(74502001)(33656001)(56816002)(65816001)(44976003)(55846006)(31966008)(46102001)(50986001)(80022001)(76482001)(54356001)(79102001)(74366001)(47446002)(66066001)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB020; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0831C25939 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Ray Hunter , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:04:31 -0000 > The "problem" here is that don't have all the names/IDs we'd like. For ex= ample, using the MAC address as the Interface_ID would do for this=20 > purpose... but the the IPv6 address is tied to the MAC address, and would= change upon replacement of the NIC (which is generally undesirable)... Undesirable by whom? For a laptop, for example, the most likely cause of a = MAC address change is that the user/owner used an administrative command to= change it, probably in an attempt at getting privacy. Keeping the same IID= would defeat the purpose. On the other hand, if I am managing a big server, I would like to retain th= e same IPv6 addresses to avoid disrupting service. But then, if I want a fi= xed address, I would probably ensure that by configuring a fixed address, n= ot by relying on a side effect of automatic address configuration. -- Christian Huitema From v6ops@globis.net Mon Apr 29 12:39:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3005421F9B5B for ; Mon, 29 Apr 2013 12:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNZvNOc-Z9zp for ; Mon, 29 Apr 2013 12:39:42 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 759F421F9B1B for <6man@ietf.org>; Mon, 29 Apr 2013 12:39:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 68D5E8700E4; Mon, 29 Apr 2013 21:39:26 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYvDZwvOrzSO; Mon, 29 Apr 2013 21:39:26 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 315EC87005E; Mon, 29 Apr 2013 21:39:26 +0200 (CEST) Message-ID: <517ECC67.10702@globis.net> Date: Mon, 29 Apr 2013 21:39:19 +0200 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Christian Huitema Subject: Re: RE: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Brian Haberman , Fernando Gont , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:39:43 -0000 Christian Huitema wrote: >> The "problem" here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this >> purpose... but the the IPv6 address is tied to the MAC address, and would change upon replacement of the NIC (which is generally undesirable)... > > Undesirable by whom? For a laptop, for example, the most likely cause of a MAC address change is that the user/owner used an administrative command to change it, probably in an attempt at getting privacy. Keeping the same IID would defeat the purpose. > > On the other hand, if I am managing a big server, I would like to retain the same IPv6 addresses to avoid disrupting service. But then, if I want a fixed address, I would probably ensure that by configuring a fixed address, not by relying on a side effect of automatic address configuration. > > -- Christian Huitema > > > Right. But a bad side effect of manually configuring fixed addresses is that you derail all of the good work around renumbering. It might prove operationally useful to be able to configure a static IID, but still continue to use of a variable network prefix (derived from RA). regards, RayH From fgont@si6networks.com Mon Apr 29 12:43:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E72E21F9B3B for ; Mon, 29 Apr 2013 12:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xIV8QG6VDgy for ; Mon, 29 Apr 2013 12:43:44 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4221F9B36 for <6man@ietf.org>; Mon, 29 Apr 2013 12:43:44 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWtuy-0007LZ-5N; Mon, 29 Apr 2013 21:43:28 +0200 Message-ID: <517ECC5B.1070609@si6networks.com> Date: Mon, 29 Apr 2013 16:39:07 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Huitema Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, RJ Atkinson , Brian Haberman , Ray Hunter , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:43:45 -0000 On 04/29/2013 12:03 PM, Christian Huitema wrote: >> The "problem" here is that don't have all the names/IDs we'd like. >> For example, using the MAC address as the Interface_ID would do for >> this purpose... but the the IPv6 address is tied to the MAC >> address, and would change upon replacement of the NIC (which is >> generally undesirable)... > > Undesirable by whom? For a laptop, for example, the most likely cause > of a MAC address change is that the user/owner used an administrative > command to change it, probably in an attempt at getting privacy. > Keeping the same IID would defeat the purpose. I don't think that's the rule for users, though. That said, in such scenarios you should probably do *only* RFC4941. And, if you're bothering to run an administrative command to change the MAC each time you connect, why not run just another command and short-cut SLAAC to get any address you want? > On the other hand, if I am managing a big server, I would like to > retain the same IPv6 addresses to avoid disrupting service. But then, > if I want a fixed address, I would probably ensure that by > configuring a fixed address, not by relying on a side effect of > automatic address configuration. There are many deployments that employ SLAAC, where address changes would be undesirable (probably the case for most organizational networks doing slaac). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dougb@dougbarton.us Mon Apr 29 13:00:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E24321F9BCC for ; Mon, 29 Apr 2013 13:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZwI+b7fPDb6 for ; Mon, 29 Apr 2013 13:00:52 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 5522621F9BC8 for ; Mon, 29 Apr 2013 13:00:52 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:855b:c13f:73da:cddb] (unknown [IPv6:2001:470:d:5e7:855b:c13f:73da:cddb]) by dougbarton.us (Postfix) with ESMTPSA id 5E85622B3F for ; Mon, 29 Apr 2013 20:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367265648; bh=Wg2Llr1p0R8BZPDBhxqkQD41CnA/1Atqnh8Etm22D1c=; h=Date:From:To:Subject:References:In-Reply-To; b=t2OCRwpNwqjBP6aaeou3umW9K84ebjR/HN1aWnbv9B8L4T0IomdAZKVgx29hhZS7a uQmCHlyaJIn7gU/3EYSiS+7gQHMbQjv5QJ+sxquFNxcb/6EQUCPJTfAyzKrekKtfC/ 4AZyPAPBIIIE00VRKb8bo8ph7wzN3ulzhGuPXncI= Message-ID: <517ED170.4050709@dougbarton.us> Date: Mon, 29 Apr 2013 13:00:48 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> <517ECC67.10702@globis.net> In-Reply-To: <517ECC67.10702@globis.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:00:56 -0000 On 04/29/2013 12:39 PM, Ray Hunter wrote: > Christian Huitema wrote: >>> The "problem" here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this >>> purpose... but the the IPv6 address is tied to the MAC address, and would change upon replacement of the NIC (which is generally undesirable)... >> >> Undesirable by whom? For a laptop, for example, the most likely cause of a MAC address change is that the user/owner used an administrative command to change it, probably in an attempt at getting privacy. Keeping the same IID would defeat the purpose. >> >> On the other hand, if I am managing a big server, I would like to retain the same IPv6 addresses to avoid disrupting service. But then, if I want a fixed address, I would probably ensure that by configuring a fixed address, not by relying on a side effect of automatic address configuration. >> >> -- Christian Huitema >> >> >> > Right. But a bad side effect of manually configuring fixed addresses is > that you derail all of the good work around renumbering. > > It might prove operationally useful to be able to configure a static > IID, but still continue to use of a variable network prefix (derived > from RA). I only peripherally followed the early discussion about this topic (only so many hours in the day). I confess that I never "got" the need for this, but lots of people seemed enthusiastic about it, so I put it in the category of things to figure out later. :) Now that there is non-trivial pushback on the draft becoming an RFC I have taken another look, and I still don't get it. Let's assume that there are 2 broad categories that cover a statistically significant percentage of the possible use cases, home and business. I don't see any scenario where the home user would be benefited from stable privacy addresses beyond what 4941 already provides. For business users, I do see a case where they would want to make sure that the same system always used the same address for accessing internal resources (auditing, accountability, etc.). The traditional answer to that has been to turn 4941 off, but that loses the benefits of 4941 when accessing outside resources. (OTOH, if the outside resources are web sites they already have much more sophisticated ways to track you besides IP address, but let's assume that 4941 is still valuable for sake of argument). Assuming my use case analysis is correct (and I would not be surprised if it were not), it seems to me that we could accomplish both goals for the business case by adding a DHCPv6 option that says, "for any traffic on networks with these prefixes, use your 'real' address if you have 4941 enabled." Does that sound like a reasonable option? Doug From fgont@si6networks.com Mon Apr 29 13:12:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F90C21F9A85 for ; Mon, 29 Apr 2013 13:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y12xgRkRiCaj for ; Mon, 29 Apr 2013 13:12:35 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA6721F9A5B for ; Mon, 29 Apr 2013 13:12:35 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWuQo-0008Fe-NW; Mon, 29 Apr 2013 22:12:18 +0200 Message-ID: <517ED417.2090506@si6networks.com> Date: Mon, 29 Apr 2013 17:12:07 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Doug Barton Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> <517ECC67.10702@globis.net> <517ED170.4050709@dougbarton.us> In-Reply-To: <517ED170.4050709@dougbarton.us> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:12:36 -0000 On 04/29/2013 05:00 PM, Doug Barton wrote: > I only peripherally followed the early discussion about this topic (only > so many hours in the day). I confess that I never "got" the need for > this, but lots of people seemed enthusiastic about it, so I put it in > the category of things to figure out later. :) > > Now that there is non-trivial pushback on the draft becoming an RFC I > have taken another look, and I still don't get it. I don't see pushback, but rather feedback and request for improvements -- which is a normal (and healthy) part of the publication process. > Let's assume that > there are 2 broad categories that cover a statistically significant > percentage of the possible use cases, home and business. I don't see any > scenario where the home user would be benefited from stable privacy > addresses beyond what 4941 already provides. Please see the appendix in draft-ietf-stable-privacy-addresses. (and keep in mind that Windows replaces the traditional slaac addresses just to avoid address scanning attacks). > Assuming my use case analysis is correct (and I would not be surprised > if it were not), Not wanting to use temporary addresses (RC4941) does not imply that you want to paste a super-cookie into your IPv6 addresses. Besides, as discussed in the appendix of draft-ietf-stable-privacy-addresses, RFC 4941 and this document are, to some extent, orthogonal. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Apr 29 13:52:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C13121F97CD for ; Mon, 29 Apr 2013 13:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGwbd9kfzwIl for ; Mon, 29 Apr 2013 13:52:45 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9AA21F9B29 for ; Mon, 29 Apr 2013 13:52:37 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWv3e-0000mO-R1; Mon, 29 Apr 2013 22:52:27 +0200 Message-ID: <517ED03E.1090503@si6networks.com> Date: Mon, 29 Apr 2013 16:55:42 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> <000301ce44e5$1f4e5570$5deb0050$@rozanak.com> In-Reply-To: <000301ce44e5$1f4e5570$5deb0050$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Christian Huitema' , 'Alissa Cooper' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:52:53 -0000 Hosnieh, Quite a few times I have responded to your comments, and have even provided pointers to publicly-available papers that you seem to have ignored. I disagree with your comments below... but cannot really invest more time in writing responses you'll ignore. This I-D improves at least two privacy related issues, with minimal effort and complexity. That's usually referred to as "engineering". As noted by others and myself in other messages, there are other aspects that might not even be addressable, or that might be undesirable to address for the general case. (e.g., from the pov of privacy you might want to use a new random address for every new flow... but that generally causes a lot of trouble and complexity). That's as much as I will add to this sub-thread. Thanks, Fernando On 04/29/2013 11:23 AM, Hosnieh Rafiee wrote: > Dear Mark > >> So privacy and security are relative, not absolute. I think this provides > better privacy compared to the use of MAC addresses for IIDs > > Unfortunately that answer is not exactly true. As I explained in my last > messages, it is really related to the lifetime of the router prefix. In > reality, if you do not change it within a short period of time, like when a > MAC address is used, then an attacker will be able to obtain enough > information about this node in order to prepare attacks against during the > time they use the same IID. Then later, the attacker will have the > opportunity to follow his victim when he goes to a new network using the > information he obtained earlier. This means that changing the IP address > now will be of no use . This is why I do not see how privacy is enhanced in > any way with this way of IID generation and I keep reiterating that what > this draft states about also providing privacy is not true. This draft is > just about the generation of IID in a manner not based on MAC addresses and > offers nothing of value concerning privacy issues. > > Privacy and security are relative, that is true. But the way he wants to > maintain privacy is like someone who hides his head in a hole hoping that > nobody will see him. I do not call this privacy. Privacy is relative when > you make as much effort as possible to keep the data confidential. If some > ingenious attackers can come up with new approaches to find your data, then > this is not your fault. I mean by this that if one wants to claim that he > has enhanced privacy, then he will have had to do everything possible to > prevent the currently known privacy attacks. But if you cannot accomplish > that in your solution, then you should not mislead readers by saying that > your solution does.. This is because privacy is like a bottle of water, > where your information is the water inside this bottle. It makes no > difference whether you do not close the tap or just don't close it as > tightly as you should (like this draft), The bottle will leak water, and for > some attackers even a few drops is all they need to initiate further attacks > which can result in much damage to the prey. So, if a draft claim to have > privacy, it cannot just say I will consider just this part of privacy not > others. This is why I suggested to him to just let the users decide on the > lifetime for their IP address when they want to install this feature. In > this case, he does not try to do anything about that bottle; the aim of the > draft is not about privacy but a randomized IID. That way no one will have > any expectations for privacy. So, what I am saying here is that having a > big title which alludes to privacy enhancements does not make sense. > > >> Can you define the "privacy" you don't think it has any effect on? > I have already answered this by what I said in my prior sentence. > > Best, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Mon Apr 29 14:18:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C895F21F9B86 for ; Mon, 29 Apr 2013 14:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtN-aiCuKZla for ; Mon, 29 Apr 2013 14:18:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BCB2321F9B97 for ; Mon, 29 Apr 2013 14:18:17 -0700 (PDT) Received: from kopoli (e179164112.adsl.alicedsl.de [85.179.164.112]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MGCRL-1UIKqq1rE7-00FDLa; Mon, 29 Apr 2013 17:17:54 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <20130412153453.14361.46272.idtracker@ietfa.amsl.com> <72EABFA7-B3E7-4FEF-BABD-4296243AABDC@cdt.org> <517AD1F1.4090602@si6networks.com> <6.2.5.6.2.20130427093454.0c82eca8@resistor.net> <517C61C3.7060703@si6networks.com> <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> <000301ce44e5$1f4e5570$5deb0050$@rozanak.com> <517ED03E.1090503@si6networks.com> In-Reply-To: <517ED03E.1090503@si6networks.com> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Mon, 29 Apr 2013 23:17:43 +0200 Message-ID: <000001ce451f$0363add0$0a2b0970$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxs1Oh6is4EjNGp9KqBUCEn+J12wJTD6xVAsgKG3oBg1eMTwEb04hZApwu0F4BtSxW1QEwxwsBAp1jerEBbzj+SAFjLGhuAdg4OQ4DD6CE8gJ2TNRXldaAD8A= Content-Language: en-us X-Provags-ID: V02:K0:L9rh8Z9v+fGCUSRU4vPl4fMRn1LLqoS4U+3lDWE/S8O ene7Tw0KBVBZKSDVwISuZH7b5BZ2VCAKPQXwEu0cMh56RcqdUH Ai2zTkHV+L6v5TQicJuE44ytew+BEtvTevWVsHN4O5IlOvtRpS 7+QblIyDr+IwMHXPbKd4Ps92FxiEpV0P7XVprOChhLpOoOiZ6U JkSvK4/M4F6F+zTG0AQu7VfMilZvVNgsu97GMKS+Wbb8pFHzc1 TaKO3EKkP7CdUG14K2VeX64vIbcF7BQgE3im4JNKlgk73g7Gjh qMHeDleFYS77o8Bg6Tn+ZpRzgH+jkRXOMc/WpNXi+Xk/HbmaKT YSHjqGEAaA0XyTRFl0To= Cc: 'Christian Huitema' , 'Alissa Cooper' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 21:18:26 -0000 Fernando, I guess that we are at an impasse again. I just want to make it clear to everyone that this proposed draft of yours doesn't really do anything substantial for privacy issues and I find it misleading to mention privacy in the title. I too am extremely busy and cannot afford to devote any more time debating this issue with you. I had stopped this discussion with you once before but some other people asked me to bring it up with you again. I see that it was for naught. Science is not absolute so what is written can just be some ones opinion based on what was happening at that time. In today's environment privacy has come to the fore front and the parameters that were used to define privacy before have changed greatly. It is a much bigger issue and getting bigger every day. Hosnieh -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com] Sent: Monday, April 29, 2013 9:56 PM To: Hosnieh Rafiee Cc: 'Mark Smith'; 'Alissa Cooper'; ipv6@ietf.org; 'Christian Huitema' Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Hosnieh, Quite a few times I have responded to your comments, and have even provided pointers to publicly-available papers that you seem to have ignored. I disagree with your comments below... but cannot really invest more time in writing responses you'll ignore. This I-D improves at least two privacy related issues, with minimal effort and complexity. That's usually referred to as "engineering". As noted by others and myself in other messages, there are other aspects that might not even be addressable, or that might be undesirable to address for the general case. (e.g., from the pov of privacy you might want to use a new random address for every new flow... but that generally causes a lot of trouble and complexity). That's as much as I will add to this sub-thread. Thanks, Fernando On 04/29/2013 11:23 AM, Hosnieh Rafiee wrote: > Dear Mark > >> So privacy and security are relative, not absolute. I think this >> provides > better privacy compared to the use of MAC addresses for IIDs > > Unfortunately that answer is not exactly true. As I explained in my > last messages, it is really related to the lifetime of the router > prefix. In reality, if you do not change it within a short period of > time, like when a MAC address is used, then an attacker will be able > to obtain enough information about this node in order to prepare > attacks against during the time they use the same IID. Then later, the > attacker will have the opportunity to follow his victim when he goes > to a new network using the information he obtained earlier. This means > that changing the IP address now will be of no use . This is why I do > not see how privacy is enhanced in any way with this way of IID > generation and I keep reiterating that what this draft states about > also providing privacy is not true. This draft is just about the > generation of IID in a manner not based on MAC addresses and offers nothing of value concerning privacy issues. > > Privacy and security are relative, that is true. But the way he wants > to maintain privacy is like someone who hides his head in a hole > hoping that nobody will see him. I do not call this privacy. Privacy > is relative when you make as much effort as possible to keep the data > confidential. If some ingenious attackers can come up with new > approaches to find your data, then this is not your fault. I mean by > this that if one wants to claim that he has enhanced privacy, then he > will have had to do everything possible to prevent the currently > known privacy attacks. But if you cannot accomplish that in your > solution, then you should not mislead readers by saying that your > solution does.. This is because privacy is like a bottle of water, > where your information is the water inside this bottle. It makes no > difference whether you do not close the tap or just don't close it as > tightly as you should (like this draft), The bottle will leak water, > and for some attackers even a few drops is all they need to initiate > further attacks which can result in much damage to the prey. So, if a > draft claim to have privacy, it cannot just say I will consider just > this part of privacy not others. This is why I suggested to him to > just let the users decide on the lifetime for their IP address when > they want to install this feature. In this case, he does not try to do > anything about that bottle; the aim of the draft is not about privacy > but a randomized IID. That way no one will have any expectations for privacy. So, what I am saying here is that having a big title which alludes to privacy enhancements does not make sense. > > >> Can you define the "privacy" you don't think it has any effect on? > I have already answered this by what I said in my prior sentence. > > Best, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dougb@dougbarton.us Mon Apr 29 15:04:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E2721F9C50 for ; Mon, 29 Apr 2013 15:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6H9+LWsskNT for ; Mon, 29 Apr 2013 15:04:35 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8221F9C4D for ; Mon, 29 Apr 2013 15:04:34 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:855b:c13f:73da:cddb] (unknown [IPv6:2001:470:d:5e7:855b:c13f:73da:cddb]) by dougbarton.us (Postfix) with ESMTPSA id 5908F22B62 for ; Mon, 29 Apr 2013 22:04:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367273073; bh=Z59hkEvPIE3ghaQ3NvvGm+1kJ54mN4Vn4CTyOdGYblQ=; h=Date:From:To:Subject:References:In-Reply-To; b=Nlj7QMlBjLda/1xdsHYzT44oDqkbG/hf1u6+kUju1DzXuz+VqBB5ByCytdxdrlSae Bl9QE8QMaB1n+v28Ygdg8cBhpeKViPazRTWXIKi9jcls6+o5vJxYUQw5UImIsiCmFC h7rxwUy7SJJis3QbMi6NFzRgfGUZEByfJprpqdLM= Message-ID: <517EEE71.5000500@dougbarton.us> Date: Mon, 29 Apr 2013 15:04:33 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> <517ECC67.10702@globis.net> <517ED170.4050709@dougbarton.us> <517ED417.2090506@si6networks.com> In-Reply-To: <517ED417.2090506@si6networks.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:04:38 -0000 On 04/29/2013 01:12 PM, Fernando Gont wrote: > On 04/29/2013 05:00 PM, Doug Barton wrote: >> I only peripherally followed the early discussion about this topic (only >> so many hours in the day). I confess that I never "got" the need for >> this, but lots of people seemed enthusiastic about it, so I put it in >> the category of things to figure out later. :) >> >> Now that there is non-trivial pushback on the draft becoming an RFC I >> have taken another look, and I still don't get it. > > I don't see pushback, but rather feedback and request for improvements > -- which is a normal (and healthy) part of the publication process. I'll leave it for the IESG to judge consensus of course, but I have seen a non-zero number of people provide "feedback" as you term it anywhere from "this is a bad idea," to "this probably won't work," to "It's not clear why this is necessary at all." The fact that they are more polite than I am may have allowed for that feedback to be misinterpreted however. >> Let's assume that >> there are 2 broad categories that cover a statistically significant >> percentage of the possible use cases, home and business. I don't see any >> scenario where the home user would be benefited from stable privacy >> addresses beyond what 4941 already provides. > > Please see the appendix in draft-ietf-stable-privacy-addresses. (and > keep in mind that Windows replaces the traditional slaac addresses just > to avoid address scanning attacks). I did. I don't find any of your arguments compelling. A.1.1 In the case of bittorrent at least I'm fairly certain that you have a fundamental misunderstanding as to how p2p connections are set up. But even if you don't, why would anyone who sets up a server-like function on their system have an expectation of privacy? A.1.2 Even if all your points from A.1.1 are valid, if the attacker is on the same network they have other ways of tracking the targeted system. Sure, knowing/guessing its address would make that easier, but if you're on the same network with a determined attacker you've pretty much lost the game already. If you're not on the same network the potential for exploiting this knowledge is minimal given properly configured firewalls. A.1.3 Printers? Seriously? This is a threat the IETF needs to mitigate against? A.2 Nothing in this section is mitigated by your proposal, other than the discarding of certain traditionally characteristic bits, which is covered by another draft already. >> Assuming my use case analysis is correct (and I would not be surprised >> if it were not), > > Not wanting to use temporary addresses (RC4941) does not imply that you > want to paste a super-cookie into your IPv6 addresses. What is the intersection of the sets of people who do not want to use 4941, but do want the privacy it provides? I'm not seeing it. As pointed out previously, in the case of tracking for web services your IP address is superfluous anyway. Do you have any other types of services in mind, and a description of why they can't use 4941? > Besides, as > discussed in the appendix of draft-ietf-stable-privacy-addresses, RFC > 4941 and this document are, to some extent, orthogonal. I'm not arguing against that. As I said, I understand the attraction of using the real address on your enterprise network(s), and using 4941 outside. I just don't think your proposal accomplishes anything that justifies the additional complexity, if it can even work as advertised. Doug From brian@innovationslab.net Mon Apr 29 15:44:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C5C21F9BEB for ; Mon, 29 Apr 2013 15:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVg7--7LxxaV for ; Mon, 29 Apr 2013 15:44:43 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 518AC21F9991 for ; Mon, 29 Apr 2013 15:44:43 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id F09D1880E7 for ; Mon, 29 Apr 2013 15:44:42 -0700 (PDT) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9FE3E1368231 for ; Mon, 29 Apr 2013 15:44:42 -0700 (PDT) Message-ID: <517EF7EB.1050109@innovationslab.net> Date: Mon, 29 Apr 2013 18:44:59 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> <517ECC67.10702@globis.net> <517ED170.4050709@dougbarton.us> <517ED417.2090506@si6networks.com> <517EEE71.5000500@dougbarton.us> In-Reply-To: <517EEE71.5000500@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:44:48 -0000 All, I just want everyone to be aware that I have stopped the publication process on this document and sent it back to the WG. There was significant feedback that I felt needed to be dealt with and that the resulting changes may alter the document significantly. The author and the document shepherd will be setting up an issue tracker for this document to ensure all issues raised are addressed within the document. Given this, I want to make sure that everyone is aware that this means that the WG has to reach consensus on the contents of the document as if it were a new document. Please let me know if you have any questions on this approach. Regards, Brian On 4/29/13 6:04 PM, Doug Barton wrote: > On 04/29/2013 01:12 PM, Fernando Gont wrote: >> On 04/29/2013 05:00 PM, Doug Barton wrote: >>> I only peripherally followed the early discussion about this topic (only >>> so many hours in the day). I confess that I never "got" the need for >>> this, but lots of people seemed enthusiastic about it, so I put it in >>> the category of things to figure out later. :) >>> >>> Now that there is non-trivial pushback on the draft becoming an RFC I >>> have taken another look, and I still don't get it. >> >> I don't see pushback, but rather feedback and request for improvements >> -- which is a normal (and healthy) part of the publication process. > > I'll leave it for the IESG to judge consensus of course, but I have seen > a non-zero number of people provide "feedback" as you term it anywhere > from "this is a bad idea," to "this probably won't work," to "It's not > clear why this is necessary at all." The fact that they are more polite > than I am may have allowed for that feedback to be misinterpreted however. > >>> Let's assume that >>> there are 2 broad categories that cover a statistically significant >>> percentage of the possible use cases, home and business. I don't see any >>> scenario where the home user would be benefited from stable privacy >>> addresses beyond what 4941 already provides. >> >> Please see the appendix in draft-ietf-stable-privacy-addresses. (and >> keep in mind that Windows replaces the traditional slaac addresses just >> to avoid address scanning attacks). > > I did. I don't find any of your arguments compelling. > > A.1.1 > In the case of bittorrent at least I'm fairly certain that you have a > fundamental misunderstanding as to how p2p connections are set up. But > even if you don't, why would anyone who sets up a server-like function > on their system have an expectation of privacy? > > A.1.2 > Even if all your points from A.1.1 are valid, if the attacker is on the > same network they have other ways of tracking the targeted system. Sure, > knowing/guessing its address would make that easier, but if you're on > the same network with a determined attacker you've pretty much lost the > game already. If you're not on the same network the potential for > exploiting this knowledge is minimal given properly configured firewalls. > > A.1.3 > Printers? Seriously? This is a threat the IETF needs to mitigate against? > > A.2 > Nothing in this section is mitigated by your proposal, other than the > discarding of certain traditionally characteristic bits, which is > covered by another draft already. > >>> Assuming my use case analysis is correct (and I would not be surprised >>> if it were not), >> >> Not wanting to use temporary addresses (RC4941) does not imply that you >> want to paste a super-cookie into your IPv6 addresses. > > What is the intersection of the sets of people who do not want to use > 4941, but do want the privacy it provides? I'm not seeing it. As pointed > out previously, in the case of tracking for web services your IP address > is superfluous anyway. Do you have any other types of services in mind, > and a description of why they can't use 4941? > >> Besides, as >> discussed in the appendix of draft-ietf-stable-privacy-addresses, RFC >> 4941 and this document are, to some extent, orthogonal. > > I'm not arguing against that. As I said, I understand the attraction of > using the real address on your enterprise network(s), and using 4941 > outside. I just don't think your proposal accomplishes anything that > justifies the additional complexity, if it can even work as advertised. > > Doug > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pkern@simplex.0x539.de Mon Apr 29 16:27:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7121F9B0D for ; Mon, 29 Apr 2013 16:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBjPU3Q4ET+7 for ; Mon, 29 Apr 2013 16:27:41 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id AC20C21F9AFC for ; Mon, 29 Apr 2013 16:27:40 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UWxTs-0001ws-QB for ipv6@ietf.org; Tue, 30 Apr 2013 01:27:36 +0200 Received: from [2001:470:720c:0:3568:ccaf:4af0:cb2c] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UWxTu-0000k8-1r for ipv6@ietf.org; Tue, 30 Apr 2013 01:27:38 +0200 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UWxTt-000394-4x for ipv6@ietf.org; Tue, 30 Apr 2013 01:27:37 +0200 Date: Tue, 30 Apr 2013 01:27:37 +0200 From: Philipp Kern To: ipv6@ietf.org Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Message-ID: <20130429232737.GB10527@simplex.0x539.de> References: <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> <000301ce44e5$1f4e5570$5deb0050$@rozanak.com> <517ED03E.1090503@si6networks.com> <000001ce451f$0363add0$0a2b0970$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <000001ce451f$0363add0$0a2b0970$@rozanak.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 23:27:46 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hosnieh, am Mon, Apr 29, 2013 at 11:17:43PM +0200 hast du folgendes geschrieben: > I guess that we are at an impasse again. I just want to make it clear to > everyone that this proposed draft of yours doesn't really do anything > substantial for privacy issues and I find it misleading to mention privacy > in the title. you seem to argue that privacy can only be mentioned if the protection is absolute. Fernando argues that even small steps are worthwhile. The main question seems to be if Fernando's draft has enough privacy value in itself apart from stable addressing that is not based on Ethernet MAC addresses. It does seem to me that to the outside world a globally unique identifier is no longer presented to the world in an address that is fixed for a given (network, host) tuple. Obviously this does not help against local attackers that can query for the MAC and obviously this does not help against ongoing tracking of the concrete host within that single network from the outside world. Fernando does not argue against using privacy extensions as an addition to this solution. Windows resorted to use some random identifier instead of EUI64 addresses by default in order not to leak the MAC address. This draft just proposes a similar algorithm for stable autoconfiguration. The title says "privacy-enhanced", maybe "Stable non-IEEE-identifier-based Addresses" (with a cuter title made up by a native speaker) would explain the goal in the title a bit more clearly. You wouldn't argue against listing the privacy benefits this has over the traditional way of EUI64-based SLAAC address assignment, I presume? Kind regards Philipp Kern --opJtzjQTFsWo+cga Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJRfwHpAAoJEERuJUU10FbsmcUIAMJIg/xtLqqcCyFnC26i5lUW hCqu82BHRfxdfGdcZ0aI/1eeiFvqTdVq2tyEsqDEAtjIZ0B/qsqLVz6Ixwr+XUyc 7u9FeqqrYozB1HG+z1oBO1+Y/xCHORXcKkFbSHfkUvL7YXTZ/jK4nHKtqQ5TPmtA eJ5EwcV8NL9qMycXO95mMJ7adjswSZJ2/LXhOeBe8ICy8WG+2zg6ohgbwWoBGwFv 9Y02XVoBn+61rhJlrR+D+m2/zNzFy+BDARunevDJ/x0i89hdv2Mu0dB5b0bIkd+w gBmFg0TNRXvLAxjeBsj+sWEFJSsu2g6cgasDshPIEwY17Qgl2JllEENl8Cmk3WE= =aUzC -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From fgont@si6networks.com Mon Apr 29 19:03:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BC621F9AA1 for ; Mon, 29 Apr 2013 19:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV4GbgKZGGn6 for ; Mon, 29 Apr 2013 19:03:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEEE21F98E9 for ; Mon, 29 Apr 2013 19:03:28 -0700 (PDT) Received: from [186.134.13.197] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UWzub-0001Xx-AM; Tue, 30 Apr 2013 04:03:21 +0200 Message-ID: <517F2660.9050105@si6networks.com> Date: Mon, 29 Apr 2013 23:03:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Doug Barton Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> <517ECC67.10702@globis.net> <517ED170.4050709@dougbarton.us> <517ED417.2090506@si6networks.com> <517EEE71.5000500@dougbarton.us> In-Reply-To: <517EEE71.5000500@dougbarton.us> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 02:03:29 -0000 On 04/29/2013 07:04 PM, Doug Barton wrote: >>> Let's assume that >>> there are 2 broad categories that cover a statistically significant >>> percentage of the possible use cases, home and business. I don't see any >>> scenario where the home user would be benefited from stable privacy >>> addresses beyond what 4941 already provides. >> >> Please see the appendix in draft-ietf-stable-privacy-addresses. (and >> keep in mind that Windows replaces the traditional slaac addresses just >> to avoid address scanning attacks). > > I did. I don't find any of your arguments compelling. > > A.1.1 > In the case of bittorrent at least I'm fairly certain that you have a > fundamental misunderstanding as to how p2p connections are set up. But > even if you don't, why would anyone who sets up a server-like function > on their system have an expectation of privacy? If what you're trying to accomplish doesn't *require* you to make it trivial for cooperating nodes to correlate your activities, I'm not sure why you should. > A.1.2 > Even if all your points from A.1.1 are valid, if the attacker is on the > same network they have other ways of tracking the targeted system. Where in the attack scenarios are we assuming that the attacker is on the same network? > Sure, > knowing/guessing its address would make that easier, but if you're on > the same network with a determined attacker you've pretty much lost the > game already. If you're not on the same network the potential for > exploiting this knowledge is minimal given properly configured firewalls. If you're implying a network-based firewall, you cannot rely on that. If you're implying a host-based firewall, it's not unusual for firewalls to respond to incoming packets (think TCP RSTs, ICMP unreach, etc.). (And, from that pov he.. you shouldn't bother to do RFC4941, because you should be using tor if you care about privacy...) > A.1.3 > Printers? Seriously? This is a threat the IETF needs to mitigate against? Doug, that's just a simple example. Call that file server, or anything else. The point is: why should you disclose more information than the one you really need to disclose to achieve your desired goal? > A.2 > Nothing in this section is mitigated by your proposal, other than the > discarding of certain traditionally characteristic bits, which is > covered by another draft already. Not sure what you mean. So far, when it comes to slaac, you have two schemes implemented: 1) traditional slaac addresses embedding IEEE identifiers 2) Windows' approach of replacing the traditional slaac addresses with a time-invariant version of RFC4941. "1)" is vulnerable to address scanning attacks. "2)" mitigates them, but still results in IIDs that are constant across networks, which lead to the issues discussed in Appendix A.1 (and its subsections) of draft-ietf-6man-stable-privacy-addresses. >>> Assuming my use case analysis is correct (and I would not be surprised >>> if it were not), >> >> Not wanting to use temporary addresses (RC4941) does not imply that you >> want to paste a super-cookie into your IPv6 addresses. > > What is the intersection of the sets of people who do not want to use > 4941, but do want the privacy it provides? I'm not seeing it. This scheme is NOT an alternative to RFC4941. For instance, if you're doing RFC4941, you still benefit from implementing this (it will remove the "constant across networks" IIDs, and will also mitigate address-scanning attacks that leverage address patterns). >> Besides, as >> discussed in the appendix of draft-ietf-stable-privacy-addresses, RFC >> 4941 and this document are, to some extent, orthogonal. > > I'm not arguing against that. As I said, I understand the attraction of > using the real address on your enterprise network(s), and using 4941 > outside. I just don't think your proposal accomplishes anything that > justifies the additional complexity, if it can even work as advertised. Let me ask a different set of questions: * What's the reason for which you want patterns on your IPv6 addresses? * Why wouldn't you want to make IPv6 address scanning attacks unfeasible? * Why would you want IIDs that are constant across networks? * When you say "complexity", are you referring to "implementation complexity"? -- does computing a hash each time you do slaac mean "complexity" to you? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tjc@ecs.soton.ac.uk Mon Apr 29 23:17:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0AF21F9BAA for ; Mon, 29 Apr 2013 23:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qf1cewYltc0 for ; Mon, 29 Apr 2013 23:17:18 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0CB21F9B93 for <6man@ietf.org>; Mon, 29 Apr 2013 23:17:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r3U6HAP2013963 for <6man@ietf.org>; Tue, 30 Apr 2013 07:17:10 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r3U6HAP2013963 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1367302631; bh=3z+ADTiGzhvEvPegGtuYqP6aRsc=; h=Subject:References:From:In-Reply-To:Date:To:Mime-Version; b=u6KZQGuWl6ZiqqfdBwlKlpyTIEw3M/xlcKvF5aHMcwCez7y4+2vgWHHY5Tsl49F1B XT498BE3suMvJL9tcg3kdQDckPyR720NolOfw+Wsz8FQz+MScMYVmQb7eUL/pgQn2i Z/GD2qBzZtgBxFUNI+9ADPiJhPfuyfya3CgGDMjI= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p3Y7HA0430636235Ql ret-id none; Tue, 30 Apr 2013 07:17:10 +0100 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r3U6Foms027455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6man@ietf.org>; Tue, 30 Apr 2013 07:15:51 +0100 Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> <517ECC67.10702@globis.net> <86F8511A-3692-48ED-88FB-73FE70543FBA@ecs.soton.ac.uk> From: Tim Chown Content-Type: multipart/alternative; boundary=Apple-Mail-FB716F57-1FE5-46FB-B2B7-E33522739150 X-Mailer: iPad Mail (10B329) In-Reply-To: <517ECC67.10702@globis.net> Message-ID: Date: Tue, 30 Apr 2013 07:15:52 +0100 To: "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p3Y7HA043063623500; tid=p3Y7HA0430636235Ql; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r3U6HAP2013963 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 06:17:19 -0000 --Apple-Mail-FB716F57-1FE5-46FB-B2B7-E33522739150 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 29 Apr 2013, at 20:39, Ray Hunter wrote: > Christian Huitema wrote: >>> The "problem" here is that don't have all the names/IDs we'd like. For e= xample, using the MAC address as the Interface_ID would do for this=20 >>> purpose... but the the IPv6 address is tied to the MAC address, and woul= d change upon replacement of the NIC (which is generally undesirable)... >>=20 >> Undesirable by whom? For a laptop, for example, the most likely cause of a= MAC address change is that the user/owner used an administrative command to= change it, probably in an attempt at getting privacy. Keeping the same IID w= ould defeat the purpose. >>=20 >> On the other hand, if I am managing a big server, I would like to retain t= he same IPv6 addresses to avoid disrupting service. But then, if I want a fi= xed address, I would probably ensure that by configuring a fixed address, no= t by relying on a side effect of automatic address configuration. >>=20 >> -- Christian Huitema > Right. But a bad side effect of manually configuring fixed addresses is > that you derail all of the good work around renumbering. >=20 > It might prove operationally useful to be able to configure a static > IID, but still continue to use of a variable network prefix (derived > from RA). As per http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifier= s-02 ? Tim --Apple-Mail-FB716F57-1FE5-46FB-B2B7-E33522739150 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Christian Huitema wrote:
The "problem" here is that don'= t have all the names/IDs we'd like. For example, using the MAC address as th= e Interface_ID would do for this
purpose... but the the I= Pv6 address is tied to the MAC address, and would change upon replacement of= the NIC (which is generally undesirable)...

Undesirable by whom? For a laptop, for example, the most li= kely cause of a MAC address change is that the user/owner used an administra= tive command to change it, probably in an attempt at getting privacy. Keepin= g the same IID would defeat the purpose.

O= n the other hand, if I am managing a big server, I would like to retain the s= ame IPv6 addresses to avoid disrupting service. But then, if I want a fixed a= ddress, I would probably ensure that by configuring a fixed address, not by r= elying on a side effect of automatic address configuration.

-- Christian Huitema

<= /span>

Right. But a bad side effect of manually configuring fixed addresse= s is
that you derail all of the good work around renumbering= .

It might prove operationally useful to be= able to configure a static
IID, but still continue to use o= f a variable network prefix (derived
from RA).

As per http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-= identifiers-02 ?

<= span style=3D"font-size: 15px; line-height: 19px; white-space: nowrap; -webk= it-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill= -color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba= (77, 128, 180, 0.230469);">Tim
= --Apple-Mail-FB716F57-1FE5-46FB-B2B7-E33522739150-- From internet-drafts@ietf.org Mon Apr 29 23:30:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7867221F9C57; Mon, 29 Apr 2013 23:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk7XZVAOyHhx; Mon, 29 Apr 2013 23:30:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E7321F9C3C; Mon, 29 Apr 2013 23:30:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130430063039.18910.18065.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 23:30:39 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 06:30:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-addr-select-opt-10.txt Pages : 10 Date : 2013-04-29 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From n@arifumi.net Mon Apr 29 23:37:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DD021F99FD for ; Mon, 29 Apr 2013 23:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCjAYh3TvwNC for ; Mon, 29 Apr 2013 23:36:56 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2272F21F99E4 for ; Mon, 29 Apr 2013 23:36:55 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id 14so130400pdj.27 for ; Mon, 29 Apr 2013 23:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=VkGQSuHBQPqcvU/mP4RYERRqLI49Od/yVWa1vkw6T8E=; b=EySu8KGgwbvAN9Jcz1MqfL+R40QV6TVtyoz96QGT53y4o8ScmxhJ4q3DEhHZnpio55 lfmIR+RXZPjRM8GEFUTG34sgGIu7J32IAr2AGqvkmUT5rEFn2yT5/hMUfeeYSTppdtNr JrZLu6DCasqP2vOndxfx/5ma/x7kRpkt+Tx8Kr+7oIPiRb63jmEqLmS7Qtd9Vo41yWZ/ 0TsQgS4bLxSV9PsCr9gUYMTb9fxAHqs53lDgnM7SiLj9xI5RFt/YccHa5B19fdYqZZYi gyQBfDaw5gygRXMrNYDGu1xrwjRrKdolqNyzDR2x2osgdN1jw46r1FtY4BanEE+e/vNJ TJMg== MIME-Version: 1.0 X-Received: by 10.66.221.105 with SMTP id qd9mr46600461pac.101.1367303814775; Mon, 29 Apr 2013 23:36:54 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.209.229 with HTTP; Mon, 29 Apr 2013 23:36:54 -0700 (PDT) X-Originating-IP: [114.186.104.206] In-Reply-To: <517A9E97.8030904@innovationslab.net> References: <517A9E97.8030904@innovationslab.net> Date: Tue, 30 Apr 2013 15:36:54 +0900 X-Google-Sender-Auth: dOLo4rSGEcae0I1wjOi8bdDkCDY Message-ID: Subject: Re: AD Evaluation: draft-ietf-6man-addr-select-opt From: Arifumi Matsumoto To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b5d679e2e18b204db8e3a4b X-Gm-Message-State: ALoCoQlIL510881PyulMWNO+auXVcc6SVyKrFih9w+gEvPybxqNozow7fJb/BYgXihYWhPeXFPIR Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "draft-ietf-6man-addr-select-opt@tools.ietf.org" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 06:37:01 -0000 --047d7b5d679e2e18b204db8e3a4b Content-Type: text/plain; charset=ISO-8859-1 Brian, thank you for your review. I posted a revision to reflect your suggestions. Regarding the section 3, I changed several sentences, to reduce implementors' confusion, and to serve better for uniform implementation behavior. Best regards, ---- A new version of I-D, draft-ietf-6man-addr-select-opt-10.txt has been successfully submitted by Arifumi Matsumoto and posted to the IETF repository. Filename: draft-ietf-6man-addr-select-opt Revision: 10 Title: Distributing Address Selection Policy using DHCPv6 Creation date: 2013-04-30 Group: 6man Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-10.txt Status: http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt Htmlized: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-10 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. 2013/4/27 Brian Haberman > Hi all, > I have performed my usual AD review of draft-ietf-6man-addr-select-**opt > prior to it moving towards IETF Last Call. The document is well-written > and I only have a few comments. Once we have resolved these, we can move > the document along in the publication process... > > 1. Section 2 > > * The beginning of this section indicates that the Address Selection > option contains zero or more policy table options. It would be good to > clarify that sending an Address Selection option with zero policy table > options allows the operator to convey the values of the A & P flags. > > * The descriptions of "precedence" and "label" should probably indicate > their direct relationship to the policy table structure in RFC 6724. > > 2. In section 3, I was expecting better detail in *how* the information in > the DHCP options is handled. I am not aware of any other DHCP-provided > information that is conditional based on the user's whim. This seems like > it could lead to hard to diagnose brokenness. > > 3. In section 6, I think it is better to point to the actual IANA registry > where the options will be documented, rather than the RFC that created the > registry. > > Regards, > Brian > --047d7b5d679e2e18b204db8e3a4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brian,

thank you for your review.
= I posted a revision to reflect your suggestions.

= Regarding the section 3, I changed several sentences, to reduce implementor= s' confusion, and to serve better for uniform implementation behavior.<= /span>
=
Best regards,

----<= /div>A new version of I-D, draft-ietf-6man-addr-select-opt-10.txt
has been succes= sfully submitted by Arifumi Matsumoto and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-i= etf-6man-addr-select-opt
Revision: =A0 = =A0 =A0 =A010
Title: =A0 = =A0 =A0 =A0 =A0 Distributing Address Selection Policy using DHCPv6 Creation date: = =A0 2013-04-30
Group: =A0 = =A0 =A0 =A0 =A0 6man
Number of pages= : 10
URL: =A0 =A0 =A0 =A0 = =A0 =A0=A0http://www.ietf.org/internet-drafts/draft-ietf-6m= an-addr-select-opt-10.txt
Status: =A0 =A0= =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-ietf-6man-addr-selec= t-opt
Htmlized: =A0 = =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10=
Diff: =A0 =A0 = =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6ma= n-addr-select-opt-10

Abstract:
=A0 =A0RFC 6724 defines default address selectio= n mechanisms for IPv6 that
=A0 =A0allow no= des to select an appropriate address when faced with multiple
=A0 =A0source and/or destination addres= ses to choose between. =A0The RFC 6724
=A0 =A0allowed = for the future definition of methods to administratively
=A0 =A0configure the address selection polic= y information. =A0This document
=A0 =A0defines = a new DHCPv6 option for such configuration, allowing a site
=A0 =A0administrator to distribute addres= s selection policy overriding the
=A0 =A0default = address selection parameters and policy table, and thus
=A0 =A0control the address selection behavior= of nodes in their site.


2013/4/= 27 Brian Haberman <brian@innovationslab.net>
Hi all,
=A0 =A0 =A0I have performed my usual AD review of draft-ietf-6man-addr-sele= ct-opt prior to it moving towards IETF Last Call. =A0The document is= well-written and I only have a few comments. Once we have resolved these, = we can move the document along in the publication process...

1. Section 2

* The beginning of this section indicates that the Address Selection option= contains zero or more policy table options. =A0It would be good to clarify= that sending an Address Selection option with zero policy table options al= lows the operator to convey the values of the A & P flags.

* The descriptions of "precedence" and "label" should p= robably indicate their direct relationship to the policy table structure in= RFC 6724.

2. In section 3, I was expecting better detail in *how* the information in = the DHCP options is handled. =A0I am not aware of any other DHCP-provided i= nformation that is conditional based on the user's whim. =A0This seems = like it could lead to hard to diagnose brokenness.

3. In section 6, I think it is better to point to the actual IANA registry = where the options will be documented, rather than the RFC that created the = registry.

Regards,
Brian

--047d7b5d679e2e18b204db8e3a4b-- From trac+6man@trac.tools.ietf.org Mon Apr 29 23:22:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585A221F9AB5 for ; Mon, 29 Apr 2013 23:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-1hPDd2VSrl for ; Mon, 29 Apr 2013 23:22:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF9321F9A4C for <6man@ietf.org>; Mon, 29 Apr 2013 23:22:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:33507 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UX3xA-0007ZG-IX; Tue, 30 Apr 2013 08:22:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: fgont@si6networks.com X-Trac-Project: 6man Date: Tue, 30 Apr 2013 06:22:16 -0000 X-URL: http://tools.ietf.org/wg/6man/ Subject: [6man] #1: Proper source for an "Interface Identifier" X-Trac-Ticket-URL: http://rsync.tools.ietf.org/wg/6man/trac/ticket/1 Message-ID: <063.6c182637b59f010c5f4ade2dffb3120a@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: fgont@si6networks.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 29 Apr 2013 23:41:01 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 06:22:19 -0000 #1: Proper source for an "Interface Identifier" Version -06 of the document includes the "interface index" in the expression "F()" that generate the stable privacy IIDs. It has been noted that interface indexes might not be stable, and that, in any case, mandating a specific source for tan "interface identifier" would be over- specifying the algorithm -- --------------------------------------+--------------------------- Reporter: fgont@si6networks.com | Owner: Fernando Gont Type: defect | Status: new Priority: major | Milestone: Component: stable-privacy-addresses | Version: Severity: Active WG Document | Keywords: --------------------------------------+--------------------------- Ticket URL: 6man From v6ops@globis.net Tue Apr 30 02:06:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBAE21F9946 for ; Tue, 30 Apr 2013 02:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWR0E4BpL8iJ for ; Tue, 30 Apr 2013 02:06:19 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id A91D421F9904 for <6man@ietf.org>; Tue, 30 Apr 2013 02:06:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C9E0F870078; Tue, 30 Apr 2013 11:06:03 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0g6visEgnjz; Tue, 30 Apr 2013 11:06:03 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A3BDD87005E; Tue, 30 Apr 2013 11:06:03 +0200 (CEST) Message-ID: <517F8975.9040501@globis.net> Date: Tue, 30 Apr 2013 11:05:57 +0200 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Tim Chown Subject: Re: Re: LC comments on stable-privacy-addresses: Interface Index vs. name References: <5179372C.7000808@si6networks.com> <517957F1.6060802@globis.net> <51795E29.9070106@si6networks.com> <1366924409.76427.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5179B5D7.9000100@si6networks.com> <1367208806.6347.YahooMailNeo@web142506.mail.bf1.yahoo.com> <517E480C.2040305@si6networks.com> <517ECC67.10702@globis.net> <86F8511A-3692-48ED-88FB-73FE70543FBA@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 09:06:20 -0000 Tim Chown wrote: > On 29 Apr 2013, at 20:39, Ray Hunter > wrote: > >> Christian Huitema wrote: >>>> The "problem" here is that don't have all the names/IDs we'd like. >>>> For example, using the MAC address as the Interface_ID would do for >>>> this >>>> purpose... but the the IPv6 address is tied to the MAC address, and >>>> would change upon replacement of the NIC (which is generally >>>> undesirable)... >>> >>> Undesirable by whom? For a laptop, for example, the most likely >>> cause of a MAC address change is that the user/owner used an >>> administrative command to change it, probably in an attempt at >>> getting privacy. Keeping the same IID would defeat the purpose. >>> >>> On the other hand, if I am managing a big server, I would like to >>> retain the same IPv6 addresses to avoid disrupting service. But >>> then, if I want a fixed address, I would probably ensure that by >>> configuring a fixed address, not by relying on a side effect of >>> automatic address configuration. >>> >>> -- Christian Huitema >>> >>> >>> >> Right. But a bad side effect of manually configuring fixed addresses is >> that you derail all of the good work around renumbering. >> >> It might prove operationally useful to be able to configure a static >> IID, but still continue to use of a variable network prefix (derived >> from RA). > > As > per http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 > ? > > Tim I hadn't seen that particular draft before, but yes. Of course you'd probably also want to be able to configure IID based ACL's, static routes etc. where the prefix was auto-prepended to the static IID portion of the config. Don't want to hijack the thread, but I see no fundamental reason why your draft couldn't be combined with Fernando's work. From trac+6man@trac.tools.ietf.org Tue Apr 30 00:51:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA22921F9C55 for ; Tue, 30 Apr 2013 00:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeOyNDxCLnHz for ; Tue, 30 Apr 2013 00:51:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A1A1821F9C32 for <6man@ietf.org>; Tue, 30 Apr 2013 00:51:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:39247 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UX5L6-0005hs-QI; Tue, 30 Apr 2013 09:51:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: fgont@si6networks.com X-Trac-Project: 6man Date: Tue, 30 Apr 2013 07:51:04 -0000 X-URL: http://tools.ietf.org/wg/6man/ Subject: [6man] #2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers) X-Trac-Ticket-URL: http://tools.ietf.org/wg/6man/trac/ticket/2 Message-ID: <063.489b47618ceae4216d09e7f502aceb95@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: fgont@si6networks.com, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 30 Apr 2013 04:35:34 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 07:51:07 -0000 #2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers) Some folks have noted that this I-D should clarify what are the issues with traditional SLAAC addresses (addresses that embed link-layer addresses). This is deemed as key to clarify which of them are solved/mitigated by the method discussed in this document. -- --------------------------------------+--------------------------- Reporter: fgont@si6networks.com | Owner: Fernando Gont Type: enhancement | Status: new Priority: minor | Milestone: Component: stable-privacy-addresses | Version: Severity: Active WG Document | Keywords: --------------------------------------+--------------------------- Ticket URL: 6man From ietf@rozanak.com Tue Apr 30 08:39:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896AC21F9947 for ; Tue, 30 Apr 2013 08:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWu8GztnwPZh for ; Tue, 30 Apr 2013 08:39:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 93C0421F9B4C for ; Tue, 30 Apr 2013 08:39:19 -0700 (PDT) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LgYm5-1UrfOy2Alx-00oPwm; Tue, 30 Apr 2013 11:38:42 -0400 From: "Hosnieh Rafiee" To: "'Philipp Kern'" References: <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> <000301ce44e5$1f4e5570$5deb0050$@rozanak.com> <517ED03E.1090503@si6networks.com> <000001ce451f$0363add0$0a2b0970$@rozanak.com> <20130429232737.GB10527@simplex.0x539.de> In-Reply-To: <20130429232737.GB10527@simplex.0x539.de> Subject: RE: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Date: Tue, 30 Apr 2013 17:38:33 +0200 Message-ID: <000301ce45b8$ca16bd70$5e443850$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKcLtBe+C62qWLf2QteTIYCeGpuyAG1LFbVATDHCwECnWN6sQFvOP5IAWMsaG4B2Dg5DgMPoITyAnZM1FcCdsW8RwKL8DVjlq0zsoA= Content-Language: en-us X-Provags-ID: V02:K0:MgZvg1do/6s9UvmPSwm6qxI9pJhU7jf/ZBVgvuH0cDl wUVOHbdB6tLNO/E+vSITltZ9VN9Jm3DdvQzumuBqe3xEwqU1ee 0uPwpntx5gXYAea6/qmcQpxfNfcfwI8Ik55EW2h8feH2DjbEwd +Rvm0163G9gF+luNnNzQwV3Fruf2KytxNguOw8YC8INR0n8Ood js+XBLll1TLqW5Aj9CwY0a6wDERXFcwcUUCuc+2IqHe7U/uPBX uUph6MQOuVh7jr2lwJL+FqqwaNFbjhsY4MAuY4mc4z9uZdmLGM 26Dw/1WJyMCBPd0lBGncBYHTYJ8pxNMBqFUwaobgmNpJj6Wwb5 qqoRdhQP8Iw5A30+r+cU= Cc: Christian Huitema , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 15:39:25 -0000 Philipp, I didn't really want to continue this debate as I have repeatedly stated my views in my past responses, but if you like, I will once again explain it from my point of view. >you seem to argue that privacy can only be mentioned if the protection is absolute. No, absolute is too a big word to use but the definition of the relative is also much different than when using it in reference to security. Unlike security where you can provide relative security through the protection of one protocol and then claim protection for all the associated protocols, privacy is not like that. Because it is related to all data that can be leaked at one time you have no way or partly protecting privacy. The problem with people who think his approach provides privacy is that they compare the relative definition of security with privacy. It is not comparable! >Fernando argues that even small steps are worthwhile. The main question seems to be if Fernando's draft has >enough privacy value in itself apart from stable addressing that is not based on Ethernet >MAC addresses. I call his approach a method for generating an IID without the use of MAC addresses, but it is not an approach for privacy! Exposing a MAC address alone, in the IP address, neither exposes privacy nor protects privacy. This is the main problem with some people in this group that think that not generating an IP address based on MAC will really help in protecting their privacy. It does, but with certain conditions that Fernando's draft doesn't explain. If I use the same IID for a long period of time, say one month or so, what is the difference between having my address generated using a MAC address or based on Fernando's approach? My answer to that is that I see no difference. Why you might ask? Well that is because there are two scenarios in play here. In first scenario my node is not mobile and remains in the same network forever. So my node expects that the router prefix will be changed so that a new IP address can be generated thus protecting his privacy. But what happens when the router prefix is not changed for a long time. The attacker will then be able to gather enough information about this victim node to allow him to do his dirty deeds. Privacy??! I see no privacy here. Now consider the second scenario where my node is mobile. The victim node joins network A, generates its IP address, and remains on the network for an X amount of time. Since the victim node is really only temporary in that network, then it can use the Privacy Extension RFC for generating its IP address as it does not need to have a fixed IP address. What is the benefit of having a fixed IP address when my node is only temporary?? I myself see no benefit. He is just a visitor on that network so why should it be important for him? Suppose that a staff member always uses network A for connecting his laptop to the network. He then moves to network B and then returns to network A. Each time he will be using the same IP address in network A and the same will be true for network B. How difficult would it be for the attacker to understand that this is the same node moving from one network to another? So once again I see no privacy here, even for mobile nodes. But what if he generated his address based on the Privacy Extension RFC. In that case every time he joined network A or network B, he would have new IP addresses (new IIDs) and it would not be easy for the attacker to detect that it is the same node making the moves. This shows that there is already a solution for my mobile node, so why should I use the procedures outlined in this draft?? >Windows resorted to use some random identifier instead of EUI64 addresses by default in order not to leak the MAC address. This draft just proposes a similar algorithm for stable autoconfiguration. >The title says "privacy-enhanced", maybe "Stable non-IEEE-identifier-based Addresses" >(with a cuter title made up by a native speaker) would explain the goal in the title a bit more clearly. You wouldn't argue against listing the privacy benefits this has over the traditional way of EUI64->based SLAAC address assignment, I presume? Yes, If the IETF wants to have an optional approach for IID generation then ""Stable non-IEEE-identifier-based Addresses" is a viable means. However, I assume that resolving the current issue using the current RFCs will be more helpful than having a new document which could confuse users. Finally, this approach does not have wide usage in the current context. As others have also mentioned, if I need more management of my IP addresses or need some fixed IP address on my node, then I could easily configure the DHCP server. I would configure for other nodes and would configure my fixed nodes manually. I will not use SLAAC, and if I want privacy and temporary addresses, then I will use Privacy Extension RFC. If that RFC has any problems with generating the IID then I would extend the algorithm for IID generation there, without having something in between that does not have wide usage. I hope you and others who have the same questions receive the response. Best, Hosnieh From fgont@si6networks.com Tue Apr 30 10:53:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF4D21F9BD4 for ; Tue, 30 Apr 2013 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rsgQlZd-awK for ; Tue, 30 Apr 2013 10:53:05 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8135C21F843E for ; Tue, 30 Apr 2013 10:53:05 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UXEjT-0007ej-EF; Tue, 30 Apr 2013 19:52:52 +0200 Message-ID: <518004E8.9020604@si6networks.com> Date: Tue, 30 Apr 2013 14:52:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: Last Call: (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard References: <517C9B07.8080807@si6networks.com> <000301ce43f1$d449f8c0$7cddea40$@rozanak.com> <000001ce4425$02082510$06186f30$@rozanak.com> <517D7FFB.9070406@gmail.com> <000901ce444c$ed75b2c0$c8611840$@rozanak.com> <1367210846.64716.YahooMailNeo@web142503.mail.bf1.yahoo.com> <000301ce44e5$1f4e5570$5deb0050$@rozanak.com> <517ED03E.1090503@si6networks.com> <000001ce451f$0363add0$0a2b0970$@rozanak.com> <20130429232737.GB10527@simplex.0x539.de> <000301ce45b8$ca16bd70$5e443850$@rozanak.com> In-Reply-To: <000301ce45b8$ca16bd70$5e443850$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 17:53:06 -0000 On 04/30/2013 12:38 PM, Hosnieh Rafiee wrote: > > No, absolute is too a big word to use but the definition of the > relative is also much different than when using it in reference to > security. Unlike security where you can provide relative security > through the protection of one protocol and then claim protection for > all the associated protocols, privacy is not like that. Privacy is handled in the same way as security. Perfect privacy (as with perfect security) doesn't exist... and you usually must decide when putting even more effort on it doesn't make any more sense. > Because it > is related to all data that can be leaked at one time you have no way > or partly protecting privacy. "The same thing could be said about security, if that's your point: your whole system can be compromised at one time". -- Of course, that doesn't make any sense. > The problem with people who think his > approach provides privacy is that they compare the relative > definition of security with privacy. THis approach mitigate a number of privacy issues that arise from using traditional slaac addresses. In many cases, mitigating those is "good enough". >> Fernando argues that even small steps are worthwhile. The main >> question > seems to be if Fernando's draft has >enough privacy value in itself > apart from stable addressing that is not based on Ethernet >MAC > addresses. It does the following: * prevents leaking address patterns * prevents trivial host-tracking across networks. For *me*, that's more than enough. > I call his approach a method for generating an IID without the use of > MAC addresses, but it is not an approach for privacy! If your concern is the name, let's call this "Fernando's addresses" :-) or whatever -- the meat is in the mechanism, rather than the title. > Exposing a MAC > address alone, in the IP address, neither exposes privacy nor > protects privacy. When it comes to host-tracking, what matters is that the IID is constant across networs -- for instance, Windows' approach suffers the same problem. OTOH, embedding the MAC address in the IID possibly leaks address patterns of the local network. > This is the main problem with some people in this > group that think that not generating an IP address based on MAC will > really help in protecting their privacy. It does, but with certain > conditions that Fernando's draft doesn't explain. Not sure what "conditions" you're referring to. Could you please elaborate? > If I use the same > IID for a long period of time, say one month or so, what is the > difference between having my address generated using a MAC address or > based on Fernando's approach? Im not sure how many times I have repeated this already: traditional slaac addresses have IIDs that **are constant across networks**. This scheme results in addresses that have IIDs that **change across networks**. --That's a big different, isn't it? > My answer to that is that I see no > difference. Why you might ask? Well that is because there are two > scenarios in play here. In first scenario my node is not mobile and > remains in the same network forever. So my node expects that the > router prefix will be changed so that a new IP address can be > generated thus protecting his privacy. Why would you expect a *prefix* to change, if your node does not move, when an *address* is supposed to be topologically-dependent?? > But what happens when the > router prefix is not changed for a long time. The attacker will then > be able to gather enough information about this victim node to allow > him to do his dirty deeds. Privacy??! I see no privacy here. No matter how short-lived you make addresses, this will still be the case. FOr instance, with current tools and bandwidths, you do not need a node to be connected for more than a few seconds to have a penetration testing tool attempt what you refer to as "dirty deeds". > Now consider the second scenario where my node is mobile. The victim > node joins network A, generates its IP address, and remains on the > network for an X amount of time. Since the victim node is really only > temporary in that network, then it can use the Privacy Extension RFC > for generating its IP address as it does not need to have a fixed IP > address. How many times do I need to repeat that RFC4941 addresses are generated **in addition** to traditional slaac addresses? So, if you do privacy extensions, you're still doing the MAC-based addresses. And, the fact that youre a mobile node doesn't mean you don't need a stable address. > What is the benefit of having a fixed IP address when my > node is only temporary?? I myself see no benefit. He is just a > visitor on that network so why should it be important for him? Because while you're still in that network, some of the protocols you employ may need a stable address... and because you may not want your e.g. ssh sessions to break every X minutes. FWIW, I'm writing this email on a laptop, which is my mobile node. It tends to stay cnnected for a few hours at home, then for a few hours at my office, then for a few hours at some relative's home I'm visiting, etc. > Suppose that a staff member always uses network A for connecting his > laptop to the network. He then moves to network B and then returns to > network A. Each time he will be using the same IP address in network > A and the same will be true for network B. How difficult would it be > for the attacker to understand that this is the same node moving from > one network to another? Certainly not obvious/possible by just looking at the IPv6 address. -- and if you don't think so, please explain your attack vector. > So once again I see no privacy here, even for > mobile nodes. But what if he generated his address based on the > Privacy Extension RFC. In that case every time he joined network A > or network B, he would have new IP addresses (new IIDs) and it would > not be easy for the attacker to detect that it is the same node > making the moves. I'd just need to learn the fixed address, and then actively poll it at the two networks. > the title a bit more clearly. You wouldn't argue against listing the > privacy benefits this has over the traditional way of EUI64->based > SLAAC address assignment, I presume? > > Yes, If the IETF wants to have an optional approach for IID > generation then ""Stable non-IEEE-identifier-based Addresses" is a > viable means. However, I assume that resolving the current issue > using the current RFCs will be more helpful than having a new > document which could confuse users. This one has been beaten to death. Please read the intro of draft-ietf-6man-stable-privacy-addresses. > Finally, this approach does not have wide usage in the current > context. As others have also mentioned, if I need more management of > my IP addresses or need some fixed IP address on my node, then I > could easily configure the DHCP server. Since you don't control which networks employ DHCP, you cannot rely on that -- you don't really want to reveal your node's identity and become subject to host-tracking attacks when you connect to networks that employ SLAAC, do you? > I would configure for other > nodes and would configure my fixed nodes manually. I will not use > SLAAC, and if I want privacy and temporary addresses, then I will use > Privacy Extension RFC. If that RFC has any problems with generating > the IID then I would extend the algorithm for IID generation there, > without having something in between that does not have wide usage. It doesn't have any "problems". It fixes part of the problem. But the stable addresses still have room for improvements -- and thats what this document tries to do. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From wwwrun@rfc-editor.org Tue Apr 30 22:32:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABA121F869A; Tue, 30 Apr 2013 22:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phyhcErG6TcG; Tue, 30 Apr 2013 22:32:04 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 50C3A21F8653; Tue, 30 Apr 2013 22:32:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E59D46217D; Tue, 30 Apr 2013 22:31:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6935 on IPv6 and UDP Checksums for Tunneled Packets From: rfc-editor@rfc-editor.org Message-Id: <20130501053133.E59D46217D@rfc-editor.org> Date: Tue, 30 Apr 2013 22:31:33 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 05:32:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6935 Title: IPv6 and UDP Checksums for Tunneled Packets Author: M. Eubanks, P. Chimento, M. Westerlund Status: Standards Track Stream: IETF Date: April 2013 Mailbox: marshall.eubanks@gmail.com, Philip.Chimento@jhuapl.edu, magnus.westerlund@ericsson.com Pages: 12 Characters: 29055 Updates: RFC2460 I-D Tag: draft-ietf-6man-udpchecksums-08.txt URL: http://www.rfc-editor.org/rfc/rfc6935.txt This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method. This document is a product of the IPv6 Maintenance 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 Internet Official Protocol Standards (STD 1) 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 http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. 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 wwwrun@rfc-editor.org Tue Apr 30 22:32:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B607921F86C4; Tue, 30 Apr 2013 22:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OQfVUaVnx9X; Tue, 30 Apr 2013 22:32:28 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DD4AA21F88EA; Tue, 30 Apr 2013 22:32:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D1209B1E00C; Tue, 30 Apr 2013 22:31:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6936 on Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums From: rfc-editor@rfc-editor.org Message-Id: <20130501053154.D1209B1E00C@rfc-editor.org> Date: Tue, 30 Apr 2013 22:31:54 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 05:32:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6936 Title: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums Author: G. Fairhurst, M. Westerlund Status: Standards Track Stream: IETF Date: April 2013 Mailbox: gorry@erg.abdn.ac.uk, magnus.westerlund@ericsson.com Pages: 40 Characters: 99557 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-udpzero-12.txt URL: http://www.rfc-editor.org/rfc/rfc6936.txt This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6. This document is a product of the IPv6 Maintenance 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 Internet Official Protocol Standards (STD 1) 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 http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. 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