From brian.e.carpenter@gmail.com Fri Feb 1 00:12: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 9DE7421F871F for ; Fri, 1 Feb 2013 00:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.842 X-Spam-Level: X-Spam-Status: No, score=-99.842 tagged_above=-999 required=5 tests=[AWL=-0.921, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYul4aLwmsVP for ; Fri, 1 Feb 2013 00:12:50 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC2321F86DA for ; Fri, 1 Feb 2013 00:12:49 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so2792892wey.34 for ; Fri, 01 Feb 2013 00:12:48 -0800 (PST) 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:subject:content-type:content-transfer-encoding; bh=jKlTl6DjuFY0rxfmsG9Fw1iJZfiTChQdKYhwp3ScHXY=; b=VSZr7GDgDbDYaDnMk760IQ2jtmffmJyY6vjLMcRY4SC0Bim5XMc2BJ944EZIwHzzqT u8tSjusU2SjihvEirMTg+85fOk/78y+4Ol/PxVDUGL+6iIXOJgV4JjmV+APmpaujz8ib uJ8XQq/fgbvgZr5nAejhLKgr635HCMpk7HOrSRqyGUT1lLsfAqdxnPQ7Fm7oIDv4ayXq RcqFkcDthTy451GqwZyLD5u3wYBtWK2L/Lo39sfsBIooZMSwYkxsWG4GCc9DE75Kc7lN Vdh1xLsbUL0YOLsjy4eVPqfsx1H6eY83vPXg3em2rvKMDbVknMQxHCIdfMHEfZv69G8e Vlbg== X-Received: by 10.180.98.98 with SMTP id eh2mr1119325wib.7.1359706368372; Fri, 01 Feb 2013 00:12:48 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-71.as13285.net. [2.102.219.71]) by mx.google.com with ESMTPS id bw9sm1570207wib.5.2013.02.01.00.12.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 00:12:47 -0800 (PST) Message-ID: <510B790D.8010301@gmail.com> Date: Fri, 01 Feb 2013 08:13:01 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Content-Type: text/plain; charset=ISO-8859-1 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, 01 Feb 2013 08:12:50 -0000 Hi, We've put this together to address the general question of the u/g bits in Interface IDs. Discussion is requested. Brian + Sheng -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-ug-00.txt Date: Fri, 01 Feb 2013 00:10:13 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The U and G bits in IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-carpenter-6man-ug-00.txt Pages : 7 Date : 2013-02-01 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-6man-ug There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-6man-ug-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 roberta.maglione@telecomitalia.it Fri Feb 1 00:26: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 C21F321F8479 for ; Fri, 1 Feb 2013 00:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2+gxIL4AWTg for ; Fri, 1 Feb 2013 00:26:34 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id F263421F8461 for ; Fri, 1 Feb 2013 00:26:33 -0800 (PST) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 1 Feb 2013 09:26:31 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Fri, 1 Feb 2013 09:26:31 +0100 From: Maglione Roberta To: "'Rajiv Asati (rajiva)'" Date: Fri, 1 Feb 2013 09:26:30 +0100 Subject: RE: MAC Address Tracking via DHCP6 Thread-Topic: MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+Ig Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> References: <20121212153725.GA11716@spike.0x539.de> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Brian Hamacher , "ipv6@ietf.org" , Philipp Kern 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, 01 Feb 2013 08:26:34 -0000 Hello Rajiv, is there any relation between your draft and draft-ietf-dhc-addr-registrat= ion-00? Thanks Regards, Roberta -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Raj= iv Asati (rajiva) Sent: Thursday, January 31, 2013 6:27 PM To: Philipp Kern; Brian Hamacher Cc: ipv6@ietf.org Subject: Re: MAC Address Tracking via DHCP6 There is a better way out to track the IPv6 addresses used by the hosts (via SLAAC or static) - http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-tracking Cheers, Rajiv -----Original Message----- From: Philipp Kern Organization: The Debian Project (http://www.debian.org) Date: Wednesday, December 12, 2012 10:37 AM To: Brian Hamacher Cc: "ipv6@ietf.org" Subject: Re: MAC Address Tracking >On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: >> I am looking for a good way to track my users MAC Addresses. I have a >> test DHCPv6 server up and running ISC 4.1.1-P1. When I look through my >> DHCP logs as well as my leases file I do not see the client MAC Address >> anywhere. Do I need to enable an option to allow this to be logged? I >> am looking to figure out how I can track what user had what IP Address >> at any given time. The MAC Address is traditionally how I have done >> this. > >One way would be to poll your routers' ND tables (like fetching ARP tables >in IPv4). As soon as you use relaying you most certainly won't get a >useable MAC address from your client, even though it might be possible in >the same network segment. (The MAC address is not copied from the wire >into the new relayed packet sent by the router to your server.) > >DHCPv6 uses the so-called client identifier extensively and not the MAC >address anymore. So you cannot do any static assignment based on MAC >addresses. > >Kind regards >Philipp Kern -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From rja.lists@gmail.com Fri Feb 1 05:55: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 79FC121F8FA4 for ; Fri, 1 Feb 2013 05:55:01 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfnxIlw8HaKs for ; Fri, 1 Feb 2013 05:55:01 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id D36EA21F88E5 for ; Fri, 1 Feb 2013 05:55:00 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id b4so1804788qen.4 for ; Fri, 01 Feb 2013 05:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=HKRM3xqfYMIIP5s6+gdPVlXiqqT7J2qzj30Gp3rg0CM=; b=pOHddQQ2lTMalyNCCALCLvKtlw1NYCXe1fcIl9zmpR/q7lUrJMb00SzQspY/HTG/SY C5VM3UhGiSu4kAOgs4oiYbfxV2Hn1ORGLpI1ifHXAgi2GKHH2e0WJM8yep+XkOCn2uC4 kLmTg3VGSUw1Fs11N800swdPX1eccALZB+hqXAKDeqP4VBRfUo5iL0E4IZVzTcmt36zn 6ERDGKAAgnkwnrP1+wfSggF8k9G0ZiQlE1gyd8Bhs494AKYKGAKytuRZVcZmmu8pbTXR RD6P4lFlgWm27aWoVqz6MXkpnOg1uvPhivn6SmW/paEeFIez+y1qddCjfXYx27KO7AkO 0RPg== X-Received: by 10.49.133.68 with SMTP id pa4mr15115464qeb.50.1359726899682; Fri, 01 Feb 2013 05:54:59 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id z17sm6744746qem.4.2013.02.01.05.54.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 05:54:58 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: 4rd IID range & IPv6 addressing architecture From: RJ Atkinson In-Reply-To: <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> Date: Fri, 1 Feb 2013 08:54:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> To: ipv6@ietf.org 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: Fri, 01 Feb 2013 13:55:01 -0000 On 31 Jan 2013, at 13:11 , R=E9mi Despr=E9s wrote: > What ensures 4rd doesn't conflict with ILNP isn't at all > that ILNP only uses u=3D0. =20 >=20 > It is that, in ILNP, no u=3Dg=3D1 is used in *unicast* addresses > (those whose IIDs are specified by RFC 4291).=20 This is still inaccurate. =20 I REALLY would be greatly obliged if you would not speculate=20 about ILNP on IETF/IRTF mailing lists, primarily because=20 any speculation is likely to be wrong -- and create needless confusion amongst other folks on those lists.=20 Some published ILNP papers talk about a form of multicast addressing/routing that we believe is novel and are exploring. =20 This combines a unicast routing prefix in the high-order=20 64-bits with an IEEE EUI-64 compliant (and RFC-4291=20 compliant) multicast group ID (i.e., U=3DG=3D1) in the low-order=20 64-bits. Because of existing IETF standards-track work=20 where U=3D0, for example CGAs or "privacy" addresses, the=20 U=3D0 identifier space (i.e., U=3D0 and G=3D1) can NOT be used=20 for multicast identifiers. So the proposed 4rd reservation of all (or most) uses of=20 addresses with the combination of (A) U=3DG=3D1 identifier space=20 and (B) unicast routing prefix is a direct conflict with published ILNP papers and active ILNP work. Both ILNP and 4rd are Experimental, at least today. =20 This is why I tabled the possibility of allocating=20 a small portion of the U=3DG=3D1 space under RFC-3692 shared=20 experimental use rules. That would permit multiple=20 experiments to proceed, and is the usual IETF custom for experimental work when a limited protocol-registry resource is involved. Yours, Ran From brian.e.carpenter@gmail.com Fri Feb 1 06:37: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 AC9D521E8030 for ; Fri, 1 Feb 2013 06:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.824 X-Spam-Level: X-Spam-Status: No, score=-99.824 tagged_above=-999 required=5 tests=[AWL=-0.903, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS8m7s7cahnh for ; Fri, 1 Feb 2013 06:37:44 -0800 (PST) Received: from mail-we0-x230.google.com (we-in-x0230.1e100.net [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id DDFB021E8034 for ; Fri, 1 Feb 2013 06:37:43 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so2944519wey.7 for ; Fri, 01 Feb 2013 06:37:43 -0800 (PST) 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=7xmXx5Iy7GJpWKuuBYXqLW0dTULHc5cov/3cNdeth/U=; b=yZ1NgJO/WqOXn2ww+09e1iMXYyBkZJsY+k5UqF1PyrSEkV1tR3oVy+eFF/lKGqNJWJ YJzQt+fTWrdkwxrhBX6b6VbOXdm8hRf7jMNvAIh/b1cqJZ0axOLmL5qsEYVVH252+g0i sMEcz+uvwYy1aNl1UNp/scDMVSJB90mNYS+ByUpP+tfTGas9lsGcLvRsRosXa7U8D49Q u8HzlTBpKyAZEOhuXONXbI9LKr7kNFuGDtn7I746GDRUlMOmp6h4itNO1FM5s9nekTH8 FUAX9kDwgmtEyH79V9blrWHwqnBOddonRsUPY66+wSC09CFNpNEM9+LFnttDfhVmER1w hldA== X-Received: by 10.180.107.130 with SMTP id hc2mr3246272wib.12.1359729463046; Fri, 01 Feb 2013 06:37:43 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-71.as13285.net. [2.102.219.71]) by mx.google.com with ESMTPS id df2sm3701882wib.0.2013.02.01.06.37.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 06:37:42 -0800 (PST) Message-ID: <510BD343.4050106@gmail.com> Date: Fri, 01 Feb 2013 14:37:55 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: 4rd IID range & IPv6 addressing architecture References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> In-Reply-To: <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 01 Feb 2013 14:37:44 -0000 Ran, I looked at the ILNP RFCs while we were preparing draft-carpenter-6man-ug= -00, and it seemed to me that ILNP doesn't in fact use IIDs, but rather a redefinition of the bottom 64 bits as a Node Identifier [RFC6741]. Doesn't that separate the use of the u/g bits for ILNP completely from their use in plain IPv6? Please have a look at the draft and suggest corrections if it seems wrong to you. Regards Brian On 01/02/2013 13:54, RJ Atkinson wrote: > On 31 Jan 2013, at 13:11 , R=C3=A9mi Despr=C3=A9s wrote: >> What ensures 4rd doesn't conflict with ILNP isn't at all >> that ILNP only uses u=3D0. =20 >> >> It is that, in ILNP, no u=3Dg=3D1 is used in *unicast* addresses >> (those whose IIDs are specified by RFC 4291).=20 >=20 > This is still inaccurate. =20 >=20 > I REALLY would be greatly obliged if you would not speculate=20 > about ILNP on IETF/IRTF mailing lists, primarily because=20 > any speculation is likely to be wrong -- and create needless > confusion amongst other folks on those lists.=20 >=20 > Some published ILNP papers talk about a form of multicast > addressing/routing that we believe is novel and are exploring. =20 > This combines a unicast routing prefix in the high-order=20 > 64-bits with an IEEE EUI-64 compliant (and RFC-4291=20 > compliant) multicast group ID (i.e., U=3DG=3D1) in the low-order=20 > 64-bits. Because of existing IETF standards-track work=20 > where U=3D0, for example CGAs or "privacy" addresses, the=20 > U=3D0 identifier space (i.e., U=3D0 and G=3D1) can NOT be used=20 > for multicast identifiers. >=20 > So the proposed 4rd reservation of all (or most) uses of=20 > addresses with the combination of (A) U=3DG=3D1 identifier space=20 > and (B) unicast routing prefix is a direct conflict with > published ILNP papers and active ILNP work. >=20 > Both ILNP and 4rd are Experimental, at least today. =20 > This is why I tabled the possibility of allocating=20 > a small portion of the U=3DG=3D1 space under RFC-3692 shared=20 > experimental use rules. That would permit multiple=20 > experiments to proceed, and is the usual IETF custom > for experimental work when a limited protocol-registry > resource is involved. >=20 > Yours, >=20 > Ran >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From rajiva@cisco.com Fri Feb 1 06:56: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 B8D1A11E80A2; Fri, 1 Feb 2013 06:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpCX0Pg-DC5z; Fri, 1 Feb 2013 06:56:05 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D298211E809B; Fri, 1 Feb 2013 06:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4000; q=dns/txt; s=iport; t=1359730565; x=1360940165; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i+KYrgczB1Qq65fETSugpl42RSJF5saG26vSiy8M/oQ=; b=WIIW23X4XtPAeDxCo76vlzWRbqXgt9J7gsu488yuZSa4FVIvM6U9YAE4 Xlca+xxsxQ87B7ul3K8kOnRUkyMoKFBO5QnM75m2DsXYFSiveN+Tiopep VJlWi5fA+OnmstDc6LrXJAgDZ5H3Jj64yoNzGURuR/RMMNHgnQTFaOo8N s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMzWC1GtJV2Z/2dsb2JhbABFvy0Wc4IeAQEBBAEBATc0BAcMBgEIEQMBAQEBChQJLgsUCQgCBA4FCIgJDMMLjQsbg0dhA5c0jzOCfIFvNQ X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171765169" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 01 Feb 2013 14:56:04 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r11Eu4bw013045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 14:56:04 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 08:56:04 -0600 From: "Rajiv Asati (rajiva)" To: Maglione Roberta Subject: Re: MAC Address Tracking via DHCP6 Thread-Topic: MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoA= Date: Fri, 1 Feb 2013 14:56:03 +0000 Message-ID: In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <12E46AE29605234C94FE4AA57EF6C33E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern 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, 01 Feb 2013 14:56:06 -0000 Hi Maglione,=20 Thanks for your review and a good question. draft-ietf-dhc-addr-registration introduces a new IPv6 Neighbor Discovery option and a new DHCPv6 option to propagate the address registration information from the hosts to the network. It requires the changes on the host. draft-asati-dhc-ipv6-autoconfig-address-tracking, on the other hand, requires no changes to IPv6 Neighbor Discovery and no changes to the hosts. It introduces changes in DHCPv6 specific to the last hop router and the DHCP server, thereby keeping the changes within the network (and DHCP server). Cheers, Rajiv -----Original Message----- From: Maglione Roberta Date: Friday, February 1, 2013 3:26 AM To: Rajiv Asati Cc: "ipv6@ietf.org" , Philipp Kern , Brian Hamacher Subject: RE: MAC Address Tracking via DHCP6 >Hello Rajiv, > is there any relation between your draft and >draft-ietf-dhc-addr-registration-00? > >Thanks >Regards, >Roberta > > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >Rajiv Asati (rajiva) >Sent: Thursday, January 31, 2013 6:27 PM >To: Philipp Kern; Brian Hamacher >Cc: ipv6@ietf.org >Subject: Re: MAC Address Tracking via DHCP6 > > >There is a better way out to track the IPv6 addresses used by the hosts >(via SLAAC or static) - > >http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-trackin >g > >Cheers, >Rajiv > >-----Original Message----- >From: Philipp Kern >Organization: The Debian Project (http://www.debian.org) >Date: Wednesday, December 12, 2012 10:37 AM >To: Brian Hamacher >Cc: "ipv6@ietf.org" >Subject: Re: MAC Address Tracking > >>On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: >>> I am looking for a good way to track my users MAC Addresses. I have a >>> test DHCPv6 server up and running ISC 4.1.1-P1. When I look through my >>> DHCP logs as well as my leases file I do not see the client MAC Address >>> anywhere. Do I need to enable an option to allow this to be logged? I >>> am looking to figure out how I can track what user had what IP Address >>> at any given time. The MAC Address is traditionally how I have done >>> this. >> >>One way would be to poll your routers' ND tables (like fetching ARP >>tables >>in IPv4). As soon as you use relaying you most certainly won't get a >>useable MAC address from your client, even though it might be possible in >>the same network segment. (The MAC address is not copied from the wire >>into the new relayed packet sent by the router to your server.) >> >>DHCPv6 uses the so-called client identifier extensively and not the MAC >>address anymore. So you cannot do any static assignment based on MAC >>addresses. >> >>Kind regards >>Philipp Kern > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione derivante >dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne immediata comunicazione al mittente e di provvedere alla >sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may contain >privileged information intended for the addressee(s) only. Dissemination, >copying, printing or use by anybody else is unauthorised. If you are not >the intended recipient, please delete this message and any attachments >and advise the sender by return e-mail, Thanks. > From rja.lists@gmail.com Fri Feb 1 07:26: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 E436021E803D for ; Fri, 1 Feb 2013 07:26:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHA4Gt6VK8p8 for ; Fri, 1 Feb 2013 07:26:42 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id F2D0321E8040 for ; Fri, 1 Feb 2013 07:26:41 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id z24so1788335qcq.5 for ; Fri, 01 Feb 2013 07:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=o9MxDylHiRPW8M1bznaBUFiGdQmYgeplGUFYJg/CnX0=; b=bQqefwEIc16ydOO/rIqjHr8poQIqIU9z33T+rZWEEzzDNPLb1SDoO2tR4BtP5lUqXs qTsjs+N6OjjcvHiSsxoabr3/ye73dGH10PPk1HYw7PVdM5CqKgaV/sfXx2zCCGzrnB0m ITlF+WwhZZVA4po4dZh9T/dAL0YhgpH4owx15UI3deqNbmr9rk9/IH6boMXqXhZc/Jqc xVYlmg2To6TgXfqDTiegw5sXdBLhydZj9yPCkHR/qqQXqPmNxMlRDaT+qXD7cd1eMDSg 4M/ZOrFEEKokf0xgAL8acDTDIQ7ZHGg6jEA50xOgwi9iHQhZkFlHryl7AgSu7B+7ViyB li5w== X-Received: by 10.224.222.145 with SMTP id ig17mr6995032qab.5.1359732401383; Fri, 01 Feb 2013 07:26:41 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id hr1sm6940847qeb.3.2013.02.01.07.26.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 07:26:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: 4rd IID range & IPv6 addressing architecture From: RJ Atkinson In-Reply-To: <510BD343.4050106@gmail.com> Date: Fri, 1 Feb 2013 10:26:39 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0CC7DF2E-A9C6-49C8-9205-8AEB928FB4E3@gmail.com> References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> <510BD343.4050106@gmail.com> To: ipv6@ietf.org 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: Fri, 01 Feb 2013 15:26:43 -0000 On 01 Feb 2013, at 09:37 , Brian E Carpenter wrote: > I looked at the ILNP RFCs while we were preparing > draft-carpenter-6man-ug-00, and it seemed to me that > ILNP doesn't in fact use IIDs, but rather a redefinition > of the bottom 64 bits as a Node Identifier [RFC6741]. ILNPv6 changes the *semantics* of the lower 64-bits *from the view of the transport-layer and above*, but is quite careful to keep the syntax unchanged. Keeping the syntax unchanged is crucial to ensuring that ordinary IPv6 routers can/will forward ILNPv6 packets -- without even needing to know that they are ILNPv6 packets. In turn, the ability of ILNPv6 to incrementally-deploy within an already extant IPv6 deployment is crucial. Flag-day transitions are broadly unacceptable for very good operational reasons, so ILNPv6 must remain backwards-compatible with existing IPv6. A great deal of time was spent engineering both ILNPv4 and ILNPv6 to ensure that each would be backwards- compatible with IPv4 and IPv6 infrastructure (respectively). > Doesn't that separate the use of the u/g bits > for ILNP completely from their use in plain IPv6? No, as explained above. > Please have a look at the draft and suggest corrections > if it seems wrong to you. I haven't done yet, due to lack of time, but will put reviewing that onto my to-do list. Thanks, Ran From despres.remi@laposte.net Fri Feb 1 07:30: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 500A321E803D for ; Fri, 1 Feb 2013 07:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE14FOQNZj1q for ; Fri, 1 Feb 2013 07:30:24 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5E80621E8030 for ; Fri, 1 Feb 2013 07:30:24 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 1552770000F4; Fri, 1 Feb 2013 16:30:23 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id E1B2370000E9; Fri, 1 Feb 2013 16:30:22 +0100 (CET) X-SFR-UUID: 20130201153022924.E1B2370000E9@msfrf2208.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 4rd IID range & IPv6 addressing architecture From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> Date: Fri, 1 Feb 2013 16:30:23 +0100 Message-Id: References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 01 Feb 2013 15:30:25 -0000 Ran, Going directly to your conclusion, it appears we have a clear common = interest! Each of the designs we are interested in depends, to be complete, on = reservation of a subset of the IID space left unused by RFC4291 (that = having u=3Dg=3D1). Since you talk about "a small portion" of this space for ILNP, and since = 4rd only needs only 1/2^14 of this space, I rather see convergence than = conflict. Hoping we can agree on it, Regards, RD A few secondary comments inline. 2013-02-01 14:54, RJ Atkinson : >=20 > On 31 Jan 2013, at 13:11 , R=E9mi Despr=E9s wrote: >> What ensures 4rd doesn't conflict with ILNP isn't at all >> that ILNP only uses u=3D0. =20 >>=20 >> It is that, in ILNP, no u=3Dg=3D1 is used in *unicast* addresses >> (those whose IIDs are specified by RFC 4291).=20 >=20 > This is still inaccurate. =20 >=20 > I REALLY would be greatly obliged if you would not speculate=20 > about ILNP on IETF/IRTF mailing lists, primarily because=20 > any speculation is likely to be wrong -- and create needless > confusion amongst other folks on those lists. Contributing on IETF mailing lists, including on what concerns existing = ILNP RFCs, is a right anyone has AFAIK. =20 > Some published ILNP papers talk about a form of multicast > addressing/routing that we believe is novel and are exploring. =20 > This combines a unicast routing prefix in the high-order=20 > 64-bits with an IEEE EUI-64 compliant (and RFC-4291=20 > compliant) multicast group ID (i.e., U=3DG=3D1) in the low-order=20 > 64-bits. > Because of existing IETF standards-track work=20 > where U=3D0, for example CGAs or "privacy" addresses, the=20 > U=3D0 identifier space (i.e., U=3D0 and G=3D1) can NOT be used=20 > for multicast identifiers. This is precisely the point I have actively contributed to make in 6man! > So the proposed 4rd reservation of all (or most) uses of=20 > addresses with the combination of (A) U=3DG=3D1 identifier space=20 > and (B) unicast routing prefix is a direct conflict with > published ILNP papers and active ILNP work. The currently proposed IID prefix is 0x0300. It only uses 1/2^14 of the = u=3Dg=3D1 space of RFC-4291. This can't be characterized as " reservation of all (or most) uses" of = this space. (Your turn to misrepresent, by mistake, the situation. Your = apologies after mine will be welcome.) > Both ILNP and 4rd are Experimental, at least today. =20 > This is why I tabled the possibility of allocating=20 > a small portion of the U=3DG=3D1 space under RFC-3692 shared=20 > experimental use rules. That would permit multiple=20 > experiments to proceed, and is the usual IETF custom > for experimental work when a limited protocol-registry > resource is involved. As said at the top of this mail, this shows we have converging = interests.=20 From brian.e.carpenter@gmail.com Fri Feb 1 07:34: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 1FFE321E8040 for ; Fri, 1 Feb 2013 07:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.791 X-Spam-Level: X-Spam-Status: No, score=-99.791 tagged_above=-999 required=5 tests=[AWL=-0.870, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mismRjHdiuc8 for ; Fri, 1 Feb 2013 07:34:13 -0800 (PST) Received: from mail-we0-x233.google.com (we-in-x0233.1e100.net [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 522BD21E8030 for ; Fri, 1 Feb 2013 07:34:13 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id x43so3114301wey.10 for ; Fri, 01 Feb 2013 07:34:12 -0800 (PST) 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=9ongyD4/751dj6eJuBsA/Gk9YI+hltk2RD70g9MWL9A=; b=X28dWf6ZvozyzMn4iriEJjEKKDd3vnjUHQBFAKi+UjCWj3QpkTCkD9wrOHoz+LkEnL Q3Iu7juZ6xSBoYpwabfMVPKXzEvD2NFmjSJvxzbd8Nbn8WzVL+53uYiu9E1sFkEDQ9py Jv4wBxi91YzMPROBVThX+eCNyHH+aIa3qiVHf/So5x+2VJkfT2i3x09CuMywUWjYANhh MVIKyLp2nU1F1rs08xo2yz/XQccz0qrRW1aRd9FKS3SQdCy9ME9hK6I8IpLEEl3h7e3i BDUfKu+xtCRrQtxF970X5G246gQgMkp3SnESDlQS0DIofXhUO09ABC/LrDfmjUXY/zy8 Qz7w== X-Received: by 10.180.82.41 with SMTP id f9mr3647406wiy.25.1359732852505; Fri, 01 Feb 2013 07:34:12 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-71.as13285.net. [2.102.219.71]) by mx.google.com with ESMTPS id hb9sm3998444wib.3.2013.02.01.07.34.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 07:34:11 -0800 (PST) Message-ID: <510BE081.4010306@gmail.com> Date: Fri, 01 Feb 2013 15:34:25 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: 4rd IID range & IPv6 addressing architecture References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> <510BD343.4050106@gmail.com> <0CC7DF2E-A9C6-49C8-9205-8AEB928FB4E3@gmail.com> In-Reply-To: <0CC7DF2E-A9C6-49C8-9205-8AEB928FB4E3@gmail.com> 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, 01 Feb 2013 15:34:14 -0000 On 01/02/2013 15:26, RJ Atkinson wrote: > On 01 Feb 2013, at 09:37 , Brian E Carpenter wrote: >> I looked at the ILNP RFCs while we were preparing >> draft-carpenter-6man-ug-00, and it seemed to me that >> ILNP doesn't in fact use IIDs, but rather a redefinition >> of the bottom 64 bits as a Node Identifier [RFC6741]. > > ILNPv6 changes the *semantics* of the lower 64-bits > *from the view of the transport-layer and above*, > but is quite careful to keep the syntax unchanged. Right, that was how I understood it. I'm hoping that what the draft proposes is compatible with ILNP, so I await your comments. Brian > > Keeping the syntax unchanged is crucial to ensuring > that ordinary IPv6 routers can/will forward ILNPv6 > packets -- without even needing to know that they are > ILNPv6 packets. > > In turn, the ability of ILNPv6 to incrementally-deploy > within an already extant IPv6 deployment is crucial. > Flag-day transitions are broadly unacceptable for > very good operational reasons, so ILNPv6 must remain > backwards-compatible with existing IPv6. > > A great deal of time was spent engineering both ILNPv4 > and ILNPv6 to ensure that each would be backwards- > compatible with IPv4 and IPv6 infrastructure (respectively). > >> Doesn't that separate the use of the u/g bits >> for ILNP completely from their use in plain IPv6? > > No, as explained above. > >> Please have a look at the draft and suggest corrections >> if it seems wrong to you. > > I haven't done yet, due to lack of time, > but will put reviewing that onto my to-do list. > > Thanks, > > Ran > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From tpoder@cis.vutbr.cz Fri Feb 1 07:38: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 6801521E804E for ; Fri, 1 Feb 2013 07:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDiTg+SqS+AN for ; Fri, 1 Feb 2013 07:38:39 -0800 (PST) Received: from ferret.cis.vutbr.cz (ferret6.cis.vutbr.cz [IPv6:2001:67c:1220:e100::93e5:391]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACBB21E8030 for ; Fri, 1 Feb 2013 07:38:37 -0800 (PST) Received: from flamingo.cis.vutbr.cz (flamingo.cis.vutbr.cz [147.229.3.147]) by ferret.cis.vutbr.cz (8.14.4/8.14.4/VUT Brno) with ESMTP id r11FcTpl035909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Feb 2013 16:38:31 +0100 (CET) (envelope-from tpoder@cis.vutbr.cz) Received: from vuts-mac-pro.local ([10.3.0.96]) (authenticated bits=0) by flamingo.cis.vutbr.cz (8.13.8/8.14.3/VUT v Brne) with ESMTP id r11FcR0O056090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 16:38:27 +0100 (CET) (envelope-from tpoder@cis.vutbr.cz) Message-ID: <510BE174.4000108@cis.vutbr.cz> Date: Fri, 01 Feb 2013 16:38:28 +0100 From: Tomas Podermanski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian Hamacher Subject: Re: MAC Address Tracking References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/alternative; boundary="------------050303020506060201080005" X-Scanned-By: MIMEDefang 2.67 on 147.229.3.145 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, 01 Feb 2013 15:38:40 -0000 This is a multi-part message in MIME format. --------------050303020506060201080005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Brian, some work that might help with that is available on http://6lab.cz/article/user-identification-in-ipv6-network/ and http://6lab.cz/article/design-of-data-retention-system-in-ipv6-network/ . Tomas On 12/11/12 11:04 PM, Brian Hamacher wrote: > > I am looking for a good way to track my users MAC Addresses. I have a > test DHCPv6 server up and running ISC 4.1.1-P1. When I look through > my DHCP logs as well as my leases file I do not see the client MAC > Address anywhere. Do I need to enable an option to allow this to be > logged? I am looking to figure out how I can track what user had what > IP Address at any given time. The MAC Address is traditionally how I > have done this. > > > > Any thoughts would be appreciated. > > > > Thank You > > > > Brian > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --------------050303020506060201080005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Brian,

    some work that might help with that is available on http://6lab.cz/article/user-identification-in-ipv6-network/ and http://6lab.cz/article/design-of-data-retention-system-in-ipv6-network/ .


Tomas



On 12/11/12 11:04 PM, Brian Hamacher wrote:

I am looking for a good way to track my users MAC Addresses.  I have a test DHCPv6 server up and running ISC 4.1.1-P1.  When I look through my DHCP logs as well as my leases file I do not see the client MAC Address anywhere.  Do I need to enable an option to allow this to be logged?  I am looking to figure out how I can track what user had what IP Address at any given time.  The MAC Address is traditionally how I have done this.

 

Any thoughts would be appreciated.

 

Thank You

 

Brian

 



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

--------------050303020506060201080005-- From cra@WPI.EDU Fri Feb 1 07:42: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 68D9121F8E09; Fri, 1 Feb 2013 07:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhUe3Bt8Bkop; Fri, 1 Feb 2013 07:42:43 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7090B21F8E08; Fri, 1 Feb 2013 07:42:43 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.6/8.14.6) with ESMTP id r11FgTZq004766; Fri, 1 Feb 2013 10:42:29 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU r11FgTZq004766 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1359733349; bh=GTRYhvZHV3IL9LYmgM4wnKz+fwL93lIidpTiy7ANdeY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=IBFLGH3UyY/cu9G1T2XgE3NBGW32IztDwaU4xr42XdjPkJcYDIjRlibM1WF/LyWU9 h1bk+IgoIs8RmhexQ56VTsV1u4fOtW3/59mGJ5WSEgs/7PBQQAgMiBjTYM6R525ZV0 1+P6aiYoMgeBX4eJLXdo8Xy0xjuDUy26eeiopnRQ= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.6/8.14.6) with ESMTP id r11FgTFq004759; Fri, 1 Feb 2013 10:42:29 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id r11FgRYq013019; Fri, 1 Feb 2013 10:42:28 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id r11FgRj7016358; Fri, 1 Feb 2013 10:42:27 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id r11FgQ4F016357; Fri, 1 Feb 2013 10:42:26 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Fri, 1 Feb 2013 10:42:26 -0500 From: Chuck Anderson To: "Rajiv Asati (rajiva)" Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 Message-ID: <20130201154226.GJ22295@angus.ind.WPI.EDU> Mail-Followup-To: "Rajiv Asati (rajiva)" , Maglione Roberta , "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern References: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Mailman-Approved-At: Fri, 01 Feb 2013 07:44:26 -0800 Cc: "dhcwg@ietf.org" , Brian Hamacher , Philipp Kern , "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, 01 Feb 2013 15:42:44 -0000 There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 which handles the case for DHCPv6 clients. That also requires no changes to clients--only the DHCPv6 Relay Agent. On Fri, Feb 01, 2013 at 02:56:03PM +0000, Rajiv Asati (rajiva) wrote: > Hi Maglione, > > Thanks for your review and a good question. > > draft-ietf-dhc-addr-registration introduces a new IPv6 Neighbor Discovery > option and a > new DHCPv6 option to propagate the address registration information > from the hosts to the network. It requires the changes on the host. > > > > draft-asati-dhc-ipv6-autoconfig-address-tracking, on the other hand, > requires no changes to IPv6 Neighbor Discovery and no changes to the > hosts. It introduces changes in DHCPv6 specific to the last hop router and > the DHCP server, thereby keeping the changes within the network (and DHCP > server). > > > Cheers, > Rajiv > > -----Original Message----- > From: Maglione Roberta > Date: Friday, February 1, 2013 3:26 AM > To: Rajiv Asati > Cc: "ipv6@ietf.org" , Philipp Kern , > Brian Hamacher > Subject: RE: MAC Address Tracking via DHCP6 > > >Hello Rajiv, > > is there any relation between your draft and > >draft-ietf-dhc-addr-registration-00? > > > >Thanks > >Regards, > >Roberta > > > > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >Rajiv Asati (rajiva) > >Sent: Thursday, January 31, 2013 6:27 PM > >To: Philipp Kern; Brian Hamacher > >Cc: ipv6@ietf.org > >Subject: Re: MAC Address Tracking via DHCP6 > > > > > >There is a better way out to track the IPv6 addresses used by the hosts > >(via SLAAC or static) - > > > >http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-trackin > >g > > > >Cheers, > >Rajiv > > > >-----Original Message----- > >From: Philipp Kern > >Organization: The Debian Project (http://www.debian.org) > >Date: Wednesday, December 12, 2012 10:37 AM > >To: Brian Hamacher > >Cc: "ipv6@ietf.org" > >Subject: Re: MAC Address Tracking > > > >>On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: > >>> I am looking for a good way to track my users MAC Addresses. I have a > >>> test DHCPv6 server up and running ISC 4.1.1-P1. When I look through my > >>> DHCP logs as well as my leases file I do not see the client MAC Address > >>> anywhere. Do I need to enable an option to allow this to be logged? I > >>> am looking to figure out how I can track what user had what IP Address > >>> at any given time. The MAC Address is traditionally how I have done > >>> this. > >> > >>One way would be to poll your routers' ND tables (like fetching ARP > >>tables > >>in IPv4). As soon as you use relaying you most certainly won't get a > >>useable MAC address from your client, even though it might be possible in > >>the same network segment. (The MAC address is not copied from the wire > >>into the new relayed packet sent by the router to your server.) > >> > >>DHCPv6 uses the so-called client identifier extensively and not the MAC > >>address anymore. So you cannot do any static assignment based on MAC > >>addresses. > >> > >>Kind regards > >>Philipp Kern From rajiva@cisco.com Fri Feb 1 07:47: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 BFB7511E8097; Fri, 1 Feb 2013 07:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.991 X-Spam-Level: X-Spam-Status: No, score=-8.991 tagged_above=-999 required=5 tests=[AWL=1.608, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSTdqPs8qdfK; Fri, 1 Feb 2013 07:47:53 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F20C021E8039; Fri, 1 Feb 2013 07:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4138; q=dns/txt; s=iport; t=1359733673; x=1360943273; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EzLj6QlsJMMLLkKvRXv8VuknxZopegpCA4AbyBF41gk=; b=cokzmuY+stk0iCW/AsNkm3ColW6bqoJ72R391wOBo3oFm8ews9O4CKw0 d242ZAZhPEfZGTQk2h6YnMV4JLgbwq67XIzCyjEsCqmusyPX+wmlff08t /h2eZQzmGcR+9dtBAjeVGfmYprJq9eHidsTLdkEg1peaYbGjVq7pbqE9S 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIriC1GtJXG8/2dsb2JhbABFDr8fFnOCHgEBAQQ6OAcMBgEIDgMDAQEBAQoUCTkUCQgCBA4FCIgJDMMZjQuDYmEDlzSPM4I+PoIk X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="168798546" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 01 Feb 2013 15:47:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r11FlnYI025644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 15:47:49 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 09:47:49 -0600 From: "Rajiv Asati (rajiva)" To: Chuck Anderson Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 Thread-Topic: [dhcwg] MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoCAAGDQAP//raMA Date: Fri, 1 Feb 2013 15:47:48 +0000 Message-ID: In-Reply-To: <20130201154226.GJ22295@angus.ind.WPI.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <87FC71402168074E86FBB05FBB6F5B59@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Brian Hamacher , Philipp Kern , "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, 01 Feb 2013 15:47:53 -0000 Hi Chuck, Yah, but draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt is for DHCPv6 clients, as you rightly pointed out, and not for SLAAC/static hosts. Cheers, Rajiv -----Original Message----- From: Chuck Anderson Date: Friday, February 1, 2013 10:42 AM To: Rajiv Asati Cc: Maglione Roberta , "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 >There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 >which handles the case for DHCPv6 clients. That also requires no >changes to clients--only the DHCPv6 Relay Agent. > >On Fri, Feb 01, 2013 at 02:56:03PM +0000, Rajiv Asati (rajiva) wrote: >> Hi Maglione,=20 >>=20 >> Thanks for your review and a good question. >>=20 >> draft-ietf-dhc-addr-registration introduces a new IPv6 Neighbor >>Discovery >> option and a >> new DHCPv6 option to propagate the address registration information >> from the hosts to the network. It requires the changes on the host. >>=20 >>=20 >>=20 >> draft-asati-dhc-ipv6-autoconfig-address-tracking, on the other hand, >> requires no changes to IPv6 Neighbor Discovery and no changes to the >> hosts. It introduces changes in DHCPv6 specific to the last hop router >>and >> the DHCP server, thereby keeping the changes within the network (and >>DHCP >> server). >>=20 >>=20 >> Cheers, >> Rajiv >>=20 >> -----Original Message----- >> From: Maglione Roberta >> Date: Friday, February 1, 2013 3:26 AM >> To: Rajiv Asati >> Cc: "ipv6@ietf.org" , Philipp Kern , >> Brian Hamacher >> Subject: RE: MAC Address Tracking via DHCP6 >>=20 >> >Hello Rajiv, >> > is there any relation between your draft and >> >draft-ietf-dhc-addr-registration-00? >> > >> >Thanks >> >Regards, >> >Roberta >> > >> > >> >-----Original Message----- >> >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> >Rajiv Asati (rajiva) >> >Sent: Thursday, January 31, 2013 6:27 PM >> >To: Philipp Kern; Brian Hamacher >> >Cc: ipv6@ietf.org >> >Subject: Re: MAC Address Tracking via DHCP6 >> > >> > >> >There is a better way out to track the IPv6 addresses used by the hosts >> >(via SLAAC or static) - >> > >>=20 >>>http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-track >>>in >> >g >> > >> >Cheers, >> >Rajiv >> > >> >-----Original Message----- >> >From: Philipp Kern >> >Organization: The Debian Project (http://www.debian.org) >> >Date: Wednesday, December 12, 2012 10:37 AM >> >To: Brian Hamacher >> >Cc: "ipv6@ietf.org" >> >Subject: Re: MAC Address Tracking >> > >> >>On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: >> >>> I am looking for a good way to track my users MAC Addresses. I >>have a >> >>> test DHCPv6 server up and running ISC 4.1.1-P1. When I look >>through my >> >>> DHCP logs as well as my leases file I do not see the client MAC >>Address >> >>> anywhere. Do I need to enable an option to allow this to be >>logged? I >> >>> am looking to figure out how I can track what user had what IP >>Address >> >>> at any given time. The MAC Address is traditionally how I have done >> >>> this. >> >> >> >>One way would be to poll your routers' ND tables (like fetching ARP >> >>tables >> >>in IPv4). As soon as you use relaying you most certainly won't get a >> >>useable MAC address from your client, even though it might be >>possible in >> >>the same network segment. (The MAC address is not copied from the wire >> >>into the new relayed packet sent by the router to your server.) >> >> >> >>DHCPv6 uses the so-called client identifier extensively and not the >>MAC >> >>address anymore. So you cannot do any static assignment based on MAC >> >>addresses. >> >> >> >>Kind regards >> >>Philipp Kern From Ted.Lemon@nominum.com Fri Feb 1 07:49: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 24CD71F0D05; Fri, 1 Feb 2013 07:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPz+jw41-kpM; Fri, 1 Feb 2013 07:49:08 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id CC7801F0CF8; Fri, 1 Feb 2013 07:49:03 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUQvj74WmNcpxHh+Vi/qCBUvU7DP0yCQf@postini.com; Fri, 01 Feb 2013 07:49:03 PST 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 6D715128008; Fri, 1 Feb 2013 07:49:03 -0800 (PST) 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 646CD190043; Fri, 1 Feb 2013 07:49:03 -0800 (PST) (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; Fri, 1 Feb 2013 07:49:03 -0800 From: Ted Lemon To: Chuck Anderson Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 Thread-Topic: [dhcwg] MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoCAAIJYAIAAAdgA Date: Fri, 1 Feb 2013 15:49:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747479218@mbx-01.win.nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> <20130201154226.GJ22295@angus.ind.WPI.EDU> In-Reply-To: <20130201154226.GJ22295@angus.ind.WPI.EDU> 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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern 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, 01 Feb 2013 15:49:15 -0000 On Feb 1, 2013, at 10:42 AM, Chuck Anderson wrote: > There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 > which handles the case for DHCPv6 clients. That also requires no > changes to clients--only the DHCPv6 Relay Agent. This document doesn't apply to SLAAC or CGA addresses, though=97just statef= ul addresses acquired through DHCPv6. Admittedly, we could also snoop DHC= PINFORM traffic, but there's no guarantee that all devices on the network w= ill do a DHCPINFORM, even if the O bit is set. From rajiva@cisco.com Fri Feb 1 07:57: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 E533321F8D29; Fri, 1 Feb 2013 07:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2KEtOYRzvnh; Fri, 1 Feb 2013 07:57:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB321F8461; Fri, 1 Feb 2013 07:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=946; q=dns/txt; s=iport; t=1359734260; x=1360943860; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=W8VyQmLR2o5IGgC+IXxgS58wZ0KrP3o85PUeaBJ+kCI=; b=go0B9QILDm52YNh5wQaQTAOOO0Mba1UdSQ2dp2R91eQEAQ2W2IIx+8m+ 3CagF0ycXxBJJUnri6F0G4l7mOQ6Rg/W6q0WNM5VnwdAtQvN6v4fnXUFj mrqP0j5ywAs2imX752LQIo25xsi0QEU+Jygv16OjVU1IXcL8wfw0pJENU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFALfkC1GtJV2b/2dsb2JhbABFDoVzuSsWc4IeAQEBBHkMBgEIEQMBAgEKVh0IAgQBDQUIiAnDGpBtYQOmZ4I+PoIk X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="168804226" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 01 Feb 2013 15:57:39 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r11FvdSr003141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 15:57:39 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 09:57:39 -0600 From: "Rajiv Asati (rajiva)" To: Ted Lemon , Chuck Anderson Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 Thread-Topic: [dhcwg] MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoCAAGDQAIAAAdqA//+ujIA= Date: Fri, 1 Feb 2013 15:57:38 +0000 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747479218@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern 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, 01 Feb 2013 15:57:41 -0000 I agree, Ted.=20 -----Original Message----- From: Ted Lemon Date: Friday, February 1, 2013 10:49 AM To: Chuck Anderson Cc: Rajiv Asati , "dhcwg@ietf.org" , Brian Hamacher , Philipp Kern , "ipv6@ietf.org" Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 >On Feb 1, 2013, at 10:42 AM, Chuck Anderson wrote: >> There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 >> which handles the case for DHCPv6 clients. That also requires no >> changes to clients--only the DHCPv6 Relay Agent. > >This document doesn't apply to SLAAC or CGA addresses, though=8Bjust >stateful addresses acquired through DHCPv6. Admittedly, we could also >snoop DHCPINFORM traffic, but there's no guarantee that all devices on >the network will do a DHCPINFORM, even if the O bit is set. > From tjc@ecs.soton.ac.uk Fri Feb 1 08:51: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 510C621E808F; Fri, 1 Feb 2013 08:51:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMwZu2fhc8xx; Fri, 1 Feb 2013 08:51:09 -0800 (PST) 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 5EF9E21E8049; Fri, 1 Feb 2013 08:51:08 -0800 (PST) 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 r11Gp3ac021892; Fri, 1 Feb 2013 16:51:03 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r11Gp3ac021892 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1359737464; bh=kD9BO7Do7eydvlfYD04jx1hpBfo=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=s0ucs6hgnx4nLthR6+mtUclT9uq8cumftJazkHK4FEAP2370n7PW/HOAzwjpSotDs Mvv92YEp4bF+vFRYBlGdxU62wWXR9+TjmWjiW443X6p6QMVedGkikClBEHdcjBtDmb mvFbSAkB/LSqovTJfP1KrReK3y2YU+ll/94Qexs0= 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 p10Gp30430611135OE ret-id none; Fri, 01 Feb 2013 16:51:03 +0000 Received: from ip-162-143.eduroam.soton.ac.uk (ip-162-143.eduroam.soton.ac.uk [152.78.162.143]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r11Gox9L032635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 16:51:01 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 From: Tim Chown In-Reply-To: Date: Fri, 1 Feb 2013 16:50:52 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "ipv6@ietf.org List" , dhcwg@ietf.org X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p10Gp3043061113500; tid=p10Gp30430611135OE; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r11Gp3ac021892 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: Fri, 01 Feb 2013 16:51:10 -0000 On 1 Feb 2013, at 15:47, Rajiv Asati (rajiva) wrote: >=20 > Yah, but draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt is for = DHCPv6 > clients, as you rightly pointed out, and not for SLAAC/static hosts. You can also of course just use tools that harvest data from = network/switch/router devices, and build the info from that. There's a = number of open source options in that space, from bespoke tools for = address tracking through to full-on monitoring platforms. Then you don't = need changes in hosts or routers. Regardless, I hope draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt = progresses. Tim= From fgont@si6networks.com Fri Feb 1 12: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 4CC9D21E804A for ; Fri, 1 Feb 2013 12:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma6OuyVFQCS8 for ; Fri, 1 Feb 2013 12:13:56 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 71AE321E8044 for ; Fri, 1 Feb 2013 12:13:56 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U1MzJ-0006Dz-Rm; Fri, 01 Feb 2013 21:13:30 +0100 Message-ID: <510C21D9.2020506@si6networks.com> Date: Fri, 01 Feb 2013 17:13:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> In-Reply-To: <510B790D.8010301@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: Fri, 01 Feb 2013 20:13:57 -0000 Hi, Brian & Sheng, On 02/01/2013 05:13 AM, Brian E Carpenter wrote: > > We've put this together to address the general question of the > u/g bits in Interface IDs. Discussion is requested. Some comments: Section 1: > The specification assumes that that the normal case is to transform > an Ethernet-style address into an IID, preserving the semantics of > two bits in particular: > > o The "u" bit in an IEEE address is set to 0 to indicate universal > scope (implying uniqueness) or to 1 to indicate local scope > (without implying uniqueness). In an IID this bit is inverted, > i.e., 1 for universal scope and 0 for local scope. According to > [RFC5342], the reason for this was "to make it easier for network > operators to type in local-scope identifiers". > o The "g" bit in an IEEE address is set to 1 to indicate group > addressing (link-layer multicast). This value is supposed to be > preserved in an IID. The second bullet is not tru: e.g. temp addresses do not do anything to preserve the "g" bit (the "u" bit *is* forced to 0, though); Section 2: > > NOTE IN DRAFT: Are there other examples we should include? Are we > sure that no IID format defines semantics for u/g? Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the probability of collisions if your IIDs are derived from global identifiers (more on this below). Section 2, page 4: > > "The use of the universal/local bit in the Modified EUI-64 format > identifier is to allow development of future technology that can take > advantage of interface identifiers with universal scope." This seems to assume that the namespace (Identifiers) of two different technologies does not overlap. Such assumption sounds like dubious to me... but I might be missing something. i.e. some non-IEEE technology is expected to obey the u/g bits? Section 3: > It should be noted that IIDs known or guessed to have been created > according to RFC 4941 could be transformed back into MAC addresses, > for example during fault diagnosis. For that reason, keeping the "u" > and "g" bits in the IID has operational value. Therefore, the EUI-64 > to IPv6 IID transformation defined in RFC 4941 MUST be used for all > cases where an IID is derived from a MAC address. How can you tell whether an IID was really derived from a MAC address, or you just had pretty bad luck with your IID randomization -- such tha it *looks* like derived form a mac address? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Fri Feb 1 12:57: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 1F2FE21E8050 for ; Fri, 1 Feb 2013 12:57:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AO4Cn5VmgxX for ; Fri, 1 Feb 2013 12:57:35 -0800 (PST) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACD121E804E for ; Fri, 1 Feb 2013 12:57:35 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id 2so1713296qeb.1 for ; Fri, 01 Feb 2013 12:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=ijZ+jbk6Q5jXaoni0tZ357TZ/27azXl/gHTjtvVeofw=; b=dY3m3IgSfuxbOFJ+mnGcCmEjcvf1bvC9HONViOuO1hOGnxcpWOmhFX0X6CJpZ/S5JA 16RhQWDGJ44EsUeSQC1BhGVcNw7rhFalnrPl+DCu9tbKzx+8+I/15igOpcR3NWa2FrmT yG3NG1cQR8K1nipU8v0oUzYoe/V/G9sRQ7kBBD5Rl2G6+IR78gr2JU0D5RaX3nX4JZh/ aeBaKlMfLrrxcO3HKZgWL7buAyKMPAWoOCGsJNutnwLfdFNz9OM/IIFVawiI5vLIiP9d SWjVAVa8k2vp7QgcdpxsI4oy/5tbueRqEVw2WCd8S2+NXJEcOiJJNqwK5Nvul58qTSXw 5IOw== X-Received: by 10.49.128.37 with SMTP id nl5mr16754192qeb.59.1359752255048; Fri, 01 Feb 2013 12:57:35 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id z5sm7697014qer.8.2013.02.01.12.57.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 12:57:33 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: 4rd IID range & IPv6 addressing architecture From: RJ Atkinson In-Reply-To: Date: Fri, 1 Feb 2013 15:57:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <75FFC268-0E6C-41BE-B703-C53BB52E1131@gmail.com> References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> To: ipv6@ietf.org 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: Fri, 01 Feb 2013 20:57:36 -0000 On 01 Feb 2013, at 10:30 , R=E9mi Despr=E9s wrote: > Each of the designs we are interested in depends, to be complete, > on reservation of a subset of the IID space left unused by RFC4291 > (that having u=3Dg=3D1). Both are *experiments*. Neither is a standard. With respect to Softwire, they decided to standardise something other than 4rd. Had they decided to=20 standardise 4rd, my views would be different,=20 but that wasn't the decision actually made in Softwire. For *experiments*, a small shared use experimental=20 allocation *under RFC-3692 rules* should be both=20 sufficient and an appropriate approach -- and also can be used with any other experiments that might arise=20 in future. I haven't asked for any ILNP-specific allocation, in part because my reading of the standards-track RFCs,=20 for example in RFC-4291, is that the (U=3D1 and G=3D1) space=20 is ALREADY designated for Multicast Identifiers. Yours, Ran From markzzzsmith@yahoo.com.au Fri Feb 1 14:19: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 8E5BE21E804E for ; Fri, 1 Feb 2013 14:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_05=-1.11, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oooKBd4KhpvD for ; Fri, 1 Feb 2013 14:19:05 -0800 (PST) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) by ietfa.amsl.com (Postfix) with SMTP id 3BF8221E8049 for ; Fri, 1 Feb 2013 14:19:05 -0800 (PST) Received: from [98.139.215.142] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2013 22:19:04 -0000 Received: from [98.139.212.212] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2013 22:19:04 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 01 Feb 2013 22:19:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 735073.38629.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 28630 invoked by uid 60001); 1 Feb 2013 22:19:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359757144; bh=tj0u5JWuKkptzinJdFsvY8nVJetQwxphmLo/+VhRkoA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1KR/bTFSzoN2AYFhGEyxJXZv9W0XIkvD/OyLLjEGmuXZ/hG4E2b8J7IH2E+q7tZxTATNoEM8upMt3rzmOr5yVg6Vi0CxSzg/Jz1aPj5E2NWFMeEUUmpfeC0e5eyhkrfhzkcfyIcaKcD+wMA14ssouAKcrZ3PQcU3kSUwfADLzWs= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qfsLKkpVmk1D6x3HR57r+R4ohzRidFt7Ri7PkUGAy80Os/TozuYwIASs3KMYx57iw7qoZO/NBonzCcdAngzmiGxsiIJnu3jqMRWfCa8HPTnbcNQh4r2nvnOOa0mrxtMCXAZwMA58KLLNK9DRcIqTcjlqAQ0IxXplvsyBas7oPg0=; X-YMail-OSG: oH65vBUVM1nM1upPryniFDmIotPOhBw7s628EW9JRfvV4Bc ChAqOlYeMn3fNdvs4dps1C3MgS87AzuSPjy5fz2EAZU3ntay9YtiHt6qp1lB whmgF08H1DOIe1LNrb16psW7XjCcIZ4hYznSQCyjL7HUsHANA4ckp0A1GZNr TWGy0CfBE4NRA0Uf0lbdqNUM3TbN5okRq7Qps79P0NUM9gufrQzNOFs4QsBU 2_FFFjalEGLgliAQmpmjaXwVoBsMujfZwYz29oEsBKU7aj_94GeQbUjQPokp Y6M2Yyir2MLqf9ADnFY.Oh7Dy9hAk69apTZwvA0eDmWRq5lB6blSHinpKSxR ONi3JdG2SXjnYBFQrYgaSNjX5178nFjSOOECEBIGm_lm60ZwclUiGpZfZWuF SvMwvM_6Z9GO1KUlfxGV7GXF0tC1MLe0ACk7HNAtxzLjMDuuRAWLSwXTa3re o27x73dHARmbhQ9SyuxqxTngltHJYZhp_sgWby3ckY8oLhdYsCLzlkuzuFta IsCqjTktUXS3j0RIcYfdOR_MrQ1i9CvJrtUVOdMYb4v6oF6PtUtBHPZI2AFV 0z6ZjK16QVxpaOs9sDXBdDdiEImNhItTMucqLwahTORZav.q3GOafoC_1UzV W6QFb8f4ivhSl9NLOjrVtq2ZVlgAmaA-- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Fri, 01 Feb 2013 14:19:04 PST X-Rocket-MIMEInfo: 001.001, SGksCgpSZWdhcmRpbmcgdGhpcywKCiJBbHNvLCB0aGVyZSBpcwrCoCDCoGV2aWRlbmNlIGZyb20gdGhlIGZpZWxkIHRoYXQgSUVFRSBNQUMgYWRkcmVzc2VzIHdpdGggInUiID0gMCBhcmUKwqAgwqBzb21ldGltZSBpbmNvcnJlY3RseSBhc3NpZ25lZCB0byBtdWx0aXBsZSBNQUMgaW50ZXJmYWNlcy4iCgpJIGNhbWUgYWNyb3NzIHRoZSBmb2xsb3dpbmcgdGhpcyB3ZWVrIHdoaWNoIG1pZ2h0IGJlIHdvcnRoIHJlZmVyZW5jaW5nIHJlZ2FyZGluZ8Kgb2NjdXJyZW5jZcKgb2YgZHVwbGljYXRlIE1BQyBhZGRyZXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.131.499 References: <510B790D.8010301@gmail.com> Message-ID: <1359757144.42776.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Fri, 1 Feb 2013 14:19:04 -0800 (PST) From: Mark Smith Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] To: Brian E Carpenter , 6man In-Reply-To: <510B790D.8010301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 01 Feb 2013 22:19:07 -0000 Hi,=0A=0ARegarding this,=0A=0A"Also, there is=0A=A0 =A0evidence from the fi= eld that IEEE MAC addresses with "u" =3D 0 are=0A=A0 =A0sometime incorrectl= y assigned to multiple MAC interfaces."=0A=0AI came across the following th= is week which might be worth referencing regarding=A0occurrence=A0of duplic= ate MAC addresses:=0A=0A- How the data was collected -=0Ahttps://speakerdec= k.com/hdm/derbycon-2012-the-wild-west?slide=3D63=0A=0A=0A- The numbers=0Aht= tps://speakerdeck.com/hdm/derbycon-2012-the-wild-west?slide=3D64=0A=0A=0AI = was quite surprised at the numbers as I've never encountered duplicate MAC = addresses in around 20 years, and have only heard one or two first hand sto= ries of it.=0A=0ARegards,=0A=0AMark. From jmh@joelhalpern.com Fri Feb 1 16:41: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 EC2EE21E8049 for ; Fri, 1 Feb 2013 16:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGFPW9qsyph0 for ; Fri, 1 Feb 2013 16:41:48 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 30E6C1F0CFB for ; Fri, 1 Feb 2013 16:41:48 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id CB8CFA3A35 for ; Fri, 1 Feb 2013 16:41:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2A9A51C054D; Fri, 1 Feb 2013 16:41:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5F1521C046D; Fri, 1 Feb 2013 16:41:42 -0800 (PST) Message-ID: <510C60B1.4060401@joelhalpern.com> Date: Fri, 01 Feb 2013 19:41:21 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fernando Gont Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> In-Reply-To: <510C21D9.2020506@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Sat, 02 Feb 2013 00:41:49 -0000 With regard to section 3, I would ask the question in the reverse. (which may actually be the same quewstion Fernando is asking.) If we assume that there is value in being able to perform the diagnostic operation described, then it seems that one needs to be able to tell when it can be applied. Currently, that is u==1 in the IID field. The text says that u==1 must be used n the IID field for IIDs derived from EUI-64. But it the goes on to say that u=1 can be used by other addresses. If u=1 can be used by addresses not derived from EUI-64, then the diagnostic operation can not be applied without a-priori knowledge. And in the presence of such knowledge, the u bit does not seem to help. The obvious answer is that to enable the diagnostic, and because there is no need to make a gratuitous change, we stick with u=1 being used always and only for addresses derived from EUI-64. The other alternative I can understand, although I do not favor it, is to not allow the diagnostic at all. Yours, Joel On 2/1/2013 3:13 PM, Fernando Gont wrote: > Section 3: >> It should be noted that IIDs known or guessed to have been created >> according to RFC 4941 could be transformed back into MAC addresses, >> for example during fault diagnosis. For that reason, keeping the "u" >> and "g" bits in the IID has operational value. Therefore, the EUI-64 >> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >> cases where an IID is derived from a MAC address. > > How can you tell whether an IID was really derived from a MAC address, > or you just had pretty bad luck with your IID randomization -- such tha > it *looks* like derived form a mac address? > > Thanks! > > Cheers, > From fgont@si6networks.com Fri Feb 1 18:23: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 454EF21F8F0E for ; Fri, 1 Feb 2013 18:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECOuUcNgDhKr for ; Fri, 1 Feb 2013 18:23:28 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id A5A9F21F8F0C for ; Fri, 1 Feb 2013 18:23:28 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U1Sl7-00008V-Ux; Sat, 02 Feb 2013 03:23:23 +0100 Message-ID: <510C644E.7070104@si6networks.com> Date: Fri, 01 Feb 2013 21:56:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> In-Reply-To: <510C60B1.4060401@joelhalpern.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: Sat, 02 Feb 2013 02:23:29 -0000 On 02/01/2013 09:41 PM, Joel M. Halpern wrote: > With regard to section 3, I would ask the question in the reverse. > (which may actually be the same quewstion Fernando is asking.) > > If we assume that there is value in being able to perform the diagnostic > operation described, then it seems that one needs to be able to tell > when it can be applied. > Currently, that is u==1 in the IID field. > The text says that u==1 must be used n the IID field for IIDs derived > from EUI-64. > But it the goes on to say that u=1 can be used by other addresses. > If u=1 can be used by addresses not derived from EUI-64, then the > diagnostic operation can not be applied without a-priori knowledge. > And in the presence of such knowledge, the u bit does not seem to help. > > The obvious answer is that to enable the diagnostic, and because there > is no need to make a gratuitous change, we stick with u=1 being used > always and only for addresses derived from EUI-64. But if we enforce u=1 only for IIDS based on EUI-64, there might be other IIDs generated with some other mechanism, that lead to IIDs with such bit set to 1. Unless u=1 is enforced for all identifiers, chances are that eventually some other technology will generate an IID with u==1, and one would mistakenly assume that such IID was based on IEEE identifiers... (yes, in order for such "collisions" to occur, u would have to be 1, and the other technology would also have to produce the 0xfffe we currently insert to generate the Modified EUI64 identifiers... but "s* happens", they say...) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Sat Feb 2 00:24: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 8920221F9111 for ; Sat, 2 Feb 2013 00:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.766 X-Spam-Level: X-Spam-Status: No, score=-97.766 tagged_above=-999 required=5 tests=[AWL=1.155, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjxhxU8Mv-Tu for ; Sat, 2 Feb 2013 00:24:52 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 93F7421F910D for ; Sat, 2 Feb 2013 00:24:52 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so908256wie.4 for ; Sat, 02 Feb 2013 00:24:51 -0800 (PST) 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=U9JkVVXNCcaYANT496ApW/AD4xK/a85oxVpr0HdC2+A=; b=a36d2udiqZKnsdLXSqYSLAK2sxYkqSteZp/BD0hMr64eW/XIZ1z2islwdbId5shFgR MGuGHdnkzi8qnxvFbQk2RP3vf/QG/doJ5cToVByU81C8bQo+PdTysFT4CYeITRNuZ7Bk VLOZtD44LkyaSvCt01iTQJJS0oh1zXPoaMBrKjd168Yq7OOxkc9CefEUkC0D56UT6nIR HHO3XorgeVlX79/E22kWMA51xM+2djLt1q3fy0w2GYXVEbRnX1h0TzosF/ZZ4VZHDIam gb5UeWO9VHmGcsJRPTZ9wsT2R6yjFS4rz1pppCZGkJe+05jcYYGt5UPjUtP4zZZ6iDxX pUDg== X-Received: by 10.194.19.10 with SMTP id a10mr25817499wje.45.1359793491673; Sat, 02 Feb 2013 00:24:51 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-3.as13285.net. [2.101.188.3]) by mx.google.com with ESMTPS id gz3sm7696307wib.2.2013.02.02.00.24.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Feb 2013 00:24:51 -0800 (PST) Message-ID: <510CCD63.8060008@gmail.com> Date: Sat, 02 Feb 2013 08:25:07 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> In-Reply-To: <510C21D9.2020506@si6networks.com> Content-Type: text/plain; charset=UTF-8 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: Sat, 02 Feb 2013 08:24:53 -0000 Hi Fernando, On 01/02/2013 20:13, Fernando Gont wrote: > Hi, Brian & Sheng, > > On 02/01/2013 05:13 AM, Brian E Carpenter wrote: >> We've put this together to address the general question of the >> u/g bits in Interface IDs. Discussion is requested. > > Some comments: > > > Section 1: > > >> The specification assumes that that the normal case is to transform >> an Ethernet-style address into an IID, preserving the semantics of >> two bits in particular: >> >> o The "u" bit in an IEEE address is set to 0 to indicate universal >> scope (implying uniqueness) or to 1 to indicate local scope >> (without implying uniqueness). In an IID this bit is inverted, >> i.e., 1 for universal scope and 0 for local scope. According to >> [RFC5342], the reason for this was "to make it easier for network >> operators to type in local-scope identifiers". >> o The "g" bit in an IEEE address is set to 1 to indicate group >> addressing (link-layer multicast). This value is supposed to be >> preserved in an IID. > > The second bullet is not tru: e.g. temp addresses do not do anything to > preserve the "g" bit (the "u" bit *is* forced to 0, though); Well yes, but the statement *is* true when an IID is created from a MAC address, which is the point being made at that point in the document. (See my next message for my comment on Joel's reply.) > Section 2: > >> NOTE IN DRAFT: Are there other examples we should include? Are we >> sure that no IID format defines semantics for u/g? > > Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the > probability of collisions if your IIDs are derived from global > identifiers (more on this below). Who said that though? You are suggesting an intention which is nowhere in the documents. In any case, as soon as you admit a non-zero probability of collision, the game is changed. > Section 2, page 4: >> "The use of the universal/local bit in the Modified EUI-64 format >> identifier is to allow development of future technology that can take >> advantage of interface identifiers with universal scope." > > > This seems to assume that the namespace (Identifiers) of two different > technologies does not overlap. Such assumption sounds like dubious to > me... but I might be missing something. Yes, I believe it was a faulty assumption from the start (and I am one of the guilty parties). > > i.e. some non-IEEE technology is expected to obey the u/g bits? > > > Section 3: >> It should be noted that IIDs known or guessed to have been created >> according to RFC 4941 could be transformed back into MAC addresses, >> for example during fault diagnosis. For that reason, keeping the "u" >> and "g" bits in the IID has operational value. Therefore, the EUI-64 >> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >> cases where an IID is derived from a MAC address. > > How can you tell whether an IID was really derived from a MAC address, > or you just had pretty bad luck with your IID randomization -- such tha > it *looks* like derived form a mac address? You can't. Operationally you *might* have enough knowledge, but that is exactly why we included the word "guessed". Brian From brian.e.carpenter@gmail.com Sat Feb 2 00:35: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 8A12B21F8FE8 for ; Sat, 2 Feb 2013 00:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.344 X-Spam-Level: X-Spam-Status: No, score=-98.344 tagged_above=-999 required=5 tests=[AWL=0.578, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0ABloj5Kr9k for ; Sat, 2 Feb 2013 00:35:34 -0800 (PST) Received: from mail-we0-x232.google.com (we-in-x0232.1e100.net [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C86E321F8FE2 for ; Sat, 2 Feb 2013 00:35:33 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x48so3549099wey.37 for ; Sat, 02 Feb 2013 00:35:33 -0800 (PST) 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=6AQyrclYCzhOIvYo22SCo4zuEjmOPDDmY3jvdbr845U=; b=RqxrleQ/QRIS52KA2wCtWzmr4iq1SE4inePUnzzy79JZxnBTykRVOBnilpHCiSujTQ rqrTFCu2kVa/vjqSI7AI31jVwpnDqy3L0/1P1xrIyVoGBEr2jzDpz70mxB160avU4CYb JKT4tOiXseIIVrvo59qkvADrMg7bU5leEVxhILEqhOeJ0fr8QNufZMdFq4Z6ECC9/IQh E2xupvcb6rDTP4SCApCcY1M7lMvZMRgIhoq9mIJb5Fp+77o2qXMg8LAJuBKiw7EWquRJ qOyPyz0NuehdlsSR5kt/+HothgfWTDDqwHUgRzA0lCFzPy419TKcVjelQ0mWwMhY7aoD 7iRw== X-Received: by 10.194.78.236 with SMTP id e12mr25882372wjx.32.1359794132925; Sat, 02 Feb 2013 00:35:32 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-3.as13285.net. [2.101.188.3]) by mx.google.com with ESMTPS id e12sm8373112wiw.5.2013.02.02.00.35.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Feb 2013 00:35:32 -0800 (PST) Message-ID: <510CCFE4.6090506@gmail.com> Date: Sat, 02 Feb 2013 08:35:48 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> In-Reply-To: <510C60B1.4060401@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , 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: Sat, 02 Feb 2013 08:35:34 -0000 Joel, On 02/02/2013 00:41, Joel M. Halpern wrote: > With regard to section 3, I would ask the question in the reverse. > (which may actually be the same quewstion Fernando is asking.) > > If we assume that there is value in being able to perform the diagnostic > operation described, then it seems that one needs to be able to tell > when it can be applied. > Currently, that is u==1 in the IID field. > The text says that u==1 must be used n the IID field for IIDs derived > from EUI-64. > But it the goes on to say that u=1 can be used by other addresses. > If u=1 can be used by addresses not derived from EUI-64, then the > diagnostic operation can not be applied without a-priori knowledge. > And in the presence of such knowledge, the u bit does not seem to help. Correct. Semantically, it's a dead duck. That's already true, whatever words are written in RFCs - the fact that u=1 does not prove the IID comes from a MAC address with u=0, and vice versa. > The obvious answer is that to enable the diagnostic, and because there > is no need to make a gratuitous change, we stick with u=1 being used > always and only for addresses derived from EUI-64. But that doesn't mean that the IID was derived from a MAC address, so its value is limited. > The other alternative I can understand, although I do not favor it, is > to not allow the diagnostic at all. The alternative is what we have today: *assume* that an IID that looks as if it came from a MAC address in fact did so. Brian > > Yours, > Joel > > On 2/1/2013 3:13 PM, Fernando Gont wrote: > >> Section 3: >>> It should be noted that IIDs known or guessed to have been created >>> according to RFC 4941 could be transformed back into MAC addresses, >>> for example during fault diagnosis. For that reason, keeping the >>> "u" >>> and "g" bits in the IID has operational value. Therefore, the >>> EUI-64 >>> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >>> cases where an IID is derived from a MAC address. >> >> How can you tell whether an IID was really derived from a MAC address, >> or you just had pretty bad luck with your IID randomization -- such tha >> it *looks* like derived form a mac address? >> >> Thanks! >> >> Cheers, >> > From ietf@rozanak.com Sat Feb 2 00:44: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 0AD9221F8F6B for ; Sat, 2 Feb 2013 00:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNDaYEGM4Tl7 for ; Sat, 2 Feb 2013 00:44:28 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 751F521F8F5D for ; Sat, 2 Feb 2013 00:44:28 -0800 (PST) Received: from kopoli (g225091013.adsl.alicedsl.de [92.225.91.13]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MbOcG-1UHzdF0M3o-00JOFw; Sat, 02 Feb 2013 03:44:27 -0500 From: "Hosnieh Rafiee" To: Subject: I-D action : draft-rafiee-6man-ssas-01 Date: Sat, 2 Feb 2013 09:44:20 +0100 Message-ID: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01CE0129.E27701A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4BIX5EiDfFMPXTRfK/NYaGz7w55Q== Content-Language: en-us X-Provags-ID: V02:K0:X54fFOVOlR39evglZcMw7hst/OQ/Lm3urqJ3Sv+gmvG TsoJHcQDTQMTezgVpp9Lny8oroPqtu9kMerlRFPHCVHH2a3KDU +nVxgZ7bXrKNoq/p6rN15iXDc3oui+g0+sGrwAshuHLM0kxT3X ZiuL9L26FGmME0wy2Z9Hk5LEhqLeDWR/ysvvhiK20M7UMcwwZX P68J4srgpfWo6JF+aIELDSIFsie5DlAko6//c78qPapnqafBAN 2GpItYJc1foheiqXTQusU+sK5/A9Kpuy11UI6hOTTfRcJo50Fb +1Izf1SXv0FGYD77ZB/7FAuZZlbMINDgUxaML2iQXNI2NKfqAB iTNVA6PMoWZyDeKrPxK0= 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, 02 Feb 2013 08:44:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01CE0129.E27701A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Anyone had an opportunity to view the new version of our SSAS draft RFC. I received no comments after I applied the last comments given by Ray, Jeremy, Fernando and others. Your thoughts and comments would be greatly appreciated. http://tools.ietf.org/html/draft-rafiee-6man-ssas-01 Thank you, Hosnieh ------=_NextPart_000_003D_01CE0129.E27701A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

He= llo,

An= yone had an opportunity to view the new version of our SSAS draft RFC. I = received no comments after I applied the last comments given by Ray, = Jeremy, Fernando and others.  Your thoughts and comments would be = greatly appreciated.

http://tools.ietf.org/html/draft-rafiee-6man-ssas-01=

 

Th= ank you,

Ho= snieh

 

------=_NextPart_000_003D_01CE0129.E27701A0-- From despres.remi@laposte.net Sat Feb 2 02:33: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 4194621F8D92 for ; Sat, 2 Feb 2013 02:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xaa-m-S5SNn for ; Sat, 2 Feb 2013 02:33:13 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4757421F8D8F for ; Sat, 2 Feb 2013 02:33:12 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id AB2F770000A8; Sat, 2 Feb 2013 11:33:11 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 369DB700008C; Sat, 2 Feb 2013 11:33:11 +0100 (CET) X-SFR-UUID: 20130202103311223.369DB700008C@msfrf2309.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510C21D9.2020506@si6networks.com> Date: Sat, 2 Feb 2013 11:33:11 +0100 Message-Id: <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> To: Brian Carpenter X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , 6man 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: Sat, 02 Feb 2013 10:33:14 -0000 Brian, I agree that this is a good time to clarify uses of u and g bits, and = support the initiative Sheng and yourself has taken. Comments and suggestions inline. 2013-02-01 21:13, Fernando Gont : > Hi, Brian & Sheng, >=20 > On 02/01/2013 05:13 AM, Brian E Carpenter wrote: >>=20 >> We've put this together to address the general question of the >> u/g bits in Interface IDs. Discussion is requested. >=20 > Some comments: >=20 >=20 > Section 1: >=20 >=20 >> The specification assumes that that the normal case is to transform >> an Ethernet-style address into an IID, preserving the semantics of >> two bits in particular: >>=20 >> o The "u" bit in an IEEE address is set to 0 to indicate universal >> scope (implying uniqueness) or to 1 to indicate local scope >> (without implying uniqueness). In an IID this bit is inverted, >> i.e., 1 for universal scope and 0 for local scope. According to >> [RFC5342], the reason for this was "to make it easier for = network >> operators to type in local-scope identifiers". >> o The "g" bit in an IEEE address is set to 1 to indicate group >> addressing (link-layer multicast). This value is supposed to be >> preserved in an IID. >=20 > The second bullet is not tru: e.g. temp addresses do not do anything = to > preserve the "g" bit (the "u" bit *is* forced to 0, though); >=20 >=20 > Section 2: >=20 >>=20 >> NOTE IN DRAFT: Are there other examples we should include? Are we >> sure that no IID format defines semantics for u/g? >=20 > Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the > probability of collisions if your IIDs are derived from global > identifiers (more on this below). It completely eliminates collisions for all devices that comply with = IEEE specifications, and dramatically reduces it where some vendors have = reused some IEEE MAC addresses. If two devices have the same IEEE MAC address on a link, they have a = problem at the link layer, even before having one at the IP layer, and = has to be fixed.=20 In any case, and more important in my understanding, this doesn't change = that any IID having u=3Dg=3D1 can never conflict with IEEE-derived IIDs, = be they duplicated or not. A clarification on this would IMHO be useful. > Section 2, page 4: >>=20 >> "The use of the universal/local bit in the Modified EUI-64 format >> identifier is to allow development of future technology that can = take >> advantage of interface identifiers with universal scope." (*) >=20 >=20 > This seems to assume that the namespace (Identifiers) of two different > technologies does not overlap. Such assumption sounds like dubious to > me... but I might be missing something. AFAIK, it means that *if u=3D1* the structure of other bits has to be = universally specified. This is used so far for IEEE-derived IIDs. It can = advantageously be used for other technologies, as foreseen in RFC4291 = itself. 4rd is just the first proposed new use. > i.e. some non-IEEE technology is expected to obey the u/g bits? - For all addresses subject to SLAAC, all IETF technologies are = constrained by the u-bit meaning of RFC4291. If u=3D0, all other bits = have no recognizable structure; if u=3D11 if all other bits have a = recognizable=20 - For addresses that aren't subject to SLAAC like, for instance, those = of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs = isn't applicable. A clarification on this would IMHO be useful. Now, a new point: The sentence of RFC 4291 about future technologies ((*) above) is, in my = understanding and if taken rigorously, less open than it can be = concerning future technologies. It is sufficient that IIDs of new = technologies using u=3D1 have a universally recognizable structure. = There IID scopes can have a non-universal scope without breaking = anything. Your draft can be a place to clarify this. Note that this point is made in general, as a contribution to clarify = the u/g issue, not because it would concern 4rd. IIDs of 4rd are = universally unique (each one contains a globally unique IPv4 address, = plus a CNP field which has different values for all CEs that share this = address). =20 > Section 3: >> It should be noted that IIDs known or guessed to have been created >> according to RFC 4941 could be transformed back into MAC addresses, >> for example during fault diagnosis. For that reason, keeping the = "u" >> and "g" bits in the IID has operational value. Therefore, the = EUI-64 >> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >> cases where an IID is derived from a MAC address. >=20 > How can you tell whether an IID was really derived from a MAC address, > or you just had pretty bad luck with your IID randomization -- such = tha > it *looks* like derived form a mac address? All currently specified randomizations concern IIDs that have u=3D0. = None can conflict with formats specified for u=3D1 IIDs. Regards, RD > Thanks! >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From v6ops@globis.net Sat Feb 2 02:33: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 EA96721F9077 for ; Sat, 2 Feb 2013 02:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.308 X-Spam-Level: X-Spam-Status: No, score=-3.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaXMXVo51O3Q for ; Sat, 2 Feb 2013 02:33:20 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6C721F8EE6 for ; Sat, 2 Feb 2013 02:33:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C790F8700BC; Sat, 2 Feb 2013 11:28:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 sF76S66t5HhC; Sat, 2 Feb 2013 11:27:30 +0100 (CET) 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 B5A63870066; Sat, 2 Feb 2013 11:27:30 +0100 (CET) Message-ID: <510CEA0C.5030203@globis.net> Date: Sat, 02 Feb 2013 11:27:24 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> In-Reply-To: <510B790D.8010301@gmail.com> 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: Sat, 02 Feb 2013 10:33:22 -0000 I've read the draft. Quote: It should be noted that IIDs known or guessed to have been created according to RFC 4941 could be transformed back into MAC addresses, for example during fault diagnosis. For that reason, keeping the "u" and "g" bits in the IID has operational value. Therefore, the EUI-64 to IPv6 IID transformation defined in RFC 4941 MUST be used for all cases where an IID is derived from a MAC address. Dumb question: I don't get this. 4941 is "privacy extensions for SLAAC" and generates random IIDs with u=0. How can you "transform" a privacy extension for SLAAC IID back to a MAC address? IMHO The only combination that has operational value for the purpose of mapping IPv6 address to MAC today is: u==1 && g==0 && (concatenated with unicast IPv6/64 prefix[2000::/3] || link local address [fe80::/10]) && SLAAC (RFC4862) We've never had this sort of reverse mapping in IPv4, and "sh arp" on the local router was generally considered good enough operationally speaking. I 'd presume "show ipv6 neighbor binding" would also suffice. Brian E Carpenter wrote: > Hi, > > We've put this together to address the general question of the > u/g bits in Interface IDs. Discussion is requested. > > Brian + Sheng > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-6man-ug-00.txt > Date: Fri, 01 Feb 2013 00:10:13 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The U and G bits in IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-6man-ug-00.txt > Pages : 7 > Date : 2013-02-01 > > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-6man-ug > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-6man-ug-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 despres.remi@laposte.net Sat Feb 2 02:40: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 DE89F21F907E for ; Sat, 2 Feb 2013 02:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KmjSTrh8ouG for ; Sat, 2 Feb 2013 02:40:05 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBEB21F8E03 for ; Sat, 2 Feb 2013 02:40:05 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id A415C7000044; Sat, 2 Feb 2013 11:40:04 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 927FD7000086; Sat, 2 Feb 2013 11:40:04 +0100 (CET) X-SFR-UUID: 20130202104004600.927FD7000086@msfrf2309.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 4rd IID range & IPv6 addressing architecture From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <75FFC268-0E6C-41BE-B703-C53BB52E1131@gmail.com> Date: Sat, 2 Feb 2013 11:40:04 +0100 Message-Id: <075E0EB3-BCF3-4E7C-BE39-304D5B742196@laposte.net> References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> <75FFC268-0E6C-41BE-B703-C53BB52E1131@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1499) 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 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 10:40:06 -0000 2013-02-01 21:57, RJ Atkinson : >=20 > On 01 Feb 2013, at 10:30 , R=E9mi Despr=E9s wrote: >> Each of the designs we are interested in depends, to be complete, >> on reservation of a subset of the IID space left unused by RFC4291 >> (that having u=3Dg=3D1). >=20 > Both are *experiments*. Neither is a standard. >=20 > With respect to Softwire, they decided to standardise > something other than 4rd. Had they decided to=20 > standardise 4rd, my views would be different,=20 > but that wasn't the decision actually made in Softwire. >=20 > For *experiments*, a small shared use experimental=20 > allocation *under RFC-3692 rules* should be both=20 > sufficient and an appropriate approach -- and also > can be used with any other experiments that might arise=20 > in future. Different understanding. Making the reservation for one design, experimental or not, is a = guarantee that no future design with conflict with it, experimental or = not. A central registry is the appropriate tool for this. Regards, RD From brian.e.carpenter@gmail.com Sat Feb 2 03:46: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 EA99A21F9073 for ; Sat, 2 Feb 2013 03:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.921 X-Spam-Level: X-Spam-Status: No, score=-99.921 tagged_above=-999 required=5 tests=[AWL=1.770, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYsiFTgtFy0C for ; Sat, 2 Feb 2013 03:46:01 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 65AF921F906C for ; Sat, 2 Feb 2013 03:45:52 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so3474615wge.34 for ; Sat, 02 Feb 2013 03:45:51 -0800 (PST) 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=ObVc9951/7+hjUfVc3NOfOkYhedpBqrniLgNCmm2+6U=; b=QkYTkyRWiLnzhuXzPvYwaDuhET0p8PNbdgfHOYOK6FkZYJXyr48YucmhDMBr1PoNLQ EhVTgWFrh9kHbY05rFB9vWAnfFmcE7hP5YKniNXWCSoch0+OlZd8deiuZwBnPX3v1vDJ CpbEQnoH5PFxvxG8tJZENqKSpS21xeOo2ewFkzWAATQXeVOZKCgcn35e0ISxcwVtAdGM l/WxhWi6Ss2sFAj6m8vaD4224VdYxXMS51fX0WoK6ZTW3ySG/CP9hV1AiD1l6qUZx1Ei W/9lAu3ehd0uBleArOIuidVV/g6qljY2mVDIaamcih9F4NNniWZyJK9igyqi+5X/IB7N KTng== X-Received: by 10.180.85.226 with SMTP id k2mr2289271wiz.34.1359805551496; Sat, 02 Feb 2013 03:45:51 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-3.as13285.net. [2.101.188.3]) by mx.google.com with ESMTPS id g2sm9313883wiy.0.2013.02.02.03.45.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Feb 2013 03:45:50 -0800 (PST) Message-ID: <510CFC7E.2040602@gmail.com> Date: Sat, 02 Feb 2013 11:46:06 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510CEA0C.5030203@globis.net> In-Reply-To: <510CEA0C.5030203@globis.net> Content-Type: text/plain; charset=UTF-8 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: Sat, 02 Feb 2013 11:46:02 -0000 On 02/02/2013 10:27, Ray Hunter wrote: > I've read the draft. > > Quote: It should be noted that IIDs known or guessed to have been created > according to RFC 4941 could be transformed back into MAC addresses, > for example during fault diagnosis. For that reason, keeping the "u" > and "g" bits in the IID has operational value. Therefore, the EUI-64 > to IPv6 IID transformation defined in RFC 4941 MUST be used for all > cases where an IID is derived from a MAC address. > > > Dumb question: I don't get this. 4941 is "privacy extensions for SLAAC" AAARGH. s/4941/4291/ > and generates random IIDs with u=0. > How can you "transform" a privacy extension for SLAAC IID back to a MAC > address? > > IMHO The only combination that has operational value for the purpose of > mapping IPv6 address to MAC today is: > u==1 && g==0 && (concatenated with unicast IPv6/64 prefix[2000::/3] || > link local address [fe80::/10]) && SLAAC (RFC4862) > > We've never had this sort of reverse mapping in IPv4, and "sh arp" on > the local router was generally considered good enough operationally > speaking. > I 'd presume "show ipv6 neighbor binding" would also suffice. Maybe, but every little helps. Brian > > Brian E Carpenter wrote: >> Hi, >> >> We've put this together to address the general question of the >> u/g bits in Interface IDs. Discussion is requested. >> >> Brian + Sheng >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-6man-ug-00.txt >> Date: Fri, 01 Feb 2013 00:10:13 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : The U and G bits in IPv6 Interface Identifiers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-carpenter-6man-ug-00.txt >> Pages : 7 >> Date : 2013-02-01 >> >> 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. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-6man-ug >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-carpenter-6man-ug-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 kauer@biplane.com.au Sat Feb 2 04:03: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 336B421F8F9E for ; Sat, 2 Feb 2013 04:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkrbLS3CcZ9m for ; Sat, 2 Feb 2013 04:03:01 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B44521F8F99 for ; Sat, 2 Feb 2013 04:02:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUDAO3/DFGWZX+7/2dsb2JhbAANMga+MQOBGoMSAQEBBCdiCxguVxmIHa54kySJV4NNAQsGS4NRA4gwijeEVYoliB+BUgE Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Feb 2013 22:32:57 +1030 Message-ID: <1359806574.6652.97.camel@karl> Subject: Re: I-D action : draft-rafiee-6man-ssas-01 From: Karl Auer To: ipv6@ietf.org Date: Sat, 02 Feb 2013 23:02:54 +1100 In-Reply-To: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.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: Sat, 02 Feb 2013 12:03:02 -0000 On Sat, 2013-02-02 at 09:44 +0100, Hosnieh Rafiee wrote: > Anyone had an opportunity to view the new version of our SSAS draft RFC. I > received no comments after I applied the last comments given by Ray, Jeremy, > Fernando and others. Your thoughts and comments would be greatly > appreciated. > > http://tools.ietf.org/html/draft-rafiee-6man-ssas-01 Comments below. Disclaimer: I am not a crypto guy :-) Regards, K. In the Abstract: I don't think the word "organitionally" exists. If it does it is so unusual that it should be replaced with a more common word or with a description of what the word means. CGA were not designed to address privacy related attacks, they are a means of securing NDP exchanges. The fact that they appear random is coincidental to their function. Introduction: Either always use leading zeros in your example values, or never, but don't mix them. I suggest that always using leading zeros would be better. MAC should always be capitalised: "MAC", not "Mac", throughout. In your description of how an EUI-64 IID is formed, you have omitted the need to complement bit7 of the IID. The introduction repeats the error in the abstract, that CGA addresses are "used to randomize the IID". There are places where necessary spaces have been omitted: "[RFC3315]can", "approachfor". The sentence beginning "This convention..." is unnecessary. In the problem statement, the second sentence should read "...easy for an attacker to track that node as it moves between networks." Or similar, but it is unclear as it stands. "If one wants to use a secure method, with the privacy extension, then one needs to use CGA." Can one use CGA with privacy addressing? That is, can you have CGA addresses that change regularly, as privacy addresses do? I'm not sure. Spell check everything ("Deniel of Service", "deminished", etc) "In order to overcome the problem with the other mechanisms,[...]" What other mechanisms? Isn't this just a problem with CGA? "the time is needed to generate and verify IP address needs to be decreased" -> "the time required to generate and verify IP addresses needs to be reduced" In 2.1.1.3 there is an odd character in "victim?s", should be "victim's". The same odd character appears in other places. In 2.1.1.3 suggest that the first SHOULD should be MAY. In 2.1.1.3, it is unclear whether the formula is provided as a helpful hint, or whether this is the formula that should be used. Why a 2-minute window? I suggest using language similar to other RFCs in similar situations, e.g. "To mitigate such an attack, a node SHOULD rate limit message verification. Implementations MUST provide a conservative default and SHOULD provide a way for the rate limiting parameters to be set by the node administrator." 2.1.2 should provide an explanation of why SSAS is helpful in nodes with limited resources. It appears that it is not helpful per se, but is helpful *in comparison to CGA*, because of the lower computational load. An explanation is also needed for why SSAS is useful in mobile networks. In the first para of section 3: Compute load is only a problem with CGA. Privacy is only a problem with SLAAC (and maybe with CGA if a node uses the same 64-bit CGA IID on multiple networks). This introductory paragraph seems to just restate what has already been said elsewhere and could probably be dropped anyway. 3.1 step 2: There is no need to specify XML or any other particular storage method, format or location. These can be left to the implementation. All that is necessary is that these items be stored where they will survive for the length of time a particular key pair will be in use. You need to address the situation where a node has no such storage. 3.1 step 2 second para: The use of should and SHOULD is confusing. Should a node generate new keys? If it does, should it use them? If it isn't going to use them, why generate them? What happens when a new address is generated - is it used alongside the old one or are current connections using the old address dropped immediately? The loss of active connections when an address changes might be worth mentioning somewhere. 3.1 step 2: Either the encryption algorithms used must be stipulated, or there must be some mechanism for the verifier to know what method was used by the sender. 3.1 step 3: What is "a fixed point format"? Needs explanation. If there is more than one possible "fixed point format" then the specific one used by SSAS must be specified. 3.1 step 5: Why is a whole byte needed to store a value from 0 to 20? Have you done the maths to check that this value will actually meaningfully "[help] randomize the IID and [...] minimize the chance of a collision in the network"? If the benefit is not significant, then this step should be omitted. 3.1 step 10 "this IP will be permanent after..." This contradicts earlier recommendations that the IP be changed after a certain period. 3.2 This needs to be clearer. It seems that you are describing the components of the NDP message that will be signed, not items that will actually be included in the signature. Either way, it seems to me that a list of components should be provided for each NDP message type that requires signing, with a default to cover all others and any that have not yet been invented. 3.3 How does a recipient know whether a message is SEND+SSAS or just SEND? 3.3.1: Length is described as including certain fields; the description does NOT include certain other fields, such as subnet prefix, other options. It seems to me that length can simply be described as "the length of the signature data field". Might be an idea to specify the units, eg "length in octets". 3.3.1 Padding would be more simply described by saying that "if the above values do not form an SSAS signature field that is an exact multiple of eight octets long, random octets are added to the end of the signature field to bring its length up to an exact multiple of eight octets." Or octets with the binary value zero, or whatever. 3.3.1: "If, for a second time, the node receives the same claim, then it considers it an attack and will use that IP address." Why? And why two? Is this because no two nodes should ever be able to generate the same address? If so, then either one try is sufficient, or arbitrarily many will be insufficient. 4: This seems to need a bit of bulking out. Also, the discussion of trust anchors is unclear - what, if any, place do trust anchors have in SSAS? Might be worth discussing how shorter key validity periods affect the likelihood of a successful attack. 5. Is that an IAN consideration? 6. This section repeats the error that CGA is about randomising IIDs. It is not, that's a side effect at best. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog 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 brian@innovationslab.net Sat Feb 2 05:26: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 28FAA21F8C5D for ; Sat, 2 Feb 2013 05:26:45 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXUCOazjbi1y for ; Sat, 2 Feb 2013 05:26:44 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id AF4FF21F8C5B for ; Sat, 2 Feb 2013 05:26:44 -0800 (PST) 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 5835788142 for ; Sat, 2 Feb 2013 05:26:44 -0800 (PST) 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 1682113000C for ; Sat, 2 Feb 2013 05:26:43 -0800 (PST) Message-ID: <510D1416.6080503@innovationslab.net> Date: Sat, 02 Feb 2013 08:26:46 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510C644E.7070104@si6networks.com> In-Reply-To: <510C644E.7070104@si6networks.com> 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: Sat, 02 Feb 2013 13:26:45 -0000 On 2/1/13 7:56 PM, Fernando Gont wrote: > On 02/01/2013 09:41 PM, Joel M. Halpern wrote: >> With regard to section 3, I would ask the question in the reverse. >> (which may actually be the same quewstion Fernando is asking.) >> >> If we assume that there is value in being able to perform the diagnostic >> operation described, then it seems that one needs to be able to tell >> when it can be applied. >> Currently, that is u==1 in the IID field. >> The text says that u==1 must be used n the IID field for IIDs derived >> from EUI-64. >> But it the goes on to say that u=1 can be used by other addresses. >> If u=1 can be used by addresses not derived from EUI-64, then the >> diagnostic operation can not be applied without a-priori knowledge. >> And in the presence of such knowledge, the u bit does not seem to help. >> >> The obvious answer is that to enable the diagnostic, and because there >> is no need to make a gratuitous change, we stick with u=1 being used >> always and only for addresses derived from EUI-64. And to state the obvious, that implies that u==g==1 means we are looking at an identifier derived from a hardware-based identifier (e.g., IEEE). > > But if we enforce u=1 only for IIDS based on EUI-64, there might be > other IIDs generated with some other mechanism, that lead to IIDs with > such bit set to 1. > > Unless u=1 is enforced for all identifiers, chances are that eventually > some other technology will generate an IID with u==1, and one would > mistakenly assume that such IID was based on IEEE identifiers... > > (yes, in order for such "collisions" to occur, u would have to be 1, and > the other technology would also have to produce the 0xfffe we currently > insert to generate the Modified EUI64 identifiers... but "s* happens", > they say...) The assumption that 0xFFFE will be in the identifier is incorrect. That pattern is only inserted when the 64-bit IID is generated from a 48-bit IEEE identifier. If I use a 64-bit IEEE identifier, the u bit will be set to 1, but the 0xFFFE pattern will (most likely) not be there. From v6ops@globis.net Sat Feb 2 05:56: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 E387C21F8836 for ; Sat, 2 Feb 2013 05:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szjvqnD8F5P6 for ; Sat, 2 Feb 2013 05:56:21 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4921F8431 for ; Sat, 2 Feb 2013 05:56:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B304C8700BC; Sat, 2 Feb 2013 14:46:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 PV-hLDhKdBOU; Sat, 2 Feb 2013 14:45:34 +0100 (CET) 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 291CE870081; Sat, 2 Feb 2013 14:45:34 +0100 (CET) Message-ID: <510D1877.9020209@globis.net> Date: Sat, 02 Feb 2013 14:45:27 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> In-Reply-To: <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Fernando Gont , 6man 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: Sat, 02 Feb 2013 13:56:23 -0000 Inline Rémi Després wrote: > Brian, > > I agree that this is a good time to clarify uses of u and g bits, and support the initiative Sheng and yourself has taken. > Comments and suggestions inline. > > 2013-02-01 21:13, Fernando Gont : > >> Hi, Brian & Sheng, >> >> On 02/01/2013 05:13 AM, Brian E Carpenter wrote: >>> We've put this together to address the general question of the >>> u/g bits in Interface IDs. Discussion is requested. >> Some comments: >> >> >> Section 1: >> >> >>> The specification assumes that that the normal case is to transform >>> an Ethernet-style address into an IID, preserving the semantics of >>> two bits in particular: Right. "Normal case." Not "exclusive case." >>> o The "u" bit in an IEEE address is set to 0 to indicate universal >>> scope (implying uniqueness) or to 1 to indicate local scope >>> (without implying uniqueness). In an IID this bit is inverted, >>> i.e., 1 for universal scope and 0 for local scope. According to >>> [RFC5342], the reason for this was "to make it easier for network >>> operators to type in local-scope identifiers". >>> o The "g" bit in an IEEE address is set to 1 to indicate group >>> addressing (link-layer multicast). This value is supposed to be >>> preserved in an IID. >> The second bullet is not tru: e.g. temp addresses do not do anything to >> preserve the "g" bit (the "u" bit *is* forced to 0, though); > >> Section 2: >> >>> NOTE IN DRAFT: Are there other examples we should include? Are we >>> sure that no IID format defines semantics for u/g? >> Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the >> probability of collisions if your IIDs are derived from global >> identifiers (more on this below). This is also my interpretation. > It completely eliminates collisions for all devices that comply with IEEE specifications, and dramatically reduces it where some vendors have reused some IEEE MAC addresses. > If two devices have the same IEEE MAC address on a link, they have a problem at the link layer, even before having one at the IP layer, and has to be fixed. > > In any case, and more important in my understanding, this doesn't change that any IID having u=1 can never conflict with IEEE-derived IIDs, be they duplicated or not. A clarification on this would IMHO be useful. I have a problem with any assumption that u=1 => global uniqueness, or u=1 => IEEE EUI64 with IEEE administered OUI. Carefully reading RFC4291 I come up with the following: Quote: "Modified EUI-64 format-based interface identifiers may have universal scope when derived from a universal token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers [EUI64])" Note the "may" and note the "e.g." Quote: "EUI64 *format*" Note the complete absence of text like "when u=1, the IID SHOULD/MUST be formed from an IEEE EUI64, including a globally unique OUI portion administered by the IEEE." I therefore openly question any assumptions regarding the IEEE as being defined as the sole and exclusive source of "universal tokens" in the IPv6 addressing architecture. If another standards body built a link technology based on EUI64 *format* identifiers, but with their own OUI administration, that should never be a problem for IPv6, because RFC4291 only requires IID's to be "unique within a subnet prefix." They are not required to be globally unique across all link technologies. This is backed up by another quote from RFC4291: "The details of forming interface identifiers are defined in the appropriate "IPv6 over " specification" Even the IEEE definition of EUI64 in http://standards.ieee.org/develop/regauth/tut/eui64.pdf states Quote "When an EUI-64 is used within the context of an IEEE standard, the standard shall be reviewed by the IEEE RAC for correctness and clarity. When an EUI-64 is referenced within non-IEEE standards, there shall not be any reference to IEEE unless approved by the IEEE RAC." Was this coupling of standards ever reviewed by the IEEE? Because it seems to me that the lack of universally clear handling of the u=1 g=1 case in IETF documents would not fit with the existing IEEE definition of EUI64, where u=1 g=1 is clearly a globally administered multicast address, and is not available for any other use. So my conclusion is that any coupling between IEEE and IETF standards should be weak at most, and also limited to individual links. > > >> Section 2, page 4: >>> "The use of the universal/local bit in the Modified EUI-64 format >>> identifier is to allow development of future technology that can take >>> advantage of interface identifiers with universal scope." > (*) > >> This seems to assume that the namespace (Identifiers) of two different >> technologies does not overlap. Such assumption sounds like dubious to >> me... but I might be missing something. > > AFAIK, it means that *if u= the structure of other bits has to be universally specified. This is used so far for IEEE-derived IIDs. It can advantageously be used for other technologies, as foreseen in RFC4291 itself. 4rd is just the first proposed new use. > > >> i.e. some non-IEEE technology is expected to obey the u/g bits? > > - For all addresses subject to SLAAC, all IETF technologies are constrained by the u-bit meaning of RFC4291. If u= all other bits have no recognizable structure; if u if all other bits have a recognizable > - For addresses that aren't subject to SLAAC like, for instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't applicable. A clarification on this would IMHO be useful. > > > Now, a new point: > The sentence of RFC 4291 about future technologies ((*) above) is, in my understanding and if taken rigorously, less open than it can be concerning future technologies. It is sufficient that IIDs of new technologies using u=have a universally recognizable structure. There IID scopes can have a non-universal scope without breaking anything. Your draft can be a place to clarify this. > > Note that this point is made in general, as a contribution to clarify the u/g issue, not because it would concern 4rd. IIDs of 4rd are universally unique (each one contains a globally unique IPv4 address, plus a CNP field which has different values for all CEs that share this address). > > >> Section 3: >>> It should be noted that IIDs known or guessed to have been created >>> according to RFC 4941 could be transformed back into MAC addresses, >>> for example during fault diagnosis. For that reason, keeping the "u" >>> and "g" bits in the IID has operational value. Therefore, the EUI-64 >>> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >>> cases where an IID is derived from a MAC address. >> How can you tell whether an IID was really derived from a MAC address, >> or you just had pretty bad luck with your IID randomization -- such tha >> it *looks* like derived form a mac address? > > All currently specified randomizations concern IIDs that have u= None can conflict with formats specified for u=1 IIDs. > > Regards, > RD > > > >> Thanks! >> >> Cheers, >> -- >> 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.e.carpenter@gmail.com Sat Feb 2 06:17: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 4E30521F8619 for ; Sat, 2 Feb 2013 06:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.364 X-Spam-Level: X-Spam-Status: No, score=-100.364 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR2aCUF461b3 for ; Sat, 2 Feb 2013 06:17:00 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 79D2821F85E0 for ; Sat, 2 Feb 2013 06:17:00 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hq4so1529472wib.12 for ; Sat, 02 Feb 2013 06:16:57 -0800 (PST) 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=9YZ5S+Y8RFNd4lgvAMfgN57+AmpQ3FCBuxCJ8CpQ/6w=; b=V7Qo+SjS5z1Se4TrXgEg6CYxUe2Pom5yMMYVT5APwihcF7Yxja2xSbf+VMElsg8CWC xo5zJnwjC0blJBKuqW2mNd07rZr680xy1PDBJ1WChgRqdhDz0XCVGppcMCXlZ8u56czj l3i2g977q1PFwteNY5y26OLuhUd6i58WozBeSH2wl3kgHtCpChZ89CkebvIHnjmZ//w6 M1NrN1mL4AZMSb6BzwPB2cvYKAXRoKgcj7g7PvXSaptIciSV4iKvOKnP3o6qLJKJkvAK AVS7Rc9rw+yixFGQzrzIWZ43/zQ+/wfIdHAlJOge6FcCmW5JsjuQuLvOmJhHXJpAgkd2 JKGw== X-Received: by 10.194.78.207 with SMTP id d15mr26820856wjx.52.1359814617379; Sat, 02 Feb 2013 06:16:57 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-3.as13285.net. [2.101.188.3]) by mx.google.com with ESMTPS id be1sm10047563wib.10.2013.02.02.06.16.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Feb 2013 06:16:56 -0800 (PST) Message-ID: <510D1FE9.90103@gmail.com> Date: Sat, 02 Feb 2013 14:17:13 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510C644E.7070104@si6networks.com> <510D1416.6080503@innovationslab.net> In-Reply-To: <510D1416.6080503@innovationslab.net> 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: Sat, 02 Feb 2013 14:17:01 -0000 On 02/02/2013 13:26, Brian Haberman wrote: > On 2/1/13 7:56 PM, Fernando Gont wrote: >> On 02/01/2013 09:41 PM, Joel M. Halpern wrote: >>> With regard to section 3, I would ask the question in the reverse. >>> (which may actually be the same quewstion Fernando is asking.) >>> >>> If we assume that there is value in being able to perform the diagnostic >>> operation described, then it seems that one needs to be able to tell >>> when it can be applied. >>> Currently, that is u==1 in the IID field. >>> The text says that u==1 must be used n the IID field for IIDs derived >>> from EUI-64. >>> But it the goes on to say that u=1 can be used by other addresses. >>> If u=1 can be used by addresses not derived from EUI-64, then the >>> diagnostic operation can not be applied without a-priori knowledge. >>> And in the presence of such knowledge, the u bit does not seem to help. >>> >>> The obvious answer is that to enable the diagnostic, and because there >>> is no need to make a gratuitous change, we stick with u=1 being used >>> always and only for addresses derived from EUI-64. > > And to state the obvious, that implies that u==g==1 means we are looking > at an identifier derived from a hardware-based identifier (e.g., IEEE). Yes, even if it make no sense. Or of course that we are looking at an arbitrarily invented IID that means nothing in particular. Who's to say? Brian > >> >> But if we enforce u=1 only for IIDS based on EUI-64, there might be >> other IIDs generated with some other mechanism, that lead to IIDs with >> such bit set to 1. >> >> Unless u=1 is enforced for all identifiers, chances are that eventually >> some other technology will generate an IID with u==1, and one would >> mistakenly assume that such IID was based on IEEE identifiers... >> >> (yes, in order for such "collisions" to occur, u would have to be 1, and >> the other technology would also have to produce the 0xfffe we currently >> insert to generate the Modified EUI64 identifiers... but "s* happens", >> they say...) > > The assumption that 0xFFFE will be in the identifier is incorrect. That > pattern is only inserted when the 64-bit IID is generated from a 48-bit > IEEE identifier. If I use a 64-bit IEEE identifier, the u bit will be > set to 1, but the 0xFFFE pattern will (most likely) not be there. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fgont@si6networks.com Sat Feb 2 06:50: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 852D621F852C for ; Sat, 2 Feb 2013 06:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oJ8E4uqxYNE for ; Sat, 2 Feb 2013 06:50:58 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8087C21F8528 for ; Sat, 2 Feb 2013 06:50:58 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U1eQH-0000eC-OM; Sat, 02 Feb 2013 15:50:32 +0100 Message-ID: <510D27AB.8000406@si6networks.com> Date: Sat, 02 Feb 2013 11:50:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510CCD63.8060008@gmail.com> In-Reply-To: <510CCD63.8060008@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 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: Sat, 02 Feb 2013 14:50:59 -0000 Hi, Brian, On 02/02/2013 05:25 AM, Brian E Carpenter wrote: >>> o The "u" bit in an IEEE address is set to 0 to indicate universal >>> scope (implying uniqueness) or to 1 to indicate local scope >>> (without implying uniqueness). In an IID this bit is inverted, >>> i.e., 1 for universal scope and 0 for local scope. According to >>> [RFC5342], the reason for this was "to make it easier for network >>> operators to type in local-scope identifiers". >>> o The "g" bit in an IEEE address is set to 1 to indicate group >>> addressing (link-layer multicast). This value is supposed to be >>> preserved in an IID. >> >> The second bullet is not tru: e.g. temp addresses do not do anything to >> preserve the "g" bit (the "u" bit *is* forced to 0, though); > > Well yes, but the statement *is* true when an IID is created from a MAC > address, which is the point being made at that point in the document. Agreed. (My apologies for how my phrase was worded.. "English as second language"+"24hs working" didn't help much in me crafting my response nicely). > (See my next message for my comment on Joel's reply.) > >> Section 2: >> >>> NOTE IN DRAFT: Are there other examples we should include? Are we >>> sure that no IID format defines semantics for u/g? >> >> Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the >> probability of collisions if your IIDs are derived from global >> identifiers (more on this below). > > Who said that though? You are suggesting an intention which is nowhere > in the documents. Agreed, but the text notes that "that is so that it is easier for manually-configured addresses" -- i.e., the text notes that the idea is that manually-configured addresses don't "overap" with the automatically-configured ones.. > In any case, as soon as you admit a non-zero probability > of collision, the game is changed. I fully agree. That's the point I was trying to make. >> This seems to assume that the namespace (Identifiers) of two different >> technologies does not overlap. Such assumption sounds like dubious to >> me... but I might be missing something. > > Yes, I believe it was a faulty assumption from the start (and I am one > of the guilty parties). I guess the current "MUST" could be changed to "MAY" -- i.e., setting the bit to zero might still help to reduce collisions with IEEE-derived IIDs. HOwever, this discussion raises yet another (more) interesting question: considering the predictability properties of IEEE-derived IIDs, and the fact that you cannot even assume that such identifiers are unique, why are we using that scheme as the default mechanism for generating SLAAC addresses in the first place? :-) 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 Sat Feb 2 07:03: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 75BC621F8584 for ; Sat, 2 Feb 2013 07:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVK57Kv1vQCW for ; Sat, 2 Feb 2013 07:03:33 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id E0AEF21F8461 for ; Sat, 2 Feb 2013 07:03:32 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U1ec8-0000sW-HI; Sat, 02 Feb 2013 16:03:10 +0100 Message-ID: <510D2A7B.80301@si6networks.com> Date: Sat, 02 Feb 2013 12:02:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: 4rd IID range & IPv6 addressing architecture References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> <75FFC268-0E6C-41BE-B703-C53BB52E1131@gmail.com> <075E0EB3-BCF3-4E7C-BE39-304D5B742196@laposte.net> In-Reply-To: <075E0EB3-BCF3-4E7C-BE39-304D5B742196@laposte.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org, 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: Sat, 02 Feb 2013 15:03:33 -0000 On 02/02/2013 07:40 AM, Rémi Després wrote: >> Both are *experiments*. Neither is a standard. >> >> With respect to Softwire, they decided to standardise >> something other than 4rd. Had they decided to >> standardise 4rd, my views would be different, >> but that wasn't the decision actually made in Softwire. >> >> For *experiments*, a small shared use experimental >> allocation *under RFC-3692 rules* should be both >> sufficient and an appropriate approach -- and also >> can be used with any other experiments that might arise >> in future. > > Different understanding. > > Making the reservation for one design, experimental or not, is a guarantee that no future design with conflict with it, experimental or not. The point is that if't an experiment, you don't really want to permanently-asign any resources to it. -- that's probably why run suggested a "shared allocation". If the experiment turns out to be successful, you get the actual assignment. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From despres.remi@laposte.net Sat Feb 2 07:09: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 1AD8321F8536 for ; Sat, 2 Feb 2013 07:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 685n3OFhsa8I for ; Sat, 2 Feb 2013 07:09:34 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 66ECF21F84F2 for ; Sat, 2 Feb 2013 07:09:33 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 5A1417000087; Sat, 2 Feb 2013 16:09:32 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 0C9707000084; Sat, 2 Feb 2013 16:09:31 +0100 (CET) X-SFR-UUID: 20130202150932516.0C9707000084@msfrf2221.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 4rd IID range & IPv6 addressing architecture From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510D2A7B.80301@si6networks.com> Date: Sat, 2 Feb 2013 16:09:32 +0100 Message-Id: <2D7214D9-0F30-4469-81FB-73A3AB12FE75@laposte.net> References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com> <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net> <4210F5DB-DB96-4883-9409-BF4787688F99@gmail.com> <75FFC268-0E6C-41BE-B703-C53BB52E1131@gmail.com> <075E0EB3-BCF3-4E7C-BE39-304D5B742196@laposte.net> <510D2A7B.80301@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Brian Haberman , Bob Hinden 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, 02 Feb 2013 15:09:35 -0000 Le 2013-02-02 =E0 16:02, Fernando Gont a =E9crit = : > On 02/02/2013 07:40 AM, R=E9mi Despr=E9s wrote: >>> Both are *experiments*. Neither is a standard. >>>=20 >>> With respect to Softwire, they decided to standardise >>> something other than 4rd. Had they decided to=20 >>> standardise 4rd, my views would be different,=20 >>> but that wasn't the decision actually made in Softwire. >>>=20 >>> For *experiments*, a small shared use experimental=20 >>> allocation *under RFC-3692 rules* should be both=20 >>> sufficient and an appropriate approach -- and also >>> can be used with any other experiments that might arise=20 >>> in future. >>=20 >> Different understanding. >>=20 >> Making the reservation for one design, experimental or not, is a = guarantee that no future design with conflict with it, experimental or = not. >=20 > The point is that if't an experiment, you don't really want to > permanently-asign any resources to it. -- that's probably why run > suggested a "shared allocation". >=20 > If the experiment turns out to be successful, you get the actual = assignment. As answered to Ran: - Making the reservation for one design, experimental or not, is a = guarantee that no future design will conflict with it, experimental or = not. - A central registry is the appropriate tool for this. Besides reserving 1/2^14 of the unused space, for which there hasn't = been any request in more than 6 years now, shouldn't be considered a big = deal (IMHO). Regards, RD =20 >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From despres.remi@laposte.net Sat Feb 2 07: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 9864321F853C for ; Sat, 2 Feb 2013 07:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpOu40hlhCOI for ; Sat, 2 Feb 2013 07:10:21 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id E835921F8797 for ; Sat, 2 Feb 2013 07:10:20 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 5795E7000087; Sat, 2 Feb 2013 16:10:20 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id E49FC7000092; Sat, 2 Feb 2013 16:10:19 +0100 (CET) X-SFR-UUID: 20130202151019936.E49FC7000092@msfrf2221.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510CFC7E.2040602@gmail.com> Date: Sat, 2 Feb 2013 16:10:20 +0100 Message-Id: <8E69E435-1186-465D-82C9-F4643DDB6345@laposte.net> References: <510B790D.8010301@gmail.com> <510CEA0C.5030203@globis.net> <510CFC7E.2040602@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ray Hunter , Brian Haberman , 6man 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: Sat, 02 Feb 2013 15:10:21 -0000 2013-02-02 12:46, Brian E Carpenter : ... >> IMHO The only combination that has operational value for the purpose = of >> mapping IPv6 address to MAC today is: >> u=3D=3D1 && g=3D=3D0 && (concatenated with unicast IPv6/64 = prefix[2000::/3] || >> link local address [fe80::/10]) && SLAAC (RFC4862) >>=20 >> We've never had this sort of reverse mapping in IPv4, and "sh arp" on >> the local router was generally considered good enough operationally >> speaking. >> I 'd presume "show ipv6 neighbor binding" would also suffice. >=20 > Maybe, but every little helps. I support that IIDs that have u=3D1 MAY be used to extract some = meaningful information, doing it or not remaining a vendor choice. Pending any new IID reservations, what is possible is AFAIK the = following:=20 - At an Ethernet interface, if an assigned IID has u=3D1, u=3D0, bits = 24-39 =3D 0xFE, and OUI bits 0-24 aren't 00-00-5E (the IANA OUI, ref = https://tools.ietf.org/html/rfc5342#section-1.2.1), then the MAC address = should be that of IID bits 0-23 followed by bits 40-127. If the 4rd reserved IID prefix is confirmed to be 0x0300, this is = complemented with the following: - At a customer site entry that is assigned an IPv6 prefix up to /64, if = an destination IID starts with 0x0300, then IID bits 16-47 should be = those of a global IPv4 address usable in this site, exclusively or = shared depending on which 4rd CE mapping rule applies to the site. In = addition, IID bits 48-64 should be the opposite of the one's complement = sum of the five 16-bit fields from address bits 0-79. =20 Regards, RD From fgont@si6networks.com Sat Feb 2 07:16: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 C956421F8505 for ; Sat, 2 Feb 2013 07:16:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPaSyD4wc6aj for ; Sat, 2 Feb 2013 07:16:10 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 472AE21F84E8 for ; Sat, 2 Feb 2013 07:16:10 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U1eok-0001Ea-Py; Sat, 02 Feb 2013 16:15:47 +0100 Message-ID: <510D2D8F.4090805@si6networks.com> Date: Sat, 02 Feb 2013 12:15:27 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ray Hunter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> <510D1877.9020209@globis.net> In-Reply-To: <510D1877.9020209@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man 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: Sat, 02 Feb 2013 15:16:10 -0000 On 02/02/2013 10:45 AM, Ray Hunter wrote: > If another standards body built a link technology based on EUI64 > *format* identifiers, but with their own OUI administration, that should > never be a problem for IPv6, because RFC4291 only requires IID's to be > "unique within a subnet prefix." They are not required to be globally > unique across all link technologies. This is backed up by another quote > from RFC4291: "The details of forming interface identifiers are defined > in the appropriate "IPv6 over " specification" How could you possible ensure such uniqueness without coordination? (i.e., how can you ensure uniqueness if several non-cooperating organizations are generating OUIS with u=1?) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From despres.remi@laposte.net Sat Feb 2 07:52: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 00F9B21F84E0 for ; Sat, 2 Feb 2013 07:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9h4NcXgTqhW for ; Sat, 2 Feb 2013 07:52:11 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 719D021F84DC for ; Sat, 2 Feb 2013 07:52:11 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id ABEA970000B3; Sat, 2 Feb 2013 16:52:10 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 89E1F70000AC; Sat, 2 Feb 2013 16:52:10 +0100 (CET) X-SFR-UUID: 20130202155210564.89E1F70000AC@msfrf2221.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510D1877.9020209@globis.net> Date: Sat, 2 Feb 2013 16:52:11 +0100 Message-Id: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> <510D1877.9020209@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Brian Haberman , Bob Hinden 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, 02 Feb 2013 15:52:18 -0000 Le 2013-02-02 =E0 14:45, Ray Hunter a =E9crit : ... >> In any case, and more important in my understanding, this doesn't = change that any IID having u=3D1 can never conflict with IEEE-derived = IIDs, be they duplicated or not. A clarification on this would IMHO be = useful. >=20 > I have a problem with any assumption that u=3D1 =3D> global = uniqueness, or > u=3D1 =3D> IEEE EUI64 with IEEE administered OUI. >=20 > Carefully reading RFC4291 I come up with the following: >=20 > Quote: "Modified EUI-64 format-based interface identifiers may have > universal > scope when derived from a universal token (e.g., IEEE 802 48-bit MAC > or IEEE EUI-64 identifiers [EUI64])" >=20 > Note the "may" and note the "e.g." This is OK because RFC 4291 says "For ALL UNICAST ADDRESSES, except = those that start with the binary value 000, Interface IDs are required = to be 64 bits long and to be constructed in Modified EUI-64 format" = (upper-cases added).=20 This implies that IIDs that have u=3D0 belong to those that have the = "Modified EUI-64 format". >=20 > Quote: "EUI64 *format*" >=20 > Note the complete absence of text like "when u=3D1, the IID = SHOULD/MUST be > formed from an IEEE EUI64, including a globally unique OUI portion > administered by the IEEE." The point is that it is the opposite that is said: EUI-64 derived IIDs = are NOT the only ones having the "Modified EUI-64 format" (see above).=20= > I therefore openly question any assumptions regarding the IEEE as = being > defined as the sole and exclusive source of "universal tokens" in the > IPv6 addressing architecture. Agreement on this. =20 > If another standards body built a link technology based on EUI64 > *format* identifiers, but with their own OUI administration, that = should > never be a problem for IPv6, because RFC4291 only requires IID's to be > "unique within a subnet prefix." They are not required to be globally > unique across all link technologies. This is backed up by another = quote > from RFC4291: "The details of forming interface identifiers are = defined > in the appropriate "IPv6 over " specification" Yes, but nay other link technology (none is defined so far AFAIK) would = have to comply with what RFC 4291 says "Modified EUI-64 format-based = interface identifiers may have universal scope when derived from a = universal token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers". The "e.g." in this sentence implies that significance of the u bit isn't = limited to EUI-64 derived IIDs. > Even the IEEE definition of EUI64 in > http://standards.ieee.org/develop/regauth/tut/eui64.pdf states >=20 > Quote "When an EUI-64 is used within the context of an IEEE standard, > the standard shall be reviewed by the IEEE RAC for correctness and > clarity. When an EUI-64 is referenced within non-IEEE standards, there > shall not be any reference to IEEE unless approved by the IEEE RAC." >=20 > Was this coupling of standards ever reviewed by the IEEE? This has no implication on universally reserved IID structures of the = future, provided they have u=3D1 and are unambiguously distinguishable = from that EUI-64 derived IIDs. > Because it seems to me that the lack of universally clear handling of > the u=3D1 g=3D1 case in IETF documents would not fit with the existing = IEEE > definition of EUI64, where u=3D1 g=3D1 is clearly a globally = administered > multicast address, and is not available for any other use. Misunderstanding. U=3Dg=3D1 does remain AVAILABLE for new IID structures because multicast = addresses you refer to aren't concerned with the Modified EUI-64 format.=20= They have 112-bit Group IDs as opposed to 64-bit Interface IDs (refs. = https://tools.ietf.org/html/rfc4291#section-2.7) and = https://tools.ietf.org/html/rfc4291#section-2.5).=20 > So my conclusion is that any coupling between IEEE and IETF standards > should be weak at most, and also limited to individual links. Limited to links, YES. Weak, NO REASON. Regards, RD From jmh@joelhalpern.com Sat Feb 2 09:18:24 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 D36A121F8473 for ; Sat, 2 Feb 2013 09:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7nI0WjyRtpZ for ; Sat, 2 Feb 2013 09:18:24 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 603D021F86A8 for ; Sat, 2 Feb 2013 09:18:24 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 22459557FD5 for ; Sat, 2 Feb 2013 09:18:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 813A41BD56C2; Sat, 2 Feb 2013 09:18:22 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B45C01BD56B9; Sat, 2 Feb 2013 09:18:15 -0800 (PST) Message-ID: <510D4A3B.6000509@joelhalpern.com> Date: Sat, 02 Feb 2013 12:17:47 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> In-Reply-To: <510CCFE4.6090506@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont , 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: Sat, 02 Feb 2013 17:18:25 -0000 I a not clear what aspect of the semantics of u==1 and the relationship to EUI-64 is a dead duck. Currently, if you see something with u==1, you know it was made from an EUI-64. Under your proposal, you would not know that. Yous tae below tat the presence of ==1 doesn't mean that. to the best of my knowledge, currently, it does mean that. It may not be derived from the EUI-64 of the interface yo want to reach, but it is derived from an EUI-64. Otherwise, u would be set to 0. You are proposing to change this rule. Aside from anything else, I do not see a motivation for changing the rule. I have no problem with clarifying under-specified corner cases. But why change the rule we have? Is there a problem with the current rule that I am missing? Yours, Joel On 2/2/2013 3:35 AM, Brian E Carpenter wrote: > Joel, > > On 02/02/2013 00:41, Joel M. Halpern wrote: >> With regard to section 3, I would ask the question in the reverse. >> (which may actually be the same quewstion Fernando is asking.) >> >> If we assume that there is value in being able to perform the diagnostic >> operation described, then it seems that one needs to be able to tell >> when it can be applied. >> Currently, that is u==1 in the IID field. >> The text says that u==1 must be used n the IID field for IIDs derived >> from EUI-64. >> But it the goes on to say that u=1 can be used by other addresses. >> If u=1 can be used by addresses not derived from EUI-64, then the >> diagnostic operation can not be applied without a-priori knowledge. >> And in the presence of such knowledge, the u bit does not seem to help. > > Correct. Semantically, it's a dead duck. That's already true, whatever > words are written in RFCs - the fact that u=1 does not prove the IID > comes from a MAC address with u=0, and vice versa. > >> The obvious answer is that to enable the diagnostic, and because there >> is no need to make a gratuitous change, we stick with u=1 being used >> always and only for addresses derived from EUI-64. > > But that doesn't mean that the IID was derived from a MAC address, > so its value is limited. > >> The other alternative I can understand, although I do not favor it, is >> to not allow the diagnostic at all. > > The alternative is what we have today: *assume* that an IID that looks > as if it came from a MAC address in fact did so. > > Brian > >> >> Yours, >> Joel >> >> On 2/1/2013 3:13 PM, Fernando Gont wrote: >> >>> Section 3: >>>> It should be noted that IIDs known or guessed to have been created >>>> according to RFC 4941 could be transformed back into MAC addresses, >>>> for example during fault diagnosis. For that reason, keeping the >>>> "u" >>>> and "g" bits in the IID has operational value. Therefore, the >>>> EUI-64 >>>> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >>>> cases where an IID is derived from a MAC address. >>> >>> How can you tell whether an IID was really derived from a MAC address, >>> or you just had pretty bad luck with your IID randomization -- such tha >>> it *looks* like derived form a mac address? >>> >>> Thanks! >>> >>> Cheers, >>> >> > From v6ops@globis.net Sat Feb 2 09:58: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 4D26021F85D9 for ; Sat, 2 Feb 2013 09:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBEUNdF2j9Ge for ; Sat, 2 Feb 2013 09:58:55 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9B28321F85C2 for ; Sat, 2 Feb 2013 09:58:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C48C78700C7; Sat, 2 Feb 2013 18:48:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 Ex2KCe9ETJfQ; Sat, 2 Feb 2013 18:48:08 +0100 (CET) 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 58D37870081; Sat, 2 Feb 2013 18:48:08 +0100 (CET) Message-ID: <510D5152.5080808@globis.net> Date: Sat, 02 Feb 2013 18:48:02 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> <510D1877.9020209@globis.net> <510D2D8F.4090805@si6networks.com> In-Reply-To: <510D2D8F.4090805@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 6man 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: Sat, 02 Feb 2013 17:58:56 -0000 > Fernando Gont > 2 February 2013 16:15 > > How could you possible ensure such uniqueness without coordination? > (i.e., how can you ensure uniqueness if several non-cooperating > organizations are generating OUIS with u=1?) > > Cheers, You can't at a global/ multi-link level. But for IPv6, why should the IETF care? All RFC4291 really cares about AFAIK is that the IID acts as a tie breaker per link. It's not as though any competing LAN/Link standards are going to be sharing a single L2 network. If VMware come up with a virtual "Wizzinet" to connect virtual routers and virtual end nodes, and they coordinate the IID's to be "unique enough" per link, and they use EUI64 format addressing, but not OUI's administered by the IEEE, what's the problem? You're not going to plug a physical Ethernet cable into a virtual link. Speaking with an operational hat on, I'd rather have access to tools and protocols that can perform mapping/registration of e.g. DUID <=> L3 <=> L2 bindings, such as http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration, rather than any fixed transformations or encoding. Although it's not problem free, at least we could then concentrate on ensuring DUID uniqueness in whatever scope we were concerned about. And it covers self-generated privacy addresses too. And potentially MAC spoofing/ locally administered addresses. Rather than relying on static addressing administered by some other standards body and which is reliant on good behaviour by all participants. As I'm sure you're aware, operations are rapidly moving to virtual machines and devices, and dedicated network hardware with a burned-in interface ID is disappearing. > Ray Hunter > 2 February 2013 14:45 > Inline > > Rémi Després wrote: >> Brian, >> >> I agree that this is a good time to clarify uses of u and g bits, and support the initiative Sheng and yourself has taken. >> Comments and suggestions inline. >> >> 2013-02-01 21:13, Fernando Gont : >> >>> Hi, Brian & Sheng, >>> >>> On 02/01/2013 05:13 AM, Brian E Carpenter wrote: >>>> We've put this together to address the general question of the >>>> u/g bits in Interface IDs. Discussion is requested. >>> Some comments: >>> >>> >>> Section 1: >>> >>> >>>> The specification assumes that that the normal case is to transform >>>> an Ethernet-style address into an IID, preserving the semantics of >>>> two bits in particular: > Right. "Normal case." Not "exclusive case." >>>> o The "u" bit in an IEEE address is set to 0 to indicate universal >>>> scope (implying uniqueness) or to 1 to indicate local scope >>>> (without implying uniqueness). In an IID this bit is inverted, >>>> i.e., 1 for universal scope and 0 for local scope. According to >>>> [RFC5342], the reason for this was "to make it easier for network >>>> operators to type in local-scope identifiers". >>>> o The "g" bit in an IEEE address is set to 1 to indicate group >>>> addressing (link-layer multicast). This value is supposed to be >>>> preserved in an IID. >>> The second bullet is not tru: e.g. temp addresses do not do anything to >>> preserve the "g" bit (the "u" bit *is* forced to 0, though); >>> Section 2: >>> >>>> NOTE IN DRAFT: Are there other examples we should include? Are we >>>> sure that no IID format defines semantics for u/g? >>> Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the >>> probability of collisions if your IIDs are derived from global >>> identifiers (more on this below). > This is also my interpretation. >> It completely eliminates collisions for all devices that comply with IEEE specifications, and dramatically reduces it where some vendors have reused some IEEE MAC addresses. >> If two devices have the same IEEE MAC address on a link, they have a problem at the link layer, even before having one at the IP layer, and has to be fixed. >> >> In any case, and more important in my understanding, this doesn't change that any IID having u=1 can never conflict with IEEE-derived IIDs, be they duplicated or not. A clarification on this would IMHO be useful. > > I have a problem with any assumption that u=1 => global uniqueness, or > u=1 => IEEE EUI64 with IEEE administered OUI. > > Carefully reading RFC4291 I come up with the following: > > Quote: "Modified EUI-64 format-based interface identifiers may have > universal > scope when derived from a universal token (e.g., IEEE 802 48-bit MAC > or IEEE EUI-64 identifiers [EUI64])" > > Note the "may" and note the "e.g." > > Quote: "EUI64 *format*" > > Note the complete absence of text like "when u=1, the IID SHOULD/MUST be > formed from an IEEE EUI64, including a globally unique OUI portion > administered by the IEEE." > > I therefore openly question any assumptions regarding the IEEE as being > defined as the sole and exclusive source of "universal tokens" in the > IPv6 addressing architecture. > > If another standards body built a link technology based on EUI64 > *format* identifiers, but with their own OUI administration, that should > never be a problem for IPv6, because RFC4291 only requires IID's to be > "unique within a subnet prefix." They are not required to be globally > unique across all link technologies. This is backed up by another quote > from RFC4291: "The details of forming interface identifiers are defined > in the appropriate "IPv6 over " specification" > > > Even the IEEE definition of EUI64 in > http://standards.ieee.org/develop/regauth/tut/eui64.pdf states > > Quote "When an EUI-64 is used within the context of an IEEE standard, > the standard shall be reviewed by the IEEE RAC for correctness and > clarity. When an EUI-64 is referenced within non-IEEE standards, there > shall not be any reference to IEEE unless approved by the IEEE RAC." > > Was this coupling of standards ever reviewed by the IEEE? > > Because it seems to me that the lack of universally clear handling of > the u=1 g=1 case in IETF documents would not fit with the existing IEEE > definition of EUI64, where u=1 g=1 is clearly a globally administered > multicast address, and is not available for any other use. > > > > So my conclusion is that any coupling between IEEE and IETF standards > should be weak at most, and also limited to individual links. > >>> Section 2, page 4: >>>> "The use of the universal/local bit in the Modified EUI-64 format >>>> identifier is to allow development of future technology that can take >>>> advantage of interface identifiers with universal scope." >> (*) >> >>> This seems to assume that the namespace (Identifiers) of two different >>> technologies does not overlap. Such assumption sounds like dubious to >>> me... but I might be missing something. >> AFAIK, it means that *if u= the structure of other bits has to be universally specified. This is used so far for IEEE-derived IIDs. It can advantageously be used for other technologies, as foreseen in RFC4291 itself. 4rd is just the first proposed new use. >> >> >>> i.e. some non-IEEE technology is expected to obey the u/g bits? >> - For all addresses subject to SLAAC, all IETF technologies are constrained by the u-bit meaning of RFC4291. If u= all other bits have no recognizable structure; if u if all other bits have a recognizable > > >> - For addresses that aren't subject to SLAAC like, for instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't applicable. A clarification on this would IMHO be useful. >> >> >> Now, a new point: >> The sentence of RFC 4291 about future technologies ((*) above) is, in my understanding and if taken rigorously, less open than it can be concerning future technologies. It is sufficient that IIDs of new technologies using u=have a universally recognizable structure. There IID scopes can have a non-universal scope without breaking anything. Your draft can be a place to clarify this. >> >> Note that this point is made in general, as a contribution to clarify the u/g issue, not because it would concern 4rd. IIDs of 4rd are universally unique (each one contains a globally unique IPv4 address, plus a CNP field which has different values for all CEs that share this address). >> >> >>> Section 3: >>>> It should be noted that IIDs known or guessed to have been created >>>> according to RFC 4941 could be transformed back into MAC addresses, >>>> for example during fault diagnosis. For that reason, keeping the "u" >>>> and "g" bits in the IID has operational value. Therefore, the EUI-64 >>>> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >>>> cases where an IID is derived from a MAC address. >>> How can you tell whether an IID was really derived from a MAC address, >>> or you just had pretty bad luck with your IID randomization -- such tha >>> it *looks* like derived form a mac address? >> All currently specified randomizations concern IIDs that have u= None can conflict with formats specified for u=1 IIDs. >> >> Regards, >> RD >> >> >> >>> Thanks! >>> >>> Cheers, >>> -- >>> 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 ietf@rozanak.com Sat Feb 2 13:41: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 06E1621F8584 for ; Sat, 2 Feb 2013 13:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZXNVN5rolNk for ; Sat, 2 Feb 2013 13:41:55 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 021D421F8576 for ; Sat, 2 Feb 2013 13:41:55 -0800 (PST) Received: from kopoli (g225091013.adsl.alicedsl.de [92.225.91.13]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M4nob-1UtK1m3FJV-00zLno; Sat, 02 Feb 2013 16:41:52 -0500 From: "Hosnieh Rafiee" To: "'Karl Auer'" References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> <1359806574.6652.97.camel@karl> In-Reply-To: <1359806574.6652.97.camel@karl> Subject: RE: I-D action : draft-rafiee-6man-ssas-01 Date: Sat, 2 Feb 2013 22:41:42 +0100 Message-ID: <000101ce018e$1ab13d10$5013b730$@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: AQE0N4uUb+l+l5FmUNpdXfZEOh59LgHnPolUmYtKwMA= Content-Language: en-us X-Provags-ID: V02:K0:z1/u41L8zwVuTAX1LcVxtNqPx4+N988LXx0PSQHhqjf ZjGaI/JNdbJcJDUQxEYjYnU7G2HXkmoP4CJzCnUznSKkEnVFh/ gjwp3E7H9ZsV3zCG7E+kvfxNyKZmAcbelJIX45S5aSixHJnYft XbwEepeMImGJQ+Td0i6/J8/MQf0ETsaLm67ISdqPe/eyqNujx/ EiCFYIlmHz7+qXmC5YWJ7gTHW/ZHke33HnrLMBqBihzH0v6XIH TZ37fnVu9kZ1jWEmUkSktmyNir4csReRTpW5ixI+NLqD85Kby8 73keVoMFn5ysW52q1IaKHndHKwYcs0WIDTwR6HIbg3q5KmP91o B8y1CqnWQWrwORUeGf6s= 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: Sat, 02 Feb 2013 21:41:56 -0000 Thanks for your comments. Please find my responses inline. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Karl Auer Sent: Saturday, February 02, 2013 1:03 PM To: ipv6@ietf.org Subject: Re: I-D action : draft-rafiee-6man-ssas-01 > http://tools.ietf.org/html/draft-rafiee-6man-ssas-01 >In the Abstract: I don't think the word "organitionally" exists. If it does it is so unusual that it should be replaced with a more common word or with a description of what the word means. Ok, I will correct it in next version. Maybe I created a new English word... who knows ;-) How about "organizationally"? > CGA were not designed to address privacy related attacks, they are a means of securing NDP exchanges. The fact that they appear random is coincidental to their function. It is true that the main purpose was security, but it is not true that privacy was not a consideration. You can find in many parts of the CGA RFC (RFC 3972) where privacy is also mentioned. Some such sections are section 3, where it explains that the reason for the addition of a modifier is to enhance privacy by adding randomness to the address and at the end of section 4 and in section 7.3 where privacy considerations are clearly explained. >Introduction: Either always use leading zeros in your example values, or never, but don't mix them. I suggest that always using leading zeros would be better. Good point. I will do this. >MAC should always be capitalised: "MAC", not "Mac", throughout. Will correct this in the next version. >In your description of how an EUI-64 IID is formed, you have omitted the need to complement bit7 of the IID. You mean bits u and g (both 7 and 8). I'll add it. Of course these two bits are a matter for discussion in Brian's draft :-) >The introduction repeats the error in the abstract, that CGA addresses are "used to randomize the IID". In RFC Privacy Extension (section 3.2.3) and also CGA RFC (in stated sections), it also mentioned CGA as an approach to randomize IID >There are places where necessary spaces have been omitted: >"[RFC3315]can", "approachfor". The problem of my "spacebar" in keyboard, sometimes doesn't work and.... thx. I'll fix it in next version >The sentence beginning "This convention..." is unnecessary. I'll remove it >In the problem statement, the second sentence should read "...easy for an attacker to track that node as it moves between networks." Or similar, but it is unclear as it stands. Yes true. I'll update it. >"If one wants to use a secure method, with the privacy extension, then one needs to use CGA." Can one use CGA with privacy addressing? That is, can you have CGA addresses that change regularly, as privacy addresses do? I'm not sure. Yes you can. Please see my first response. > Spell check everything ("Deniel of Service", "deminished", etc) Ops... Ok, I'll correct it in next version. >"In order to overcome the problem with the other mechanisms,[...]" What other mechanisms? Isn't this just a problem with CGA? True, maybe I will have to rephrase the sentence. I wanted to address both privacy related attacks (privacy extension RFC) and also the problem with CGA. >"the time is needed to generate and verify IP address needs to be decreased" -> "the time required to generate and verify IP addresses needs to be reduced" >In 2.1.1.3 there is an odd character in "victim?s", should be "victim's". The same odd character appears in other places. ? will be replaced with ' . > In 2.1.1.3 suggest that the first SHOULD should be MAY. I'll correct it. >In 2.1.1.3, it is unclear whether the formula is provided as a helpful hint, or whether this is the formula that should be used. Why a 2-minute window? I suggest using language similar to other RFCs in >similar situations, e.g. "To mitigate such an attack, a node SHOULD rate limit message verification. Implementations MUST provide a conservative default and SHOULD provide a way for the rate >limiting parameters to be set by the node administrator." Good suggestion! I will apply it. >2.1.2 should provide an explanation of why SSAS is helpful in nodes with limited resources. It appears that it is not helpful per se, but is helpful *in comparison to CGA*, because of the lower >computational load. >An explanation is also needed for why SSAS is useful in mobile networks. I will clarify this section. >In the first para of section 3: Compute load is only a problem with CGA. >Privacy is only a problem with SLAAC (and maybe with CGA if a node uses the same 64-bit CGA IID on multiple networks). This introductory paragraph seems to just restate what has already been said >elsewhere and could probably be dropped anyway. Ok I will correct it. >3.1 step 2: There is no need to specify XML or any other particular storage method, format or location. These can be left to the implementation. All that is necessary is that these items be stored where >they will survive for the length of time a particular key pair will be in use. You need to address the situation where a node has no such storage. I think I really saw it from the implementers' point of view. You are right. I will change it. >3.1 step 2 second para: The use of should and SHOULD is confusing. >Should a node generate new keys? If it does, should it use them? If it isn't going to use them, why generate them? What happens when a new address is generated - is it used alongside the old one or >are current connections using the old address dropped immediately? The loss of active connections when an address changes might be worth mentioning somewhere. The old IP address status is changed to deprecated. This means the node will not use it for the new connection but it can continue using it for the old connections. When the node generates a new IP address, it should also re-generate public/private keys because of the privacy concerns. > 3.1 step 2: Either the encryption algorithms used must be stipulated, or there must be some mechanism for the verifier to know what method was used by the sender. I will add a bit to the SSAS data structure in order to distinguish between RSA and ECC or other faster algorithms of the future. > 3.1 step 3: What is "a fixed point format"? Needs explanation. If there is more than one possible "fixed point format" then the specific one used by SSAS must be specified. I explained in the draft that we are using the same format as RFC SEND. > 3.1 step 5: Why is a whole byte needed to store a value from 0 to 20? >Have you done the maths to check that this value will actually meaningfully "[help] randomize the IID and [...] minimize the chance of a collision in the network"? If the benefit is not significant, then >this step should be omitted. Yes , it does. >3.1 step 10 "this IP will be permanent after..." This contradicts earlier recommendations that the IP be changed after a certain period. I meant the status of the IP address. The first status will be temporary and if no collisions are found the status will change to permanent. The 3 statuses for an IP address are deprecated, temporary and permanent. This defines how the IP address can be used at the start of new connections or its use in existing connections. Each IP address has a lifetime. When the lifetime of the IP address has expired, the node changes the status of the IP address to deprecated. I will add the status and add this explanation to the new version. >3.2 This needs to be clearer. It seems that you are describing the components of the NDP message that will be signed, not items that will actually be included in the signature. Either way, it seems to me >that a list of components should be provided for each NDP message type that requires signing, with a default to cover all others and any that have not yet been invented. True. Maybe instead of NDP, I have to change it to SEND. Then it might be clearer. > 3.3 How does a recipient know whether a message is SEND+SSAS or just SEND? In SSAS, just the RSA signature is different than the RSA signature section of SEND. I will think about using another type, like type=16, for SSAS Data field (signature and...). >3.3.1: Length is described as including certain fields; the description does NOT include certain other fields, such as subnet prefix, other options. It seems to me that length can simply be described as >"the length of the signature data field". Might be an idea to specify the units, eg "length in octets". Good suggestion. >3.3.1 Padding would be more simply described by saying that "if the above values do not form an SSAS signature field that is an exact multiple of eight octets long, random octets are added to the end >of the signature field to bring its length up to an exact multiple of eight octets." Or octets with the binary value zero, or whatever. Good suggestion. >3.3.1: "If, for a second time, the node receives the same claim, then it considers it an attack and will use that IP address." Why? And why two? >Is this because no two nodes should ever be able to generate the same address? If so, then either one try is sufficient, or arbitrarily many will be insufficient. There have been no proven collisions using SHA256. Also, it will be a very rare case when two nodes choose the same modifier and even rarer If, after a node increments the modifier after the first collision, another node will have the IP address. > 4: This seems to need a bit of bulking out. Also, the discussion of trust anchors is unclear - what, if any, place do trust anchors have in SSAS? Might be worth discussing how shorter key validity periods > affect the likelihood of a successful attack. I will clarify the section describing trust anchors. About successful attacks, in practice, it is not like theoretical proofs; the probability is very low. I obtained that mathematical proof by finding the expected value for 2 days, 10 days, and also 20 days... . >5. Is that an IAN consideration? It might be. >6. This section repeats the error that CGA is about randomising IIDs. It is not, that's a side effect at best. Please refer to my first response Thank you. I really cannot understand how I made so many spelling mistakes, especially when I had a text correctors in front of me... :-/ or perhaps sleepy!? Hosnieh From brian.e.carpenter@gmail.com Sun Feb 3 00:20: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 88AD621F854C for ; Sun, 3 Feb 2013 00:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.76 X-Spam-Level: X-Spam-Status: No, score=-99.76 tagged_above=-999 required=5 tests=[AWL=-0.839, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYMYAWLh6pSS for ; Sun, 3 Feb 2013 00:20:06 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B942F21F8459 for ; Sun, 3 Feb 2013 00:20:05 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id x43so3960119wey.38 for ; Sun, 03 Feb 2013 00:20:04 -0800 (PST) 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=Z/OA/lDYsEHYjTFqG9Ga1YSNmsEHNDGQx8F6z7NeSJc=; b=iP9sPTTced4ysaMAnhK5OR84GuYtQEa0oRSnyAG2DAMdifyL8IvfrwGPf0KhuksWXM b2jV2GyGccpemWjN37ddU0h3Q+Vjzb+16kcmk6Xqdrddto0CGI8Iw0sLrDtKG4iX8aUM ADLIPcN6zZx11qNk32uaB32tokZHtXHPapHLF/qQiLM47opsD2t9B9/lPUxUc31lTxwb tHCmq5t0wL8e0+twvltaiDNTUC/85qLUr+qGZjRocguyBhZ5EngLWmcIXaEUWd4pTkxp FYOVBz+zTG4k/u5Gr9LD8PpOVURwthbb/weByoQW6ZWHuIl8N6BjROFSlu8/HiCw2u53 smdw== X-Received: by 10.181.13.195 with SMTP id fa3mr5030399wid.8.1359879604611; Sun, 03 Feb 2013 00:20:04 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-151.as13285.net. [2.102.218.151]) by mx.google.com with ESMTPS id cu7sm13152107wib.8.2013.02.03.00.20.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 00:20:03 -0800 (PST) Message-ID: <510E1DB2.7070106@gmail.com> Date: Sun, 03 Feb 2013 08:20:02 +0000 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: I-D action : draft-rafiee-6man-ssas-01 References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> <1359806574.6652.97.camel@karl> <000101ce018e$1ab13d10$5013b730$@rozanak.com> In-Reply-To: <000101ce018e$1ab13d10$5013b730$@rozanak.com> 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: Sun, 03 Feb 2013 08:20:06 -0000 On 02/02/2013 21:41, Hosnieh Rafiee wrote: > Thanks for your comments. Please find my responses inline. > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Karl > Auer ... >> In your description of how an EUI-64 IID is formed, you have omitted the > need to complement bit7 of the IID. > > You mean bits u and g (both 7 and 8). I'll add it. Of course these two bits > are a matter for discussion in Brian's draft :-) Only the u bit is complemented, the g bit is untouched. In any case, draft-carpenter-6man-ug doesn't change or abolish this. Brian From brian.e.carpenter@gmail.com Sun Feb 3 00:24: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 A907B21F8464 for ; Sun, 3 Feb 2013 00:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.816 X-Spam-Level: X-Spam-Status: No, score=-100.816 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATCkwY4-5fJx for ; Sun, 3 Feb 2013 00:24:56 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2921F8459 for ; Sun, 3 Feb 2013 00:24:56 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so649155wib.9 for ; Sun, 03 Feb 2013 00:24:55 -0800 (PST) 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=uJl71pHwe+XaX/6hPI75MuPJE6gHii2PS8zzhxOxzx8=; b=VB+Ju27jNw85BjmnVRpV1YpMiGLMG5vmfQs3QclX9mRwJK3Udq8XvsC+hiTKnZ3T5B 0I4vpsz+elb9it+SGiv60kym2q8xuKPQonmuJ+IlONHqpAcwzKDPWalfwP3MqXkeZZbS Npkhng07237MOJA7wBLDBCHl3HxdBaRgUkpQzuzjCBVE2CssBDQA9FApQSx1cpCi3eP1 UqpQcD83dgqSvgI17jzFfKd/7Y51k3jzcRQGsT061PkU9zHX+9IDMAoa4BhytVAD7FoE tbWk1ZVRcdixIMa0b3pPyKcd93rU2V+JPNVMYgoG2TCwV91SltQh0DatzD8vV4hgHR41 MGhA== X-Received: by 10.180.82.65 with SMTP id g1mr5082085wiy.22.1359879895276; Sun, 03 Feb 2013 00:24:55 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-151.as13285.net. [2.102.218.151]) by mx.google.com with ESMTPS id ge2sm13187362wib.4.2013.02.03.00.24.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 00:24:54 -0800 (PST) Message-ID: <510E1ED5.7040705@gmail.com> Date: Sun, 03 Feb 2013 08:24:53 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> <510D1877.9020209@globis.net> <510D2D8F.4090805@si6networks.com> <510D5152.5080808@globis.net> In-Reply-To: <510D5152.5080808@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , 6man 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: Sun, 03 Feb 2013 08:24:57 -0000 On 02/02/2013 17:48, Ray Hunter wrote: >> Fernando Gont >> 2 February 2013 16:15 >> >> How could you possible ensure such uniqueness without coordination? >> (i.e., how can you ensure uniqueness if several non-cooperating >> organizations are generating OUIS with u=3D1?) >> >> Cheers, > You can't at a global/ multi-link level. But for IPv6, why should the > IETF care? All RFC4291 really cares about AFAIK is that the IID acts as= > a tie breaker per link.=20 Only because it's supported by DAD, surely? There is no piece of magic that absolutely prevents two hosts claiming the same IID. Brian > It's not as though any competing LAN/Link > standards are going to be sharing a single L2 network. >=20 > If VMware come up with a virtual "Wizzinet" to connect virtual routers > and virtual end nodes, and they coordinate the IID's to be "unique > enough" per link, and they use EUI64 format addressing, but not OUI's > administered by the IEEE, what's the problem? You're not going to plug = a > physical Ethernet cable into a virtual link. >=20 > Speaking with an operational hat on, I'd rather have access to tools an= d > protocols that can perform mapping/registration of e.g. DUID <=3D> L3 <= =3D> > L2 bindings, such as > http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration, rathe= r > than any fixed transformations or encoding. Although it's not problem > free, at least we could then concentrate on ensuring DUID uniqueness in= > whatever scope we were concerned about. And it covers self-generated > privacy addresses too. And potentially MAC spoofing/ locally > administered addresses. Rather than relying on static addressing > administered by some other standards body and which is reliant on good > behaviour by all participants. As I'm sure you're aware, operations are= > rapidly moving to virtual machines and devices, and dedicated network > hardware with a burned-in interface ID is disappearing. >=20 >> Ray Hunter >> 2 February 2013 14:45 >> Inline >> >> R=C3=A9mi Despr=C3=A9s wrote: >>> Brian, >>> >>> I agree that this is a good time to clarify uses of u and g bits, and= support the initiative Sheng and yourself has taken. >>> Comments and suggestions inline. >>> >>> 2013-02-01 21:13, Fernando Gont : >>> >>>> Hi, Brian & Sheng, >>>> >>>> On 02/01/2013 05:13 AM, Brian E Carpenter wrote: >>>>> We've put this together to address the general question of the >>>>> u/g bits in Interface IDs. Discussion is requested. >>>> Some comments: >>>> >>>> >>>> Section 1: >>>> >>>> >>>>> The specification assumes that that the normal case is to transfo= rm >>>>> an Ethernet-style address into an IID, preserving the semantics o= f >>>>> two bits in particular: >> Right. "Normal case." Not "exclusive case." >>>>> o The "u" bit in an IEEE address is set to 0 to indicate univers= al >>>>> scope (implying uniqueness) or to 1 to indicate local scope >>>>> (without implying uniqueness). In an IID this bit is inverted= , >>>>> i.e., 1 for universal scope and 0 for local scope. According = to >>>>> [RFC5342], the reason for this was "to make it easier for netw= ork >>>>> operators to type in local-scope identifiers". >>>>> o The "g" bit in an IEEE address is set to 1 to indicate group >>>>> addressing (link-layer multicast). This value is supposed to = be >>>>> preserved in an IID. >>>> The second bullet is not tru: e.g. temp addresses do not do anything= to >>>> preserve the "g" bit (the "u" bit *is* forced to 0, though); >>>> Section 2: >>>> >>>>> NOTE IN DRAFT: Are there other examples we should include? Are w= e >>>>> sure that no IID format defines semantics for u/g? >>>> Not that I'm aware of. -- AFAIK, the u bit is just used to reduce th= e >>>> probability of collisions if your IIDs are derived from global >>>> identifiers (more on this below). >> This is also my interpretation. >>> It completely eliminates collisions for all devices that comply with = IEEE specifications, and dramatically reduces it where some vendors have = reused some IEEE MAC addresses. >>> If two devices have the same IEEE MAC address on a link, they have a = problem at the link layer, even before having one at the IP layer, and ha= s to be fixed.=20 >>> >>> In any case, and more important in my understanding, this doesn't cha= nge that any IID having u=3D1 can never conflict with IEEE-derived IIDs, = be they duplicated or not. A clarification on this would IMHO be useful. >> I have a problem with any assumption that u=3D1 =3D> global uniqueness= , or >> u=3D1 =3D> IEEE EUI64 with IEEE administered OUI. >> >> Carefully reading RFC4291 I come up with the following: >> >> Quote: "Modified EUI-64 format-based interface identifiers may have >> universal >> scope when derived from a universal token (e.g., IEEE 802 48-bit MA= C >> or IEEE EUI-64 identifiers [EUI64])" >> >> Note the "may" and note the "e.g." >> >> Quote: "EUI64 *format*" >> >> Note the complete absence of text like "when u=3D1, the IID SHOULD/MUS= T be >> formed from an IEEE EUI64, including a globally unique OUI portion >> administered by the IEEE." >> >> I therefore openly question any assumptions regarding the IEEE as bein= g >> defined as the sole and exclusive source of "universal tokens" in the >> IPv6 addressing architecture. >> >> If another standards body built a link technology based on EUI64 >> *format* identifiers, but with their own OUI administration, that shou= ld >> never be a problem for IPv6, because RFC4291 only requires IID's to be= >> "unique within a subnet prefix." They are not required to be globally >> unique across all link technologies. This is backed up by another quot= e >> from RFC4291: "The details of forming interface identifiers are define= d >> in the appropriate "IPv6 over " specification" >> >> >> Even the IEEE definition of EUI64 in >> http://standards.ieee.org/develop/regauth/tut/eui64.pdf states >> >> Quote "When an EUI-64 is used within the context of an IEEE standard, >> the standard shall be reviewed by the IEEE RAC for correctness and >> clarity. When an EUI-64 is referenced within non-IEEE standards, there= >> shall not be any reference to IEEE unless approved by the IEEE RAC." >> >> Was this coupling of standards ever reviewed by the IEEE? >> >> Because it seems to me that the lack of universally clear handling of >> the u=3D1 g=3D1 case in IETF documents would not fit with the existing= IEEE >> definition of EUI64, where u=3D1 g=3D1 is clearly a globally administe= red >> multicast address, and is not available for any other use. >> >> >> >> So my conclusion is that any coupling between IEEE and IETF standards >> should be weak at most, and also limited to individual links. >> =20 >>>> Section 2, page 4: >>>>> "The use of the universal/local bit in the Modified EUI-64 format >>>>> identifier is to allow development of future technology that can = take >>>>> advantage of interface identifiers with universal scope." >>> (*) >>> >>>> This seems to assume that the namespace (Identifiers) of two differe= nt >>>> technologies does not overlap. Such assumption sounds like dubious t= o >>>> me... but I might be missing something. >>> AFAIK, it means that *if u=3D the structure of other bits has to be u= niversally specified. This is used so far for IEEE-derived IIDs. It can a= dvantageously be used for other technologies, as foreseen in RFC4291 itse= lf. 4rd is just the first proposed new use. >>> >>> >>>> i.e. some non-IEEE technology is expected to obey the u/g bits? >>> - For all addresses subject to SLAAC, all IETF technologies are const= rained by the u-bit meaning of RFC4291. If u=3D all other bits have no re= cognizable structure; if u=11 if all other bits have a recognizable=20 >> >>> - For addresses that aren't subject to SLAAC like, for instance, thos= e of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn= 't applicable. A clarification on this would IMHO be useful. >>> >>> >>> Now, a new point: >>> The sentence of RFC 4291 about future technologies ((*) above) is, in= my understanding and if taken rigorously, less open than it can be conce= rning future technologies. It is sufficient that IIDs of new technologies= using u=3Dhave a universally recognizable structure. There IID scopes ca= n have a non-universal scope without breaking anything. Your draft can be= a place to clarify this. >>> >>> Note that this point is made in general, as a contribution to clarify= the u/g issue, not because it would concern 4rd. IIDs of 4rd are univer= sally unique (each one contains a globally unique IPv4 address, plus a CN= P field which has different values for all CEs that share this address). >>> =20 >>> >>>> Section 3: >>>>> It should be noted that IIDs known or guessed to have been create= d >>>>> according to RFC 4941 could be transformed back into MAC addresse= s, >>>>> for example during fault diagnosis. For that reason, keeping the= "u" >>>>> and "g" bits in the IID has operational value. Therefore, the EU= I-64 >>>>> to IPv6 IID transformation defined in RFC 4941 MUST be used for a= ll >>>>> cases where an IID is derived from a MAC address. >>>> How can you tell whether an IID was really derived from a MAC addres= s, >>>> or you just had pretty bad luck with your IID randomization -- such = tha >>>> it *looks* like derived form a mac address? >>> All currently specified randomizations concern IIDs that have u=3D No= ne can conflict with formats specified for u=3D1 IIDs. >>> >>> Regards, >>> RD >>> >>> >>> >>>> Thanks! >>>> >>>> Cheers, >>>> --=20 >>>> 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 >>>> --------------------------------------------------------------------= >> ----------------------------------------------------------------------= -- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From brian.e.carpenter@gmail.com Sun Feb 3 00:41: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 26D4A21F8432 for ; Sun, 3 Feb 2013 00:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.125 X-Spam-Level: X-Spam-Status: No, score=-101.125 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNt6cSgW2eIO for ; Sun, 3 Feb 2013 00:41:17 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 07A6E21F86AA for ; Sun, 3 Feb 2013 00:41:16 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn17so653667wib.10 for ; Sun, 03 Feb 2013 00:41:16 -0800 (PST) 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=AOwYbygLVI5SKFniCpD2rRlmOctzG/t0h2VetxPocV8=; b=cnj3hKflvQKK8GmdMcxbMxYvldncrMGHSSG++Ubt6vXkZh78mkw/NGSD7duk67QvaK TAejGdKDqoVhpkz0q0fUencBo+1iRMAUWa98oDbxtoe5Y+B7p9N6ClxrnK76ntrnDeH7 ZwpPEnNWa5bEelwSIyVqbOOtlpj+KsVDxiHqUn/vPEHcxGCy73lbjGjDwoaVaJeXAnAk gkFv1IWMcJOgpQdlzGAHklHfrQlVBpU5cavJeEvEbbCFrYN1faw1uXGxsfV6811Vc1SU re8h+vaT3SaFBaOAkCEc6AuS7lHEP/VqeyiL/fsu4YpiDNdDYgpdVgaVK8LM2qoVecfs tNLg== X-Received: by 10.194.90.242 with SMTP id bz18mr9755859wjb.24.1359880876242; Sun, 03 Feb 2013 00:41:16 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-151.as13285.net. [2.102.218.151]) by mx.google.com with ESMTPS id s8sm13215497wif.9.2013.02.03.00.41.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 00:41:15 -0800 (PST) Message-ID: <510E22AA.3050308@gmail.com> Date: Sun, 03 Feb 2013 08:41:14 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> In-Reply-To: <510D4A3B.6000509@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , 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, 03 Feb 2013 08:41:18 -0000 On 02/02/2013 17:17, Joel M. Halpern wrote: > I a not clear what aspect of the semantics of u==1 and the relationship > to EUI-64 is a dead duck. Currently, if you see something with u==1, > you know it was made from an EUI-64. Actually, you don't. You know that it looks as if it was made in Modified EUI-64 format, but you don't know that there is a genuine MAC address behind it. You can apply heuristics (like "Is 0xFFFE present?" and "Is the OUI an IEEE-assigned value?") but that's all. Also, u==0 does not imply that it is not Modified EUI-64. The examples in RFC 4291 all use EUI-64 with u==0, i.e. Modified EUI-64 with u==1, but those are only examples. In the end all you have is 64 meaningless bits, as far as I can tell. Brian > Under your proposal, you would not > know that. > Yous tae below tat the presence of ==1 doesn't mean that. to the best > of my knowledge, currently, it does mean that. It may not be derived > from the EUI-64 of the interface yo want to reach, but it is derived > from an EUI-64. Otherwise, u would be set to 0. > > You are proposing to change this rule. > > Aside from anything else, I do not see a motivation for changing the rule. > I have no problem with clarifying under-specified corner cases. > But why change the rule we have? Is there a problem with the current > rule that I am missing? > > Yours, > Joel > > On 2/2/2013 3:35 AM, Brian E Carpenter wrote: >> Joel, >> >> On 02/02/2013 00:41, Joel M. Halpern wrote: >>> With regard to section 3, I would ask the question in the reverse. >>> (which may actually be the same quewstion Fernando is asking.) >>> >>> If we assume that there is value in being able to perform the diagnostic >>> operation described, then it seems that one needs to be able to tell >>> when it can be applied. >>> Currently, that is u==1 in the IID field. >>> The text says that u==1 must be used n the IID field for IIDs derived >>> from EUI-64. >>> But it the goes on to say that u=1 can be used by other addresses. >>> If u=1 can be used by addresses not derived from EUI-64, then the >>> diagnostic operation can not be applied without a-priori knowledge. >>> And in the presence of such knowledge, the u bit does not seem to help. >> >> Correct. Semantically, it's a dead duck. That's already true, whatever >> words are written in RFCs - the fact that u=1 does not prove the IID >> comes from a MAC address with u=0, and vice versa. >> >>> The obvious answer is that to enable the diagnostic, and because there >>> is no need to make a gratuitous change, we stick with u=1 being used >>> always and only for addresses derived from EUI-64. >> >> But that doesn't mean that the IID was derived from a MAC address, >> so its value is limited. >> >>> The other alternative I can understand, although I do not favor it, is >>> to not allow the diagnostic at all. >> >> The alternative is what we have today: *assume* that an IID that looks >> as if it came from a MAC address in fact did so. >> >> Brian >> >>> >>> Yours, >>> Joel >>> >>> On 2/1/2013 3:13 PM, Fernando Gont wrote: >>> >>>> Section 3: >>>>> It should be noted that IIDs known or guessed to have been >>>>> created >>>>> according to RFC 4941 could be transformed back into MAC >>>>> addresses, >>>>> for example during fault diagnosis. For that reason, keeping the >>>>> "u" >>>>> and "g" bits in the IID has operational value. Therefore, the >>>>> EUI-64 >>>>> to IPv6 IID transformation defined in RFC 4941 MUST be used >>>>> for all >>>>> cases where an IID is derived from a MAC address. >>>> >>>> How can you tell whether an IID was really derived from a MAC address, >>>> or you just had pretty bad luck with your IID randomization -- such tha >>>> it *looks* like derived form a mac address? >>>> >>>> Thanks! >>>> >>>> Cheers, >>>> >>> >> > From randy@psg.com Sun Feb 3 01:46: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 31AA021F84BF for ; Sun, 3 Feb 2013 01:46:08 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-NecHWmx+jS for ; Sun, 3 Feb 2013 01:46:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0121F86F5 for ; Sun, 3 Feb 2013 01:46:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U1w9C-000PrZ-Co; Sun, 03 Feb 2013 09:46:02 +0000 Date: Sun, 03 Feb 2013 18:46:01 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] In-Reply-To: <510E22AA.3050308@gmail.com> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention 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, 03 Feb 2013 09:46:08 -0000 >> I am not clear what aspect of the semantics of u==1 and the >> relationship to EUI-64 is a dead duck. Currently, if you see >> something with u==1, you know it was made from an EUI-64. > > Actually, you don't. You know that it looks as if it was made in > Modified EUI-64 format, but you don't know that there is a genuine MAC > address behind it. You can apply heuristics (like "Is 0xFFFE present?" > and "Is the OUI an IEEE-assigned value?") but that's all. > > Also, u==0 does not imply that it is not Modified EUI-64. The examples > in RFC 4291 all use EUI-64 with u==0, i.e. Modified EUI-64 with u==1, > but those are only examples. > > In the end all you have is 64 meaningless bits, as far as I can tell. well, not entirely meaningless, eh? :) we do line packets to go back and forth. i hate to sound like a broken record, but magic bits are almost never worth the pain. randy From despres.remi@laposte.net Sun Feb 3 02:57: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 E2C1121F88A9 for ; Sun, 3 Feb 2013 02:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBqHwiRwGeqY for ; Sun, 3 Feb 2013 02:57:47 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id C881C21F8721 for ; Sun, 3 Feb 2013 02:57:46 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2213.sfr.fr (SMTP Server) with ESMTP id 7D5447000088; Sun, 3 Feb 2013 11:57:45 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2213.sfr.fr (SMTP Server) with ESMTP id DC78170000BC; Sun, 3 Feb 2013 11:57:44 +0100 (CET) X-SFR-UUID: 20130203105744903.DC78170000BC@msfrf2213.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510D4A3B.6000509@joelhalpern.com> Date: Sun, 3 Feb 2013 11:57:41 +0100 Message-Id: <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> To: Brian Carpenter X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 03 Feb 2013 10:57:48 -0000 Le 2013-02-02 =E0 18:17, Joel M. Halpern a =E9crit = : > I a not clear what aspect of the semantics of u=3D=3D1 and the = relationship to EUI-64 is a dead duck. Currently, if you see something = with u=3D=3D1, you know it was made from an EUI-64. Under your = proposal, you would not know that. > Yous tae below tat the presence of =3D=3D1 doesn't mean that. to the = best of my knowledge, currently, it does mean that. It may not be = derived from the EUI-64 of the interface yo want to reach, but it is = derived from an EUI-64. Otherwise, u would be set to 0. >=20 > You are proposing to change this rule. Same understanding. u=3D1 has a meaning that shouldn't be negated now. > Aside from anything else, I do not see a motivation for changing the = rule. The rule concerning the u=3D1 can advantageously be completed with new = uses (provided they don't conflict wit previous uses). Regards, RD > I have no problem with clarifying under-specified corner cases. > But why change the rule we have? Is there a problem with the current = rule that I am missing? >=20 > Yours, > Joel >=20 > On 2/2/2013 3:35 AM, Brian E Carpenter wrote: >> Joel, >>=20 >> On 02/02/2013 00:41, Joel M. Halpern wrote: >>> With regard to section 3, I would ask the question in the reverse. >>> (which may actually be the same quewstion Fernando is asking.) >>>=20 >>> If we assume that there is value in being able to perform the = diagnostic >>> operation described, then it seems that one needs to be able to tell >>> when it can be applied. >>> Currently, that is u=3D=3D1 in the IID field. >>> The text says that u=3D=3D1 must be used n the IID field for IIDs = derived >>> from EUI-64. >>> But it the goes on to say that u=3D1 can be used by other addresses. >>> If u=3D1 can be used by addresses not derived from EUI-64, then the >>> diagnostic operation can not be applied without a-priori knowledge. >>> And in the presence of such knowledge, the u bit does not seem to = help. >>=20 >> Correct. Semantically, it's a dead duck. That's already true, = whatever >> words are written in RFCs - the fact that u=3D1 does not prove the = IID >> comes from a MAC address with u=3D0, and vice versa. >>=20 >>> The obvious answer is that to enable the diagnostic, and because = there >>> is no need to make a gratuitous change, we stick with u=3D1 being = used >>> always and only for addresses derived from EUI-64. >>=20 >> But that doesn't mean that the IID was derived from a MAC address, >> so its value is limited. >>=20 >>> The other alternative I can understand, although I do not favor it, = is >>> to not allow the diagnostic at all. >>=20 >> The alternative is what we have today: *assume* that an IID that = looks >> as if it came from a MAC address in fact did so. >>=20 >> Brian >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 2/1/2013 3:13 PM, Fernando Gont wrote: >>>=20 >>>> Section 3: >>>>> It should be noted that IIDs known or guessed to have been = created >>>>> according to RFC 4941 could be transformed back into MAC = addresses, >>>>> for example during fault diagnosis. For that reason, keeping = the >>>>> "u" >>>>> and "g" bits in the IID has operational value. Therefore, the >>>>> EUI-64 >>>>> to IPv6 IID transformation defined in RFC 4941 MUST be used = for all >>>>> cases where an IID is derived from a MAC address. >>>>=20 >>>> How can you tell whether an IID was really derived from a MAC = address, >>>> or you just had pretty bad luck with your IID randomization -- such = tha >>>> it *looks* like derived form a mac address? >>>>=20 >>>> Thanks! >>>>=20 >>>> Cheers, >>>>=20 >>>=20 >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Sun Feb 3 03:44: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 B4FCA21F863F for ; Sun, 3 Feb 2013 03:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.967 X-Spam-Level: X-Spam-Status: No, score=-100.967 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSnz9hl+It0N for ; Sun, 3 Feb 2013 03:44:01 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA8521F863C for ; Sun, 3 Feb 2013 03:44:00 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l13so1481417wie.14 for ; Sun, 03 Feb 2013 03:43:59 -0800 (PST) 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=ow1gCkNLsLbyw9c4UJsYwDbyeEd0P+yDLxl3pfNoZt0=; b=LAPKyhMFGAeIUErshpY78YQ6V/11oK61T88eefuR0ocvbLGRwbBktG6lya3xH6ovi9 ASn1RDAA9tdgmc79jeLU/h+FLgyeSTAKP6uP2wTXhovcTQcbbHNfrJk7U8UEZJEwVV4A LnCR1JpPhUqgWn/OAF34m8l5CaxUGNMaHJoBsgiBg9oh0Z1gMU5+aPAzUswBCsSgnDUA zK7KxYalta5Lj+Z/1Qe1Z4WFhfYSEbqLl+xtY52ujTdBb78D/VSXI+XAGPJz184a98oy B/7wn+BAIh9LfYL1PermBkUwzPTMGU2hCrGqXtBv/r6n2Rh1+SvFSzfIRP2j798ITUUT fRHg== X-Received: by 10.180.77.68 with SMTP id q4mr5604044wiw.10.1359891839630; Sun, 03 Feb 2013 03:43:59 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-151.as13285.net. [2.102.218.151]) by mx.google.com with ESMTPS id j9sm7404961wia.5.2013.02.03.03.43.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 03:43:58 -0800 (PST) Message-ID: <510E4D7C.5020307@gmail.com> Date: Sun, 03 Feb 2013 11:43:56 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> In-Reply-To: <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 03 Feb 2013 11:44:01 -0000 On 03/02/2013 10:57, R=C3=A9mi Despr=C3=A9s wrote: > Le 2013-02-02 =C3=A0 18:17, Joel M. Halpern a =C3= =A9crit : >=20 >> I a not clear what aspect of the semantics of u=3D=3D1 and the relatio= nship to EUI-64 is a dead duck. Currently, if you see something with u=3D= =3D1, you know it was made from an EUI-64. Under your proposal, you woul= d not know that. >> Yous tae below tat the presence of =3D=3D1 doesn't mean that. to the = best of my knowledge, currently, it does mean that. It may not be derive= d from the EUI-64 of the interface yo want to reach, but it is derived fr= om an EUI-64. Otherwise, u would be set to 0. >> >> You are proposing to change this rule. >=20 > Same understanding. > u=3D1 has a meaning that shouldn't be negated now. >=20 >> Aside from anything else, I do not see a motivation for changing the r= ule. Actually, I don't think that is what the draft proposes. What it proposes= is that we delete the fiction that the bit has any meaning after it arriv= es in an IID. It seems to be that fiction that causes confusion, not the rule about how to generate Modified EUI-64 format from a MAC address. Quoting a wise colleague, "magic bits are almost never worth the pain." To say it again in different words, u=3D=3D1 does not prove that an IID i= s universally unique and u=3D=3D0 does not prove that an IID is locally uni= que. So it's fine to specify methods for generating the u bit, but it is incorrect to draw firm conclusions based on its value. Brian >=20 > The rule concerning the u=3D1 can advantageously be completed with new = uses (provided they don't conflict wit previous uses). >=20 > Regards, > RD >=20 >=20 >> I have no problem with clarifying under-specified corner cases. >> But why change the rule we have? Is there a problem with the current = rule that I am missing? >> >> Yours, >> Joel >> >> On 2/2/2013 3:35 AM, Brian E Carpenter wrote: >>> Joel, >>> >>> On 02/02/2013 00:41, Joel M. Halpern wrote: >>>> With regard to section 3, I would ask the question in the reverse. >>>> (which may actually be the same quewstion Fernando is asking.) >>>> >>>> If we assume that there is value in being able to perform the diagno= stic >>>> operation described, then it seems that one needs to be able to tell= >>>> when it can be applied. >>>> Currently, that is u=3D=3D1 in the IID field. >>>> The text says that u=3D=3D1 must be used n the IID field for IIDs de= rived >>>> from EUI-64. >>>> But it the goes on to say that u=3D1 can be used by other addresses.= >>>> If u=3D1 can be used by addresses not derived from EUI-64, then the >>>> diagnostic operation can not be applied without a-priori knowledge. >>>> And in the presence of such knowledge, the u bit does not seem to he= lp. >>> Correct. Semantically, it's a dead duck. That's already true, whateve= r >>> words are written in RFCs - the fact that u=3D1 does not prove the II= D >>> comes from a MAC address with u=3D0, and vice versa. >>> >>>> The obvious answer is that to enable the diagnostic, and because the= re >>>> is no need to make a gratuitous change, we stick with u=3D1 being us= ed >>>> always and only for addresses derived from EUI-64. >>> But that doesn't mean that the IID was derived from a MAC address, >>> so its value is limited. >>> >>>> The other alternative I can understand, although I do not favor it, = is >>>> to not allow the diagnostic at all. >>> The alternative is what we have today: *assume* that an IID that look= s >>> as if it came from a MAC address in fact did so. >>> >>> Brian >>> >>>> Yours, >>>> Joel >>>> >>>> On 2/1/2013 3:13 PM, Fernando Gont wrote: >>>> >>>>> Section 3: >>>>>> It should be noted that IIDs known or guessed to have been cre= ated >>>>>> according to RFC 4941 could be transformed back into MAC addre= sses, >>>>>> for example during fault diagnosis. For that reason, keeping = the >>>>>> "u" >>>>>> and "g" bits in the IID has operational value. Therefore, the= >>>>>> EUI-64 >>>>>> to IPv6 IID transformation defined in RFC 4941 MUST be used fo= r all >>>>>> cases where an IID is derived from a MAC address. >>>>> How can you tell whether an IID was really derived from a MAC addre= ss, >>>>> or you just had pretty bad luck with your IID randomization -- such= tha >>>>> it *looks* like derived form a mac address? >>>>> >>>>> Thanks! >>>>> >>>>> Cheers, >>>>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From v6ops@globis.net Sun Feb 3 06:03: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 43BE921F8467 for ; Sun, 3 Feb 2013 06:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90xbq8TQS1mi for ; Sun, 3 Feb 2013 06:03:56 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 98C3521F8440 for ; Sun, 3 Feb 2013 06:03:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 03E7A8700DD; Sun, 3 Feb 2013 14:56:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 yGGjvoGAaxir; Sun, 3 Feb 2013 14:55:39 +0100 (CET) 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 DA0698700C7; Sun, 3 Feb 2013 14:55:38 +0100 (CET) Message-ID: <510E6C54.6090002@globis.net> Date: Sun, 03 Feb 2013 14:55:32 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> <510D1877.9020209@globis.net> <510D2D8F.4090805@si6networks.com> <510D5152.5080808@globis.net> <510E1ED5.7040705@gmail.com> In-Reply-To: <510E1ED5.7040705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Fernando Gont , 6man 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: Sun, 03 Feb 2013 14:03:57 -0000 Brian E Carpenter wrote: > On 02/02/2013 17:48, Ray Hunter wrote: >>> Fernando Gont >>> 2 February 2013 16:15 >>> >>> How could you possible ensure such uniqueness without coordination? >>> (i.e., how can you ensure uniqueness if several non-cooperating >>> organizations are generating OUIS with u=) >>> >>> Cheers, >> You can't at a global/ multi-link level. But for IPv6, why should the >> IETF care? All RFC4291 really cares about AFAIK is that the IID acts as >> a tie breaker per link. > > Only because it's supported by DAD, surely? There is no piece of magic > that absolutely prevents two hosts claiming the same IID. > > Brian What "uniqueness" is strictly required for correct operation of IPv6? If the competing technologies can never share an L2 link, what's the problem? IMVHO We should be careful what semantics we import from other standards bodies, and only do this explicitly. Looking at various alternatives for the semantics of IETF defined flags: u = deprecated. EUI64 MAY be used in generation of IIDs. DAD SHOULD be performed for all unicast addresses. A distinct possibility in my book. Reasoning: IIDs are only tie breakers per link. Collisions happen. Deal with it. u==1 => derived from one (of potentially many) mapping schemes based on a universal token, and therefore nodes MAY skip performing DAD on all link types. Also seems reasonable. Some might even think useful. u==1 && g==0 => IEEE EUI64 with IEEE registered OUI on all link technology Is probably too much (and unnecessary for correct functioning of IPv6 AFAIK) Do we really want to tell everyone who wants to produce links that supports IPv6 that they should obtain an OUI from the IEEE, or force them to use u=0 when generating addresses? What value does this restriction add for the IETF? u == 1 && g==0 => IEEE EUI64 with IEEE registered OUI, but only for IPv6 unicast addresses and only on IEEE-defined link technology. Would be fine by me, and current practice AFAIK u==1 && g==1 => reserved for future use by the IETF for generating addresses on all technologies for both unicast and multicast Is currently a possibility. I wouldn't object. Beyond that, if you want a Universally Unique Identifier you should probably be looking at rfc4122, rather than abusing/re-using IID's for this function. >> It's not as though any competing LAN/Link >> standards are going to be sharing a single L2 network. >> >> If VMware come up with a virtual "Wizzinet" to connect virtual routers >> and virtual end nodes, and they coordinate the IID's to be "unique >> enough" per link, and they use EUI64 format addressing, but not OUI's >> administered by the IEEE, what's the problem? You're not going to plug a >> physical Ethernet cable into a virtual link. >> >> Speaking with an operational hat on, I'd rather have access to tools and >> protocols that can perform mapping/registration of e.g. DUID <=L3 <=> >> L2 bindings, such as >> http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration, rather >> than any fixed transformations or encoding. Although it's not problem >> free, at least we could then concentrate on ensuring DUID uniqueness in >> whatever scope we were concerned about. And it covers self-generated >> privacy addresses too. And potentially MAC spoofing/ locally >> administered addresses. Rather than relying on static addressing >> administered by some other standards body and which is reliant on good >> behaviour by all participants. As I'm sure you're aware, operations are >> rapidly moving to virtual machines and devices, and dedicated network >> hardware with a burned-in interface ID is disappearing. >> >>> Ray Hunter >>> 2 February 2013 14:45 >>> Inline >>> >>> Rémi Després wrote: >>>> Brian, >>>> >>>> I agree that this is a good time to clarify uses of u and g bits, and support the initiative Sheng and yourself has taken. >>>> Comments and suggestions inline. >>>> >>>> 2013-02-01 21:13, Fernando Gont : >>>> >>>>> Hi, Brian & Sheng, >>>>> >>>>> On 02/01/2013 05:13 AM, Brian E Carpenter wrote: >>>>>> We've put this together to address the general question of the >>>>>> u/g bits in Interface IDs. Discussion is requested. >>>>> Some comments: >>>>> >>>>> >>>>> Section 1: >>>>> >>>>> >>>>>> The specification assumes that that the normal case is to transform >>>>>> an Ethernet-style address into an IID, preserving the semantics of >>>>>> two bits in particular: >>> Right. "Normal case." Not "exclusive case." >>>>>> o The "u" bit in an IEEE address is set to 0 to indicate universal >>>>>> scope (implying uniqueness) or to 1 to indicate local scope >>>>>> (without implying uniqueness). In an IID this bit is inverted, >>>>>> i.e., 1 for universal scope and 0 for local scope. According to >>>>>> [RFC5342], the reason for this was "to make it easier for network >>>>>> operators to type in local-scope identifiers". >>>>>> o The "g" bit in an IEEE address is set to 1 to indicate group >>>>>> addressing (link-layer multicast). This value is supposed to be >>>>>> preserved in an IID. >>>>> The second bullet is not tru: e.g. temp addresses do not do anything to >>>>> preserve the "g" bit (the "u" bit *is* forced to 0, though); >>>>> Section 2: >>>>> >>>>>> NOTE IN DRAFT: Are there other examples we should include? Are we >>>>>> sure that no IID format defines semantics for u/g? >>>>> Not that I'm aware of. -- AFAIK, the u bit is just used to reduce the >>>>> probability of collisions if your IIDs are derived from global >>>>> identifiers (more on this below). >>> This is also my interpretation. >>>> It completely eliminates collisions for all devices that comply with IEEE specifications, and dramatically reduces it where some vendors have reused some IEEE MAC addresses. >>>> If two devices have the same IEEE MAC address on a link, they have a problem at the link layer, even before having one at the IP layer, and has to be fixed. >>>> >>>> In any case, and more important in my understanding, this doesn't change that any IID having u=can never conflict with IEEE-derived IIDs, be they duplicated or not. A clarification on this would IMHO be useful. >>> I have a problem with any assumption that u==> global uniqueness, or >>> u==> IEEE EUI64 with IEEE administered OUI. >>> >>> Carefully reading RFC4291 I come up with the following: >>> >>> Quote: "Modified EUI-64 format-based interface identifiers may have >>> universal >>> scope when derived from a universal token (e.g., IEEE 802 48-bit MAC >>> or IEEE EUI-64 identifiers [EUI64])" >>> >>> Note the "may" and note the "e.g." >>> >>> Quote: "EUI64 *format*" >>> >>> Note the complete absence of text like "when u= the IID SHOULD/MUST be >>> formed from an IEEE EUI64, including a globally unique OUI portion >>> administered by the IEEE." >>> >>> I therefore openly question any assumptions regarding the IEEE as being >>> defined as the sole and exclusive source of "universal tokens" in the >>> IPv6 addressing architecture. >>> >>> If another standards body built a link technology based on EUI64 >>> *format* identifiers, but with their own OUI administration, that should >>> never be a problem for IPv6, because RFC4291 only requires IID's to be >>> "unique within a subnet prefix." They are not required to be globally >>> unique across all link technologies. This is backed up by another quote >>> from RFC4291: "The details of forming interface identifiers are defined >>> in the appropriate "IPv6 over " specification" >>> >>> >>> Even the IEEE definition of EUI64 in >>> http://standards.ieee.org/develop/regauth/tut/eui64.pdf states >>> >>> Quote "When an EUI-64 is used within the context of an IEEE standard, >>> the standard shall be reviewed by the IEEE RAC for correctness and >>> clarity. When an EUI-64 is referenced within non-IEEE standards, there >>> shall not be any reference to IEEE unless approved by the IEEE RAC." >>> >>> Was this coupling of standards ever reviewed by the IEEE? >>> >>> Because it seems to me that the lack of universally clear handling of >>> the u=g=1 case in IETF documents would not fit with the existing IEEE >>> definition of EUI64, where u=g=1 is clearly a globally administered >>> multicast address, and is not available for any other use. >>> >>> >>> >>> So my conclusion is that any coupling between IEEE and IETF standards >>> should be weak at most, and also limited to individual links. >>> >>>>> Section 2, page 4: >>>>>> "The use of the universal/local bit in the Modified EUI-64 format >>>>>> identifier is to allow development of future technology that can take >>>>>> advantage of interface identifiers with universal scope." >>>> (*) >>>> >>>>> This seems to assume that the namespace (Identifiers) of two different >>>>> technologies does not overlap. Such assumption sounds like dubious to >>>>> me... but I might be missing something. >>>> AFAIK, it means that *if u=he structure of other bits has to be universally specified. This is used so far for IEEE-derived IIDs. It can advantageously be used for other technologies, as foreseen in RFC4291 itself. 4rd is just the first proposed new use. >>>> >>>> >>>>> i.e. some non-IEEE technology is expected to obey the u/g bits? >>>> - For all addresses subject to SLAAC, all IETF technologies are constrained by the u-bit meaning of RFC4291. If u=ll other bits have no recognizable structure; if u if all other bits have a recognizable >>>> - For addresses that aren't subject to SLAAC like, for instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't applicable. A clarification on this would IMHO be useful. >>>> >>>> >>>> Now, a new point: >>>> The sentence of RFC 4291 about future technologies ((*) above) is, in my understanding and if taken rigorously, less open than it can be concerning future technologies. It is sufficient that IIDs of new technologies using u=ve a universally recognizable structure. There IID scopes can have a non-universal scope without breaking anything. Your draft can be a place to clarify this. >>>> >>>> Note that this point is made in general, as a contribution to clarify the u/g issue, not because it would concern 4rd. IIDs of 4rd are universally unique (each one contains a globally unique IPv4 address, plus a CNP field which has different values for all CEs that share this address). >>>> >>>> >>>>> Section 3: >>>>>> It should be noted that IIDs known or guessed to have been created >>>>>> according to RFC 4941 could be transformed back into MAC addresses, >>>>>> for example during fault diagnosis. For that reason, keeping the "u" >>>>>> and "g" bits in the IID has operational value. Therefore, the EUI-64 >>>>>> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >>>>>> cases where an IID is derived from a MAC address. >>>>> How can you tell whether an IID was really derived from a MAC address, >>>>> or you just had pretty bad luck with your IID randomization -- such tha >>>>> it *looks* like derived form a mac address? >>>> All currently specified randomizations concern IIDs that have u=one can conflict with formats specified for u=1 IIDs. >>>> >>>> Regards, >>>> RD >>>> >>>> >>>> >>>>> Thanks! >>>>> >>>>> Cheers, >>>>> -- >>>>> 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 >>>>> -------------------------------------------------------------------- >>> ------------------------------------------------------------------------ >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From jmh@joelhalpern.com Sun Feb 3 08:08: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 6BF7C21F8622 for ; Sun, 3 Feb 2013 08:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kggx1v3+VNJl for ; Sun, 3 Feb 2013 08:08:03 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8912521F885C for ; Sun, 3 Feb 2013 08:08:03 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 2855AA4122 for ; Sun, 3 Feb 2013 08:08:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0870D1C073C; Sun, 3 Feb 2013 08:08:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 72D751C0538; Sun, 3 Feb 2013 08:07:52 -0800 (PST) Message-ID: <510E8B38.2010908@joelhalpern.com> Date: Sun, 03 Feb 2013 11:07:20 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> In-Reply-To: <510E4D7C.5020307@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man 6man-wg , Bob Hinden 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, 03 Feb 2013 16:08:04 -0000 I presume I am misunderstanding you Brian. You seem to be saying that because some liet coul violate the spec, and set u==1 on something that did not come from an EUI-64 on that device, then it ollows that the spec is meaningless. It is true for almost all our specs tat they can be ignored, bent, or violated, and mostly, things still work. That does not make the specs or their requirements meaningless. The fact that you can make a u==0 IID from anything you want is irrelevant to the question of what u==1 means. Is there an implementation in the real world that is violating the spec by generating u==1 from something other than EUI values? I wuld be very surprised, but if you know of such, and there is a reason they di it, that would e useful information. As far as I can tell, all of the confusion regarding the spec has been in what else we are allowed to specify. So having a clearer spec would help us. But that, by itself, even with pithy quotes, is not a reason to change an existing IETF agreement. Is there a problem with the current rules? Yours, Joel On 2/3/2013 6:43 AM, Brian E Carpenter wrote: > On 03/02/2013 10:57, Rémi Després wrote: >> Le 2013-02-02 à 18:17, Joel M. Halpern a écrit : >> >>> I a not clear what aspect of the semantics of u==1 and the relationship to EUI-64 is a dead duck. Currently, if you see something with u==1, you know it was made from an EUI-64. Under your proposal, you would not know that. >>> Yous tae below tat the presence of ==1 doesn't mean that. to the best of my knowledge, currently, it does mean that. It may not be derived from the EUI-64 of the interface yo want to reach, but it is derived from an EUI-64. Otherwise, u would be set to 0. >>> >>> You are proposing to change this rule. >> >> Same understanding. >> u=1 has a meaning that shouldn't be negated now. >> >>> Aside from anything else, I do not see a motivation for changing the rule. > > Actually, I don't think that is what the draft proposes. What it proposes > is that we delete the fiction that the bit has any meaning after it arrives > in an IID. It seems to be that fiction that causes confusion, not the > rule about how to generate Modified EUI-64 format from a MAC address. > > Quoting a wise colleague, "magic bits are almost never worth the pain." > > To say it again in different words, u==1 does not prove that an IID is > universally unique and u==0 does not prove that an IID is locally unique. > So it's fine to specify methods for generating the u bit, but it is > incorrect to draw firm conclusions based on its value. > > Brian > >> >> The rule concerning the u=1 can advantageously be completed with new uses (provided they don't conflict wit previous uses). >> >> Regards, >> RD >> >> >>> I have no problem with clarifying under-specified corner cases. >>> But why change the rule we have? Is there a problem with the current rule that I am missing? >>> >>> Yours, >>> Joel >>> >>> On 2/2/2013 3:35 AM, Brian E Carpenter wrote: >>>> Joel, >>>> >>>> On 02/02/2013 00:41, Joel M. Halpern wrote: >>>>> With regard to section 3, I would ask the question in the reverse. >>>>> (which may actually be the same quewstion Fernando is asking.) >>>>> >>>>> If we assume that there is value in being able to perform the diagnostic >>>>> operation described, then it seems that one needs to be able to tell >>>>> when it can be applied. >>>>> Currently, that is u==1 in the IID field. >>>>> The text says that u==1 must be used n the IID field for IIDs derived >>>>> from EUI-64. >>>>> But it the goes on to say that u=1 can be used by other addresses. >>>>> If u=1 can be used by addresses not derived from EUI-64, then the >>>>> diagnostic operation can not be applied without a-priori knowledge. >>>>> And in the presence of such knowledge, the u bit does not seem to help. >>>> Correct. Semantically, it's a dead duck. That's already true, whatever >>>> words are written in RFCs - the fact that u=1 does not prove the IID >>>> comes from a MAC address with u=0, and vice versa. >>>> >>>>> The obvious answer is that to enable the diagnostic, and because there >>>>> is no need to make a gratuitous change, we stick with u=1 being used >>>>> always and only for addresses derived from EUI-64. >>>> But that doesn't mean that the IID was derived from a MAC address, >>>> so its value is limited. >>>> >>>>> The other alternative I can understand, although I do not favor it, is >>>>> to not allow the diagnostic at all. >>>> The alternative is what we have today: *assume* that an IID that looks >>>> as if it came from a MAC address in fact did so. >>>> >>>> Brian >>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/1/2013 3:13 PM, Fernando Gont wrote: >>>>> >>>>>> Section 3: >>>>>>> It should be noted that IIDs known or guessed to have been created >>>>>>> according to RFC 4941 could be transformed back into MAC addresses, >>>>>>> for example during fault diagnosis. For that reason, keeping the >>>>>>> "u" >>>>>>> and "g" bits in the IID has operational value. Therefore, the >>>>>>> EUI-64 >>>>>>> to IPv6 IID transformation defined in RFC 4941 MUST be used for all >>>>>>> cases where an IID is derived from a MAC address. >>>>>> How can you tell whether an IID was really derived from a MAC address, >>>>>> or you just had pretty bad luck with your IID randomization -- such tha >>>>>> it *looks* like derived form a mac address? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Cheers, >>>>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> > From jmh@joelhalpern.com Sun Feb 3 09:27: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 1355C21F8417 for ; Sun, 3 Feb 2013 09:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fup-74Innj7P for ; Sun, 3 Feb 2013 09:27:16 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AA85621F83EF for ; Sun, 3 Feb 2013 09:27:16 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 7DF64A3B04 for ; Sun, 3 Feb 2013 09:27:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5B4DD1C07B8; Sun, 3 Feb 2013 09:27:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48C491C0538; Sun, 3 Feb 2013 09:27:12 -0800 (PST) Message-ID: <510E9DD3.2050907@joelhalpern.com> Date: Sun, 03 Feb 2013 12:26:43 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Randy Bush Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Deployment Prevention 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, 03 Feb 2013 17:27:17 -0000 To a significant degree Randy, I agree with you in your comment about magic bits. If I were designing IPv6 from scratch (counter-factual in so may ways at once) I would not do it that way. But, unless there is an actual problem with the design the IETF has adopted, I am reluctant to change it "just because". Yours, Joel On 2/3/2013 4:46 AM, Randy Bush wrote: ... > i hate to sound like a broken record, but magic bits are almost never > worth the pain. > > randy From brian.e.carpenter@gmail.com Sun Feb 3 11:36: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 0B96121F8639 for ; Sun, 3 Feb 2013 11:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.146 X-Spam-Level: X-Spam-Status: No, score=-101.146 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-kECry8W8mr for ; Sun, 3 Feb 2013 11:36:17 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 61B5921F8635 for ; Sun, 3 Feb 2013 11:36:17 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so4096041wgb.33 for ; Sun, 03 Feb 2013 11:36:16 -0800 (PST) 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=o2M2m9mSmzjk5XAso7nA5732nkWl8k8DdDcRENElWIE=; b=dfN0gm1SX2Y84QCT1ZSEKEDotqBha56gHPwuPkvbE/KnpRSp88N1E8XDenOokPkVm3 OReTtE7ASFndhKSUoYsIO7FECsD/P1xxLnGt580b8MYRD635Z1i566ckH8bqeuY1MkNk yp2PSQqYT843PcFDA5IdLVwQdn9rzT/tCDABG+c7LT3IYcDseYvpK5sETLPE6oQ73BLD oyoEskVF0KZCT6LcEReSJWTjknd9e1y76pOvtT10BmzVT/URuneu6yPxMsXL/pGYU85C iVgPsfCu+p8k2fJlUg1nrLKA/hsfjFGqpYWLakv908wLeDgHh+HFI6YevyQ1ajSk5Y/P n7+A== X-Received: by 10.194.19.10 with SMTP id a10mr31142016wje.45.1359920176406; Sun, 03 Feb 2013 11:36:16 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-151.as13285.net. [2.102.218.151]) by mx.google.com with ESMTPS id s10sm17384304wiw.4.2013.02.03.11.36.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 11:36:14 -0800 (PST) Message-ID: <510EBC22.2070503@gmail.com> Date: Sun, 03 Feb 2013 19:36:02 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> In-Reply-To: <510E9DD3.2050907@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 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: Sun, 03 Feb 2013 19:36:18 -0000 On 03/02/2013 17:26, Joel M. Halpern wrote: > To a significant degree Randy, I agree with you in your comment about > magic bits. If I were designing IPv6 from scratch (counter-factual in > so may ways at once) I would not do it that way. > > But, unless there is an actual problem with the design the IETF has > adopted, I am reluctant to change it "just because". Which is why the draft actually proposes nothing that would change any running code. Brian > > Yours, > Joel > > On 2/3/2013 4:46 AM, Randy Bush wrote: > ... >> i hate to sound like a broken record, but magic bits are almost never >> worth the pain. >> >> randy > > From jmh@joelhalpern.com Sun Feb 3 11:40: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 8B17A21F8960 for ; Sun, 3 Feb 2013 11:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPJl4xdjbq+j for ; Sun, 3 Feb 2013 11:40:00 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AA69421F881E for ; Sun, 3 Feb 2013 11:40:00 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 628B0557F92 for ; Sun, 3 Feb 2013 11:40:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 15FFC1BC7B70; Sun, 3 Feb 2013 11:40:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8957A1BC7B50; Sun, 3 Feb 2013 11:39:59 -0800 (PST) Message-ID: <510EBCF5.1050705@joelhalpern.com> Date: Sun, 03 Feb 2013 14:39:33 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> In-Reply-To: <510EBC22.2070503@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Sun, 03 Feb 2013 19:40:01 -0000 On 2/3/2013 2:36 PM, Brian E Carpenter wrote: > On 03/02/2013 17:26, Joel M. Halpern wrote: >> To a significant degree Randy, I agree with you in your comment about >> magic bits. If I were designing IPv6 from scratch (counter-factual in >> so may ways at once) I would not do it that way. >> >> But, unless there is an actual problem with the design the IETF has >> adopted, I am reluctant to change it "just because". > > Which is why the draft actually proposes nothing that would change > any running code. > > Brian But it does propose to change the spec. Why? What problem does changing the spec solve? Yours, Joel From markzzzsmith@yahoo.com.au Sun Feb 3 12:25: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 EF01E21F87DC for ; Sun, 3 Feb 2013 12:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8IPwJaM2ZUt for ; Sun, 3 Feb 2013 12:25:16 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id 22EF821F87D3 for ; Sun, 3 Feb 2013 12:25:16 -0800 (PST) Received: from [98.139.212.147] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 20:25:15 -0000 Received: from [98.139.212.241] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 20:25:15 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 20:25:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 484599.19778.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 89157 invoked by uid 60001); 3 Feb 2013 20:25:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359923115; bh=GOkkq4bb/gjYlQx5uHEnjj6P0WxcvoCIc2cS7qCa99s=; 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=U88dxKSb8CUabE6g7TzG4uoAK+3BpS5B/5M3Bm4ib1D3JdIYARdzzfh3HQt4Psjza59QrCRCfxt01LGmlS+6ycUBC/zHNmOi6SmvlLUrP3dQsnBrsYQS/72R/o7Q7jIrx7qQHJMF6F0kkEWie7AgIYsrrrvTUllgyY3rC3BMxJw= 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=lv6jnEFivl+d3U1XhbW/C1f4evf9jghu8DAimvEB/yoGYL7sPMhX0fLerQGfu3cToxkdn5zZG8iIi+M+O0JD2fbrarJiodPLKDIHcO1Sj0bLQ8GdfhkIPxzTRk0dnC4YqG3iB5JNnkrfARQ9tlqFzOgUi+iO20dZfrJZoby14uM=; X-YMail-OSG: 6fpZu_oVM1mRoBldTDH6OoMdTKWmYLWTigPz0pkXdZFKJcN LPMNrU.1nI7yKL9gBoVXaCPlREJKwQvWaBhw_.cgU6bSDOah8KzQ1vNMeRSc Tbkfp6rOU.P4T4dS4EpI0BDbbXZE2WXYlCAfzgdHglqf5sHbYOsdk3lgDPu0 .PWM1aO2fOz7QNDTNjFp8NVB1lCnHVpnhjY.59SfktXytGldyFLTgZvgzaNd bE8u7C6BnXBppR3lx2azSBvUYUVaQOWCW9Y.oYc0F6JQGd0ka9S.CkEvFU57 gxh_SQE8s.2etkYPAknMjA7SiPENyCK9wcX261QuatTIl5cp1MgBpgJEDZ0x LJArNt8iQuEcntevUJZQjtIzteazHdwa6ax7WHCe8.RP0Me3NdmPeL8ARGRH WbyNeiIias1gP277tYPqKJa4H1VKdSm0cCS9nFmpCtzsbharQORIDRxzEVum FMA5oRRZgs_vk.7x8rSI7Ubs3tPEbPOZsvAH5ucXWytwRJkzcmy__mVc_q5K YQnIzQw_CQ4BdWfpVfj2OdIYfjswxdv1BeGoYONFe70cM62So_4Dza0ClCsF 00WWPoXPvWr8lIA1B0ni7uPUUcpAX20n5B7MUMCbutCIEzORO9QaamrTCIC9 Ez5KGfT1C_UU9mkQ1qaQjPeHTZDsjm9.cNNiEc6AdmDPqdfFOJF8K4T6fR6_ YCtWKoiydGV.wKpOjpVADknpT797le6dYozcFd_lRBw-- Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Sun, 03 Feb 2013 12:25:14 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBSYXkgSHVudGVyIDx2Nm9wc0BnbG9iaXMubmV0Pgo.IFRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IENjOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.OyA2bWFuIDZtYW4td2cgPGlwdjZAaWV0Zi5vcmc.Cj4gU2VudDogTW9uZGF5LCA0IEZlYnJ1YXJ5IDIwMTMgMTI6NTUgQU0KPiBTdWJqZWN0OiBSZTogUmU6IFtGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWNhcnBlbnQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.131.499 References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> <510D1877.9020209@globis.net> <510D2D8F.4090805@si6networks.com> <510D5152.5080808@globis.net> <510E1ED5.7040705@gmail.com> <510E6C54.6090002@globis.net> Message-ID: <1359923114.88818.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Sun, 3 Feb 2013 12:25:14 -0800 (PST) From: Mark Smith Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] To: Ray Hunter , Brian E Carpenter In-Reply-To: <510E6C54.6090002@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , 6man 6man-wg 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: Sun, 03 Feb 2013 20:25:18 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Ray Hunter =0A> To: Brian E Carpenter =0A> Cc: Ferna= ndo Gont ; 6man 6man-wg =0A> Sent: Mo= nday, 4 February 2013 12:55 AM=0A> Subject: Re: Re: [Fwd: I-D Action: draft= -carpenter-6man-ug-00.txt]=0A> =0A> Brian E Carpenter wrote:=0A>> On 02/02= /2013 17:48, Ray Hunter wrote:=0A>>>> Fernando Gont =0A>>>> 2 February 2013 16:15=0A>>>> =0A>>>> How could you possib= le ensure such uniqueness without coordination?=0A>>>> (i.e., how can you = ensure uniqueness if several non-cooperating=0A>>>> organizations are gene= rating OUIS with u=3D)=0A>>>> =0A>>>> Cheers,=0A>>> You can't at a global= / multi-link level. But for IPv6, why should =0A> the=0A>>> IETF care? All= RFC4291 really cares about AFAIK is that the IID acts as=0A>>> a tie brea= ker per link. =0A>> =0A>> Only because it's supported by DAD, surely? Ther= e is no piece of magic=0A>> that absolutely prevents two hosts claiming th= e same IID.=0A>> =0A>> =A0 =A0 Brian=0A> What "uniqueness" is strictly requ= ired for correct operation of IPv6?=0A> If the competing technologies can n= ever share an L2 link, what's the=0A> problem?=0A> =0A> IMVHO We should be = careful what semantics we import from other standards=0A> bodies, and only = do this explicitly.=0A> =0A> Looking at various alternatives for the semant= ics of IETF defined flags:=0A>=A0=0A> u =3D deprecated. EUI64 MAY be used i= n generation of IIDs. DAD SHOULD be=0A=0A> performed for all unicast addres= ses.=0A> A distinct possibility in my book. Reasoning: IIDs are only tie br= eakers=0A> per link. Collisions happen. Deal with it.=0A>=A0=0A=0AOther tha= n the "u =3D deprecated" I think this is already the status quo.=0A=0APerha= ps the confusion is because in RFC4291 it refers to the IID being in "Modif= ied EUI-64 format", which implies that IID must be derived from an EUI-64. = That then implies the the IID then also inherits the properties of an EUI-6= 4 i.e. the IID is globally unique if the EUI-64 is assumed to be.=0A=0AIn t= he past I've found this confusing because IPX and XNS also derived the laye= r 3 interface identifier from the layer 2 interface identifier, and tightly= coupled them together such that there was no ARP/ND protocol - at the last= hop the layer 3 interface identifier was copied into the layer 2 header de= stination address for delivery. So the question at the time I had was if IP= v6 IIDs are derived from EUI-64s, which were usually derived from EUI-48s, = why bother with a layer 3 to layer 2 address resolution protocol (and then = think maybe it'd fix the ND DoS Attack problem, but it doesn't, it just shi= fts it to layer 2)? I then realised that deriving the IID from an EUI-64 wa= s just an IID generation algorithm, nothing more. DAD is necessary because = even though the IID might appear to be unique because the EUI-64 should be = unique, it may not be (https://speakerdeck.com/hdm/derbycon-2012-the-wild-w= est)=0A=0A=0A> u=3D=3D1 =3D> derived from one (of potentially many) mapping= schemes based on=0A> a universal token, and therefore nodes MAY skip perfo= rming DAD on all=0A> link types.=0A> Also seems reasonable. Some might even= think useful.=0A>=0A=0AI've had the unfortunate experience in the distance= past of troubleshooting 5 duplicate IPv4 addresses on a link when some sof= tware developers decided to duplicate their TCP/IP network configuration se= ttings on their PCs. This was before RFC1918, so the addresses were globall= y unique, and before DAD was implemented in desktop PCs. It's was very conf= using because the only symptom, other than things randomly failing, was con= stantly changing MAC addresses in the ARP table of the router.=A0DAD would = have saved a huge amount of time in this scenario.=0A=0ASo what I don't und= erstand is why people seem to want to skip performing DAD? It's only a few = multicast packets, and ensures that if there are duplicate addresses, the c= ause is immediately obvious, and also doesn't disrupt the host that is alre= ady using that address. The savings of avoiding DAD don't seem to be worth = the benefits to me.=0A=A0=A0=0A=0A> u=3D=3D1 && g=3D=3D0=A0 =3D> IEEE EUI64= with IEEE registered OUI on all link =0A> technology=0A> Is probably too m= uch (and unnecessary for correct functioning of IPv6 AFAIK)=0A> Do we reall= y want to tell everyone who wants to produce links that=0A> supports IPv6 t= hat they should obtain an OUI from the IEEE, or force=0A> them to use u=3D0= when generating addresses? What value does this=0A> restriction add for th= e IETF?=0A>=A0=0A=0AI don't think we should, as it would too tightly couple= layer 3 with a particular layer 2 addressing scheme.=0A=0A> u =3D=3D 1 && = g=3D=3D0 =3D> IEEE EUI64 with IEEE registered OUI, but only for =0A> IPv6= =0A> unicast addresses and only on IEEE-defined link technology.=0A> Would = be fine by me, and current practice AFAIK=0A>=A0=0A=0AThat would seem to ma= ke the u =3D=3D 1 bit really the IEEE Address =3D=3D 1 bit. Going down that= path would suggest also giving other parties who allocate addresses their = own bits if they want them e.g. an E.164 =3D=3D 1 bit.=0A=0A> u=3D=3D1 && g= =3D=3D1 =3D> reserved for future use by the IETF for generating=0A> address= es on all technologies for both unicast and multicast=0A> Is currently a po= ssibility. I wouldn't object.=0A> =0A> =0A> Beyond that, if you want a Univ= ersally Unique Identifier you should=0A> probably be looking at rfc4122, ra= ther than abusing/re-using IID's for=0A> this function.=0A=0AI think this w= ould be a better option than tying layer 3 IID uniqueness to one layer 2 ad= dress uniqueness scheme. Even then I'd argue that DAD needs to be performed= .=0A=0A>>> It's not as though any competing LAN/Link=0A>>> standards are = going to be sharing a single L2 network.=0A>>> =0A>>> If VMware come up wi= th a virtual "Wizzinet" to connect =0A> virtual routers=0A>>> and virtual = end nodes, and they coordinate the IID's to be =0A> "unique=0A>>> enough" = per link, and they use EUI64 format addressing, but not =0A> OUI's=0A>>> a= dministered by the IEEE, what's the problem? You're not going =0A> to plug = a=0A>>> physical Ethernet cable into a virtual link.=0A>>> =0A>>> Speakin= g with an operational hat on, I'd rather have access to =0A> tools and=0A>>= > protocols that can perform mapping/registration of e.g. DUID <=3DL3 =0A>= <=3D>=0A>>> L2 bindings, such as=0A>>> http://datatracker.ietf.org/doc/d= raft-ietf-dhc-addr-registration, =0A> rather=0A>>> than any fixed transfor= mations or encoding.=A0 Although it's not =0A> problem=0A>>> free, at leas= t we could then concentrate on ensuring DUID uniqueness in=0A>>> whatever = scope we were concerned about. And it covers self-generated=0A>>> privacy = addresses too. And potentially MAC spoofing/ locally=0A>>> administered ad= dresses. Rather than relying on static addressing=0A>>> administered by so= me other standards body and which is reliant on good=0A>>> behaviour by al= l participants. As I'm sure you're aware, =0A> operations are=0A>>> rapidl= y moving to virtual machines and devices, and dedicated network=0A>>> hard= ware with a burned-in interface ID is disappearing.=0A>>> =0A>>>> Ray Hunt= er =0A>>>> 2 February 2013 14:45=0A>>>> Inline= =0A>>>> =0A>>>> R=E9mi Despr=E9s wrote:=0A>>>>> Brian,=0A>>>>> =0A>>>>> = I agree that this is a good time to clarify uses of u and g =0A> bits, and = support the initiative Sheng and yourself has taken.=0A>>>>> Comments and = suggestions inline.=0A>>>>> =0A>>>>> 2013-02-01 21:13, Fernando Gont :=0A>>>>> =0A>>>>>> Hi, Brian & Sheng,=0A>>>>>> =0A>>>>= >> On 02/01/2013 05:13 AM, Brian E Carpenter wrote:=0A>>>>>>> We've put t= his together to address the general =0A> question of the=0A>>>>>>> u/g bit= s in Interface IDs. Discussion is requested.=0A>>>>>> Some comments:=0A>>>= >>> =0A>>>>>> =0A>>>>>> Section 1:=0A>>>>>> =0A>>>>>> =0A>>>>>>> =A0 The = specification assumes that that the normal case =0A> is to transform=0A>>>>= >>> =A0 an Ethernet-style address into an IID, preserving the =0A> semanti= cs of=0A>>>>>>> =A0 two bits in particular:=0A>>>> Right. "Normal case." = Not "exclusive case."=0A>>>>>>> =A0 o=A0 The "u" bit in an IEEE address is= set to =0A> 0 to indicate universal=0A>>>>>>> =A0 =A0 =A0 scope (implying = uniqueness) or to 1 to indicate =0A> local scope=0A>>>>>>> =A0 =A0 =A0 (wit= hout implying uniqueness).=A0 In an IID this bit =0A> is inverted,=0A>>>>>>= > =A0 =A0 =A0 i.e., 1 for universal scope and 0 for local =0A> scope.=A0 Ac= cording to=0A>>>>>>> =A0 =A0 =A0 [RFC5342], the reason for this was "to mak= e =0A> it easier for network=0A>>>>>>> =A0 =A0 =A0 operators to type in loc= al-scope =0A> identifiers".=0A>>>>>>> =A0 o=A0 The "g" bit in an IEEE addr= ess is set to =0A> 1 to indicate group=0A>>>>>>> =A0 =A0 =A0 addressing (li= nk-layer multicast).=A0 This value is =0A> supposed to be=0A>>>>>>> =A0 =A0= =A0 preserved in an IID.=0A>>>>>> The second bullet is not tru: e.g. temp= addresses do not do =0A> anything to=0A>>>>>> preserve the "g" bit (the "= u" bit *is* =0A> forced to 0, though);=0A>>>>>> Section 2:=0A>>>>>> =0A>>>= >>>> =A0 NOTE IN DRAFT: Are there other examples we should =0A> include?= =A0 Are we=0A>>>>>>> =A0 sure that no IID format defines semantics for u/g= ?=0A>>>>>> Not that I'm aware of. -- AFAIK, the u bit is just used =0A> to= reduce the=0A>>>>>> probability of collisions if your IIDs are derived fr= om =0A> global=0A>>>>>> identifiers (more on this below).=0A>>>> This is = also my interpretation.=0A>>>>> It completely eliminates collisions for al= l devices that comply =0A> with IEEE specifications, and dramatically reduc= es it where some vendors have =0A> reused some IEEE MAC addresses.=0A>>>>> = If two devices have the same IEEE MAC address on a link, they =0A> have a = problem at the link layer, even before having one at the IP layer, and =0A>= has to be fixed. =0A>>>>> =0A>>>>> In any case, and more important in my = understanding, this =0A> doesn't change that any IID having u=3Dcan never c= onflict with IEEE-derived =0A> IIDs, be they duplicated or not. A clarifica= tion on this would IMHO be useful.=0A>>>> I have a problem with any assump= tion that u=3D=3D> global =0A> uniqueness, or=0A>>>> u=3D=3D> IEEE EUI64 w= ith IEEE administered OUI.=0A>>>> =0A>>>> Carefully reading RFC4291 I come= up with the following:=0A>>>> =0A>>>> Quote: "Modified EUI-64 format-base= d interface identifiers may =0A> have=0A>>>> universal=0A>>>> =A0 =A0 scop= e when derived from a universal token (e.g., IEEE 802 48-bit =0A> MAC=0A>>>= > =A0 =A0 or IEEE EUI-64 identifiers [EUI64])"=0A>>>> =0A>>>> Note the "ma= y" and note the "e.g."=0A>>>> =0A>>>> Quote: "EUI64 *format*"=0A>>>> =0A>>= >> Note the complete absence of text like "when u=3D the IID =0A> SHOULD/M= UST be=0A>>>> formed from an IEEE EUI64, including a globally unique OUI p= ortion=0A>>>> administered by the IEEE."=0A>>>> =0A>>>> I therefore openl= y question any assumptions regarding the IEEE as =0A> being=0A>>>> defined= as the sole and exclusive source of "universal =0A> tokens" in the=0A>>>> = IPv6 addressing architecture.=0A>>>> =0A>>>> If another standards body bu= ilt a link technology based on EUI64=0A>>>> *format* identifiers, but with= their own OUI administration, that =0A> should=0A>>>> never be a problem = for IPv6, because RFC4291 only requires =0A> IID's to be=0A>>>> "unique wi= thin a subnet prefix." They are not required to =0A> be globally=0A>>>> un= ique across all link technologies. This is backed up by another =0A> quote= =0A>>>> from RFC4291: "The details of forming interface identifiers =0A> a= re defined=0A>>>> in the appropriate "IPv6 over " =0A> specification= "=0A>>>> =0A>>>> =0A>>>> Even the IEEE definition of EUI64 in=0A>>>> http= ://standards.ieee.org/develop/regauth/tut/eui64.pdf states=0A>>>> =0A>>>> = Quote "When an EUI-64 is used within the context of an IEEE =0A> standard,= =0A>>>> the standard shall be reviewed by the IEEE RAC for correctness and= =0A>>>> clarity. When an EUI-64 is referenced within non-IEEE standards, = =0A> there=0A>>>> shall not be any reference to IEEE unless approved by th= e IEEE =0A> RAC."=0A>>>> =0A>>>> Was this coupling of standards ever revie= wed by the IEEE?=0A>>>> =0A>>>> Because it seems to me that the lack of un= iversally clear handling =0A> of=0A>>>> the u=3Dg=3D1 case in IETF documen= ts would not fit with the existing =0A> IEEE=0A>>>> definition of EUI64, w= here u=3Dg=3D1 is clearly a globally administered=0A>>>> multicast address= , and is not available for any other use.=0A>>>> =0A>>>> =0A>>>> =0A>>>> S= o my conclusion is that any coupling between IEEE and IETF =0A> standards= =0A>>>> should be weak at most, and also limited to individual links.=0A>>= >> =A0 =0A>>>>>> Section 2, page 4:=0A>>>>>>> =A0 "The use of the universa= l/local bit in the =0A> Modified EUI-64 format=0A>>>>>>> =A0 identifier is= to allow development of future =0A> technology that can take=0A>>>>>>> =A0= advantage of interface identifiers with universal =0A> scope."=0A>>>>> (= *)=0A>>>>> =0A>>>>>> This seems to assume that the namespace (Identifiers)= of =0A> two different=0A>>>>>> technologies does not overlap. Such assump= tion sounds like =0A> dubious to=0A>>>>>> me... but I might be missing som= ething.=0A>>>>> AFAIK, it means that *if u=3Dhe structure of other bits ha= s to be =0A> universally specified. This is used so far for IEEE-derived II= Ds. It can =0A> advantageously be used for other technologies, as foreseen = in RFC4291 itself. =0A> 4rd is just the first proposed new use.=0A>>>>> =0A= >>>>> =0A>>>>>> i.e. some non-IEEE technology is expected to obey the u/g = =0A> bits?=0A>>>>> - For all addresses subject to SLAAC, all IETF technolo= gies are =0A> constrained by the u-bit meaning of RFC4291. If u=3Dll other = bits have no =0A> recognizable structure; if u if all other bits have a rec= ognizable =0A>>>>> - For addresses that aren't subject to SLAAC like, for = =0A> instance, those of inter-router links of RFC6164, the RFC4291 structur= e of /64 =0A> IIDs isn't applicable. A clarification on this would IMHO be = useful.=0A>>>>> =0A>>>>> =0A>>>>> Now, a new point:=0A>>>>> The sentence = of RFC 4291 about future technologies ((*) above) =0A> is, in my understand= ing and if taken rigorously, less open than it can be =0A> concerning futur= e technologies. It is sufficient that IIDs of new technologies =0A> using u= =3Dve a universally recognizable structure. There IID scopes can have a =0A= > non-universal scope without breaking anything. Your draft can be a place = to =0A> clarify this.=0A>>>>> =0A>>>>> Note that this point is made in gen= eral, as a contribution to =0A> clarify the u/g issue, not because it would= concern 4rd. IIDs of 4rd are=A0 =0A> universally unique (each one contains= a globally unique IPv4 address, plus a CNP =0A> field which has different = values for all CEs that share this address).=0A>>>>> =A0 =0A>>>>> =0A>>>>>>= Section 3:=0A>>>>>>> =A0 It should be noted that IIDs known or guessed t= o have =0A> been created=0A>>>>>>> =A0 according to RFC 4941 could be tran= sformed back into =0A> MAC addresses,=0A>>>>>>> =A0 for example during fau= lt diagnosis.=A0 For that reason, =0A> keeping the "u"=0A>>>>>>> =A0 and "= g" bits in the IID has operational =0A> value.=A0 Therefore, the EUI-64=0A>= >>>>>> =A0 to IPv6 IID transformation defined in RFC 4941 MUST =0A> be use= d for all=0A>>>>>>> =A0 cases where an IID is derived from a MAC address.= =0A>>>>>> How can you tell whether an IID was really derived from a =0A> M= AC address,=0A>>>>>> or you just had pretty bad luck with your IID randomi= zation =0A> -- such tha=0A>>>>>> it *looks* like derived form a mac addres= s?=0A>>>>> All currently specified randomizations concern IIDs that have = =0A> u=3Done can conflict with formats=A0 specified for u=3D1 IIDs.=0A>>>>>= =0A>>>>> Regards,=0A>>>>> RD=0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>>> Thanks= !=0A>>>>>> =0A>>>>>> Cheers,=0A>>>>>> -- =0A>>>>>> Fernando Gont=0A>>>>>= > SI6 Networks=0A>>>>>> e-mail: fgont@si6networks.com=0A>>>>>> PGP Finge= rprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 =0A> 1D4E 7492=0A>>>>>> =0A= >>>>>> =0A>>>>>> =0A>>>>>> =0A>>>>>> =0A> ---------------------------------= -----------------------------------=0A>>>>>> IETF IPv6 working group maili= ng list=0A>>>>>> ipv6@ietf.org=0A>>>>>> Administrative Requests: =0A> htt= ps://www.ietf.org/mailman/listinfo/ipv6=0A>>>>>> =0A> ---------------------= -----------------------------------------------=0A>>>> =0A> ---------------= ---------------------------------------------------------=0A>>> ----------= ----------------------------------------------------------=0A>>> IETF IPv6= working group mailing list=0A>>> ipv6@ietf.org=0A>>> Administrative Requ= ests: https://www.ietf.org/mailman/listinfo/ipv6=0A>>> -------------------= -------------------------------------------------=0A>>> =0A>> =0A>> =0A> = =0A> --------------------------------------------------------------------= =0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------= ------------------------------------------------------=0A> From joelja@bogus.com Sun Feb 3 12:57: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 6F3AF21F8846 for ; Sun, 3 Feb 2013 12:57:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St-stHPKBGFN for ; Sun, 3 Feb 2013 12:57:05 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EE8DE21F882E for ; Sun, 3 Feb 2013 12:57:04 -0800 (PST) Received: from joels-MacBook-Air.local (96.sub-70-199-78.myvzw.com [70.199.78.96]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r13Kv0x4045934 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 3 Feb 2013 20:57:00 GMT (envelope-from joelja@bogus.com) Message-ID: <510ECF17.8020802@bogus.com> Date: Sun, 03 Feb 2013 12:56:55 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> In-Reply-To: <510EBCF5.1050705@joelhalpern.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, 03 Feb 2013 20:57:02 +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, 03 Feb 2013 20:57:05 -0000 On 2/3/13 11:39 AM, Joel M. Halpern wrote: > > > On 2/3/2013 2:36 PM, Brian E Carpenter wrote: >> On 03/02/2013 17:26, Joel M. Halpern wrote: >>> To a significant degree Randy, I agree with you in your comment about >>> magic bits. If I were designing IPv6 from scratch (counter-factual in >>> so may ways at once) I would not do it that way. >>> >>> But, unless there is an actual problem with the design the IETF has >>> adopted, I am reluctant to change it "just because". >> >> Which is why the draft actually proposes nothing that would change >> any running code. >> >> Brian > > But it does propose to change the spec. Why? What problem does > changing the spec solve? If it prevents someone from ascribing new utility to these bit(s) in the future that seems like a worthwhile goal. While I'm sure that we can come up with new and different was to apply meaning to global unicast addresses I think the world is a simpler place when we don't. joelja > Yours, > Joel > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From george+ipng@m5p.com Sun Feb 3 13:35: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 3067421F8629 for ; Sun, 3 Feb 2013 13:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q777T2c1Fn3X for ; Sun, 3 Feb 2013 13:35:45 -0800 (PST) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by ietfa.amsl.com (Postfix) with ESMTP id 86DFC21F83EF for ; Sun, 3 Feb 2013 13:35:45 -0800 (PST) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r13LZaC9091812 for ; Sun, 3 Feb 2013 16:35:41 -0500 (EST) (envelope-from george+ipng@m5p.com) Message-ID: <510ED828.1020301@m5p.com> Date: Sun, 03 Feb 2013 16:35:36 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120908 Thunderbird/15.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D action : draft-rafiee-6man-ssas-01 References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> <1359806574.6652.97.camel@karl> <000101ce018e$1ab13d10$5013b730$@rozanak.com> In-Reply-To: <000101ce018e$1ab13d10$5013b730$@rozanak.com> Content-Type: multipart/mixed; boundary="------------060701050004050706020402" X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 03 Feb 2013 16:35:43 -0500 (EST) 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, 03 Feb 2013 21:35:47 -0000 This is a multi-part message in MIME format. --------------060701050004050706020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/02/13 16:41, Hosnieh Rafiee wrote: > Thanks for your comments. Please find my responses inline. > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Karl > Auer > Sent: Saturday, February 02, 2013 1:03 PM > To: ipv6@ietf.org > Subject: Re: I-D action : draft-rafiee-6man-ssas-01 > >> http://tools.ietf.org/html/draft-rafiee-6man-ssas-01 > >> In the Abstract: I don't think the word "organitionally" exists. If it does > it is so unusual that it should be replaced with a more common word or with > a description of what the word means. > > Ok, I will correct it in next version. Maybe I created a new English word... > who knows ;-) How about "organizationally"? > [...] Administratively? -- George Mitchell --------------060701050004050706020402 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Envelope-From: ipv6-bounces@ietf.org Return-Path: Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:126c::1:1e]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r12LgFIh081880 for ; Sat, 2 Feb 2013 16:42:22 -0500 (EST) (envelope-from ipv6-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA66521F8584; Sat, 2 Feb 2013 13:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1359841319; bh=OG6oSDMRTDnuR//w2jmFLZH4gD6+/ElPFDEwdsiB2hE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Cc:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Content-Transfer-Encoding: Sender; b=xNWFIitNx4KKq+Zn4NrKLmO+tzOOEG5I1OqbE0rRAlqAqi72PpXx/0G1gnKgukq3/ CKAsAvM5+by1cIdcdCWg/eT04ZWUsD7Vk9w+hQ0D10rYDfzWKqUFY6LqjTlToamHLP z8z7tNPXSUADbxNP5+k4/v8Ts5cr07/BrIyqjXR0= 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 06E1621F8584 for ; Sat, 2 Feb 2013 13:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZXNVN5rolNk for ; Sat, 2 Feb 2013 13:41:55 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 021D421F8576 for ; Sat, 2 Feb 2013 13:41:55 -0800 (PST) Received: from kopoli (g225091013.adsl.alicedsl.de [92.225.91.13]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M4nob-1UtK1m3FJV-00zLno; Sat, 02 Feb 2013 16:41:52 -0500 From: "Hosnieh Rafiee" To: "'Karl Auer'" References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> <1359806574.6652.97.camel@karl> In-Reply-To: <1359806574.6652.97.camel@karl> Subject: RE: I-D action : draft-rafiee-6man-ssas-01 Date: Sat, 2 Feb 2013 22:41:42 +0100 Message-ID: <000101ce018e$1ab13d10$5013b730$@rozanak.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE0N4uUb+l+l5FmUNpdXfZEOh59LgHnPolUmYtKwMA= Content-Language: en-us X-Provags-ID: V02:K0:z1/u41L8zwVuTAX1LcVxtNqPx4+N988LXx0PSQHhqjf ZjGaI/JNdbJcJDUQxEYjYnU7G2HXkmoP4CJzCnUznSKkEnVFh/ gjwp3E7H9ZsV3zCG7E+kvfxNyKZmAcbelJIX45S5aSixHJnYft XbwEepeMImGJQ+Td0i6/J8/MQf0ETsaLm67ISdqPe/eyqNujx/ EiCFYIlmHz7+qXmC5YWJ7gTHW/ZHke33HnrLMBqBihzH0v6XIH TZ37fnVu9kZ1jWEmUkSktmyNir4csReRTpW5ixI+NLqD85Kby8 73keVoMFn5ysW52q1IaKHndHKwYcs0WIDTwR6HIbg3q5KmP91o B8y1CqnWQWrwORUeGf6s= 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Scanned-By: MIMEDefang 2.73 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sat, 02 Feb 2013 16:42:24 -0500 (EST) Thanks for your comments. Please find my responses inline. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Karl Auer Sent: Saturday, February 02, 2013 1:03 PM To: ipv6@ietf.org Subject: Re: I-D action : draft-rafiee-6man-ssas-01 > http://tools.ietf.org/html/draft-rafiee-6man-ssas-01 >In the Abstract: I don't think the word "organitionally" exists. If it does it is so unusual that it should be replaced with a more common word or with a description of what the word means. Ok, I will correct it in next version. Maybe I created a new English word... who knows ;-) How about "organizationally"? > CGA were not designed to address privacy related attacks, they are a means of securing NDP exchanges. The fact that they appear random is coincidental to their function. It is true that the main purpose was security, but it is not true that privacy was not a consideration. You can find in many parts of the CGA RFC (RFC 3972) where privacy is also mentioned. Some such sections are section 3, where it explains that the reason for the addition of a modifier is to enhance privacy by adding randomness to the address and at the end of section 4 and in section 7.3 where privacy considerations are clearly explained. >Introduction: Either always use leading zeros in your example values, or never, but don't mix them. I suggest that always using leading zeros would be better. Good point. I will do this. >MAC should always be capitalised: "MAC", not "Mac", throughout. Will correct this in the next version. >In your description of how an EUI-64 IID is formed, you have omitted the need to complement bit7 of the IID. You mean bits u and g (both 7 and 8). I'll add it. Of course these two bits are a matter for discussion in Brian's draft :-) >The introduction repeats the error in the abstract, that CGA addresses are "used to randomize the IID". In RFC Privacy Extension (section 3.2.3) and also CGA RFC (in stated sections), it also mentioned CGA as an approach to randomize IID >There are places where necessary spaces have been omitted: >"[RFC3315]can", "approachfor". The problem of my "spacebar" in keyboard, sometimes doesn't work and.... thx. I'll fix it in next version >The sentence beginning "This convention..." is unnecessary. I'll remove it >In the problem statement, the second sentence should read "...easy for an attacker to track that node as it moves between networks." Or similar, but it is unclear as it stands. Yes true. I'll update it. >"If one wants to use a secure method, with the privacy extension, then one needs to use CGA." Can one use CGA with privacy addressing? That is, can you have CGA addresses that change regularly, as privacy addresses do? I'm not sure. Yes you can. Please see my first response. > Spell check everything ("Deniel of Service", "deminished", etc) Ops... Ok, I'll correct it in next version. >"In order to overcome the problem with the other mechanisms,[...]" What other mechanisms? Isn't this just a problem with CGA? True, maybe I will have to rephrase the sentence. I wanted to address both privacy related attacks (privacy extension RFC) and also the problem with CGA. >"the time is needed to generate and verify IP address needs to be decreased" -> "the time required to generate and verify IP addresses needs to be reduced" >In 2.1.1.3 there is an odd character in "victim?s", should be "victim's". The same odd character appears in other places. ? will be replaced with ' . > In 2.1.1.3 suggest that the first SHOULD should be MAY. I'll correct it. >In 2.1.1.3, it is unclear whether the formula is provided as a helpful hint, or whether this is the formula that should be used. Why a 2-minute window? I suggest using language similar to other RFCs in >similar situations, e.g. "To mitigate such an attack, a node SHOULD rate limit message verification. Implementations MUST provide a conservative default and SHOULD provide a way for the rate >limiting parameters to be set by the node administrator." Good suggestion! I will apply it. >2.1.2 should provide an explanation of why SSAS is helpful in nodes with limited resources. It appears that it is not helpful per se, but is helpful *in comparison to CGA*, because of the lower >computational load. >An explanation is also needed for why SSAS is useful in mobile networks. I will clarify this section. >In the first para of section 3: Compute load is only a problem with CGA. >Privacy is only a problem with SLAAC (and maybe with CGA if a node uses the same 64-bit CGA IID on multiple networks). This introductory paragraph seems to just restate what has already been said >elsewhere and could probably be dropped anyway. Ok I will correct it. >3.1 step 2: There is no need to specify XML or any other particular storage method, format or location. These can be left to the implementation. All that is necessary is that these items be stored where >they will survive for the length of time a particular key pair will be in use. You need to address the situation where a node has no such storage. I think I really saw it from the implementers' point of view. You are right. I will change it. >3.1 step 2 second para: The use of should and SHOULD is confusing. >Should a node generate new keys? If it does, should it use them? If it isn't going to use them, why generate them? What happens when a new address is generated - is it used alongside the old one or >are current connections using the old address dropped immediately? The loss of active connections when an address changes might be worth mentioning somewhere. The old IP address status is changed to deprecated. This means the node will not use it for the new connection but it can continue using it for the old connections. When the node generates a new IP address, it should also re-generate public/private keys because of the privacy concerns. > 3.1 step 2: Either the encryption algorithms used must be stipulated, or there must be some mechanism for the verifier to know what method was used by the sender. I will add a bit to the SSAS data structure in order to distinguish between RSA and ECC or other faster algorithms of the future. > 3.1 step 3: What is "a fixed point format"? Needs explanation. If there is more than one possible "fixed point format" then the specific one used by SSAS must be specified. I explained in the draft that we are using the same format as RFC SEND. > 3.1 step 5: Why is a whole byte needed to store a value from 0 to 20? >Have you done the maths to check that this value will actually meaningfully "[help] randomize the IID and [...] minimize the chance of a collision in the network"? If the benefit is not significant, then >this step should be omitted. Yes , it does. >3.1 step 10 "this IP will be permanent after..." This contradicts earlier recommendations that the IP be changed after a certain period. I meant the status of the IP address. The first status will be temporary and if no collisions are found the status will change to permanent. The 3 statuses for an IP address are deprecated, temporary and permanent. This defines how the IP address can be used at the start of new connections or its use in existing connections. Each IP address has a lifetime. When the lifetime of the IP address has expired, the node changes the status of the IP address to deprecated. I will add the status and add this explanation to the new version. >3.2 This needs to be clearer. It seems that you are describing the components of the NDP message that will be signed, not items that will actually be included in the signature. Either way, it seems to me >that a list of components should be provided for each NDP message type that requires signing, with a default to cover all others and any that have not yet been invented. True. Maybe instead of NDP, I have to change it to SEND. Then it might be clearer. > 3.3 How does a recipient know whether a message is SEND+SSAS or just SEND? In SSAS, just the RSA signature is different than the RSA signature section of SEND. I will think about using another type, like type=16, for SSAS Data field (signature and...). >3.3.1: Length is described as including certain fields; the description does NOT include certain other fields, such as subnet prefix, other options. It seems to me that length can simply be described as >"the length of the signature data field". Might be an idea to specify the units, eg "length in octets". Good suggestion. >3.3.1 Padding would be more simply described by saying that "if the above values do not form an SSAS signature field that is an exact multiple of eight octets long, random octets are added to the end >of the signature field to bring its length up to an exact multiple of eight octets." Or octets with the binary value zero, or whatever. Good suggestion. >3.3.1: "If, for a second time, the node receives the same claim, then it considers it an attack and will use that IP address." Why? And why two? >Is this because no two nodes should ever be able to generate the same address? If so, then either one try is sufficient, or arbitrarily many will be insufficient. There have been no proven collisions using SHA256. Also, it will be a very rare case when two nodes choose the same modifier and even rarer If, after a node increments the modifier after the first collision, another node will have the IP address. > 4: This seems to need a bit of bulking out. Also, the discussion of trust anchors is unclear - what, if any, place do trust anchors have in SSAS? Might be worth discussing how shorter key validity periods > affect the likelihood of a successful attack. I will clarify the section describing trust anchors. About successful attacks, in practice, it is not like theoretical proofs; the probability is very low. I obtained that mathematical proof by finding the expected value for 2 days, 10 days, and also 20 days... . >5. Is that an IAN consideration? It might be. >6. This section repeats the error that CGA is about randomising IIDs. It is not, that's a side effect at best. Please refer to my first response Thank you. I really cannot understand how I made so many spelling mistakes, especially when I had a text correctors in front of me... :-/ or perhaps sleepy!? Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------060701050004050706020402-- From rogerj@gmail.com Sun Feb 3 13:40: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 59B6521F85A4 for ; Sun, 3 Feb 2013 13:40:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvZDezl2aa6v for ; Sun, 3 Feb 2013 13:40:32 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2E72021F889D for ; Sun, 3 Feb 2013 13:40:32 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so4415702wey.0 for ; Sun, 03 Feb 2013 13:40:31 -0800 (PST) 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=csULrkGwcLxb8nX/UXTa+AohJM0voIyfrF9efOqEaBY=; b=VrAmhHM8KBlxwKIWU6reQlU2lrj1DnOsKVL8Mlf+AtF7g0h0tMPVWtYLznE9ex76lg w3biTWcqZYm/oe0oftRC4PI9TmvIKboFxyTxFV/QarjUM6D+u3k4gBkiqzGEbtJT2pXK RXA9yYVF9JiHuofTnYwkhrNaqvui/pWiHGTpCgHy/WbAPzqcxxnFMGgBY8pxaNEuNiuA PsousYXZeK/Zh+QWV2Ggad3QlU/pycTTlMNrP48/7HJz8C6gjEESbxOgixe8VV+ow+Mc xRhkBRmrWXaQbXNjv3xs/mmh12yRsgutCVaXdMvzrvl0UtHlJh7aR23WowaFB6yzrliJ zb4A== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr176873wiw.21.1359927631256; Sun, 03 Feb 2013 13:40:31 -0800 (PST) Received: by 10.217.44.74 with HTTP; Sun, 3 Feb 2013 13:40:31 -0800 (PST) In-Reply-To: <510ECF17.8020802@bogus.com> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> Date: Sun, 3 Feb 2013 22:40:31 +0100 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: 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: Sun, 03 Feb 2013 21:40:33 -0000 On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli wrote: > On 2/3/13 11:39 AM, Joel M. Halpern wrote: >> On 2/3/2013 2:36 PM, Brian E Carpenter wrote: >>> On 03/02/2013 17:26, Joel M. Halpern wrote: >>>> >>>> To a significant degree Randy, I agree with you in your comment about >>>> magic bits. If I were designing IPv6 from scratch (counter-factual in >>>> so may ways at once) I would not do it that way. >>>> >>>> But, unless there is an actual problem with the design the IETF has >>>> adopted, I am reluctant to change it "just because". >>> >>> >>> Which is why the draft actually proposes nothing that would change >>> any running code. >>> >>> Brian >> >> >> But it does propose to change the spec. Why? What problem does changing >> the spec solve? > > If it prevents someone from ascribing new utility to these bit(s) in the > future that seems like a worthwhile goal. While I'm sure that we can come up > with new and different was to apply meaning to global unicast addresses I > think the world is a simpler place when we don't. KISS is always a good approach - Keep It Stupid Simple, or Simple Stupid. (or in short, special meaning attached to bits seems to cause more confusion than good) And on the topic of DAD vs assume uniqueness - I learned this from an earlier colleague "To Assume is to make an Ass out of you and Me" -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From kauer@biplane.com.au Sun Feb 3 14:58: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 3719B21F8464 for ; Sun, 3 Feb 2013 14:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1+-IZmRdTuX for ; Sun, 3 Feb 2013 14:58:42 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 65D6321F8446 for ; Sun, 3 Feb 2013 14:58:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAOjpDlGWZX+7/2dsb2JhbAANN79JgxIBAQEEgQkLGC5XGbQ4kkOOKYMpA4gwmTGIHw Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 04 Feb 2013 09:28:38 +1030 Message-ID: <1359932317.6652.195.camel@karl> Subject: Re: I-D action : draft-rafiee-6man-ssas-01 From: Karl Auer To: ipv6@ietf.org Date: Mon, 04 Feb 2013 09:58:37 +1100 In-Reply-To: <510ED828.1020301@m5p.com> References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> <1359806574.6652.97.camel@karl> <000101ce018e$1ab13d10$5013b730$@rozanak.com> <510ED828.1020301@m5p.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: Sun, 03 Feb 2013 22:58:43 -0000 On Sun, 2013-02-03 at 16:35 -0500, George Mitchell wrote: > >> In the Abstract: I don't think the word "organitionally" exists. > Administratively? The word is unnecessary anyway. Just leave it out. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog 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 randy@psg.com Sun Feb 3 16:41: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 427B221F880E for ; Sun, 3 Feb 2013 16:41:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSXbgNnPbm9p for ; Sun, 3 Feb 2013 16:41:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DCEE521F8806 for ; Sun, 3 Feb 2013 16:41:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U2A80-0002MN-Pq; Mon, 04 Feb 2013 00:41:45 +0000 Date: Mon, 04 Feb 2013 09:41:43 +0900 Message-ID: From: Randy Bush To: "Joel M. Halpern" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] In-Reply-To: <510E9DD3.2050907@joelhalpern.com> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention 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, 04 Feb 2013 00:41:49 -0000 > To a significant degree Randy, I agree with you in your comment about > magic bits. If I were designing IPv6 from scratch (counter-factual in > so may ways at once) I would not do it that way. > > But, unless there is an actual problem with the design the IETF has > adopted, I am reluctant to change it "just because". i know. ipv6 is perfect, widely deployed, and unchangable. i hope we all like v4 nat. randy From huitema@microsoft.com Sun Feb 3 18:00: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 5730A21F8865 for ; Sun, 3 Feb 2013 18:00:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWYVSzmVpDdK for ; Sun, 3 Feb 2013 18:00:48 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id B071D21F885C for ; Sun, 3 Feb 2013 18:00:48 -0800 (PST) Received: from BL2FFO11FD003.protection.gbl (10.173.161.202) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.609.9; Mon, 4 Feb 2013 02:00:39 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Mon, 4 Feb 2013 02:00:38 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.84]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Mon, 4 Feb 2013 02:00:36 +0000 From: Christian Huitema To: Randy Bush , "Joel M. Halpern" Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Thread-Index: AQHOAFP6U45YIPsCGUaCxJT4NY+RKJhlcHiAgABK6oCAAISPAIAAkdeAgAECAwCAABIZgIAAgLiAgAB5ioCAABMP4A== Date: Mon, 4 Feb 2013 02:00:35 +0000 Message-ID: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.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.37] 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)(2473001)(51704002)(76482001)(47776003)(20776003)(16406001)(54316002)(56776001)(63696002)(4396001)(55846006)(53806001)(54356001)(79102001)(56816002)(46102001)(46406002)(33656001)(47446002)(31966008)(74502001)(47736001)(44976002)(74662001)(50466001)(59766001)(51856001)(77982001)(49866001)(23726001)(50986001)(47976001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:3; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07473990A5 Cc: IPv6 Deployment Prevention 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, 04 Feb 2013 02:00:49 -0000 >> But, unless there is an actual problem with the design the IETF has=20 >> adopted, I am reluctant to change it "just because". > > i know. ipv6 is perfect, widely deployed, and unchangable. i hope we al= l like v4 nat. I can find many reasons to remove the magic from the U and G bits. I person= ally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC 6052 (IPv4-e= mbedded IPv6 addresses). In both cases, the design would have been simpler = if we had not try to maintain the fiction of the U and G bits. And CGA coul= d definitely benefit from 2 additional bits of entropy. So this is not a ch= ange "just because."=20 -- Christian Huitema From randy@psg.com Sun Feb 3 18:18: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 9934121F892C for ; Sun, 3 Feb 2013 18:18:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ImQUPr-hp1S for ; Sun, 3 Feb 2013 18:18:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3324B21F842A for ; Sun, 3 Feb 2013 18:18:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U2Bde-0002nZ-9B; Mon, 04 Feb 2013 02:18:30 +0000 Date: Mon, 04 Feb 2013 11:18:29 +0900 Message-ID: From: Randy Bush To: Christian Huitema Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] In-Reply-To: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention 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, 04 Feb 2013 02:18:35 -0000 >> i know. ipv6 is perfect, widely deployed, and unchangable. i hope >> we all like v4 nat. > I can find many reasons to remove the magic from the U and G bits. I > personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC > 6052 (IPv4-embedded IPv6 addresses). In both cases, the design would > have been simpler if we had not try to maintain the fiction of the U > and G bits. And CGA could definitely benefit from 2 additional bits of > entropy. So this is not a change "just because." a prospective implementor looks at ipv6 and sees a whole bunch of twisty passages of useless second system syndrome. there are more damn options than the chicago mercantile exchange. and as there is no *strong* pull from the market, all our pleas do not transform income you can sell to your management. when multiple layers of ipv4 nat is financially more attractive than our product, we have a very serious problem. we need to wipe the lipstick off the pig and start selling straightforward port chops. except i fear it is far too late. randy From hesham@elevatemobile.com Sun Feb 3 20:13: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 6188E21F8A25 for ; Sun, 3 Feb 2013 20:13:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvbO-O1TcClC for ; Sun, 3 Feb 2013 20:13:22 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8E04A21F895B for ; Sun, 3 Feb 2013 20:13:21 -0800 (PST) Received: from [118.209.143.134] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1U2DQY-0008RS-95; Mon, 04 Feb 2013 15:13:06 +1100 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 04 Feb 2013 15:12:54 +1100 Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: Hesham Soliman To: Christian Huitema , Randy Bush , "Joel M. Halpern" Message-ID: Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com 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, 04 Feb 2013 04:13:23 -0000 >>>But, unless there is an actual problem with the design the IETF has >>> adopted, I am reluctant to change it "just because". >> >> i know. ipv6 is perfect, widely deployed, and unchangable. i hope we >>all like v4 nat. > >I can find many reasons to remove the magic from the U and G bits. I >personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC 6052 >(IPv4-embedded IPv6 addresses). In both cases, the design would have been >simpler if we had not try to maintain the fiction of the U and G bits. >And CGA could definitely benefit from 2 additional bits of entropy. So >this is not a change "just because." => +1 on CGA and Teredo. I never agreed/understood the need for u/g bits. The concept was flawed IMHO. I respect the questioning of timing but on principle those two flags are a bad idea. Hesham > >-- Christian Huitema > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From sthaug@nethelp.no Sun Feb 3 23:52: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 3A52521F8865 for ; Sun, 3 Feb 2013 23:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMqWagUdCkWX for ; Sun, 3 Feb 2013 23:52:44 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 988DA21F884F for ; Sun, 3 Feb 2013 23:52:43 -0800 (PST) Received: (qmail 26639 invoked from network); 4 Feb 2013 07:52:41 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Feb 2013 07:52:41 -0000 Date: Mon, 04 Feb 2013 08:52:41 +0100 (CET) Message-Id: <20130204.085241.74728256.sthaug@nethelp.no> To: huitema@microsoft.com Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: sthaug@nethelp.no In-Reply-To: References: <510E9DD3.2050907@joelhalpern.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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, 04 Feb 2013 07:52:45 -0000 > I can find many reasons to remove the magic from the U and G bits. I personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC 6052 (IPv4-embedded IPv6 addresses). In both cases, the design would have been simpler if we had not try to maintain the fiction of the U and G bits. And CGA could definitely benefit from 2 additional bits of entropy. So this is not a change "just because." Fully agreed. Another point in favor of removing the magic: RFC 4291 explicitly says "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." but later in the same chapter says "IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique." And indeed, on the routers where I have tried, I am able to configure static IPv6 addresses with no regard to the u/g bits. In other words, any special meaning of the u/g bits is just fiction - there is no enforcement or guarantee of any kind. Steinar Haug, AS 2116 From jmh.direct@joelhalpern.com Sun Feb 3 19:54: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 E3F3721F89EE for ; Sun, 3 Feb 2013 19:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzWJQs-kp8yf for ; Sun, 3 Feb 2013 19:54:52 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8673E21F89AE for ; Sun, 3 Feb 2013 19:54:52 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 1BBE4557FAD for ; Sun, 3 Feb 2013 19:54:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D05AE1C073C; Sun, 3 Feb 2013 19:54:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from localhost (mobile-198-228-227-154.mycingular.net [198.228.227.154]) by mailb2.tigertech.net (Postfix) with ESMTPA id 991DF1C0538; Sun, 3 Feb 2013 19:54:50 -0800 (PST) Date: Sun, 03 Feb 2013 22:54:44 -0500 Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Message-ID: Importance: low From: "Jmh.direct" To: randy@psg.com, jmh@joelhalpern.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_91797128367292" X-Mailman-Approved-At: Mon, 04 Feb 2013 00:02:49 -0800 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, 04 Feb 2013 03:54:53 -0000 ----_com.android.email_91797128367292 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhdCBpcyBub3Qgd2hhdCBJIHNhaWQuIMKgQ2hyaXN0aWFuLCB0aGFuayB5b3UsIHRoYXQgaXMg dGhlIGtpYmQgb2YgaW5mb3JtYXRpb24gSSB3YXMgbG9va2luZyBmb3IsIGFuZCBleHBlY3QgaW4g dGhlIGRyYWZ0IG9yIGZyb20gdGhlIGF1dGhvcnMuCgpZb3VycywKSm9lbAoKClNlbnQgZnJvbSBt eSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmVAoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAt LS0tLS0tLQpTdWJqZWN0OiBSZTogW0Z3ZDogSS1EIEFjdGlvbjogZHJhZnQtY2FycGVudGVyLTZt YW4tdWctMDAudHh0XSAKRnJvbTogUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNvbT4gClRvOiAiSm9l bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gCkNDOiBCcmlhbiBFIENhcnBlbnRl ciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPixJUHY2IERlcGxveW1lbnQgUHJldmVudGlv biA8aXB2NkBpZXRmLm9yZz4gCgo+IFRvIGEgc2lnbmlmaWNhbnQgZGVncmVlIFJhbmR5LCBJIGFn cmVlIHdpdGggeW91IGluIHlvdXIgY29tbWVudCBhYm91dCAKPiBtYWdpYyBiaXRzLsKgIElmIEkg d2VyZSBkZXNpZ25pbmcgSVB2NiBmcm9tIHNjcmF0Y2ggKGNvdW50ZXItZmFjdHVhbCBpbiAKPiBz byBtYXkgd2F5cyBhdCBvbmNlKSBJIHdvdWxkIG5vdCBkbyBpdCB0aGF0IHdheS4KPiAKPiBCdXQs IHVubGVzcyB0aGVyZSBpcyBhbiBhY3R1YWwgcHJvYmxlbSB3aXRoIHRoZSBkZXNpZ24gdGhlIElF VEYgaGFzIAo+IGFkb3B0ZWQsIEkgYW0gcmVsdWN0YW50IHRvIGNoYW5nZSBpdCAianVzdCBiZWNh dXNlIi4KCmkga25vdy7CoCBpcHY2IGlzIHBlcmZlY3QsIHdpZGVseSBkZXBsb3llZCwgYW5kIHVu Y2hhbmdhYmxlLsKgIGkgaG9wZSB3ZQphbGwgbGlrZSB2NCBuYXQuCgpyYW5keQo= ----_com.android.email_91797128367292 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5UaGF0IGlzIG5vdCB3aGF0IEkgc2Fp ZC4gJm5ic3A7Q2hyaXN0aWFuLCB0aGFuayB5b3UsIHRoYXQgaXMgdGhlIGtpYmQgb2YgaW5mb3Jt YXRpb24gSSB3YXMgbG9va2luZyBmb3IsIGFuZCBleHBlY3QgaW4gdGhlIGRyYWZ0IG9yIGZyb20g dGhlIGF1dGhvcnMuPGRpdj48YnI+PC9kaXY+PGRpdj5Zb3Vycyw8L2Rpdj48ZGl2PkpvZWw8YnI+ PGJyPjxicj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjg3JSI+U2VudCBmcm9tIG15IFNhbXN1bmcg c21hcnRwaG9uZSBvbiBBVCZhbXA7VDwvc3Bhbj4gPC9kaXY+PGJyPjxicj48YnI+LS0tLS0tLS0g T3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj5TdWJqZWN0OiBSZTogW0Z3ZDogSS1EIEFjdGlv bjogZHJhZnQtY2FycGVudGVyLTZtYW4tdWctMDAudHh0XSA8YnI+RnJvbTogUmFuZHkgQnVzaCAm bHQ7cmFuZHlAcHNnLmNvbSZndDsgPGJyPlRvOiAiSm9lbCBNLiBIYWxwZXJuIiAmbHQ7am1oQGpv ZWxoYWxwZXJuLmNvbSZndDsgPGJyPkNDOiBCcmlhbiBFIENhcnBlbnRlciAmbHQ7YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tJmd0OyxJUHY2IERlcGxveW1lbnQgUHJldmVudGlvbiAmbHQ7aXB2 NkBpZXRmLm9yZyZndDsgPGJyPjxicj48YnI+PGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1h bGw7Ij4mZ3Q7IFRvIGEgc2lnbmlmaWNhbnQgZGVncmVlIFJhbmR5LCBJIGFncmVlIHdpdGggeW91 IGluIHlvdXIgY29tbWVudCBhYm91dCA8YnI+Jmd0OyBtYWdpYyBiaXRzLiZuYnNwOyBJZiBJIHdl cmUgZGVzaWduaW5nIElQdjYgZnJvbSBzY3JhdGNoIChjb3VudGVyLWZhY3R1YWwgaW4gPGJyPiZn dDsgc28gbWF5IHdheXMgYXQgb25jZSkgSSB3b3VsZCBub3QgZG8gaXQgdGhhdCB3YXkuPGJyPiZn dDsgPGJyPiZndDsgQnV0LCB1bmxlc3MgdGhlcmUgaXMgYW4gYWN0dWFsIHByb2JsZW0gd2l0aCB0 aGUgZGVzaWduIHRoZSBJRVRGIGhhcyA8YnI+Jmd0OyBhZG9wdGVkLCBJIGFtIHJlbHVjdGFudCB0 byBjaGFuZ2UgaXQgImp1c3QgYmVjYXVzZSIuPGJyPjxicj5pIGtub3cuJm5ic3A7IGlwdjYgaXMg cGVyZmVjdCwgd2lkZWx5IGRlcGxveWVkLCBhbmQgdW5jaGFuZ2FibGUuJm5ic3A7IGkgaG9wZSB3 ZTxicj5hbGwgbGlrZSB2NCBuYXQuPGJyPjxicj5yYW5keTxicj48L2Rpdj4gPC9ib2R5Pg== ----_com.android.email_91797128367292-- From brian.e.carpenter@gmail.com Mon Feb 4 00:16: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 2CC7721F88E5 for ; Mon, 4 Feb 2013 00:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.421 X-Spam-Level: X-Spam-Status: No, score=-99.421 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azRLf3HJO+jj for ; Mon, 4 Feb 2013 00:16:50 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD7321F874B for ; Mon, 4 Feb 2013 00:16:49 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x48so4444745wey.23 for ; Mon, 04 Feb 2013 00:16:49 -0800 (PST) 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=+28Iw1cRqzEkGkO9PGEGfpauOeVfLoM9PagHCHwNPvM=; b=E4SdzwWAG6qqNXJpilhgnYsoDhLjbOC4x5g3YuZfWb+Lu2sOaXHdNWf8N11y3AUXS+ 3PY3DTpwXaXNvHTPqr47wM6H78XvPqvQIIyrUaYjevdkTpz1meBqvQwJRhRxx19m2CSy /V8p4kgSwGVB21IBGrGJnD8rmc2mEwA1ZpcqdhLbkp6xaT9Jma0o+5cwNVJ1FZZUlQ11 wtaqkbRZ2dmMEZY0pR1M5ZPfq8gKXyzkYC+2p/GdL1rfA2TM+E2yanoKfFWcZgpxaJYM LbTpXOCwn3l2S7AUVcpOspl4ADsOYlo2o0FEqVdxfZb7VgIm6yQ05ctAjfetiztHPlqe 4GhA== X-Received: by 10.180.81.39 with SMTP id w7mr8735902wix.15.1359965809265; Mon, 04 Feb 2013 00:16:49 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-53.as13285.net. [2.101.189.53]) by mx.google.com with ESMTPS id ec3sm13323478wib.1.2013.02.04.00.16.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 00:16:48 -0800 (PST) Message-ID: <510F6E71.6010306@gmail.com> Date: Mon, 04 Feb 2013 08:16:49 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510E9DD3.2050907@joelhalpern.com> <20130204.085241.74728256.sthaug@nethelp.no> In-Reply-To: <20130204.085241.74728256.sthaug@nethelp.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: huitema@microsoft.com, 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, 04 Feb 2013 08:16:51 -0000 On 04/02/2013 07:52, sthaug@nethelp.no wrote: >> I can find many reasons to remove the magic from the U and G bits. I personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC 6052 (IPv4-embedded IPv6 addresses). In both cases, the design would have been simpler if we had not try to maintain the fiction of the U and G bits. And CGA could definitely benefit from 2 additional bits of entropy. So this is not a change "just because." > > Fully agreed. > > Another point in favor of removing the magic: RFC 4291 explicitly says > > "For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." > > but later in the same chapter says > > "IPv6 nodes are not required to validate that interface identifiers > created with modified EUI-64 tokens with the "u" bit set to universal > are unique." > > And indeed, on the routers where I have tried, I am able to configure > static IPv6 addresses with no regard to the u/g bits. > > In other words, any special meaning of the u/g bits is just fiction - > there is no enforcement or guarantee of any kind. Right. The draft may be clumsily expressed so far, but that is the point. I think we know how we have to improve the draft to make these things more clear. Please give us a little time, since my co-author is on vacation for the Chinese New Year holidays. Brian From despres.remi@laposte.net Mon Feb 4 00:38: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 8102421F855C for ; Mon, 4 Feb 2013 00:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XdXMU9zBebb for ; Mon, 4 Feb 2013 00:38:42 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB1521F855D for ; Mon, 4 Feb 2013 00:38:42 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id E62497000070; Mon, 4 Feb 2013 09:38:40 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 57A16700008E; Mon, 4 Feb 2013 09:38:40 +0100 (CET) X-SFR-UUID: 20130204083840359.57A16700008E@msfrf2302.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510E4D7C.5020307@gmail.com> Date: Mon, 4 Feb 2013 09:38:38 +0100 Message-Id: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> To: Brian Carpenter , Bob Hinden X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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, 04 Feb 2013 08:38:43 -0000 Brian, Bob, 2013-02-03 12:43, Brian E Carpenter : > On 03/02/2013 10:57, R=E9mi Despr=E9s wrote: >> Le 2013-02-02 =E0 18:17, Joel M. Halpern a = =E9crit : >>=20 >>> I a not clear what aspect of the semantics of u=3D=3D1 and the = relationship to EUI-64 is a dead duck. Currently, if you see something = with u=3D=3D1, you know it was made from an EUI-64. Under your = proposal, you would not know that. >>> Yous tae below tat the presence of =3D=3D1 doesn't mean that. to = the best of my knowledge, currently, it does mean that. It may not be = derived from the EUI-64 of the interface yo want to reach, but it is = derived from an EUI-64. Otherwise, u would be set to 0. >>>=20 >>> You are proposing to change this rule. >>=20 >> Same understanding. >> u=3D1 has a meaning that shouldn't be negated now. >>=20 >>> Aside from anything else, I do not see a motivation for changing the = rule. >=20 > Actually, I don't think that is what the draft proposes. What it = proposes > is that we delete > the fiction that the bit has any meaning after it arrives > in an IID. Serious disagreement with the extreme view that, today, the u bit has no = meaning. See (*) and (**) below. > It seems to be that fiction that causes confusion, not the > rule about how to generate Modified EUI-64 format from a MAC address. >=20 > Quoting a wise colleague, "magic bits are almost never worth the = pain." Agreed. But the u bit isn't "magic".=20 It is just a bit whose function has been specified (and used, see (*) = below). > To say it again in different words, u=3D=3D1 does not prove that an = IID is > universally unique Agreed. (*) It remains that IIDs having u=3D1 SHOULD be unique, i.e. with rare = enough exceptions. This is somewhat similar to the expectation that ULA = collisions shouldn't be seen). This theoretical unicity has been extensively used to assign stable = IIDs, without administrative action, to hosts that have no privacy = constraints requiring the opposite. =20 If our understanding differs on this, I suppose we should go further = into it.=20 > and u=3D=3D0 does not prove that an IID is locally unique. Agreed. > So it's fine to specify methods for generating the u bit, but it is > incorrect to draw firm conclusions based on its value. Disagreed. Here is one "firm" conclusion, and a useful one AFAIK to "allow = development of future technology that can take advantage of interface = identifiers with universal scope": (**) "All IIDs that comply with RFC 4291, that have u=3D1, and that are = based on an IEEE MAC address, also have g=3D0 and bits 24-39 =3D 0xFE." Disagreeing on this would need an explanation. Conclusion: your ug draft, which is IMHO welcome to clarify what seems = misunderstood, must be clear about issue (*) and (**) above, one way or = another. Steps backward without carefully checked justifications should be = avoided. Regards, RD From despres.remi@laposte.net Mon Feb 4 00:47: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 398B921F85BB for ; Mon, 4 Feb 2013 00:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-+FlEEeoHmL for ; Mon, 4 Feb 2013 00:46:59 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 857E221F85B2 for ; Mon, 4 Feb 2013 00:46:59 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id E80107000075; Mon, 4 Feb 2013 09:46:58 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id D32C37000071; Mon, 4 Feb 2013 09:46:58 +0100 (CET) X-SFR-UUID: 20130204084658865.D32C37000071@msfrf2302.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510EBCF5.1050705@joelhalpern.com> Date: Mon, 4 Feb 2013 09:46:58 +0100 Message-Id: <88CAE29A-5E2A-4410-8DBD-57FBD844966B@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> To: Brian Carpenter X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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, 04 Feb 2013 08:47:00 -0000 2013-02-03 =E0 20:39, Joel M. Halpern : >=20 >=20 > On 2/3/2013 2:36 PM, Brian E Carpenter wrote: >> On 03/02/2013 17:26, Joel M. Halpern wrote: >>> To a significant degree Randy, I agree with you in your comment = about >>> magic bits. If I were designing IPv6 from scratch (counter-factual = in >>> so may ways at once) I would not do it that way. >>>=20 >>> But, unless there is an actual problem with the design the IETF has >>> adopted, I am reluctant to change it "just because". >>=20 >> Which is why the draft actually proposes nothing that would change >> any running code. >>=20 >> Brian >=20 > But it does propose to change the spec. Why? What problem does = changing the spec solve? Same question. RD >=20 > Yours, > Joel > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From despres.remi@laposte.net Mon Feb 4 01:11: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 65BBD21F8619 for ; Mon, 4 Feb 2013 01:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Trq79PtAKyxd for ; Mon, 4 Feb 2013 01:11:31 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5613B21F85DC for ; Mon, 4 Feb 2013 01:11:31 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id 416117001881; Mon, 4 Feb 2013 10:11:30 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id E6AEC700009F; Mon, 4 Feb 2013 10:11:29 +0100 (CET) X-SFR-UUID: 20130204091129944.E6AEC700009F@msfrf2316.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 4 Feb 2013 10:11:29 +0100 Message-Id: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> To: Roger =?iso-8859-1?q?J=F8rgensen?= X-Mailer: Apple Mail (2.1499) 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: Mon, 04 Feb 2013 09:11:37 -0000 Hi, Roger, Please see inline. 2013-02-03 22:40, Roger J=F8rgensen : > On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli wrote: >> On 2/3/13 11:39 AM, Joel M. Halpern wrote: >>> On 2/3/2013 2:36 PM, Brian E Carpenter wrote: >>>> On 03/02/2013 17:26, Joel M. Halpern wrote: >>>>>=20 >>>>> To a significant degree Randy, I agree with you in your comment = about >>>>> magic bits. If I were designing IPv6 from scratch = (counter-factual in >>>>> so may ways at once) I would not do it that way. >>>>>=20 >>>>> But, unless there is an actual problem with the design the IETF = has >>>>> adopted, I am reluctant to change it "just because". >>>>=20 >>>>=20 >>>> Which is why the draft actually proposes nothing that would change >>>> any running code. >>>>=20 >>>> Brian >>>=20 >>>=20 >>> But it does propose to change the spec. Why? What problem does = changing >>> the spec solve? >>=20 >> If it prevents someone from ascribing new utility to these bit(s) in = the >> future that seems like a worthwhile goal. While I'm sure that we can = come up >> with new and different was to apply meaning to global unicast = addresses I >> think the world is a simpler place when we don't. It depends on what is done with the new design, especially if it is = backward compatible and optional. The question that started this discussion is whether reserving a = currently unused IID range having u=3D1 is compatible with the IPv6 = addressing architecture (i.e. RFC 4291).=20 AFAICT, the answer is YES. Changing RFC 4291 to make it become a NO would have consequences well = beyond this new request.=20 > KISS is always a good approach - Keep It Stupid Simple, or Simple = Stupid. Agreed. > (or in short, special meaning attached to bits seems to cause more > confusion than good) - Not a consequence of KISS. - Changing a specification without a pressing need, and although it has = been used, isn't a way to increase confidence in any design. IPv6 needs = confidence. > And on the topic of DAD vs assume uniqueness - I learned this from an > earlier colleague No one proposes to abandon DAD! The point is that, while a specification *clarification* on u/g appears = to be useful, specification *change* would be harmful. Regards, RD =20 From despres.remi@laposte.net Mon Feb 4 01:42: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 685FA21F8619 for ; Mon, 4 Feb 2013 01:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go5csAXm5XZQ for ; Mon, 4 Feb 2013 01:42:03 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id A0F3E21F85C3 for ; Mon, 4 Feb 2013 01:42:03 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 3411B70000A7; Mon, 4 Feb 2013 10:42:02 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id D129170000A2; Mon, 4 Feb 2013 10:42:01 +0100 (CET) X-SFR-UUID: 20130204094201856.D129170000A2@msfrf2206.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 4 Feb 2013 10:42:01 +0100 Message-Id: <6BD7F1B3-FC28-48C2-84E7-26D7F6D26BDD@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> To: Randy Bush X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Deployment Prevention 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, 04 Feb 2013 09:42:04 -0000 Randy,=20 We have in common, as you know, the objective of IPv6 promotion, and = that of NATs elimination as much as possible. In this respect, changing now the IPv6 specification for hosts that = configure IIDs having u=3D1, although no serious need has been = identified, and this specification has ben used, would be in my = understanding very counterproductive: stability of already used = specifications is important for their success. =3D> Concerning u/g bits: - OK to clarify what can easily be misunderstood - NOK to change the substance of the specification Hope you can agree. Regards, RD 2013-02-04 03:18, Randy Bush : >>> i know. ipv6 is perfect, widely deployed, and unchangable. i hope >>> we all like v4 nat. >> I can find many reasons to remove the magic from the U and G bits. I >> personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC >> 6052 (IPv4-embedded IPv6 addresses). In both cases, the design would >> have been simpler if we had not try to maintain the fiction of the U >> and G bits. And CGA could definitely benefit from 2 additional bits = of >> entropy. So this is not a change "just because." >=20 > a prospective implementor looks at ipv6 and sees a whole bunch of = twisty > passages of useless second system syndrome. there are more damn = options > than the chicago mercantile exchange. and as there is no *strong* = pull > from the market, all our pleas do not transform income you can sell to > your management. >=20 > when multiple layers of ipv4 nat is financially more attractive than = our > product, we have a very serious problem. we need to wipe the lipstick > off the pig and start selling straightforward port chops. >=20 > except i fear it is far too late. >=20 > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Mon Feb 4 01:42: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 77A4821F8688 for ; Mon, 4 Feb 2013 01:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhYh3m4LPA03 for ; Mon, 4 Feb 2013 01:42:09 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 74F8F21F8684 for ; Mon, 4 Feb 2013 01:42:09 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2IYH-000436-TE; Mon, 04 Feb 2013 10:41:44 +0100 Message-ID: <510F823E.7080100@si6networks.com> Date: Mon, 04 Feb 2013 06:41:18 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 04 Feb 2013 09:42:10 -0000 On 02/04/2013 06:11 AM, Rémi Després wrote: > > It depends on what is done with the new design, especially if it is backward compatible and optional. > > The question that started this discussion is whether reserving a currently unused IID range having u=1 is compatible with the IPv6 addressing architecture (i.e. RFC 4291). > AFAICT, the answer is YES. I believe that the original question really was "whether it makes sense to reserve an unused IID range for 4rd". As noted by Ran Atkinson, since 4rd is an experimental document, it seems more appropriate to separate a *shared* range for this kind of experiment, rather than assign an IID range to 4rd. 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 Feb 4 01:46: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 E04D521F85B1 for ; Mon, 4 Feb 2013 01:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuKuhEE357xX for ; Mon, 4 Feb 2013 01:46:54 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4A71521F842D for ; Mon, 4 Feb 2013 01:46:54 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2IdK-0004Af-Ru; Mon, 04 Feb 2013 10:46:39 +0100 Message-ID: <510F5ABF.1030000@si6networks.com> Date: Mon, 04 Feb 2013 03:52:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: I-D action : draft-rafiee-6man-ssas-01 References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> <1359806574.6652.97.camel@karl> <000101ce018e$1ab13d10$5013b730$@rozanak.com> In-Reply-To: <000101ce018e$1ab13d10$5013b730$@rozanak.com> 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, 04 Feb 2013 09:46:55 -0000 Hosnieh, On 02/02/2013 06:41 PM, Hosnieh Rafiee wrote: > >> CGA were not designed to address privacy related attacks, they are a means > of securing NDP exchanges. The fact that they appear random is coincidental > to their function. > > It is true that the main purpose was security, but it is not true that > privacy was not a consideration. It can't be a consideration, because in order for CGAs to serve their purpose, nodes must be able to compute the IID. An IID that aims at protecting user privacy works the other way around: a third-party should not be able to compute the IID. Cheers, -- 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 Feb 4 01:47: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 DFE8221F8694 for ; Mon, 4 Feb 2013 01:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nczsFzveVlBM for ; Mon, 4 Feb 2013 01:47:04 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD0521F841A for ; Mon, 4 Feb 2013 01:47:04 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2IdQ-0004Ai-W2; Mon, 04 Feb 2013 10:47:00 +0100 Message-ID: <510F6DB4.5020703@si6networks.com> Date: Mon, 04 Feb 2013 05:13:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ray Hunter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <735400A8-EE45-41C1-8910-976D644FEEC0@laposte.net> <510D1877.9020209@globis.net> <510D2D8F.4090805@si6networks.com> <510D5152.5080808@globis.net> <510E1ED5.7040705@gmail.com> <510E6C54.6090002@globis.net> In-Reply-To: <510E6C54.6090002@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man 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, 04 Feb 2013 09:47:05 -0000 On 02/03/2013 10:55 AM, Ray Hunter wrote: > What "uniqueness" is strictly required for correct operation of IPv6? > If the competing technologies can never share an L2 link, what's the > problem? > > IMVHO We should be careful what semantics we import from other standards > bodies, and only do this explicitly. > > Looking at various alternatives for the semantics of IETF defined flags: > > u = deprecated. EUI64 MAY be used in generation of IIDs. DAD SHOULD be > performed for all unicast addresses. > A distinct possibility in my book. Reasoning: IIDs are only tie breakers > per link. Collisions happen. Deal with it. We currently do not deal with them. With start with the (fictional) assumption that we can get unique addresses if we based our IIDs on (allegedly) unique MAC addresses. But e.g. virtualization software can generate duplicate mac addresses. And in the presence of such failures, SLAAC/DAD fails (in some implementations, when DAD fails for link-local address, you need to reboot) > u==1 => derived from one (of potentially many) mapping schemes based on > a universal token, and therefore nodes MAY skip performing DAD on all > link types. > Also seems reasonable. Some might even think useful. Reality indicates that even when deemed as "unique", those tokens are not really universal. So if you skip that, you might end up in a slaac failure. Therefore, in practice you cannot really skip that. And if DAD fails, you must have some algorithm in place to solve the problem. Most likely, such algorithm is going to generate some random ID of some sort... in which case we should probably ask ourselves: why are we generating the addresses with an embedded IEEE identifier for the first try, and with a completely different scheme if DAD fails? > u==1 && g==0 => IEEE EUI64 with IEEE registered OUI on all link technology > Is probably too much (and unnecessary for correct functioning of IPv6 AFAIK) > Do we really want to tell everyone who wants to produce links that > supports IPv6 that they should obtain an OUI from the IEEE, or force > them to use u=0 when generating addresses? What value does this > restriction add for the IETF? Agreed. > u == 1 && g==0 => IEEE EUI64 with IEEE registered OUI, but only for IPv6 > unicast addresses and only on IEEE-defined link technology. > Would be fine by me, and current practice AFAIK But... is there any value in continuing with this? Cheers, -- 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 Feb 4 01:55: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 1BE1921F8639 for ; Mon, 4 Feb 2013 01:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYTFLkaMlaKA for ; Mon, 4 Feb 2013 01:55:51 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9B46921F8635 for ; Mon, 4 Feb 2013 01:55:49 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2Ilc-0004P4-1Z; Mon, 04 Feb 2013 10:55:46 +0100 Message-ID: <510F8566.1090907@si6networks.com> Date: Mon, 04 Feb 2013 06:54:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> In-Reply-To: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 6man 6man-wg , Bob Hinden 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, 04 Feb 2013 09:55:52 -0000 On 02/04/2013 05:38 AM, Rémi Després wrote: > > (*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare > enough exceptions. This is somewhat similar to the expectation that > ULA collisions shouldn't be seen). > > This theoretical unicity has been extensively used to assign stable > IIDs, without administrative action, to hosts that have no privacy > constraints requiring the opposite. If anything, privacy should be an "opt out", rather as an "opt in". In scenarios where privacy matters a lot, if our default policy is "no privacy", those users "opting in" for privacy would be flagged as "suspicious" just for the act of "opting in". Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From despres.remi@laposte.net Mon Feb 4 01:56: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 BCB7221F865B for ; Mon, 4 Feb 2013 01:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5aN9EnraV2A for ; Mon, 4 Feb 2013 01:56:41 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 12FD521F8635 for ; Mon, 4 Feb 2013 01:56:40 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 23C3570000B5; Mon, 4 Feb 2013 10:56:40 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id F24C27000051; Mon, 4 Feb 2013 10:56:39 +0100 (CET) X-SFR-UUID: 20130204095639992.F24C27000051@msfrf2206.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510F823E.7080100@si6networks.com> Date: Mon, 4 Feb 2013 10:56:39 +0100 Message-Id: <134D9D40-3832-41AD-B708-9725D9CDBFFB@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> <510F823E.7080100@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) 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: Mon, 04 Feb 2013 09:56:41 -0000 2013-02-04 10:41, Fernando Gont : > On 02/04/2013 06:11 AM, R=E9mi Despr=E9s wrote: >>=20 >> It depends on what is done with the new design, especially if it is = backward compatible and optional. >>=20 >> The question that started this discussion is whether reserving a = currently unused IID range having u=3D1 is compatible with the IPv6 = addressing architecture (i.e. RFC 4291).=20 >> AFAICT, the answer is YES. >=20 > I believe that the original question really was "whether it makes = sense > to reserve an unused IID range for 4rd". A 4rd reserved range, for 4rd activation to never require IPv6 = renumbering, has been for long in the specification studied in Softwire. Here is what Suresh said in the question to 6man: "There were some concerns raised in softwire about whether such = addresses are actually compatible with the IPv6 addressing architecture. = Whether this is actually compatible with the IPv6 addressing = architecture is outside the scope of the softwire wg. Hence we would = like to hear the 6man wg's perspective on this." > As noted by Ran Atkinson, since 4rd is an experimental document, it > seems more appropriate to separate a *shared* range for this kind of > experiment, rather than assign an IID range to 4rd. As already answered to Ran: "Making the reservation for one design, experimental or not, is a = guarantee that no future design with conflict with it, experimental or = not." If you disagree, please explain. In any case, this comment isn't about compatibility of the 4rd range = with the IPv6 addressing architecture.=20 Regards, RD >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From despres.remi@laposte.net Mon Feb 4 02:06: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 AC51E21F8684 for ; Mon, 4 Feb 2013 02:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+idEfX06yCl for ; Mon, 4 Feb 2013 02:06:11 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1719F21F8633 for ; Mon, 4 Feb 2013 02:06:11 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 6782C7000058; Mon, 4 Feb 2013 11:06:06 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 4BF327000051; Mon, 4 Feb 2013 11:06:06 +0100 (CET) X-SFR-UUID: 20130204100606311.4BF327000051@msfrf2206.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510F8566.1090907@si6networks.com> Date: Mon, 4 Feb 2013 11:06:06 +0100 Message-Id: <61612976-9949-44CF-ACE8-38033EB3B1CB@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510F8566.1090907@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 04 Feb 2013 10:06:11 -0000 Le 2013-02-04 =E0 10:54, Fernando Gont a =E9crit = : > On 02/04/2013 05:38 AM, R=E9mi Despr=E9s wrote: >>=20 >> (*) It remains that IIDs having u=3D1 SHOULD be unique, i.e. with = rare >> enough exceptions. This is somewhat similar to the expectation that >> ULA collisions shouldn't be seen). >>=20 >> This theoretical unicity has been extensively used to assign stable >> IIDs, without administrative action, to hosts that have no privacy >> constraints requiring the opposite. >=20 > If anything, privacy should be an "opt out", rather as an "opt in". Same view. IIDs derived by default from IEEE assigned MAC addresses is a good to = have. RD >=20 > In scenarios where privacy matters a lot, if our default policy is "no > privacy", those users "opting in" for privacy would be flagged as > "suspicious" just for the act of "opting in". >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From brian.e.carpenter@gmail.com Mon Feb 4 05:08: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 4C3EB21F855F for ; Mon, 4 Feb 2013 05:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.585 X-Spam-Level: X-Spam-Status: No, score=-100.585 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF9xo6IWlIPA for ; Mon, 4 Feb 2013 05:08:49 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1216021F869E for ; Mon, 4 Feb 2013 05:08:48 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so4757552wgb.5 for ; Mon, 04 Feb 2013 05:08:48 -0800 (PST) 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=YxGQ54ExuSHMQWDcTg+88evejeluW4qNFQHvhjtFrxQ=; b=All2yo8Ar8ngnJjihmnICljP6EkLKIPtCzxa7/eQaGB9LLcEOhP/N7fSREtHvOdgMq /Cvrg8l6S9rgnpok2W5pGvJn0z8VSF8Rg/jopjphf6kE6hezLIBSXb0K1CmoCpyi6spo E72RQGr4BzIjCe3dZo/jbrpsSVztQ4DGWJlE+7zj0r17fDxz293Nm8iUonzEbRQLALrP llEMXee6jyaxCQEPai4A79/8T5V3RaydWBnBVmTq5dfSyH9nE73DlOmmGfej03QfjQsT 6922xFrBNALlPVsO60ZFBDyXFxiw2JwsCVZaUubePhCu1GMq2UE/SEW+ZmknRmAJJonK Y1WA== X-Received: by 10.180.80.35 with SMTP id o3mr10466944wix.9.1359983328023; Mon, 04 Feb 2013 05:08:48 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-53.as13285.net. [2.101.189.53]) by mx.google.com with ESMTPS id o13sm2067770wie.10.2013.02.04.05.08.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 05:08:47 -0800 (PST) Message-ID: <510FB2DF.8030201@gmail.com> Date: Mon, 04 Feb 2013 13:08:47 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Mon, 04 Feb 2013 13:08:50 -0000 R=C3=A9mi, On 04/02/2013 09:11, R=C3=A9mi Despr=C3=A9s wrote: > Hi, Roger, >=20 > Please see inline. >=20 > 2013-02-03 22:40, Roger J=C3=B8rgensen : >=20 >> On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli wrote:= >>> On 2/3/13 11:39 AM, Joel M. Halpern wrote: >>>> On 2/3/2013 2:36 PM, Brian E Carpenter wrote: >>>>> On 03/02/2013 17:26, Joel M. Halpern wrote: >>>>>> To a significant degree Randy, I agree with you in your comment ab= out >>>>>> magic bits. If I were designing IPv6 from scratch (counter-factua= l in >>>>>> so may ways at once) I would not do it that way. >>>>>> >>>>>> But, unless there is an actual problem with the design the IETF ha= s >>>>>> adopted, I am reluctant to change it "just because". >>>>> >>>>> Which is why the draft actually proposes nothing that would change >>>>> any running code. >>>>> >>>>> Brian >>>> >>>> But it does propose to change the spec. Why? What problem does cha= nging >>>> the spec solve? >>> If it prevents someone from ascribing new utility to these bit(s) in = the >>> future that seems like a worthwhile goal. While I'm sure that we can = come up >>> with new and different was to apply meaning to global unicast address= es I >>> think the world is a simpler place when we don't. >=20 > It depends on what is done with the new design, especially if it is bac= kward compatible and optional. >=20 > The question that started this discussion is whether reserving a curren= tly unused IID range having u=3D1 is compatible with the IPv6 addressing= architecture (i.e. RFC 4291).=20 > AFAICT, the answer is YES. > Changing RFC 4291 to make it become a NO would have consequences well b= eyond this new request.=20 Indeed. That is not in any way proposed by the draft. Rather to the contr= ary, in fact, since one of the co-authors of 4rd is my co-author. Brian >> KISS is always a good approach - Keep It Stupid Simple, or Simple Stup= id. >=20 > Agreed. >=20 >> (or in short, special meaning attached to bits seems to cause more >> confusion than good) >=20 > - Not a consequence of KISS. > - Changing a specification without a pressing need, and although it has= been used, isn't a way to increase confidence in any design. IPv6 needs = confidence. >=20 >=20 >> And on the topic of DAD vs assume uniqueness - I learned this from an >> earlier colleague >=20 > No one proposes to abandon DAD! > The point is that, while a specification *clarification* on u/g appears= to be useful, specification *change* would be harmful. >=20 > Regards, > RD >=20 > =20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From ietf@rozanak.com Mon Feb 4 06:46: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 75C6F21F85BC for ; Mon, 4 Feb 2013 06:46:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ4kH9cu3iyT for ; Mon, 4 Feb 2013 06:46:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id B2F3521F85B8 for ; Mon, 4 Feb 2013 06:46:09 -0800 (PST) Received: from FB10H117WS01 ([141.89.226.146]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M2KNg-1Urrxr1cXs-00s7QK; Mon, 04 Feb 2013 09:46:08 -0500 From: "Hosnieh Rafiee" To: References: <003c01ce0121$80b0ebf0$8212c3d0$@rozanak.com> <1359806574.6652.97.camel@karl> <000101ce018e$1ab13d10$5013b730$@rozanak.com> <510F5ABF.1030000@si6networks.com> In-Reply-To: <510F5ABF.1030000@si6networks.com> Subject: RE: I-D action : draft-rafiee-6man-ssas-01 Date: Mon, 4 Feb 2013 15:46:05 +0100 Message-ID: <003601ce02e6$5e5cb270$1b161750$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4CvI/M5oPl+84ST3a2S+0jBsI/6wAKXegw Content-Language: de X-Provags-ID: V02:K0:lKkCxilkadp51aXO9fXd3nRD+AFO/e622ONNDRlZJ0W SqJH3u0gKy/74bWi2aZ5exOESP7aZku+VphUUjFQLPZse0NLO8 cOOBAg8svHbsI8YKuUhn2JToiEf7H14Yx5C8lD17vcQpwPQJ6N 7awmZ5zMMrw/kljgaMCNBtTpNIrkUH2GoHi8L1MePFZdeQaEhY LACDk5Ye3MXQPyoesumy/gET7IX5+I8zqXGt/kscmtmeTD5QA6 wLL8tx99BCrEhyoAqSK7Ek9FXi6iAKJJWFHYn5G6U5zPjslIgU vI/5+MTVbqZ8QOezFZXsWVQCmNI1NQnFWWwxH6tI0Uwj1S1hoy a0lmMw9vZ1KKQI506x3Y= 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, 04 Feb 2013 14:46:10 -0000 >It can't be a consideration, because in order for CGAs to serve their purpose, nodes must be able to compute the IID. An IID that aims at protecting user privacy works the other way around: a third->party should not be able to compute the IID. Please refer you to CGA RFC. About SSAS: the purpose of this draft is to discuss the means of combining or integrating privacy (layer 3) and security. Thank you, Hosnieh -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com] Sent: Montag, 4. Februar 2013 07:53 To: Hosnieh Rafiee Cc: 'Karl Auer'; ipv6@ietf.org Subject: Re: I-D action : draft-rafiee-6man-ssas-01 Hosnieh, On 02/02/2013 06:41 PM, Hosnieh Rafiee wrote: > >> CGA were not designed to address privacy related attacks, they are a >> means > of securing NDP exchanges. The fact that they appear random is > coincidental to their function. > > It is true that the main purpose was security, but it is not true that > privacy was not a consideration. It can't be a consideration, because in order for CGAs to serve their purpose, nodes must be able to compute the IID. An IID that aims at protecting user privacy works the other way around: a third-party should not be able to compute the IID. Cheers, -- 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 Feb 4 06:58: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 DD3D921F85FD for ; Mon, 4 Feb 2013 06:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9rQcB6MlM9F for ; Mon, 4 Feb 2013 06:58:11 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 538E321F85D4 for ; Mon, 4 Feb 2013 06:58:08 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2NUi-00037C-JN; Mon, 04 Feb 2013 15:58:05 +0100 Message-ID: <510F8F4D.9020502@si6networks.com> Date: Mon, 04 Feb 2013 07:37:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> <510F823E.7080100@si6networks.com> <134D9D40-3832-41AD-B708-9725D9CDBFFB@laposte.net> In-Reply-To: <134D9D40-3832-41AD-B708-9725D9CDBFFB@laposte.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 04 Feb 2013 14:58:13 -0000 On 02/04/2013 06:56 AM, Rémi Després wrote: > >> I believe that the original question really was "whether it makes >> sense to reserve an unused IID range for 4rd". > > A 4rd reserved range, for 4rd activation to never require IPv6 > renumbering, has been for long in the specification studied in > Softwire. But my understanding is that softwires didn't adopt 4rd? If 4rd is published as "experimental", then it doesn't make sense to permanently assign an address range to it. >> As noted by Ran Atkinson, since 4rd is an experimental document, >> it seems more appropriate to separate a *shared* range for this >> kind of experiment, rather than assign an IID range to 4rd. > > As already answered to Ran: "Making the reservation for one design, > experimental or not, is a guarantee that no future design with > conflict with it, experimental or not." If you disagree, please > explain. We have several shared resources (ICMPv6 types, etc.) for experiments. Why should this be an exception? 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 Feb 4 06:58: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 D341021F86D6 for ; Mon, 4 Feb 2013 06:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwAPyl7MlVOn for ; Mon, 4 Feb 2013 06:58:21 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id B24C121F85C3 for ; Mon, 4 Feb 2013 06:58:21 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2NUw-00037X-Es; Mon, 04 Feb 2013 15:58:18 +0100 Message-ID: <510F8FEA.1020209@si6networks.com> Date: Mon, 04 Feb 2013 07:39:38 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510F8566.1090907@si6networks.com> <61612976-9949-44CF-ACE8-38033EB3B1CB@laposte.net> In-Reply-To: <61612976-9949-44CF-ACE8-38033EB3B1CB@laposte.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 6man 6man-wg , Bob Hinden 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, 04 Feb 2013 14:58:24 -0000 On 02/04/2013 07:06 AM, Rémi Després wrote: > > Le 2013-02-04 à 10:54, Fernando Gont a écrit : > >> On 02/04/2013 05:38 AM, Rémi Després wrote: >>> >>> (*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare >>> enough exceptions. This is somewhat similar to the expectation that >>> ULA collisions shouldn't be seen). >>> >>> This theoretical unicity has been extensively used to assign stable >>> IIDs, without administrative action, to hosts that have no privacy >>> constraints requiring the opposite. >> >> If anything, privacy should be an "opt out", rather as an "opt in". > > Same view. > IIDs derived by default from IEEE assigned MAC addresses is a good to have. Such IIDs do not preserve privacy, so... are you suggesting that they should not be the default algorithm for selecting IIDs with SLAAC? Cheers, -- 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 Feb 4 06:58: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 33E1421F85FD for ; Mon, 4 Feb 2013 06:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.233 X-Spam-Level: X-Spam-Status: No, score=-3.233 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHu6KDGlmucB for ; Mon, 4 Feb 2013 06:58:24 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABB621F85C3 for ; Mon, 4 Feb 2013 06:58:24 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2NUb-00036t-Br; Mon, 04 Feb 2013 15:57:58 +0100 Message-ID: <510F8E3B.3030407@si6networks.com> Date: Mon, 04 Feb 2013 07:32:27 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <6BD7F1B3-FC28-48C2-84E7-26D7F6D26BDD@laposte.net> In-Reply-To: <6BD7F1B3-FC28-48C2-84E7-26D7F6D26BDD@laposte.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Deployment Prevention 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, 04 Feb 2013 14:58:25 -0000 On 02/04/2013 06:42 AM, Rémi Després wrote: > In this respect, changing now the IPv6 specification for hosts that > configure IIDs having u=1, although no serious need has been > identified, and this specification has ben used, would be in my > understanding very counterproductive: stability of already used > specifications is important for their success. I strongly disagree. For many reasons, including: 1) What's broken, is broken. And if it's known to be broken, it should be fixed. 2) We do maintenance of widely-implemented, widely-deployed protocols. So I'm not sure why we should be scared about changing stuff in v6 (particularly when we're still at a point in which the v6 traffic is very small) 3) Whatever changes are needed should be done soon. The more we wait, the more expensive they'll become. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jouni.nospam@gmail.com Mon Feb 4 07:46: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 06A9921F87FF for ; Mon, 4 Feb 2013 07:46:43 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mouKJx3uDlWa for ; Mon, 4 Feb 2013 07:46:42 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1FD21F87B3 for ; Mon, 4 Feb 2013 07:46:41 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id gm6so6624794lbb.26 for ; Mon, 04 Feb 2013 07:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=GGuM62JB5yRbXYfQJQkr8SROtQBST+aay05WbU74fvU=; b=xfScPl0TlzvvSUKn7dITn6GRxSQbR2cE/BfsmLwZZxmqjUAUQfOwnDmIqyINPiWlVJ s57063RSXOSJ8JjQfLFmPz4bxrlJSwF2gQIhwwZPxhuX0CBtMheDdS0mzm6kbS5MH5F6 cw+jL43Wkp1H/Zr2Qwst2fHxfLeidsqraz0aAsM+G/rtDZzt2J7WGj011UaCILjE5tqV DD3IJKJNFPnRpKO0zWnOA8B1Uquywc20otiFN41KyMkqUJIKvoyDugPHy2eol066R5Hi jjTyfnRPYnlBQhbMuafBH521P1Sv6ydP9S/rPVQ/0Za0bxYxU5zbdrOXZok4ZeB/ESvw JX1Q== X-Received: by 10.152.106.5 with SMTP id gq5mr19858263lab.5.1359992801113; Mon, 04 Feb 2013 07:46:41 -0800 (PST) Received: from [10.37.126.66] ([77.95.242.36]) by mx.google.com with ESMTPS id iw6sm9239374lab.2.2013.02.04.07.45.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 07:46:40 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: Jouni Korhonen In-Reply-To: <510F8E3B.3030407@si6networks.com> Date: Mon, 4 Feb 2013 17:45:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FDCF0F7-53D6-4637-BD87-BE3A12DFE21D@gmail.com> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <6BD7F1B3-FC28-48C2-84E7-26D7F6D26BDD@laposte.net> <510F8E3B.3030407@si6networks.com> To: Fernando Gont , IPv6 Deployment Prevention X-Mailer: Apple Mail (2.1499) 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, 04 Feb 2013 15:46:43 -0000 On Feb 4, 2013, at 12:32 PM, Fernando Gont = wrote: > On 02/04/2013 06:42 AM, R=E9mi Despr=E9s wrote: >> In this respect, changing now the IPv6 specification for hosts that >> configure IIDs having u=3D1, although no serious need has been >> identified, and this specification has ben used, would be in my >> understanding very counterproductive: stability of already used >> specifications is important for their success. >=20 > I strongly disagree. For many reasons, including: >=20 > 1) What's broken, is broken. And if it's known to be broken, it should > be fixed. It is awkward but not broken imho, so in this respect I would think = twice changing RFC4291. However, I do agree Randy about magic bits and the = pain involved. Actually, a lot IPv6 business recently has been around adding magic to IPv6 addressing, which I kind of find uncomfortable.. My personal take on this is that we keep things as they are now. It = would be cool to have all IIDs as a binary blob but.. that does not give a = reason to start changing the addressing architecture at this point. Brian's document could be a good place to hash out the "confusing" = points of the magic bits - as a plain discussion document without a = recommendation about next steps. - Jouni (hmm.. where this conservative me came from ;-) >=20 > 2) We do maintenance of widely-implemented, widely-deployed protocols. > So I'm not sure why we should be scared about changing stuff in v6 > (particularly when we're still at a point in which the v6 traffic is > very small) >=20 > 3) Whatever changes are needed should be done soon. The more we wait, > the more expensive they'll become. >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From despres.remi@laposte.net Mon Feb 4 08: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 6624121F88AC for ; Mon, 4 Feb 2013 08:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkLv5xxC6hj5 for ; Mon, 4 Feb 2013 08:38:06 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71F621F885B for ; Mon, 4 Feb 2013 08:38:05 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id DC999700006D; Mon, 4 Feb 2013 17:38:03 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id BCF0F70000AC; Mon, 4 Feb 2013 17:38:03 +0100 (CET) X-SFR-UUID: 20130204163803774.BCF0F70000AC@msfrf2119.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510F8F4D.9020502@si6networks.com> Date: Mon, 4 Feb 2013 17:38:04 +0100 Message-Id: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> <510F823E.7080100@si6networks.com> <134D9D40-3832-41AD-B708-9725D9CDBFFB@laposte.net> <510F8F4D.9020502@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) 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: Mon, 04 Feb 2013 16:38:06 -0000 2013-02-04 11:37, Fernando Gont : > On 02/04/2013 06:56 AM, R=E9mi Despr=E9s wrote: >>=20 >>> I believe that the original question really was "whether it makes >>> sense to reserve an unused IID range for 4rd". >>=20 >> A 4rd reserved range, for 4rd activation to never require IPv6 >> renumbering, has been for long in the specification studied in >> Softwire. >=20 > But my understanding is that softwires didn't adopt 4rd? 4rd is adopted (on experimental track) under the only condition that = 6man confirms that it doesn't conflict with the IPv6 addressing = architecture. =20 > If 4rd is published as "experimental", then it doesn't make sense to > permanently assign an address range to it. See (*) below. If 4rd is eventually deprecated, the range will be freed. If it isn't deprecated, the range will remain reserved (which, as you = know, is only 1/16384 of available IIDs having u=3Dg=3D1, i.e. nothing = to be alarmed by). If and when IPv4 is deprecated, the reservation will become meaningless. As long as IPv4 isn't deprecated, any solution that has distinctive = properties for IPv4 service across IPv6-only clouds, is relevant.=20 >>> As noted by Ran Atkinson, since 4rd is an experimental document, >>> it seems more appropriate to separate a *shared* range for this >>> kind of experiment, rather than assign an IID range to 4rd. >>=20 (*) >> As already answered to Ran: "Making the reservation for one design, >> experimental or not, is a guarantee that no future design with >> conflict with it, experimental or not." If you disagree, please >> explain. >=20 > We have several shared resources (ICMPv6 types, etc.) for experiments. > Why should this be an exception? All other experiment, I suppose, had enough with what has been reserved = so far. As far as 4rd is concerned, it needs an IID range that cannot conflict = with any host address that complies with RFC 4291.=20 Regards, RD > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From despres.remi@laposte.net Mon Feb 4 09: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 C2D9B21F89F9 for ; Mon, 4 Feb 2013 09:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvdhqd0Sgtns for ; Mon, 4 Feb 2013 09:00:16 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E9C21F8A48 for ; Mon, 4 Feb 2013 09:00:15 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id F14EE70000E4; Mon, 4 Feb 2013 18:00:13 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id 8569070000A0; Mon, 4 Feb 2013 18:00:13 +0100 (CET) X-SFR-UUID: 20130204170013546.8569070000A0@msfrf2119.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510F8E3B.3030407@si6networks.com> Date: Mon, 4 Feb 2013 18:00:14 +0100 Message-Id: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <6BD7F1B3-FC28-48C2-84E7-26D7F6D26BDD@laposte.net> <510F8E3B.3030407@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Deployment Prevention 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, 04 Feb 2013 17:00:17 -0000 Le 2013-02-04 =E0 11:32, Fernando Gont a =E9crit = : > On 02/04/2013 06:42 AM, R=E9mi Despr=E9s wrote: >> In this respect, changing now the IPv6 specification for hosts that >> configure IIDs having u=3D1, although no serious need has been >> identified, and this specification has ben used, would be in my >> understanding very counterproductive: stability of already used >> specifications is important for their success. >=20 > I strongly disagree. For many reasons, including: >=20 > 1) What's broken, is broken. And if it's known to be broken, it should > be fixed. One has to come with a proof that reserving u=3D1 for universally = specified IID formats is harmful. None has been seen. OTPH, 4rd is the first instance that shows it can be beneficial beyond = its current application to IEEE derived IIDs. =20 > 2) We do maintenance of widely-implemented, widely-deployed protocols. > So I'm not sure why we should be scared about changing stuff in v6 > (particularly when we're still at a point in which the v6 traffic is > very small) Different understanding. To me, standard modifications need serious reasons, and much caution. RD >=20 > 3) Whatever changes are needed should be done soon. The more we wait, > the more expensive they'll become. >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From dougb@dougbarton.us Mon Feb 4 09:37: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 C07DE21F89BA for ; Mon, 4 Feb 2013 09:37:54 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNslrtrgW8FL for ; Mon, 4 Feb 2013 09:37:54 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 426CA21F84B2 for ; Mon, 4 Feb 2013 09:37:54 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:54ce:d412:561f:420a] (unknown [IPv6:2001:470:d:5e7:54ce:d412:561f:420a]) by dougbarton.us (Postfix) with ESMTPSA id CAE8A22B0C for ; Mon, 4 Feb 2013 17:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1359999473; bh=W2fW96WxIxc1DQWvOg8wtM+BB13usPwKJC6Q33Q5rKY=; h=Date:From:To:Subject:References:In-Reply-To; b=QMBWoD2jM/bR7AHhB29T4ylBtWzbcQooqMmUVoRezIHTNp6CBhf9rgcHtAw/eVHH+ pdmoDiXXJ8QR5BQ5zVo1IwYZq/KxJl8XnEvwEMFOKws78/Be1WFKEvgcLGKyI03nbi Gt224qp2+w41eKXITzdoISg+1IkfMmpYakjMUvrA= Message-ID: <510FF1F0.3030903@dougbarton.us> Date: Mon, 04 Feb 2013 09:37:52 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> In-Reply-To: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 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, 04 Feb 2013 17:37:54 -0000 On 02/04/2013 12:38 AM, Rémi Després wrote: > It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough exceptions. This is somewhat similar to the expectation that ULA collisions shouldn't be seen). > > This theoretical unicity has been extensively used to assign stable IIDs, without administrative action, to hosts that have no privacy constraints requiring the opposite. What software exists that makes determinations based on the u bit? How would that software be impacted if the u bit were suddenly be devoid of meaning? I am of course assuming that DAD would still be in play for dynamically assigned addresses, which it seems we are all in agreement on. Doug From fgont@si6networks.com Mon Feb 4 10:15: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 476CF21F8AE3 for ; Mon, 4 Feb 2013 10:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUR8uKoNBrei for ; Mon, 4 Feb 2013 10:15:28 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 486C521F8A8F for ; Mon, 4 Feb 2013 10:15:28 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2QZB-0007uf-Ez; Mon, 04 Feb 2013 19:14:56 +0100 Message-ID: <510FF47E.5080301@si6networks.com> Date: Mon, 04 Feb 2013 14:48:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jouni Korhonen Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <6BD7F1B3-FC28-48C2-84E7-26D7F6D26BDD@laposte.net> <510F8E3B.3030407@si6networks.com> <8FDCF0F7-53D6-4637-BD87-BE3A12DFE21D@gmail.com> In-Reply-To: <8FDCF0F7-53D6-4637-BD87-BE3A12DFE21D@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Fernando Gont , IPv6 Deployment Prevention 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, 04 Feb 2013 18:15:29 -0000 On 02/04/2013 12:45 PM, Jouni Korhonen wrote: > >> On 02/04/2013 06:42 AM, Rémi Després wrote: >>> In this respect, changing now the IPv6 specification for hosts that >>> configure IIDs having u=1, although no serious need has been >>> identified, and this specification has ben used, would be in my >>> understanding very counterproductive: stability of already used >>> specifications is important for their success. >> >> I strongly disagree. For many reasons, including: >> >> 1) What's broken, is broken. And if it's known to be broken, it should >> be fixed. > > It is awkward but not broken imho, so in this respect I would think twice FWIW, my comment was in response of the general statement "stability of already used specifications is important for their success". Actually, I'm not opposed to "stable specifications", but about resistance to change/fix/improve those things just because to maintain the status quo. > changing RFC4291. However, I do agree Randy about magic bits and the pain > involved. Actually, a lot IPv6 business recently has been around adding > magic to IPv6 addressing, which I kind of find uncomfortable.. Not sure what you mean. For instance, draft-ietf-6man-stable-privacy-addresses doesn't change the architecture, but simply is an alternative algorithm that fits in the existing architecture. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ot@cisco.com Mon Feb 4 10:49: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 AD58221F8B0E for ; Mon, 4 Feb 2013 10:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL3FiG-lqN+t for ; Mon, 4 Feb 2013 10:49:52 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7221F8AE5 for ; Mon, 4 Feb 2013 10:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=661; q=dns/txt; s=iport; t=1360003792; x=1361213392; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Jhwo0HfJ+kyDISxguOgO9yjd4TVZxnwFAgSsr4jOBVU=; b=YRwDyszN6Ly/ucnDiVDdyPnt2HKy6yAVUrjui7Gwa52lWRN+mBsNyHIy FqAAiDWwO1HZHkDdeQTYSSy0YRpJCQEdevYIKv/i/e3nBHkqrFE3zVnVO 2Q0gLH7fctPR7DeMGWQ4+HGJRbQ8RPtK49oKDAqY6l9H4sWs+BISyZIYG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAJAHQCEFGQ/khL/2dsb2JhbABFvjEEBIEDFnOCIAEBBHkQCxI0SQ4GiCS8DJBxYQOWH5BRgn0 X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="80243492" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Feb 2013 18:49:48 +0000 Received: from dhcp-10-61-99-218.cisco.com (dhcp-10-61-99-218.cisco.com [10.61.99.218]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r14InmdH017800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Feb 2013 18:49:48 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: Ole Troan In-Reply-To: Date: Mon, 4 Feb 2013 19:49:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <390642F8-71B0-4E3E-AC6B-AC1F7919A7EE@cisco.com> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <510EBC22.2070503@gmail.com> <510EBCF5.1050705@joelhalpern.com> <510ECF17.8020802@bogus.com> <510F823E.7080100@si6networks.com> <134D9D40-3832-41AD-B708-9725D9CDBFFB@laposte.net> <510F8F4D.9020502@si6networks.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: 6man 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, 04 Feb 2013 18:49:52 -0000 Remi, >>>> I believe that the original question really was "whether it makes >>>> sense to reserve an unused IID range for 4rd". >>>=20 >>> A 4rd reserved range, for 4rd activation to never require IPv6 >>> renumbering, has been for long in the specification studied in >>> Softwire. >>=20 >> But my understanding is that softwires didn't adopt 4rd? >=20 > 4rd is adopted (on experimental track) under the only condition that = 6man confirms that it doesn't conflict with the IPv6 addressing = architecture. that of course doesn't mean that softwire will not publish 4rd if the = authors were to accept the advice from 6man. cheers, Ole= From fgont@si6networks.com Mon Feb 4 11:27: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 436FA21F899E for ; Mon, 4 Feb 2013 11:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfAOFp-TNiIE for ; Mon, 4 Feb 2013 11:27:47 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6921F85A1 for ; Mon, 4 Feb 2013 11:27:40 -0800 (PST) Received: from [186.134.24.14] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U2RhY-0001F0-1x; Mon, 04 Feb 2013 20:27:36 +0100 Message-ID: <51100B9E.2040503@si6networks.com> Date: Mon, 04 Feb 2013 16:27:26 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> Subject: Moving forward draft-ietf-6man-oversized-header chain? 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, 04 Feb 2013 19:27:48 -0000 Folks, I was wondering what's the status of draft-ietf-6man-oversized-header-chain. Was it ready to ship to the IESG? Or does it still need to be WGLC'ed? FWIW, this I-D has been stable for a few months now, and quite a few folks agreed that it was ready to progress. 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 jouni.nospam@gmail.com Mon Feb 4 12:50: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 0222621F8AEA for ; Mon, 4 Feb 2013 12:50:31 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoa9jAkiYvIW for ; Mon, 4 Feb 2013 12:50:30 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3495721F87D5 for ; Mon, 4 Feb 2013 12:50:30 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id c13so3589449eek.0 for ; Mon, 04 Feb 2013 12:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=hVir1WTWOOk2Rneo+qRYoIf2P3Kmn/zKYvkM7soq4oY=; b=lgmki4eASBA4VItR6v6p6DUdtUwHw+8PZnhLtWW4Qemxd0Ne9lRTH5hx/8KLP3O0x3 dtNGSqoplQNZlBmeBOZ2GZyv3yePnZCn6fk/ZMAIeAvnU/I2aNZbCGC//ubdwV2GswHa 1pIDkNkkHCAIYkoAlqWQe2mONm6n8YYrEyZcWcgptPrWfYmfVt/Z1nK5lptle8wT10RY ndKFzWLPoHBdxliNEj8XMGGIYDEMgzQFnCk6cxGlgM0tG4YlF4omRdXqYoCcm4Vgkehc HzVONKz/EYmY2dvzUkcGqlDtjtOTZFdZdkMRVldsN9VC/mOHgNQCqrEtjpqHe8w03ciW O5eA== X-Received: by 10.14.194.195 with SMTP id m43mr75558617een.44.1360011029202; Mon, 04 Feb 2013 12:50:29 -0800 (PST) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id q5sm29067038eeo.17.2013.02.04.12.50.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 12:50:28 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: Jouni Korhonen In-Reply-To: <510FF47E.5080301@si6networks.com> Date: Mon, 4 Feb 2013 22:50:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <510E22AA.3050308@gmail.com> <510E9DD3.2050907@joelhalpern.com> <6BD7F1B3-FC28-48C2-84E7-26D7F6D26BDD@laposte.net> <510F8E3B.3030407@si6networks.com> <8FDCF0F7-53D6-4637-BD87-BE3A12DFE21D@gmail.com> <510FF47E.5080301@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: IPv6 Deployment Prevention 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, 04 Feb 2013 20:50:31 -0000 On Feb 4, 2013, at 7:48 PM, Fernando Gont wrote: > On 02/04/2013 12:45 PM, Jouni Korhonen wrote: >>=20 >>> On 02/04/2013 06:42 AM, R=E9mi Despr=E9s wrote: >>>> In this respect, changing now the IPv6 specification for hosts that >>>> configure IIDs having u=3D1, although no serious need has been >>>> identified, and this specification has ben used, would be in my >>>> understanding very counterproductive: stability of already used >>>> specifications is important for their success. >>>=20 >>> I strongly disagree. For many reasons, including: >>>=20 >>> 1) What's broken, is broken. And if it's known to be broken, it = should >>> be fixed. >>=20 >> It is awkward but not broken imho, so in this respect I would think = twice >=20 > FWIW, my comment was in response of the general statement "stability = of > already used specifications is important for their success". >=20 > Actually, I'm not opposed to "stable specifications", but about Good. > resistance to change/fix/improve those things just because to maintain > the status quo. Understand. But within this specific ug topic I am still not convinced myself that what we have now is broken or would even need a facelift.. >> changing RFC4291. However, I do agree Randy about magic bits and the = pain >> involved. Actually, a lot IPv6 business recently has been around = adding >> magic to IPv6 addressing, which I kind of find uncomfortable.. >=20 > Not sure what you mean. For instance, > draft-ietf-6man-stable-privacy-addresses doesn't change the Your draft is just fine since it is by the RFC4291 rules. I should have been more precise with my above comment, which was a generic comment = about the desire to specify something that ends up to a special IPv6 address handling or configuration just because we have 'so many bits to play = with'. - Jouni > architecture, but simply is an alternative algorithm that fits in the > existing architecture. >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From randy@psg.com Mon Feb 4 19:12: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 E545021F8934 for ; Mon, 4 Feb 2013 19:12:47 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUughcMMMQBX for ; Mon, 4 Feb 2013 19:12:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 887BA21F85A1 for ; Mon, 4 Feb 2013 19:12:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U2Yxa-0007nm-Rx; Tue, 05 Feb 2013 03:12:39 +0000 Date: Tue, 05 Feb 2013 12:12:38 +0900 Message-ID: From: Randy Bush To: Fernando Gont Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] In-Reply-To: <510F8566.1090907@si6networks.com> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510F8566.1090907@si6networks.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention 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, 05 Feb 2013 03:12:48 -0000 > In scenarios where privacy matters a lot, if our default policy is > "no privacy", those users "opting in" for privacy would be flagged > as "suspicious" just for the act of "opting in". and 82.3% would not realize they needed to opt out. i would think that, in general, across the ietf protocols, privacy preservation would be the desired default. randy From dougb@dougbarton.us Mon Feb 4 20:50: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 D2F4221F87FE for ; Mon, 4 Feb 2013 20:50:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E42xOc8iqNB for ; Mon, 4 Feb 2013 20:50:28 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 546A121F873E for ; Mon, 4 Feb 2013 20:50:28 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:98e5:9a49:b9f7:cbb2] (unknown [IPv6:2001:470:d:5e7:98e5:9a49:b9f7:cbb2]) by dougbarton.us (Postfix) with ESMTPSA id EA46522B2A for ; Tue, 5 Feb 2013 04:50:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1360039828; bh=9kWmob/LU8pQq9hMGDoIK7l3FZuxmMV798lKjKqH3a0=; h=Date:From:To:Subject:References:In-Reply-To; b=i5M2CiDR0DC+wq6uhRVinIo0jmJG7iGRccdtk5oG0v5SLOs4g0RAxMcQO8uKMufxr bVqP2AXCUbzjOnAuWXPWVnsFWFCNWxet9QBBR8mCetode/GzUilTpj7xikdgLI4ntk 7Wmxum6IZgtjLp/L2IcLLBAuhOGxh2504eX06SS8= Message-ID: <51108F91.1070909@dougbarton.us> Date: Mon, 04 Feb 2013 20:50:25 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510F8566.1090907@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 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: Tue, 05 Feb 2013 04:50:29 -0000 On 02/04/2013 07:12 PM, Randy Bush wrote: >> In scenarios where privacy matters a lot, if our default policy is >> "no privacy", those users "opting in" for privacy would be flagged >> as "suspicious" just for the act of "opting in". > > and 82.3% would not realize they needed to opt out. > > i would think that, in general, across the ietf protocols, privacy > preservation would be the desired default. Agreed. I have never understood why the default for this has always been "off." Given that most implementations have ignored the RFC(s) and enabled it by default anyway, I think it's time that we acknowledged reality (both in the sense of what people are doing, and in the sense that it's clearly working). From ot@cisco.com Tue Feb 5 04:36: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 8692A21F875F for ; Tue, 5 Feb 2013 04:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57q--ye-9PRj for ; Tue, 5 Feb 2013 04:36:43 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A150F21F8775 for ; Tue, 5 Feb 2013 04:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=160; q=dns/txt; s=iport; t=1360067803; x=1361277403; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=fj95MSA85nuDWwqKE9y9phqtJMZtefvWi+P/B6r2Xtc=; b=L0g+Lu4QuVf2mx3sSkRv8/OEcbWREZJyxE+xVSW5m3vK37/+MWXbXj9X Wac1pJs3TUu9Vu6Zb26aURkSiAfFcQKvKqlVWXPjDHGzIkoItFK7kqGJu HzkdkwlvHj/xt0NwXh4uXN/b9+X1W/QOG119oml5LKCBFYLjG4qXYQFh5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG78EFGQ/khR/2dsb2JhbABEv1wWc4JgP4E+iCSqHpAnkHlhA5YhkFGCfQ X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="11597703" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 05 Feb 2013 12:36:42 +0000 Received: from dhcp-10-61-106-228.cisco.com (dhcp-10-61-106-228.cisco.com [10.61.106.228]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r15Caf8R028528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 12:36:42 GMT From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Writeup: draft-ietf-6man-impatient-nud Date: Tue, 5 Feb 2013 13:36:41 +0100 Message-Id: <6D97AA88-5BD0-4D5A-9A11-7CB905DC00B5@cisco.com> To: "draft-ietf-6man-impatient-nud@tools.ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: 6man 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, 05 Feb 2013 12:36:44 -0000 Erik, Igor, as part of doing the writeup to the IESG. do you know of any = implementations or plans for implementations of impatient NUD? cheers, Ole From despres.remi@laposte.net Tue Feb 5 05:57: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 5DFD421F85AC for ; Tue, 5 Feb 2013 05:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv5X5Fr1Eb0R for ; Tue, 5 Feb 2013 05:57:22 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8F721F858E for ; Tue, 5 Feb 2013 05:57:22 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 5525670000AB; Tue, 5 Feb 2013 14:57:21 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 0AEF470000A5; Tue, 5 Feb 2013 14:57:20 +0100 (CET) X-SFR-UUID: 20130205135721449.0AEF470000A5@msfrf2117.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510FF1F0.3030903@dougbarton.us> Date: Tue, 5 Feb 2013 14:57:24 +0100 Message-Id: <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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, 05 Feb 2013 13:57:23 -0000 Hi, Doug, Please see inline. 2013-02-04 =E0 18:37, Doug Barton : > On 02/04/2013 12:38 AM, R=E9mi Despr=E9s wrote: >> It remains that IIDs having u=3D1 SHOULD be unique, i.e. with rare = enough exceptions. This is somewhat similar to the expectation that ULA = collisions shouldn't be seen). >>=20 >> This theoretical unicity has been extensively used to assign stable = IIDs, without administrative action, to hosts that have no privacy = constraints requiring the opposite. >=20 > What software exists that makes determinations based on the u bit? (*) Major OSes can assign IIDs derived from IEEE MAC addresses of their = LAN adapters (if not by default, at least as a possibility). They do it = because of what IEEE and IETF have specified, each one for its own = domain, concerning their respective u bits.=20 With these specifications, it is impossible on a SLAAC link that two = hosts that have universal-scope addresses (necessarily different if they = communicate at the MAC layer), would have conflicting IIDs at the IP = layer if they derive them from MAC addresses. >=20 > How would that software be impacted if the u bit were suddenly be = devoid of meaning? Hosts would become free to assign arbitrary IIDs having u=3D1, breaking = applicability of (*) above. >=20 > I am of course assuming that DAD would still be in play for = dynamically assigned addresses, which it seems we are all in agreement = on. Sure (agreement confirmed). Hope it clarifies. RD >=20 > Doug > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From sthaug@nethelp.no Tue Feb 5 06:02: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 1CBC121F88A6 for ; Tue, 5 Feb 2013 06:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBK7meEG564L for ; Tue, 5 Feb 2013 06:02:00 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id A3A8021F889C for ; Tue, 5 Feb 2013 06:01:59 -0800 (PST) Received: (qmail 63390 invoked from network); 5 Feb 2013 14:01:57 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Feb 2013 14:01:57 -0000 Date: Tue, 05 Feb 2013 15:01:56 +0100 (CET) Message-Id: <20130205.150156.74693024.sthaug@nethelp.no> To: despres.remi@laposte.net Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: sthaug@nethelp.no In-Reply-To: <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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, 05 Feb 2013 14:02:01 -0000 > With these specifications, it is impossible on a SLAAC link that two hosts that have universal-scope addresses (necessarily different if they communicate at the MAC layer), would have conflicting IIDs at the IP layer if they derive them from MAC addresses. Impossible if the MAC addresses are indeed unique. That is correct for *almost* all cases. But not 100%. Steinar Haug, AS 2116 From despres.remi@laposte.net Tue Feb 5 06:11: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 ACFEE21F8754 for ; Tue, 5 Feb 2013 06:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvliUfvYQc2j for ; Tue, 5 Feb 2013 06:11:42 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id BE29621F863F for ; Tue, 5 Feb 2013 06:11:30 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id 52381700015E; Tue, 5 Feb 2013 15:11:29 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id CD1F3700011A; Tue, 5 Feb 2013 15:11:28 +0100 (CET) X-SFR-UUID: 20130205141128840.CD1F3700011A@msfrf2418.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <20130205.150156.74693024.sthaug@nethelp.no> Date: Tue, 5 Feb 2013 15:11:28 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1499) 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 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:11:42 -0000 Le 2013-02-05 =E0 15:01, sthaug@nethelp.no a =E9crit : >> With these specifications, it is impossible on a SLAAC link that two = hosts that have universal-scope addresses (necessarily different if they = communicate at the MAC layer), would have conflicting IIDs at the IP = layer if they derive them from MAC addresses. >=20 > Impossible if the MAC addresses are indeed unique. That is correct for > *almost* all cases. But not 100%. They are different 100% of cases at the IP layer if they are different = at the MAC layer (which is needed for communication at this layer). OK? RD >=20 > Steinar Haug, AS 2116 From brian.e.carpenter@gmail.com Tue Feb 5 06:36: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 AB2F521F880B for ; Tue, 5 Feb 2013 06:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.109 X-Spam-Level: X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwvLcYe7cIEP for ; Tue, 5 Feb 2013 06:36:55 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC4321F87BB for ; Tue, 5 Feb 2013 06:36:33 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi8so267776wib.7 for ; Tue, 05 Feb 2013 06:36:32 -0800 (PST) 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=z1k8X4n/vkYeyc0uL9BsYYasTcc0buYOYuwyc1PB6XE=; b=phchqhyvsluI/OPycynaKsIIX5+L7VKTaxQ2CgK39ZIdOB7lTbaI+rLQXrt94DLxld cOBp1dUyXdQuNkdHSaGQmgI0yr7IVwZlsAe32i9dbRoL4+hx+UzF1TU7nwAkZ6AM0jrb JWTzXqhss0G8FUdbwe7r4nalEp4zv/hAd7we2t8xxa6zlfqhS9deBrbLD6OOL4slQII6 GWzPIbW8Ep/rCx4P19HnZThgNDmSRw6xBrmJHrHq5QvY2lork62Ksv/X0OYduK3301/v q3PWQopzbwR/JX0h6FI/r+Ad0lWEEajtbAQwo/S5u7DJhco86wXqv6yUtlz296jcZS3G gneA== X-Received: by 10.180.83.227 with SMTP id t3mr17680620wiy.2.1360074992528; Tue, 05 Feb 2013 06:36:32 -0800 (PST) Received: from [128.232.110.79] (c079.al.cl.cam.ac.uk. [128.232.110.79]) by mx.google.com with ESMTPS id q13sm5550492wie.0.2013.02.05.06.36.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 06:36:31 -0800 (PST) Message-ID: <511118F1.6060906@gmail.com> Date: Tue, 05 Feb 2013 14:36:33 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 05 Feb 2013 14:36:55 -0000 On 05/02/2013 14:11, R=C3=A9mi Despr=C3=A9s wrote: > Le 2013-02-05 =C3=A0 15:01, sthaug@nethelp.no a =C3=A9crit : >=20 >>> With these specifications, it is impossible on a SLAAC link that two = hosts that have universal-scope addresses (necessarily different if they = communicate at the MAC layer), would have conflicting IIDs at the IP laye= r if they derive them from MAC addresses. >> Impossible if the MAC addresses are indeed unique. That is correct for= >> *almost* all cases. But not 100%. >=20 > They are different 100% of cases at the IP layer if they are different = at the MAC layer (which is needed for communication at this layer). > OK? Not if the same MAC address appears on two different subnets in the same site. This would work from a conventional IPv6 point of view, but it woul= d immediately demonstrate that the u bit does not mathematically guarantee uniqueness. There has been discussion recently in MIF of scenarios where the same IID would appear intentionally on different interfaces of the same device= =2E It is not the process of generating IIDs that is a problem - that is well defined. It is assuming after they have been generated that the u/g bits have meaning that is problematic. (Which is also why the solution of a reserved range makes sense for 4rd.) Brian From warren@kumari.net Tue Feb 5 06:56: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 32A1421F88B5 for ; Tue, 5 Feb 2013 06:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.601 X-Spam-Level: X-Spam-Status: No, score=-101.601 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERXGPIKdSjBP for ; Tue, 5 Feb 2013 06:56:06 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF26321F88B4 for ; Tue, 5 Feb 2013 06:56:06 -0800 (PST) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id 0A4B71B40706; Tue, 5 Feb 2013 09:56:06 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [6MAN] Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: Warren Kumari In-Reply-To: <20130205.150156.74693024.sthaug@nethelp.no> Date: Tue, 5 Feb 2013 09:56:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8467E1D9-9F7C-418E-99B5-0E6EDFABAB51@kumari.net> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1499) 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, 05 Feb 2013 14:56:07 -0000 On Feb 5, 2013, at 9:01 AM, sthaug@nethelp.no wrote: >> With these specifications, it is impossible on a SLAAC link that two = hosts that have universal-scope addresses (necessarily different if they = communicate at the MAC layer), would have conflicting IIDs at the IP = layer if they derive them from MAC addresses. >=20 > Impossible if the MAC addresses are indeed unique. That is correct for > *almost* all cases. But not 100%. Yup, there have been multiple instances where NIC vendors have = accidentally (or possibly intentionally) recycled MACs.=20 And, unfortunately with the increase in virtulization (and cloning of = virtual machines) the chances of identical MACs increases dramatically=85=20= W >=20 > Steinar Haug, AS 2116 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --=20 "I think it would be a good idea."=20 - Mahatma Ghandi, when asked what he thought of Western civilization From despres.remi@laposte.net Tue Feb 5 07:51: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 EE25521F8881 for ; Tue, 5 Feb 2013 07:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkUwC-lMOjR1 for ; Tue, 5 Feb 2013 07:51:20 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9A121F853A for ; Tue, 5 Feb 2013 07:51:20 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id 540867000154; Tue, 5 Feb 2013 16:51:19 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id 0D3677000087; Tue, 5 Feb 2013 16:51:19 +0100 (CET) X-SFR-UUID: 20130205155119542.0D3677000087@msfrf2303.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <511118F1.6060906@gmail.com> Date: Tue, 5 Feb 2013 16:51:17 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 6man 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, 05 Feb 2013 15:51:21 -0000 Bob, It seems the general discussion on u/g-bits clarification is going to be = long. Fortunately it also appears, for instance in the following, that = compatibility of the 4rd IID-range with the IPv6 addressing architecture = doesn't depend on this work being completed. 2013-02-05 15:36, Brian E Carpenter : ... > It is not the process of generating IIDs that is a problem - that is > well defined. It is assuming after they have been generated that the > u/g bits have meaning that is problematic. (Which is also why > the > solution of a reserved range makes sense for 4rd.) Unless I missed something conclusions that the 4rd IID range DOES NOT = conflict with the IPv6 addressing architecture have been expressed by = Brian Carpenter, Joel Halpern, Sheng Jiang, Gang Chen, and myself. Several opinions against a 4rd-range reservation have also been = expressed, but they concern the purpose of 4rd, or its experimental = status, or personal feelings against one more specification. They are = not about technical compatibility with the IPv6 addressing architecture.=20= Keeping the 4rd answer separate from the general u/g bit discussion will = permit, I hope, to now finalize this answer asap.=20 Best regards, RD > Brian >=20 From joelja@bogus.com Tue Feb 5 08:02: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 7943F21F84D9 for ; Tue, 5 Feb 2013 08:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H6Mzf++BSp5 for ; Tue, 5 Feb 2013 08:02:17 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DECC721F84D3 for ; Tue, 5 Feb 2013 08:02:16 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r15G2EDq075288 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 16:02:15 GMT (envelope-from joelja@bogus.com) Message-ID: <51112D01.9040000@bogus.com> Date: Tue, 05 Feb 2013 08:02:09 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Warren Kumari , sthaug@nethelp.no Subject: Re: [6MAN] Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <8467E1D9-9F7C-418E-99B5-0E6EDFABAB51@kumari.net> In-Reply-To: <8467E1D9-9F7C-418E-99B5-0E6EDFABAB51@kumari.net> Content-Type: text/plain; charset=windows-1252; 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]); Tue, 05 Feb 2013 16:02:16 +0000 (UTC) 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, 05 Feb 2013 16:02:17 -0000 On 2/5/13 6:56 AM, Warren Kumari wrote: > On Feb 5, 2013, at 9:01 AM, sthaug@nethelp.no wrote: > >>> With these specifications, it is impossible on a SLAAC link that two hosts that have universal-scope addresses (necessarily different if they communicate at the MAC layer), would have conflicting IIDs at the IP layer if they derive them from MAC addresses. >> Impossible if the MAC addresses are indeed unique. That is correct for >> *almost* all cases. But not 100%. > Yup, there have been multiple instances where NIC vendors have accidentally (or possibly intentionally) recycled MACs. > > And, unfortunately with the increase in virtulization (and cloning of virtual machines) the chances of identical MACs increases dramatically… or because you recycled your vrrp6 interface config. > W >> Steinar Haug, AS 2116 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> From joelja@bogus.com Tue Feb 5 08:10: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 BE1E621F88FC for ; Tue, 5 Feb 2013 08:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl-MXwh8MuFc for ; Tue, 5 Feb 2013 08:10:50 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8021F8599 for ; Tue, 5 Feb 2013 08:10:50 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r15GAhw4075483 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 16:10:44 GMT (envelope-from joelja@bogus.com) Message-ID: <51112EFE.2050305@bogus.com> Date: Tue, 05 Feb 2013 08:10:38 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter , =?UTF-8?B?UsOpbWkgRGU=?= =?UTF-8?B?c3Byw6lz?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> In-Reply-To: <511118F1.6060906@gmail.com> Content-Type: text/plain; charset=UTF-8; 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]); Tue, 05 Feb 2013 16:10:44 +0000 (UTC) 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, 05 Feb 2013 16:10:50 -0000 On 2/5/13 6:36 AM, Brian E Carpenter wrote: > On 05/02/2013 14:11, Rémi Després wrote: >> Le 2013-02-05 à 15:01, sthaug@nethelp.no a écrit : >> >>>> With these specifications, it is impossible on a SLAAC link that two hosts that have universal-scope addresses (necessarily different if they communicate at the MAC layer), would have conflicting IIDs at the IP layer if they derive them from MAC addresses. >>> Impossible if the MAC addresses are indeed unique. That is correct for >>> *almost* all cases. But not 100%. >> They are different 100% of cases at the IP layer if they are different at the MAC layer (which is needed for communication at this layer). >> OK? > Not if the same MAC address appears on two different subnets in the same > site. This would work from a conventional IPv6 point of view, but it would > immediately demonstrate that the u bit does not mathematically guarantee > uniqueness. that describes vlans on most ethernet switches... e.g. Vlan1729 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864) MTU 1500 bytes Up 217 days, 16 hours, 52 minutes, 58 seconds Vlan1730 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864) MTU 1500 bytes Up 217 days, 16 hours, 52 minutes, 58 seconds Vlan1731 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864) MTU 1500 bytes Up 217 days, 16 hours, 52 minutes, 58 seconds Vlan1732 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864) MTU 1500 bytes Up 217 days, 16 hours, 52 minutes, 58 seconds Vlan1792 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864) MTU 1500 bytes Up 217 days, 16 hours, 52 minutes, 58 seconds Vlan1793 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864) MTU 1500 bytes Up 217 days, 16 hours, 52 minutes, 58 seconds Vlan4094 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.7310.8864 (bia 001c.7310.8864) MTU 1500 bytes Up 336 days, 15 hours, 53 minutes, 49 seconds > > There has been discussion recently in MIF of scenarios where the same > IID would appear intentionally on different interfaces of the same device. > > It is not the process of generating IIDs that is a problem - that is > well defined. It is assuming after they have been generated that the > u/g bits have meaning that is problematic. (Which is also why the > solution of a reserved range makes sense for 4rd.) > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From despres.remi@laposte.net Tue Feb 5 08:51: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 B306621F893E for ; Tue, 5 Feb 2013 08:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E23wzRi6MEo for ; Tue, 5 Feb 2013 08:51:27 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 85CE121F85BB for ; Tue, 5 Feb 2013 08:51:26 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 7469170001C4; Tue, 5 Feb 2013 17:51:25 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 1642170001C2; Tue, 5 Feb 2013 17:51:25 +0100 (CET) X-SFR-UUID: 20130205165125915.1642170001C2@msfrf2409.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <511118F1.6060906@gmail.com> Date: Tue, 5 Feb 2013 17:51:24 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) 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 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:51:27 -0000 Brian, (a) The fact that IEEE MAC addresses are recycled by some vendors is = well understood. Please be sure I don't ignore it. (b) I am also well convinced that u=3D1 isn't a "mathematical guarantee" = of uniqueness.=20 To me, what is important is agreeing that the 4rd IID range makes sense.=20= (Despite my understanding that the point I had made below isn't = contradictory with (a) and (b) above, I see no point in arguing more = about it.) Thanks, RD Le 2013-02-05 =E0 15:36, Brian E Carpenter = a =E9crit : >=20 > On 05/02/2013 14:11, R=E9mi Despr=E9s wrote: >> Le 2013-02-05 =E0 15:01, sthaug@nethelp.no a =E9crit : >>=20 >>>> With these specifications, it is impossible on a SLAAC link that = two hosts that have universal-scope addresses (necessarily different if = they communicate at the MAC layer), would have conflicting IIDs at the = IP layer if they derive them from MAC addresses. >>> Impossible if the MAC addresses are indeed unique. That is correct = for >>> *almost* all cases. But not 100%. >>=20 >> They are different 100% of cases at the IP layer if they are = different at the MAC layer (which is needed for communication at this = layer). >> OK? >=20 > Not if the same MAC address appears on two different subnets in the = same > site. > This would work from a conventional IPv6 point of view, but it would > immediately demonstrate that the u bit does not mathematically = guarantee > uniqueness. >=20 > There has been discussion recently in MIF of scenarios where the same > IID would appear intentionally on different interfaces of the same = device. >=20 > It is not the process of generating IIDs that is a problem - that is > well defined. It is assuming after they have been generated that the > u/g bits have meaning that is problematic. (Which is also why the > solution of a reserved range makes sense for 4rd.) >=20 > Brian >=20 From roland.bless@kit.edu Tue Feb 5 09:07: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 78C6521F86E3 for ; Tue, 5 Feb 2013 09:07:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4J2aYPzGdao for ; Tue, 5 Feb 2013 09:07:51 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63E21F86E1 for ; Tue, 5 Feb 2013 09:07:49 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1U2lzi-0003f8-Mh for ; Tue, 05 Feb 2013 18:07:48 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 88E78A80629 for ; Tue, 5 Feb 2013 18:07:42 +0100 (CET) Message-ID: <51113C5E.6020003@kit.edu> Date: Tue, 05 Feb 2013 18:07:42 +0100 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 1360084068.647836000 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, 05 Feb 2013 17:07:52 -0000 Hi all, On 05.02.2013 16:51, Rémi Després wrote: > Several opinions against a 4rd-range reservation have also been > expressed, but they concern the purpose of 4rd, or its experimental > status, or personal feelings against one more specification. They are > not about technical compatibility with the IPv6 addressing > architecture. > > Keeping the 4rd answer separate from the general u/g bit discussion > will permit, I hope, to now finalize this answer asap. My personal summary is as follows: - The u/g bits have no real meaning in an IID (though the original intention of mapping EUI-64/48 addresses as modified EUI-64 into the IID may have been to preserve their meaning), so using them as indicator for the presence of a particular "IID format" seems to be not a good idea (see Brian's draft as well as Randy's "magic bits are almost never worth the pain"). - I feel uncomfortable with reserving another range in the IID space for 4rd, since it is not clear what implementations should do with it - building exceptions into implementations (e.g., martian IIDs) is error prone and may cause conflicts with future IID uses, even if 4rd is experimental. So I'm also sharing Ole's concerns here: http://www.ietf.org/mail-archive/web/ipv6/current/msg16976.html - without knowing too many details of the 4rd solution I'd rather propose to use configured 4rd subnet-IDs as indicator that the IID has a special format: this would be IMHO far more reliable and consistent than relying on this "reserved IID range". Since 4rd will require configuration anyway, one can configure the right 4rd /64s. I'm aware of the counter arguments (j)(m) in http://www.ietf.org/mail-archive/web/ipv6/current/msg16949.html, i.e., "free choice of subnet prefixes at CE sites" and "IID assignments made before 4rd activation". But it is not clear to me how often this will be _actually_ the case in practice and whether it's worth to "sacrifice" IID space and IPv6 flexibility for keeping these requirements. IPv6 is flexible enough to automatically reassign subnet prefixes or IIDs, thus I'm still not buying the arguments yet... Regards, Roland From internet-drafts@ietf.org Tue Feb 5 12:14: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 F2B5321F8566; Tue, 5 Feb 2013 12:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFaBc-Mul-DK; Tue, 5 Feb 2013 12:14:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B35521F85DB; Tue, 5 Feb 2013 12:14:47 -0800 (PST) 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-enhanced-dad-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130205201447.561.98583.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2013 12:14:47 -0800 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, 05 Feb 2013 20:14:48 -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 : Enhanced Duplicate Address Detection Author(s) : Rajiv Asati Hemant Singh Wes Beebee Eli Dart Wes George Carlos Pignataro Filename : draft-ietf-6man-enhanced-dad-02.txt Pages : 12 Date : 2013-02-05 Abstract: Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-enhanced-dad-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shemant@cisco.com Tue Feb 5 12:27: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 1458221F8468 for ; Tue, 5 Feb 2013 12:27:25 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ji5XEbw+m4X for ; Tue, 5 Feb 2013 12:27:24 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2B56E21F8467 for ; Tue, 5 Feb 2013 12:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2799; q=dns/txt; s=iport; t=1360096044; x=1361305644; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=d8LOML5+t47XoqLsCPsAYQOq4M3sNT3es51BSXijQOg=; b=H2SczIZo/6ppiRoKhgZPUwlIRE0/PAo3feisxgOWlJlj82IAppd7ySIN zjj7HusiETCCD1AMHQC5wKVruPTnSEKBOV0lqeluRt/+jM+vSnDVlxmzy hIToDnqSE0iZkFONxLEgH1Mx7jcuBNbOYE4I/FwfP7MkBB0EGCSCCf9AD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPxpEVGtJXG//2dsb2JhbABFg3e7bhZzgh8BAQEEAQEBNzQLDAYBCBEEAQELFAkuCxQJCQEEDgUIAYgIBwWqXZAkkHphA5c+jzWCfoIk X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="173699689" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 05 Feb 2013 20:27:23 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r15KRNGY001381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 20:27:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 14:27:23 -0600 From: "Hemant Singh (shemant)" To: "ipv6@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-02.txt Thread-Topic: I-D Action: draft-ietf-6man-enhanced-dad-02.txt Thread-Index: Ac4D3wDpWmFJTLz6TlWd0w9ZAx94WA== Date: Tue, 5 Feb 2013 20:27:22 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8911349E85@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ray Hunter \(v6ops@globis.net\)" 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, 05 Feb 2013 20:27:25 -0000 6man folks, Please see the new proposal made in the second paragraph of section 4 in th= is new version and provide feedback. The -01 version algorithm suppressed = subsequent probes on a detecting a looped back probe. The -02 version cha= nges to NOT suppress and probe forever. Thanks to Ray who caught the suppr= ession in the -01 version and asked not to suppress. Regards, Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Tuesday, February 05, 2013 3:15 PM To: i-d-announce@ietf.org Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-enhanced-dad-02.txt 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 : Enhanced Duplicate Address Detection Author(s) : Rajiv Asati Hemant Singh Wes Beebee Eli Dart Wes George Carlos Pignataro Filename : draft-ietf-6man-enhanced-dad-02.txt Pages : 12 Date : 2013-02-05 Abstract: Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-enhanced-dad-02 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 albert.e.manfredi@boeing.com Tue Feb 5 12:55: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 0D15221F8558 for ; Tue, 5 Feb 2013 12:55:27 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWhivbzaiujh for ; Tue, 5 Feb 2013 12:55:26 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4310221F8459 for ; Tue, 5 Feb 2013 12:55:26 -0800 (PST) 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 r15KtPMP008232 for ; Tue, 5 Feb 2013 12:55:25 -0800 Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r15KtNgX008200 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Feb 2013 12:55:25 -0800 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-03.mw.nos.boeing.com ([134.57.119.161]) with mapi; Tue, 5 Feb 2013 14:55:24 -0600 From: "Manfredi, Albert E" To: "Bless, Roland (TM)" , "ipv6@ietf.org" Date: Tue, 5 Feb 2013 14:55:22 -0600 Subject: RE: Keeping the 4rd-range issue separate from the general u/g discussion Thread-Topic: Keeping the 4rd-range issue separate from the general u/g discussion Thread-Index: Ac4Dw25gik02/wMvSW202esQOP20iAAHr+sQ Message-ID: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <51113C5E.6020003@kit.edu> In-Reply-To: <51113C5E.6020003@kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No 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, 05 Feb 2013 20:55:28 -0000 +1 If a better alternative is devised for 4rd, as Roland proposes here, then c= an we deprecate the u/g bit usage? Seems to me that privacy addresses are p= referable anyway, if not DHCP or statically assigned ones, so any importanc= e assigned to u/g surely becomes a historical artifact? Bert > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bless, Roland (TM) > Sent: Tuesday, February 05, 2013 12:08 PM > To: ipv6@ietf.org > Subject: Re: Keeping the 4rd-range issue separate from the general u/g > discussion >=20 > Hi all, >=20 > On 05.02.2013 16:51, R=E9mi Despr=E9s wrote: > > Several opinions against a 4rd-range reservation have also been > > expressed, but they concern the purpose of 4rd, or its experimental > > status, or personal feelings against one more specification. They are > > not about technical compatibility with the IPv6 addressing > > architecture. > > > > Keeping the 4rd answer separate from the general u/g bit discussion > > will permit, I hope, to now finalize this answer asap. >=20 > My personal summary is as follows: > - The u/g bits have no real meaning in an IID (though the original > intention of mapping EUI-64/48 addresses as modified EUI-64 into the > IID may have been to preserve their meaning), so using them as > indicator for the presence of a particular "IID format" seems to > be not a good idea (see Brian's draft as well as Randy's "magic bits > are almost never worth the pain"). >=20 > - I feel uncomfortable with reserving another range in the IID space > for 4rd, since it is not clear what implementations should do with > it - building exceptions into implementations (e.g., martian IIDs) > is error prone and may cause conflicts with future IID uses, > even if 4rd is experimental. > So I'm also sharing Ole's concerns here: > http://www.ietf.org/mail-archive/web/ipv6/current/msg16976.html >=20 > - without knowing too many details of the 4rd solution I'd rather > propose to use configured 4rd subnet-IDs as indicator that the > IID has a special format: this would be IMHO far more reliable > and consistent than relying on this "reserved IID range". Since 4rd > will require configuration anyway, one can configure the right 4rd > /64s. I'm aware of the counter arguments (j)(m) in > http://www.ietf.org/mail-archive/web/ipv6/current/msg16949.html, > i.e., "free choice of subnet prefixes at CE sites" and > "IID assignments made before 4rd activation". > But it is not clear to me how often this will be _actually_ the case > in practice and whether it's worth to "sacrifice" IID space and IPv6 > flexibility for keeping these requirements. IPv6 is flexible enough > to automatically reassign subnet prefixes or IIDs, thus I'm still > not buying the arguments yet... >=20 > Regards, > Roland > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ot@cisco.com Tue Feb 5 13:43: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 1936621F892E for ; Tue, 5 Feb 2013 13:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lH9PkrGDDku for ; Tue, 5 Feb 2013 13:43:00 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 134AB21F886A for ; Tue, 5 Feb 2013 13:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1685; q=dns/txt; s=iport; t=1360100579; x=1361310179; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rDAwy8PlXDtIryKAeGCISv6a4SgDm008uBFVRh/4ATk=; b=gWxFUwmEk0iPp/FxaFHOzTbrzJzQmOmCoXGxJMt44sf4EaY7KDYCiZYc yfVP+Uv8d6yUClZ+bLnt1WzCzSuFm1urvZEgMZYDrSLr/gMTekZ+hBS07 /h1vtUCzvrYyOhLZdVnOGmIrLBgEDzEs9WheHwBdzsVlPo6RNH05ydMcf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADN7EVGQ/khR/2dsb2JhbABFv2kWc4IgAQEEeRALRlcGLod2qn2QIZB6YQOWIZBSgn8 X-IronPort-AV: E=Sophos;i="4.84,610,1355097600"; d="scan'208";a="150178653" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Feb 2013 21:42:56 +0000 Received: from dhcp-10-61-98-83.cisco.com (dhcp-10-61-98-83.cisco.com [10.61.98.83]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r15LgtJL011310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2013 21:42:56 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: Ole Troan In-Reply-To: Date: Tue, 5 Feb 2013 22:42:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46EBD0C2-AED8-41D5-BAB8-5A2A9DF67F05@cisco.com> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <51113C5E.6020003@kit.edu> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1499) 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, 05 Feb 2013 21:43:01 -0000 > +1 >=20 > If a better alternative is devised for 4rd, as Roland proposes here, = then can we deprecate the u/g bit usage? Seems to me that privacy = addresses are preferable anyway, if not DHCP or statically assigned = ones, so any importance assigned to u/g surely becomes a historical = artifact? indeed. 4rd tries to solve the problem of having a 4rd CE located behind the CPE = (that receives the IPv6 delegated prefix). the current 4rd solution is to try to share the on-link /64 that is = also used by native hosts. for a single shared IPv4 address, I believe a 4rd CE would require 2^16 = addresses. (the last 16 bits are used for the CNP). i.e. a /112. the problematic assumption 4rd makes, is that it requires these = addresses without having a mechanism to do duplicate address detection. what are the alternatives to a fixed reservation of the interface-id = space proposed? 1) pick a separate /64 for the purpose of the 4rd function. an automated = mechanism for prefix assignment is being worked on in homenet. (draft-arkko-homenet-prefix-assignment-03)=20 2) defend the 4rd CE address space using DAD. pick 64K addresses out = ::0:a.b:c.d:CNP. chances of a conflict are small, and you would be able to detect and = defend those for nodes trying to take that address after the 4rd CE comes up. I wouldn't recommend doing DAD on every = address first. so you may end up in a situation where you encounter a conflict while in operation. that should be = possible to handle though. 3) remove the CNP feature that makes 4rd require so many addresses to = function. =20 either of these are=20 cheers, Ole From dougb@dougbarton.us Tue Feb 5 15:45: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 384BE21F8605 for ; Tue, 5 Feb 2013 15:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DhW8pxTiP6q for ; Tue, 5 Feb 2013 15:45:09 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 944B921F85FD for ; Tue, 5 Feb 2013 15:45:09 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:811e:396d:817b:69b7] (unknown [IPv6:2001:470:d:5e7:811e:396d:817b:69b7]) by dougbarton.us (Postfix) with ESMTPSA id 3BE8222BA8; Tue, 5 Feb 2013 23:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1360107909; bh=E5qrPG1ogk0w++Q2p0GqOkufkqbqm1lB73wbiAXKZrM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=pY3WSfTxiFGBrzS40LLKcokCdhOsdcIp4vr00WREynfDC++8k5CBsaUb36JqkLYr7 OCiUqOOw6A50kjUzaNWtMwZMCp35/Ya75Tp70nkAdT4675ljC6e/EcCJ4INFPnSldh 0uX6Ns+yYvhIy9NEepF4er3CLuTrW2YH2ThdcCas= Message-ID: <51119983.4050403@dougbarton.us> Date: Tue, 05 Feb 2013 15:45:07 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> In-Reply-To: <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man 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, 05 Feb 2013 23:45:10 -0000 On 02/05/2013 05:57 AM, Rémi Després wrote: > Hi, Doug, > > Please see inline. > > > 2013-02-04 à 18:37, Doug Barton : > >> On 02/04/2013 12:38 AM, Rémi Després wrote: >>> It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough exceptions. This is somewhat similar to the expectation that ULA collisions shouldn't be seen). >>> >>> This theoretical unicity has been extensively used to assign stable IIDs, without administrative action, to hosts that have no privacy constraints requiring the opposite. >> >> What software exists that makes determinations based on the u bit? > > (*) Major OSes can assign IIDs derived from IEEE MAC addresses of their LAN adapters (if not by default, at least as a possibility). They do it because of what IEEE and IETF have specified, each one for its own domain, concerning their respective u bits. Yes, you've described reality. You haven't answered my questions. > With these specifications, it is impossible on a SLAAC link that two hosts that have universal-scope addresses (necessarily different if they communicate at the MAC layer), would have conflicting IIDs at the IP layer if they derive them from MAC addresses. What makes the addresses unique are the unique MACs, not the u bit. >> How would that software be impacted if the u bit were suddenly be devoid of meaning? > > Hosts would become free to assign arbitrary IIDs having u=1, breaking applicability of (*) above. Faulty premise -> faulty conclusion. >> I am of course assuming that DAD would still be in play for dynamically assigned addresses, which it seems we are all in agreement on. > > Sure (agreement confirmed). > > > Hope it clarifies. To me, it clarifies that you don't have answers to my questions. Given that you cannot demonstrate any negative impact to un-defining the u bit, I wonder what the basis of your objection is. Doug From marka@isc.org Tue Feb 5 19:12: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 1418121F85FC for ; Tue, 5 Feb 2013 19:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC6J0PGGLPob for ; Tue, 5 Feb 2013 19:12:40 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CD75021F85A2 for ; Tue, 5 Feb 2013 19:12:21 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2E2DEC9432 for ; Wed, 6 Feb 2013 03:12:16 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1360120340; bh=BAp9hDfIOlfoeqP80ct21cRqRy8nC/kY27MuekLGUE0=; h=To:From:Subject:Date; b=awMJM0Ts85DgrqfWWAXp4DkyQOFO/phouyjuHBitfynZLKl+xRBFosjHYc1UYzaEw 1ZgBYx1ZN40Dga16CYzFxkgxpeSXPzWJA5xy5YcCweRTFkMevqonL27B9CkOEqRlxQ WTzXJH0NvtvDUJr78jAleB2zBB6rF4S6j6bbJR+g= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS for ; Wed, 6 Feb 2013 03:12:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fd3c:4fc0:9596:e28a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id BD71E216C3B for ; Wed, 6 Feb 2013 03:12:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5F7EC2F16E68 for ; Wed, 6 Feb 2013 14:12:12 +1100 (EST) To: ipv6@ietf.org From: Mark Andrews Subject: draft-ietf-6man-addr-select-opt Date: Wed, 06 Feb 2013 14:12:12 +1100 Message-Id: <20130206031212.5F7EC2F16E68@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist 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, 06 Feb 2013 03:12:41 -0000 prefix: A variable-length field containing an IP address or the prefix of an IP address. An IPv4-mapped address [RFC4291] must be used to represent an IPv4 address as a prefix value. The prefix should be left aligned, big-endian, and zero padded on the right up to the next octet boundary. So the length of this field should be between 0 and 16 bytes is ambigious on the encoding of 2002:1234:8734::/64 is it: 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00 or 40:20:02:12:34:87:34:00:00 or 40:20:02:12:34:87:34:00 or 40:20:02:12:34:87:34 All appear to be legal. It would be cleaner if the floor((prefix-len+7)/8) gave the number of octets in the prefix field. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From markzzzsmith@yahoo.com.au Tue Feb 5 19: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 260A521F8622 for ; Tue, 5 Feb 2013 19:28:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po84xorZD-PQ for ; Tue, 5 Feb 2013 19:28:55 -0800 (PST) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) by ietfa.amsl.com (Postfix) with ESMTP id 524C221F85F3 for ; Tue, 5 Feb 2013 19:28:55 -0800 (PST) Received: from [98.139.212.144] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 03:28:54 -0000 Received: from [98.139.212.199] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 03:28:54 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 03:28:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 186062.67098.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 53661 invoked by uid 60001); 6 Feb 2013 03:28:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360121334; bh=2NTTj59KdAu/Gzl06mJEmuYDPrsud2TZpvslXhy//jw=; 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=y0aexTmf8/Zz+l4BRNj8+l+SWNQs85Os4Txzi0QJuViLfAUNLS/Bz0I7oZvTODVIqVhY4SWZ5iXn7lX7qXZbGJsdIGJUVNfx9GR5au8O9ujM1R6xt2ek47ZOLhjQ1GNJsrHgyXMU8cjnsdU9VuiAI9DyzK6RWJCRv9/ukJPUyew= 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=bnoIzPgu+cXnM4OijotZfWtM5auieNQrYZBPMATO28Wwemlxf13COaQ2N4EkoQJJ0ANzuiRWc72Vj2gLtwmO+v8HyuI8oqjuheOxZ586CnCkjjkcj+q2Z14KK+ASUQT/+Hj2IOVQQms03ss43tI19s+IiBU9blcB7Es+6pBayPQ=; X-YMail-OSG: uSpLR_0VM1kzeCyQ7gL0iBgPxOUqQFBFTuSmYBBNyufYKnz IlacBVPvgO_eq.m4Fa_O17CiYIJKpb2mZB6LBjcUy9xHYTM9WsnvYxXBkMPT EXFssJzS7ANjVg6QQMUBZVmDq0uHI6cj2vB_fZW6bg7VigeHoiktsASxSctw 3kxlCY.Jg4sfovOBZSRkkJF27qGMtOtX4FfI0nbVVKVYOVZkplVg2VMuHJoc s4sp8NLtPtiCKndwjl53Tae7QnHAHZJvEKDdAsKrGS0YC299mHRYrmDQ7wEw J25bYP.X.Ud8wuT9wLREdnsOTsDooAP.h31R5jG6Ill_Y6vXTSBJJBdNfKB0 oFYqkWqqAh6jpZoWO7HG5EKfilkQcyO.zhwOdH13xa522vOlJLULyPYF0a51 6W..NDqxO418ayfQ3JAgOtpubA0Scgd_3EB9MlrLEu2iV0PfnmO9zxLzOaUo ejCVOF4sUnAX0LNzFE_HAoocs_JdvBE0.pQ9K0WnTy7sKWdJ3j1cOaCxBA1M TW5MrIImRRB3ygXLkREqvCU1H3c3a5ZTAnibGtgJ23CT4SYjAF89bAXr2xr9 wqQCFpGo_c6g6DA2I534qKrw7oymh0.K5fQDteMSgngj6nSXevnPRcmvlVb4 Ymjr_SwjbPO9kuZ28qKnUk3050QQPCg-- Received: from [121.200.231.211] by web142504.mail.bf1.yahoo.com via HTTP; Tue, 05 Feb 2013 19:28:53 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAic3RoYXVnQG5ldGhlbHAubm8iIDxzdGhhdWdAbmV0aGVscC5ubz4KPiBUbzogZGVzcHJlcy5yZW1pQGxhcG9zdGUubmV0Cj4gQ2M6IGlwdjZAaWV0Zi5vcmcKPiBTZW50OiBXZWRuZXNkYXksIDYgRmVicnVhcnkgMjAxMyAxOjAxIEFNCj4gU3ViamVjdDogUmU6IFtGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWNhcnBlbnRlci02bWFuLXVnLTAwLnR4dF0KPiAKPj4gIFdpdGggdGhlc2Ugc3BlY2lmaWNhdGlvbnMsIGl0IGlzIGltcG9zc2libGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> Message-ID: <1360121333.53631.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Tue, 5 Feb 2013 19:28:53 -0800 (PST) From: Mark Smith Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] To: "sthaug@nethelp.no" , "despres.remi@laposte.net" In-Reply-To: <20130205.150156.74693024.sthaug@nethelp.no> 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: Wed, 06 Feb 2013 03:28:56 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "sthaug@nethelp.no" =0A> To: despres.remi@laposte.net=0A> Cc: ipv6@ietf.org=0A> = Sent: Wednesday, 6 February 2013 1:01 AM=0A> Subject: Re: [Fwd: I-D Action:= draft-carpenter-6man-ug-00.txt]=0A> =0A>> With these specifications, it i= s impossible on a SLAAC link that two hosts =0A> that have universal-scope = addresses (necessarily different if they communicate =0A> at the MAC layer)= , would have conflicting IIDs at the IP layer if they derive =0A> them from= MAC addresses.=0A> =0A> Impossible if the MAC addresses are indeed unique.= That is correct for=0A> *almost* all cases. But not 100%.=0A=0ASo I emaile= d HD Moore, who did the research which produced this slide, showing volumes= of duplicate MAC addresses by vendor.=0A=0A=0Ahttps://speakerdeck.com/hdm/= derbycon-2012-the-wild-west?slide=3D64=0A=0A=0AI asked him if he would be a= ble sent me some info on the number of=A0occurrences=A0of duplication by MA= C address. He sent me quite a bit of information, which I'll need to ask hi= m how much he is willing for me to publish publicly. However, I'm confident= that he'd be ok with the following.=0A=0AHere is the top 10 list of occurr= ences of individual MAC addresses:=0A=0A- 6987574=0A- =A0829787=0A- =A07876= 61=0A- =A0347282=0A- =A0292288=0A- =A0112580=0A- =A0 =A095484=0A- =A0 =A060= 295=0A- =A0 =A060254=0A- =A0 =A060125=0A=0AYes, that first number is 6 mill= ion.=0A=0AThis information was gleaned from NetBIOS Name Service informatio= n accessible over the Internet, so it is a subset of the possible actual nu= mbers of duplicate MAC addresses.=0A=0A=0A=0A> =0A> Steinar Haug, AS 2116= =0A> --------------------------------------------------------------------= =0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------= ------------------------------------------------------=0A> From james.cutler@consultant.com Tue Feb 5 19: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 482A721F89E9 for ; Tue, 5 Feb 2013 19:54:01 -0800 (PST) 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=[BAYES_00=-2.599, FAKE_HELO_MAIL_COM=1.317, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdPsUOcvn-Ns for ; Tue, 5 Feb 2013 19:54:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [74.208.4.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7117D21F89E1 for ; Tue, 5 Feb 2013 19:54:00 -0800 (PST) Received: from mailout-us.mail.com ([172.19.198.94]) by mrigmx.server.lan (mrigmxus001) with ESMTP (Nemesis) id 0MPm4s-1Tz4C53BCM-00508K for ; Wed, 06 Feb 2013 04:53:59 +0100 Received: (qmail invoked by alias); 06 Feb 2013 03:53:59 -0000 Received: from c-68-43-142-33.hsd1.mi.comcast.net (EHLO [192.168.1.44]) [68.43.142.33] by mail.gmx.com (mp-us011) with SMTP; 05 Feb 2013 22:53:59 -0500 X-Authenticated: #76096295 X-Provags-ID: V01U2FsdGVkX18rpMYm4tIrAAsFs55CsHEERKNImeKJsvLwr3CLhP lKqAF5KF3CWcdq Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft-ietf-6man-addr-select-opt From: Cutler James R In-Reply-To: <20130206031212.5F7EC2F16E68@drugs.dv.isc.org> Date: Tue, 5 Feb 2013 22:53:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130206031212.5F7EC2F16E68@drugs.dv.isc.org> To: ipv6@ietf.org, Mark Andrews X-Mailer: Apple Mail (2.1499) X-Y-GMX-Trusted: 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: Wed, 06 Feb 2013 03:54:01 -0000 On Feb 5, 2013, at 10:12 PM, Mark Andrews wrote: > prefix: A variable-length field containing an IP address or the > prefix of an IP address. An IPv4-mapped address [RFC4291] = must > be used to represent an IPv4 address as a prefix value. The > prefix should be left aligned, big-endian, and zero padded = on > the right up to the next octet boundary. So the length of = this > field should be between 0 and 16 bytes >=20 > is ambigious on the encoding of 2002:1234:8734::/64 >=20 > is it: > 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00:00 > or > 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00 > or > 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00 > or > 40:20:02:12:34:87:34:00:00:00:00:00:00 > or > 40:20:02:12:34:87:34:00:00:00:00:00 > or > 40:20:02:12:34:87:34:00:00:00:00 > or > 40:20:02:12:34:87:34:00:00:00 > or > 40:20:02:12:34:87:34:00:00 > or > 40:20:02:12:34:87:34:00 > or > 40:20:02:12:34:87:34 >=20 > All appear to be legal. It would be cleaner if the > floor((prefix-len+7)/8) gave the number of octets in > the prefix field. Mark, You have me confused here. /64 defines a prefix length of 64 bits, = exactly 8 octets. Octet for Octet, 20:02:12:34:87:34:00:00 is = unambiguously correct and in accordance with the definition cited. = Please explain where the leading 40 originates. James R. Cutler james.cutler@consultant.com From marka@isc.org Tue Feb 5 20:50: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 F1C4821F89E1 for ; Tue, 5 Feb 2013 20:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJVjFNrU58oq for ; Tue, 5 Feb 2013 20:50:28 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B1C8B21F89A4 for ; Tue, 5 Feb 2013 20:50:27 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4595B5F9923; Wed, 6 Feb 2013 04:50:18 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1360126226; bh=KHfyKthxGFOZiZf/koh04cjHGJYTl27HdVl7XnjYXe4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=F1Hc0qedu+OkRbXF+Tpx2uihp3lPkAmXWAmVJgDh0JkCQjEnFJS2I5tFRQmBtwreP iUZpOZ02RaehOjVYyc4cEUxAyzuyQJWdULIGCbOH4M/ycloVNJdh3nVRlsBFT3PBl/ 4/0tMJuyReYdtO0p8asU4F/4lR+EhGGFH5WQvvGY= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A0344216C3B; Wed, 6 Feb 2013 04:50:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5145A2F17B51; Wed, 6 Feb 2013 15:50:13 +1100 (EST) To: Cutler James R From: Mark Andrews References: <20130206031212.5F7EC2F16E68@drugs.dv.isc.org> Subject: Re: draft-ietf-6man-addr-select-opt In-reply-to: Your message of "Tue, 05 Feb 2013 22:53:57 CDT." Date: Wed, 06 Feb 2013 15:50:12 +1100 Message-Id: <20130206045013.5145A2F17B51@drugs.dv.isc.org> 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, 06 Feb 2013 04:50:29 -0000 In message , Cutler James R writes: > On Feb 5, 2013, at 10:12 PM, Mark Andrews wrote: > > prefix: A variable-length field containing an IP address or the > > prefix of an IP address. An IPv4-mapped address [RFC4291] = > must > > be used to represent an IPv4 address as a prefix value. The > > prefix should be left aligned, big-endian, and zero padded = > on > > the right up to the next octet boundary. So the length of = > this > > field should be between 0 and 16 bytes > >=20 > > is ambigious on the encoding of 2002:1234:8734::/64 > >=20 > > is it: > > 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00:00 > > or > > 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00 > > or > > 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00 > > or > > 40:20:02:12:34:87:34:00:00:00:00:00:00 > > or > > 40:20:02:12:34:87:34:00:00:00:00:00 > > or > > 40:20:02:12:34:87:34:00:00:00:00 > > or > > 40:20:02:12:34:87:34:00:00:00 > > or > > 40:20:02:12:34:87:34:00:00 > > or > > 40:20:02:12:34:87:34:00 > > or > > 40:20:02:12:34:87:34 > >=20 > > All appear to be legal. It would be cleaner if the > > floor((prefix-len+7)/8) gave the number of octets in > > the prefix field. > > Mark, > > You have me confused here. /64 defines a prefix length of 64 bits, = > exactly 8 octets. Octet for Octet, 20:02:12:34:87:34:00:00 is = > unambiguously correct and in accordance with the definition cited. = > Please explain where the leading 40 originates. The 40 was the prefix length octet (0x40 == 64). Sorry for not being clear on that. The sub-option has a length field which means that you can append zeros up to the defined maximum (16). As it is a zero padded field you can also theoretically remove trailing zeros without loss of information. Nothing in the definition says that you can't do that. prefix-len: An 8-bit unsigned integer; the number of leading bits in the prefix that are valid. The value ranges from 0 to 128. Mark > James R. Cutler > james.cutler@consultant.com > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From despres.remi@laposte.net Wed Feb 6 02:01: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 9BEC521F8800 for ; Wed, 6 Feb 2013 02:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYC4avYrML3y for ; Wed, 6 Feb 2013 02:01:23 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5A21F85FE for ; Wed, 6 Feb 2013 02:01:22 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id D1E0C70000C0; Wed, 6 Feb 2013 11:01:20 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 9EC76700007A; Wed, 6 Feb 2013 11:01:20 +0100 (CET) X-SFR-UUID: 20130206100120650.9EC76700007A@msfrf2412.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <51119983.4050403@dougbarton.us> Date: Wed, 6 Feb 2013 11:01:20 +0100 Message-Id: <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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: Wed, 06 Feb 2013 10:01:23 -0000 2013-02-06 00:45, Doug Barton : > On 02/05/2013 05:57 AM, R=E9mi Despr=E9s wrote: >> Hi, Doug, >>=20 >> Please see inline. >>=20 >>=20 >> 2013-02-04 =E0 18:37, Doug Barton : >>=20 >>> On 02/04/2013 12:38 AM, R=E9mi Despr=E9s wrote: >>>> It remains that IIDs having u=3D1 SHOULD be unique, i.e. with rare = enough exceptions. This is somewhat similar to the expectation that ULA = collisions shouldn't be seen). >>>>=20 >>>> This theoretical unicity has been extensively used to assign stable = IIDs, without administrative action, to hosts that have no privacy = constraints requiring the opposite. >>>=20 >>> What software exists that makes determinations based on the u bit? >>=20 >> (*) Major OSes can assign IIDs derived from IEEE MAC addresses of = their LAN adapters (if not by default, at least as a possibility). They = do it because of what IEEE and IETF have specified, each one for its own = domain, concerning their respective u bits. >=20 > Yes, you've described reality. You haven't answered my questions. Fair enough. My answer is that no software that I know makes determination based on = the u bit. My point is that it isn't sufficient for the IETF u bit to have no = meaning. (a) It has what is specified in RFC 4291. (b) No software I know creates IIDs having u =3D 1 without an IEEE-based = OUI.=20 QUESTION: Do you know one? >> With these specifications, it is impossible on a SLAAC link that two = hosts that have universal-scope addresses (necessarily different if they = communicate at the MAC layer), would have conflicting IIDs at the IP = layer if they derive them from MAC addresses. >=20 > What makes the addresses unique are the unique MACs, not the u bit. No disagreement on this. >=20 >>> How would that software be impacted if the u bit were suddenly be = devoid of meaning? >>=20 >> Hosts would become free to assign arbitrary IIDs having u=3D1, = breaking applicability of (*) above. >=20 > Faulty premise -> faulty conclusion. This gets too subtle for my ability to understand which premises and = which conclusion you talk about. Let's go to basics. Are you suggesting to CHANGE the u bit significance? - If no, no disagreement is IMHO worth debating - If yes, we have indeed different opinions. See below. =20 >=20 >>> I am of course assuming that DAD would still be in play for = dynamically assigned addresses, which it seems we are all in agreement = on. >>=20 >> Sure (agreement confirmed). >>=20 >>=20 >> Hope it clarifies. >=20 > To me, it clarifies that you don't have answers to my questions. I have now answered the ONLY remaining question from you I have noticed. Your turn to answer mine. > Given that you cannot demonstrate any negative impact to un-defining = the u bit, I wonder what the basis of your objection is. The logic is the reverse. Before changing a standard, one needs to = demonstrate it is indispensable. QUESTIONS: =20 (a) Which sentences of RFC 4291 you think MUST be changed? (b) Why? Please give your personal answers (not by reference to comments made by = someone else). Thanks, RD >=20 > Doug >=20 From markzzzsmith@yahoo.com.au Wed Feb 6 02:12: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 8828121F85FE for ; Wed, 6 Feb 2013 02:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HztUVHtwYTDR for ; Wed, 6 Feb 2013 02:12:44 -0800 (PST) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with SMTP id 913F021F846C for ; Wed, 6 Feb 2013 02:12:43 -0800 (PST) Received: from [98.139.214.32] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 10:12:41 -0000 Received: from [98.139.212.193] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 10:12:41 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 10:12:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 679385.77810.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 11414 invoked by uid 60001); 6 Feb 2013 10:12:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360145561; bh=n7y/Qvw2xe+QjuE44xD0Zv78QsDoPEweq6vT7VU3Fis=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hu9GxYCAbI8UGzWg1GKIOk45Gi0xy0SoY03QKQz4mBcDxqHl+/UAdDRykZwP/+jyypT00kWdnjTElDm7bgCfYuqZpXMK8DQF1ObPVbD+Qn6Z/YPYJx5xtqkEV1M5n7lAsV2o1CKeTsUq3MaBeWqoSBVvRlW47jMofV32Z8fKG30= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ObcolIKmrtzK6pvondaNQY4ceJiFjreJPLosO/+gA8+UDBcjJLdsYRITToAmGr3rJR0T04r+AzkOxavQeAvjQu5r3XvXWeoy70W8rxL9e/Wsln+5fSTE7zB0uzR6RqICqkGgbiygkRhqQm17HFIeqKhLdAPR/8fsso/X2ChhpGw=; X-YMail-OSG: aEgk3dkVM1m13XfM1MXD.hCf6p9lGrhToaW_OkcjepHtiwy s9wXwUh_o_67jcAOLZObYPQQDrmlsmhAXanV5lM9icCFM5Vf87PCDIXOq_XR BjuEsBxAXDB.tSSiEONwk79s1O.0igRmkvBsekCGllv_MvlHbazN0dh46ekW Q0L2ySG36YqKymiS_VNwXAD67kY68F4wDemMidQVbTSU.QeRipLoqADsfPwD WUGq_dSoOm.bTrjHJHzAKqh34zoCI1OPpCAaC4.qY6JuvHRgcN8JK4rWoEqe KQk1OWt1ocydPA1I_iVihaAxkyAfIq4LWrZzPm06gwgyDT7Ij9ZCYDxZH0.r 93p_zCMO1k10dNA2XgieVgVpe.otf2J8v63KQDKbUwaD3js3NBryLXeI32la Rj5chG2rYxofvzEkwZLSrzS.Q8zTIdWjqa7CDPJhuYBN2G5O5usuW1SaY7cw rwgW62.0_rxH.2xdOHocgVB57dd.uP.FUaaFghASqL2YOijl50fKkefIUWvQ hpwM0O2qW2VxEJxcDbS37nAstJJVZ Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Wed, 06 Feb 2013 02:12:41 PST X-Rocket-MIMEInfo: 001.001, SGksCgoKSSB3YXMgYXNrZWQgb2ZmIGxpc3QgdG8gY2xhcmlmeSBpZiB0aGUgTUFDIGFkZHJlc3NlcyBpbiB0aGUgZm9sbG93aW5nIGxpc3QgaGFkIHRoZSBMb2NhbGx5IEFzc2lnbmVkIGJpdCBzd2l0Y2hlZCBvZmYsIGkuZS4gZG9uJ3QgaGF2ZSAweDAyIGluIHRoZWlyIGZpcnN0IG9jdGV0LgoKCkkndmUgZmxhZ2dlZCB0aGXCoHN1cHBvc2VkIGdsb2JhbGx5IHVuaXF1ZSBvbmVzIGJlbG93IHdpdGggYSAqLiBJJ3ZlIGFsc28gZmxhZ2dlZCB0aGUgc2FtZSBPVUkgL3ZlbmRvciB3aXRoIGEgJiBvciArIHN5bWIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <1360121333.53631.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1360145561.10752.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Wed, 6 Feb 2013 02:12:41 -0800 (PST) From: Mark Smith Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] To: "ipv6@ietf.org" In-Reply-To: <1360121333.53631.YahooMailNeo@web142504.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 06 Feb 2013 10:12:45 -0000 Hi,=0A=0A=0AI was asked off list to clarify if the MAC addresses in the fol= lowing list had the Locally Assigned bit switched off, i.e. don't have 0x02= in their first octet.=0A=0A=0AI've flagged the=A0supposed globally unique = ones below with a *. I've also flagged the same OUI /vendor with a & or + s= ymbol when they appear at least twice. Finally, I've flagged ones where the= OUI resolves to a name via the IEEE=A0OUI PUBLIC LISTING web page with '= =3D'.=0A=0A> =0A> Here is the top 10 list of occurrences of individual MAC = addresses:=0A> =0A> - 6987574 *=0A> - =A0829787=0A> - =A0787661 *=3D=0A> - = =A0347282 *=0A> - =A0292288 *=0A> - =A0112580 *&=0A> - =A0 =A095484 *&=0A> = - =A0 =A060295 *+=3D=0A> - =A0 =A060254 *+=3D=0A> - =A0 =A060125 *+=3D=0A> = =0A=0A=0ARegards,=0AMark. From despres.remi@laposte.net Wed Feb 6 02:13: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 0CD9B21F8869 for ; Wed, 6 Feb 2013 02:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjRVcHi1rmke for ; Wed, 6 Feb 2013 02:13:53 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3F721F86E6 for ; Wed, 6 Feb 2013 02:13:53 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 9C988700007F; Wed, 6 Feb 2013 11:13:52 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 87B9370000AC; Wed, 6 Feb 2013 11:13:52 +0100 (CET) X-SFR-UUID: 20130206101352556.87B9370000AC@msfrf2412.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 6 Feb 2013 11:13:53 +0100 Message-Id: <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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: Wed, 06 Feb 2013 10:13:54 -0000 Bob, This is, in my understanding, what should be avoided in 6man, a debate = on new 4rd modifications: - The 4rd design has been stabilized for long in Softwire. - The question to 6man is ONLY whether the proposed reserved range is = compatible with the IPv6 addressing architecture. Thanks, RD > De : Ole Troan > Objet : R=E9p : Keeping the 4rd-range issue separate from the general = u/g discussion > Date : 2013-02-05 22:42 > =C0 : "Manfredi, Albert E" > Cc: "ipv6@ietf.org" >=20 >> +1 >>=20 >> If a better alternative is devised for 4rd, as Roland proposes here, = then can we deprecate the u/g bit usage? Seems to me that privacy = addresses are preferable anyway, if not DHCP or statically assigned = ones, so any importance assigned to u/g surely becomes a historical = artifact? >=20 > indeed. > 4rd tries to solve the problem of having a 4rd CE located behind the = CPE (that receives the IPv6 delegated prefix). > the current 4rd solution is to try to share the on-link /64 that is = also used by native hosts. >=20 > for a single shared IPv4 address, I believe a 4rd CE would require = 2^16 addresses. (the last 16 bits are used for the CNP). > i.e. a /112. >=20 > the problematic assumption 4rd makes, is that it requires these = addresses without having a mechanism to do duplicate address > detection. >=20 > what are the alternatives to a fixed reservation of the interface-id = space proposed? >=20 > 1) pick a separate /64 for the purpose of the 4rd function. an = automated mechanism for prefix assignment is being worked > on in homenet. (draft-arkko-homenet-prefix-assignment-03)=20 >=20 > 2) defend the 4rd CE address space using DAD. pick 64K addresses out = ::0:a.b:c.d:CNP. > chances of a conflict are small, and you would be able to detect = and defend those for nodes trying to take that address > after the 4rd CE comes up. I wouldn't recommend doing DAD on every = address first. so you may end up in a situation > where you encounter a conflict while in operation. that should be = possible to handle though. >=20 > 3) remove the CNP feature that makes 4rd require so many addresses to = function. >=20 > either of these are=20 > cheers, > Ole >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From otroan@employees.org Wed Feb 6 03:46: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 6F4C021F892B for ; Wed, 6 Feb 2013 03:46:15 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV+1ivxwU1oy for ; Wed, 6 Feb 2013 03:46:15 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3421F885C for ; Wed, 6 Feb 2013 03:46:14 -0800 (PST) Received: from dhcp-lys01-vla250-10-147-113-8.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id A174D5F3D; Wed, 6 Feb 2013 03:46:13 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: Ole Troan In-Reply-To: <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> Date: Wed, 6 Feb 2013 12:46:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: 6man 6man-wg , Bob Hinden 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, 06 Feb 2013 11:46:15 -0000 Remi, the point I'm trying to make is that the future of 4rd does not depend = on 6man accepting the request for a reserved space. 4rd can function very well without it. cheers, Ole > This is, in my understanding, what should be avoided in 6man, a = debate on new 4rd modifications: > - The 4rd design has been stabilized for long in Softwire. > - The question to 6man is ONLY whether the proposed reserved range is = compatible with the IPv6 addressing architecture. >=20 > Thanks, > RD >=20 >=20 >=20 >> De : Ole Troan >> Objet : R=E9p : Keeping the 4rd-range issue separate from the general = u/g discussion >> Date : 2013-02-05 22:42 >> =C0 : "Manfredi, Albert E" >> Cc: "ipv6@ietf.org" >>=20 >>> +1 >>>=20 >>> If a better alternative is devised for 4rd, as Roland proposes here, = then can we deprecate the u/g bit usage? Seems to me that privacy = addresses are preferable anyway, if not DHCP or statically assigned = ones, so any importance assigned to u/g surely becomes a historical = artifact? >>=20 >> indeed. >> 4rd tries to solve the problem of having a 4rd CE located behind the = CPE (that receives the IPv6 delegated prefix). >> the current 4rd solution is to try to share the on-link /64 that is = also used by native hosts. >>=20 >> for a single shared IPv4 address, I believe a 4rd CE would require = 2^16 addresses. (the last 16 bits are used for the CNP). >> i.e. a /112. >>=20 >> the problematic assumption 4rd makes, is that it requires these = addresses without having a mechanism to do duplicate address >> detection. >>=20 >> what are the alternatives to a fixed reservation of the interface-id = space proposed? >>=20 >> 1) pick a separate /64 for the purpose of the 4rd function. an = automated mechanism for prefix assignment is being worked >> on in homenet. (draft-arkko-homenet-prefix-assignment-03)=20 >>=20 >> 2) defend the 4rd CE address space using DAD. pick 64K addresses out = ::0:a.b:c.d:CNP. >> chances of a conflict are small, and you would be able to detect = and defend those for nodes trying to take that address >> after the 4rd CE comes up. I wouldn't recommend doing DAD on every = address first. so you may end up in a situation >> where you encounter a conflict while in operation. that should be = possible to handle though. >>=20 >> 3) remove the CNP feature that makes 4rd require so many addresses to = function. >>=20 >> either of these are=20 >> cheers, >> Ole >>=20 >> -------------------------------------------------------------------- >> 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 roland.bless@kit.edu Wed Feb 6 04:07: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 374A821F8552 for ; Wed, 6 Feb 2013 04:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+W3z9MmXz5I for ; Wed, 6 Feb 2013 04:07:30 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64821F8550 for ; Wed, 6 Feb 2013 04:07:29 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U33md-0004oT-D5; Wed, 06 Feb 2013 13:07:28 +0100 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 1U33md-0005Vj-6B; Wed, 06 Feb 2013 13:07:23 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id F02F7A8043C; Wed, 6 Feb 2013 13:07:22 +0100 (CET) Message-ID: <5112477A.2030105@kit.edu> Date: Wed, 06 Feb 2013 13:07:22 +0100 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> In-Reply-To: <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 1360152448.411416000 Cc: 6man 6man-wg , Bob Hinden 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, 06 Feb 2013 12:07:31 -0000 Dear Rémi, Am 06.02.2013 11:13, schrieb Rémi Després: > This is, in my understanding, what should be avoided in 6man, a debate on new 4rd modifications: > - The 4rd design has been stabilized for long in Softwire. > - The question to 6man is ONLY whether the proposed reserved range is compatible with the IPv6 addressing architecture. This isn't totally decoupled: - if someone asks to introduce a "new format"/magic bits into the IID, my answer is: "this is bad for the IPv6 addressing architecture" - if someone asks to reserve a larger range in the IID space my answer is: "this is bad for the IPv6 addressing architecture", because it is unclear what implementations should do with these specially reserved IIDs and how conflicts are resolved. It may be "compatible" with the current IPv6 addressing architecture, but it's a bad idea. - Furthermore, your solution should IMHO not solely rely on testing the "IID format" or range, as there are probably more robust and reliable solutions as I pointed out. Regards, Roland From despres.remi@laposte.net Wed Feb 6 05: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 EF87D21F86C8 for ; Wed, 6 Feb 2013 05:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmtw3Xbmsmy0 for ; Wed, 6 Feb 2013 05:52:51 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1985021F869B for ; Wed, 6 Feb 2013 05:52:49 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2519.sfr.fr (SMTP Server) with ESMTP id CAAD77000042; Wed, 6 Feb 2013 14:52:48 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2519.sfr.fr (SMTP Server) with ESMTP id 9790270000BD; Wed, 6 Feb 2013 14:52:48 +0100 (CET) X-SFR-UUID: 20130206135248620.9790270000BD@msfrf2519.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5112477A.2030105@kit.edu> Date: Wed, 6 Feb 2013 14:52:48 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 06 Feb 2013 13:52:53 -0000 2013-02-06 =E0 13:07, "Bless, Roland (TM)" : > Dear R=E9mi, >=20 > Am 06.02.2013 11:13, schrieb R=E9mi Despr=E9s: >> This is, in my understanding, what should be avoided in 6man, a = debate on new 4rd modifications: >> - The 4rd design has been stabilized for long in Softwire. >> - The question to 6man is ONLY whether the proposed reserved range is = compatible with the IPv6 addressing architecture. >=20 > This isn't totally decoupled: > - if someone asks to introduce a "new format"/magic bits > into the IID, my answer is: > "this is bad for the IPv6 addressing architecture" As already said, the 4rd range only makes a first use of an existing = RFC4291 provision: "The use of the universal/local bit in the Modified EUI-64 format = identifier is to allow development of future technology that can take = advantage of interface identifiers with universal scope." New, indeed, but nothing magic. > - if someone asks to reserve a larger range in the IID space > my answer is: > "this is bad for the IPv6 addressing architecture", because > it is unclear what implementations should do with these > specially reserved IIDs and how conflicts are resolved. > It may be "compatible" with the current IPv6 addressing > architecture, but it's a bad idea. - Once more: existing implementations have NOTHING to do (as long as = they don't add 4rd support). Expressed doubts on this should be justified by a detailed technical = justification. If you have any, let's look at it. - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a = tool to RESOLVE them when they occur.=20 =20 > - Furthermore, your solution should IMHO not solely rely on > testing the "IID format" or range, as there are probably more > robust and reliable solutions as I pointed out. This doesn't concern "compatibility with the IPv6 addressing = architecture". Regards, RD >=20 > Regards, > Roland >=20 From fernando@gont.com.ar Wed Feb 6 08:20:16 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 8CD2221F8715 for ; Wed, 6 Feb 2013 08:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8ogU0b1KGGT for ; Wed, 6 Feb 2013 08:20:15 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2D921F87FE for ; Wed, 6 Feb 2013 08:20:15 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U37iO-0000xc-D4; Wed, 06 Feb 2013 17:19:44 +0100 Message-ID: <511281D0.6010208@gont.com.ar> Date: Wed, 06 Feb 2013 13:16:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Bob Hinden , 6man 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: Wed, 06 Feb 2013 16:20:16 -0000 On 02/06/2013 10:52 AM, Rémi Després wrote: > > - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a tool to RESOLVE them when they occur. DAD *detects* them, but does not resolve them (for instance, the last "D" stands for detection). As a datapoint, all the v6 implementations I know of support DAD, yet they do not resolve DAD failures when one is encountered. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ot@cisco.com Wed Feb 6 08:28: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 7675F21F89EE for ; Wed, 6 Feb 2013 08:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbPnix2SQMOf for ; Wed, 6 Feb 2013 08:28:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A139421F89E9 for ; Wed, 6 Feb 2013 08:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=584; q=dns/txt; s=iport; t=1360168111; x=1361377711; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JKRl4sezb/V0oSBXcH86YMgoRIL7diQnk/4YmhtoXUI=; b=CZevghH51cJkEPUqAL7/Nyhw+dwTL9nKyTAhWj6GsB0gw8TR6tgf911T 24Z7xhyHca5pAYQAwImC2Lu6sPPuRC6IbqGP8Vmo6hb5PWk17H5TVet+Z +g3YnFk1P8dG3xpKB5PjjjR9c/MJJInf+AYxx2f/HYardV5xSCWz8b5nV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAJAHODElGQ/khL/2dsb2JhbABFvz8EBIEAFnOCIAEBBHkQC0ZXBogkvE2QemEDliGQUoJ/ X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; d="scan'208";a="150210856" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2013 16:28:29 +0000 Received: from dhcp-lys01-vla250-10-147-113-8.cisco.com (dhcp-lys01-vla250-10-147-113-8.cisco.com [10.147.113.8]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r16GSSle021295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Feb 2013 16:28:29 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: Ole Troan In-Reply-To: <511281D0.6010208@gont.com.ar> Date: Wed, 6 Feb 2013 17:28:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: 6man 6man-wg , Bob Hinden 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, 06 Feb 2013 16:28:31 -0000 Fernando, >> - The reserved range is a tool to AVOID conflicts. It isn't, like = DAD, a tool to RESOLVE them when they occur.=20 >=20 > DAD *detects* them, but does not resolve them (for instance, the last > "D" stands for detection). As a datapoint, all the v6 implementations = I > know of support DAD, yet they do not resolve DAD failures when one is > encountered. unless you call the fact that the duplicate address is not assigned to = the interface, as resolving the problem. with Remi's proposal, a duplicate address will not even be detected. cheers, Ole From despres.remi@laposte.net Wed Feb 6 08:37: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 03ED021F8A00 for ; Wed, 6 Feb 2013 08:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYngz69g6lgm for ; Wed, 6 Feb 2013 08:37:05 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id E8EE521F8585 for ; Wed, 6 Feb 2013 08:37:04 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 4BC637000910; Wed, 6 Feb 2013 17:37:03 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id A0492700090C; Wed, 6 Feb 2013 17:37:02 +0100 (CET) X-SFR-UUID: 20130206163702656.A0492700090C@msfrf2319.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <511281D0.6010208@gont.com.ar> Date: Wed, 6 Feb 2013 17:37:02 +0100 Message-Id: <5F33CD52-482F-43CC-80CF-4CAA50B5601B@laposte.net> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden , 6man 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: Wed, 06 Feb 2013 16:37:11 -0000 Le 2013-02-06 =E0 17:16, Fernando Gont a =E9crit = : > On 02/06/2013 10:52 AM, R=E9mi Despr=E9s wrote: >>=20 >> - The reserved range is a tool to AVOID conflicts. It isn't, like = DAD, a tool to RESOLVE them when they occur.=20 >=20 > DAD *detects* them, but does not resolve them (for instance, the last > "D" stands for detection). Right, thanks for noting I failed to be as rigorous as I should. I should have said DETECT as far DAD is concerned (I do know what it = means!), or have referred to RFC 4941 (privacy extension) as a tool to = RESOLVE duplicates if "detected" by DAD. =20 > As a datapoint, all the v6 implementations I > know of support DAD, yet they do not resolve DAD failures when one is > encountered. Well, RFC 4941 says "If DAD indicates the address is already in use, the = node MUST generate a new randomized interface identifier", and is widely = implemented (as I am sure you know).=20 Your turn, it seems, to be less rigorous than you could ;-). Regards, RD =20 >=20 > Cheers, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 From roland.bless@kit.edu Wed Feb 6 08:41: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 771B321F861A for ; Wed, 6 Feb 2013 08:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2vXO8syO-GM for ; Wed, 6 Feb 2013 08:41:47 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8440721F85D2 for ; Wed, 6 Feb 2013 08:41:47 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U3845-0003QG-IF; Wed, 06 Feb 2013 17:41:46 +0100 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 1U3845-00065b-B5; Wed, 06 Feb 2013 17:41:41 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 353D7A804A8; Wed, 6 Feb 2013 17:41:41 +0100 (CET) Message-ID: <511287C5.20203@kit.edu> Date: Wed, 06 Feb 2013 17:41:41 +0100 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 1360168906.675002000 Cc: 6man 6man-wg , Bob Hinden 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, 06 Feb 2013 16:41:48 -0000 Hi, Am 06.02.2013 14:52, schrieb Rémi Després: > As already said, the 4rd range only makes a first use of an existing > RFC4291 provision: "The use of the universal/local bit in the > Modified EUI-64 format identifier is to allow development of future > technology that can take advantage of interface identifiers with > universal scope." As it turns out now, this assumption is probably no longer true. > - Once more: existing implementations have NOTHING to do (as long as > they don't add 4rd support). Expressed doubts on this should be > justified by a detailed technical justification. If you have any, > let's look at it. I was talking more about implications on new/forthcoming/updated implementations. Do they need to keep a list of reserved IIDs and check against them? This seems to be a bad idea IMHO. We have no clear rules for this yet. > - The reserved range is a tool to AVOID conflicts. It isn't, like > DAD, a tool to RESOLVE them when they occur. That's exactly my point: what should future implementations do in order to avoid such conflicts? In case that they are not using 4rd, MUST they exclude this IID range? Regards, Roland From erik.hugne@ericsson.com Wed Feb 6 08:23: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 DB5CB21F879A for ; Wed, 6 Feb 2013 08:23:07 -0800 (PST) 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_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgSYybpLecRN for ; Wed, 6 Feb 2013 08:23:06 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3721F87FF for ; Wed, 6 Feb 2013 08:23:03 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-9b-51128364a709 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F6.D7.19728.46382115; Wed, 6 Feb 2013 17:23:01 +0100 (CET) Received: from eerihug-hybrid.ki.sw.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 6 Feb 2013 17:23:00 +0100 Date: Wed, 6 Feb 2013 17:20:07 +0100 From: Erik Hugne To: ipv6@ietf.org Subject: RFC4291 - ff01::/16 Message-ID: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKJMWRmVeSWpSXmKPExsUyM+JvrW5qs1CgwaoHHBYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxosfNxgLrjBWXNq9hrGBcRljFyMnh4SAicTLZT9ZIWwxiQv3 1rN1MXJxCAmcZJR41PyYEcLZzShx+MgSdpAqFgEVid+fO8A62AS0JCY+n8gEYosICEpsf/CD BcQWFpCROLhuEZjNK+Aqcf/kKWYIW1Di5MwnYHFmAR2JBbs/AW3jALKlJZb/4wAJiwKNn3Jy GxuILQRk3385m30CI98sJN2zkHTPQuhewMi8ipE9NzEzJ73caBMjMGgObvmtuoPxzjmRQ4zS HCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDGujYv0+3o3GfAxNA6I/xAwgIJ mx49+yPezp27rwYHiD/4kdFvkPTbMXr22d05m5PFnD/q/r5fPVvmhKqr44KOdzz9oSt8ribr BX5Xm5MuvSsyyPZGuMqeSA5zqTQbwbUHt2bNm3f7v2D6/Hs15zMrFc+oe/A83LOR6Z2/kr+2 fu8yqYXfLiixFGckGmoxFxUnAgBqCcVO6AEAAA== X-Mailman-Approved-At: Wed, 06 Feb 2013 08:45:48 -0800 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, 06 Feb 2013 16:23:08 -0000 RFC4291 is clear that packets destined to ff01::/16 must never leave the local node, but what should be done if such packets are received as a result from a broken implementation on the other side? //E From roland.bless@kit.edu Wed Feb 6 08:52: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 D7B4B21F842E for ; Wed, 6 Feb 2013 08:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCqPW-uTnZbU for ; Wed, 6 Feb 2013 08:52:27 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED7121F842A for ; Wed, 6 Feb 2013 08:52:26 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U38EO-0004JN-AS; Wed, 06 Feb 2013 17:52:25 +0100 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 1U38EO-0006Yh-1W; Wed, 06 Feb 2013 17:52:20 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id E73BDA804A8; Wed, 6 Feb 2013 17:52:19 +0100 (CET) Message-ID: <51128A43.4000900@kit.edu> Date: Wed, 06 Feb 2013 17:52:19 +0100 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> In-Reply-To: <511281D0.6010208@gont.com.ar> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 1360169545.639790000 Cc: 6man 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: Wed, 06 Feb 2013 16:52:28 -0000 Hi Fernando, Am 06.02.2013 17:16, schrieb Fernando Gont: > On 02/06/2013 10:52 AM, Rémi Després wrote: >> >> - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a tool to RESOLVE them when they occur. > > DAD *detects* them, but does not resolve them (for instance, the last > "D" stands for detection). As a datapoint, all the v6 implementations I > know of support DAD, yet they do not resolve DAD failures when one is > encountered. Partially true: it is "resolved" so that two hosts do not use the same address at the same time in this subnet. DAD does not specify how to get out of the DAD failure, e.g., retry with a new address etc. DAD resolves a conflict if one host has got already an address and another host tries to configure the same address. In this case the latter host will be usually left with an unusable address in state tentative/dad conflict. If two hosts try to configure the same address at the same time, both will not get a working address after detecting a duplicate address. I would say that the conflict is resolved, but the systems are not left in a state in which they can communicate thereafter. Regards, Roland From despres.remi@laposte.net Wed Feb 6 08:55: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 9EC0421F844C for ; Wed, 6 Feb 2013 08:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeiI7fc7-gA2 for ; Wed, 6 Feb 2013 08:55:04 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id EF39021F842E for ; Wed, 6 Feb 2013 08:55:03 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id 30C07700020A; Wed, 6 Feb 2013 17:55:03 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id DDF727000200; Wed, 6 Feb 2013 17:55:02 +0100 (CET) X-SFR-UUID: 20130206165502909.DDF727000200@msfrf2321.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <511287C5.20203@kit.edu> Date: Wed, 6 Feb 2013 17:55:02 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511287C5.20203@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 06 Feb 2013 16:55:04 -0000 2013-02-06 17:41, "Bless, Roland (TM)" : > Hi, >=20 > Am 06.02.2013 14:52, schrieb R=E9mi Despr=E9s: >> As already said, the 4rd range only makes a first use of an existing >> RFC4291 provision: "The use of the universal/local bit in the >> Modified EUI-64 format identifier is to allow development of future >> technology that can take advantage of interface identifiers with >> universal scope." >=20 > As it turns out now, this assumption is probably no longer true. This isn't an "assumption", this is just a quote of RFC 4291. >> - Once more: existing implementations have NOTHING to do (as long as >> they don't add 4rd support). Expressed doubts on this should be >> justified by a detailed technical justification. If you have any, >> let's look at it. >=20 > I was talking more about implications on new/forthcoming/updated > implementations. Do they need to keep a list of reserved IIDs > and check against them? No, they don't. > This seems to be a bad idea IMHO. > We have no clear rules for this yet. If it would be the case, yes, it would be a bad idea, but it isn't the = case. >> - The reserved range is a tool to AVOID conflicts. It isn't, like >> DAD, a tool to RESOLVE them when they occur. >=20 > That's exactly my point: what should future implementations > do in order to avoid such conflicts? Nothing new needs to be done in any implementation other than that of a = 4rd-supporting devices (4rd CEs and BRs).=20 > In case that they are > not using 4rd, MUST they exclude this IID range? Because of RFC 4291 is as it is, softwares that assign IIDs NEVER do it = with u=3Dg=3D1 =3D> they don't need any update to exclude the 4rd range. (That's precisely why the 4rd range has been chosen with u=3Dg=3D1). Regards, RD >=20 > Regards, > Roland From roland.bless@kit.edu Wed Feb 6 08:59: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 B8E2121F8569 for ; Wed, 6 Feb 2013 08:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9izVPYKQKV9 for ; Wed, 6 Feb 2013 08:59:53 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 292F721F855D for ; Wed, 6 Feb 2013 08:59:52 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U38Lb-0004tb-Bs for ; Wed, 06 Feb 2013 17:59:52 +0100 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 for id 1U38Lb-0007mb-2w; Wed, 06 Feb 2013 17:59:47 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id F21FBA804A8 for ; Wed, 6 Feb 2013 17:59:46 +0100 (CET) Message-ID: <51128C02.4080301@kit.edu> Date: Wed, 06 Feb 2013 17:59:46 +0100 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: RFC4291 - ff01::/16 References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> In-Reply-To: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> X-Enigmail-Version: 1.4.6 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 1360169992.269869000 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, 06 Feb 2013 16:59:53 -0000 Hi, On 06.02.2013 17:20, Erik Hugne wrote: > RFC4291 is clear that packets destined to ff01::/16 must never leave > the local node, but what should be done if such packets are received > as a result from a broken implementation on the other side? "Be liberal in what you accept, and conservative in what you send", Since the sending node obviously violated the 2nd part of Jon Postel's robustness principle, it should be ignored and dropped by the receiving system. Moreover, report the failure to the vendor of the broken implementation or fix it by yourself if possible ;-) Regards, Roland From igor@yahoo-inc.com Wed Feb 6 09: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 4A1A321F89EE for ; Wed, 6 Feb 2013 09:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl8FZlN-93KF for ; Wed, 6 Feb 2013 09:44:37 -0800 (PST) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 70D5421F8A00 for ; Wed, 6 Feb 2013 09:44:37 -0800 (PST) Received: from netops1.corp.bf1.yahoo.com (netops1.corp.bf1.yahoo.com [98.139.254.110]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r16HhYPV021575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2013 09:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1360172616; bh=qpO9bLwwFAE56/GK4TS6avr1vXpbjEIIdZFQxAfGIJA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=vorKfds3DJ9pZDCGjU1rhUBiHgHkYBAxfHcbdtVokJsBO+ApEcRiKoBDs5nigVqqj NR1Z9vvICinI4Calgurztq8w4S14x7UqUo0rCm08UMDDnpRLgwXF7T+87cqlr1aGNs nGC59LstlGZL85ta2OTCAwFeieZR9GgEWqEMYGf8= Date: Wed, 6 Feb 2013 09:43:34 -0800 (PST) From: Igor Gashinsky X-X-Sender: igor@netops1.corp.bf1.yahoo.com To: Ole Troan Subject: Re: Writeup: draft-ietf-6man-impatient-nud In-Reply-To: <6D97AA88-5BD0-4D5A-9A11-7CB905DC00B5@cisco.com> Message-ID: References: <6D97AA88-5BD0-4D5A-9A11-7CB905DC00B5@cisco.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 172615002 X-Mailman-Approved-At: Wed, 06 Feb 2013 10:01:04 -0800 Cc: nordmark@cisco.com, "draft-ietf-6man-impatient-nud@tools.ietf.org" , 6man 6man-wg , draft-alias-bounces@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, 06 Feb 2013 17:44:38 -0000 Hey Ole, Cisco has this implemented in certain code trains today (on nexus/6500 platforms), and there is at least one other switch manufacturer that is about to release it as well. Thanks, -igor On Tue, 5 Feb 2013, Ole Troan wrote: :: Erik, Igor, :: :: as part of doing the writeup to the IESG. do you know of any implementations or plans for implementations :: of impatient NUD? :: :: cheers, :: Ole :: --------------------+----------------------+------------------ Igor Gashinsky | Network Architecture | Yahoo! Inc. igor@yahoo-inc.com | cell 917.807.2213 | Do You... Yahoo? --------------------+----------------------+------------------ From mcr@sandelman.ca Wed Feb 6 10:25: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 E5F5F21F8A71 for ; Wed, 6 Feb 2013 10:25:00 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofPhTnfjkdt1 for ; Wed, 6 Feb 2013 10:25:00 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DC6AE21F8A79 for ; Wed, 6 Feb 2013 10:24:59 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 916EA2016D for ; Wed, 6 Feb 2013 13:30:55 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6FCB163769; Wed, 6 Feb 2013 13:23:57 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5D18E636C5 for ; Wed, 6 Feb 2013 13:23:57 -0500 (EST) From: Michael Richardson To: ipv6@ietf.org Subject: Re: RFC4291 - ff01::/16 In-Reply-To: <51128C02.4080301@kit.edu> References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.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: Wed, 06 Feb 2013 18:25:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "TM" =3D=3D TM writes: >> RFC4291 is clear that packets destined to ff01::/16 must never >> leave the local node, but what should be done if such packets are >> received as a result from a broken implementation on the other >> side? TM> "Be liberal in what you accept, and conservative in what you TM> send", Since the sending node obviously violated the 2nd part of TM> Jon Postel's robustness principle, it should be ignored and TM> dropped by the receiving system. Moreover, report the failure The key is that the packets should be dropped without generating any errors or traffic. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAURKfvYqHRg3pndX9AQIF7gQA2ElKDkEoNCVO0Ad53gakLzmwMiE8RRm5 fgYWBi7oYwV5YspSQCQ5OjESgbaXNyxzFuDSnAprXIR9sjXpzFzmIUnPOaO8kh86 0sAQNf3q82sBeaCpDxrfWMwDkoufCvkSumuGz03fy2oZ/I4gyFhntI/4eylum4vW xfAxjLWygUg= =8swZ -----END PGP SIGNATURE----- --=-=-=-- From joelja@bogus.com Wed Feb 6 11:48: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 DF2E321F88B6 for ; Wed, 6 Feb 2013 11:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUBtkcDfRxFM for ; Wed, 6 Feb 2013 11:48:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6974621F8809 for ; Wed, 6 Feb 2013 11:48:30 -0800 (PST) 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 r16JmSMp095124 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 6 Feb 2013 19:48:28 GMT (envelope-from joelja@bogus.com) Message-ID: <5112B387.5070002@bogus.com> Date: Wed, 06 Feb 2013 11:48:23 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Igor Gashinsky , Ole Troan Subject: Re: Writeup: draft-ietf-6man-impatient-nud References: <6D97AA88-5BD0-4D5A-9A11-7CB905DC00B5@cisco.com> In-Reply-To: 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, 06 Feb 2013 19:48:29 +0000 (UTC) Cc: nordmark@cisco.com, 6man 6man-wg , "draft-ietf-6man-impatient-nud@tools.ietf.org" , draft-alias-bounces@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, 06 Feb 2013 19:48:31 -0000 We talked to dell/f10 about it, I don't have a timeline or promise for that yet. joel On 2/6/13 9:43 AM, Igor Gashinsky wrote: > Hey Ole, > > Cisco has this implemented in certain code trains today (on nexus/6500 > platforms), and there is at least one other switch manufacturer that is > about to release it as well. > > Thanks, > -igor > > On Tue, 5 Feb 2013, Ole Troan wrote: > > :: Erik, Igor, > :: > :: as part of doing the writeup to the IESG. do you know of any implementations or plans for implementations > :: of impatient NUD? > :: > :: cheers, > :: Ole > :: > > --------------------+----------------------+------------------ > Igor Gashinsky | Network Architecture | Yahoo! Inc. > igor@yahoo-inc.com | cell 917.807.2213 | Do You... Yahoo? > --------------------+----------------------+------------------ > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From rbonica@juniper.net Wed Feb 6 12:24: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 EE44D21F868D for ; Wed, 6 Feb 2013 12:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHHLZLITb+wn for ; Wed, 6 Feb 2013 12:24:05 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0F89F21F8681 for ; Wed, 6 Feb 2013 12:24:03 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKURK74mc2sblbelAaN6N5eMFVbfZFZQzy@postini.com; Wed, 06 Feb 2013 12:24:05 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Feb 2013 12:22:55 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 6 Feb 2013 12:22:54 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 6 Feb 2013 12:31:40 -0800 Received: from mail77-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 20:22:50 +0000 Received: from mail77-tx2 (localhost [127.0.0.1]) by mail77-tx2-R.bigfish.com (Postfix) with ESMTP id B0126420262 for ; Wed, 6 Feb 2013 20:22:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -27 X-BigFish: PS-27(zz9371I103dK542I1432I62a3Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2 (MessageSwitch) id 1360182169597876_28867; Wed, 6 Feb 2013 20:22:49 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.248]) by mail77-tx2.bigfish.com (Postfix) with ESMTP id 82CA26005B; Wed, 6 Feb 2013 20:22:49 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Feb 2013 20:22:48 +0000 Received: from BL2PRD0512MB646.namprd05.prod.outlook.com ([169.254.9.155]) by BL2PRD0512HT001.namprd05.prod.outlook.com ([10.255.233.34]) with mapi id 14.16.0263.000; Wed, 6 Feb 2013 20:22:45 +0000 From: Ronald Bonica To: Fernando Gont , "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> Subject: RE: Moving forward draft-ietf-6man-oversized-header chain? Thread-Topic: Moving forward draft-ietf-6man-oversized-header chain? Thread-Index: AQHOAw28zEIc3pLjHkiS7gIVdRH7CphtSPow Date: Wed, 6 Feb 2013 20:22:45 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> References: <51100B9E.2040503@si6networks.com> In-Reply-To: <51100B9E.2040503@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%SI6NETWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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, 06 Feb 2013 20:24:06 -0000 Hi Fernando, If the chairs were to initiate a last call, I would support this document. Maybe the chairs can comment? Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: Monday, February 04, 2013 2:27 PM > To: 6man-chairs@tools.ietf.org > Cc: ipv6@ietf.org > Subject: Moving forward draft-ietf-6man-oversized-header chain? >=20 > Folks, >=20 > I was wondering what's the status of draft-ietf-6man-oversized-header- > chain. >=20 > Was it ready to ship to the IESG? Or does it still need to be WGLC'ed? >=20 > FWIW, this I-D has been stable for a few months now, and quite a few > folks agreed that it was ready to progress. >=20 > Thanks! >=20 > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From roland.bless@kit.edu Wed Feb 6 12:54: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 1BC4221F853C for ; Wed, 6 Feb 2013 12:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP2JuKAZNMH4 for ; Wed, 6 Feb 2013 12:54:44 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id E247B21F8514 for ; Wed, 6 Feb 2013 12:54:42 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U3C0m-00072v-6q; Wed, 06 Feb 2013 21:54:37 +0100 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 1U3C0m-0000Vz-0H; Wed, 06 Feb 2013 21:54:32 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id A77E0A804A8; Wed, 6 Feb 2013 21:54:31 +0100 (CET) Message-ID: <5112C307.7070308@kit.edu> Date: Wed, 06 Feb 2013 21:54:31 +0100 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: RFC4291 - ff01::/16 References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> In-Reply-To: <5857.1360175037@sandelman.ca> X-Enigmail-Version: 1.5 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 1360184077.861555000 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, 06 Feb 2013 20:54:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 06.02.2013 19:23, Michael Richardson wrote: >>>>>> "TM" == TM writes: >>> RFC4291 is clear that packets destined to ff01::/16 must never >>> leave the local node, but what should be done if such packets >>> are received as a result from a broken implementation on the >>> other side? > > TM> "Be liberal in what you accept, and conservative in what you > TM> send", Since the sending node obviously violated the 2nd part > of TM> Jon Postel's robustness principle, it should be ignored and > TM> dropped by the receiving system. Moreover, report the failure > > The key is that the packets should be dropped without generating > any errors or traffic. Yep, you are right - I assumed that implicitly, but I should have mentioned that explicitly :-) Regards, Roland -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlESwwEACgkQ1YyfLd659kdpaACfai8zkguwd5YYIlD47K5j7CqJ Hl8An14AMH5Z4sWfjRNimZeEMYOaZXnn =fCgK -----END PGP SIGNATURE----- From roland.bless@kit.edu Wed Feb 6 13:12: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 877E321F84ED for ; Wed, 6 Feb 2013 13:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImqRpVZlg1Sc for ; Wed, 6 Feb 2013 13:12:26 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id B621E21F84EA for ; Wed, 6 Feb 2013 13:12:24 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U3CHy-00005L-0t; Wed, 06 Feb 2013 22:12:23 +0100 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 1U3CHx-0000J2-14; Wed, 06 Feb 2013 22:12:17 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 70872A804A8; Wed, 6 Feb 2013 22:12:16 +0100 (CET) Message-ID: <5112C72F.6040900@kit.edu> Date: Wed, 06 Feb 2013 22:12:15 +0100 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: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511287C5.20203@kit.edu> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 1360185143.544048000 Cc: 6man 6man-wg , Bob Hinden 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, 06 Feb 2013 21:12:26 -0000 Hi, On 06.02.2013 17:55, Rémi Després wrote: >> Am 06.02.2013 14:52, schrieb Rémi Després: >>> As already said, the 4rd range only makes a first use of an existing >>> RFC4291 provision: "The use of the universal/local bit in the >>> Modified EUI-64 format identifier is to allow development of future >>> technology that can take advantage of interface identifiers with >>> universal scope." >> >> As it turns out now, this assumption is probably no longer true. > > This isn't an "assumption", this is just a quote of RFC 4291. I meant the assumption within the RFC 4291... > Nothing new needs to be done in any implementation other than that of a 4rd-supporting devices (4rd CEs and BRs). > >> In case that they are >> not using 4rd, MUST they exclude this IID range? > > Because of RFC 4291 is as it is, softwares that assign IIDs NEVER do it with u=g=1 => they don't need any update to exclude the 4rd range. > (That's precisely why the 4rd range has been chosen with u=g=1). Then I don't see a compelling reason to reserve an IID range for 4rd, since it should work without the reservation just fine. Regards, Roland From ot@cisco.com Wed Feb 6 13:29: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 1450521F8552 for ; Wed, 6 Feb 2013 13:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziVWDBpFW7oV for ; Wed, 6 Feb 2013 13:29:41 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9B621F854F for ; Wed, 6 Feb 2013 13:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=248; q=dns/txt; s=iport; t=1360186181; x=1361395781; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jcXW7u11/8YbpCyLq0rChI8pettUH3olD7bhKd3gj1o=; b=P1q4Yq4cJAOJ+8FyGSgRP9B9X5is628S/OOmBnwkPayYbypo0fZ5mDFp vbVKJX+3P7zL1WA3sqq2hQ7J1Scwf1xHbNGZ/ULa/iBHGvYlNXOk2ZiVX bj9mVMM9lJADLlWFWqpqydKWRBkgBGIo2v9ZEJfpx+kbpiJK/huCL7Odq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPzKElGQ/khN/2dsb2JhbABFwFAWc4IfAQEBAwE6PwULCw44VwaIHga8W5B4YQOWIZBSgn8 X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208";a="11647877" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 06 Feb 2013 21:29:40 +0000 Received: from dhcp-10-61-107-57.cisco.com (dhcp-10-61-107-57.cisco.com [10.61.107.57]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r16LTdqZ018764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Feb 2013 21:29:40 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Ole Troan In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> Date: Wed, 6 Feb 2013 22:29:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1499) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "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, 06 Feb 2013 21:29:42 -0000 Ron, thanks for the reminder. > If the chairs were to initiate a last call, I would support this document. > > Maybe the chairs can comment? Bob and I will discuss progress on this document in our call next week. Best regards, Ole From ot@cisco.com Wed Feb 6 13:51: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 8CDDA21F8470 for ; Wed, 6 Feb 2013 13:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSXJEpcgujcn for ; Wed, 6 Feb 2013 13:51:07 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9891C21F8684 for ; Wed, 6 Feb 2013 13:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1506; q=dns/txt; s=iport; t=1360187467; x=1361397067; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MDpa4DvtqRbpkZgQ6AC8T8oxEE8XxadBgVgyhf3TbvM=; b=jInREoYHHal8HIGeV5Iv+Z8iz42CQeb1/BCatWZueg8Zmwf7cwgS1k7e s2n3o4QG0Xz3DyILmgR276Xam7nPMwFofZ9LWgxMTszbNM4Xa9ejnAT/x 9oh3g8QMg32vVPyg3Stt71mk4FUGeACce77QlBWABpjUmsW9cs/8lpYu3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB7PElGQ/khL/2dsb2JhbABFwFAWc4IgAQEEOj8QCw44VwYuh3a8ZI0ug0phA5YhkFKCf4Fn X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208";a="11648346" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 06 Feb 2013 21:51:06 +0000 Received: from dhcp-10-61-107-57.cisco.com (dhcp-10-61-107-57.cisco.com [10.61.107.57]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r16Lp5jq020113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Feb 2013 21:51:05 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Ole Troan In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> Date: Wed, 6 Feb 2013 22:51:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1499) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "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, 06 Feb 2013 21:51:08 -0000 while we are on the topic, and you made me re-read the document. section 4: issues with terminology. call a device that walks the extension header = chain something else than a router. rfc2460 definition of a router; "extension headers are not examined or = processed by any node along a packet's delivery path". a switch in my book doesn't look at L3 headers. use "middlebox" or "filtering router"? section 3: is the main justification for this work to make NAT64s function better? = if so that might be a little short-sighted, by the time we've updated = IPv6 implementations... perhaps use a different example than NAT64? section 5: restricting the header chain seems like an incomplete solution. doesn't = a middlebox need to reassembly fragments anyway, to deal with mis-ordered fragments? at least at some point I thought BSD sent fragmented packets by sending = the last fragment first. with a more idealist hat on: that extension headers are hard to parse, some consider a feature of = IPv6. a feature that tries to protect the end to end Internet, i.e. that we = can deploy new transport protocols and extension headers without upgrading all intermediate boxes. changing the IPv6 = protocol for a flawed design (aka middleboxes), is that wise? might as well just deprecate IP fragmentation. (which I would be in = favour of). and don't get me wrong, I can't imagine any use case for an extension = header chain longer than 1280 bytes either. cheers, Ole From rbonica@juniper.net Wed Feb 6 15:41:24 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 111C021F85A0 for ; Wed, 6 Feb 2013 15:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8xXxC2Rm6YN for ; Wed, 6 Feb 2013 15:41:23 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2D821F856F for ; Wed, 6 Feb 2013 15:41:23 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKURLqIwhi7BAtS3c35LFixvFtJADrKdJW@postini.com; Wed, 06 Feb 2013 15:41:23 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Feb 2013 15:41:22 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 6 Feb 2013 15:41:21 -0800 Received: from CO9EHSOBE042.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 6 Feb 2013 15:50:11 -0800 Received: from mail102-co9-R.bigfish.com (10.236.132.233) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 23:41:21 +0000 Received: from mail102-co9 (localhost [127.0.0.1]) by mail102-co9-R.bigfish.com (Postfix) with ESMTP id B82F63401A3 for ; Wed, 6 Feb 2013 23:41:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz9371I146fI542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail102-co9 (localhost.localdomain [127.0.0.1]) by mail102-co9 (MessageSwitch) id 1360194079717637_4820; Wed, 6 Feb 2013 23:41:19 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.251]) by mail102-co9.bigfish.com (Postfix) with ESMTP id ACD643C005C; Wed, 6 Feb 2013 23:41:19 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Feb 2013 23:41:18 +0000 Received: from BL2PRD0512MB646.namprd05.prod.outlook.com ([169.254.9.155]) by BL2PRD0512HT001.namprd05.prod.outlook.com ([10.255.233.34]) with mapi id 14.16.0263.000; Wed, 6 Feb 2013 23:41:08 +0000 From: Ronald Bonica To: Ole Troan Subject: RE: Moving forward draft-ietf-6man-oversized-header chain? Thread-Topic: Moving forward draft-ietf-6man-oversized-header chain? Thread-Index: AQHOAw28zEIc3pLjHkiS7gIVdRH7CphtSPowgAAZCoCAABuuAA== Date: Wed, 6 Feb 2013 23:41:07 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> In-Reply-To: <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%SI6NETWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "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, 06 Feb 2013 23:41:24 -0000 Ole, I am supporting this draft because the community has become accustomed to s= tateless firewalls on routers. These stateless firewalls are capable of fil= tering based upon information gleaned from both the IPv6 and L4 header. When a stateless firewall encounters an IPv6 datagram in which the IPv6 hea= der and L4 header don't appear in the first fragment, it can't make an info= rmed filtering decision on any fragment. However, if there is a guarantee t= hat the IPv6 header and the L4 header are in the first fragment, it can at = least make an informed decision regarding that fragment.=20 Would the draft be more acceptable if we stated this as the motivation and = removed references to NAT64? Ron > -----Original Message----- > From: Ole Troan [mailto:ot@cisco.com] > Sent: Wednesday, February 06, 2013 4:51 PM > To: Ronald Bonica > Cc: Fernando Gont; 6man-chairs@tools.ietf.org; ipv6@ietf.org > Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? >=20 > while we are on the topic, and you made me re-read the document. >=20 > section 4: > issues with terminology. call a device that walks the extension header > chain something else than a router. > rfc2460 definition of a router; "extension headers are not examined or > processed by any node along a packet's delivery path". > a switch in my book doesn't look at L3 headers. > use "middlebox" or "filtering router"? >=20 > section 3: > is the main justification for this work to make NAT64s function better? > if so that might be a little short-sighted, by the time we've updated > IPv6 implementations... perhaps use a different example than NAT64? >=20 > section 5: > restricting the header chain seems like an incomplete solution. doesn't > a middlebox need to reassembly fragments anyway, to deal with mis- > ordered fragments? > at least at some point I thought BSD sent fragmented packets by sending > the last fragment first. >=20 > with a more idealist hat on: > that extension headers are hard to parse, some consider a feature of > IPv6. > a feature that tries to protect the end to end Internet, i.e. that we > can deploy new transport protocols and extension headers without > upgrading all intermediate boxes. changing the IPv6 protocol for a > flawed design (aka middleboxes), is that wise? > might as well just deprecate IP fragmentation. (which I would be in > favour of). >=20 > and don't get me wrong, I can't imagine any use case for an extension > header chain longer than 1280 bytes either. >=20 > cheers, > Ole >=20 >=20 >=20 From joelja@bogus.com Wed Feb 6 16:01: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 2FAE621F8484 for ; Wed, 6 Feb 2013 16:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHDEjLHZA09t for ; Wed, 6 Feb 2013 16:01:55 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 82BE521F8449 for ; Wed, 6 Feb 2013 16:01:55 -0800 (PST) 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 r1701rCw098022 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 7 Feb 2013 00:01:53 GMT (envelope-from joelja@bogus.com) Message-ID: <5112EEEC.8030205@bogus.com> Date: Wed, 06 Feb 2013 16:01:48 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Ronald Bonica , Ole Troan Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.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]); Thu, 07 Feb 2013 00:01:54 +0000 (UTC) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "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, 07 Feb 2013 00:01:56 -0000 On 2/6/13 3:41 PM, Ronald Bonica wrote: > Ole, > > I am supporting this draft because the community has become accustomed to stateless firewalls on routers. These stateless firewalls are capable of filtering based upon information gleaned from both the IPv6 and L4 header. > > When a stateless firewall encounters an IPv6 datagram in which the IPv6 header and L4 header don't appear in the first fragment, it can't make an informed filtering decision on any fragment. However, if there is a guarantee that the IPv6 header and the L4 header are in the first fragment, it can at least make an informed decision regarding that fragment. my own .02 Stateless observation of upper layer headers of any variety have this issue whether applied in a router or on and end system. if I wish to apply a particular priority to a packet forwarding on the basis of an L4 identifier I have to find it first. If I want my sflow/netflow export to expose the contents of the upper layer header I need to find them. If I want to protect the control plane, first I need to find the upper layer header. If I need to mitigate a DOS attack sourced on UDP 53 I need to find the upper layer header etc. I don't really belive that wanting usable data out of flow sampling (which necessarily due to the nature of sampling cannot do reassembly), or the ability to assign queues to traffic on the basis of something other than source/dest address and an empty flow label result in what would be characterized as flawed middlebox design. Nor whould I characterize the devices that do this as firewalls, elsewise every high-scale router on the internet is a firewall. > > Would the draft be more acceptable if we stated this as the motivation and removed references to NAT64? > > Ron > > >> -----Original Message----- >> From: Ole Troan [mailto:ot@cisco.com] >> Sent: Wednesday, February 06, 2013 4:51 PM >> To: Ronald Bonica >> Cc: Fernando Gont; 6man-chairs@tools.ietf.org; ipv6@ietf.org >> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? >> >> while we are on the topic, and you made me re-read the document. >> >> section 4: >> issues with terminology. call a device that walks the extension header >> chain something else than a router. >> rfc2460 definition of a router; "extension headers are not examined or >> processed by any node along a packet's delivery path". >> a switch in my book doesn't look at L3 headers. >> use "middlebox" or "filtering router"? >> >> section 3: >> is the main justification for this work to make NAT64s function better? >> if so that might be a little short-sighted, by the time we've updated >> IPv6 implementations... perhaps use a different example than NAT64? >> >> section 5: >> restricting the header chain seems like an incomplete solution. doesn't >> a middlebox need to reassembly fragments anyway, to deal with mis- >> ordered fragments? >> at least at some point I thought BSD sent fragmented packets by sending >> the last fragment first. >> >> with a more idealist hat on: >> that extension headers are hard to parse, some consider a feature of >> IPv6. >> a feature that tries to protect the end to end Internet, i.e. that we >> can deploy new transport protocols and extension headers without >> upgrading all intermediate boxes. changing the IPv6 protocol for a >> flawed design (aka middleboxes), is that wise? >> might as well just deprecate IP fragmentation. (which I would be in >> favour of). >> >> and don't get me wrong, I can't imagine any use case for an extension >> header chain longer than 1280 bytes either. >> >> cheers, >> Ole >> >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fgont@si6networks.com Wed Feb 6 16:48: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 27A9121F8546 for ; Wed, 6 Feb 2013 16:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sodrc8WTfPfU for ; Wed, 6 Feb 2013 16:48:13 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2730421F8539 for ; Wed, 6 Feb 2013 16:48:12 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3FeI-0005Xs-Dp; Thu, 07 Feb 2013 01:47:42 +0100 Message-ID: <5112F99B.7090604@si6networks.com> Date: Wed, 06 Feb 2013 21:47:23 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> In-Reply-To: <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.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>, "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, 07 Feb 2013 00:48:14 -0000 On 02/06/2013 06:51 PM, Ole Troan wrote: > while we are on the topic, and you made me re-read the document. > > section 4: issues with terminology. call a device that walks the > extension header chain something else than a router. rfc2460 > definition of a router; "extension headers are not examined or > processed by any node along a packet's delivery path". a switch in my > book doesn't look at L3 headers. use "middlebox" or "filtering > router"? Will do. > section 3: is the main justification for this work to make NAT64s > function better? if so that might be a little short-sighted, by the > time we've updated IPv6 implementations... perhaps use a different > example than NAT64? I could mention something along the lines of "any middlebox that must/wants_to perform stateless processing of packets" > section 5: restricting the header chain seems like an incomplete > solution. doesn't a middlebox need to reassembly fragments anyway, to > deal with mis-ordered fragments? No. Such devices typically pass non-first fragments, and enforce their policy based on the information contained in the first fragment. > with a more idealist hat on: that extension headers are hard to > parse, some consider a feature of IPv6. Others consider "deployability" a more interesting feature -- are we really having this discussion? > a feature that tries to > protect the end to end Internet, That doesn't protect the end-to-end-ness of the Internet, but rather just prevents IPv6 from being deployed -- such "feature" ("overlooked conercase", I'd rather say) will only prevent traffic (that would have otherwise been allowed) from flowing in the network. > i.e. that we can deploy new > transport protocols and extension headers without upgrading all > intermediate boxes. changing the IPv6 protocol for a flawed design > (aka middleboxes), is that wise? That's your take. My take is that packets that have more headers than payload don't make any sense. We put headers to move payloads -- not the other way around. > might as well just deprecate IP > fragmentation. (which I would be in favour of). IMHO, (and all the above said), this document was adopted almost a year ago. If we're going to stop moving documents forward to re-hash one-year-old discussions (as we already did with draft-ietf-6man-stable-privacy-addresses), it becomes very hard to make any sort of progress. 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.e.carpenter@gmail.com Thu Feb 7 00:05: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 2D7CB21F88EA for ; Thu, 7 Feb 2013 00:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hieYjg8zn5aL for ; Thu, 7 Feb 2013 00:04:59 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5596221F84E3 for ; Thu, 7 Feb 2013 00:04:57 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so1731982wgb.33 for ; Thu, 07 Feb 2013 00:04:56 -0800 (PST) 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=ueZ89YGn5fqA/i/RT4O4D9LR+VLyylfZHkJxsC7fBEk=; b=USMF5hak2WfsfLbsGZXegsAAXfdrpvlWHqXecZ8Shkz1WK1g6DWzbMa9x9OzH3ZNHN jSJS0fYf01UysPhu7jVkmJ1QXR7r0vSqYENsFD+i7ezhdzVxv3dHKeEakDCzADSxnoJ1 6iW/NhUkvm25wqVvgXIh8/lgZ5RQvlVC46CIp9Jp5IGc5bLa3rtw6Gu0M32JRrLGyCIL ACY3PfHCj2Z80Ho6FIybXRS5DPgswMQ40OgTuim/wDi9wJyhI7Je07TM6wbe52B/WJyh ew+s2nUedBCOyNRZgbkZjXsjL532yylDPRqTSPNS4DF7itnBRGWrnHnyQzxFYv4yOGZ8 nCpg== X-Received: by 10.194.156.196 with SMTP id wg4mr658916wjb.22.1360224296143; Thu, 07 Feb 2013 00:04:56 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-157.as13285.net. [2.102.217.157]) by mx.google.com with ESMTPS id l3sm7693451wiy.8.2013.02.07.00.04.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 00:04:55 -0800 (PST) Message-ID: <5113602B.5090709@gmail.com> Date: Thu, 07 Feb 2013 08:04:59 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <5112F99B.7090604@si6networks.com> In-Reply-To: <5112F99B.7090604@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Ole Troan , "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, 07 Feb 2013 08:05:00 -0000 On 07/02/2013 00:47, Fernando Gont wrote: > On 02/06/2013 06:51 PM, Ole Troan wrote: >> while we are on the topic, and you made me re-read the document. >> >> section 4: issues with terminology. call a device that walks the >> extension header chain something else than a router. rfc2460 >> definition of a router; "extension headers are not examined or >> processed by any node along a packet's delivery path". a switch in my >> book doesn't look at L3 headers. use "middlebox" or "filtering >> router"? > > Will do. > > > >> section 3: is the main justification for this work to make NAT64s >> function better? if so that might be a little short-sighted, by the >> time we've updated IPv6 implementations... perhaps use a different >> example than NAT64? > > I could mention something along the lines of "any middlebox that > must/wants_to perform stateless processing of packets" Yes, it's certainly an issue for load balancers, for example. It certainly isn't "routers" in the classical sense. At the chairs' request, I cross-checked the interaction of this draft with draft-carpenter-6man-ext-transmit some time back, and concluded that there's no conflict. Banning fragmented header chains makes header processing easier, so it's a good thing, IMHO. >> section 5: restricting the header chain seems like an incomplete >> solution. doesn't a middlebox need to reassembly fragments anyway, to >> deal with mis-ordered fragments? > > No. Such devices typically pass non-first fragments, and enforce their > policy based on the information contained in the first fragment. > > >> with a more idealist hat on: that extension headers are hard to >> parse, some consider a feature of IPv6. > > Others consider "deployability" a more interesting feature -- are we > really having this discussion? > > >> a feature that tries to >> protect the end to end Internet, > > That doesn't protect the end-to-end-ness of the Internet, but rather > just prevents IPv6 from being deployed -- such "feature" ("overlooked > conercase", I'd rather say) will only prevent traffic (that would have > otherwise been allowed) from flowing in the network. > > >> i.e. that we can deploy new >> transport protocols and extension headers without upgrading all >> intermediate boxes. changing the IPv6 protocol for a flawed design >> (aka middleboxes), is that wise? IMHO yes - this was an oversight in the design. I would like to fix middleboxes too, hence draft-carpenter-6man-ext-transmit, but it is not easily enforceable. > That's your take. My take is that packets that have more headers than > payload don't make any sense. We put headers to move payloads -- not the > other way around. > > >> might as well just deprecate IP >> fragmentation. (which I would be in favour of). That's an even bigger piece to bite off. For now, just set your MTU to 1280 ;-) Brian > > IMHO, (and all the above said), this document was adopted almost a year > ago. If we're going to stop moving documents forward to re-hash > one-year-old discussions (as we already did with > draft-ietf-6man-stable-privacy-addresses), it becomes very hard to make > any sort of progress. > > Thanks! > > Best regards, From despres.remi@laposte.net Thu Feb 7 00:32: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 D840C21F8561 for ; Thu, 7 Feb 2013 00:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUZjGJQ6WKkg for ; Thu, 7 Feb 2013 00:32:31 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E10921F8554 for ; Thu, 7 Feb 2013 00:32:30 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 6568A700007B; Thu, 7 Feb 2013 09:32:29 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 262A0700006B; Thu, 7 Feb 2013 09:32:28 +0100 (CET) X-SFR-UUID: 20130207083229156.262A0700006B@msfrf2102.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5112C72F.6040900@kit.edu> Date: Thu, 7 Feb 2013 09:32:29 +0100 Message-Id: <3A4980F8-FEEC-4781-9CB1-D3D1AF227909@laposte.net> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511287C5.20203@kit.edu> <5112C72F.6040900@kit.edu> To: Roland Bless X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 07 Feb 2013 08:32:32 -0000 Le 2013-02-06 =E0 22:12, Roland Bless a =E9crit : ... >=20 >> Nothing new needs to be done in any implementation other than that of = a 4rd-supporting devices (4rd CEs and BRs).=20 >>=20 >>> In case that they are >>> not using 4rd, MUST they exclude this IID range? >>=20 >> Because of RFC 4291 is as it is, softwares that assign IIDs NEVER do = it with u=3Dg=3D1 =3D> they don't need any update to exclude the 4rd = range. >> (That's precisely why the 4rd range has been chosen with u=3Dg=3D1). >=20 > Then I don't see a compelling reason to reserve an IID range for 4rd, > since it should work without the reservation just fine. - As already pointed out, in particular to Ran Atkinson: "Making the reservation for one design, experimental or not, is a = guarantee that no future design with conflict with it, experimental or = not. A central registry is the appropriate tool for this." - 4rd needs only 1/16384 of the currently unused range, which is worth = registering. Regards, RD >=20 > Regards, > Roland >=20 From kauer@biplane.com.au Thu Feb 7 00:37: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 DF0F621F84D5 for ; Thu, 7 Feb 2013 00:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prBE2eI3OD26 for ; Thu, 7 Feb 2013 00:37:41 -0800 (PST) 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 2FF6021F84C0 for ; Thu, 7 Feb 2013 00:37:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAGRnE1GWZX+7/2dsb2JhbAANOMBogxIBAQEEgQkLGC5XGbIqkziOMIMpA4gwmTOIIg 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; 07 Feb 2013 19:07:39 +1030 Message-ID: <1360226247.5572.43.camel@karl> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Karl Auer To: ipv6@ietf.org Date: Thu, 07 Feb 2013 19:37:27 +1100 In-Reply-To: <5113602B.5090709@gmail.com> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <5112F99B.7090604@si6networks.com> <5113602B.5090709@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-nXT8+IIQov5C76+/PB2I" X-Mailer: Evolution 3.2.3-0ubuntu6 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: Thu, 07 Feb 2013 08:37:42 -0000 --=-nXT8+IIQov5C76+/PB2I Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Thu, 2013-02-07 at 08:04 +0000, Brian E Carpenter wrote: > > That's your take. My take is that packets that have more headers than > > payload don't make any sense. We put headers to move payloads -- not th= e > > other way around. Coming in very late and this has probably already been thought of, but the ESP header *is* effectively a payload, and may need to be fragmented. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 --=-nXT8+IIQov5C76+/PB2I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EABEIAAYFAlETZ8cACgkQYjkSCJhlX5r1BgD/Vh9Guc8oTDYVt2nWQAFJYC6d NS2keb8GDOvISEGQFNIA/jTfncY7/EBn9Ec/ZMCdXgg8UMH/rOp2WKbLSwQs2St1 =TNMZ -----END PGP SIGNATURE----- --=-nXT8+IIQov5C76+/PB2I-- From joelja@bogus.com Thu Feb 7 01:14: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 0930F21F85A4 for ; Thu, 7 Feb 2013 01:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFBuUrgie5yE for ; Thu, 7 Feb 2013 01:14:44 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 266D121F8599 for ; Thu, 7 Feb 2013 01:14:44 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r179EXut004144 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 7 Feb 2013 09:14:34 GMT (envelope-from joelja@bogus.com) Message-ID: <51137074.2030707@bogus.com> Date: Thu, 07 Feb 2013 01:14:28 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Karl Auer , ipv6@ietf.org Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <5112F99B.7090604@si6networks.com> <5113602B.5090709@gmail.com> <1360226247.5572.43.camel@karl> In-Reply-To: <1360226247.5572.43.camel@karl> 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]); Thu, 07 Feb 2013 09:14:34 +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, 07 Feb 2013 09:14:45 -0000 On 2/7/13 12:37 AM, Karl Auer wrote: > On Thu, 2013-02-07 at 08:04 +0000, Brian E Carpenter wrote: >>> That's your take. My take is that packets that have more headers than >>> payload don't make any sense. We put headers to move payloads -- not the >>> other way around. > Coming in very late and this has probably already been thought of, but > the ESP header *is* effectively a payload, and may need to be > fragmented. everything after the esp header is payload for everyone other than the intended recipient, who has more headers to unwrap once the payload has been decrypted. > > Regards, K. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From otroan@employees.org Thu Feb 7 02:18: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 B85A721F8654 for ; Thu, 7 Feb 2013 02:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuHUb7r1rCDp for ; Thu, 7 Feb 2013 02:18:39 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E021F8653 for ; Thu, 7 Feb 2013 02:18:39 -0800 (PST) Received: from dhcp-10-61-108-93.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 793A35E62; Thu, 7 Feb 2013 02:18:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Ole Troan In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> Date: Thu, 7 Feb 2013 11:18:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C27CF37-C351-43E9-B8A8-32DB0D191196@employees.org> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1499) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "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, 07 Feb 2013 10:18:39 -0000 Ron, > I am supporting this draft because the community has become accustomed = to stateless firewalls on routers. These stateless firewalls are capable = of filtering based upon information gleaned from both the IPv6 and L4 = header. don't get me wrong, I'm also in support of this work. ;-) but if we go down this slippery slope. where do we draw the line? I do = know of filtering routers that look at the L7 headers. and I'm sure there are those that inspect the payload as well. do we arbitrary choose to stop at the L4 header? as Karl pointed out, what do we do with the ESP header? do you define = which part of the ESP header that must be included in the first = fragment? or does this mean that a packet with ESP MUST NOT be = fragmented? are there other headers where what consist of the "entire ipv6 header = chain" is unclear? > When a stateless firewall encounters an IPv6 datagram in which the = IPv6 header and L4 header don't appear in the first fragment, it can't = make an informed filtering decision on any fragment. However, if there = is a guarantee that the IPv6 header and the L4 header are in the first = fragment, it can at least make an informed decision regarding that = fragment.=20 >=20 > Would the draft be more acceptable if we stated this as the motivation = and removed references to NAT64? yes, I think that would help. Best regards, Ole >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: Ole Troan [mailto:ot@cisco.com] >> Sent: Wednesday, February 06, 2013 4:51 PM >> To: Ronald Bonica >> Cc: Fernando Gont; 6man-chairs@tools.ietf.org; ipv6@ietf.org >> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? >>=20 >> while we are on the topic, and you made me re-read the document. >>=20 >> section 4: >> issues with terminology. call a device that walks the extension = header >> chain something else than a router. >> rfc2460 definition of a router; "extension headers are not examined = or >> processed by any node along a packet's delivery path". >> a switch in my book doesn't look at L3 headers. >> use "middlebox" or "filtering router"? >>=20 >> section 3: >> is the main justification for this work to make NAT64s function = better? >> if so that might be a little short-sighted, by the time we've updated >> IPv6 implementations... perhaps use a different example than NAT64? >>=20 >> section 5: >> restricting the header chain seems like an incomplete solution. = doesn't >> a middlebox need to reassembly fragments anyway, to deal with mis- >> ordered fragments? >> at least at some point I thought BSD sent fragmented packets by = sending >> the last fragment first. >>=20 >> with a more idealist hat on: >> that extension headers are hard to parse, some consider a feature of >> IPv6. >> a feature that tries to protect the end to end Internet, i.e. that we >> can deploy new transport protocols and extension headers without >> upgrading all intermediate boxes. changing the IPv6 protocol for a >> flawed design (aka middleboxes), is that wise? >> might as well just deprecate IP fragmentation. (which I would be in >> favour of). >>=20 >> and don't get me wrong, I can't imagine any use case for an extension >> header chain longer than 1280 bytes either. >>=20 >> cheers, >> Ole >>=20 >>=20 >>=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kauer@biplane.com.au Thu Feb 7 02:34: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 D3E3121F85D2 for ; Thu, 7 Feb 2013 02:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-GDHcPiTZGB for ; Thu, 7 Feb 2013 02:34:50 -0800 (PST) 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 EE5D521F85D0 for ; Thu, 7 Feb 2013 02:34:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkDABCDE1GWZX+7/2dsb2JhbAANOL9PAoEYgxIBAQEEgQkLGC5XGbI9kz2OHRODKQOIMJkziCI 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; 07 Feb 2013 21:04:26 +1030 Message-ID: <1360233264.5572.46.camel@karl> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Karl Auer To: ipv6@ietf.org Date: Thu, 07 Feb 2013 21:34:24 +1100 In-Reply-To: <51137074.2030707@bogus.com> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <5112F99B.7090604@si6networks.com> <5113602B.5090709@gmail.com> <1360226247.5572.43.camel@karl> <51137074.2030707@bogus.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: Thu, 07 Feb 2013 10:34:50 -0000 On Thu, 2013-02-07 at 01:14 -0800, joel jaeggli wrote: > On 2/7/13 12:37 AM, Karl Auer wrote: > > On Thu, 2013-02-07 at 08:04 +0000, Brian E Carpenter wrote: > >>> That's your take. My take is that packets that have more headers than > >>> payload don't make any sense. We put headers to move payloads -- not the > >>> other way around. > > Coming in very late and this has probably already been thought of, but > > the ESP header *is* effectively a payload, and may need to be > > fragmented. > everything after the esp header is payload for everyone other than the > intended recipient, who has more headers to unwrap once the payload has > been decrypted. Er - yes. I just meant that you can't take the hard line that "headers shall not be fragmented" (not that Brian was saying that) when at least one header may have to be. There will only be more headers to unwrap in tunnel mode. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog 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 alexandru.petrescu@gmail.com Thu Feb 7 02:44: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 3249721F8606 for ; Thu, 7 Feb 2013 02:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+UT6UHiC6gh for ; Thu, 7 Feb 2013 02:44:29 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id AF88121F856E for ; Thu, 7 Feb 2013 02:44:28 -0800 (PST) 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 r17AiRbm014866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Feb 2013 11:44:27 +0100 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 r17AiRs2013703 for ; Thu, 7 Feb 2013 11:44:27 +0100 (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 r17AiMvG003621 for ; Thu, 7 Feb 2013 11:44:27 +0100 Message-ID: <51138586.1050008@gmail.com> Date: Thu, 07 Feb 2013 11:44:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: RFC4291 - ff01::/16 References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> <5112C307.7070308@kit.edu> In-Reply-To: <5112C307.7070308@kit.edu> 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, 07 Feb 2013 10:44:30 -0000 Le 06/02/2013 21:54, Roland Bless a écrit : > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Hi Michael, > > On 06.02.2013 19:23, Michael Richardson wrote: >>>>>>> "TM" == TM writes: >>>> RFC4291 is clear that packets destined to ff01::/16 must never >>>> leave the local node, but what should be done if such packets >>>> are received as a result from a broken implementation on the >>>> other side? >> >> TM> "Be liberal in what you accept, and conservative in what you >> TM> send", Since the sending node obviously violated the 2nd part >> of TM> Jon Postel's robustness principle, it should be ignored and >> TM> dropped by the receiving system. Moreover, report the failure >> >> The key is that the packets should be dropped without generating >> any errors or traffic. > > Yep, you are right - I assumed that implicitly, but I should have > mentioned that explicitly :-) Also, the implementation of that dropping may not be that straightforward as at a quick first sight. A stack presented with a packet whose dst's leftmost 16bits precisely match ff01::/16 should be dropped _only_ if the src of that packet is an address which does not belong to that stack (in other words don't discard packets originated by stack and addressed to self). ('be liberal in what you accept'). A question could be raised about what should do a stack when presented with a packet whose src==:: (unspecified address) and dst==ff01::/16 Should it drop it? Log an error? Accept it? Alex > > Regards, Roland > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlESwwEACgkQ1YyfLd659kdpaACfai8zkguwd5YYIlD47K5j7CqJ > Hl8An14AMH5Z4sWfjRNimZeEMYOaZXnn =fCgK -----END PGP SIGNATURE----- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From ot@cisco.com Thu Feb 7 04:29: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 ECF7621F8439 for ; Thu, 7 Feb 2013 04:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8Id1MGa43mN for ; Thu, 7 Feb 2013 04:29:17 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4421F8415 for ; Thu, 7 Feb 2013 04:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=712; q=dns/txt; s=iport; t=1360240157; x=1361449757; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FRPofiapxhLrk2mH4kLQp0qSxxhy5l/jU4Svytj3j2A=; b=EOFp7C25q+pig7Hx/fQRuVqhrhnM2Kbypfnbc40+9KDrCylGPRVQZAkp gWANj09a356XxM1QsaRw+sdomFllCUYklff7zUBiUGnOJjy27AimNwYTg ejR6X/DWLojAbdAfIZAUTKkpEqmnBe8p2BBvJ+3Eq7rxKgEGSArXNDaen w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAJAOSdE1GQ/khN/2dsb2JhbABFv0kEBIEDFnOCHwEBAQMBeQULCw44VwaIHga+CJB4YQOWIZBSgn8 X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="11651040" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 07 Feb 2013 12:28:58 +0000 Received: from dhcp-lys02-vla252-10-147-116-49.cisco.com (dhcp-lys02-vla252-10-147-116-49.cisco.com [10.147.116.49]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r17CSv3Q028961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 12:28:58 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-03.txt From: Ole Troan In-Reply-To: <51087C12.7010907@si6networks.com> Date: Thu, 7 Feb 2013 13:28:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130130014200.25208.35907.idtracker@ietfa.amsl.com> <51087C12.7010907@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.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: Thu, 07 Feb 2013 12:29:18 -0000 Fernando, > It's been a month since I received your last message regarding this = I-D. >=20 > Can we ship this document now? >=20 > P.S.: This latest version addresses the feedback received from Tassos > (I've double-checked with him that his comments have been addressed). it would be good if you could summarise the changes from the last call. I read through the document again, and my only remaining concern is that = the document doesn't specify the=20 hash function to be used. is there usefulness in having stable interface-ids that are generated = the same across implementations? and are predictable given knowledge of the "secret key". I would think = so. Best regards, Ole= From erik.hugne@ericsson.com Thu Feb 7 04:52: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 A1AC521F8446 for ; Thu, 7 Feb 2013 04:52:25 -0800 (PST) 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_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h3gLDNLZ1ZU for ; Thu, 7 Feb 2013 04:52:25 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B6DFA21F8413 for ; Thu, 7 Feb 2013 04:52:24 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-70-5113a387d5a3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 51.66.32353.783A3115; Thu, 7 Feb 2013 13:52:23 +0100 (CET) Received: from eerihug-hybrid.ki.sw.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 7 Feb 2013 13:52:22 +0100 Date: Thu, 7 Feb 2013 13:49:27 +0100 From: Erik Hugne To: Alexandru Petrescu Subject: Re: RFC4291 - ff01::/16 Message-ID: <20130207124927.GE27969@eerihug-hybrid.ki.sw.ericsson.se> References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> <5112C307.7070308@kit.edu> <51138586.1050008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <51138586.1050008@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rrd9sXCgwYNeVYuZ736wWrw8+57J gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MrYubuTseA6a0Vr3zrmBsYzLF2MnBwSAiYS j67A2GISF+6tZ+ti5OIQEjjJKLHnfSOUs5tR4uO7W0wgVSwCKhKv73wH62AT0JKY+HwiWFxE wFRiz9bHbCA2s4CgxLPDP1hBbGEBBYmFh7eyg9i8Aq4SK9dsgxq6n1FizskPLBAJQYmTM5+w QDTrSCzY/QmoiAPIlpZY/o8DJMwpoCmxu3cXI4gtCnTDlJPbwHYJAdn3X85mn8AoOAvJpFlI Js1CmLSAkXkVI3tuYmZOern5JkZgSB7c8ttgB+Om+2KHGKU5WJTEecNdLwQICaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYGRTkRVP21Pi3LnRxp2rr7Rt1ZPqXr0ACamw4AVf7LIcfNf+2Te/ 8qua7cxpEapr6mWk8pMbuFSD1wqk6FZ9flLbIMbz5L6+xnu+ZY/POKXsvvZ61eI7hsqvCv1z HZjOBHd+uxWWtOQ3y+Z9cVFGhobS86cu9Gx9EZPAv/7lWU6hK9Z9Pls0lViKMxINtZiLihMB JhDjjBcCAAA= 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, 07 Feb 2013 12:52:25 -0000 On Thu, Feb 07, 2013 at 11:44:22AM +0100, Alexandru Petrescu wrote: > Also, the implementation of that dropping may not be that > straightforward as at a quick first sight. > > A stack presented with a packet whose dst's leftmost 16bits precisely > match ff01::/16 should be dropped _only_ if the src of that packet is an > address which does not belong to that stack (in other words don't > discard packets originated by stack and addressed to self). ('be liberal > in what you accept'). > FreeBSD drops any packets sent to ff01::/16 if they did not originate from the local host. http://fxr.watson.org/fxr/source/netinet6/ip6_input.c#L555 Linux currently accept these, regardless of who sent them. //E From despres.remi@laposte.net Thu Feb 7 05:36: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 3E38621F85CE for ; Thu, 7 Feb 2013 05:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3D9ilMvZ3dg for ; Thu, 7 Feb 2013 05:36:51 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9319921F8455 for ; Thu, 7 Feb 2013 05:36:50 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id CA4F9700017B; Thu, 7 Feb 2013 14:36:49 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 8884E7000047; Thu, 7 Feb 2013 14:36:49 +0100 (CET) X-SFR-UUID: 20130207133649559.8884E7000047@msfrf2302.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> Date: Thu, 7 Feb 2013 14:36:50 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 07 Feb 2013 13:36:52 -0000 2013-02-06 17:28, Ole Troan : > Fernando, ... > with Remi's proposal, a duplicate address will not even be detected. Correct: even if software is available to detect collisions between 4rd = addresses and RFC 4291-compatible host addresses, it won't detect any. = (Such software, which isn't mandatory for 4rd, is of course not excluded = either.)=20 The simple reason for this non-detection is that these addresses have = IIDs in disjoint sets.=20 Regards, RD From ot@cisco.com Thu Feb 7 05:41: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 0DB6621F8606 for ; Thu, 7 Feb 2013 05:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.43 X-Spam-Level: X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8Zx1o2kqoAy for ; Thu, 7 Feb 2013 05:41:27 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2B21F85F0 for ; Thu, 7 Feb 2013 05:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=556; q=dns/txt; s=iport; t=1360244487; x=1361454087; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8BcDkx7/gFdSrOB6QRMokR1b/ErIVLUE9X5Eq15IJRc=; b=AF4p1FQsnWoNTzvGCqcYghtX0P0fUx2G20qeFZCM0OfHgpOsk8x7SrSp ztbksIZfP2a7DpVuhpK46jYpwU5r3U24dGcu0+4RDw1xd5Dpqih9yZ1n0 ng/MWP46ywF4LNrxuBi/q0OaNhuvFSWiTXitF+/43niWqng788e8r3d75 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMquE1GQ/khN/2dsb2JhbABFwGYWc4IgAQEEOj8QC0ZXBogkviCQe2EDliGQUoMB X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="11653069" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 07 Feb 2013 13:41:06 +0000 Received: from dhcp-lys02-vla252-10-147-116-49.cisco.com (dhcp-lys02-vla252-10-147-116-49.cisco.com [10.147.116.49]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r17Df6O0009877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 13:41:06 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: Ole Troan In-Reply-To: Date: Thu, 7 Feb 2013 14:41:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: Bob Hinden , 6man 6man-wg , Fernando Gont 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, 07 Feb 2013 13:41:28 -0000 Remi, > ... >> with Remi's proposal, a duplicate address will not even be detected. >=20 > Correct: even if software is available to detect collisions between = 4rd addresses and RFC 4291-compatible host addresses, it won't detect = any. (Such software, which isn't mandatory for 4rd, is of course not = excluded either.)=20 >=20 > The simple reason for this non-detection is that these addresses have = IIDs in disjoint sets.=20 I think you have received quite a lot of pushback against creating = disjoint sets of IIDs. cheers, Ole= From despres.remi@laposte.net Thu Feb 7 06:01: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 A4E3F21F8632 for ; Thu, 7 Feb 2013 06:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZiTM4w7Qx-u for ; Thu, 7 Feb 2013 06:01:42 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id CAD9B21F85F0 for ; Thu, 7 Feb 2013 06:01:41 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 8848F7000124; Thu, 7 Feb 2013 15:01:40 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id 6B9037000071; Thu, 7 Feb 2013 15:01:40 +0100 (CET) X-SFR-UUID: 20130207140140440.6B9037000071@msfrf2302.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> Date: Thu, 7 Feb 2013 15:01:41 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden , 6man 6man-wg , Fernando Gont 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, 07 Feb 2013 14:01:42 -0000 2013-02-07 14:41, Ole Troan : > Remi, >=20 >> ... >>> with Remi's proposal, a duplicate address will not even be detected. >>=20 >> Correct: even if software is available to detect collisions between = 4rd addresses and RFC 4291-compatible host addresses, it won't detect = any. (Such software, which isn't mandatory for 4rd, is of course not = excluded either.)=20 >>=20 >> The simple reason for this non-detection is that these addresses have = IIDs in disjoint sets.=20 >=20 > I think you have received quite a lot of pushback against creating = disjoint sets of IIDs. Different understanding.=20 - Those who have supported haven't needed to repeat their support (see = names in http://www.ietf.org/mail-archive/web/ipv6/current/msg17094, and = one more in http://www.ietf.org/mail-archive/web/ipv6/current/msg16972) - Those who have objected continue to receive answers to their concerns = (the above being one instance). Besides, these remaining concerns are aside from the question asked by = Softwire (whether reserving a subset of an IID range unused by RFC 4291 = is compatible with the IPv6 addressing architecture). Regards, RD From ot@cisco.com Thu Feb 7 06:04: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 BB09C21F8632 for ; Thu, 7 Feb 2013 06:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRq7zjo3xst0 for ; Thu, 7 Feb 2013 06:04:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A79D921F85F0 for ; Thu, 7 Feb 2013 06:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1310; q=dns/txt; s=iport; t=1360245884; x=1361455484; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sPoonzHZygQAwvN7CZVJe5wBS/5ZEmUBeavrBdrq1Uc=; b=SxUGnrCv5s6JE2UY648uJX3FFfBN7hqF9VldBsxeJo62BgBBaEn2VMCa YSdmmvEidkm1J03Fi70JsJEij/BCewAnNBm+lGCLmV8eq9icmUO9gRyBM G7dKrR5V9TJz7NTGi+j3LAeUVyHdfolca0lqnmTT2AlgTmsbMsJQvkdDW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKqzE1GQ/khM/2dsb2JhbABFwGYWc4IgAQEEOj8QCxI0SQ4GHIgIDL4wjSSDV2EDliGQUoMBgW4 X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="150249350" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 07 Feb 2013 14:04:43 +0000 Received: from dhcp-lys02-vla252-10-147-116-49.cisco.com (dhcp-lys02-vla252-10-147-116-49.cisco.com [10.147.116.49]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r17E4gvS017028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 14:04:43 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: Ole Troan In-Reply-To: Date: Thu, 7 Feb 2013 15:04:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FDC4715-C550-4A96-B546-26B2E09FBE27@cisco.com> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: 6man 6man-wg , Bob Hinden , Fernando Gont 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, 07 Feb 2013 14:04:46 -0000 Remi, >>>> with Remi's proposal, a duplicate address will not even be = detected. >>>=20 >>> Correct: even if software is available to detect collisions between = 4rd addresses and RFC 4291-compatible host addresses, it won't detect = any. (Such software, which isn't mandatory for 4rd, is of course not = excluded either.)=20 >>>=20 >>> The simple reason for this non-detection is that these addresses = have IIDs in disjoint sets.=20 >>=20 >> I think you have received quite a lot of pushback against creating = disjoint sets of IIDs. >=20 > Different understanding.=20 > - Those who have supported haven't needed to repeat their support (see = names in http://www.ietf.org/mail-archive/web/ipv6/current/msg17094, and = one more in http://www.ietf.org/mail-archive/web/ipv6/current/msg16972) > - Those who have objected continue to receive answers to their = concerns (the above being one instance). >=20 > Besides, these remaining concerns are aside from the question asked by = Softwire (whether reserving a subset of an IID range unused by RFC 4291 = is compatible with the IPv6 addressing architecture). I think our understanding of the IPv6 addressing architecture is = incompatible. there are no unused subset or unused ranges of interface-ids in IPv6. cheers, Ole= From despres.remi@laposte.net Thu Feb 7 07:29: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 D6C0D21F86F2 for ; Thu, 7 Feb 2013 07:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELO5Om9oO38t for ; Thu, 7 Feb 2013 07:29:45 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 316D521F86EF for ; Thu, 7 Feb 2013 07:29:45 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id E9DF870001C9; Thu, 7 Feb 2013 16:29:43 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id A624D7000077; Thu, 7 Feb 2013 16:29:43 +0100 (CET) X-SFR-UUID: 20130207152943680.A624D7000077@msfrf2409.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <4FDC4715-C550-4A96-B546-26B2E09FBE27@cisco.com> Date: Thu, 7 Feb 2013 16:29:45 +0100 Message-Id: <0ACF6053-D614-4BDA-B346-FAC7792DBD8E@laposte.net> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> <4FDC4715-C550-4A96-B546-26B2E09FBE27@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg , Bob Hinden 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, 07 Feb 2013 15:29:45 -0000 2013-02-07 15:04, Ole Troan : > I think our understanding of the IPv6 addressing architecture is = incompatible. > there are no unused subset or unused ranges of interface-ids in IPv6. 1. If you interpret RFC 4291 as already permitting to set u=3D1 in some = IIDs other than derived from IEEE MAC addresses, yes, we differ. Note that, concerning the u/g bit significance, RFC 4291 is not the only = RFC that avoids u=3D1 in IIDs that aren't IEEE derived, and to avoid u=3D1= in IEEE derived addresses that are unicast: - RFC 3972 requires, in CGA IIDs, "setting bits 6 and 7 (i.e., the "u" = and "g" bits) to zero". - RFC 4941 requires, for privacy-extension IIDs, "set bit 6 (the = leftmost bit is numbered 0) to zero. This creates an interface = identifier with the universal/local bit indicating local significance = only."=20 =20 - RFC 6740 requires that "ILNP Identifiers have the same syntax as IPv6 = interface identifiers [RFC4291], based on the EUI-64 format = [IEEE-EUI]... If they have global scope, they SHOULD be globally = unique... For both ILNP node Identifiers and also IPv6 interface = identifiers, this Group bit is set to 0." 2. In http://www.ietf.org/mail-archive/web/ipv6/current/msg16982 you = mentioned a particular use you know of a local-scope IID having u=3Dg=3D1,= namely ffff:0:0:1. Reason why its u bit isn't 0 is so far unclear but, = assuming there is a reason, this IID can be reserved too in the = IID-range registry, or one of its prefixes.=20 As already noted, there isn't conflict between this IID and the 4rd = range. No need to change either one. =20 Conclusion: if you need some IIDs having u=3Dg=3D1 for some identified = use, let's document this use.=20 We will thus avoid an unnecessary controversy.=20 Regards, RD From v6ops@globis.net Thu Feb 7 07:39: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 644A621F8DCB for ; Thu, 7 Feb 2013 07:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7Myd77jkGGd for ; Thu, 7 Feb 2013 07:39:55 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6058C21F8D3F for ; Thu, 7 Feb 2013 07:39:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9911A8700E2; Thu, 7 Feb 2013 16:34:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 u2xLuc3-iO+V; Thu, 7 Feb 2013 16:34:09 +0100 (CET) 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 8BC828700AE; Thu, 7 Feb 2013 16:34:09 +0100 (CET) Message-ID: <5113C96B.5030103@globis.net> Date: Thu, 07 Feb 2013 16:34:03 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ole Troan Subject: Re: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> <4FDC4715-C550-4A96-B546-26B2E09FBE27@cisco.com> In-Reply-To: <4FDC4715-C550-4A96-B546-26B2E09FBE27@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , 6man 6man-wg , Fernando Gont 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, 07 Feb 2013 15:39:56 -0000 Ole Troan wrote: > Remi, > >>>>> with Remi's proposal, a duplicate address will not even be detected. >>>> Correct: even if software is available to detect collisions between 4rd addresses and RFC 4291-compatible host addresses, it won't detect any. (Such software, which isn't mandatory for 4rd, is of course not excluded either.) >>>> >>>> The simple reason for this non-detection is that these addresses have IIDs in disjoint sets. >>> I think you have received quite a lot of pushback against creating disjoint sets of IIDs. >> Different understanding. >> - Those who have supported haven't needed to repeat their support (see names in http://www.ietf.org/mail-archive/web/ipv6/current/msg17094, and one more in http://www.ietf.org/mail-archive/web/ipv6/current/msg16972) >> - Those who have objected continue to receive answers to their concerns (the above being one instance). >> >> Besides, these remaining concerns are aside from the question asked by Softwire (whether reserving a subset of an IID range unused by RFC 4291 is compatible with the IPv6 addressing architecture). > > I think our understanding of the IPv6 addressing architecture is incompatible. > there are no unused subset or unused ranges of interface-ids in IPv6. > > cheers, > Ole FWIW I agree with Ole. An IID currently only has relevance to the IPv6 addressing architecture specified in RFC4291 only when concatenated behind a /64 unicast address prefix, and only on an individual link. draft-ietf-softwire-4rd proposes breaking that tight coupling. I'm not per se against breaking the tight coupling, because RFC4291 states "The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope." But it is a change to current specification. But in addition IMVHO..... RFC 4291 states "Modified EUI-64 format-based interface identifiers may have universal scope when derived from a universal token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points) or where global tokens are undesirable (e.g., temporary tokens for privacy [PRIV])." The intention here to me is quite clear, even if it isn't written in normative language. u=1 should be used for generating an IID derived from universal tokens. The examples of universal tokens given in the document are those, which by the nature of their distributed administration, can be assumed to universally unique. Appendix E of draft-ietf-softwire-4rd demonstrates how to generate an IPv6 address for use with 4rd from an RFC 1918 address. I do not consider an IPv4 RFC1918 address to be a global/universal token. I don't see how generating an identifier that has to be unique way beyond an individual link [by definition in 4rd], from an identifier or token that clearly isn't globally unique [RFC1918], fits anywhere within the spirit of any text contained in RFC4291. To quote RFC1918 "As before, any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry." Use of magic beans to ensure global uniqueness would seem to be excluded. So as I have previously asserted, I think there certainly needs to be some clarification of any possible transportation of 4rd across an AS boundary, regardless of any other discussions. Transporting RFC1918 addresses across an AS boundary (in a 4rd tunnel), accidentally or otherwise, would to me be a clear violation of RFC1918, and the IPv4 [sic] addressing architecture. Nothing I've read in the meantime has changed this view. Which is one reason why I continue to assert that a global IID reservation is not necessary for experimental deployment of 4rd at this time: IMVVHO 4rd as specified today in draft-ietf-softwire-4rd can only safely be deployed within a single AS. Inter-AS 4rd would be potentially harmful. And for the record, Remi: The IETF is a meritocracy. I don't believe it's your role to call consensus in this WG, or otherwise define or limit what is, or is not, a valid discussion or stand point. It isn't mine either for that matter. If the chairs wish to make a statement, I'm sure they will do. Respectfully yours, RayH From dougb@dougbarton.us Thu Feb 7 08:55: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 13FEB21F86CD for ; Thu, 7 Feb 2013 08:55:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDI86tXFMWbo for ; Thu, 7 Feb 2013 08:55:41 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id A418221F84C6 for ; Thu, 7 Feb 2013 08:55:40 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:407b:2909:39f6:db4] (unknown [IPv6:2001:470:d:5e7:407b:2909:39f6:db4]) by dougbarton.us (Postfix) with ESMTPSA id 2F1F622BD4 for ; Thu, 7 Feb 2013 16:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1360256138; bh=My7mdOguotj2p37Cubn+pZnc/mXO4I/BJYRcAP27PaQ=; h=Date:From:To:Subject:References:In-Reply-To; b=ce72ieUVRwGfSwGCMeOCzCIWejdUvOHPrGBV10/qvGLPlc5WOPfkTWqIQ3RjpiIFj dOlre94KD7d5SFCefeynDHEoeoDWSyZ2nBWhtGXBjbV5FgHd9BgPcMd1p9aRAihDy3 7GvXNMXHUDo2hN++mrHhph8rtGxnsw4koakOoiPE= Message-ID: <5113DC89.4050008@dougbarton.us> Date: Thu, 07 Feb 2013 08:55:37 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 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, 07 Feb 2013 16:55:46 -0000 On 02/07/2013 06:01 AM, Rémi Després wrote: > Besides, these remaining concerns are aside from the question asked by Softwire Rémi, Do you admit to the possibility that the design coming from softwire might have flaws that should be addressed before it proceeds? I'm not saying necessarily that it does, although people here a lot smarter than me have raised concerns that I would like to see addressed in a manner other than, "I don't want to talk about that." Doug From dougb@dougbarton.us Thu Feb 7 09:02: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 002AC21F8473 for ; Thu, 7 Feb 2013 09:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soSUG+Zy3DB8 for ; Thu, 7 Feb 2013 09:02:51 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3801421F846C for ; Thu, 7 Feb 2013 09:02:51 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:407b:2909:39f6:db4] (unknown [IPv6:2001:470:d:5e7:407b:2909:39f6:db4]) by dougbarton.us (Postfix) with ESMTPSA id D564722BA8 for ; Thu, 7 Feb 2013 17:02:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1360256570; bh=tfJwvEwwaZgVZDq7rPxV7G5vKL1sQ98pI8N/TRB75Qw=; h=Date:From:To:Subject:References:In-Reply-To; b=kr2YA7n4NK8G7l9jQ6UB+fOltShvNu0jW/t+/i72U19Zf4AsVvdvsoKw5u4Zx9mu3 A1lhH4qKEeZ/Pn8LoUgK0ZxVMdn0b8RMLPwPDxXaKbqWMIwLs4uRx/1cFWV6TdT/HU NkYrl18Az+KBRE6plBsLkLJPhxlB5UzkI3fX3NBQ= Message-ID: <5113DE3A.6090605@dougbarton.us> Date: Thu, 07 Feb 2013 09:02:50 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: 6man 6man-wg Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> In-Reply-To: <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 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, 07 Feb 2013 17:02:52 -0000 Rémi, I think you've misunderstood me. Please see below. On 02/06/2013 02:01 AM, Rémi Després wrote: > > 2013-02-06 00:45, Doug Barton : > >> On 02/05/2013 05:57 AM, Rémi Després wrote: >>> Hi, Doug, >>> >>> Please see inline. >>> >>> >>> 2013-02-04 à 18:37, Doug Barton : >>> >>>> On 02/04/2013 12:38 AM, Rémi Després wrote: >>>>> It remains that IIDs having u=1 SHOULD be unique, i.e. with >>>>> rare enough exceptions. This is somewhat similar to the >>>>> expectation that ULA collisions shouldn't be seen). >>>>> >>>>> This theoretical unicity has been extensively used to assign >>>>> stable IIDs, without administrative action, to hosts that >>>>> have no privacy constraints requiring the opposite. >>>> >>>> What software exists that makes determinations based on the u >>>> bit? >>> >>> (*) Major OSes can assign IIDs derived from IEEE MAC addresses of >>> their LAN adapters (if not by default, at least as a >>> possibility). They do it because of what IEEE and IETF have >>> specified, each one for its own domain, concerning their >>> respective u bits. >> >> Yes, you've described reality. You haven't answered my questions. > > Fair enough. My answer is that no software that I know makes > determination based on the u bit. Thanks, that matches my (admittedly imperfect) understanding as well. > My point is that it isn't sufficient for the IETF u bit to have no > meaning. (a) It has what is specified in RFC 4291. (b) No software I > know creates IIDs having u = 1 without an IEEE-based OUI. So my new question is, why do you care? To amplify slightly, I am ambivalent about un-defining the u and g bits. Generally such a thing is difficult to do, since it's nearly impossible to get a complete survey of all software everywhere that may use those bits, and determine if it is safe to stop to just stop caring about them. OTOH, I am not a fan of magic bits in general, and I have never seen an adequate explanation of why an implementor should care about these 2. So I'm sympathetic to the argument about un-defining them, but you seem to be vehemently opposed to it, so I'm trying to understand your objection. "It's important because it's important!" doesn't help me. :) Doug From despres.remi@laposte.net Thu Feb 7 09:26: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 5D41521F8620 for ; Thu, 7 Feb 2013 09:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwFBIYt311WE for ; Thu, 7 Feb 2013 09:26:50 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFD521F846C for ; Thu, 7 Feb 2013 09:26:47 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id C7D637000445; Thu, 7 Feb 2013 18:26:46 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 552FF700042C; Thu, 7 Feb 2013 18:26:46 +0100 (CET) X-SFR-UUID: 20130207172646349.552FF700042C@msfrf2206.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5113C96B.5030103@globis.net> Date: Thu, 7 Feb 2013 18:26:44 +0100 Message-Id: References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> <4FDC4715-C550-4A96-B546-26B2E09FBE27@cisco.com> <5113C96B.5030103@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ole Troan , 6man 6man-wg , Fernando Gont , Bob Hinden 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, 07 Feb 2013 17:26:55 -0000 2013-02-07 16:34, Ray Hunter : > Ole Troan wrote: >> Remi, ... >>=20 >> I think our understanding of the IPv6 addressing architecture is = incompatible. >> there are no unused subset or unused ranges of interface-ids in IPv6. >>=20 >> cheers, >> Ole > FWIW I agree with Ole. >=20 > An IID currently only has relevance to the IPv6 addressing = architecture > specified in RFC4291 only when concatenated behind a /64 unicast = address > prefix, and only on an individual link. In RFC 4291; - 2.5 is Unicast addresses - 2.5.1 is Interface Identifiers. - It says: "For all unicast addresses, except those that start with the = binary value 000, Interface IDs are required to be 64 bits long" > draft-ietf-softwire-4rd proposes breaking that tight coupling. 4rd only depends on the RFC-4291 constraint that all native IPv6 = destinations that don't start with 000 and enter a 4rd-CE site comply = with the above. =20 >=20 > I'm not per se against breaking the tight coupling, because RFC4291 > states "The use of the universal/local bit in the Modified EUI-64 = format > identifier is to allow development of future technology that can take > advantage of interface identifiers with universal scope." But it is a > change to current specification. No change of the current specification is needed, because of the above. =20 > But in addition IMVHO..... >=20 > RFC 4291 states "Modified EUI-64 format-based interface identifiers = may > have universal > scope when derived from a universal token (e.g., IEEE 802 48-bit MAC > or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a > global token is not available (e.g., serial links, tunnel = end-points) > or where global tokens are undesirable (e.g., temporary tokens for > privacy [PRIV])." >=20 > The intention here to me is quite clear, even if it isn't written in > normative language. >=20 > u=3D1 should be used for generating an IID derived from universal = tokens. > The examples of universal tokens given in the document are those, = which > by the nature of their distributed administration, can be assumed to > universally unique. >=20 > Appendix E of draft-ietf-softwire-4rd demonstrates how to generate an > IPv6 address for use with 4rd from an RFC 1918 address. >=20 > I do not consider an IPv4 RFC1918 address to be a global/universal = token. >=20 > I don't see how generating an identifier that has to be unique way > beyond an individual link [by definition in 4rd], from an identifier = or > token that clearly isn't globally unique [RFC1918], fits anywhere = within > the spirit of any text contained in RFC4291. (a) As a matter of fact, a 4rd IID is UNIVERSALLY UNIQUE: it contains a = global IPv4 address (see the definition of a 4rd IPv4 address), followed = by a CNP which cannot have the same value for two CEs sharing the same = IPv4 address. (16-bit prefixes of two CE prefixes that differ only by n = consecutive bits, with 0 < n < 16, are necessarily different) In view of your misinterpretation here, it may be useful to add a = clarification on this in the 4rd draft itself. I can provide text if = needed. (b) Seeing your reference to RFC 1918, I looked at Appendix E, the only = place where it is referenced.=20 It contains an unfortunate typo. If it facilitated the misunderstanding, = sorry for that.=20 Where it says "the public IPv4 prefix to be used for shared addresses is = supposed to be 192.16.0.0/16 (0xc610)", it should have had = 198.16.0.0/16. (a usual example value for a global IPv4 prefix, and = equal to 0xC610).=20 In this Appendix E, 4rd is used *as usual* for GLOBAL IPv4 over IPv6. It = only happens that the (global) IPv6 is deployed using 6rd on an RFC1918 = ISP network.=20 > To quote RFC1918 "As before, any enterprise that needs globally unique > address space is required to obtain such addresses from an Internet > registry." Use of magic beans to ensure global uniqueness would seem = to > be excluded. 4rd doesn't work with RFC-1918 addresses. (And there isn't any magic bean anyway.) > So as I have previously asserted, I think there certainly needs to be > some clarification of any possible transportation of 4rd across an AS > boundary, regardless of any other discussions. >=20 > Transporting RFC1918 addresses across an AS boundary (in a 4rd = tunnel), > accidentally or otherwise, would to me be a clear violation of = RFC1918, > and the IPv4 [sic] addressing architecture. Nothing I've read in the > meantime has changed this view. >=20 > Which is one reason why I continue to assert that a global IID > reservation is not necessary for experimental deployment of 4rd at = this > time: IMVVHO 4rd as specified today in draft-ietf-softwire-4rd can = only > safely be deployed within a single AS. Inter-AS 4rd would be = potentially > harmful. No problem as 4rd IPv4 addresses are all global. > And for the record, Remi: The IETF is a meritocracy. I don't believe > it's your role to call consensus in this WG, or otherwise define or > limit what is, or is not, a valid discussion or stand point. It isn't > mine either for that matter. If the chairs wish to make a statement, = I'm > sure they will do. I have complete respect for the role of chairs, if for no other reason = because I do know how difficult it is. (I a-have been long ago in such a = position in another body.) I only feel being in my role when expressing my understanding of where = we are.=20 Thanks for the opportunity to correct the Appendix E typo. Regards, RD >=20 > Respectfully yours, > RayH From alexandru.petrescu@gmail.com Thu Feb 7 09:27: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 EC9AF21F8859 for ; Thu, 7 Feb 2013 09:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.21 X-Spam-Level: X-Spam-Status: No, score=-10.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VseJow6l8yDz for ; Thu, 7 Feb 2013 09:27:10 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9B62D21F867D for ; Thu, 7 Feb 2013 09:27:01 -0800 (PST) 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 r17HQxlf019380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2013 18:26:59 +0100 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 r17HQwGL006803; Thu, 7 Feb 2013 18:26:59 +0100 (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 r17HQrrY004619; Thu, 7 Feb 2013 18:26:58 +0100 Message-ID: <5113E3DD.8070804@gmail.com> Date: Thu, 07 Feb 2013 18:26:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Erik Hugne Subject: Re: RFC4291 - ff01::/16 References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> <5112C307.7070308@kit.edu> <51138586.1050008@gmail.com> <20130207124927.GE27969@eerihug-hybrid.ki.sw.ericsson.se> In-Reply-To: <20130207124927.GE27969@eerihug-hybrid.ki.sw.ericsson.se> 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: Thu, 07 Feb 2013 17:27:12 -0000 Le 07/02/2013 13:49, Erik Hugne a écrit : > On Thu, Feb 07, 2013 at 11:44:22AM +0100, Alexandru Petrescu wrote: >> Also, the implementation of that dropping may not be that >> straightforward as at a quick first sight. >> >> A stack presented with a packet whose dst's leftmost 16bits >> precisely match ff01::/16 should be dropped _only_ if the src of >> that packet is an address which does not belong to that stack (in >> other words don't discard packets originated by stack and addressed >> to self). ('be liberal in what you accept'). >> > > FreeBSD drops any packets sent to ff01::/16 if they did not originate > from the local host. > http://fxr.watson.org/fxr/source/netinet6/ip6_input.c#L555 > > Linux currently accept these, regardless of who sent them. That says to me that could be clarified, so that implementers make interoperable implementations. In one sense, one wouldn't want a Linux to behave unexpectedly when a FreeBSD sent it a packet whose IP dst is ff01::/64 with the right MAC dst address. In another sense, one wouldn't want a FreeBSD to drop packets sent by a Linux which thinks everyone acts like him/her. But this is speculative. HAve you seen it in practice? Which protocol makes common use of ff01::/64? Alex > > //E > > From fgont@si6networks.com Thu Feb 7 09:36: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 0242F21F857C for ; Thu, 7 Feb 2013 09:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRPXto2uk3fS for ; Thu, 7 Feb 2013 09:36:42 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 03BBB21F8467 for ; Thu, 7 Feb 2013 09:36:42 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3VOF-0005Do-D2; Thu, 07 Feb 2013 18:36:12 +0100 Message-ID: <5113E5EF.3020306@si6networks.com> Date: Thu, 07 Feb 2013 14:35:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Karl Auer Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <5112F99B.7090604@si6networks.com> <5113602B.5090709@gmail.com> <1360226247.5572.43.camel@karl> <51137074.2030707@bogus.com> <1360233264.5572.46.camel@karl> In-Reply-To: <1360233264.5572.46.camel@karl> 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: Thu, 07 Feb 2013 17:36:43 -0000 On 02/07/2013 07:34 AM, Karl Auer wrote: >>> Coming in very late and this has probably already been thought of, but >>> the ESP header *is* effectively a payload, and may need to be >>> fragmented. >> everything after the esp header is payload for everyone other than the >> intended recipient, who has more headers to unwrap once the payload has >> been decrypted. > > Er - yes. I just meant that you can't take the hard line that "headers > shall not be fragmented" (not that Brian was saying that) when at least > one header may have to be. There will only be more headers to unwrap in > tunnel mode. >From the pov of this I-D, ESP is the "upper layer protocol". So as long as you have everythin till the ESP header in the first fragment, you're fine. I could add a clarification, if you want (for instance, I added something along those lines in draft-ietf-v6ops-ra-guard-implementation) Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From despres.remi@laposte.net Thu Feb 7 09:45: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 187E821F8473 for ; Thu, 7 Feb 2013 09:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bVbJEDVTW1o for ; Thu, 7 Feb 2013 09:45:06 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2921F8479 for ; Thu, 7 Feb 2013 09:45:05 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 183C97000051; Thu, 7 Feb 2013 18:45:05 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id C875870000B8; Thu, 7 Feb 2013 18:45:04 +0100 (CET) X-SFR-UUID: 20130207174504821.C875870000B8@msfrf2216.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Keeping the 4rd-range issue separate from the general u/g discussion From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5113DC89.4050008@dougbarton.us> Date: Thu, 7 Feb 2013 18:45:05 +0100 Message-Id: <2D697DA1-C8F6-4BB4-830D-2018717E37B3@laposte.net> References: <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <20130205.150156.74693024.sthaug@nethelp.no> <511118F1.6060906@gmail.com> <65B90B43-DBF3-4999-BB9B-0DD3C6E7222D@laposte.net> <5112477A.2030105@kit.edu> <511281D0.6010208@gont.com.ar> <15B60CA7-1964-41F7-93FC-D89592955E40@cisco.com> <44EA445C-4DBF-435E-BF09-51BB46D9A49C@cisco.com> <5113DC89.4050008@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) 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 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 17:45:07 -0000 Le 2013-02-07 =E0 17:55, Doug Barton a =E9crit : > On 02/07/2013 06:01 AM, R=E9mi Despr=E9s wrote: >> Besides, these remaining concerns are aside from the question asked = by Softwire >=20 > R=E9mi, >=20 > Do you admit to the possibility that the design coming from softwire = might have flaws that should be addressed before it proceeds? Of course I do! OTOH, the place to discuss efficiently potential design flaws is the WG = where experts of the design are present. >=20 > I'm not saying necessarily that it does, although people here a lot = smarter than me have raised concerns that I would like to see addressed = in a manner other than, "I don't want to talk about that." OK, please quote the exchange(s) you are referring to, and I will try to = answer more. Note that preferring to discuss in a better forum isn't "I don't want to = talk about that". Anyway, sorry if I gave this impression. Regards, RD >=20 > Doug > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From stig@venaas.com Thu Feb 7 09:59: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 22A4421F8800 for ; Thu, 7 Feb 2013 09:59:06 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrmQ8tMULrpM for ; Thu, 7 Feb 2013 09:59:05 -0800 (PST) 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 6898621F85CB for ; Thu, 7 Feb 2013 09:58:59 -0800 (PST) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 714457FC7; Thu, 7 Feb 2013 18:58:57 +0100 (CET) Message-ID: <5113EB5B.3070006@venaas.com> Date: Thu, 07 Feb 2013 09:58:51 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: RFC4291 - ff01::/16 References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> <5112C307.7070308@kit.edu> <51138586.1050008@gmail.com> <20130207124927.GE27969@eerihug-hybrid.ki.sw.ericsson.se> <5113E3DD.8070804@gmail.com> In-Reply-To: <5113E3DD.8070804@gmail.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: Thu, 07 Feb 2013 17:59:06 -0000 On 2/7/2013 9:26 AM, Alexandru Petrescu wrote: > Le 07/02/2013 13:49, Erik Hugne a écrit : >> On Thu, Feb 07, 2013 at 11:44:22AM +0100, Alexandru Petrescu wrote: >>> Also, the implementation of that dropping may not be that >>> straightforward as at a quick first sight. >>> >>> A stack presented with a packet whose dst's leftmost 16bits >>> precisely match ff01::/16 should be dropped _only_ if the src of >>> that packet is an address which does not belong to that stack (in >>> other words don't discard packets originated by stack and addressed >>> to self). ('be liberal in what you accept'). >>> >> >> FreeBSD drops any packets sent to ff01::/16 if they did not originate >> from the local host. >> http://fxr.watson.org/fxr/source/netinet6/ip6_input.c#L555 >> >> Linux currently accept these, regardless of who sent them. To me the FreeBSD is the obviously correct behavior. They are supposed to be interface-local, hence not arriving from somewhere else. There could be security implications with applications using this to pass packets between them and not expecting that a forged packet could be arriving from the outside. Checking the source address is not sufficient IMO. Stig > That says to me that could be clarified, so that implementers make > interoperable implementations. > > In one sense, one wouldn't want a Linux to behave unexpectedly when a > FreeBSD sent it a packet whose IP dst is ff01::/64 with the right MAC > dst address. > > In another sense, one wouldn't want a FreeBSD to drop packets sent by a > Linux which thinks everyone acts like him/her. > > But this is speculative. HAve you seen it in practice? Which protocol > makes common use of ff01::/64? > > Alex > >> >> //E >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Thu Feb 7 10:02: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 C105721F8856 for ; Thu, 7 Feb 2013 10:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-+KBxgMn0U1 for ; Thu, 7 Feb 2013 10:02:10 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1143321F8845 for ; Thu, 7 Feb 2013 10:02:09 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3VnF-0005oj-BP; Thu, 07 Feb 2013 19:02:01 +0100 Message-ID: <5113EC09.1080506@si6networks.com> Date: Thu, 07 Feb 2013 15:01:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-03.txt References: <20130130014200.25208.35907.idtracker@ietfa.amsl.com> <51087C12.7010907@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>, 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, 07 Feb 2013 18:02:10 -0000 Hi, Ole, On 02/07/2013 09:28 AM, Ole Troan wrote: > Fernando, > >> It's been a month since I received your last message regarding this I-D. >> >> Can we ship this document now? >> >> P.S.: This latest version addresses the feedback received from Tassos >> (I've double-checked with him that his comments have been addressed). > > it would be good if you could summarise the changes from the last call. I will. > I read through the document again, and my only remaining concern is that the document doesn't specify the > hash function to be used. > > is there usefulness in having stable interface-ids that are generated the same across implementations? > and are predictable given knowledge of the "secret key". I would think so. I'm not saying there wouldn't be any value, however: 1) That means all implementations should employ the same hash function -- however, e.g. an embedded device might be more inclined to use MD5 than a more expensive function (that could be used by, say, a desktop computer). 2) Mandating a hash function makes us stuck with a single hash-function forever. What if whatever function we adopt becomes deprecated? (we would update the std, and now have a set of boxes that behave one way, are another set that behaves in another). 3) One of the paramters to the hash function is the Interface Index. Different implementations use different values for the interface index (for instance, the RFCs do not speficify how an interface index should be constructed) -- and, besides, there's no requirement whatsoever that even if two implementations use, say, small numbers for interface index, they use exactly the same values, for the same interfaces. Put another way, it seems to me that what you describe would not be that easy to enforce. Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From despres.remi@laposte.net Thu Feb 7 10:22: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 60EAE21F84F5 for ; Thu, 7 Feb 2013 10:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx8fpZNqMW6E for ; Thu, 7 Feb 2013 10:22:00 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFC121F88CB for ; Thu, 7 Feb 2013 10:22:00 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id 03F8970000B5; Thu, 7 Feb 2013 19:21:58 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id B74D370000AE; Thu, 7 Feb 2013 19:21:57 +0100 (CET) X-SFR-UUID: 20130207182157750.B74D370000AE@msfrf2312.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5113DE3A.6090605@dougbarton.us> Date: Thu, 7 Feb 2013 19:21:58 +0100 Message-Id: <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> <5113DE3A.6090605@dougbarton.us> To: 6man 6man-wg , Doug Barton X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 07 Feb 2013 18:22:01 -0000 Le 2013-02-07 =E0 18:02, Doug Barton a =E9crit : > R=E9mi, >=20 > I think you've misunderstood me. Please see below. >=20 > On 02/06/2013 02:01 AM, R=E9mi Despr=E9s wrote: ... >> Fair enough. My answer is that no software that I know makes >> determination based on the u bit. >=20 > Thanks, that matches my (admittedly imperfect) understanding as well. >=20 >> My point is that it isn't sufficient for the IETF u bit to have no >> meaning. (a) It has what is specified in RFC 4291. (b) No software I >> know creates IIDs having u =3D 1 without an IEEE-based OUI. >=20 > So my new question is, why do you care? See below. >=20 > To amplify slightly, I am ambivalent about un-defining the u and g = bits. > Generally such a thing is difficult to do, since it's nearly = impossible to get a complete survey of all software everywhere that may = use those bits, and determine if it is safe to stop to just stop caring = about them. Since it is at least risky, one would need a good reason to take that = risk. =20 > OTOH, I am not a fan of magic bits in general, and I have never seen = an adequate explanation of why an implementor should care about these 2. = So I'm sympathetic to the argument about un-defining them, but you seem = to be vehemently opposed to it, so I'm trying to understand your = objection. "It's important because it's important!" doesn't help me. :) Let me clarify where I stand: (a) Whether changing RFC4291 or not is not the issue for which I work so = hard these days. I do think it isn't necessary and have argued in this = direction, but my point is that I see a real benefit (point (b)) in = using RFC 4291 as is. No modification should break anything, including = this benefit. =20 (b) The benefit comes from the following, i.e. one of the 4rd = objectives:=20 - We want to statelessly establish automatic tunnels for residual IPv4 = across IPv6-only domains. - We don't want, when doing so, to impose any renumbering of IPv6 link = and/or host. - This is possible ONLY IF we use, for each CE tunnel endpoint, an IPv6 = address that no host in the CE site may be using. - Fortunately this happens to be feasible, with IPv6 as is: in a site = that is delegated a prefix up to /64, no host that has a global unicast = address conforming to RFC4291 may have an IID in which u=3Dg=3D1. - By reserving a small subset of this unused IID space, we reach our = objective. Hope it clarifies. Regards, RD >=20 > Doug >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rogerj@gmail.com Thu Feb 7 10:35: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 6DCA821F88B9 for ; Thu, 7 Feb 2013 10:35:37 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nToYPWOG0O4D for ; Thu, 7 Feb 2013 10:35:36 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E0DE121F8895 for ; Thu, 7 Feb 2013 10:35:35 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so2405655wey.29 for ; Thu, 07 Feb 2013 10:35:35 -0800 (PST) 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=nNp4ZB7obe6sQ7MjyeUE0erGvqqcgH6FnTlHZumFP18=; b=Etd/k6t7+DA8FDFj7sSF8zJHsnfJlx45f2AsSToL2nv8Vd8QQkzXctnIEjV/IjgE/j 9sXL8qgSOTSkLn4OQ5XFA8wFRaVCk8FHHl6GuKBZD/d/dvJIgil5TyciRxP6aawC3h43 4tqxsQ+t/ENTZbtlMCfzHjpA51gDbBeLhw9hsIuC2jZ+e/Y1mnAS9osnMOHFRLgI17r8 sQw8ZIzEKuN6dQv2WqFZ4vw/d0YxAWNpHh6TQowNNyRwROc9KoqrNrjSUvCj4SRihsIg 9mkuaL3J9A60EI62VWt+w1z9pqxvKULOXq2e2mBW42Xej1Anjnr4tH6Pe+MrC+wtsU6J U8+A== MIME-Version: 1.0 X-Received: by 10.194.57.231 with SMTP id l7mr4931520wjq.9.1360262135053; Thu, 07 Feb 2013 10:35:35 -0800 (PST) Received: by 10.217.44.74 with HTTP; Thu, 7 Feb 2013 10:35:34 -0800 (PST) In-Reply-To: <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> <5113DE3A.6090605@dougbarton.us> <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> Date: Thu, 7 Feb 2013 19:35:34 +0100 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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, 07 Feb 2013 18:35:37 -0000 sorry, but we can't all be nice all the time, see more inline, On Thu, Feb 7, 2013 at 7:21 PM, R=E9mi Despr=E9s = wrote: > (b) The benefit comes from the following, i.e. one of the 4rd objectives: > - We want to statelessly establish automatic tunnels for residual IPv4 ac= ross IPv6-only domains. not a bad idea, but don't we have other options in this area? > - We don't want, when doing so, to impose any renumbering of IPv6 link an= d/or host. excellent, any protocol/idea that impose this is quite badly designed. > - This is possible ONLY IF we use, for each CE tunnel endpoint, an IPv6 a= ddress that no host in the CE site may be using. I have always thought any address I get on my host from dhcpv6/ra or similar, mixed with DAD and other mechanism are as close to a guaranty as we can get. No need for some magic bits of any type. > - Fortunately this happens to be feasible, with IPv6 as is: in a site tha= t is delegated a prefix up to /64, no host that has a global unicast addres= s conforming to RFC4291 may have an IID in which u=3Dg=3D1. ... You just ASSUME something I think we all understand is not possible to guaranty. There will be collision, deal with it. Someone will probably sooner than later, assign either auto (yes they break the "rule") or manual an address that will cause two hosts on the same link/site to have the same address no matter how much you ASSUME the above (u=3Dg=3D1...) > - By reserving a small subset of this unused IID space, we reach our obje= ctive. > > Hope it clarifies. yes it clarifies to me that you suggest a quite broken way of using IPv6 addresses. You ASSUME things, among that some magic bits (u and g) will give you something close to an unique address. --=20 Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From rbonica@juniper.net Thu Feb 7 11:26: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 65A3721F8678 for ; Thu, 7 Feb 2013 11:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDrcVdw943CE for ; Thu, 7 Feb 2013 11:26:22 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9791521F8856 for ; Thu, 7 Feb 2013 11:26:22 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKURP/3nzoj97XrtIRltoe3Ae7RoppQBkB@postini.com; Thu, 07 Feb 2013 11:26:22 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Feb 2013 08:18:48 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 7 Feb 2013 08:18:48 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.181) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 7 Feb 2013 08:27:36 -0800 Received: from mail83-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Thu, 7 Feb 2013 16:18:47 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id 6C0192C00EF for ; Thu, 7 Feb 2013 16:18:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz9371I146fI542I1432I1418Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 1360253924548371_936; Thu, 7 Feb 2013 16:18:44 +0000 (UTC) Received: from CH1EHSMHS043.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id 6B86C44025D; Thu, 7 Feb 2013 16:18:44 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 7 Feb 2013 16:18:43 +0000 Received: from BL2PRD0512MB646.namprd05.prod.outlook.com ([169.254.9.21]) by BL2PRD0512HT001.namprd05.prod.outlook.com ([10.255.233.34]) with mapi id 14.16.0263.000; Thu, 7 Feb 2013 16:18:43 +0000 From: Ronald Bonica To: Ole Troan Subject: RE: Moving forward draft-ietf-6man-oversized-header chain? Thread-Topic: Moving forward draft-ietf-6man-oversized-header chain? Thread-Index: AQHOAw28zEIc3pLjHkiS7gIVdRH7CphtSPowgAAZCoCAABuuAIAAtSuAgABg7dA= Date: Thu, 7 Feb 2013 16:18:42 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501EAA730@BL2PRD0512MB646.namprd05.prod.outlook.com> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> <9C27CF37-C351-43E9-B8A8-32DB0D191196@employees.org> In-Reply-To: <9C27CF37-C351-43E9-B8A8-32DB0D191196@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%EMPLOYEES.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%SI6NETWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "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, 07 Feb 2013 19:26:32 -0000 Inline.... > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Thursday, February 07, 2013 5:19 AM > To: Ronald Bonica > Cc: 6man-chairs@tools.ietf.org; Fernando Gont; ipv6@ietf.org > Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? >=20 > Ron, >=20 > > I am supporting this draft because the community has become > accustomed to stateless firewalls on routers. These stateless firewalls > are capable of filtering based upon information gleaned from both the > IPv6 and L4 header. >=20 > don't get me wrong, I'm also in support of this work. ;-) but if we go > down this slippery slope. where do we draw the line? I do know of > filtering routers that look at the L7 headers. > and I'm sure there are those that inspect the payload as well. > do we arbitrary choose to stop at the L4 header? Clearly, we have to draw the line somewhere. I think that it is reasonable = to stop at the L4 header. >=20 > as Karl pointed out, what do we do with the ESP header? do you define > which part of the ESP header that must be included in the first > fragment? or does this mean that a packet with ESP MUST NOT be > fragmented? > are there other headers where what consist of the "entire ipv6 header > chain" is unclear? The document needs to make a special exception for encrypted payloads. In t= hat case, the ESP header must begin on the first fragment, but need not end= on the first fragment. Does this sound reasonable? >=20 > > When a stateless firewall encounters an IPv6 datagram in which the > IPv6 header and L4 header don't appear in the first fragment, it can't > make an informed filtering decision on any fragment. However, if there > is a guarantee that the IPv6 header and the L4 header are in the first > fragment, it can at least make an informed decision regarding that > fragment. > > > > Would the draft be more acceptable if we stated this as the > motivation and removed references to NAT64? >=20 > yes, I think that would help. I will work with Fernando on this. >=20 > Best regards, > Ole >=20 >=20 > > > > Ron > > > > > >> -----Original Message----- > >> From: Ole Troan [mailto:ot@cisco.com] > >> Sent: Wednesday, February 06, 2013 4:51 PM > >> To: Ronald Bonica > >> Cc: Fernando Gont; 6man-chairs@tools.ietf.org; ipv6@ietf.org > >> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? > >> > >> while we are on the topic, and you made me re-read the document. > >> > >> section 4: > >> issues with terminology. call a device that walks the extension > >> header chain something else than a router. > >> rfc2460 definition of a router; "extension headers are not examined > >> or processed by any node along a packet's delivery path". > >> a switch in my book doesn't look at L3 headers. > >> use "middlebox" or "filtering router"? > >> > >> section 3: > >> is the main justification for this work to make NAT64s function > better? > >> if so that might be a little short-sighted, by the time we've > updated > >> IPv6 implementations... perhaps use a different example than NAT64? > >> > >> section 5: > >> restricting the header chain seems like an incomplete solution. > >> doesn't a middlebox need to reassembly fragments anyway, to deal > with > >> mis- ordered fragments? > >> at least at some point I thought BSD sent fragmented packets by > >> sending the last fragment first. > >> > >> with a more idealist hat on: > >> that extension headers are hard to parse, some consider a feature of > >> IPv6. > >> a feature that tries to protect the end to end Internet, i.e. that > we > >> can deploy new transport protocols and extension headers without > >> upgrading all intermediate boxes. changing the IPv6 protocol for a > >> flawed design (aka middleboxes), is that wise? > >> might as well just deprecate IP fragmentation. (which I would be in > >> favour of). > >> > >> and don't get me wrong, I can't imagine any use case for an > extension > >> header chain longer than 1280 bytes either. > >> > >> cheers, > >> Ole > >> > >> > >> > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 From kauer@biplane.com.au Thu Feb 7 12:44: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 9906321F8455 for ; Thu, 7 Feb 2013 12:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9aZu39W4jVV for ; Thu, 7 Feb 2013 12:44:14 -0800 (PST) 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 A3C2D21F8A4F for ; Thu, 7 Feb 2013 12:44:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIDAGURFFGWZX+7/2dsb2JhbAANOL9iAgKBG4MSAQEBBIEJCxguVwYTtEyTRo1RT4M8A4gwmTOIJA 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; 08 Feb 2013 07:14:10 +1030 Message-ID: <1360269850.5572.68.camel@karl> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Karl Auer To: IETF IPv6 Date: Fri, 08 Feb 2013 07:44:10 +1100 In-Reply-To: <5113E5EF.3020306@si6networks.com> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <5112F99B.7090604@si6networks.com> <5113602B.5090709@gmail.com> <1360226247.5572.43.camel@karl> <51137074.2030707@bogus.com> <1360233264.5572.46.camel@karl> <5113E5EF.3020306@si6networks.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: Thu, 07 Feb 2013 20:44:14 -0000 On Thu, 2013-02-07 at 14:35 -0300, Fernando Gont wrote: > I could add a clarification, if you want I think every exception needs a clarification, yes :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog 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 otroan@employees.org Thu Feb 7 13:00: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 1B9AF21F86F5 for ; Thu, 7 Feb 2013 13:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-Vc2ce8hBMH for ; Thu, 7 Feb 2013 13:00:00 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACA421F86F2 for ; Thu, 7 Feb 2013 13:00:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIkUFFGQ/khR/2dsb2JhbABFwGwWc4IfAQEEAToxDhALDjhXBieHdwbAB40Tg2hhA6ZzgwE X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208";a="80324623" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 07 Feb 2013 20:59:59 +0000 Received: from dhcp-10-61-100-216.cisco.com (dhcp-10-61-100-216.cisco.com [10.61.100.216]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r17KxwUb025980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 20:59:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Ole Troan In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501EAA730@BL2PRD0512MB646.namprd05.prod.outlook.com> Date: Thu, 7 Feb 2013 21:59:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54B6EBB0-6EEF-49E6-BA1C-114C1EBB6E47@employees.org> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> <9C27CF37-C351-43E9-B8A8-32DB0D191196@employees.org> <2CF4CB03E2AA464BA0982EC92A02CE2501EAA730@BL2PRD0512MB646.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1499) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "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, 07 Feb 2013 21:00:01 -0000 Ron, >>> I am supporting this draft because the community has become >> accustomed to stateless firewalls on routers. These stateless = firewalls >> are capable of filtering based upon information gleaned from both the >> IPv6 and L4 header. >>=20 >> don't get me wrong, I'm also in support of this work. ;-) but if we = go >> down this slippery slope. where do we draw the line? I do know of >> filtering routers that look at the L7 headers. >> and I'm sure there are those that inspect the payload as well. >> do we arbitrary choose to stop at the L4 header? >=20 > Clearly, we have to draw the line somewhere. I think that it is = reasonable to stop at the L4 header. agree. >> as Karl pointed out, what do we do with the ESP header? do you define >> which part of the ESP header that must be included in the first >> fragment? or does this mean that a packet with ESP MUST NOT be >> fragmented? >> are there other headers where what consist of the "entire ipv6 header >> chain" is unclear? >=20 > The document needs to make a special exception for encrypted payloads. = In that case, the ESP header must begin on the first fragment, but need = not end on the first fragment. >=20 > Does this sound reasonable? yes, I'll leave it to the ipsec experts to determine if there is a part = of the header that should be in the first fragment or not. >>> When a stateless firewall encounters an IPv6 datagram in which the >> IPv6 header and L4 header don't appear in the first fragment, it = can't >> make an informed filtering decision on any fragment. However, if = there >> is a guarantee that the IPv6 header and the L4 header are in the = first >> fragment, it can at least make an informed decision regarding that >> fragment. >>>=20 >>> Would the draft be more acceptable if we stated this as the >> motivation and removed references to NAT64? >>=20 >> yes, I think that would help. >=20 > I will work with Fernando on this. thanks! cheers, Ole From kauer@biplane.com.au Thu Feb 7 13:47: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 1FDE821F8910 for ; Thu, 7 Feb 2013 13:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaZgISgxHf2O for ; Thu, 7 Feb 2013 13:47:06 -0800 (PST) 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 4498521F8901 for ; Thu, 7 Feb 2013 13:47:02 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMDABsfFFGWZX+7/2dsb2JhbAANOL9fBAICgRuDEgEBAQSBCQsYLlcZtQ2TQY4gE4MpA4gwmTOIJA 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; 08 Feb 2013 08:17:01 +1030 Message-ID: <1360273621.5572.78.camel@karl> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Karl Auer To: ipv6@ietf.org Date: Fri, 08 Feb 2013 08:47:01 +1100 In-Reply-To: <54B6EBB0-6EEF-49E6-BA1C-114C1EBB6E47@employees.org> References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> <9C27CF37-C351-43E9-B8A8-32DB0D191196@employees.org> <2CF4CB03E2AA464BA0982EC92A02CE2501EAA730@BL2PRD0512MB646.namprd05.prod.outlook.com> <54B6EBB0-6EEF-49E6-BA1C-114C1EBB6E47@employees.org> 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: Thu, 07 Feb 2013 21:47:07 -0000 On Thu, 2013-02-07 at 21:59 +0100, Ole Troan wrote: > >> as Karl pointed out, what do we do with the ESP header? > > The document needs to make a special exception for encrypted > > payloads. In that case, the ESP header must begin on the first > > fragment, but need not end on the first fragment. Do you mean that the ESP header must be the first item in the fragmentable part of the first fragment? Or that the ESP header must be (at least partly) in the non-fragmentable part of the first fragment? If the latter, that's a new kind of animal. At present, a header is either completely in the non-fragmentable part or completely in the fragmentable part. Permitting a header to straddle the fragment header seems odd, and I can't immediately see how you could do it without changing the fragment header definition, either. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog 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 Thu Feb 7 13:57: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 458D121F86D4 for ; Thu, 7 Feb 2013 13:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdwNOppMaYFx for ; Thu, 7 Feb 2013 13:57:03 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7D67E21F842E for ; Thu, 7 Feb 2013 13:57:03 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3ZSf-0002pe-22; Thu, 07 Feb 2013 22:56:56 +0100 Message-ID: <5114231E.4020405@si6networks.com> Date: Thu, 07 Feb 2013 18:56:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Karl Auer Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <51100B9E.2040503@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E907F7@BL2PRD0512MB646.namprd05.prod.outlook.com> <9B7C0D23-4EC3-4C87-913F-C6CB24CCAD8B@cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E93999@BL2PRD0512MB646.namprd05.prod.outlook.com> <9C27CF37-C351-43E9-B8A8-32DB0D191196@employees.org> <2CF4CB03E2AA464BA0982EC92A02CE2501EAA730@BL2PRD0512MB646.namprd05.prod.outlook.com> <54B6EBB0-6EEF-49E6-BA1C-114C1EBB6E47@employees.org> <1360273621.5572.78.camel@karl> In-Reply-To: <1360273621.5572.78.camel@karl> 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: Thu, 07 Feb 2013 21:57:04 -0000 On 02/07/2013 06:47 PM, Karl Auer wrote: > On Thu, 2013-02-07 at 21:59 +0100, Ole Troan wrote: >>>> as Karl pointed out, what do we do with the ESP header? >>> The document needs to make a special exception for encrypted >>> payloads. In that case, the ESP header must begin on the first >>> fragment, but need not end on the first fragment. > > Do you mean that the ESP header must be the first item in the > fragmentable part of the first fragment? Or that the ESP header must be > (at least partly) in the non-fragmentable part of the first fragment? > > If the latter, that's a new kind of animal. At present, a header is > either completely in the non-fragmentable part or completely in the > fragmentable part. Permitting a header to straddle the fragment header > seems odd, and I can't immediately see how you could do it without > changing the fragment header definition, either. I think we all mean that the ESP header must be the last "visible" header in the fragmentable part of the first fragment. Put another way, if the ESP header is the last chunk of headers one could possibly snoop without decrypting the packet, then that header must be in the first fragment. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From erik.hugne@ericsson.com Thu Feb 7 22:33: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 F1C4521F89DC for ; Thu, 7 Feb 2013 22:33:29 -0800 (PST) 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_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFTszl1g1qWO for ; Thu, 7 Feb 2013 22:33:29 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C943021F89E1 for ; Thu, 7 Feb 2013 22:33:23 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-b5-51149c31641e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FD.9E.10459.13C94115; Fri, 8 Feb 2013 07:33:21 +0100 (CET) Received: from eerihug-hybrid.ki.sw.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 8 Feb 2013 07:33:21 +0100 Date: Fri, 8 Feb 2013 07:30:24 +0100 From: Erik Hugne To: Stig Venaas Subject: Re: RFC4291 - ff01::/16 Message-ID: <20130208063024.GB2069@eerihug-hybrid.ki.sw.ericsson.se> References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> <5112C307.7070308@kit.edu> <51138586.1050008@gmail.com> <20130207124927.GE27969@eerihug-hybrid.ki.sw.ericsson.se> <5113E3DD.8070804@gmail.com> <5113EB5B.3070006@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5113EB5B.3070006@venaas.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RtdwjkigwbQ/hhYz3/1gtXh59j2T RcfnS4wOzB47Z91l91iy5CeTx8auh0wBzFFcNimpOZllqUX6dglcGQc+nmIt6GWvePWgn7mB 8SVrFyMnh4SAicTd8+tYIGwxiQv31rN1MXJxCAmcZJTo33iYFcLZzSjx/cx5JpAqFgEViV9v /7CD2GwCWhITn08Ei4sIKEqc3fSTDcRmFnCR+NrTyQhiCwsoSCw8vBWsnhcofuDWYqgNu5gk Vu34xAKREJQ4OfMJC0SzjsSC3Z+AijiAbGmJ5f84QExOoF3LXtuBVIgCnTDl5DawVUJA9v2X s9knMArOQjJoFpJBsxAGLWBkXsXInpuYmZNebriJERikB7f81t3BeOqcyCFGaQ4WJXHeMNcL AUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYfR5tCNTczisyN1jSN2PJ/uzHnKz1UpL9x3ve u35JK9l3wj7HTLtZ34zlp8/KiJLT8a6e1xR5Ylxz99b0BvF1L+26emHKFROPhuVljx5ev2bS a31+tYvl/mJP0w9vNDf7rDHWmc0acTONdUXbkh1mDg+sJ8u4dnef6vhTvZZF/2zmdeGaXXuV WIozEg21mIuKEwEumfocIAIAAA== Cc: Alexandru Petrescu , 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, 08 Feb 2013 06:33:30 -0000 On Thu, Feb 07, 2013 at 09:58:51AM -0800, Stig Venaas wrote: > To me the FreeBSD is the obviously correct behavior. They are supposed > to be interface-local, hence not arriving from somewhere else. There > could be security implications with applications using this to pass > packets between them and not expecting that a forged packet could be > arriving from the outside. Checking the source address is not sufficient > IMO. Submitted errata: http://www.rfc-editor.org/errata_search.php?rfc=4291&eid=3480 > On 2/7/2013 9:26 AM, Alexandru Petrescu wrote: > >But this is speculative. HAve you seen it in practice? Which protocol > >makes common use of ff01::/64? Yes, There's a long story originating from a Java/JDK bug, where it fails to bind sockets to a link-local multicast address. The desperate designer started using ff01::/16 addresses instead, which worked on Linux. //E From despres.remi@laposte.net Fri Feb 8 00:31: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 D677221F854F for ; Fri, 8 Feb 2013 00:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvL6+TZ1T310 for ; Fri, 8 Feb 2013 00:31:43 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id A077D21F8460 for ; Fri, 8 Feb 2013 00:31:42 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id BD5EA7000068; Fri, 8 Feb 2013 09:31:41 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id 785847000067; Fri, 8 Feb 2013 09:31:41 +0100 (CET) X-SFR-UUID: 20130208083141493.785847000067@msfrf2112.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 8 Feb 2013 09:31:40 +0100 Message-Id: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> <5113DE3A.6090605@dougbarton.us> <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> To: Roger =?iso-8859-1?q?J=F8rgensen?= X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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: Fri, 08 Feb 2013 08:31:44 -0000 2013-02-07 19:35, Roger J=F8rgensen : > sorry, but we can't all be nice all the time, see more inline, >=20 >=20 > On Thu, Feb 7, 2013 at 7:21 PM, R=E9mi Despr=E9s = wrote: > >> (b) The benefit comes from the following, i.e. one of the 4rd = objectives: >> - We want to statelessly establish automatic tunnels for residual = IPv4 across IPv6-only domains. >=20 > not a bad idea, but don't we have other options in this area? In Softwire, conclusion has been this was a tool to have. >> - We don't want, when doing so, to impose any renumbering of IPv6 = link and/or host. >=20 > excellent, any protocol/idea that impose this is quite badly designed. (*) Good. >> - This is possible ONLY IF we use, for each CE tunnel endpoint, an = IPv6 address that no host in the CE site may be using. >=20 > I have always thought any address I get on my host from dhcpv6/ra or > similar, mixed with DAD and other mechanism are as close to a guaranty > as we can get. Hosts of an IPv6 customer site can have IPv6 addresses assigned, with = SLAAC or DHCPv6, BEFORE 4rd is activated.=20 If these addresses become in conflict with the CE 4rd address when 4rd = is activated, renumbering becomes necessary. The objective (*) isn't = satisfied. =20 (Reason why the CE itself cannot take another address is because this = address must be *algorithmically derived* from an a IPv4 destination by = other CEs.) > No need for some magic bits of any type. Bits u and g haven't been invented for 4rd. Using u=3D1 for future technologies, is anticipated in RFC4291 itself.=20= No magic involved. >> - Fortunately this happens to be feasible, with IPv6 as is: in a site = that is delegated a prefix up to /64, no host that has a global unicast = address conforming to RFC4291 may have an IID in which u=3Dg=3D1. >=20 > ... You just ASSUME something I think we all understand is not > possible to guaranty. There will be collision, deal with it. Let me make the point again. It is a fact (not an assumption) that RFC4291-conforming IIDs either = have u=3D0, in which case other bits may have any values, or, if they = have have g=3D1, have a specified structure. So far the only such = structure is that of IEEE derived IIDs. With it, g=3D0 because these = IIDs are those of unicast addresses. If, in your understanding, RFC 4291 authorizes IIDs having u=3Dg=3D1, = PLEASE EXPLAIN. > Someone will probably sooner than later, assign either auto (yes they > break the "rule") Auto assignments that break the rules are bound to create problems = anyway. Their bugs need to be fixed. > or manual an address that will cause two hosts on > the same link/site to have the same address no matter how much you > ASSUME the above (u=3Dg=3D1...) Manual mistakes do occur, yes. They have to be fixed like other bugs.=20 >> - By reserving a small subset of this unused IID space, we reach our = objective. >>=20 >> Hope it clarifies. >=20 > yes it clarifies to me that you suggest a quite broken way of using > IPv6 addresses. You ASSUME things, among that some magic bits (u and > g) will give you something close to an unique address. I hope you will eventually understand that so much negativeness isn't = justified.=20 Fortunately for me, a number of highly experienced 6man contributors = have already expressed their view that the proposed range reservation = isn't a problem. Regards, RD >=20 >=20 >=20 > --=20 >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no From ot@cisco.com Fri Feb 8 01:03: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 B130121F8581 for ; Fri, 8 Feb 2013 01:03:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRRdofy8HhYr for ; Fri, 8 Feb 2013 01:03:55 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2B21F854D for ; Fri, 8 Feb 2013 01:03:55 -0800 (PST) Received: from dhcp-10-61-101-242.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 6541C5ECA; Fri, 8 Feb 2013 01:03:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: RFC4291 - ff01::/16 From: Ole Troan In-Reply-To: <20130208063024.GB2069@eerihug-hybrid.ki.sw.ericsson.se> Date: Fri, 8 Feb 2013 10:03:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EF57B5F-96E0-4A64-A852-00DB7CA83FCE@cisco.com> References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> <5112C307.7070308@kit.edu> <51138586.1050008@gmail.com> <20130207124927.GE27969@eerihug-hybrid.ki.sw.ericsson.se> <5113E3DD.8070804@gmail.com> <5113EB5B.3070006@venaas.com> <20130208063024.GB2069@eerihug-hybrid.ki.sw.ericsson.se> To: Erik Hugne X-Mailer: Apple Mail (2.1499) Cc: Alexandru Petrescu , 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, 08 Feb 2013 09:03:56 -0000 Erik, >> To me the FreeBSD is the obviously correct behavior. They are = supposed >> to be interface-local, hence not arriving from somewhere else. There >> could be security implications with applications using this to pass >> packets between them and not expecting that a forged packet could be >> arriving from the outside. Checking the source address is not = sufficient >> IMO. >=20 > Submitted errata: > http://www.rfc-editor.org/errata_search.php?rfc=3D4291&eid=3D3480 you don't think the text in RFC4007 is clear enough? cheers, Ole >=20 >> On 2/7/2013 9:26 AM, Alexandru Petrescu wrote: >>> But this is speculative. HAve you seen it in practice? Which = protocol >>> makes common use of ff01::/64? >=20 > Yes, There's a long story originating from a Java/JDK bug, where it = fails to=20 > bind sockets to a link-local multicast address. The desperate designer = started > using ff01::/16 addresses instead, which worked on Linux. >=20 > //E > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From erik.hugne@ericsson.com Fri Feb 8 01:29: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 46D0A21F8765 for ; Fri, 8 Feb 2013 01:29:21 -0800 (PST) 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_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c372g8N6fSM6 for ; Fri, 8 Feb 2013 01:29:20 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6521221F8733 for ; Fri, 8 Feb 2013 01:29:20 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-63-5114c56eda2e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.69.10459.E65C4115; Fri, 8 Feb 2013 10:29:18 +0100 (CET) Received: from eerihug-hybrid.ki.sw.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 8 Feb 2013 10:29:17 +0100 Date: Fri, 8 Feb 2013 10:26:21 +0100 From: Erik Hugne To: Ole Troan Subject: Re: RFC4291 - ff01::/16 Message-ID: <20130208092621.GC29046@eerihug-hybrid.ki.sw.ericsson.se> References: <20130206162007.GD12781@eerihug-hybrid.ki.sw.ericsson.se> <51128C02.4080301@kit.edu> <5857.1360175037@sandelman.ca> <5112C307.7070308@kit.edu> <51138586.1050008@gmail.com> <20130207124927.GE27969@eerihug-hybrid.ki.sw.ericsson.se> <5113E3DD.8070804@gmail.com> <5113EB5B.3070006@venaas.com> <20130208063024.GB2069@eerihug-hybrid.ki.sw.ericsson.se> <3EF57B5F-96E0-4A64-A852-00DB7CA83FCE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <3EF57B5F-96E0-4A64-A852-00DB7CA83FCE@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+JvjW7eUZFAg4cHjC1mvvvBavHy7Hsm ixW71rNadHy+xOjA4jHl90ZWj52z7rJ7LFnyk8ljY9dDpgCWKC6blNSczLLUIn27BK6M9icT mAuuMFfMOXiQpYHxJ1MXIyeHhICJxP2D81ggbDGJC/fWs3UxcnEICZxklPjXuoQJwtnNKLHz 61qwDhYBFYl5Cw6DdbAJaElMfD4RLC4iICNxac1RsDizQKrE42NPweLCAgoSCw9vZQexeQVc Ja58/QA1dAWzxOV7W5khEoISJ2c+gWrWkViw+xPQGRxAtrTE8n8cIGFOAVuJGRMgdokC3TDl 5DY2EFsIyL7/cjb7BEbBWUgmzUIyaRbCpAWMzKsY2XMTM3PSyw03MQJD9+CW37o7GE+dEznE KM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD44xjt7fwPNnsoGziafnR13nm it287ud/rPzuFrWEL43l8Hp+02lFNnkxSVemia3RtebVfFPa+aM023heXLTi/933Lv9fYcPB EjhdXDvIbka9y3rn3ffteE3/JTbNff9uyfyeYP8tFs4LuSr/6E9nrs7pZLKKfSEvfuzFzSKN c6eSV6g9nymqq8RSnJFoqMVcVJwIAI31NHIrAgAA Cc: Alexandru Petrescu , 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, 08 Feb 2013 09:29:21 -0000 On Fri, Feb 08, 2013 at 10:03:51AM +0100, Ole Troan wrote: > you don't think the text in RFC4007 is clear enough? > It doesn't explicitly say that packets sent to ff01::/16 must be dropped if originated from another host. Only that it "is useful only for loopback delivery of multicasts within a single node". 'Useful' is a quite loose definition, and I was asked to file an errata on this. http://marc.info/?l=linux-netdev&m=136025168507249&w=2 //E From sthaug@nethelp.no Fri Feb 8 01:51: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 12D3A21F8955 for ; Fri, 8 Feb 2013 01:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayETVFq8CkXH for ; Fri, 8 Feb 2013 01:51:43 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0383821F876E for ; Fri, 8 Feb 2013 01:51:41 -0800 (PST) Received: (qmail 51301 invoked from network); 8 Feb 2013 09:51:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Feb 2013 09:51:39 -0000 Date: Fri, 08 Feb 2013 10:51:39 +0100 (CET) Message-Id: <20130208.105139.78750204.sthaug@nethelp.no> To: despres.remi@laposte.net Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: sthaug@nethelp.no In-Reply-To: References: <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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, 08 Feb 2013 09:51:45 -0000 > > ... You just ASSUME something I think we all understand is not > > possible to guaranty. There will be collision, deal with it. > > Let me make the point again. > It is a fact (not an assumption) that RFC4291-conforming IIDs either have u=0, in which case other bits may have any values, or, if they have have g=1, have a specified structure. So far the only such structure is that of IEEE derived IIDs. With it, g=0 because these IIDs are those of unicast addresses. However, there is nothing which enforces RFC4291-conforming IIDs for (for instance) statically configured IPv6-addresses. So in what way do well defined u/g values for RFC4291-conforming IIDs help you? Steinar Haug, AS 2116 From despres.remi@laposte.net Fri Feb 8 02:14: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 1E7AD21F8464 for ; Fri, 8 Feb 2013 02:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM3OD5lXYPSH for ; Fri, 8 Feb 2013 02:14:36 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3493A21F84F8 for ; Fri, 8 Feb 2013 02:14:35 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 6C45E70008E2; Fri, 8 Feb 2013 11:14:34 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 27EF270008E1; Fri, 8 Feb 2013 11:14:34 +0100 (CET) X-SFR-UUID: 20130208101434163.27EF270008E1@msfrf2401.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <20130208.105139.78750204.sthaug@nethelp.no> Date: Fri, 8 Feb 2013 11:14:32 +0100 Message-Id: References: <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> <20130208.105139.78750204.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1499) 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 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 10:14:37 -0000 2013-02-08 =E0 10:51, sthaug@nethelp.no : >>> ... You just ASSUME something I think we all understand is not >>> possible to guaranty. There will be collision, deal with it. >>=20 >> Let me make the point again. >> It is a fact (not an assumption) that RFC4291-conforming IIDs either = have u=3D0, in which case other bits may have any values, or, if they = have have g=3D1, have a specified structure. So far the only such = structure is that of IEEE derived IIDs. With it, g=3D0 because these = IIDs are those of unicast addresses. >=20 > However, there is nothing which enforces RFC4291-conforming IIDs for > (for instance) statically configured IPv6-addresses. > So in what way do > well defined u/g values for RFC4291-conforming IIDs help you? 1. Users that manually configure their IPv6 addresses should be = knowledgeable about what they do. If one configures an address has u=3Dg=3D1, unless it is for an = experiment, it is a human mistake (it conflicts with the IPv6 addressing = architecture of RFC 4291). Depending on the context, this mistake will = have no consequence or will eventually have to be corrected. Note that, even if one does such a mistake in a 4rd site, the likelihood = of using the 4rd IID prefix 0x0300 remains low. 2. On my home network, I know nobody is doing manual configuration. Regards, RD >=20 > Steinar Haug, AS 2116 From fgont@si6networks.com Fri Feb 8 02:17: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 E5B3221F86DC for ; Fri, 8 Feb 2013 02:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAhyJxKzMJNS for ; Fri, 8 Feb 2013 02:17:01 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5D02B21F85E6 for ; Fri, 8 Feb 2013 02:17:01 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3l0U-0004sS-0f; Fri, 08 Feb 2013 11:16:35 +0100 Message-ID: <5114D079.8040103@si6networks.com> Date: Fri, 08 Feb 2013 07:16:25 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "fltemplin@acm.org" Subject: Feedback on draft-generic-6man-tunfrag-07 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: Fri, 08 Feb 2013 10:17:03 -0000 Hi, Fred, Sorry for the delay in providing comments (as promised). Here they are: Section 2: > The current "Internet cell size" is effectively 1500 bytes, i.e., the > minimum MTU configured by the vast majority of links in the Internet. > IPv6 constrains this even further by specifying a minimum link MTU of > 1280 bytes [RFC2460]. However, due to operational issues with Path > MTU Discovery (PMTUD) [RFC1981] these sizes can often only be > accommodated when links with smaller link-layer segment sizes are > configured to perform link adaptation. We could probably add some references regarding PMTUD issues in IPv6 (some folks think/thought/expected them to be gone with v6... but they are not) -- found them later... could you move them to this para? > Unfortunately, link adaptation can present a significant burden to > the link endpoints, i.e., especially when the link supports high data > rates and/or is located nearer the "middle" of the network instead of > nearer the "edge". An alternative therefore is to ask the > originating IPv6 node to perform fragmentation on the packets it > sends, in which case reassembly would be performed by the final > destination. This is okay, but.. in the previous para, you started with the premise that you have to rely on link-adaptation as a result of PMTUD failures, so.... if ICMPv6 PTB are going to be blocked, how an you expect the sources to fragment their packets? (i.e., receive the corresponding signal) Section 3: > > This document does not propose to change these requirements, but > notes that link adaptation can be burdensome for some links to the > point that it would be highly desirable to push the fragmentation and > reassembly responsibility to the IPv6 communication endpoints. In > order to accommodate this, when the router at the link ingress > performs link adaptation on a packet it should also send an ICMPv6 > PTB message back to the original source (subject to rate limiting) > with a Next-Hop MTU less than 1280 and with Code field set to 1 > [RFC4443]. (Note that these PTB messages are advisory in nature and > do not necessarily indicate packet loss.) Some implementations validate ICMP error messages based on connection-progress (please see RFC 5927)-- in v6 this is as good as it can get, since you might not even receive the eg TCP header in the ICMPv6 payload. Since you'd be both sending an error *and* performing link adaptation, the connection would progress, and hence such implementations would drop the ICMPv6 message. -- workaround: keep track of whether the other endpoint reduces the size of its packets. If it doesn't, try "drop & send ICMPv6 PTB". (and yes, if packets stop flowing, you should assume there's a PMTUD blackhole) Section 3: > "In response to an IPv6 packet that is sent to a destination located > beyond an IPv6 link that must perform link adaptation, the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280 and with Code=1. In that > case, the IPv6 node is not required to reduce the size of subsequent > packets to less than 1500 bytes, but must perform IPv6 fragmentation > on those packets by breaking the packet into N roughly equal-length > pieces (where N is minimized and the length of each piece is smaller > than the Next-Hop MTU). These fragments will be reassembled by the > destination." I guess you meant "1280" rather than 1500? That aside: the text is a bit confusing. what's should be the maximum size of each fragment? The one reported by the ICMPv6 PTB code 1? Section 4: > Regardless of whether there is a link in the path that performs link > adaptation, when an originating IPv6 node receives a PTB message > reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node > need not reduce the size of the packets it sends. The node may > instead invoke fragmentation for packets between 1281 and 1500 bytes > (again, by splitting the packet into N roughly equal-length pieces) > before submitting each fragment for link-layer framing. These > fragments will be reassembled by the final destination Why don't you want the packet size to be reduced in this case? That aside, if you're fragmenting the packets, you're reducing their size.... so I don't get why the text says "need not reduce..." Section 4: > A more interesting situation arises when PTB messages are lost on the > return path to the originating IPv6 node. Since the node has no way > of discerning which paths may exhibit this condition, it may be > better served to assume the worst case for all paths and take > precautionary measures to avoid silent packet loss. For example, an > originating IPv6 node that wishes to ensure that packets between 1281 > and 1500 bytes will reach the final destination can use "proactive > fragmentation" to fragment each packet (again, by splitting the > packet into N roughly equal-length pieces). Fragmentation is not a panacea. Please check the recent discussion on v6ops regarding IPv6 fragment filtering, and . > 6. IANA Considerations > > There are no IANA considerations for this document. Of the top of my head: Aren't you specifying a new Code value for ICMPv6 PTB? -- Then it looks like you do have actions for IANA. Important item: At the end of the day, you're somehow saying that the IPv6 minimum MTU is no longer 1280 -- but not explicitly. So this should be made explicit (yes, yes.. "controversial"... but I like to call a lemon a lemon :-) ). -- FWIW, some folks have already noted that the hassle of having to do link adaptation, and v6-enabled links failing to to that (I have always been for references on this topic, though). 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 Fri Feb 8 02:23: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 21E9A21F87F5 for ; Fri, 8 Feb 2013 02:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZOBQ6yxaT7O for ; Fri, 8 Feb 2013 02:23:57 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8621F8700 for ; Fri, 8 Feb 2013 02:23:55 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3l7W-00050G-5f; Fri, 08 Feb 2013 11:23:51 +0100 Message-ID: <5114D22D.5040106@si6networks.com> Date: Fri, 08 Feb 2013 07:23:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: draft-ietf-6man-stable-privacy-addresses-03: Summary of changes 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> 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, 08 Feb 2013 10:23:59 -0000 Folks, As requested by Ole, here's the summary of changes from version -01 (the one WGLC'ed) to version -03 (the current one): * Incorporated text noting that the algorithm should handle reserved IIDs, and how to handle the case in which such an IID is generated. * Added more details regarding how to handle reserved IIDs and DAD failures (e.g., suggesting how many new addresses to try). * Clarified that these addresses have the same lifetime as the traditional SLAAC addresses (since we're not changing SLAAC) * Clarified that from the point of view of renumbering, these addresses behave as the traditional slaac addresses. * Added the rationale for not mandating any specific hash algorithm (additional comments on this topic may be found in my recent on-list) response to Ole) * Miscellaneous edits (added additional references, fixed obsolete text that somehow was still there from earlier versions of this document (when this I-D was meant to be a replacement for the traditional slaac addresses, rather than an alternative), etc.) Should we ship now? 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 he@uninett.no Fri Feb 8 02:59: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 CAA9321F86BE for ; Fri, 8 Feb 2013 02:59:14 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF9Wp5wT6DOC for ; Fri, 8 Feb 2013 02:59:13 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6F321F86AA for ; Fri, 8 Feb 2013 02:59:13 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id E19C43D0B4; Fri, 8 Feb 2013 11:59:10 +0100 (CET) Date: Fri, 08 Feb 2013 11:59:10 +0100 (CET) Message-Id: <20130208.115910.200301799.he@uninett.no> To: despres.remi@laposte.net Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: Havard Eidnes In-Reply-To: References: <20130208.105139.78750204.sthaug@nethelp.no> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) 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 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 10:59:14 -0000 >> However, there is nothing which enforces RFC4291-conforming IIDs for= >> (for instance) statically configured IPv6-addresses. >> So in what way do >> well defined u/g values for RFC4291-conforming IIDs help you? > > 1. > Users that manually configure their IPv6 addresses should be > knowledgeable about what they do. > > If one configures an address has u=3Dg=3D1, unless it is for an > experiment, it is a human mistake (it conflicts with the IPv6 > addressing architecture of RFC 4291). Depending on the context, > this mistake will have no consequence or will eventually have > to be corrected. What's the operational failure mode? Does it fail in a way which would be obvious to the ones who has made this mistake, or will simply some seemingly-random pairs of hosts fail to communicate? I think it would be an engineering mistake to willfully create hard-to-detect failure scenarios via a modification to already fielded standards. > Note that, even if one does such a mistake in a 4rd site, the > likelihood of using the 4rd IID prefix 0x0300 remains low. That's a nice handwave... > 2. > On my home network, I know nobody is doing manual configuration. That doesn't really prove anything. Regards, - H=E5vard From roland.bless@kit.edu Fri Feb 8 03:08: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 1862921F86B8 for ; Fri, 8 Feb 2013 03:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIaKG089Igoc for ; Fri, 8 Feb 2013 03:08:50 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 51C8821F85D7 for ; Fri, 8 Feb 2013 03:08:49 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U3lot-0004PB-2E; Fri, 08 Feb 2013 12:08:44 +0100 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 1U3los-0007Hx-RF; Fri, 08 Feb 2013 12:08:38 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id A83D7A807B8; Fri, 8 Feb 2013 12:08:38 +0100 (CET) Message-ID: <5114DCB6.5060201@kit.edu> Date: Fri, 08 Feb 2013 12:08:38 +0100 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: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> <5113DE3A.6090605@dougbarton.us> <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 1360321724.211733000 Cc: 6man 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: Fri, 08 Feb 2013 11:08:51 -0000 Hi, On 08.02.2013 09:31, Rémi Després wrote: > Hosts of an IPv6 customer site can have IPv6 addresses assigned, with > SLAAC or DHCPv6, BEFORE 4rd is activated. > If these addresses become in conflict with the CE 4rd address when > 4rd is activated, renumbering becomes necessary. The objective (*) > isn't satisfied. (Reason why the CE itself cannot take another > address is because this address must be *algorithmically derived* > from an a IPv4 destination by other CEs.) Maybe I don't get it, but it seems that mixed usage of non-4rd hosts and 4rd hosts in the same subnet is not easily possible, since 4rd cannot use different IIDs than the algorithmically derived ones. So conflicts are hopefully detected, but cannot be resolved. This seems to suggest that you better use a different 4rd subnet-prefix when configuring 4rd use so that all nodes in this 4rd subnet-prefix use the same method to derive their IID and you avoid conflicts with other hosts. Wouldn't it be possible to use those two subnets in parallel, then there would be no need to renumber existing hosts. Regards, Roland From Anders_Brandt@sigmadesigns.com Fri Feb 8 04:17: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 3009E21F854E; Fri, 8 Feb 2013 04:17:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHtf3qScot02; Fri, 8 Feb 2013 04:17:04 -0800 (PST) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 92C9121F8581; Fri, 8 Feb 2013 04:17:00 -0800 (PST) From: Anders Brandt To: "ipv6@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: FW: New Version Notification for draft-brandt-6man-lowpanz-00.txt Thread-Topic: New Version Notification for draft-brandt-6man-lowpanz-00.txt Thread-Index: AQHOBfQXxCLrKrklvUiku7D3I3CLq5hv3jNQ Date: Fri, 8 Feb 2013 12:16:57 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0AD3CCA0@cph-ex1> References: <20130208120152.10298.94148.idtracker@ietfa.amsl.com> In-Reply-To: <20130208120152.10298.94148.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.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 08 Feb 2013 05:01:53 -0800 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, 08 Feb 2013 12:17:05 -0000 R3JlZXRpbmdzLA0KDQpBIG5ldyAiSVB2NiBvdmVyIGZvbyIgSS1EIGhhcyBiZWVuIHBvc3RlZCBh dA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFuei0w MC4NCg0KVGhpcyBJLUQgc3BlY2lmaWVzIGFuIElQdjYgZW5jYXBzdWxhdGlvbiBmb3IgSVRVLVQg Ry45OTU5IHJhZGlvIG5ldHdvcmtzIHRoYXQNCkknZCBkZXNjcmliZSBhcyBhbiBhbHRlcm5hdGl2 ZSB0byBJRUVFIDgwMi4xNS40IGluIGhvbWUgYW5kIGJ1aWxkaW5nIGF1dG9tYXRpb24uIA0KDQpU aGUgSS1EIHByb3ZpZGVzIHNvbWUgYmFja2dyb3VuZCBtYXRlcmlhbCBvbiBJVFUtVCBHLjk5NTkg KGFkZHJlc3NpbmcsIGV0Yy4pDQphcyB3ZWxsIGFzIHRoZSByZXF1aXJlZCBJUHY2IHN0dWZmLiAg VGhlIGVuY2Fwc3VsYXRpb24gYW5kIGhlYWRlciBjb21wcmVzc2lvbg0Kc2NoZW1lcyBhcmUgZGVy aXZlZCBmcm9tIChhbmQgY29tcGF0aWJsZSB3aXRoKSA2TG9XUEFOLg0KDQpJIGhvcGUgdG8gZ2V0 IGEgZmV3IG1pbnV0ZXMgb24gdGhlIDZtYW4gYWdlbmRhIGluIE9ybGFuZG8gdG8gZGlzY3VzcyB0 aGUgSS1EIGFuZA0Kd2hlcmUgaXQgYmVsb25ncy4NCg0KVGhhbmtzLA0KICBBbmRlcnMNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiA4LiBmZWJydWFyIDIwMTMg MTM6MDINClRvOiBBbmRlcnMgQnJhbmR0DQpDYzogSmFrb2IgQnVyb24NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFuei0wMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFuei0wMC50 eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbmRlcnMgQnJhbmR0IGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1icmFuZHQt Nm1hbi1sb3dwYW56DQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBUcmFuc21pc3Npb24gb2YgSVB2 NiBwYWNrZXRzIG92ZXIgSVRVLVQgRy45OTU5IE5ldHdvcmtzDQpDcmVhdGlvbiBkYXRlOgkgMjAx My0wMi0wOA0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDEzDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWJyYW5kdC02bWFuLWxvd3BhbnotMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFueg0KSHRt bGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icmFuZHQtNm1h bi1sb3dwYW56LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0 aGUgZnJhbWUgZm9ybWF0IGZvciB0cmFuc21pc3Npb24gb2YgSVB2Ng0KICAgcGFja2V0cyBhbmQg YSBtZXRob2Qgb2YgZm9ybWluZyBJUHY2IGxpbmstbG9jYWwgYWRkcmVzc2VzIGFuZA0KICAgc3Rh dGVsZXNzbHkgYXV0b2NvbmZpZ3VyZWQgSVB2NiBhZGRyZXNzZXMgb24gSVRVLVQgRy45OTU5IG5l dHdvcmtzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From rja.lists@gmail.com Fri Feb 8 05:38: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 360F821F85E2 for ; Fri, 8 Feb 2013 05:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaVP50zkqnBU for ; Fri, 8 Feb 2013 05:38:04 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6E74921F858E for ; Fri, 8 Feb 2013 05:38:04 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id fc21so2334400vbb.35 for ; Fri, 08 Feb 2013 05:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=jvazphgIfSk6ZNDjWrt9nRuWj4TYPag5MM0yHCy3yhE=; b=Xynfgqv40ZhXkIkzDxHiC03Kav3elZMVZ8KrdK06K1GzMTaDMma/C/H0CQAhMTvLon rMRBS894EYuGb7AFS2g7X8jL7BwfvISROwFZPbhOEKQtPHOhg/VMCC0dfGMz1Xw5Cy6w KnB5ooGRv55nkBDHhW8txY+J4vac6L0pDjId4p0o2sWnXOLZCZ1q9fpMUGsqQNKVkh3a F+lWB3asKgiW5dVwIz470UJRicWk2uy6jQDLHh8OppgKY0TBzlLwfM8NKdLtuz3uYKMv kbrPQ1Qj4TwmfomBw90Lx7UbHeDBQmJoptmGpobnPqu3okJoIc7Dwm330tryuTYCmQIl Sp0g== X-Received: by 10.52.66.71 with SMTP id d7mr5746450vdt.121.1360330683875; Fri, 08 Feb 2013 05:38:03 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id x17sm43793433vdi.1.2013.02.08.05.38.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 05:38:02 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? Date: Fri, 8 Feb 2013 08:38:01 -0500 Message-Id: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> To: ipv6@ietf.org 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: Fri, 08 Feb 2013 13:38:10 -0000 On Friday 8th Feb 2013, Karl Auer wrote, in part: > Do you mean that the ESP header must be the first item in the > fragmentable part of the first fragment? Or that the ESP header > must be (at least partly) in the non-fragmentable part of the > first fragment? I can't lex your question, so please forgive me for starting from first principles. :-) As the name Encapsulating Security Payload (ESP) implies, ESP *encapsulates* other information, (seeks to) protect the encapsulated information, and ESP is always a terminating payload. Put another way, while ESP might contain something else (e.g. an encrypted blob that if successfully decrypted becomes a TCP header and TCP data segment), ESP is itself always the last payload in the original on-the-wire packet. In the general case, the ESP is encrypted, so the only parseable object is the SPI, which consists of the first few bytes of the ESP. The SPI is used to demux different ESP-protected sessions so that a legitimate recipient can learn which cryptographic keys/algorithms/modes to apply to the ESP in order to retrieve the protected information. While various techniques for parsing an ESP that might not be encrypted have been proposed, none seems completely (i.e. 100.00%) reliable. Separately, the proposed WESP extension appears to have zero implementations, and no support in any router/middlebox/firewall/NAT device. So WESP turns out to be irrelevant for this discussion. > If the latter, that's a new kind of animal. Not at all. ESP isn't an optional intermediate header. ESP always is an optional terminating payload, optional in the sense that a packet could contain other terminating payloads (e.g. UDP, TCP, SCTP, ICMP). > At present, a header is either completely in the > non-fragmentable part or completely in the fragment able > part. Permitting a header to straddle the fragment header > seems odd, It is already the normal case for ESP. At present, ESP might be partly in a first fragment, split between two fragments, or entirely in a non-first fragment. > and I can't immediately see how you could do it without > changing the fragment header definition, either. In turn, your confusion puzzles me. Does the above explanation help at all ? Cheers, Ran From brian.e.carpenter@gmail.com Fri Feb 8 06:36: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 417CE21F8A4A for ; Fri, 8 Feb 2013 06:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.868 X-Spam-Level: X-Spam-Status: No, score=-100.868 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-ykouI4Fg8d for ; Fri, 8 Feb 2013 06:36:03 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 97A1B21F89AA for ; Fri, 8 Feb 2013 06:36:03 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so2936259wgl.18 for ; Fri, 08 Feb 2013 06:36:02 -0800 (PST) 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=P72dh63TWCMEN3Iq+9NEKlJJyMHLF25A5TIf8GFJSJ4=; b=h2pneKqkvuzCt9hjiFhkkhe1OZQRZOYEgVmgj3Rf9vjtYhClKh8A5DTw3dwI4X8BKs kCiaUMWuNxNyjAakKfNXqTDUHSV72fnMl8GR9tB0X1YrZdhzSu7baNzS+0Ibf/OlpU5V 7kEhBMMpBLBbpzPcpMOrhiw8OCjVsDJl+IetmkpcffHDMEzN2t0wZ2SnAkQgItUpuXMw EyMSiVz0iQ4TbRllEogLKuZPTbxPd6aXRug89pTLFYxUUg9VLjoHD/tfH6FFJnHgroJM zA8JXGv48W2msHpF6af+Dt1fEZQgFL1K8ItiHMPlMN86lYqfYZjVhP0sM7s0niOID1Vv X9yg== X-Received: by 10.194.161.135 with SMTP id xs7mr10191427wjb.41.1360334160159; Fri, 08 Feb 2013 06:36:00 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-26.as13285.net. [2.101.188.26]) by mx.google.com with ESMTPS id bf2sm4513421wib.6.2013.02.08.06.35.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 06:35:58 -0800 (PST) Message-ID: <51150D5B.4010907@gmail.com> Date: Fri, 08 Feb 2013 14:36:11 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> In-Reply-To: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> 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, 08 Feb 2013 14:36:04 -0000 On 08/02/2013 13:38, RJ Atkinson wrote: > On Friday 8th Feb 2013, Karl Auer wrote, in part: ... > In turn, your confusion puzzles me. Me too. TCP is also an encapsulating header; its contents just don't happen to be encrypted. The draft's definition of "Entire IPv6 header chain" uses TCP as an example: Note: If there is an upper layer header, only the header (and not its payload) are considered part of the "entire IPv6 header chain". For example, if the upper layer protocol is TCP, only the TCP header (and not its possible data bytes) should be considered part of the "entire IPv6 header chain". but I don't think it would be any different for ESP. However, I do see one point that is under-defined right now: **How many bytes of the transport header+payload are included in this definition?** For ESP, is it 8 bytes (SPI + Sequence Number)? For TCP, is it 8 bytes (ports + Sequence Number)? etc. The draft also defines "Extension Headers": Any Extension Headers as described in Section 4 of [RFC2460], and specified in [RFC2460] or any subsequent documents. FYI, we have included a complete list of extension headers in draft-carpenter-6man-ext-transmit, and a related IANA proposal. Brian From rja.lists@gmail.com Fri Feb 8 07:17: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 402DF21F8A8F for ; Fri, 8 Feb 2013 07:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5CkSYWpN-+W for ; Fri, 8 Feb 2013 07:17:20 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 41EF921F8A61 for ; Fri, 8 Feb 2013 07:17:20 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so2432980vbb.10 for ; Fri, 08 Feb 2013 07:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=0ibxUFj5+tl5abzmSLI0OEIpO+XQRi/+nKNkEt+jBb4=; b=0dMmVkPCqwuV3j9CNZUk2up9hW6YJ6neGV6pRebZwJr+3MqIgiUG+FTqPhIoRdWBAK GLtCkJCkZjusJBRUXW6ZjPQ00nQU4dCGJlV0Z5y3kxHlNNk+oQ05LONcjurejVJ6nGVr UP2BDjDwPRYJDISD6rN3N+6nRuR7n+FO6OfWt78RXe30JgWhAV3ep0vKa4HfRucxHGJg 5iT9qQ01Q8VZeacvzODUyxQGg9RK7udyplzQh8xF0OX3WckGAZQ5LlbBeRF9DVVKHrCV W/MJgFAjb8/JYkgkPWiO2xXLmkE4atfFiq4DWHvxHdmuz8zid/Pn2rMqw6nahFAlolqi Od+A== X-Received: by 10.220.219.9 with SMTP id hs9mr6936787vcb.68.1360336639628; Fri, 08 Feb 2013 07:17:19 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id h11sm42509919vdj.12.2013.02.08.07.17.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 07:17:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: RJ Atkinson In-Reply-To: <51150D5B.4010907@gmail.com> Date: Fri, 8 Feb 2013 10:17:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> To: ipv6@ietf.org 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: Fri, 08 Feb 2013 15:17:21 -0000 On 08 Feb 2013, at 09:36 , Brian E Carpenter wrote: > Me too. TCP is also an encapsulating header; its contents > just don't happen to be encrypted. The draft's definition > of "Entire IPv6 header chain" uses TCP as an example: >=20 > Note: If there is an upper layer header, only the header (and > not its payload) are considered part of the "entire IPv6 = header > chain". For example, if the upper layer protocol is TCP, only > the TCP header (and not its possible data bytes) should be > considered part of the "entire IPv6 header chain". >=20 > but I don't think it would be any different for ESP. >=20 > However, I do see one point that is under-defined right now: >=20 > **How many bytes of the transport header+payload are included in this = definition?** >=20 > For ESP, is it 8 bytes (SPI + Sequence Number)? I think that would be OK. Certainly it MUST NOT be more than those 8 bytes, because beyond there lies encrypted bits (in the general case). =20 I actually believe that the SPI alone would suffice for ESP. > For TCP, is it 8 bytes (ports + Sequence Number)? My own sense is that Source Port and Destination Port, so 32 bits, actually would suffice, but I'll at least=20 note one possible counter-argument: A firewall implementation might want to look=20 at the TCP flags to check for invalid flag=20 combinations. For UDP, my own sense is that the first 32 bits would suffice, although I don't see any harm in including the first 64 bits. I would have no objection to Fernando adding more detail for the obvious terminating payloads (e.g. UDP, TCP, SCTP, ICMP, ESP) to the draft. Adding more clarity about this to the I-D could not hurt,=20 and might help some implementers. Yours, Ran From despres.remi@laposte.net Fri Feb 8 07:51: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 B15BA21F8AA3 for ; Fri, 8 Feb 2013 07:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK64rjhPbOBf for ; Fri, 8 Feb 2013 07:51:23 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDF221F8AB4 for ; Fri, 8 Feb 2013 07:51:21 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 49F1E7000092; Fri, 8 Feb 2013 16:51:20 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id EF36570000BD; Fri, 8 Feb 2013 16:51:19 +0100 (CET) X-SFR-UUID: 20130208155119979.EF36570000BD@msfrf2421.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <20130208.115910.200301799.he@uninett.no> Date: Fri, 8 Feb 2013 16:51:19 +0100 Message-Id: <7C04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net> References: <20130208.105139.78750204.sthaug@nethelp.no> <20130208.115910.200301799.he@uninett.no> To: Havard Eidnes X-Mailer: Apple Mail (2.1499) 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 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 15:51:25 -0000 Le 2013-02-08 =E0 11:59, Havard Eidnes a =E9crit : >>> However, there is nothing which enforces RFC4291-conforming IIDs for >>> (for instance) statically configured IPv6-addresses. >>> So in what way do >>> well defined u/g values for RFC4291-conforming IIDs help you? >>=20 >> 1. >> Users that manually configure their IPv6 addresses should be >> knowledgeable about what they do. >>=20 >> If one configures an address has u=3Dg=3D1, unless it is for an >> experiment, it is a human mistake (it conflicts with the IPv6 >> addressing architecture of RFC 4291). Depending on the context, >> this mistake will have no consequence or will eventually have >> to be corrected. >=20 > What's the operational failure mode? Does it fail in a way which > would be obvious to the ones who has made this mistake, or will > simply some seemingly-random pairs of hosts fail to communicate? > I think it would be an engineering mistake to willfully create > hard-to-detect failure scenarios via a modification to already > fielded standards. FULL AGREEMENT that we don't want to modify any "already fielded = standard". If you believe such a change is needed for 4rd, PLEASE EXPLAIN.=20 If one configures an address that doesn't follow configuration = constraints, it may fail in various ways, but under its own = responsibility. For instance, if it has the wrong subnet prefix, it won't be reachable = from across the Internet, like what may happen if it has a = non-RFC4291-complying IID that happens to be in the 4rd reserved range = in a site where 4rd is activated. >=20 >> Note that, even if one does such a mistake in a 4rd site, the >> likelihood of using the 4rd IID prefix 0x0300 remains low. >=20 > That's a nice handwave... This is a fact, worth noting IMHO, especially since the particular = example of a non RFC4291-compliant address Ole gave didn't conflict with = 4rd. Your lack of interest for this point doesn't justify, IMHO, a so = depreciating comment.=20 >> 2. >> On my home network, I know nobody is doing manual configuration. >=20 > That doesn't really prove anything. It doesn't prove anything, OK, and wasn't BTW claimed to prove anything = in particular. Yet, the risk of manual misconfigurations that may conflict with the RFC = 4291, which is indeed a risk, is mitigated by the fact that manual = address configuration is AFAIK more an exception than a general = practice. =20 Regards, RD >=20 > Regards, >=20 > - H=E5vard From despres.remi@laposte.net Fri Feb 8 07:58: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 CB83621F8A6E for ; Fri, 8 Feb 2013 07:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajPMQA7PZYRL for ; Fri, 8 Feb 2013 07:58:44 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 28F3621F8A5E for ; Fri, 8 Feb 2013 07:58:43 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 8EA3E70000BD; Fri, 8 Feb 2013 16:58:42 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 7753470000AC; Fri, 8 Feb 2013 16:58:42 +0100 (CET) X-SFR-UUID: 20130208155842488.7753470000AC@msfrf2421.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5114DCB6.5060201@kit.edu> Date: Fri, 8 Feb 2013 16:58:42 +0100 Message-Id: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> <5113DE3A.6090605@dougbarton.us> <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> <5114DCB6.5060201@kit.edu> To: Roland Bless X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 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: Fri, 08 Feb 2013 15:58:44 -0000 Le 2013-02-08 =E0 12:08, Roland Bless a =E9crit : > Hi, >=20 > On 08.02.2013 09:31, R=E9mi Despr=E9s wrote: >=20 >> Hosts of an IPv6 customer site can have IPv6 addresses assigned, with >> SLAAC or DHCPv6, BEFORE 4rd is activated. >=20 >> If these addresses become in conflict with the CE 4rd address when >> 4rd is activated, renumbering becomes necessary. The objective (*) >> isn't satisfied. (Reason why the CE itself cannot take another >> address is because this address must be *algorithmically derived* >> from an a IPv4 destination by other CEs.) >=20 > Maybe I don't get it, but it seems that mixed usage of non-4rd hosts > and 4rd hosts in the same subnet is not easily possible, since 4rd > cannot use different IIDs than the algorithmically derived ones. > So conflicts are hopefully detected, but cannot be resolved. There isn't such thing than a 4rd host. There are only 4rd CEs (customer-edge routers) in which IPv4-in-IPv6 = tunnels are terminated. > This seems to suggest that you better use a different 4rd = subnet-prefix > when configuring 4rd use so that all nodes in this 4rd subnet-prefix > use the same method to derive their IID and you avoid conflicts > with other hosts. Wouldn't it be possible to use those two subnets in > parallel, then there would be no need to renumber existing hosts. Using a 4rd-specific subnet prefix may impose some renumbering when 4rd = is activated, which is contrary to our objective.=20 (This prefix, needing to be automatically configured, cannot depend on = which subnet prefixes are have been used before 4rd activation.) Regards, RD >=20 > Regards, > Roland >=20 From randy@psg.com Fri Feb 8 09:18: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 2AEF321F86E8 for ; Fri, 8 Feb 2013 09:18:48 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6JnzywrtxRQ for ; Fri, 8 Feb 2013 09:18:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9033421F876E for ; Fri, 8 Feb 2013 09:18:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3rb2-0000s6-2Z for ipv6@ietf.org; Fri, 08 Feb 2013 17:18:44 +0000 Date: Fri, 08 Feb 2013 09:18:43 -0800 Message-ID: From: Randy Bush To: IPv6 Deployment Prevention Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] In-Reply-To: References: <510B790D.8010301@gmail.com> <510C21D9.2020506@si6networks.com> <510C60B1.4060401@joelhalpern.com> <510CCFE4.6090506@gmail.com> <510D4A3B.6000509@joelhalpern.com> <6F610921-2041-4436-9160-CE537E31BB2E@laposte.net> <510E4D7C.5020307@gmail.com> <954FE2BB-69DB-4214-9696-0BA3DF6CF346@laposte.net> <510FF1F0.3030903@dougbarton.us> <92B7D8D3-3406-44D5-9802-8320AE32A62C@laposte.net> <51119983.4050403@dougbarton.us> <11775F89-FC81-450B-88D3-02C6AB07A444@laposte.net> <5113DE3A.6090605@dougbarton.us> <7F84B0B4-A103-49A2-8242-DB6C79EAAE1D@laposte.net> <5114DCB6.5060201@kit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII 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, 08 Feb 2013 17:18:48 -0000 folk, can we stop beating the horse? everyone but the horse knows it is dead. and the bits of spattered horse are consuming significant energy better spent on productive work. randy From dmudric@avaya.com Fri Feb 8 10:12: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 E566A21F8A96 for ; Fri, 8 Feb 2013 10:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QniF+60HQ1+U for ; Fri, 8 Feb 2013 10:12:54 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4541721F882A for ; Fri, 8 Feb 2013 10:12:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJoQA1HGmAcF/2dsb2JhbABCA4JII7tnFnOCIAEBAwwGFQZeARUVFgE/JgEEGxMHh20BC50uhCqcdI4Rgk1hA5waijuCd4Ik X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208,217";a="388029717" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Feb 2013 13:12:09 -0500 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Feb 2013 13:11:37 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Fri, 8 Feb 2013 13:12:50 -0500 From: "Mudric, Dusan (Dusan)" To: "ipv6@ietf.org" Subject: IPv6 Address Resolution in Linux 2.6.27 Thread-Topic: IPv6 Address Resolution in Linux 2.6.27 Thread-Index: Ac4GJ+8UAeS56CLDTka3IP0LEU5Aaw== Date: Fri, 8 Feb 2013 18:12:50 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E45384AEAD9@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E45384AEAD9AZUS1EXMB03glob_" 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, 08 Feb 2013 18:12:56 -0000 --_000_9142206A0C5BF24CB22755C8EC422E45384AEAD9AZUS1EXMB03glob_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, I experience Address Resolution problem while using Linux 2.6.27. A and B use global IPv6 addresses. * 2009::6:173 - 'A' global address (the capture monitors its port) * 2009::6:172 - 'B' global address Both A and B are about 8 seconds in the reachable states (STALE / DELAY / P= ROBE) with full audio, and then ~30 seconds in the INCOMPLETE state. This h= appens periodically. Media behavior when phones talk P2P: RTP directions # reference packet Starting time Time diff [seconds] 172 <- -> 173 940 13.5 - 172 -> 173 1779 21.5 8 172 <- -> 173 4134 63.9 42 172 -> 173 4983 71.9 8 172 <- -> 173 7361 114.3 42 172 -> 173 8211 122.4 8 I added debug info in net\ipv6\ndisc.c ndisc_recv_na() to print src and dst= IPs. I added debug info in neigh_update() to print LL address and a new state I enabled NEIGH_PRINTKx and ND_PRINTKx Observations: 1. 173 discover and lose 172 address in periodic manner - 8 / 42 / 8 / 4= 2 / ... 2. When 173 loses 172 (and when it gets it again) we see ICMPv6 traffic:= NS from 173 to 172 and NA from 172 to 173 * During the time 173 can't reach 172 there are ICMPv6 NS messages = from 173 and NA to 173. 173 ndisc_recv_na() is not called. NAs are silently= discarded somewhere. At the same time, 173 neighbor cache entry does not f= ollow the RFC4861. neigh_update() state changes from INCOMPLETE to STALE do= DELAYED after the first timeout. It should stay in INCOMPLETE. From DELAYE= D state it goes to PROBE which is allowed by RFC. It stays in PROBE for 3se= c (3 NS retransmissions) and goes to FAILED state. 2sec later is send NS ag= ain and goes into DELAYED state. 3. NDP: a. 172 sends only 3 solicitation request for 173 during the capture peri= od, while 173 sends solicitation to 172 every second b. 173 reach 172 only after 172 sends advertisement to 173' LL address (= not the global one and without the "override" flag) Q: Is this a known problem? If yes, is there a patch for it? Regards, Du=B9an Mudri=E6 Software Architect Endpoints & Video Solutions Avaya Global Communication Systems Telephone: (613) 595-9045 425 Legget Drive, Ottawa, Ontario, K2K 2W2 "I have always believed, and I still believe, that whatever good or bad for= tune may come our way, we can always give it meaning and transform it into = something of value." - Hermann Hesse --_000_9142206A0C5BF24CB22755C8EC422E45384AEAD9AZUS1EXMB03glob_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I experience Address R= esolution problem while using Linux 2.6.27.

 

A and B use global IPv= 6 addresses.

·      &= nbsp;  2009::6:173 &#= 8211; ‘A’  global address (the capture monitors its port)<= o:p>

·      &= nbsp;  2009::6:172 &#= 8211; ‘B’ global address

 

Both A and B are about= 8 seconds in the reachable states (STALE / DELAY / PROBE) with full audio,= and then ~30 seconds in the INCOMPLETE state. This happens periodically.

 

Media behavior when ph= ones talk P2P:

RTP directions<= span style=3D"font-size:10.0pt;font-family:"Bookman Old Style",&q= uot;serif";color:green">

# reference packet

Starting time

Time diff [seconds]

172 <- -> 173

940

13.5

-

172    =  -> 173

1779

21.5

8

172 <- -> 173

4134

63.9

42

172    =  -> 173

4983

71.9

8

172 <- -> 173

7361

114.3<= /span>

42

172    =  -> 173

8211

122.4<= /span>

8

 

I added debug info in net\ipv6\ndisc.c ndisc_recv_na() to print src and dst IPs.

I added debug info in neigh_update() to print LL address and a new stat= e

I enabled NEIGH_PRINTKx and ND_PRINTKx

 

Observations:

1.&n= bsp;   173 discover a= nd lose 172 address in periodic manner – 8 / 42 / 8 / 42 / …

2.&n= bsp;   When 173 loses= 172 (and when it gets it again) we see ICMPv6 traffic: NS from 173 to 172 = and NA from 172 to 173

·         During the time 173 can’t reach 17=
2 there are ICMPv6 NS messages from 173 and NA to 173. 173 ndisc_recv_na() =
is not called. NAs are silently discarded somewhere. At the same time, 173 =
neighbor cache entry does not follow the RFC4861. neigh_update() state chan=
ges from INCOMPLETE to STALE do DELAYED after the first timeout. It should =
stay in INCOMPLETE. From DELAYED state it goes to PROBE which is allowed by=
 RFC. It stays in PROBE for 3sec (3 NS retransmissions) and goes to FAILED =
state. 2sec later is send NS again and goes into DELAYED state.

3.&n= bsp;   NDP:

a. &nbs= p;  172 sends only= 3 solicitation request for 173 during the capture period, while 173 sends = solicitation to 172 every second

b. &nbs= p;  173 reach 172 = only after 172 sends advertisement to 173’ LL address (not the global= one and without the “override” flag)

 

Q: Is this a known pro= blem? If yes, is there a patch for it?

Regards,

Du=B9an Mudri=E6

Software Architect<= /o:p>

Endpoints & Video So= lutions

Avaya Global Communicati= on Systems

Telephone: (613) 595-9045
425 Legget Drive, Ottawa, Ontario, K2K 2W2

 

"I have always= believed, and I still believe, that whatever good or bad fortune may come = our way, we can always give it meaning and transform it into something of value." — Hermann Hesse

 

--_000_9142206A0C5BF24CB22755C8EC422E45384AEAD9AZUS1EXMB03glob_-- From Fred.L.Templin@boeing.com Fri Feb 8 10:17: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 DE67721F8BAB for ; Fri, 8 Feb 2013 10:17:00 -0800 (PST) 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=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtpfjjhFa302 for ; Fri, 8 Feb 2013 10:16:59 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 99DAE21F8B9F for ; Fri, 8 Feb 2013 10:16:59 -0800 (PST) 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 r18IGxBu002062 for ; Fri, 8 Feb 2013 10:16:59 -0800 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r18IGvi7002047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 8 Feb 2013 10:16:58 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 8 Feb 2013 10:16:57 -0800 From: "Templin, Fred L" To: Fernando Gont Date: Fri, 8 Feb 2013 10:16:57 -0800 Subject: RE: Feedback on draft-generic-6man-tunfrag-07 Thread-Topic: Feedback on draft-generic-6man-tunfrag-07 Thread-Index: Ac4F5XW3svRlbKLOTl6epuE5+TQz7gAOCU+g Message-ID: References: <5114D079.8040103@si6networks.com> In-Reply-To: <5114D079.8040103@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No 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, 08 Feb 2013 18:17:01 -0000 Hi Fernando, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: Friday, February 08, 2013 2:16 AM > To: fltemplin@acm.org > Cc: ipv6@ietf.org > Subject: Feedback on draft-generic-6man-tunfrag-07 >=20 > Hi, Fred, >=20 > Sorry for the delay in providing comments (as promised). Here they are: Thank you for taking the time to read and comment. Please see below for follow-ups: > Section 2: >=20 > > The current "Internet cell size" is effectively 1500 bytes, i.e., th= e > > minimum MTU configured by the vast majority of links in the Internet= . > > IPv6 constrains this even further by specifying a minimum link MTU o= f > > 1280 bytes [RFC2460]. However, due to operational issues with Path > > MTU Discovery (PMTUD) [RFC1981] these sizes can often only be > > accommodated when links with smaller link-layer segment sizes are > > configured to perform link adaptation. >=20 > We could probably add some references regarding PMTUD issues in IPv6 > (some folks think/thought/expected them to be gone with v6... but they > are not) -- found them later... could you move them to this para? Yes, absolutely. The studies by Matthew Luckie and his colleagues would fit in here, as would the reference you cited below. > > Unfortunately, link adaptation can present a significant burden to > > the link endpoints, i.e., especially when the link supports high dat= a > > rates and/or is located nearer the "middle" of the network instead o= f > > nearer the "edge". An alternative therefore is to ask the > > originating IPv6 node to perform fragmentation on the packets it > > sends, in which case reassembly would be performed by the final > > destination. >=20 > This is okay, but.. in the previous para, you started with the premise > that you have to rely on link-adaptation as a result of PMTUD failures, Link adaptation is not necessarily as a result of PMTUD failures. We already know that, for IPv6, link adaptation is a MUST if the link MTU is smaller than 1280. What I am saying is that some links may wish to set an even larger link adaptation threshold (say 1500) under the presumption that PMTUD *might* fail. =20 > so.... if ICMPv6 PTB are going to be blocked, how an you expect the > sources to fragment their packets? (i.e., receive the corresponding > signal) The ICMPv6 PTB messages I am proposing would be advisory in nature and not an indication of packet loss. So, delivery of the PTB's to the source is best-effort, and loss of the messages would not result in a black hole. It is just that the link would need to continue to work hard if the messages either don't get delivered to the source or are ignored by the source.=20 > Section 3: >=20 > > > > This document does not propose to change these requirements, but > > notes that link adaptation can be burdensome for some links to the > > point that it would be highly desirable to push the fragmentation an= d > > reassembly responsibility to the IPv6 communication endpoints. In > > order to accommodate this, when the router at the link ingress > > performs link adaptation on a packet it should also send an ICMPv6 > > PTB message back to the original source (subject to rate limiting) > > with a Next-Hop MTU less than 1280 and with Code field set to 1 > > [RFC4443]. (Note that these PTB messages are advisory in nature and > > do not necessarily indicate packet loss.) >=20 > Some implementations validate ICMP error messages based on > connection-progress (please see RFC 5927)-- in v6 this is as good as it > can get, since you might not even receive the eg TCP header in the > ICMPv6 payload. I'm curious as to what you mean by this. ICMPv6 PTB messages are mandated to include "As much of (the) invoking packet as possible". Has this not proven to be the case in operational practice? Or, are you saying that the TCP header is sometimes not available in-the-clear, e.g., if IP security is applied? > Since you'd be both sending an error *and* performing > link adaptation, the connection would progress, and hence such > implementations would drop the ICMPv6 message. The system will still work if the source drops the ICMPv6 PTB message - it's just that the system would work *better* if the source would heed the message as specified in this document. > -- workaround: keep track > of whether the other endpoint reduces the size of its packets. If it > doesn't, try "drop & send ICMPv6 PTB". (and yes, if packets stop > flowing, you should assume there's a PMTUD blackhole) It would be too much to ask for the link adaptation endpoint to keep track of all of the sources and observe their behavior. > Section 3: >=20 > > "In response to an IPv6 packet that is sent to a destination located > > beyond an IPv6 link that must perform link adaptation, the > > originating IPv6 node may receive an ICMP Packet Too Big message > > reporting a Next-Hop MTU less than 1280 and with Code=3D1. In that > > case, the IPv6 node is not required to reduce the size of subsequent > > packets to less than 1500 bytes, but must perform IPv6 fragmentation > > on those packets by breaking the packet into N roughly equal-length > > pieces (where N is minimized and the length of each piece is smaller > > than the Next-Hop MTU). These fragments will be reassembled by the > > destination." >=20 > I guess you meant "1280" rather than 1500? No, I actually meant 1500 bytes. This is the minimum-sized reassembly buffer that the destination is required to configure per RFC2460. So, this is the maximum size for which the source can expect the destination to perform reassembly unless it has some way of knowing that the destination is capable of reassembling more. > That aside: the text is a bit confusing. what's should be the maximum > size of each fragment? The one reported by the ICMPv6 PTB code 1? Each piece must be smaller than the Next-Hop MTU as reported by the ICMPv6 PTB message, and the source must also minimize the number of pieces it sends. =20 > Section 4: > > Regardless of whether there is a link in the path that performs link > > adaptation, when an originating IPv6 node receives a PTB message > > reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node > > need not reduce the size of the packets it sends. The node may > > instead invoke fragmentation for packets between 1281 and 1500 bytes > > (again, by splitting the packet into N roughly equal-length pieces) > > before submitting each fragment for link-layer framing. These > > fragments will be reassembled by the final destination >=20 > Why don't you want the packet size to be reduced in this case? That > aside, if you're fragmenting the packets, you're reducing their size.... > so I don't get why the text says "need not reduce..." Again, this is leveraging the fact that all IPv6 nodes are required to reassemble 1500 bytes at a minimum. It is up to the source whether it would be better served to reduce the size of its packets to something smaller than 1500 bytes or to perform fragmentation and let the destination perform reassembly. But, I get your point about confusing wording so here is a proposed re-write: "...when an originating IPv6 node receives a PTB message reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node can reduce the size of the packets it sends as specified in RFC1981. Alternatively, the node can invoke fragmentation for packets that are larger than the Next-Hop MTU value but no larger than 1500 bytes, since IPv6 destinations are required to reassemble at least that much [RFC2460= ]." =20 > Section 4: > > A more interesting situation arises when PTB messages are lost on th= e > > return path to the originating IPv6 node. Since the node has no way > > of discerning which paths may exhibit this condition, it may be > > better served to assume the worst case for all paths and take > > precautionary measures to avoid silent packet loss. For example, an > > originating IPv6 node that wishes to ensure that packets between 128= 1 > > and 1500 bytes will reach the final destination can use "proactive > > fragmentation" to fragment each packet (again, by splitting the > > packet into N roughly equal-length pieces). >=20 > Fragmentation is not a panacea. Please check the recent discussion on > v6ops regarding IPv6 fragment filtering, and > thesis.pdf>. That is worrisome. I don't understand that, if an IPv6 destination is required to reassemble at least 1500 bytes, that middleboxes in the network would prevent it from doing so. This seems to be even more broken than the failure of the network to deliver ICMPv6 PTB messages. If these core features don't work as advertised, can we really ever expect to do anything better than 1280?=20 > > 6. IANA Considerations > > > > There are no IANA considerations for this document. >=20 > Of the top of my head: Aren't you specifying a new Code value for ICMPv6 > PTB? -- Then it looks like you do have actions for IANA. >=20 >=20 > Important item: At the end of the day, you're somehow saying that the > IPv6 minimum MTU is no longer 1280 -- but not explicitly. So this should > be made explicit (yes, yes.. "controversial"... but I like to call a > lemon a lemon :-) ). What I would like to say is that the IPv6 minimum MTU size should be bounded by the IPv6 minimum reassembly size (which is 1500 bytes) instead of bounded by some curious constant value such as 1280. Packets larger than 1500 bytes are also possible when the IPv6 source uses RFC4821, but these packets would be delivered without fragmentation if they are delivered at all. > -- FWIW, some folks have already noted that the > hassle of having to do link adaptation, and v6-enabled links failing to > to that (I have always been for references on this topic, though). I think 6lowpan (RFC4944) might be one example? Thanks - Fred fred.l.templin@boeing.com > Thanks! >=20 > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kauer@biplane.com.au Fri Feb 8 10:27: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 50BCC21F8B65 for ; Fri, 8 Feb 2013 10:27:04 -0800 (PST) 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.050, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJRU72PE+MAM for ; Fri, 8 Feb 2013 10:27:02 -0800 (PST) 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 E6EE321F8B1C for ; Fri, 8 Feb 2013 10:26:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkDAONCFVGWZX+7/2dsb2JhbAANOMAAAoEfgxIBAQEDAYEJCxgdEVcZiAurU5MpjiATgykDiDCZN4gk 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; 09 Feb 2013 04:56:57 +1030 Message-ID: <1360348016.4381.23.camel@karl> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Karl Auer To: ipv6@ietf.org Date: Sat, 09 Feb 2013 05:26:56 +1100 In-Reply-To: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.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: Fri, 08 Feb 2013 18:27:05 -0000 On Fri, 2013-02-08 at 08:38 -0500, RJ Atkinson wrote: > On Friday 8th Feb 2013, Karl Auer wrote, in part: > > Do you mean that the ESP header must be the first item in the > > fragmentable part of the first fragment? Or that the ESP header > > must be (at least partly) in the non-fragmentable part of the > > first fragment? I had completely misunderstood what the person I was replying to meant. There was a third option which Fernando put admirably clearly later, i.e., simply that the beginning of the ESP header had to be in the first fragment. How much of the beginning of te ESP header needs to be present in the first fragment is, as you pointed out, a good question. The following explanation is thus pretty pointless, but just for laughs: > > If the latter, that's a new kind of animal. > > Not at all. I was (erroneously) imagining that someone was suggesting that some part of the ESP header should precede the fragment header in the first fragment (i.e., in the non-fragmentable part), with some part of the rest of the ESP header following in the fragmentable part. That would definitely be a new animal :-) > > part. Permitting a header to straddle the fragment header > > seems odd, > > It is already the normal case for ESP. At present, > ESP might be partly in a first fragment, split between > two fragments, or entirely in a non-first fragment. Sure - but the ESP header never straddles a fragment header. The fragment header, if present, is always the last thing in the non-fragmentable part. I was imagining a scenario where this was no longer the case. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog 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 swmike@swm.pp.se Fri Feb 8 10:32: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 A630621F8BD9 for ; Fri, 8 Feb 2013 10:32:18 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p6U1OuhfCTM for ; Fri, 8 Feb 2013 10:32:17 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D508321F8BB0 for ; Fri, 8 Feb 2013 10:32:15 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0AE219C; Fri, 8 Feb 2013 19:32:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 054419A; Fri, 8 Feb 2013 19:32:14 +0100 (CET) Date: Fri, 8 Feb 2013 19:32:14 +0100 (CET) From: Mikael Abrahamsson To: "Mudric, Dusan (Dusan)" Subject: Re: IPv6 Address Resolution in Linux 2.6.27 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E45384AEAD9@AZ-US1EXMB03.global.avaya.com> Message-ID: References: <9142206A0C5BF24CB22755C8EC422E45384AEAD9@AZ-US1EXMB03.global.avaya.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 08 Feb 2013 18:32:24 -0000 On Fri, 8 Feb 2013, Mudric, Dusan (Dusan) wrote: > Q: Is this a known problem? If yes, is there a patch for it? I believe this is not the correct list for asking these questions. The linux netdev is probably more suitable place to ask linux specific questions. Then again, I doubt you'll get much enthusiasm there to fault find a kernel that was released in october 2008. -- Mikael Abrahamsson email: swmike@swm.pp.se From fgont@si6networks.com Fri Feb 8 13:21: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 0510F21F8C38 for ; Fri, 8 Feb 2013 13:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYwU4XzcULkp for ; Fri, 8 Feb 2013 13:21:03 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9521F8C1F for ; Fri, 8 Feb 2013 13:21:02 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3vMf-0003LJ-M6; Fri, 08 Feb 2013 22:20:33 +0100 Message-ID: <51156BFC.4070201@si6networks.com> Date: Fri, 08 Feb 2013 18:19:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Feedback on draft-generic-6man-tunfrag-07 References: <5114D079.8040103@si6networks.com> In-Reply-To: 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: Fri, 08 Feb 2013 21:21:04 -0000 On 02/08/2013 03:16 PM, Templin, Fred L wrote: >>> Unfortunately, link adaptation can present a significant burden to >>> the link endpoints, i.e., especially when the link supports high data >>> rates and/or is located nearer the "middle" of the network instead of >>> nearer the "edge". An alternative therefore is to ask the >>> originating IPv6 node to perform fragmentation on the packets it >>> sends, in which case reassembly would be performed by the final >>> destination. >> >> This is okay, but.. in the previous para, you started with the premise >> that you have to rely on link-adaptation as a result of PMTUD failures, > > Link adaptation is not necessarily as a result of PMTUD failures. > We already know that, for IPv6, link adaptation is a MUST if the > link MTU is smaller than 1280. What I am saying is that some links > may wish to set an even larger link adaptation threshold (say 1500) > under the presumption that PMTUD *might* fail. That wasn't what I got in my first read of the document (at least). WOuld it be possible to clarify that? >>> This document does not propose to change these requirements, but >>> notes that link adaptation can be burdensome for some links to the >>> point that it would be highly desirable to push the fragmentation and >>> reassembly responsibility to the IPv6 communication endpoints. In >>> order to accommodate this, when the router at the link ingress >>> performs link adaptation on a packet it should also send an ICMPv6 >>> PTB message back to the original source (subject to rate limiting) >>> with a Next-Hop MTU less than 1280 and with Code field set to 1 >>> [RFC4443]. (Note that these PTB messages are advisory in nature and >>> do not necessarily indicate packet loss.) >> >> Some implementations validate ICMP error messages based on >> connection-progress (please see RFC 5927)-- in v6 this is as good as it >> can get, since you might not even receive the eg TCP header in the >> ICMPv6 payload. > > I'm curious as to what you mean by this. ICMPv6 PTB messages are > mandated to include "As much of (the) invoking packet as possible". > Has this not proven to be the case in operational practice? Or, are > you saying that the TCP header is sometimes not available in-the-clear, > e.g., if IP security is applied? I'm saying that, at least theoretically speaking, such header might not be there. Even if a node complies with draft-ietf-6man-oversized-header-chain (and e.g. puts lots of extension headers and then the tcp header in the first frag), when an error is elicited, the tcp header might need to be left out. That said, some implementations check for progress on the connection before honoring ICMPv6 PTB -- which means such implementations would drop the ICMPv6 PTB your proposing. >> Since you'd be both sending an error *and* performing >> link adaptation, the connection would progress, and hence such >> implementations would drop the ICMPv6 message. > > The system will still work if the source drops the ICMPv6 PTB > message - it's just that the system would work *better* if the > source would heed the message as specified in this document. Agreed. Just wanted to point this one out, since I don't know whether you had considered it. -- it might be worth a para. >> -- workaround: keep track >> of whether the other endpoint reduces the size of its packets. If it >> doesn't, try "drop & send ICMPv6 PTB". (and yes, if packets stop >> flowing, you should assume there's a PMTUD blackhole) > > It would be too much to ask for the link adaptation endpoint to > keep track of all of the sources and observe their behavior. Agreed. > > Section 3: >> >>> "In response to an IPv6 packet that is sent to a destination located >>> beyond an IPv6 link that must perform link adaptation, the >>> originating IPv6 node may receive an ICMP Packet Too Big message >>> reporting a Next-Hop MTU less than 1280 and with Code=1. In that >>> case, the IPv6 node is not required to reduce the size of subsequent >>> packets to less than 1500 bytes, but must perform IPv6 fragmentation >>> on those packets by breaking the packet into N roughly equal-length >>> pieces (where N is minimized and the length of each piece is smaller >>> than the Next-Hop MTU). These fragments will be reassembled by the >>> destination." >> >> I guess you meant "1280" rather than 1500? > > No, I actually meant 1500 bytes. This is the minimum-sized reassembly > buffer that the destination is required to configure per RFC2460. So, > this is the maximum size for which the source can expect the destination > to perform reassembly unless it has some way of knowing that the > destination is capable of reassembling more. > >> That aside: the text is a bit confusing. what's should be the maximum >> size of each fragment? The one reported by the ICMPv6 PTB code 1? > > Each piece must be smaller than the Next-Hop MTU as reported by the > ICMPv6 PTB message, and the source must also minimize the number of > pieces it sends. But then you *are* reducing the size of your packets (the text says "is not required..."). Or am I missing something? May be you mean "is not required to reduce the assumed path mtu"? > >> Section 4: >>> Regardless of whether there is a link in the path that performs link >>> adaptation, when an originating IPv6 node receives a PTB message >>> reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node >>> need not reduce the size of the packets it sends. The node may >>> instead invoke fragmentation for packets between 1281 and 1500 bytes >>> (again, by splitting the packet into N roughly equal-length pieces) >>> before submitting each fragment for link-layer framing. These >>> fragments will be reassembled by the final destination >> >> Why don't you want the packet size to be reduced in this case? That >> aside, if you're fragmenting the packets, you're reducing their size.... >> so I don't get why the text says "need not reduce..." > [...] > > "...when an originating IPv6 node receives a PTB message > reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node > can reduce the size of the packets it sends as specified in RFC1981. > Alternatively, the node can invoke fragmentation for packets that are > larger than the Next-Hop MTU value but no larger than 1500 bytes, since > IPv6 destinations are required to reassemble at least that much [RFC2460]." Probably saying "..can reduce the assumed path mtu" (RFC1918-terminology IIRC) might make it even clearer? >> Section 4: >>> A more interesting situation arises when PTB messages are lost on the >>> return path to the originating IPv6 node. Since the node has no way >>> of discerning which paths may exhibit this condition, it may be >>> better served to assume the worst case for all paths and take >>> precautionary measures to avoid silent packet loss. For example, an >>> originating IPv6 node that wishes to ensure that packets between 1281 >>> and 1500 bytes will reach the final destination can use "proactive >>> fragmentation" to fragment each packet (again, by splitting the >>> packet into N roughly equal-length pieces). >> >> Fragmentation is not a panacea. Please check the recent discussion on >> v6ops regarding IPv6 fragment filtering, and >> > thesis.pdf>. > > That is worrisome. Yes. :-) > I don't understand that, if an IPv6 destination > is required to reassemble at least 1500 bytes, that middleboxes in > the network would prevent it from doing so. This seems to be even > more broken than the failure of the network to deliver ICMPv6 PTB > messages. If these core features don't work as advertised, can we > really ever expect to do anything better than 1280? I guess when it comes to packet size, something along the lines of < 1400 would generally work (i.e., the usual internet cell size, minus some bytes for possible tunnels). But it looks like as long as you need ICMPv6 PTB and/or fragmentation, you're in trouble. >>> 6. IANA Considerations >>> >>> There are no IANA considerations for this document. >> >> Of the top of my head: Aren't you specifying a new Code value for ICMPv6 >> PTB? -- Then it looks like you do have actions for IANA. >> >> >> Important item: At the end of the day, you're somehow saying that the >> IPv6 minimum MTU is no longer 1280 -- but not explicitly. So this should >> be made explicit (yes, yes.. "controversial"... but I like to call a >> lemon a lemon :-) ). > > What I would like to say is that the IPv6 minimum MTU size > should be bounded by the IPv6 minimum reassembly size (which is > 1500 bytes) instead of bounded by some curious constant value > such as 1280. I wasn't objecting at all -- for instance, at least at first thought, what you say makes sense to me. > Packets larger than 1500 bytes are also possible > when the IPv6 source uses RFC4821, but these packets would be > delivered without fragmentation if they are delivered at all. What if you need to send, say, a 5000 byte UDP datagram? >> -- FWIW, some folks have already noted that the >> hassle of having to do link adaptation, and v6-enabled links failing to >> to that (I have always been for references on this topic, though). > > I think 6lowpan (RFC4944) might be one example? To be honest, I haven't picked at 6lowpan, yet. Do they implement an adaptation layer, or they simply say "sorry, our minimum MTU is something smaller than 1280"? Cheers, -- 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 Fri Feb 8 13:42: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 5CC3821F8B9F for ; Fri, 8 Feb 2013 13:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJvELehuKGaA for ; Fri, 8 Feb 2013 13:42:27 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id C504D21F8B9B for ; Fri, 8 Feb 2013 13:42:27 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3vht-0003va-Kr; Fri, 08 Feb 2013 22:42:05 +0100 Message-ID: <51157129.5080209@si6networks.com> Date: Fri, 08 Feb 2013 18:42:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> In-Reply-To: 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: Fri, 08 Feb 2013 21:42:28 -0000 On 02/08/2013 12:17 PM, RJ Atkinson wrote: >> **How many bytes of the transport header+payload are included in this definition?** >> >> For ESP, is it 8 bytes (SPI + Sequence Number)? > > I think that would be OK. Certainly it MUST NOT be > more than those 8 bytes, because beyond there lies > encrypted bits (in the general case). Quickly skimming through RFC4303, it looks like the first 8 bytes of the ESP header are referred to as "header" (with the other being referred to as "payload" and "trailer").. so it looks like ESP wouldn't really be a "special case". Should we clarify "how many bytes are included" for ESP, nevertheless? > I actually believe that the SPI alone would suffice > for ESP. It probably would, but.. since the Seq # is part of the header, and it is also transmitted in plain text, I'd personally deal with ESP as with the general case "the entire ESP header" (IMO, the fewer the "special cases", the better). >> For TCP, is it 8 bytes (ports + Sequence Number)? > > My own sense is that Source Port and Destination Port, > so 32 bits, actually would suffice, but I'll at least > note one possible counter-argument: > A firewall implementation might want to look > at the TCP flags to check for invalid flag > combinations. In general, firewalls tend to look at many fields in the upper-layer header -- so it's useful to have it all. > I would have no objection to Fernando adding more > detail for the obvious terminating payloads > (e.g. UDP, TCP, SCTP, ICMP, ESP) to the draft. > > Adding more clarity about this to the I-D could not hurt, > and might help some implementers. Something that might make sense is to specify something along the lines of "if the size of the upper layer header is unknown (say, the upper layer protocol is implemented as a loadable module, in userland, or the like). Thoughts? 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 Fri Feb 8 13:51: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 F05F021F8BE2 for ; Fri, 8 Feb 2013 13:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwN6LG1VOQHt for ; Fri, 8 Feb 2013 13:51:20 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id C32C321F8BD4 for ; Fri, 8 Feb 2013 13:51:19 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3vqk-00049t-6L; Fri, 08 Feb 2013 22:51:15 +0100 Message-ID: <5115734D.8010307@si6networks.com> Date: Fri, 08 Feb 2013 18:51:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Mudric, Dusan (Dusan)" Subject: Re: IPv6 Address Resolution in Linux 2.6.27 References: <9142206A0C5BF24CB22755C8EC422E45384AEAD9@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E45384AEAD9@AZ-US1EXMB03.global.avaya.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 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: Fri, 08 Feb 2013 21:51:27 -0000 Hi, Dusan, On 02/08/2013 03:12 PM, Mudric, Dusan (Dusan) wrote: > · During the time 173 can’t reach 172 there are ICMPv6 NS > messages from 173 and NA to 173. 173 ndisc_recv_na() is not called. > NAs are silently discarded somewhere. At the same time, 173 neighbor > cache entry does not follow the RFC4861. neigh_update() state changes > from INCOMPLETE to STALE do DELAYED after the first timeout. It > should stay in INCOMPLETE. If at some point ND had been successful for such address, I think such entry should remain in the "STALE" state rather than move to INCOMPLETE (of the top of my head). > From DELAYED state it goes to PROBE which > is allowed by RFC. It stays in PROBE for 3sec (3 NS retransmissions) > and goes to FAILED state. 2sec later is send NS again and goes into > DELAYED state. > > 3. NDP: > > a. 172 sends only 3 solicitation request for 173 during the > capture period, while 173 sends solicitation to 172 every second > > b. 173 reach 172 only after 172 sends advertisement to 173’ LL > address (not the global one and without the “override” flag) > > Q: Is this a known problem? If yes, is there a patch for it? For this kind of scenario, it's usually helpful if you can provide a packet trace (e.g. tcpdump formated). That said, as noted by others the Linux netdev might be a better place to ask this question... or for instance, you might want to ask it on the ipv6hackers mailing-list: Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Fred.L.Templin@boeing.com Fri Feb 8 14:41: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 B78D121F8B4A for ; Fri, 8 Feb 2013 14:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QYrOSlU8af2 for ; Fri, 8 Feb 2013 14:41:47 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id AFC5A21F8B48 for ; Fri, 8 Feb 2013 14:41:47 -0800 (PST) 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 r18Mfl8a030284 for ; Fri, 8 Feb 2013 14:41:47 -0800 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r18Mfjtj030281 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 8 Feb 2013 14:41:46 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 8 Feb 2013 14:41:46 -0800 From: "Templin, Fred L" To: Fernando Gont Date: Fri, 8 Feb 2013 14:41:44 -0800 Subject: RE: Feedback on draft-generic-6man-tunfrag-07 Thread-Topic: Feedback on draft-generic-6man-tunfrag-07 Thread-Index: Ac4GQieaoB403ZZXRGmLKa8NERO3pQAAsHIw Message-ID: References: <5114D079.8040103@si6networks.com> <51156BFC.4070201@si6networks.com> In-Reply-To: <51156BFC.4070201@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No 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, 08 Feb 2013 22:41:48 -0000 Hi Fernando, > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Friday, February 08, 2013 1:20 PM > To: Templin, Fred L > Cc: ipv6@ietf.org > Subject: Re: Feedback on draft-generic-6man-tunfrag-07 >=20 > On 02/08/2013 03:16 PM, Templin, Fred L wrote: > >>> Unfortunately, link adaptation can present a significant burden to > >>> the link endpoints, i.e., especially when the link supports high > data > >>> rates and/or is located nearer the "middle" of the network instead > of > >>> nearer the "edge". An alternative therefore is to ask the > >>> originating IPv6 node to perform fragmentation on the packets it > >>> sends, in which case reassembly would be performed by the final > >>> destination. > >> > >> This is okay, but.. in the previous para, you started with the premise > >> that you have to rely on link-adaptation as a result of PMTUD failures= , > > > > Link adaptation is not necessarily as a result of PMTUD failures. > > We already know that, for IPv6, link adaptation is a MUST if the > > link MTU is smaller than 1280. What I am saying is that some links > > may wish to set an even larger link adaptation threshold (say 1500) > > under the presumption that PMTUD *might* fail. >=20 > That wasn't what I got in my first read of the document (at least). > WOuld it be possible to clarify that? Sure. I will write up a clarification in a new draft and post it along with the diff's. > >>> This document does not propose to change these requirements, but > >>> notes that link adaptation can be burdensome for some links to the > >>> point that it would be highly desirable to push the fragmentation > and > >>> reassembly responsibility to the IPv6 communication endpoints. In > >>> order to accommodate this, when the router at the link ingress > >>> performs link adaptation on a packet it should also send an ICMPv6 > >>> PTB message back to the original source (subject to rate limiting) > >>> with a Next-Hop MTU less than 1280 and with Code field set to 1 > >>> [RFC4443]. (Note that these PTB messages are advisory in nature > and > >>> do not necessarily indicate packet loss.) > >> > >> Some implementations validate ICMP error messages based on > >> connection-progress (please see RFC 5927)-- in v6 this is as good as i= t > >> can get, since you might not even receive the eg TCP header in the > >> ICMPv6 payload. > > > > I'm curious as to what you mean by this. ICMPv6 PTB messages are > > mandated to include "As much of (the) invoking packet as possible". > > Has this not proven to be the case in operational practice? Or, are > > you saying that the TCP header is sometimes not available in-the-clear, > > e.g., if IP security is applied? >=20 > I'm saying that, at least theoretically speaking, such header might not > be there. Even if a node complies with > draft-ietf-6man-oversized-header-chain (and e.g. puts lots of extension > headers and then the tcp header in the first frag), when an error is > elicited, the tcp header might need to be left out. Thanks - this clarifies. > That said, some implementations check for progress on the connection > before honoring ICMPv6 PTB -- which means such implementations would > drop the ICMPv6 PTB your proposing. It is OK if some implementations drop this "new kind" of PTB; correct operation will still result. It would be better however if those implementations were updated to honor the messages, and this can be done in an incremental deployment fashion. =20 > >> Since you'd be both sending an error *and* performing > >> link adaptation, the connection would progress, and hence such > >> implementations would drop the ICMPv6 message. > > > > The system will still work if the source drops the ICMPv6 PTB > > message - it's just that the system would work *better* if the > > source would heed the message as specified in this document. >=20 > Agreed. Just wanted to point this one out, since I don't know whether > you had considered it. -- it might be worth a para. Yes; I will add a paragraph that captures your above points. > >> -- workaround: keep track > >> of whether the other endpoint reduces the size of its packets. If it > >> doesn't, try "drop & send ICMPv6 PTB". (and yes, if packets stop > >> flowing, you should assume there's a PMTUD blackhole) > > > > It would be too much to ask for the link adaptation endpoint to > > keep track of all of the sources and observe their behavior. >=20 > Agreed. OK. > > Section 3: > >> > >>> "In response to an IPv6 packet that is sent to a destination > located > >>> beyond an IPv6 link that must perform link adaptation, the > >>> originating IPv6 node may receive an ICMP Packet Too Big message > >>> reporting a Next-Hop MTU less than 1280 and with Code=3D1. In tha= t > >>> case, the IPv6 node is not required to reduce the size of > subsequent > >>> packets to less than 1500 bytes, but must perform IPv6 > fragmentation > >>> on those packets by breaking the packet into N roughly equal-lengt= h > >>> pieces (where N is minimized and the length of each piece is > smaller > >>> than the Next-Hop MTU). These fragments will be reassembled by th= e > >>> destination." > >> > >> I guess you meant "1280" rather than 1500? > > > > No, I actually meant 1500 bytes. This is the minimum-sized reassembly > > buffer that the destination is required to configure per RFC2460. So, > > this is the maximum size for which the source can expect the destinatio= n > > to perform reassembly unless it has some way of knowing that the > > destination is capable of reassembling more. > > > >> That aside: the text is a bit confusing. what's should be the maximum > >> size of each fragment? The one reported by the ICMPv6 PTB code 1? > > > > Each piece must be smaller than the Next-Hop MTU as reported by the > > ICMPv6 PTB message, and the source must also minimize the number of > > pieces it sends. >=20 > But then you *are* reducing the size of your packets (the text says "is > not required..."). Or am I missing something? >=20 > May be you mean "is not required to reduce the assumed path mtu"? Yes - I think your statement is more accurate. I will fix it. > >> Section 4: > >>> Regardless of whether there is a link in the path that performs > link > >>> adaptation, when an originating IPv6 node receives a PTB message > >>> reporting a Next-Hop MTU value between 1280 and 1500 bytes, the > node > >>> need not reduce the size of the packets it sends. The node may > >>> instead invoke fragmentation for packets between 1281 and 1500 > bytes > >>> (again, by splitting the packet into N roughly equal-length pieces= ) > >>> before submitting each fragment for link-layer framing. These > >>> fragments will be reassembled by the final destination > >> > >> Why don't you want the packet size to be reduced in this case? That > >> aside, if you're fragmenting the packets, you're reducing their > size.... > >> so I don't get why the text says "need not reduce..." > > > [...] > > > > "...when an originating IPv6 node receives a PTB message > > reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node > > can reduce the size of the packets it sends as specified in RFC1981. > > Alternatively, the node can invoke fragmentation for packets that ar= e > > larger than the Next-Hop MTU value but no larger than 1500 bytes, > since > > IPv6 destinations are required to reassemble at least that much > [RFC2460]." >=20 > Probably saying "..can reduce the assumed path mtu" (RFC1918-terminology > IIRC) might make it even clearer? OK. =20 > >> Section 4: > >>> A more interesting situation arises when PTB messages are lost on > the > >>> return path to the originating IPv6 node. Since the node has no > way > >>> of discerning which paths may exhibit this condition, it may be > >>> better served to assume the worst case for all paths and take > >>> precautionary measures to avoid silent packet loss. For example, > an > >>> originating IPv6 node that wishes to ensure that packets between > 1281 > >>> and 1500 bytes will reach the final destination can use "proactive > >>> fragmentation" to fragment each packet (again, by splitting the > >>> packet into N roughly equal-length pieces). > >> > >> Fragmentation is not a panacea. Please check the recent discussion on > >> v6ops regarding IPv6 fragment filtering, and > >> >> thesis.pdf>. > > > > That is worrisome. >=20 > Yes. :-) Ok, but what can be done to fix it? > > I don't understand that, if an IPv6 destination > > is required to reassemble at least 1500 bytes, that middleboxes in > > the network would prevent it from doing so. This seems to be even > > more broken than the failure of the network to deliver ICMPv6 PTB > > messages. If these core features don't work as advertised, can we > > really ever expect to do anything better than 1280? >=20 > I guess when it comes to packet size, something along the lines of < > 1400 would generally work (i.e., the usual internet cell size, minus > some bytes for possible tunnels). I don't think even that is safe. We are entering an age where we will more and more see multiple levels of nested tunnels within tunnels where the innermost nesting levels will see progressively smaller MTUs. For example, RFC2473 tunnels invoke fragmentation when the tunnel nesting level becomes too deep to fit within the path MTU. Unfortunately, that can only be detected if PMTUD works. > But it looks like as long as you need ICMPv6 PTB and/or fragmentation, > you're in trouble. Then, links that perform link adaptation will have no way of offloading fragmentation and reassembly to the end systems. With working IPv6 frag/reas, we should be able to do better than that. > > >>> 6. IANA Considerations > >>> > >>> There are no IANA considerations for this document. > >> > >> Of the top of my head: Aren't you specifying a new Code value for > ICMPv6 > >> PTB? -- Then it looks like you do have actions for IANA. > >> > >> > >> Important item: At the end of the day, you're somehow saying that the > >> IPv6 minimum MTU is no longer 1280 -- but not explicitly. So this > should > >> be made explicit (yes, yes.. "controversial"... but I like to call a > >> lemon a lemon :-) ). > > > > What I would like to say is that the IPv6 minimum MTU size > > should be bounded by the IPv6 minimum reassembly size (which is > > 1500 bytes) instead of bounded by some curious constant value > > such as 1280. >=20 > I wasn't objecting at all -- for instance, at least at first thought, > what you say makes sense to me. OK, thanks. > > Packets larger than 1500 bytes are also possible > > when the IPv6 source uses RFC4821, but these packets would be > > delivered without fragmentation if they are delivered at all. >=20 > What if you need to send, say, a 5000 byte UDP datagram? The sender needs to know that the receiver can reassemble at least as much as 5000. It should then use IPv6 fragmentation to break the packet up into fragments no larger than 1280 and send each fragment to the receiver (another reason why IPv6 frag/reas *must* be fixed). =20 > >> -- FWIW, some folks have already noted that the > >> hassle of having to do link adaptation, and v6-enabled links failing t= o > >> to that (I have always been for references on this topic, though). > > > > I think 6lowpan (RFC4944) might be one example? >=20 > To be honest, I haven't picked at 6lowpan, yet. Do they implement an > adaptation layer, or they simply say "sorry, our minimum MTU is > something smaller than 1280"? Yes; RFC4944 specifies a link adaptation method for IPv6 over 6lowpan. Thanks - Fred fred.l.templin@boeing.com > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 From osmankh@yahoo.com Fri Feb 8 18:16: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 5A00821F8BE0 for ; Fri, 8 Feb 2013 18:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSJuVul-BEFB for ; Fri, 8 Feb 2013 18:16:50 -0800 (PST) Received: from nm21-vm0.bullet.mail.bf1.yahoo.com (nm21-vm0.bullet.mail.bf1.yahoo.com [98.139.213.137]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0DB21F8BDB for ; Fri, 8 Feb 2013 18:16:50 -0800 (PST) Received: from [98.139.212.145] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 09 Feb 2013 02:16:49 -0000 Received: from [98.139.173.162] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 09 Feb 2013 02:16:49 -0000 Received: from [127.0.0.1] by smtp105-mob.biz.mail.bf1.yahoo.com with NNFMP; 09 Feb 2013 02:16:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360376209; bh=699uYlUA1cQaGlUppNFOTRXRWrw/Y+ORmLDDqhqOJPU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Subject:Content-Transfer-Encoding:From:Content-Type:X-Mailer:Message-Id:Date:Cc:To:Mime-Version; b=Fah316t4UQM9WPNTIn4FuKwc0JBYIi0pZ1KDHJNzpGNjVXbHSV/I27CuMQmEPfh9Jr2DG8WrpCFA0k6FD0KNYK2nAL3Q2g3PV14j1tA+8pEfpe5BJ8Ill41t03JjPMkGe6/6GKCbQnfnZ4CizdE8o5FLpsNNr2VKL+lvg0jBDeE= X-Yahoo-Newman-Id: 316934.53962.bm@smtp105-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4zmcArQVM1lomZnpEQH8z2Pn_FiNLFFcqxpmviChr8hdivw BKxyLP3SZv.7f0qAj.JtcNWU1TqnNEFCt6GsyoTpLIL5gmk_i3AH1IynIp9H 6AuzCB6JyrIZoFjIjCBrwHhiBEXjcZJqSKOWrWXdtOGyF54vEwpt0TOzBx2Z hXwX8.ORoCtR3kGd9MSagEPYAZTPMONFaPo4EzVWEa.YmjYRbQF.8NzlR43K qPvdhWTUWiMo6MMizdZtT.LyyzWJZMvhQOhwN93q64ZtkjKn9gr2pYpZ0epx D9wAsw.o8x4WrLWAw6hsuBGLj5xmFoBJdU8qVLIG__6UF4rXR239ZcWxhCEH RCUiTWJIWCKh1Up71nFp9g8RpJlwTQhSECaQVE0tYNuE6FjYvKxBj2_qalKU YnQ5N6SofWgea0KTAUn.cgwToW5eOXJbwmgoCHxAxXR6DVSanNKjWUAs1Eq5 CVPpLcGU- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [192.168.1.67] (osmankh@27.32.72.22 with xymcookie) by smtp105-mob.biz.mail.bf1.yahoo.com with SMTP; 08 Feb 2013 18:16:49 -0800 PST Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Content-Transfer-Encoding: 7bit From: Usman Latif Content-Type: multipart/alternative; boundary=Apple-Mail-002B6A92-9352-4B35-A138-ED1CB991DADB X-Mailer: iPhone Mail (9B206) Message-Id: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> Date: Sat, 9 Feb 2013 13:16:45 +1100 To: "despres.remi@laposte.net" Mime-Version: 1.0 (1.0) 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: Sat, 09 Feb 2013 02:16:51 -0000 --Apple-Mail-002B6A92-9352-4B35-A138-ED1CB991DADB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Remi, A few months ago, I raised some concerns around RFC 6164 which permitted use= of /127 prefixes on inter-router p2p links. You mention use of u/g bits and reserved IID range for 4rd Don't you think that network operators who have by now implemented 6164 base= d addressing in their networks would end up having to readdress portions of t= heir network where they intend to implement 4rd? Rgds, Usman Date: Fri, 8 Feb 2013 16:51:19 +0100 From: R?mi Despr?s To: Havard Eidnes Cc: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Message-ID: <7C04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net> Content-Type: text/plain; charset=3Diso-8859-1 Le 2013-02-08 ? 11:59, Havard Eidnes a ?crit : >>> However, there is nothing which enforces RFC4291-conforming IIDs for >>> (for instance) statically configured IPv6-addresses. >>> So in what way do >>> well defined u/g values for RFC4291-conforming IIDs help you? >>=20 >> 1. >> Users that manually configure their IPv6 addresses should be >> knowledgeable about what they do. >>=20 >> If one configures an address has u=3Dg=3D1, unless it is for an >> experiment, it is a human mistake (it conflicts with the IPv6 >> addressing architecture of RFC 4291). Depending on the context, >> this mistake will have no consequence or will eventually have >> to be corrected. >=20 > What's the operational failure mode? Does it fail in a way which > would be obvious to the ones who has made this mistake, or will > simply some seemingly-random pairs of hosts fail to communicate? > I think it would be an engineering mistake to willfully create > hard-to-detect failure scenarios via a modification to already > fielded standards. FULL AGREEMENT that we don't want to modify any "already fielded standard". If you believe such a change is needed for 4rd, PLEASE EXPLAIN.=20 If one configures an address that doesn't follow configuration constraints, i= t may fail in various ways, but under its own responsibility. For instance, if it has the wrong subnet prefix, it won't be reachable from a= cross the Internet, like what may happen if it has a non-RFC4291-complying I= ID that happens to be in the 4rd reserved range in a site where 4rd is activ= ated. >=20 >> Note that, even if one does such a mistake in a 4rd site, the >> likelihood of using the 4rd IID prefix 0x0300 remains low. >=20 > That's a nice handwave... This is a fact, worth noting IMHO, especially since the particular example o= f a non RFC4291-compliant address Ole gave didn't conflict with 4rd. Your lack of interest for this point doesn't justify, IMHO, a so depreciatin= g comment.=20 >> 2. >> On my home network, I know nobody is doing manual configuration. >=20 > That doesn't really prove anything. It doesn't prove anything, OK, and wasn't BTW claimed to prove anything in p= articular. Yet, the risk of manual misconfigurations that may conflict with the RFC 429= 1, which is indeed a risk, is mitigated by the fact that manual address conf= iguration is AFAIK more an exception than a general practice. Regards, RD --Apple-Mail-002B6A92-9352-4B35-A138-ED1CB991DADB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Remi,
<= div>
A few months ago, I raised some concerns around RFC 6164 w= hich permitted use of /127 prefixes on inter-router p2p links.
You= mention use of u/g bits and reserved IID range for 4rd
Don't you t= hink that network operators who have by now implemented 6164 based addressin= g in their networks would end up having to readdress portions of their netwo= rk where they intend to implement 4rd?


Rgds,
Usman


Date: Fri, 8= Feb 2013 16:51:19 +0100
From: R?mi Despr?s <despres.remi@laposte.net>
To: Havar= d Eidnes <he@uninett.no>
Cc: ipv6@ietf.org
Subjec= t: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]
Mes= sage-ID: <7C= 04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net>
Conte= nt-Type: text/plain; charset=3Diso-8859-1

<= /span>
Le 2013-02-08 ? 11:59<= /a>, Havard Eidnes <he@uninett.no> a ?cr= it :

However, there is nothing which enforces RFC4291-conforming II= Ds for
(for instance) statically conf= igured IPv6-addresses.
So in what way= do
well defined u/g values for RFC42= 91-conforming IIDs help you?

1.
=
Users that manually configure t= heir IPv6 addresses should be
knowledgeable about what they do.

<= /font>
If one confi= gures an address has u=3Dg=3D1, unless it is for an
experiment, it is a huma= n mistake (it conflicts with the IPv6
addressing architecture of RFC 4291). D= epending on the context,
this mistake will have no consequence or will event= ually have
to be corrected.

What's the operational failure mode?=  Does it fail in a way which
woul= d be obvious to the ones who has made this mistake, or will
simply some seemingly-random pairs of hosts fail to com= municate?
I think it would be an engine= ering mistake to willfully create
hard-t= o-detect failure scenarios via a modification to already
fielded standards.

FULL AGREEMENT that we don't want to modify any "already fielded= standard".
If you believe such a change is needed for 4rd, P= LEASE EXPLAIN. 

If one configures an a= ddress that doesn't follow configuration constraints, it may fail in various= ways, but under its own responsibility.
For instance, if it= has the wrong subnet prefix, it won't be reachable from across the Internet= , like what may happen if it has a non-RFC4291-complying IID that happens to= be in the 4rd reserved range in a site where 4rd is activated.


Note that, even if one does such a mistake in a 4rd site, the
like= lihood of using the 4rd IID prefix 0x0300 remains low.

That's a n= ice handwave...

This is= a fact, worth noting IMHO, especially since the particular example of a non= RFC4291-compliant address Ole gave didn't conflict with 4rd.

Your lack of interest for this point doesn't justify, IMH= O, a so depreciating comment. 

=
2.
On my home network, I know nobody is= doing manual configuration.

That doesn't really prove anything.=

It doesn't prove anyth= ing, OK, and wasn't BTW claimed to prove anything in particular.
<= span>
Yet, the risk of manual misconfigurations that may con= flict with the RFC 4291, which is indeed a risk, is mitigated by the fact th= at manual address configuration is AFAIK more an exception than a general pr= actice.


Regards,RD

= --Apple-Mail-002B6A92-9352-4B35-A138-ED1CB991DADB-- From brian.e.carpenter@gmail.com Fri Feb 8 23:57: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 D3FB921F8C96 for ; Fri, 8 Feb 2013 23:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.746 X-Spam-Level: X-Spam-Status: No, score=-99.746 tagged_above=-999 required=5 tests=[AWL=-0.825, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6g3qkYTdPPk for ; Fri, 8 Feb 2013 23:57:25 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0821F8B9E for ; Fri, 8 Feb 2013 23:57:24 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so3694979wey.0 for ; Fri, 08 Feb 2013 23:57:24 -0800 (PST) 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=azJ68SBY57bY3w9V/BKBq8EDn1pD2CG3i+icsssWk1M=; b=huj+EY4QGU6kVpEBorRK3/pRYRtdKbj1B+22hhmQPwWjMK+FCeCBncv8PKvHqCxtVu UrWdTJz6dWh3VANdEYXIdhzkrvC+5J4n99W0YlUAPf0KRKcd5rDA91bUNRyhFoklQd+I Ic0ldfWEtSGlk+lsf5P070/vJQs7PeE+aIV98S3IYfWKMml11Y93FMnosyczp/0NREy+ WLZVqPXUFN2Cfp9zA9D4TqF3qG+oLt2/3Xiu4mRj4I6ehMeEQlSA/rRNxHrEE0Mp11KC FrkvCI697+/aWcqaey0Q1QpiL6S3G7roGYYdNWoBghqc33ZbwxpIzwCO9kEbp6PLhiky LRNw== X-Received: by 10.194.110.69 with SMTP id hy5mr4183279wjb.1.1360396643991; Fri, 08 Feb 2013 23:57:23 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-25.as13285.net. [2.102.219.25]) by mx.google.com with ESMTPS id fx5sm19742198wib.11.2013.02.08.23.57.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 23:57:23 -0800 (PST) Message-ID: <51160171.2090105@gmail.com> Date: Sat, 09 Feb 2013 07:57:37 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> In-Reply-To: <51157129.5080209@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 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: Sat, 09 Feb 2013 07:57:25 -0000 On 08/02/2013 21:42, Fernando Gont wrote: > On 02/08/2013 12:17 PM, RJ Atkinson wrote: >>> **How many bytes of the transport header+payload are included in this definition?** >>> >>> For ESP, is it 8 bytes (SPI + Sequence Number)? >> I think that would be OK. Certainly it MUST NOT be >> more than those 8 bytes, because beyond there lies >> encrypted bits (in the general case). > > Quickly skimming through RFC4303, it looks like the first 8 bytes of the > ESP header are referred to as "header" (with the other being referred to > as "payload" and "trailer").. so it looks like ESP wouldn't really be a > "special case". > > Should we clarify "how many bytes are included" for ESP, nevertheless? > > > >> I actually believe that the SPI alone would suffice >> for ESP. > > It probably would, but.. since the Seq # is part of the header, and it > is also transmitted in plain text, I'd personally deal with ESP as with > the general case "the entire ESP header" (IMO, the fewer the "special > cases", the better). > > > >>> For TCP, is it 8 bytes (ports + Sequence Number)? >> My own sense is that Source Port and Destination Port, >> so 32 bits, actually would suffice, but I'll at least >> note one possible counter-argument: >> A firewall implementation might want to look >> at the TCP flags to check for invalid flag >> combinations. > > In general, firewalls tend to look at many fields in the upper-layer > header -- so it's useful to have it all. > > > >> I would have no objection to Fernando adding more >> detail for the obvious terminating payloads >> (e.g. UDP, TCP, SCTP, ICMP, ESP) to the draft. >> >> Adding more clarity about this to the I-D could not hurt, >> and might help some implementers. > > Something that might make sense is to specify something along the lines > of "if the size of the upper layer header is unknown (say, the upper > layer protocol is implemented as a loadable module, in userland, or the > like). > > Thoughts? If you specify a minimum of 8 bytes that would cover most cases, wouldn't it? I don't think you will find much enthusiasm among coders for a case statement that adjusts the number of bytes according to the layer 4 protocol. Brian From fgont@si6networks.com Sat Feb 9 01:12: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 A00CF21F87A4 for ; Sat, 9 Feb 2013 01:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1FyMTJhim2j for ; Sat, 9 Feb 2013 01:12:47 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD1321F86B8 for ; Sat, 9 Feb 2013 01:12:46 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U46TY-0004g8-CX; Sat, 09 Feb 2013 10:12:01 +0100 Message-ID: <511612D9.1030708@si6networks.com> Date: Sat, 09 Feb 2013 06:11:53 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> <51160171.2090105@gmail.com> In-Reply-To: <51160171.2090105@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson , 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, 09 Feb 2013 09:12:47 -0000 On 02/09/2013 04:57 AM, Brian E Carpenter wrote: >> Something that might make sense is to specify something along the lines >> of "if the size of the upper layer header is unknown (say, the upper >> layer protocol is implemented as a loadable module, in userland, or the >> like). >> >> Thoughts? > > If you specify a minimum of 8 bytes that would cover most cases, wouldn't it? Not really. Firewalls look at many fields in the layer-4 headers -- and such stuff can be past the first 8 bytes. e.g. OpenBSD PF looks at stuff such as the initial TCP window for passive OS fingerprinting, such that you can filter based on the OS type. For instance, the ability to look at the TCP flags is mandatory for most firewalls. > I don't think you will find much enthusiasm among coders for a case statement > that adjusts the number of bytes according to the layer 4 protocol. There are a number of places where this could be taken care of: * The IPv6 layer, with a case statement (as you describe) -- there are not that many upper-layer protocols, anyway. * The transport layer (where you know the MTU, and you know how many bytes you're sending down the stack * The user application (If you're going to insert extension headers, do the math and make sure all the headers make it into the first fragment) If we fail to include critical information in the first fragment, such traffic will be dropped even more than it currently is. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From despres.remi@laposte.net Sat Feb 9 01:17: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 AC40F21F87A4 for ; Sat, 9 Feb 2013 01:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdbbXJzdxve6 for ; Sat, 9 Feb 2013 01:17:05 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8BC21F8BB9 for ; Sat, 9 Feb 2013 01:17:05 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id A130B70000FF; Sat, 9 Feb 2013 10:16:55 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id 5C3F57000096; Sat, 9 Feb 2013 10:16:50 +0100 (CET) X-SFR-UUID: 20130209091650377.5C3F57000096@msfrf2317.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> Date: Sat, 9 Feb 2013 10:16:49 +0100 Message-Id: References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> To: Usman Latif X-Mailer: Apple Mail (2.1499) Content-Type: multipart/alternative; boundary="Apple-Mail=_87A2F79C-800A-48C5-8205-8C745472CC3A" Cc: Miya Kohno , 6man 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: Sat, 09 Feb 2013 09:17:06 -0000 --Apple-Mail=_87A2F79C-800A-48C5-8205-8C745472CC3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Usman, Thank you for this opportunity to clarify once more an important point. 2013-02-09 03:16, Usman Latif : > Hi Remi, >=20 > A few months ago, I raised some concerns around RFC 6164 which = permitted use of /127 prefixes on inter-router p2p links. > You mention use of u/g bits and reserved IID range for 4rd > Don't you think that network operators who have by now implemented = 6164 based addressing in their networks would end up having to readdress = portions of their network where they intend to implement 4rd? The reason why no readdressing will be needed is tat RFC 6144 only = concerns inter-router links. Their /127 IPv6 prefixes are distinct from = those used with 64-bit IIDs. Incidentally, I wrote myself: - "it is a fact that, *for some addresses that aren't concerned with = SLAAC*, typically some manually configured addresses, the IID structure = of RFC 4291 can be ignored. One example where it is actually ignored is = in RFC 6164 which deals with /127 prefixes on inter-router links. = (Incidentally, I have been an active supporter of this RFC, as Miya = Kohno may remember" (ref. = http://www.ietf.org/mail-archive/web/ipv6/current/msg16988)=20 - "For addresses that aren't subject to SLAAC like, for instance, those = of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs = isn't applicable. A clarification on this would IMHO be useful." (ref. = http://www.ietf.org/mail-archive/web/ipv6/current/msg17023). Regards, RD > Rgds, > Usman >=20 >=20 > Date: Fri, 8 Feb 2013 16:51:19 +0100 > From: R?mi Despr?s > To: Havard Eidnes > Cc: ipv6@ietf.org > Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] > Message-ID: <7C04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net> > Content-Type: text/plain; charset=3Diso-8859-1 >=20 >=20 > Le 2013-02-08 ? 11:59, Havard Eidnes a ?crit : >=20 >>>> However, there is nothing which enforces RFC4291-conforming IIDs = for >>>> (for instance) statically configured IPv6-addresses. >>>> So in what way do >>>> well defined u/g values for RFC4291-conforming IIDs help you? >>>=20 >>> 1. >>> Users that manually configure their IPv6 addresses should be >>> knowledgeable about what they do. >>>=20 >>> If one configures an address has u=3Dg=3D1, unless it is for an >>> experiment, it is a human mistake (it conflicts with the IPv6 >>> addressing architecture of RFC 4291). Depending on the context, >>> this mistake will have no consequence or will eventually have >>> to be corrected. >>=20 >> What's the operational failure mode? Does it fail in a way which >> would be obvious to the ones who has made this mistake, or will >> simply some seemingly-random pairs of hosts fail to communicate? >> I think it would be an engineering mistake to willfully create >> hard-to-detect failure scenarios via a modification to already >> fielded standards. >=20 > FULL AGREEMENT that we don't want to modify any "already fielded = standard". > If you believe such a change is needed for 4rd, PLEASE EXPLAIN.=20 >=20 > If one configures an address that doesn't follow configuration = constraints, it may fail in various ways, but under its own = responsibility. > For instance, if it has the wrong subnet prefix, it won't be reachable = from across the Internet, like what may happen if it has a = non-RFC4291-complying IID that happens to be in the 4rd reserved range = in a site where 4rd is activated. >=20 >>=20 >>> Note that, even if one does such a mistake in a 4rd site, the >>> likelihood of using the 4rd IID prefix 0x0300 remains low. >>=20 >> That's a nice handwave... >=20 > This is a fact, worth noting IMHO, especially since the particular = example of a non RFC4291-compliant address Ole gave didn't conflict with = 4rd. >=20 > Your lack of interest for this point doesn't justify, IMHO, a so = depreciating comment.=20 >=20 >=20 >>> 2. >>> On my home network, I know nobody is doing manual configuration. >>=20 >> That doesn't really prove anything. >=20 > It doesn't prove anything, OK, and wasn't BTW claimed to prove = anything in particular. >=20 > Yet, the risk of manual misconfigurations that may conflict with the = RFC 4291, which is indeed a risk, is mitigated by the fact that manual = address configuration is AFAIK more an exception than a general = practice. >=20 >=20 > Regards, > RD >=20 --Apple-Mail=_87A2F79C-800A-48C5-8205-8C745472CC3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = Usman,

Thank you for this opportunity to clarify once = more an important point.

2013-02-09 03:16, Usman = Latif <osmankh@yahoo.com> = :

Hi = Remi,

A few months ago, I raised some concerns = around RFC 6164 which permitted use of /127 prefixes on inter-router p2p = links.
You mention use of u/g bits and reserved IID range for = 4rd

Don't you think that network operators who have = by now implemented 6164 based addressing in their networks would end up = having to readdress portions of their network where they intend to = implement 4rd?

The reason = why no readdressing will be needed is tat RFC 6144 only concerns = inter-router links. Their /127 IPv6 prefixes are distinct from those = used with 64-bit IIDs.

Incidentally, I wrote = myself:
- "it is a = fact that, *for some addresses that aren't concerned with SLAAC*, = typically some manually configured addresses, the IID structure of RFC = 4291 can be ignored. One example where it is actually ignored is in RFC = 6164 which deals with /127 prefixes on inter-router links. = (Incidentally, I have been an active supporter of this RFC, as Miya = Kohno may remember" (ref. http:/= /www.ietf.org/mail-archive/web/ipv6/current/msg16988) 
- "For addresses that aren't subject = to SLAAC like, for instance, those of inter-router links of RFC6164, the = RFC4291 structure of /64 IIDs isn't applicable. A clarification on this = would IMHO be useful." (ref. http:/= /www.ietf.org/mail-archive/web/ipv6/current/msg17023).

<= /div>
Regards,
RD



Rgds,
Usman

Date: Fri, 8 Feb 2013 16:51:19 +0100
From: R?mi = Despr?s <despres.remi@laposte.net>
To: Havard Eidnes <he@uninett.no>
Cc: ipv6@ietf.org
Sub= ject: Re: [Fwd: I-D Action: = draft-carpenter-6man-ug-00.txt]
Message-ID: <7C04FB57-D1B8-42C5-803F-79BF5892526A@= laposte.net>
Content-Type: text/plain; = charset=3Diso-8859-1


Le = 2013-02-08 ? 11:59, Havard Eidnes <he@uninett.no> a ?crit = :

However, there is nothing which = enforces RFC4291-conforming IIDs = for
(for instance) statically configured = IPv6-addresses.
So in what way = do
well defined u/g values for = RFC4291-conforming IIDs help = you?

1.
Users that manually configure their = IPv6 addresses should = be
knowledgeable about what they = do.

If one configures an address has u=3Dg=3D= 1, unless it is for = an
experiment, it is a human mistake (it = conflicts with the = IPv6
addressing architecture of RFC 4291). = Depending on the = context,
this mistake will have no consequence = or will eventually = have
to be = corrected.

What's the = operational failure mode?  Does it fail in a way = which
would be obvious to the ones who has = made this mistake, or will
simply some = seemingly-random pairs of hosts fail to = communicate?
I think it would be an engineering = mistake to willfully create
hard-to-detect = failure scenarios via a modification to = already
fielded = standards.

FULL = AGREEMENT that we don't want to modify any "already fielded = standard".
If you believe such a change is needed for = 4rd, PLEASE EXPLAIN. 

If one = configures an address that doesn't follow configuration constraints, it = may fail in various ways, but under its own = responsibility.
For instance, if it has the wrong subnet = prefix, it won't be reachable from across the Internet, like what may = happen if it has a non-RFC4291-complying IID that happens to be in the = 4rd reserved range in a site where 4rd is = activated.


Note that, even if one does such a = mistake in a 4rd site, = the
likelihood of using the 4rd IID prefix = 0x0300 remains = low.

That's a nice = handwave...

This is = a fact, worth noting IMHO, especially since the particular example of a = non RFC4291-compliant address Ole gave didn't conflict with = 4rd.

Your lack of interest for this = point doesn't justify, IMHO, a so depreciating = comment. 


2.
On my home network, I know nobody is = doing manual = configuration.

That doesn't = really prove = anything.

It = doesn't prove anything, OK, and wasn't BTW claimed to prove anything in = particular.

Yet, the risk of manual = misconfigurations that may conflict with the RFC 4291, which is indeed a = risk, is mitigated by the fact that manual address configuration is = AFAIK more an exception than a general = practice.


Regards,
RD


= --Apple-Mail=_87A2F79C-800A-48C5-8205-8C745472CC3A-- From brian.e.carpenter@gmail.com Sat Feb 9 03:11: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 4074421F884A for ; Sat, 9 Feb 2013 03:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ4ALXAhZC+9 for ; Sat, 9 Feb 2013 03:11:36 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB8E21F84FC for ; Sat, 9 Feb 2013 03:11:36 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so3693359wgb.24 for ; Sat, 09 Feb 2013 03:11:35 -0800 (PST) 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=4Z4lJCf04r3UUTag/iVLjSa9JT8IgYiHzck+AtmlPs8=; b=uu07qbwgzzJtYP05Dcnp8pssmkwsh0/8935WWGLUtUUIfidSGiuZd+3KyumXEFsQbE VlaHO5+GKZNYZzS5EFEelkeJtu8+dH6LhN/726M4cMowf4EOjUOPoP0jRz21s8ebZhyN 20Myt9mqPRL8vHtS2mfaFNoaT2llPHeV466B9uzfBI3st2+JcIKcVSYT3B01zBcQHz0S vknUN0ZpZA7TVTWSmkBRhQO7wPiK4rUV5qI+kbdv2y3GE2WDLf6HESAadp/yjgDqFbus QDo/4bqoaF++wOxDkQiX8907TeTDeAAdoC707j02W9Mn3+iYmNQtW9atsiwV1hgctcxE VTRA== X-Received: by 10.180.104.196 with SMTP id gg4mr7204872wib.16.1360408295686; Sat, 09 Feb 2013 03:11:35 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-25.as13285.net. [2.102.219.25]) by mx.google.com with ESMTPS id ge2sm18935931wib.4.2013.02.09.03.11.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 03:11:34 -0800 (PST) Message-ID: <51162EF6.7000501@gmail.com> Date: Sat, 09 Feb 2013 11:11:50 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> <51160171.2090105@gmail.com> <511612D9.1030708@si6networks.com> In-Reply-To: <511612D9.1030708@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson , 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, 09 Feb 2013 11:11:37 -0000 On 09/02/2013 09:11, Fernando Gont wrote: > On 02/09/2013 04:57 AM, Brian E Carpenter wrote: >>> Something that might make sense is to specify something along the lines >>> of "if the size of the upper layer header is unknown (say, the upper >>> layer protocol is implemented as a loadable module, in userland, or the >>> like). >>> >>> Thoughts? >> If you specify a minimum of 8 bytes that would cover most cases, wouldn't it? > > Not really. Firewalls look at many fields in the layer-4 headers -- and > such stuff can be past the first 8 bytes. e.g. OpenBSD PF looks at stuff > such as the initial TCP window for passive OS fingerprinting, such that > you can filter based on the OS type. For instance, the ability to look > at the TCP flags is mandatory for most firewalls. But the job of this draft is to specify the "on the wire" behaviour of a sending host. To do that, as far as I can see, you have specify how many bytes of the transport header MUST be in the first fragment. Does it include TCP options, for example? At the moment, the draft doesn't tell me what to put in the code (regardless of where in the host stack this is coded). Brian > > >> I don't think you will find much enthusiasm among coders for a case statement >> that adjusts the number of bytes according to the layer 4 protocol. > > There are a number of places where this could be taken care of: > > * The IPv6 layer, with a case statement (as you describe) -- there are > not that many upper-layer protocols, anyway. > * The transport layer (where you know the MTU, and you know how many > bytes you're sending down the stack > * The user application (If you're going to insert extension headers, do > the math and make sure all the headers make it into the first fragment) > > > If we fail to include critical information in the first fragment, such > traffic will be dropped even more than it currently is. > > Cheers, From rja.lists@gmail.com Sat Feb 9 06:03: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 AC7F421F88C8 for ; Sat, 9 Feb 2013 06:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzjAvHk0JGeC for ; Sat, 9 Feb 2013 06:03:10 -0800 (PST) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id B34FE21F87B6 for ; Sat, 9 Feb 2013 06:02:57 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id ff1so2925265vbb.1 for ; Sat, 09 Feb 2013 06:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=z6d/gHx8TK8zmLq12OGsUEuQLFXS4ku53MqLqvRJaWM=; b=ZC0w4RHzX/h09DYdo8vJi3D4M4ARdnudpkpHa438DOB2CVxjq9h8MR3iJ6vDukAY2W gG+lzAvKNz55INbZPak2vhkqKHkxbAfgS+Xx6COKYSMZNsaNAdUbgIH8gaz2lis6Xjhf y8SaoA9YOLnrOpxjKw/NLO5us9f6w2z7y2eG1XPjBo/HCvLHC19WfUntOZ6abiskjwj0 TsbUAZuRNlsCct85G5qSYoRYftejjpXWsVKhRTn9zxQBiWKiNsNDIFA2MDTdxQVzQjai ZquOfngGxYeFMGhpu6IcRM+sgBe9J/DelG/DzoG36MV/uoXUTrrWGDW+ttBdkH2Jt+yH +y/w== X-Received: by 10.52.27.138 with SMTP id t10mr9806499vdg.59.1360418577212; Sat, 09 Feb 2013 06:02:57 -0800 (PST) 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 pa4sm35870645veb.1.2013.02.09.06.02.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 06:02:56 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? Date: Sat, 9 Feb 2013 09:02:55 -0500 Message-Id: <2A024063-9013-4F60-8884-7301DAD5502B@gmail.com> To: ipv6@ietf.org 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: Sat, 09 Feb 2013 14:03:10 -0000 BACKGROUND: After this draft becomes a standard, and implementers have time to update their code, there seems to be a good chance that more fragmented packets will be able to traverse various middleboxes (e.g. firewalls, NATs, whatever else). Off list feedback indicates that for several middlebox implementers, it is important that the middlebox is able to examine the TCP Flags in any first fragment containing TCP as the terminal payload. Reportedly, checks for invalid TCP Flag combinations are considered essential in deciding whether to allow a packet. For UDP or ESP, however, the first 8 bytes is reportedly sufficient. COMMENT: Various folks makes a persuasive case that this draft ought to more explicitly specify, for each terminating payload type, how many bytes need to be included in the first fragment. However, as someone who has worked on more than one IPv6 implementation, I disagree with Brian that adding a case statement to the existing IPv6 fragmentation code is a big deal in an IPv6 host implementation. While one of those implementations was in an ordinary host, two of those implementations were in embedded systems, so I am familiar with the constraints of embedded systems. In any event, the I-D only needs specify a *minimum* number of bytes for each terminal payload type that is to be included in the first fragment. So, purely for example, if ESP/UDP had a value of 8 bytes minimum, while TCP had a value of 16 bytes minimum, code would be compliant EITHER if it had a case statement OR if it always included at least 16 bytes. PROPOSAL: Perhaps Fernando could edit the draft to specify, on a per terminal payload basis, the minimum number of initial bytes to include in the first fragment. Purely for clarity, and one would hope this would be blatantly obvious already, I'd also suggest adding a sentence explicitly stating that an implementation MAY include more bytes than the minimum in its first fragments. HOPE: One would hope that after those 2 edits are made, then this I-D would be ready to begin WG Last Call. Cheers, Ran From fgont@si6networks.com Sat Feb 9 11:40: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 3084B21F8628 for ; Sat, 9 Feb 2013 11:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqMuZ8av6lfE for ; Sat, 9 Feb 2013 11:40:06 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 927FB21F8554 for ; Sat, 9 Feb 2013 11:40:06 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U4GGz-00053A-Ou; Sat, 09 Feb 2013 20:39:42 +0100 Message-ID: <5116A5F6.6030304@si6networks.com> Date: Sat, 09 Feb 2013 16:39:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> <51160171.2090105@gmail.com> <511612D9.1030708@si6networks.com> <51162EF6.7000501@gmail.com> In-Reply-To: <51162EF6.7000501@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 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: Sat, 09 Feb 2013 19:40:07 -0000 On 02/09/2013 08:11 AM, Brian E Carpenter wrote: > On 09/02/2013 09:11, Fernando Gont wrote: >> >> Not really. Firewalls look at many fields in the layer-4 headers -- and >> such stuff can be past the first 8 bytes. e.g. OpenBSD PF looks at stuff >> such as the initial TCP window for passive OS fingerprinting, such that >> you can filter based on the OS type. For instance, the ability to look >> at the TCP flags is mandatory for most firewalls. > > But the job of this draft is to specify the "on the wire" behaviour of a > sending host. Exactly: And it requires to include all header up to the entire layer-4 header. > To do that, as far as I can see, you have specify how many > bytes of the transport header MUST be in the first fragment. Does it include > TCP options, for example? Yes. TCP options are part of the TCP header... so they should be there. The short story is: all sort of devices are used to look at the layer-4 header. Legitimate traffic won't have the ipv6 header chain spanning multiple fragments. So such packets will be dropped. We need to flag them as appropriate, such that folks that might possibly send those packets are aware that those packets won't probably survive in the network. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From osmankh@yahoo.com Sat Feb 9 19:43: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 BFD1E21F845E for ; Sat, 9 Feb 2013 19:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sElllrfuujET for ; Sat, 9 Feb 2013 19:43:54 -0800 (PST) Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11621F8B7C for ; Sat, 9 Feb 2013 19:43:54 -0800 (PST) Received: from [98.139.215.141] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2013 03:43:53 -0000 Received: from [98.139.173.165] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2013 03:43:53 -0000 Received: from [127.0.0.1] by smtp108-mob.biz.mail.bf1.yahoo.com with NNFMP; 10 Feb 2013 03:43:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360467833; bh=ZnFBMX/z8pxtoDsy6aywcCyq/bE0c4BmeanL0tQtV2s=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=H/GyJR9KsE79x6uPC/DVvP9ew1Iv2UiHxj9LoO0ry2/AXPtwYOX63voZrUF0aDVXXx0JlbL+PYpBSc5qUqKAJQDZjiRAve3AnYS7ru+5MnRlTGwgbMfkOY10f3kfe8mwHkDB8VEmgMorlBWslKav/ZTMsM/6IBtUmKVqKAeCn80= X-Yahoo-Newman-Id: 726245.78803.bm@smtp108-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: iy1zEhsVM1kbdLftAmd7znK2hCM7ymGTClia93bGehxGRd. 2jVpERm4_nCbXQro91p7pbrAx52dKziQFEzenhbi1S87Pvxn32Ht9NmKe5DP XODYJ22eupQTmBuCSP2JkHICEHt0jWayfakNKv6vR8pF3m1cejZd1tCkP1CJ 7N7SGmqxokGu_h06mGBOac_0V0etUNXWoPGc9PPG8P6r0kxPv8D1MgNMibae 2yChbOITHiqaUz15kSDQ8gFxlMwzxV1hbz5kGc_6rLsB9txEgIteeoPR3NXZ Tah6BOPGtT27X7Odl6u7cy2k._OCbi5KL8GATxFGMgmxFT5z4OWTVzvPEkDA pnYKZLbt4RQZWMdSQlsDssGBL5LBXux6ejz4BV.5MIo2NiK4h2lpsXHrwcGd mLX0kO1w8K8PN9oOzdJFhFQvE5pgJT_TNL_nKoLmJIbgaBBCNXyrEbxV43RB TANCD_HHs X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [192.168.1.67] (osmankh@27.32.72.22 with xymcookie) by smtp108-mob.biz.mail.bf1.yahoo.com with SMTP; 09 Feb 2013 19:43:53 -0800 PST References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-E455FBF7-211B-4A53-B708-D06B9C0FACB6 Message-Id: <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Date: Sun, 10 Feb 2013 14:43:48 +1100 To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= Cc: Miya Kohno , 6man 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: Sun, 10 Feb 2013 03:43:55 -0000 --Apple-Mail-E455FBF7-211B-4A53-B708-D06B9C0FACB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Remi, > The reason why no readdressing will be needed is tat RFC 6144 only concern= s inter-router links. Their /127 IPv6 prefixes are distinct from those used w= ith 64-bit IIDs. So if I understand it correctly, if a PE-CE link already has a /127 prefix a= ssigned to it- and we wanted to use the CE as a 4rd CE, we'll have to assign= an additional IPv6 prefix to the CE with 64-bit IIDs? Pls share little detail with me in a scenario where a SP already has /127 wi= th CEs and 4rd is needed from the CE thanks, Usman On 09/02/2013, at 8:16 PM, R=C3=A9mi Despr=C3=A9s = wrote: > Hi, Usman, >=20 > Thank you for this opportunity to clarify once more an important point. >=20 > 2013-02-09 03:16, Usman Latif : >=20 >> Hi Remi, >>=20 >> A few months ago, I raised some concerns around RFC 6164 which permitted u= se of /127 prefixes on inter-router p2p links. >> You mention use of u/g bits and reserved IID range for 4rd >=20 >> Don't you think that network operators who have by now implemented 6164 b= ased addressing in their networks would end up having to readdress portions o= f their network where they intend to implement 4rd? >=20 > The reason why no readdressing will be needed is tat RFC 6144 only concern= s inter-router links. Their /127 IPv6 prefixes are distinct from those used w= ith 64-bit IIDs. >=20 > Incidentally, I wrote myself: > - "it is a fact that, *for some addresses that aren't concerned with SLAAC= *, typically some manually configured addresses, the IID structure of RFC 42= 91 can be ignored. One example where it is actually ignored is in RFC 6164 w= hich deals with /127 prefixes on inter-router links. (Incidentally, I have b= een an active supporter of this RFC, as Miya Kohno may remember" (ref. http= ://www.ietf.org/mail-archive/web/ipv6/current/msg16988)=20 > - "For addresses that aren't subject to SLAAC like, for instance, those of= inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't appl= icable. A clarification on this would IMHO be useful." (ref. http://www.ietf= .org/mail-archive/web/ipv6/current/msg17023). >=20 > Regards, > RD >=20 >=20 >=20 >> Rgds, >> Usman >>=20 >>=20 >> Date: Fri, 8 Feb 2013 16:51:19 +0100 >> From: R?mi Despr?s >> To: Havard Eidnes >> Cc: ipv6@ietf.org >> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] >> Message-ID: <7C04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net> >> Content-Type: text/plain; charset=3Diso-8859-1 >>=20 >>=20 >> Le 2013-02-08 ? 11:59, Havard Eidnes a ?crit : >>=20 >>>>> However, there is nothing which enforces RFC4291-conforming IIDs for >>>>> (for instance) statically configured IPv6-addresses. >>>>> So in what way do >>>>> well defined u/g values for RFC4291-conforming IIDs help you? >>>>=20 >>>> 1. >>>> Users that manually configure their IPv6 addresses should be >>>> knowledgeable about what they do. >>>>=20 >>>> If one configures an address has u=3Dg=3D1, unless it is for an >>>> experiment, it is a human mistake (it conflicts with the IPv6 >>>> addressing architecture of RFC 4291). Depending on the context, >>>> this mistake will have no consequence or will eventually have >>>> to be corrected. >>>=20 >>> What's the operational failure mode? Does it fail in a way which >>> would be obvious to the ones who has made this mistake, or will >>> simply some seemingly-random pairs of hosts fail to communicate? >>> I think it would be an engineering mistake to willfully create >>> hard-to-detect failure scenarios via a modification to already >>> fielded standards. >>=20 >> FULL AGREEMENT that we don't want to modify any "already fielded standard= ". >> If you believe such a change is needed for 4rd, PLEASE EXPLAIN.=20 >>=20 >> If one configures an address that doesn't follow configuration constraint= s, it may fail in various ways, but under its own responsibility. >> For instance, if it has the wrong subnet prefix, it won't be reachable fr= om across the Internet, like what may happen if it has a non-RFC4291-complyi= ng IID that happens to be in the 4rd reserved range in a site where 4rd is a= ctivated. >>=20 >>>=20 >>>> Note that, even if one does such a mistake in a 4rd site, the >>>> likelihood of using the 4rd IID prefix 0x0300 remains low. >>>=20 >>> That's a nice handwave... >>=20 >> This is a fact, worth noting IMHO, especially since the particular exampl= e of a non RFC4291-compliant address Ole gave didn't conflict with 4rd. >>=20 >> Your lack of interest for this point doesn't justify, IMHO, a so deprecia= ting comment.=20 >>=20 >>=20 >>>> 2. >>>> On my home network, I know nobody is doing manual configuration. >>>=20 >>> That doesn't really prove anything. >>=20 >> It doesn't prove anything, OK, and wasn't BTW claimed to prove anything i= n particular. >>=20 >> Yet, the risk of manual misconfigurations that may conflict with the RFC 4= 291, which is indeed a risk, is mitigated by the fact that manual address co= nfiguration is AFAIK more an exception than a general practice. >>=20 >>=20 >> Regards, >> RD >>=20 >=20 --Apple-Mail-E455FBF7-211B-4A53-B708-D06B9C0FACB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Remi,

The reason why no readdressin= g will be needed is tat RFC 6144 only concerns inter-router links. Thei= r /127 IPv6 prefixes are distinct from those used with 64-bit IIDs.

So if I understand it= correctly, if a PE-CE link already has a /127 prefix assigned to it- and we= wanted to use the CE as a 4rd CE, we'll have to assign an additional IPv6 p= refix to the CE with 64-bit IIDs?

Pls share little d= etail with me in a scenario where a SP already has /127 with CEs and 4rd is n= eeded from the CE

thanks,
Usman


On 09/02/2013, at 8:16 PM, R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net> wrote:
Hi, Usman,<= div>
Thank you for this opportunity to clarify once more an im= portant point.

2013-02-09 03:16, Usman Latif <osmankh@yahoo.com> :

Hi Remi,

A few months ago, I rais= ed some concerns around RFC 6164 which permitted use of /127 prefixes on int= er-router p2p links.
You mention use of u/g bits and reserved IID r= ange for 4rd

Don't you think that network operators who have by now i= mplemented 6164 based addressing in their networks would end up having to re= address portions of their network where they intend to implement 4rd?
<= /div>

The reason why no readdressing will be= needed is tat RFC 6144 only concerns inter-router links. Their /127 IP= v6 prefixes are distinct from those used with 64-bit IIDs.

Incidentally, I wrote myself:
- "it is a fact that, *for some addresses that aren't concerned w= ith SLAAC*, typically some manually configured addresses, the IID structure o= f RFC 4291 can be ignored. One example where it is actually ignored is in RFC= 6164 which deals with /127 prefixes on inter-router links. (Incidentally, I= have been an active supporter of this RFC, as Miya Kohno may remember" (ref= . http://www.ietf.org/mail-archive/web/ipv6/current/msg16988) 

Regards,
RD


Rgds,
Usman


Date: Fri= , 8 Feb 2013 16:51:19 +0100
From: R?mi Despr?s <despres.remi@laposte.net>
To: Ha= vard Eidnes <he@uninett.no>
Cc: ipv6@ietf.org
Sub= ject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]
= Message-ID: <7C04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net>
Co= ntent-Type: text/plain; charset=3Diso-8859-1


Le 2013-02-08 ? 11:= 59, Havard Eidnes <he@uninett.no> a ?= crit :

H= owever, there is nothing which enforces RFC4291-conforming IIDs for
(for instance) statically configured IPv6-addresses.
=
So in what way do
well defined u/g values fo= r RFC4291-conforming IIDs help you?

<= blockquote type=3D"cite">
1.
U= sers that manually configure their IPv6 addresses should be
knowledgeable about what they do.<= /span>

=
If one configures an address has u=3D= g=3D1, unless it is for an
experiment, it is a human mistake (it conflicts with the IPv6
addressing architecture o= f RFC 4291). Depending on the context,
this mistake will have no consequence or will eventuall= y have
=
to be corre= cted.
<= font class=3D"Apple-style-span">
What's the operati= onal failure mode?  Does it fail in a way which
woul= d be obvious to the ones who has made this mistake, or will
simply some seemingly-random pairs of hosts fail to communicate?
I think it would be an engineering mistake to willfully create
hard-to-detect failure scenarios via a modification to alre= ady
fielded standards.

FULL AGREEMENT that we don't want to modify any "already f= ielded standard".
If you believe such a change is needed for= 4rd, PLEASE EXPLAIN. 

If one configur= es an address that doesn't follow configuration constraints, it may fail in v= arious ways, but under its own responsibility.
For instance,= if it has the wrong subnet prefix, it won't be reachable from across the In= ternet, like what may happen if it has a non-RFC4291-complying IID that happ= ens to be in the 4rd reserved range in a site where 4rd is activated.=


Note that, even if o= ne does such a mistake in a 4rd site, the
likelihood of using the 4rd IID prefix 0x0300 remain= s low.
=
That's a nice han= dwave...

This is a fact= , worth noting IMHO, especially since the particular example of a non RFC429= 1-compliant address Ole gave didn't conflict with 4rd.

Your lack of interest for this point doesn't justify, IMHO, a so= depreciating comment. 


2.
On m= y home network, I know nobody is doing manual configuration.

That doesn't really prove anything.

It doesn't prove anything,= OK, and wasn't BTW claimed to prove anything in particular.

Yet, the risk of manual misconfigurations that may conflic= t with the RFC 4291, which is indeed a risk, is mitigated by the fact that m= anual address configuration is AFAIK more an exception than a general practi= ce.


Regards,
RD<= br>

= --Apple-Mail-E455FBF7-211B-4A53-B708-D06B9C0FACB6-- From mkohno@cisco.com Sun Feb 10 03:45: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 105E121F856D for ; Sun, 10 Feb 2013 03:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.098 X-Spam-Level: X-Spam-Status: No, score=-9.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE1emXS4giXC for ; Sun, 10 Feb 2013 03:45:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBEB21F8554 for ; Sun, 10 Feb 2013 03:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19844; q=dns/txt; s=iport; t=1360496755; x=1361706355; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=GKvmihXktp5rNlmtLo011IjyvP8pfuyGxUd4FSBIwqs=; b=RM+0GThJegCMsRuM+rSqnofIIDcvj3U5U9obzUp686WcY6j8Ci14u1Pv 3CyRzGO4Jpcmab4AzX6BlHCvWYni4UBYaFoUtcX7iiOn0869GDFMk3dHl JwQ8eiZZskP3Jhgf5F/zgNNIIKCQVQz6c42JLACX5vdepSnmtqZicROrK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYFAKuHF1GtJV2Z/2dsb2JhbABFgkmGY6R/kCGCRhZzgh8BAQEEeRIBCA4DAQIBAgsdORMBAwYIAgQBDQUIAYd3Aw8MtRATiVWMP4ESg1hhA4gwjB+NFYUTgwaBbzU X-IronPort-AV: E=Sophos;i="4.84,637,1355097600"; d="scan'208,217";a="175473063" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 10 Feb 2013 11:45:55 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1ABjsVb012475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Feb 2013 11:45:54 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0328.009; Sun, 10 Feb 2013 05:45:54 -0600 From: "Miya Kohno (mkohno)" To: Usman Latif , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Thread-Index: AQHOBqY1rg+VVz+oDk6a+ryXvLE3CJhy2PMAgAEdj4A= Date: Sun, 10 Feb 2013 11:45:53 +0000 Message-ID: In-Reply-To: <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.230.165] Content-Type: multipart/alternative; boundary="_000_C8A79ED02CC0B245937B465B37CB14F11542F824xmbalnx11ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 10 Feb 2013 04:50:49 -0800 Cc: "Miya Kohno \(mkohno\)" , 6man 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: Sun, 10 Feb 2013 11:45:57 -0000 --_000_C8A79ED02CC0B245937B465B37CB14F11542F824xmbalnx11ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Usman, /127 addressing and SLAAC is mutually exclusive, so I think it's out of the= scope of the problem, where we discuss if u/g bit should be meaningful als= o for non-EUI-derived address. Miya From: Usman Latif > Date: Sunday, February 10, 2013 12:43 PM To: R=E9mi Despr=E9s > Cc: 6man 6man-wg >, "Miya Kohno (mkohno= )" > Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Hi Remi, The reason why no readdressing will be needed is tat RFC 6144 only concerns= inter-router links. Their /127 IPv6 prefixes are distinct from those used = with 64-bit IIDs. So if I understand it correctly, if a PE-CE link already has a /127 prefix = assigned to it- and we wanted to use the CE as a 4rd CE, we'll have to assi= gn an additional IPv6 prefix to the CE with 64-bit IIDs? Pls share little detail with me in a scenario where a SP already has /127 w= ith CEs and 4rd is needed from the CE thanks, Usman On 09/02/2013, at 8:16 PM, R=E9mi Despr=E9s > wrote: Hi, Usman, Thank you for this opportunity to clarify once more an important point. 2013-02-09 03:16, Usman Latif >= : Hi Remi, A few months ago, I raised some concerns around RFC 6164 which permitted us= e of /127 prefixes on inter-router p2p links. You mention use of u/g bits and reserved IID range for 4rd Don't you think that network operators who have by now implemented 6164 bas= ed addressing in their networks would end up having to readdress portions o= f their network where they intend to implement 4rd? The reason why no readdressing will be needed is tat RFC 6144 only concerns= inter-router links. Their /127 IPv6 prefixes are distinct from those used = with 64-bit IIDs. Incidentally, I wrote myself: - "it is a fact that, *for some addresses that aren't concerned with SLAAC*= , typically some manually configured addresses, the IID structure of RFC 42= 91 can be ignored. One example where it is actually ignored is in RFC 6164 = which deals with /127 prefixes on inter-router links. (Incidentally, I have= been an active supporter of this RFC, as Miya Kohno may remember" (ref. ht= tp://www.ietf.org/mail-archive/web/ipv6/current/msg16988) - "For addresses that aren't subject to SLAAC like, for instance, those of = inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't appl= icable. A clarification on this would IMHO be useful." (ref. http://www.iet= f.org/mail-archive/web/ipv6/current/msg17023). Regards, RD Rgds, Usman Date: Fri, 8 Feb 2013 16:51:19 +0100 From: R?mi Despr?s > To: Havard Eidnes > Cc: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Message-ID: <7C04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net> Content-Type: text/plain; charset=3Diso-8859-1 Le 2013-02-08 ? 11:59, Havard Eidnes > a ?crit : However, there is nothing which enforces RFC4291-conforming IIDs for (for instance) statically configured IPv6-addresses. So in what way do well defined u/g values for RFC4291-conforming IIDs help you? 1. Users that manually configure their IPv6 addresses should be knowledgeable about what they do. If one configures an address has u=3Dg=3D1, unless it is for an experiment, it is a human mistake (it conflicts with the IPv6 addressing architecture of RFC 4291). Depending on the context, this mistake will have no consequence or will eventually have to be corrected. What's the operational failure mode? Does it fail in a way which would be obvious to the ones who has made this mistake, or will simply some seemingly-random pairs of hosts fail to communicate? I think it would be an engineering mistake to willfully create hard-to-detect failure scenarios via a modification to already fielded standards. FULL AGREEMENT that we don't want to modify any "already fielded standard". If you believe such a change is needed for 4rd, PLEASE EXPLAIN. If one configures an address that doesn't follow configuration constraints,= it may fail in various ways, but under its own responsibility. For instance, if it has the wrong subnet prefix, it won't be reachable from= across the Internet, like what may happen if it has a non-RFC4291-complyin= g IID that happens to be in the 4rd reserved range in a site where 4rd is a= ctivated. Note that, even if one does such a mistake in a 4rd site, the likelihood of using the 4rd IID prefix 0x0300 remains low. That's a nice handwave... This is a fact, worth noting IMHO, especially since the particular example = of a non RFC4291-compliant address Ole gave didn't conflict with 4rd. Your lack of interest for this point doesn't justify, IMHO, a so depreciati= ng comment. 2. On my home network, I know nobody is doing manual configuration. That doesn't really prove anything. It doesn't prove anything, OK, and wasn't BTW claimed to prove anything in = particular. Yet, the risk of manual misconfigurations that may conflict with the RFC 42= 91, which is indeed a risk, is mitigated by the fact that manual address co= nfiguration is AFAIK more an exception than a general practice. Regards, RD --_000_C8A79ED02CC0B245937B465B37CB14F11542F824xmbalnx11ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Usman,

/127 addressing and SLAAC is mutually exclusive, so I think it's out o= f the scope of the problem, where we discuss if u/g bit should be meaningfu= l also for non-EUI-derived address. 

Miya

From: Usman Latif <osmankh@yahoo.com>
Date: Sunday, February 10, 2013 12:= 43 PM
To: R=E9mi Despr=E9s <despres.remi@laposte.net>
Cc: 6man 6man-wg <ipv6@ietf.org>, "Miya Kohno (mkohno)" &= lt;mkohno@cisco.com>
Subject: Re: [Fwd: I-D Action: draf= t-carpenter-6man-ug-00.txt]

Hi Remi,

The reason why no readdressing will be needed is tat RFC 6144 onl= y concerns inter-router links. Their /127 IPv6 prefixes are distinct from t= hose used with 64-bit IIDs.

So if I understand it correctly, if a PE-CE link already has a /127 pr= efix assigned to it- and we wanted to use the CE as a 4rd CE, we'll have to= assign an additional IPv6 prefix to the CE with 64-bit IIDs?

Pls share little detail with me in a scenario where a SP already has /= 127 with CEs and 4rd is needed from the CE

thanks,
Usman


On 09/02/2013, at 8:16 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:

Hi, Usman,

Thank you for this opportunity to clarify once more an important point= .

2013-02-09 03:16, Usman Latif <osmankh@yahoo.com> :

Hi Remi,

A few months ago, I raised some concerns around RFC 6164 which permitt= ed use of /127 prefixes on inter-router p2p links.
You mention use of u/g bits and reserved IID range for 4rd

Don't you think that network operators who have by now implemented 616= 4 based addressing in their networks would end up having to readdress porti= ons of their network where they intend to implement 4rd?

The reason why no readdressing will be needed is tat RFC 6144 onl= y concerns inter-router links. Their /127 IPv6 prefixes are distinct from t= hose used with 64-bit IIDs.

Incidentally, I wrote myself:
- "it is a fact that, *fo= r some addresses that aren't concerned with SLAAC*, typically some manually= configured addresses, the IID structure of RFC 4291 can be ignored. One ex= ample where it is actually ignored is in RFC 6164 which deals with /127 prefixes on inter-router links. (Incidental= ly, I have been an active supporter of this RFC, as Miya Kohno may remember= " (ref. http://www.ietf.org/mail-archive/web/ipv6/current/msg16988) 

Regards,
RD



Rgds,
Usman


Date: Fri, 8 Feb 2013 16:51:19 +0100
From: R?mi Despr?s <despres.= remi@laposte.net>
To: Havard Eidnes <he@uninett.no>= ;
Cc: ipv6@ietf.org
Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]=
Message-ID: <7C04FB57-D1B8-42C5-803F-79BF5892526A@laposte.net> Content-Type: text/plain; charset=3Diso-8859-1


Le 2013-02-08 ? 11:59, Hav= ard Eidnes <he@uninett.no> a ?crit :

However, t= here is nothing which enforces RFC4291-conforming IIDs for
(for insta= nce) statically configured IPv6-addresses.
So in what= way do
well defin= ed u/g values for RFC4291-conforming IIDs help you?
1.<= br>
Users that= manually configure their IPv6 addresses should be
knowledgea= ble about what they do.
If one con= figures an address has u=3Dg=3D1, unless it is for an
experiment= , it is a human mistake (it conflicts with the IPv6
addressing= architecture of RFC 4291). Depending on the context,
this mista= ke will have no consequence or will eventually have
to be corr= ected.
What's the= operational failure mode?  Does it fail in a way which
would be o= bvious to the ones who has made this mistake, or will
simply som= e seemingly-random pairs of hosts fail to communicate?
I think it= would be an engineering mistake to willfully create
hard-to-de= tect failure scenarios via a modification to already
fielded st= andards.

FULL AGREEMENT that we don't want to modify any "already fielded= standard".
If you believe such a change is needed for 4rd, PLEASE EXPLAIN. =

If one configures an address that doesn't follow configuration constr= aints, it may fail in various ways, but under its own responsibility.
For instance, if it has the wrong subnet prefix, it won't be reachabl= e from across the Internet, like what may happen if it has a non-RFC4291-co= mplying IID that happens to be in the 4rd reserved range in a site where 4r= d is activated.

Note that,= even if one does such a mistake in a 4rd site, the
likelihood= of using the 4rd IID prefix 0x0300 remains low.
That's a n= ice handwave...

This is a fact, worth noting IMHO, especially since the particular ex= ample of a non RFC4291-compliant address Ole gave didn't conflict with 4rd.=

Your lack of interest for this point doesn't justify, IMHO, a so depr= eciating comment. 


2.<= br>
On my home= network, I know nobody is doing manual configuration.
That doesn= 't really prove anything.

It doesn't prove anything, OK, and wasn't BTW claimed to prove anythi= ng in particular.

Yet, the risk of manual misconfigurations that may conflict with the = RFC 4291, which is indeed a risk, is mitigated by the fact that manual addr= ess configuration is AFAIK more an exception than a general practice.


Regards,
RD


 --_000_C8A79ED02CC0B245937B465B37CB14F11542F824xmbalnx11ciscoc_-- From jitendra.bhadoriya@one97.net Sun Feb 10 23:31: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 A3EEF21F8994 for ; Sun, 10 Feb 2013 23:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfRH3Werpj7z for ; Sun, 10 Feb 2013 23:31:27 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id BB70721F8972 for ; Sun, 10 Feb 2013 23:31:27 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so2594343dak.2 for ; Sun, 10 Feb 2013 23:31:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=OKGjkLNNN0wvYL4RhkDsfyNAQs8YO72I+qDvqjnbHTA=; b=QlMTrjODKT7uZGqC2ghC7CxolEeI5buiyptfvJ9RgBG34S/Ge3wa4pWx3RKuFZcb99 s9/P6SlMaiGcVzQUJNcPkFI3vDVAfYVLsG20TCQn6SeuwkhFSbJ46acs31tPURBwsCb1 XtfiqthxzErd7oeOZWYZbfCeZrwzwP5+Hk+n83nsDhnkgdR8C8bxTiwQt1b4FNCSIP+B lrGKIr8hzbnyO1pFksGkBl4f6EJAIhNIi9YGWrfAOhH1oj/0pDGkF3Ggkaa1kLRrku6X h44tjF7bfQh22wsrzDugzeIKmdRaSwZhW4ZxaGz1KKeWwnHtpRj5LRj7jN/iVMP5GwUf vSmw== X-Received: by 10.68.137.36 with SMTP id qf4mr16398119pbb.85.1360567887445; Sun, 10 Feb 2013 23:31:27 -0800 (PST) Received: from Jitendrabhadoriya ([125.63.68.98]) by mx.google.com with ESMTPS id g10sm6830486pbl.10.2013.02.10.23.31.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 10 Feb 2013 23:31:26 -0800 (PST) From: "Jitendra Singh" To: Subject: server program in C for IPv6 Date: Mon, 11 Feb 2013 13:02:20 +0530 Message-ID: <51189e4e.aa29440a.3237.ffff9d32@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CE0858.0FE78B20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4GAfoIDPPfzEK4RDiH1/UN4Yz5nw== Content-Language: en-in X-Gm-Message-State: ALoCoQm84xvy/cUJXLiGa+/cNLpwSlY9unYCkffzG7Rewmp81naxOdppkGS/9lRsSMlvT6c0bT/a 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, 11 Feb 2013 07:31:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01CE0858.0FE78B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am trying to write an IPv6 client in C++ using ACE framework. Even after compiling with ACE_HAS_IPV6 preprocessor flag, I am not able to connect to an IPv6 server. Can somebody please guide me what extra steps I need to take for compiling ACE with IPv6 support. Thanks, Jitendra ------=_NextPart_000_0004_01CE0858.0FE78B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am trying = to write an IPv6 client in C++ using ACE framework. Even after compiling = with ACE_HAS_IPV6 preprocessor flag, I am not able to connect to an IPv6 = server.

Can somebody please guide me = what extra steps I need to take for compiling ACE with IPv6 = support.

 

Thanks,

Jitendra =

------=_NextPart_000_0004_01CE0858.0FE78B20-- From despres.remi@laposte.net Mon Feb 11 02:13: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 EA65F21F86F6 for ; Mon, 11 Feb 2013 02:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VIl6W27+Yih for ; Mon, 11 Feb 2013 02:13:11 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 19A1D21F86DD for ; Mon, 11 Feb 2013 02:13:10 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 20956700007C; Mon, 11 Feb 2013 11:13:09 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id D07AB70000EA; Mon, 11 Feb 2013 11:13:08 +0100 (CET) X-SFR-UUID: 20130211101308854.D07AB70000EA@msfrf2403.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: RFC 6144 to be listed as updating RFC 4291 From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> Date: Mon, 11 Feb 2013 11:13:04 +0100 Message-Id: <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> To: Bob Hinden , Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: multipart/alternative; boundary="Apple-Mail=_969EB371-0B06-4A06-9300-6474D083F33B" Cc: Miya Kohno , Usman Latif , 6man 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, 11 Feb 2013 10:13:12 -0000 --Apple-Mail=_969EB371-0B06-4A06-9300-6474D083F33B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Bob, Ole, RFC 6164 (/127 on inter-router links) is in fact an update of RFC4291 = (IPv6 addressing architecture). Yet, it isn't listed as such in https://tools.ietf.org/html/rfc4291. Shouldn't this be fixed? Regards, RD PS: This point has been noted during the discussion below concerning 4rd = CEs and u/g bits of IIDs.:=20 2013-02-10 04:43, Usman Latif =20 ... > So if I understand it correctly, if a PE-CE link already has a /127 = prefix assigned to it- and we wanted to use the CE as a 4rd CE, we'll = have to assign an additional IPv6 prefix to the CE with 64-bit IIDs? >=20 > Pls share little detail with me in a scenario where a SP already has = /127 with CEs and 4rd is needed from the CE According to RFC 6164, /127 prefixes are used ONLY on inter-router link.=20= They cannot be used as customer-site IPv6 prefixes which, to comply with = https://tools.ietf.org/html/rfc4291#section-2.5.1, MUST permit 64-bit = IIDs.=20 Each 4rd CE MUST therefore be delegated at least one IPv6 prefix having = at most 64 bits (this doesn't depend on its WAN link having or not a = /127).=20 RD --Apple-Mail=_969EB371-0B06-4A06-9300-6474D083F33B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://tools.ietf.org/html/r= fc4291.
Shouldn't this be = fixed?

Regards,
RD

=


PS: This point has been noted = during the discussion below concerning 4rd CEs and u/g bits of = IIDs.: 

2013-02-10 04:43, Usman Latif = <osmankh@yahoo.com> 
...
So if = I understand it correctly, if a PE-CE link already has a /127 prefix = assigned to it- and we wanted to use the CE as a 4rd CE, we'll have to = assign an additional IPv6 prefix to the CE with 64-bit = IIDs?

Pls share little detail with me in a = scenario where a SP already has /127 with CEs and 4rd is needed from the = CE

According to RFC = 6164, /127 prefixes are used ONLY on inter-router = link. 
They cannot be used as customer-site IPv6 = prefixes which, to comply with https://tools.i= etf.org/html/rfc4291#section-2.5.1, MUST permit 64-bit = IIDs. 

Each 4rd CE MUST = therefore be delegated at least one IPv6 prefix having at most 64 = bits (this doesn't depend on its WAN link having or not = a /127). 

RD

= --Apple-Mail=_969EB371-0B06-4A06-9300-6474D083F33B-- From brian.e.carpenter@gmail.com Mon Feb 11 02:55: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 3457621F87A4 for ; Mon, 11 Feb 2013 02:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.968 X-Spam-Level: X-Spam-Status: No, score=-100.968 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4BTuR5umKZz for ; Mon, 11 Feb 2013 02:55:46 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id CFFA221F879B for ; Mon, 11 Feb 2013 02:55:20 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so4506487wgd.28 for ; Mon, 11 Feb 2013 02:55:19 -0800 (PST) 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=NCXqoYOuPfa5G5n1HKiEjIqIwl5PD3hfoWgTrBXyggo=; b=U5bROAeXhfmlzKx4R/nM5k1knhNMst6/LXP8f5AdFKQevDr0ttavrCcAbM9v9DNgb3 UVbh+qlVFzuxNaeo6ANNAefYqR4Wxup+zB5AihDUo+JJdCVDw5ZzIbcp2U2+4G8NMsz4 BGAOrQTnG+M9DClCgES/ntbgloxbH0VOqmaJNiAPEezQMI85S/bKIrUEIbbgZwGlas4E GhDoHv6Ralrc3lqQp5mSTx+o+wgXSAMOMv3xtX61vA6To5l6ZLpXqjfua/OGK75K76ip BJ41lXQPOUbP/xL4TL+UU05IYumHXoOwMKlTLktkw/gT7fo3g9v8rxU23+XTIEC+JsiV NdbQ== X-Received: by 10.180.81.39 with SMTP id w7mr15210019wix.15.1360580119867; Mon, 11 Feb 2013 02:55:19 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-50.as13285.net. [2.102.218.50]) by mx.google.com with ESMTPS id l3sm32291797wiy.8.2013.02.11.02.55.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 02:55:19 -0800 (PST) Message-ID: <5118CE19.9040607@gmail.com> Date: Mon, 11 Feb 2013 10:55:21 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Subject: RFC 6164 to be listed as updating RFC 4291 References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> In-Reply-To: <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ole Troan , Miya Kohno , Usman Latif , Bob Hinden , 6man 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, 11 Feb 2013 10:55:47 -0000 (Correcting the Subject header) That could be reported as an erratum against RFC 6164. Regards Brian On 11/02/2013 10:13, R=C3=A9mi Despr=C3=A9s wrote: > Hi, Bob, Ole, >=20 > RFC 6164 (/127 on inter-router links) is in fact an update of RFC4291 (= IPv6 addressing architecture). > Yet, it isn't listed as such in https://tools.ietf.org/html/rfc4291. > Shouldn't this be fixed? >=20 > Regards, > RD >=20 >=20 >=20 > PS: This point has been noted during the discussion below concerning 4r= d CEs and u/g bits of IIDs.:=20 >=20 > 2013-02-10 04:43, Usman Latif =20 > ... >> So if I understand it correctly, if a PE-CE link already has a /127 pr= efix assigned to it- and we wanted to use the CE as a 4rd CE, we'll have = to assign an additional IPv6 prefix to the CE with 64-bit IIDs? >> >> Pls share little detail with me in a scenario where a SP already has /= 127 with CEs and 4rd is needed from the CE >=20 > According to RFC 6164, /127 prefixes are used ONLY on inter-router link= =2E=20 > They cannot be used as customer-site IPv6 prefixes which, to comply wit= h https://tools.ietf.org/html/rfc4291#section-2.5.1, MUST permit 64-bit I= IDs.=20 >=20 > Each 4rd CE MUST therefore be delegated at least one IPv6 prefix having= at most 64 bits (this doesn't depend on its WAN link having or not a /12= 7).=20 >=20 > RD >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From despres.remi@laposte.net Mon Feb 11 03:05: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 3302E21F87D1 for ; Mon, 11 Feb 2013 03:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n06Pf8O+VG7c for ; Mon, 11 Feb 2013 03:05:06 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.121]) by ietfa.amsl.com (Postfix) with ESMTP id 30BDA21F87CD for ; Mon, 11 Feb 2013 03:05:05 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2516.sfr.fr (SMTP Server) with ESMTP id 8A01570000B5; Mon, 11 Feb 2013 12:05:04 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2516.sfr.fr (SMTP Server) with ESMTP id 4C93170000B6; Mon, 11 Feb 2013 12:05:04 +0100 (CET) X-SFR-UUID: 20130211110504313.4C93170000B6@msfrf2516.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: RFC 6164 to be listed as updating RFC 4291 From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5118CE19.9040607@gmail.com> Date: Mon, 11 Feb 2013 12:05:02 +0100 Message-Id: <1395FDD9-9B42-4D95-ACF6-43457EF8CF43@laposte.net> References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> <5118CE19.9040607@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ole Troan , Miya Kohno , Usman Latif , Bob Hinden , 6man 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, 11 Feb 2013 11:05:10 -0000 Le 2013-02-11 =E0 11:55, Brian E Carpenter = a =E9crit : > (Correcting the Subject header ) Oops, 6144 instead of 6164 was a typo! >=20 > That could be reported as an erratum against RFC 6164. IN ADDITION to citing RFC 6164 as updating RFC 4291, this makes sense to = me. Thanks, RD >=20 > Regards > Brian >=20 > On 11/02/2013 10:13, R=E9mi Despr=E9s wrote: >> Hi, Bob, Ole, >>=20 >> RFC 6164 (/127 on inter-router links) is in fact an update of RFC4291 = (IPv6 addressing architecture). >> Yet, it isn't listed as such in https://tools.ietf.org/html/rfc4291. >> Shouldn't this be fixed? >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> PS: This point has been noted during the discussion below concerning = 4rd CEs and u/g bits of IIDs.:=20 >>=20 >> 2013-02-10 04:43, Usman Latif =20 >> ... >>> So if I understand it correctly, if a PE-CE link already has a /127 = prefix assigned to it- and we wanted to use the CE as a 4rd CE, we'll = have to assign an additional IPv6 prefix to the CE with 64-bit IIDs? >>>=20 >>> Pls share little detail with me in a scenario where a SP already has = /127 with CEs and 4rd is needed from the CE >>=20 >> According to RFC 6164, /127 prefixes are used ONLY on inter-router = link.=20 >> They cannot be used as customer-site IPv6 prefixes which, to comply = with https://tools.ietf.org/html/rfc4291#section-2.5.1, MUST permit = 64-bit IIDs.=20 >>=20 >> Each 4rd CE MUST therefore be delegated at least one IPv6 prefix = having at most 64 bits (this doesn't depend on its WAN link having or = not a /127).=20 >>=20 >> RD >>=20 >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From kerlyn2001@gmail.com Mon Feb 11 05: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 4CF9421F88A1 for ; Mon, 11 Feb 2013 05:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuhqAiiA7qUs for ; Mon, 11 Feb 2013 05:32:33 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8C04621F88A9 for ; Mon, 11 Feb 2013 05:32:33 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l20so6106086oag.23 for ; Mon, 11 Feb 2013 05:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=87UEypbYqWoFyHieEHBCZDO0QGjA2R5ivhsskdGntsg=; b=XMts6Bkr7L567ayMLfYg+Gv4QsbjJJs/tuTk8Z/D9MEs4YBiASo0dO8sAyLN5UK5FJ xmONsxNvIcwJoNzR7apnVhMv+MssObpJjvPBAnVIUSD0Q/Y4nkdLTIzlLsH6f5yqHIyS QXjiHKSgg33ORm52kuSZlNKHwg/nUmjl2xmH5tcV5lUFkuiyOr0d4wtJHMgb0t2neW6J 5YrkmMgL8P/WLZ5nejvw0E59vMx6PBnJUcMg24I2u8cORB7SJ+5ADYmHu80Yu54awjT3 QYKVBHfrFWnx55LkRdRKiQpDNzIlXNKdrPou9OMUTCFoNHl30s7qUL6jbBJQYVuEoCgP Sxhw== MIME-Version: 1.0 X-Received: by 10.60.12.103 with SMTP id x7mr10891132oeb.56.1360589553036; Mon, 11 Feb 2013 05:32:33 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.3.129 with HTTP; Mon, 11 Feb 2013 05:32:32 -0800 (PST) In-Reply-To: <51189e4e.aa29440a.3237.ffff9d32@mx.google.com> References: <51189e4e.aa29440a.3237.ffff9d32@mx.google.com> Date: Mon, 11 Feb 2013 08:32:32 -0500 X-Google-Sender-Auth: kcO8vHfN-40R_ZkxscIGrbeO_-g Message-ID: Subject: Re: server program in C for IPv6 From: Kerry Lynn To: Jitendra Singh Content-Type: multipart/alternative; boundary=e89a8fb20570fe6e5804d572f084 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, 11 Feb 2013 13:32:34 -0000 --e89a8fb20570fe6e5804d572f084 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 11, 2013 at 2:32 AM, Jitendra Singh < jitendra.bhadoriya@one97.net> wrote: > Hi,**** > > ** ** > > I am trying to write an IPv6 client in C++ using ACE framework. Even after > compiling with ACE_HAS_IPV6 preprocessor flag, I am not able to connect to > an IPv6 server.**** > > Can somebody please guide me what extra steps I need to take for compiling > ACE with IPv6 support. > **** > > ** > Suggest you ask on comp.soft-sys.ace . -K- > ** > > Thanks,**** > > Jitendra **** > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --e89a8fb20570fe6e5804d572f084 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2013 at 2:32 AM, Jitendra Singh <jitendra.bhado= riya@one97.net> wrote:

Hi,

=A0

I am trying to write an IPv6 client in C++ using ACE frame= work. Even after compiling with ACE_HAS_IPV6 preprocessor flag, I am not ab= le to connect to an IPv6 server.

Can somebody please guide me what extra steps I need= to take for compiling ACE with IPv6 support.=A0

=A0

Suggest you ask on=A0comp.soft-sys.ace.

-K-
=A0

Thanks,

Jitendra

=

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


--e89a8fb20570fe6e5804d572f084-- From wesley.george@twcable.com Mon Feb 11 05:32: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 3438021F8A40 for ; Mon, 11 Feb 2013 05:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMOv65ufRHoh for ; Mon, 11 Feb 2013 05:32:36 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9C22721F8917 for ; Mon, 11 Feb 2013 05:32:35 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,643,1355115600"; d="scan'208";a="24530182" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Feb 2013 08:31:47 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 11 Feb 2013 08:32:34 -0500 From: "George, Wes" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Brian E Carpenter Date: Mon, 11 Feb 2013 08:32:37 -0500 Subject: RE: RFC 6164 to be listed as updating RFC 4291 Thread-Topic: RFC 6164 to be listed as updating RFC 4291 Thread-Index: Ac4IR7ApaNzx593hQbWRDuIsUEP/ngAFBxRg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033DEE1B32@PRVPEXVS15.corp.twcable.com> References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> <5118CE19.9040607@gmail.com> <1395FDD9-9B42-4D95-ACF6-43457EF8CF43@laposte.net> In-Reply-To: <1395FDD9-9B42-4D95-ACF6-43457EF8CF43@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ole Troan , Usman Latif , Miya Kohno , Bob Hinden , 6man 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, 11 Feb 2013 13:32:37 -0000 > > > > > That could be reported as an erratum against RFC 6164. > > IN ADDITION to citing RFC 6164 as updating RFC 4291, this makes sense to > me. > [WEG] FWIW, I suggested the erratum route when I realized that 6164 also fa= iled to take obsolete 3627, and was told by IESG that I needed to write a s= hort draft, hence 6547. Wish someone had brought up 4291 at the time when t= he draft of 6547 was being reviewed... Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From otroan@employees.org Mon Feb 11 12:07: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 EFEFC21F87EE for ; Mon, 11 Feb 2013 12:07:57 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruA2k0sQuA6w for ; Mon, 11 Feb 2013 12:07:57 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 603B521F87DC for ; Mon, 11 Feb 2013 12:07:57 -0800 (PST) Received: from dhcp-10-61-109-254.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 0F0105E9B for ; Mon, 11 Feb 2013 12:07:55 -0800 (PST) From: Ole Troan Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Message-Id: <286350F5-34E0-452E-AC53-A6307286DBF4@employees.org> Date: Mon, 11 Feb 2013 21:07:53 +0100 To: "ipv6@ietf.org 6man-wg" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) 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, 11 Feb 2013 20:07:58 -0000 All, This message starts a two week 6MAN Working Group on advancing: Title : Security and Interoperability Implications of = Oversized IPv6 Header Chains Author(s) : F Gont, V. Manral Filename : draft-ietf-6man-oversized-header-chain-02 Pages : 13 Date : 2012-11-05 = https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the author. This last call will = end on 2013-02-25. The chairs would also like to solicit a few people to do a detailed = review of this document. Please contact the chairs directly. Regards, Bob Hinden & Ole Tr=F8an= From otroan@employees.org Mon Feb 11 13:42: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 4957C21F8917 for ; Mon, 11 Feb 2013 13:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNhaSZsv32kF for ; Mon, 11 Feb 2013 13:42:24 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id E071121F890D for ; Mon, 11 Feb 2013 13:42:24 -0800 (PST) Received: from otroan-mac.getinternet.no (cm-84.209.200.28.getinternet.no [84.209.200.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id F02D65EFE; Mon, 11 Feb 2013 13:42:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Ole Troan In-Reply-To: <51157129.5080209@si6networks.com> Date: Mon, 11 Feb 2013 22:42:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0954EEA5-DF47-440B-A18E-8E483CBFE6E6@employees.org> References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: ipv6@ietf.org, 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: Mon, 11 Feb 2013 21:42:25 -0000 Fernando, >>> **How many bytes of the transport header+payload are included in = this definition?** >>>=20 >>> For ESP, is it 8 bytes (SPI + Sequence Number)? >>=20 >> I think that would be OK. Certainly it MUST NOT be >> more than those 8 bytes, because beyond there lies >> encrypted bits (in the general case).=20 >=20 > Quickly skimming through RFC4303, it looks like the first 8 bytes of = the > ESP header are referred to as "header" (with the other being referred = to > as "payload" and "trailer").. so it looks like ESP wouldn't really be = a > "special case". >=20 > Should we clarify "how many bytes are included" for ESP, nevertheless? anything that has a next header field is not the upper layer header. the middlebox doesn't have access to anything following the ESP header. >> I actually believe that the SPI alone would suffice >> for ESP. >=20 > It probably would, but.. since the Seq # is part of the header, and it > is also transmitted in plain text, I'd personally deal with ESP as = with > the general case "the entire ESP header" (IMO, the fewer the "special > cases", the better). what about ESP with NULL encryption? what you are trying to archive is "the first fragment should include as = much of the header chain as would be available if the packet was reassembled", right? perhaps phrase it along those lines. cheers, Ole= From rja.lists@gmail.com Mon Feb 11 13:51: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 38A5621F869B for ; Mon, 11 Feb 2013 13:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXb7-gTP4MBM for ; Mon, 11 Feb 2013 13:51:55 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5A621F8696 for ; Mon, 11 Feb 2013 13:51:55 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so4040553vbb.23 for ; Mon, 11 Feb 2013 13:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=iGiOQ00gIfzS0zqIL0DcDJfv+k9dIY00n4f97YQ3U20=; b=Xm8W+G2yE7n2KmiBkecOPZeLTpTp0fWYjzl8EdiFDJZTwY30SXoWLgRsLTzIyfkua9 TlcnmTpubcc7mxHjUhvZgDp/hnpNzil8ePZDkX0fNOZ+URwrbNZL6iXMWRgy+wCtI9pB zP/JH8B379xPnrvcSyMvGhOZi1NRoKofs6/ByddNsbbkZx4ckLrr6a1dkzuNrtJMJVNU QLLS+jHic8uATAzRxnumrxh/exT0Tz8h0ijBIxAVIneCz0y2+vrmzAx3veEdNj9I8lY5 0HpOtqNG+qoC5xsLeXiych7YIzxjbZw5+cDUge+nntPKeKh4uNzHG9oqnn33fn3p7+E5 KPAQ== X-Received: by 10.52.175.9 with SMTP id bw9mr13718163vdc.28.1360619515125; Mon, 11 Feb 2013 13:51:55 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id o6sm61531934vdd.11.2013.02.11.13.51.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 13:51:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: RJ Atkinson In-Reply-To: <0954EEA5-DF47-440B-A18E-8E483CBFE6E6@employees.org> Date: Mon, 11 Feb 2013 16:51:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> <0954EEA5-DF47-440B-A18E-8E483CBFE6E6@employees.org> To: ipv6@ietf.org 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, 11 Feb 2013 21:51:56 -0000 On 11 Feb 2013, at 16:42 , Ole Troan wrote: > what about ESP with NULL encryption? In the general case, there is no way to reliably (i.e. 100.00%) know whether a transit ESP packet is using encryption or not. There are published heuristics that seek to identify ESP packets that might not be encrypted, but I don't know of any fully reliable heuristics one might use (see above for my definition of reliable). Also, the IETF standardised WESP, but after asking around and looking, I can't find even one implementation of WESP. So WESP appears to have either zero deployment or ignorably low deployment. Yours, Ran From osmankh@yahoo.com Mon Feb 11 14:51: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 3461421F883C for ; Mon, 11 Feb 2013 14:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE+Ew5K+pKFX for ; Mon, 11 Feb 2013 14:51:08 -0800 (PST) Received: from nm16.bullet.mail.gq1.yahoo.com (nm16.bullet.mail.gq1.yahoo.com [98.137.176.58]) by ietfa.amsl.com (Postfix) with SMTP id 7DAE921F880F for ; Mon, 11 Feb 2013 14:51:08 -0800 (PST) Received: from [98.137.12.56] by nm16.bullet.mail.gq1.yahoo.com with NNFMP; 11 Feb 2013 22:51:07 -0000 Received: from [98.136.185.202] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 11 Feb 2013 22:51:07 -0000 Received: from [127.0.0.1] by smtp111-mob.biz.mail.gq1.yahoo.com with NNFMP; 11 Feb 2013 22:51:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360623067; bh=mQLWtPzw23iA41DbehuNZpOJmV+i50VH5ggvyk9CDJw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=VtQ1pCkwYXmEnXaw9UJKuQc7vVrZaDpASQ2LIvMUFh2MUAwvECbtsxJMyKhVZAXa/+QRX9zs8wL/DGKwqNYiSJtw3O0WlYNfX0pAMH+k8bb/fXuo74O7dQAsuivWNzGH1mdIBMh6OMAWBtsLUdMvP0yu9FjxAzWY+zQkiRkRzHI= X-Yahoo-Newman-Id: 721494.48018.bm@smtp111-mob.biz.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OaLdlooVM1n51UgHIOctVP0wvoe1RVnQ_8C2_cQgh5T9gQE BzwlQkwU2o7V42cDcpz4yDQEETZErSXiYWLmVdId71vSmplbTuNqX4azVcCN jUpPD0.r0qHrWs2zHgJVD3cKRUdiZB9LzsEUSNe6qyDmiLca50XV9l3yF74T RIqtngDoz4Kyh38OfyWOKhwYDK1WmQFBP0MIwtmcW3MUWRMhJeFIBgVNdDl5 3Iqc7.Bz55SYtAwPaHHnxGlMwdj_W0CBNAp3x63Lw1iICopoYSlQyqpeIg4z su4UAZnM5WtXvpHMJ.46sKHRwN5V6l_c1D.EdpfHaJc.Hn4faIqaLfZBomW1 iQvs2dFsD4b8grSSoPr_bTMErZrVHmt_8YmAwUqn1G1_.ha_yRYsvB23.Pvq ksGn0EoIF1MyiICmdlVJQ9RuT0P9ltqedvHlZYB9G9QfqxtZxXAZ6o_E.DtB jhL.EDfjQfGHG_ZhW9eD8ON1eBzTGJVRESRa4P8BH.KKAXUMzxzauOmz3toT upOUxQXwkPfQx2VbVSQNZwqU- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [10.19.197.142] (osmankh@49.176.71.230 with xymcookie) by smtp111-mob.biz.mail.gq1.yahoo.com with SMTP; 11 Feb 2013 14:51:07 -0800 PST References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> In-Reply-To: <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-AB548679-0F6E-4E3E-B279-990F7F9D69EC Message-Id: <24FEDC2B-2452-4935-BC4C-5DBB091B3385@yahoo.com> X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Date: Tue, 12 Feb 2013 09:51:02 +1100 To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= Cc: Miya Kohno , 6man 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, 11 Feb 2013 22:51:09 -0000 --Apple-Mail-AB548679-0F6E-4E3E-B279-990F7F9D69EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Remi, On 11/02/2013, at 9:13 PM, R=C3=A9mi Despr=C3=A9s = =20 > ... >> So if I understand it correctly, if a PE-CE link already has a /127 prefi= x assigned to it- and we wanted to use the CE as a 4rd CE, we'll have to ass= ign an additional IPv6 prefix to the CE with 64-bit IIDs? >>=20 >> Pls share little detail with me in a scenario where a SP already has /127= with CEs and 4rd is needed from the CE >=20 > According to RFC 6164, /127 prefixes are used ONLY on inter-router link.=20= > They cannot be used as customer-site IPv6 prefixes which, to comply with h= ttps://tools.ietf.org/html/rfc4291#section-2.5.1, MUST permit 64-bit IIDs.=20= >=20 > Each 4rd CE MUST therefore be delegated at least one IPv6 prefix having at= most 64 bits (this doesn't depend on its WAN link having or not a /127).=20= >=20 > RD Yes 6164 is only for inter-router links I was under the impression that 4rd CE might use the WAN IPv6 address for st= ateless tunnelling of IPv4 inside IPv6 Maybe this was a misunderstanding(?) Or is it really upto the operator whether he wants to leverage the CE WAN IP= v6 prefix or the allocated IPv6 prefix routed to the CE site If the CE WAN happens to be a /64 prefix, could the 4rd leverage that? What is the recommendation there Regards, Usman --Apple-Mail-AB548679-0F6E-4E3E-B279-990F7F9D69EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Remi,



On 11/02/2013, at 9:13 PM, R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>&n= bsp;
...
So if I understand it correctly, i= f a PE-CE link already has a /127 prefix assigned to it- and we wanted to us= e the CE as a 4rd CE, we'll have to assign an additional IPv6 prefix to the C= E with 64-bit IIDs?

Pls share little detail with me= in a scenario where a SP already has /127 with CEs and 4rd is needed from t= he CE

According to RFC 6164= , /127 prefixes are used ONLY on inter-router link. 
They can= not be used as customer-site IPv6 prefixes which, to comply with <= a href=3D"https://tools.ietf.org/html/rfc4291#section-2.5.1">https://tools.i= etf.org/html/rfc4291#section-2.5.1, MUST permit 64-bit IIDs. 
=

Each 4rd CE MUST therefore be delegated at lea= st one IPv6 prefix having at most 64 bits (this doesn't depend on its W= AN link having or not a /127). 

RD


Yes 61= 64 is only for inter-router links
I was under the impression that 4= rd CE might use the WAN IPv6 address for stateless tunnelling of IPv4 inside= IPv6
Maybe this was a misunderstanding(?)
Or is it real= ly upto the operator whether he wants to leverage the CE WAN IPv6 prefix or t= he allocated IPv6 prefix routed to the CE site
If the CE WAN happe= ns to be a /64 prefix, could the 4rd leverage that?
What is the re= commendation there


Regards,
Usman



= --Apple-Mail-AB548679-0F6E-4E3E-B279-990F7F9D69EC-- From fgont@si6networks.com Mon Feb 11 15:20: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 7C50F21F8873 for ; Mon, 11 Feb 2013 15:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSGqs7evs1Vd for ; Mon, 11 Feb 2013 15:20:51 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id AA17C21F8837 for ; Mon, 11 Feb 2013 15:20:50 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U52fd-0004SZ-0T; Tue, 12 Feb 2013 00:20:21 +0100 Message-ID: <51197CAD.2050500@si6networks.com> Date: Mon, 11 Feb 2013 20:20:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> <0954EEA5-DF47-440B-A18E-8E483CBFE6E6@employees.org> In-Reply-To: <0954EEA5-DF47-440B-A18E-8E483CBFE6E6@employees.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 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: Mon, 11 Feb 2013 23:20:52 -0000 Hi, Ole, On 02/11/2013 06:42 PM, Ole Troan wrote: >>> I think that would be OK. Certainly it MUST NOT be more than >>> those 8 bytes, because beyond there lies encrypted bits (in the >>> general case). >> >> Quickly skimming through RFC4303, it looks like the first 8 bytes >> of the ESP header are referred to as "header" (with the other being >> referred to as "payload" and "trailer").. so it looks like ESP >> wouldn't really be a "special case". >> >> Should we clarify "how many bytes are included" for ESP, >> nevertheless? > > anything that has a next header field is not the upper layer header. > the middlebox doesn't have access to anything following the ESP > header. Not sure what you mean. You mean that we shouldn't refer to ESP as an "upper-layer header"? Or something else? >>> I actually believe that the SPI alone would suffice for ESP. >> >> It probably would, but.. since the Seq # is part of the header, and >> it is also transmitted in plain text, I'd personally deal with ESP >> as with the general case "the entire ESP header" (IMO, the fewer >> the "special cases", the better). > > what about ESP with NULL encryption? Please see Ran's response. > what you are trying to archive is "the first fragment should include > as much of the header chain as would be available if the packet was > reassembled", right? perhaps phrase it along those lines. I would specify everything "from the sender side", since that where the decision is to be made (e.g., "must include the entire IPv6 header chain available prior to any possible fragmentation"). FWIW, if ESP is used, the encrypted bytes are the payload (not the header), and hence we're fine. If tunneling is being employed (whether with IPsec or with something else), anything inside the tunnel is, strictly speaking, a different layer -- so including everything up till the ESP header would be okay. Thougths? 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.e.carpenter@gmail.com Mon Feb 11 23:58: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 7E06F21F8CA4 for ; Mon, 11 Feb 2013 23:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.446 X-Spam-Level: X-Spam-Status: No, score=-99.446 tagged_above=-999 required=5 tests=[AWL=-0.525, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiOTxHaxF+m2 for ; Mon, 11 Feb 2013 23:58:38 -0800 (PST) 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 CE08C21F8C54 for ; Mon, 11 Feb 2013 23:58:37 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so5603090wey.17 for ; Mon, 11 Feb 2013 23:58:36 -0800 (PST) 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:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=czv+DW+HRc7kbk5cA2XOdrZmyUy7Jpsf35hx9R1S134=; b=qdtjyidSDbdUOlGFe36BBobUcu9kUb/5OGPL52fsuAdoAC0tNgu4vvz+lKRy9MI2VA Nbufd49TKRHZF+ZmpBEv1Tx2annqWZpd/c5PL04qy0rx5hmAo6l+ndcGZ9JXD3q3LLji 1llwEbJRGxt/QRYR79nXDrL8TKz5GQT3oiQ+mAIf7MqiYS9TdnzriMOOYcpQb185RDUe wEIVdDGk3skrIZ+p60+RJwDKh74s7183dF9tdrZliVUWesPbgHEu9WUKeuKYDoAeMFlj 5zFwbxLwuJ+jElAJ7ZMrehISKxHZONY85BK2sM7IbM8zMS0bwTcuOx4yphdceTj7E/TI jMKg== X-Received: by 10.180.72.232 with SMTP id g8mr1285366wiv.0.1360655916902; Mon, 11 Feb 2013 23:58:36 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-200.as13285.net. [2.101.188.200]) by mx.google.com with ESMTPS id ec3sm34965738wib.1.2013.02.11.23.58.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 23:58:36 -0800 (PST) Message-ID: <5119F62C.10503@gmail.com> Date: Tue, 12 Feb 2013 07:58:36 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: 6MAN WG Last Call: References: <286350F5-34E0-452E-AC53-A6307286DBF4@employees.org> In-Reply-To: <286350F5-34E0-452E-AC53-A6307286DBF4@employees.org> Content-Type: text/plain; charset=UTF-8 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: Tue, 12 Feb 2013 07:58:38 -0000 I believe the draft needs one more spin in order to be precise about the number of bytes included in the upper layer header. Consider that in addition to the common transport headers, and ICMPv6, any protocol number defined in the IANA registry that is not an extension header might in theory occur as the final "next header". The phrasing in the draft at present does not tell a programmer what to do in the general case: Note: If there is an upper layer header, only the header (and not its payload) are considered part of the "entire IPv6 header chain". Regards Brian Carpenter From otroan@employees.org Tue Feb 12 00:14: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 42DA421F8C54 for ; Tue, 12 Feb 2013 00:14:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GwPrtu9Q1A2 for ; Tue, 12 Feb 2013 00:14:31 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7D21F8C66 for ; Tue, 12 Feb 2013 00:14:31 -0800 (PST) Received: from dhcp-lys02-vla252-10-147-116-66.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id EA0005E44; Tue, 12 Feb 2013 00:14:29 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? From: Ole Troan In-Reply-To: <51197CAD.2050500@si6networks.com> Date: Tue, 12 Feb 2013 09:14:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <98D218A5-B010-41D9-8BC9-3D5AA10D9FF1@employees.org> References: <819B2FEB-1915-4B56-B46A-0425FF8E502D@gmail.com> <51150D5B.4010907@gmail.com> <51157129.5080209@si6networks.com> <0954EEA5-DF47-440B-A18E-8E483CBFE6E6@employees.org> <51197CAD.2050500@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: ipv6@ietf.org, 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: Tue, 12 Feb 2013 08:14:32 -0000 > FWIW, if ESP is used, the encrypted bytes are the payload (not the > header), and hence we're fine. If tunneling is being employed (whether > with IPsec or with something else), anything inside the tunnel is, > strictly speaking, a different layer -- so including everything up = till > the ESP header would be okay. from the sender's perspective the ESP header is an intermediate header. you need to make it clearer in the draft what you expect to see on the = wire and how the host is supposed to behave. cheers, Ole= From despres.remi@laposte.net Tue Feb 12 00:58: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 97C9121F8A6F for ; Tue, 12 Feb 2013 00:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7EC+KxISa6J for ; Tue, 12 Feb 2013 00:58:22 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9824921F8A4E for ; Tue, 12 Feb 2013 00:58:21 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 7ADF17000145; Tue, 12 Feb 2013 09:58:20 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 567D9700009B; Tue, 12 Feb 2013 09:58:20 +0100 (CET) X-SFR-UUID: 20130212085820354.567D9700009B@msfrf2211.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <24FEDC2B-2452-4935-BC4C-5DBB091B3385@yahoo.com> Date: Tue, 12 Feb 2013 09:58:20 +0100 Message-Id: <07E59734-7110-418D-8447-2F72F388872D@laposte.net> References: <72E5DF27-0BBF-426C-8729-5C80128C2DC6@yahoo.com> <749EF226-7D28-46F4-A720-ECECCEF56100@yahoo.com> <1579EFDF-E751-4289-ADCA-C05E06834047@laposte.net> <24FEDC2B-2452-4935-BC4C-5DBB091B3385@yahoo.com> To: Usman Latif X-Mailer: Apple Mail (2.1499) Content-Type: multipart/alternative; boundary="Apple-Mail=_D132C0D3-0496-4497-A76B-D40904B44473" Cc: Miya Kohno , 6man 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, 12 Feb 2013 08:58:22 -0000 --Apple-Mail=_D132C0D3-0496-4497-A76B-D40904B44473 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2013-02-11 23:51, Usman Latif : > Hi Remi, >=20 >=20 >=20 > On 11/02/2013, at 9:13 PM, R=E9mi Despr=E9s =20= >> ... >>> So if I understand it correctly, if a PE-CE link already has a /127 = prefix assigned to it- and we wanted to use the CE as a 4rd CE, we'll = have to assign an additional IPv6 prefix to the CE with 64-bit IIDs? >>>=20 >>> Pls share little detail with me in a scenario where a SP already has = /127 with CEs and 4rd is needed from the CE >>=20 >> According to RFC 6164, /127 prefixes are used ONLY on inter-router = link.=20 >> They cannot be used as customer-site IPv6 prefixes which, to comply = with https://tools.ietf.org/html/rfc4291#section-2.5.1, MUST permit = 64-bit IIDs.=20 >>=20 >> Each 4rd CE MUST therefore be delegated at least one IPv6 prefix = having at most 64 bits (this doesn't depend on its WAN link having or = not a /127).=20 >>=20 >> RD >=20 >=20 > Yes 6164 is only for inter-router links > I was under the impression that 4rd CE might use the WAN IPv6 address = for stateless tunnelling of IPv4 inside IPv6 > Maybe this was a misunderstanding(?) In the 4rd specification, CE IPv6 prefixes are at most /64. See Figure 5 in particular: +----------+---+-+-+------+---+ +--------------+-+-+------+---+ |CE v6 prfx| 0 |V|0|v4 add|CNP| |BR IPv6 prefix|V|0|v4 add|CNP| +----------+-|-+-+-|+-----+---+ +--------------+-+-+------+---+ : =3D<64 : | :8:8: 32 :16 : : 64 :8:8: 32 :16 : | Padding to /64 RD =20 > Or is it really upto the operator whether he wants to leverage the CE = WAN IPv6 prefix or the allocated IPv6 prefix routed to the CE site > If the CE WAN happens to be a /64 prefix, could the 4rd leverage that? > What is the recommendation there >=20 >=20 > Regards, > Usman >=20 >=20 >=20 --Apple-Mail=_D132C0D3-0496-4497-A76B-D40904B44473 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 osmankh@yahoo.com> :
Hi = Remi,



On 11/02/2013, at 9:13 PM, = R=E9mi Despr=E9s <despres.remi@laposte.net>&= nbsp;
...
So if I understand it = correctly, if a PE-CE link already has a /127 prefix assigned to it- and = we wanted to use the CE as a 4rd CE, we'll have to assign an additional = IPv6 prefix to the CE with 64-bit IIDs?

Pls = share little detail with me in a scenario where a SP already has /127 = with CEs and 4rd is needed from the = CE

According to RFC = 6164, /127 prefixes are used ONLY on inter-router = link. 
They cannot be used as customer-site IPv6 = prefixes which, to comply with https://tools.i= etf.org/html/rfc4291#section-2.5.1, MUST permit 64-bit = IIDs. 

Each 4rd CE MUST = therefore be delegated at least one IPv6 prefix having at most 64 = bits (this doesn't depend on its WAN link having or not = a /127). 

RD


Yes 6164 is only for inter-router = links
I was under the impression that 4rd CE might use the WAN = IPv6 address for stateless tunnelling of IPv4 inside = IPv6
Maybe this was a = misunderstanding(?)

In the 4rd = specification, CE IPv6 prefixes are at most /64.
See Figure 5 = in particular:

  =  +----------+---+-+-+------+---+     = +--------------+-+-+------+---+
   |CE v6 prfx| 0 = |V|0|v4 add|CNP|     |BR IPv6 prefix|V|0|v4 = add|CNP|
   +----------+-|-+-+-|+-----+---+   =   +--------------+-+-+------+---+
   :   = =3D<64   : | :8:8:  32  :16 :     :   =    64      :8:8:  32  :16 = :
                = |
          Padding to = /64

RD


<= div>
 
Or is it really upto the operator whether he = wants to leverage the CE WAN IPv6 prefix or the allocated IPv6 prefix = routed to the CE site
If the CE WAN happens to be a /64 = prefix, could the 4rd leverage that?
What is the = recommendation = there


Regards,
Usman



= --Apple-Mail=_D132C0D3-0496-4497-A76B-D40904B44473-- From v6ops@globis.net Tue Feb 12 03:35: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 78B6E21F8D17 for ; Tue, 12 Feb 2013 03:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cjIPHbvF82d for ; Tue, 12 Feb 2013 03:35:11 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 105C521F8CBB for ; Tue, 12 Feb 2013 03:35:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6C3F3870115; Tue, 12 Feb 2013 12:29:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 B++9Qt62YT6g; Tue, 12 Feb 2013 12:29:25 +0100 (CET) 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 5ED5687010B; Tue, 12 Feb 2013 12:29:25 +0100 (CET) Message-ID: <511A278F.3080909@globis.net> Date: Tue, 12 Feb 2013 12:29:19 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Fernando Gont , vishwas.manral@hp.com Subject: Re: 6MAN WG Last Call: References: <286350F5-34E0-452E-AC53-A6307286DBF4@employees.org> In-Reply-To: <286350F5-34E0-452E-AC53-A6307286DBF4@employees.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "ipv6@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, 12 Feb 2013 11:35:12 -0000 I have read this draft and support the work. The intention is good. The detail is thorny. Substantive Comment: I think you're going to be asked lots of questions about what constitutes an "IPv6 header chain," and to provide a tighter specification of where it ends. I'm sure there are people who wouldn't necessarily regard the contents of the TCP header as being an integral part of an IPv6 header chain. If I read RFC2460 "upper layer - a protocol layer immediately above IPv6. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IPv6 such as IPX, AppleTalk, or IPv6 itself." So to me, a first-fragment that contained a complete IPv6 header with a next-header value of 6 (an upper layer protocol) , but without containing the TCP header itself, could also be considered a valid IPv6 header chain. However I'm sure we'd agree that'd be pretty useless for stateless firewall filtering based solely on the first-fragment. On the other hand, I know plenty of people who will certainly want to apply a very granular filter on ICMPv6 Type and Code fields. Some ICMPv6 messages are required for normal operations, but others are useful in network reconnaissance. Yet officially ICMPv6 is not called a header AFAIK: it's a "message" with a "psuedo-header." So I think we'll probably have to end up with an explicit specification for the next-header values that constitute the first "upper-layer protocol" together with the number of octets of that next header that are mandatory to include, plus a default "last IPv6 header + X bytes" for any unknown/new headers. An alternative would be to make this an Informational RFC, and let developers use "common sense" on "ensuring that sufficient information is included in the first fragment for a packet classifier located on the forwarding path to be able to classify a packet as matching a filter with a low probability of either false positives or false negatives" Editorial > A lot of the switches and Routers in the internet do hardware based > forwarding. To be able to achieve a level of throughput, there is a > fixed maximum number of clock cycles dedicated to each packet. > However with the use of unlimited options and header interleaving, > larger packets with a lot of interleaving might have to be forwarded > to the software. This is one reason why the maximum size of valid > packets with interleaved headers needs to be limited. It ain't just firewalls: there's all sorts of middleware boxes and packet classifiers. Suggest: Various devices on the internet forward or process packets via a number of alternative internal paths, each of which may be optimised to handle specific packet types in different ways. Packets are generally sent for processing by the various paths based on the complexity of the packet, with the most optimised path being the fastest (low latency and/or high throughput) but also the most limited, whilst other paths may be able to handle more complex packet formats, albeit slower (higher latency and/or lower throughput). Some of these paths may be implemented in hardware, with a fixed number of clock cycles dedicated to processing each packet. Larger packets with a lot of headers may have to be processed by the more generic, slower paths, leading to lower overall network performance. This is one reason why the maximum size of header chains needs to be limited. Additionally, stateless processing of packets (where each packet can be processed independently) can be far more efficient and require less resources than stateful processing (where a device has to maintain state between related packets, and match newly arriving packets to previously observed flows). Fragmentation of the IPv6 header chain across multiple fragments may force a device into stateful processing, again reducing overall network or device performance. Or perhaps more likely, the packet will simply be dropped, or not correctly processed by this device. Add to the list under 5:? o Specific transport-layer information e.g. ICMPv6 message Type and Code fields. s/When presented with fragmented traffic, many of such firewalls typically enforce their policy only on the first fragment of a packet,/ When presented with fragmented traffic, many such firewalls typically enforce their policy based only on the information contained in the first fragment of a packet,/ Small clarification: s/On the other hand, first-fragments that fail to include the entire IPv6 header chain have never been formally deprecated and thus, in theory, might be legitimately generated./ On the other hand, first-fragments that fail to include the entire IPv6 header chain have never been formally deprecated and thus, in theory, might be legitimately generated by end nodes, but incorrectly dropped by firewalls./ Suggest lower case NOT as there's no special meaning here, just emphasis. s/packets that do NOT contain/packets that do not contain/ regards, RayH Ole Troan wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Security and Interoperability Implications of Oversized IPv6 Header Chains > Author(s) : F Gont, V. Manral > Filename : draft-ietf-6man-oversized-header-chain-02 > Pages : 13 > Date : 2012-11-05 > > https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ > > as a Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the author. This last call will end on 2013-02-25. > > The chairs would also like to solicit a few people to do a detailed review of this document. Please contact the chairs directly. > > Regards, > > Bob Hinden & Ole Trøan From rja.lists@gmail.com Tue Feb 12 10:15: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 DB54A21F906B for ; Tue, 12 Feb 2013 10:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd0bZmyrKbk5 for ; Tue, 12 Feb 2013 10:15:23 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 25F9C21F905E for ; Tue, 12 Feb 2013 10:15:23 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id p16so230020vcq.1 for ; Tue, 12 Feb 2013 10:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=Lj1+VZGPfkjMukPsY43O5TppOWkIzYjCnV8N7tK47hc=; b=xKOgA6t6GUVfjaM4vPlhOuDDo/fyEIq8BGon2ZIXKQMJQ0ZDafCBodS60UMxKMkiGv 2t3DtxKb+KHIrbQcmUxdq010Fwxd8+CqGOSKabGzAgJJszLgMC9DWOWS8lwEtJy2/6Yr UxfB4PNrGQssk81CrYP8tcmsRVGJKaI6IUJAVOPGCdux09+K1R4wNGiiEKAraq0QLjnT 0Gz94IupRQnergcJHYGbcIydc8O1AVXX61W6jvyfw7yVvj635hEt8Aor9eGpKGJt+eGg B3S4iKXOYe7J0uLPcAiTBOzxWaqr1RxPvJS3MsD287Q7wNykDl0R0XkmBSKj6Vca14Rz fYQw== X-Received: by 10.58.132.170 with SMTP id ov10mr24737871veb.57.1360692918506; Tue, 12 Feb 2013 10:15:18 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id x17sm66041542vdi.1.2013.02.12.10.15.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:15:17 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 6MAN WG Last Call: Date: Tue, 12 Feb 2013 13:15:16 -0500 Message-Id: To: ipv6@ietf.org 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: Tue, 12 Feb 2013 18:15:24 -0000 I support publishing this draft as a Proposed Standard. There has been more than ample time to review the draft, and various minor updates already have been made, so this seems ready to shop. Ran From brian.e.carpenter@gmail.com Thu Feb 14 01:11: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 53F5121F8640 for ; Thu, 14 Feb 2013 01:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.886 X-Spam-Level: X-Spam-Status: No, score=-99.886 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP0JTuPcGPPW for ; Thu, 14 Feb 2013 01:11:30 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id CD26B21F8632 for ; Thu, 14 Feb 2013 01:11:29 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t57so1778945wey.13 for ; Thu, 14 Feb 2013 01:11:28 -0800 (PST) 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:subject:content-type:content-transfer-encoding; bh=TAkaetIRs5usbgSnpZTDSngBpm+A5BK8EGnM9aWtvD0=; b=Oxug6rPrVpUdFdtsD07ObmWHP8uD3Dep8qzdbH4aEvoqwAJtTQUpEa91zoO7hFQYgN h8kQhivmv8/+l9Pe1KxxX9hhBN0NhWa2+NlW5Q6/3cXpJklYQhzwYdkoc9XnvM+8/qIl IUlHeuSrwbmBYOUfLOGKbyGh449tCFnoRMlDWDpbbb+FvGteWunf+sFIKurIfhc56QkU 5jJ3yyyTySCqLLs3DMeW70OuGZTVEK8hx++hvcdy/7urPP9Z5RwKRGJh8Tw8tkX9yGjb ecz4swXfh2mYbNLXp/J1F823RU0Dt/yuygRv6awEPm5U0fTMmgF3kDyo6SN66/U5W+L5 pUYQ== X-Received: by 10.180.93.73 with SMTP id cs9mr4380698wib.7.1360833088513; Thu, 14 Feb 2013 01:11:28 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-171.as13285.net. [2.101.189.171]) by mx.google.com with ESMTPS id bj9sm18179388wib.4.2013.02.14.01.11.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 01:11:27 -0800 (PST) Message-ID: <511CAA49.1050106@gmail.com> Date: Thu, 14 Feb 2013 09:11:37 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: draft-carpenter-6man-ext-transmit-01.txt Content-Type: text/plain; charset=UTF-8 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, 14 Feb 2013 09:11:36 -0000 https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/ There was some discussion of this draft when it came out, but nothing that led to any specific changes. We should perhaps emphasise that it's complementary to draft-ietf-6man-oversized-header-chain. I'd like to ask for opinions about taking this draft forward. I won't be in Orlando, but the other author (Sheng) will be. Regards Brian From v6ops@globis.net Thu Feb 14 13:21: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 0C48D21F858C for ; Thu, 14 Feb 2013 13:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoI0VHpjGxLv for ; Thu, 14 Feb 2013 13:21:12 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46C21F889A for ; Thu, 14 Feb 2013 13:21:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3C5C08700EB; Thu, 14 Feb 2013 22:15:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 JM+5f1JGjKK0; Thu, 14 Feb 2013 22:15:26 +0100 (CET) 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 2BAA5870088; Thu, 14 Feb 2013 22:15:26 +0100 (CET) Message-ID: <511D53E7.3030501@globis.net> Date: Thu, 14 Feb 2013 22:15:19 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-carpenter-6man-ext-transmit-01.txt References: <511CAA49.1050106@gmail.com> In-Reply-To: <511CAA49.1050106@gmail.com> 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: Thu, 14 Feb 2013 21:21:13 -0000 Brian E Carpenter wrote: > https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/ > > There was some discussion of this draft when it came out, but nothing > that led to any specific changes. We should perhaps emphasise that > it's complementary to draft-ietf-6man-oversized-header-chain. > > I'd like to ask for opinions about taking this draft forward. > > I won't be in Orlando, but the other author (Sheng) will be. > > Regards > Brian > > You can write what you like about firewalls needing to have an explicit policy configured (manually) before dropping any packets. And this standard will then (quite rightly) be ignored by every single firewall manufacturer I know. If an extension proves itself safe, easily parse-able, and useful, it will be transported over the public Internet. If it doesn't, it will get dropped. regards, RayH From brian.e.carpenter@gmail.com Fri Feb 15 00:23: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 4107721E803C for ; Fri, 15 Feb 2013 00:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.481 X-Spam-Level: X-Spam-Status: No, score=-99.481 tagged_above=-999 required=5 tests=[AWL=-0.560, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5ALb+Vd93bw for ; Fri, 15 Feb 2013 00:23:48 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2669621E8039 for ; Fri, 15 Feb 2013 00:23:47 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id r5so2615820wey.18 for ; Fri, 15 Feb 2013 00:23:47 -0800 (PST) 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=KLWXuoFxlmfiQ1B7yZEIsDdbmNpSxMiw5LXesO2IUa0=; b=bGy0mhwDqfJ7ECCci2wLzIGskyG/DDO8qhcnF9RHSDF116KkxdmTYLDBCbr7ufcQNz bOEaAuFLbd0+GnSFMBBjh/YiN6vJ7fB4+ekTIIJPRvDqhZT9gVsQR4osy5kEwUe50QiB 3ao9X505ZStbFuOJ+b9zN1Mrs00gf0KSykdX3gYMYHXyXxH1RDAaVYkxQY0fakr4VPXx rPrNuA13pNpmWriS6Q5o29FLBFF9+9X+/zN1zFQ/sSaO4nhyctaDmxHpOVyF4Rg2UzaN kCTYkK3v80+wHY9jHuAFqGMv2atiuL0eGyIWse2OlyqQMWrU1TG2NCiL6h45oVl8fZVK HIeg== X-Received: by 10.180.79.201 with SMTP id l9mr2392978wix.20.1360916627274; Fri, 15 Feb 2013 00:23:47 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-220.as13285.net. [2.101.188.220]) by mx.google.com with ESMTPS id ex15sm3443608wid.5.2013.02.15.00.23.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 00:23:46 -0800 (PST) Message-ID: <511DF0A0.6080005@gmail.com> Date: Fri, 15 Feb 2013 08:24:00 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Re: draft-carpenter-6man-ext-transmit-01.txt References: <511CAA49.1050106@gmail.com> <511D53E7.3030501@globis.net> In-Reply-To: <511D53E7.3030501@globis.net> Content-Type: text/plain; charset=UTF-8 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: Fri, 15 Feb 2013 08:23:49 -0000 On 14/02/2013 21:15, Ray Hunter wrote: > > Brian E Carpenter wrote: >> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/ >> >> There was some discussion of this draft when it came out, but nothing >> that led to any specific changes. We should perhaps emphasise that >> it's complementary to draft-ietf-6man-oversized-header-chain. >> >> I'd like to ask for opinions about taking this draft forward. >> >> I won't be in Orlando, but the other author (Sheng) will be. >> >> Regards >> Brian >> >> > You can write what you like about firewalls needing to have an explicit > policy configured (manually) before dropping any packets. Ray, the IETF is supposed to make the Internet work better. So we should write down requirements for that to happen. > And this standard will then (quite rightly) be ignored by every single > firewall manufacturer I know. That parenthesis is a value judgement, but in any case, the idea of the draft is to push implementors in the direction of parsing all well-defined extensions, and of making policy control possible. > If an extension proves itself safe, easily parse-able, and useful, it > will be transported over the public Internet. If it doesn't, it will get > dropped. At the moment this is impossible. There is no place for firewall implementors to find a master list of all well-defined extension headers and no way for site IT managers to configure firewalls to block or allow specific extension headers. So there is no way for a new extension header to prove itself safe and viable. It's pure Catch 22. Firewalls should be designed to make new extension headers subject to user control, and the IETF should structure its designs, documents and IANA registries to make life as easy as possible for both firewall implementors and users. That's what we need to fix. We can maybe state it more clearly in the draft; thanks for pointing to the existing Catch 22. Brian From v6ops@globis.net Fri Feb 15 01:39: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 205FC21F8770 for ; Fri, 15 Feb 2013 01:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj6LQIREWKfD for ; Fri, 15 Feb 2013 01:39:47 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD821F8495 for ; Fri, 15 Feb 2013 01:39:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id EDD728700BB; Fri, 15 Feb 2013 10:31:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 Rvqsqj2DQcXW; Fri, 15 Feb 2013 10:31:40 +0100 (CET) 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 A36C5870056; Fri, 15 Feb 2013 10:31:40 +0100 (CET) Message-ID: <511E0076.4050700@globis.net> Date: Fri, 15 Feb 2013 10:31:34 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-carpenter-6man-ext-transmit-01.txt References: <511CAA49.1050106@gmail.com> <511D53E7.3030501@globis.net> <511DF0A0.6080005@gmail.com> In-Reply-To: <511DF0A0.6080005@gmail.com> Content-Type: multipart/alternative; boundary="------------020308050609060307060806" 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, 15 Feb 2013 09:39:49 -0000 This is a multi-part message in MIME format. --------------020308050609060307060806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Brian E Carpenter > 15 February 2013 09:24 > On 14/02/2013 21:15, Ray Hunter wrote: >> Brian E Carpenter wrote: >>> https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/ >>> >>> There was some discussion of this draft when it came out, but nothing >>> that led to any specific changes. We should perhaps emphasise that >>> it's complementary to draft-ietf-6man-oversized-header-chain. >>> >>> I'd like to ask for opinions about taking this draft forward. >>> >>> I won't be in Orlando, but the other author (Sheng) will be. >>> >>> Regards >>> Brian >>> >>> >> You can write what you like about firewalls needing to have an explicit >> policy configured (manually) before dropping any packets. > > Ray, the IETF is supposed to make the Internet work better. So we should > write down requirements for that to happen. Well IMHO I think the requirements are precisely the other way around: extensions should be simple to parse, demonstrably not a security issue or likely to cause harm, and useful: not that firewalls should blindly pass everything thrown at them. Hop by hop has already been labelled potentially harmful in http://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05. The market is still deciding what headers are "good". >> And this standard will then (quite rightly) be ignored by every single >> firewall manufacturer I know. > > That parenthesis is a value judgement, but in any case, the idea of the > draft is to push implementors in the direction of parsing all well-defined > extensions, and of making policy control possible. Agreed. I'd support a draft with these goals, but let's keep it realistic. >> If an extension proves itself safe, easily parse-able, and useful, it >> will be transported over the public Internet. If it doesn't, it will get >> dropped. > > At the moment this is impossible. There is no place for firewall > implementors to find a master list of all well-defined extension headers > and no way for site IT managers to configure firewalls to block or allow > specific extension headers. So there is no way for a new extension > header to prove itself safe and viable. It's pure Catch 22. Providing a clear list of extensions in a repository, what their benefits are, and how they work, is a completely different matter to mandating behaviour of middleware boxes that is directly contradictory to current industry best-practice. > Firewalls should be designed to make new extension headers subject > to user control, and the IETF should structure its designs, documents and > IANA registries to make life as easy as possible for both firewall > implementors and users. Agreed. Extensions should also clearly have been designed with firewalls and other middleware boxes in mind. And new extensions should too. Firewall code and other middleware box code will always significantly lag IETF standards. I don't really see how the Uniform Format header structure defined in http://tools.ietf.org/html/rfc6564 truly addresses the firewall issue. If we were starting from scratch I'd prefer that unknown extensions should be easily "strippable", rather than having to drop the entire packet if they cannot be parsed, or still having to traverse the full chain without truly understanding the contents and then passing that unknown content into a secure zone. How you achieve that practically I don't really know. Thinking out loud, we could potentially define yet another new extension header that defines a fork in the header chain: next header field = following(optional) header extensions,plus length to reach the next header as per RFC6564; final header field (contained as header specific data within the new header) = top level protocol of the final header value e.g. TCP= 6, plus offset to reach the final payload headerin either octets or 8-octet units. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | FinalHeader | offset to | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | final header | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ That in itself of course will not be fully backwards compatible. But at least it would be a once-off action. And firewalls could strip out the optional headers, whilst easily locating and parsing payload data. regards, RayH > That's what we need to fix. We can maybe state it more clearly in the draft; > thanks for pointing to the existing Catch 22. > > Brian > Ray Hunter > 14 February 2013 22:15 > You can write what you like about firewalls needing to have an explicit > policy configured (manually) before dropping any packets. > And this standard will then (quite rightly) be ignored by every single > firewall manufacturer I know. > > If an extension proves itself safe, easily parse-able, and useful, it > will be transported over the public Internet. If it doesn't, it will get > dropped. > > regards, > RayH > ------------------------------------------------------------------------ --------------020308050609060307060806 Content-Type: multipart/related; boundary="------------090805040609090107010201" --------------090805040609090107010201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
15 February 2013 09:24
On 14/02/2013 21:15, Ray Hunter wrote:

Brian E Carpenter wrote:

https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/

There was some discussion of this draft when it came out, but nothing
that led to any specific changes. We should perhaps emphasise that
it's complementary to draft-ietf-6man-oversized-header-chain.

I'd like to ask for opinions about taking this draft forward.

I won't be in Orlando, but the other author (Sheng) will be.

Regards
   Brian



You can write what you like about firewalls needing to have an explicit
policy configured (manually) before dropping any packets.


Ray, the IETF is supposed to make the Internet work better. So we should
write down requirements for that to happen.

Well IMHO I think the requirements are precisely the other way around: extensions should be simple to parse, demonstrably not a security issue or likely to cause harm, and useful:  not that firewalls should blindly pass everything thrown at them. Hop by hop has already been labelled potentially harmful in http://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05. The market is still deciding what headers are "good". 
And this standard will then (quite rightly) be ignored by every single
firewall manufacturer I know.


That parenthesis is a value judgement, but in any case, the idea of the
draft is to push implementors in the direction of parsing all well-defined
extensions, and of making policy control possible.
Agreed. I'd support a draft with these goals, but let's keep it realistic.


If an extension proves itself safe, easily parse-able, and useful, it
will be transported over the public Internet. If it doesn't, it will get
dropped.


At the moment this is impossible. There is no place for firewall
implementors to find a master list of all well-defined extension headers
and no way for site IT managers to configure firewalls to block or allow
specific extension headers. So there is no way for a new extension
header to prove itself safe and viable. It's pure Catch 22.




Providing a clear list of extensions in a repository, what their 
benefits are, and how they work, is a completely different matter to 
mandating behaviour of  middleware boxes that is directly contradictory 
to current industry best-practice.



  

    
Firewalls should be designed to make new extension headers subject
to user control, and the IETF should structure its designs, documents and
IANA registries to make life as easy as possible for both firewall
implementors and users.


  



Agreed. Extensions should also clearly have been designed with firewalls
 and other middleware boxes in mind. And new extensions should too.



Firewall code and other middleware box code will always significantly 
lag IETF standards.  I don't really see how the Uniform 
Format header structure defined in http://tools.ietf.org/html/rfc6564 
truly addresses the firewall issue.

  

If we were starting from scratch I'd prefer that unknown 
extensions should be easily "strippable", rather than having to drop the
 entire packet if they cannot be parsed, or still having to traverse the
 full chain without truly understanding the contents and then passing 
that unknown content into a secure zone.



How you achieve that practically I don't really know.



Thinking out loud, we could potentially define yet another new 
extension header that defines a fork in the header chain: next header 
field = following (optional) header extensions,
 plus length to reach the next header as per RFC6564; final header field
 (contained as header specific data within the new header) =  top
 level protocol of the final header value e.g. TCP= 6, plus
 offset to reach the final payload header in either 
octets or 8-octet units.

  

      0                   1                   
2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |  Next Header  |  Hdr Ext 
Len  | Final 
Header  | offset to     |

     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     | final header  |             
                                  |

     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  

That in itself of course will not be fully backwards compatible. But at 
least it would be a once-off action. And firewalls could strip out the 
optional headers, whilst easily locating and parsing payload data.

  

regards,

RayH




  

    
That's what we need to fix. We can maybe state it more clearly in the draft;
thanks for pointing to the existing Catch 22.

    Brian


  

  
 	
      
   
  14 February 2013 
22:15

  
You can write what 
you like about firewalls needing to have an explicit
policy 
configured (manually) before dropping any packets.
And this standard 
will then (quite rightly) be ignored by every single
firewall 
manufacturer I know.

If an extension proves itself safe, easily 
parse-able, and useful, it
will be transported over the public 
Internet. If it doesn't, it will get
dropped.

regards,
RayH
 







--------------090805040609090107010201
Content-Type: image/jpeg; x-apple-mail-type=stationery;
 name="compose-unknown-contact.jpg"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="compose-unknown-contact.jpg"

/9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC
AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC
AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR
CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK
BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA
AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA
DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ
VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4
v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx
+a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR
UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab
eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz
hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi
yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y
zqnlfp6FrqbwawG8/9k=
--------------090805040609090107010201--

--------------020308050609060307060806--

From brian.e.carpenter@gmail.com  Fri Feb 15 06:46: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 468AC21F8AB4 for ; Fri, 15 Feb 2013 06:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.536
X-Spam-Level: 
X-Spam-Status: No, score=-99.536 tagged_above=-999 required=5 tests=[AWL=-0.615, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YsP8JCSF3N2 for ; Fri, 15 Feb 2013 06:46:08 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9747021F8AB2 for ; Fri, 15 Feb 2013 06:46:08 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id x48so3115422wey.9 for ; Fri, 15 Feb 2013 06:46:07 -0800 (PST)
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=jhXOKZPE1jqpA2NVNTP+L9vCKRZC3Kbi/1pBstXqwc0=; b=qoO1yKsrZ9dD41HZii9ffcPQXrLAFA3R/bimdX2beBic6i7j+Ut/8yUZcd+gTe/1uv /cC9n5agEvLP1j0hk5xuK+fueVTwUF/ZUuuhmbfYJDfTdptQ+KS2bTHtANQ61PQys3Bz s0beBFyacufikNswoQsuwsWXfs7Fg6lFqTchikDIDgFqDzFTBoLKEb29PHF55V0l5EhS J0OFSBppNOMK6faDUythQfJU0bs8yhcDek9doRA6kMK8guRSJ+ep9J5V/i8KCHrdHuuI zGPojRKs1YqaRB7n3tCrFrdU4//UJKqYMjOf8PAJHAWq2peFbX08xtEJfiAE7Nly7/F6 P0aQ==
X-Received: by 10.180.72.148 with SMTP id d20mr6255324wiv.31.1360939563743; Fri, 15 Feb 2013 06:46:03 -0800 (PST)
Received: from [192.168.1.65] (host-2-101-188-220.as13285.net. [2.101.188.220]) by mx.google.com with ESMTPS id ek4sm5288151wib.11.2013.02.15.06.46.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 06:46:02 -0800 (PST)
Message-ID: <511E4A38.3080601@gmail.com>
Date: Fri, 15 Feb 2013 14:46:16 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter 
Subject: Re: draft-carpenter-6man-ext-transmit-01.txt
References: <511CAA49.1050106@gmail.com> <511D53E7.3030501@globis.net> <511DF0A0.6080005@gmail.com> <511E0076.4050700@globis.net>
In-Reply-To: <511E0076.4050700@globis.net>
Content-Type: text/plain; charset=UTF-8
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: Fri, 15 Feb 2013 14:46:09 -0000

Ray,

We have different prespectives. The next version of the draft will
try to make the case a bit clearer. On one specific point:

>> Thinking out loud, we could potentially define yet another new extension header 
>> that defines a fork in the header chain: next header field = following 
>> (optional) header extensions, plus length to reach the next header as per 
>> RFC6564; final header field (contained as header specific data within the new 
>> header) =  top level protocol of the final header value e.g. TCP= 6, plus offset 
>> to reach the final payload header in either octets or 8-octet units.

Please look at http://tools.ietf.org/id/draft-zhang-6man-offset-option-01.txt,
although it got no traction here.

   Brian

From bob.hinden@gmail.com  Sun Feb 17 03:37: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 5FA4F21F85ED for ; Sun, 17 Feb 2013 03:37:59 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiRgQfOejRC7 for ; Sun, 17 Feb 2013 03:37:59 -0800 (PST)
Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id A619B21F85C6 for ; Sun, 17 Feb 2013 03:37:58 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id t10so2576967eei.35 for ; Sun, 17 Feb 2013 03:37:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=FN3S4LWTSe1EPGK8NvDA1HSUo/YCy1bVz9w1amiquzo=; b=p0x020K7buDot6eSZSV072kQe66N6JZVMVZWbQL4NFnhFtjeE3jECaZgZwjcibD/Ot hLy7xG2RpD3thdBdGtUlfCfBz3kiHI9shb4b9heNtIxvoqytgzgjPx93oMYQIGDxobeJ N/qzWNGI101oUuXz38sJnk7I5ot6kqI/briwXNvqKOVIHvMEjLiZ2u7Y8WifUdGoxC/X FIAeDIBIt63zZYjZM8DWpGuWiJSHsHMFqWfzK5/Cl2ux5Jv013MEu+lj9JqdsuNRxLHI LXbRufK526fTwh1v3AJM50AOEIOKeUP4oCKY9BTRfueN+pc9LATa23cZg3Z8ZqNX6pch dS/w==
X-Received: by 10.14.3.70 with SMTP id 46mr31964657eeg.2.1361101077696; Sun, 17 Feb 2013 03:37:57 -0800 (PST)
Received: from [172.24.248.238] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPS id q5sm92883737eep.11.2013.02.17.03.37.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Feb 2013 03:37:56 -0800 (PST)
Subject: Re: draft-carpenter-6man-ext-transmit-01.txt
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Bob Hinden 
In-Reply-To: <511DF0A0.6080005@gmail.com>
Date: Sun, 17 Feb 2013 13:37:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <511CAA49.1050106@gmail.com> <511D53E7.3030501@globis.net> <511DF0A0.6080005@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1283)
Cc: Ray Hunter , Bob Hinden , 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, 17 Feb 2013 11:37:59 -0000

Just to focus on one area at the moment:=20

>=20
>> If an extension proves itself safe, easily parse-able, and useful, it
>> will be transported over the public Internet. If it doesn't, it will =
get
>> dropped.
>=20
> At the moment this is impossible. There is no place for firewall
> implementors to find a master list of all well-defined extension =
headers
> and no way for site IT managers to configure firewalls to block or =
allow
> specific extension headers. So there is no way for a new extension
> header to prove itself safe and viable. It's pure Catch 22.

My personal view is that it is very useful to have a single IANA =
registry that lists all IPv6 extension headers.  I would like to think I =
am fairly knowledgable about IPv6, and it's hard for me to find them =
all.  This is a win independent of what policy we recommend that =
firewall/middlebox/etc. vendors support.  Let's not loose that.

Bob



From brian.e.carpenter@gmail.com  Sun Feb 17 04:16:16 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 2CD5421F89AF for ; Sun, 17 Feb 2013 04:16:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.891
X-Spam-Level: 
X-Spam-Status: No, score=-100.891 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwHhq-1VFLbD for ; Sun, 17 Feb 2013 04:16:15 -0800 (PST)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6102F21F89A4 for ; Sun, 17 Feb 2013 04:16:15 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id es5so3817206wgb.17 for ; Sun, 17 Feb 2013 04:16:14 -0800 (PST)
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=iUvzHqullwKD9eCvoMtmZSOy0b3JC2xU5UnmeZaHL6Y=; b=DJKHhIAnRfccvMx9la75r5kEHrfBXK8e8QG2wq9KGvtphnm93yjSoxDAInDto53Wpm K2JF87qnH/G7kqrU2xCs82yOEUGIx2j/AiclE8rwKvhllRp5cTe+SCupjPlU6iQwUyXC dZKWKcppJMfyhkWwqdLwhsV3MF/rCENR+6xoUPk3V1xha8oS9ym66hkiHrLoCvoDYS3K kcYCmbaRE6PhX+MDvIbn2Z0OxxWBYql6DL1BHIiYCoR0wYeuNsCe+YcGmsfqWu8GSnjA 7Xxt2Uf6mezLi8v1f8dVy9iPcOPIgJq4WNOymoroO88xk2lSefRr5FuqK8Js8+WqV35E aPew==
X-Received: by 10.180.81.2 with SMTP id v2mr5927391wix.17.1361103374176; Sun, 17 Feb 2013 04:16:14 -0800 (PST)
Received: from [192.168.1.65] (host-2-101-189-232.as13285.net. [2.101.189.232]) by mx.google.com with ESMTPS id ex15sm14374282wid.5.2013.02.17.04.16.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 04:16:13 -0800 (PST)
Message-ID: <5120CA0C.6090607@gmail.com>
Date: Sun, 17 Feb 2013 12:16:12 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Bob Hinden 
Subject: Re: draft-carpenter-6man-ext-transmit-01.txt
References: <511CAA49.1050106@gmail.com> <511D53E7.3030501@globis.net> <511DF0A0.6080005@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ray Hunter , 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, 17 Feb 2013 12:16:16 -0000

On 17/02/2013 11:37, Bob Hinden wrote:
> Just to focus on one area at the moment: 
> 
>>> If an extension proves itself safe, easily parse-able, and useful, it
>>> will be transported over the public Internet. If it doesn't, it will get
>>> dropped.
>> At the moment this is impossible. There is no place for firewall
>> implementors to find a master list of all well-defined extension headers
>> and no way for site IT managers to configure firewalls to block or allow
>> specific extension headers. So there is no way for a new extension
>> header to prove itself safe and viable. It's pure Catch 22.
> 
> My personal view is that it is very useful to have a single IANA registry that lists all IPv6 extension headers.  I would like to think I am fairly knowledgable about IPv6, and it's hard for me to find them all.  This is a win independent of what policy we recommend that firewall/middlebox/etc. vendors support.  Let's not loose that.

Indeed. That is one of the two proposals in the draft.

The other proposal is to specify what firewalls should do to make extension
headers deployable (subject to site policy). I think this is complementary to
the oversized-header-chain draft, which is necessary to remove some cases
that are unreasonable for any firewall to handle.

    Brian

From bill.jouris@insidethestack.com  Sun Feb 17 16:05: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 A094D21F89EE for ; Sun, 17 Feb 2013 16:05:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvCOZVoKWydL for ; Sun, 17 Feb 2013 16:05:36 -0800 (PST)
Received: from nm15-vm0.access.bullet.mail.sp2.yahoo.com (nm15-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.164]) by ietfa.amsl.com (Postfix) with ESMTP id 15C2821F8996 for ; Sun, 17 Feb 2013 16:05:36 -0800 (PST)
Received: from [98.139.44.106] by nm15.access.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2013 00:05:33 -0000
Received: from [98.139.44.64] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2013 00:05:33 -0000
Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 18 Feb 2013 00:05:33 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 481985.44558.bm@omp1001.access.mail.sp2.yahoo.com
Received: (qmail 87734 invoked by uid 60001); 18 Feb 2013 00:05:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361145932; bh=qIgSh+WXZgM8TMl+rOwRHs6EgstIDwbnFrFkX9ogAnM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=h28XLSUmu6kdPfLCwCBtQba5XMyqU6YDutIu9QR2YIXjIfhJtXC91CbY8BvkGBgD8ImqmXR87DBavmQNCF2MKHTeieEZuCm29pptynEB1wfRiHxVAupRR68KGDWLfhgEei2RxvRdJOZsUHDWvQKzLJY8nzkxrmLBtAwQgU78sn8=
X-YMail-OSG: zJEN1usVM1kKgZVGcYimrm7hZ5o8EaK5JHiVgfD4PQGlL7J an9_dbEe4AanQn68gpNkuUUJ7P0JCd_ejqf8O8SE1bGG8IQ8Na4LbLAzb.5H jPXilyrRI4X81rFgYkf..U9xOFzJdLENaJPlPbDj7Sk4Nfh7PBowZ_Ql5awi pnic6oIFCLk3CEma3yJ3k_2t_2mBwQQYlu9dg1ulG7yz_aaijsfEgmkAcS_p vuGIS.OvgKE1_DY_O1JFL66Hk.lzHqaWoVGf7kBf_FwsmWXep..pj3xsd0tQ BDCkvRvE44uscblSNV7WNUIeuk.NSmZnwYIbngB2lM21_fZiL.5FkxrpaUgI Pj4fxOUz8UVdp3mBeQ_iXoA34XXvpZR4jC9US0llQ2Y6ExTecRijOGDXlFC0 iSmA03UJV198wBreYv_ZzEirgtBMWNrJfYu3_ThQcHuY8eLTIl_3P6cWhjha 8wzrES.8U31gt6WZitYxG6VE9utjNdUSD0YEstj1ZWh2mR3HRqI.4Yv9MxGg .ufTkS6_CSsVg
Received: from [50.148.178.232] by web2819.biz.mail.ne1.yahoo.com via HTTP; Sun, 17 Feb 2013 16:05:32 PST
X-Rocket-MIMEInfo: 001.001, QXQgdGhpcyBwb2ludCwgaXQgc2VlbXMgbGlrZSB0aGUgYmVzdCB0aGluZyB0byBkbyBpcyBkcmFmdCB0d28gc2VwYXJhdGUgcHJvcG9zYWxzOiANCjEpwqDCoCBsaXN0IGV4dGVuc2lvbiBoZWFkZXJzLCBhbmQgDQoyKSDCoCBhIHNlcGFyYXRlIG9uZSB0byBkZWFsIHdpdGggZmlyZXdhbGxzIGFuZCBob3cgdGhleSBkZWFsIHdpdGggZXh0ZW5zaW9ucy7CoCANCg0KVGhhdCB3YXksIHdlIGNhbiBnZXQgdGhlIGZpcnN0IG9uZSB0aHJ1IGZhaXJseSBxdWlja2x5IChpdCBkb2Vzbid0IHNlZW0gbGlrZSB0aGVyZSABMAEBAQE-
X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.133.508
Message-ID: <1361145932.64319.YahooMailClassic@web2819.biz.mail.ne1.yahoo.com>
Date: Sun, 17 Feb 2013 16:05:32 -0800 (PST)
From: Bill Jouris 
Subject: Re: draft-carpenter-6man-ext-transmit-01.txt
To: 6man , Brian E Carpenter 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1179469976-717550784-1361145932=:64319"
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, 18 Feb 2013 00:05:36 -0000

--1179469976-717550784-1361145932=:64319
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

At this point, it seems like the best thing to do is draft two separate pro=
posals:=20
1)=A0=A0 list extension headers, and=20
2) =A0 a separate one to deal with firewalls and how they deal with extensi=
ons.=A0=20

That way, we can get the first one thru fairly quickly (it doesn't seem lik=
e there is actually much room for controversy there, but that may be naive =
on my part).=A0 And then focus more narrowly on the second one in the rest =
of this discussion.=20

Bill

> Just to focus on one area at the moment:=20
>=20
>>> If an extension proves itself safe, easily parse-able, and useful, it
>>> will be transported over the public Internet. If it doesn't, it will ge=
t
>>> dropped.
>> At the moment this is impossible. There is no place for firewall
>> implementors to find a master list of all well-defined extension headers
>> and no way for site IT managers to configure firewalls to block or allow
>> specific extension headers. So there is no way for a new extension
>> header to prove itself safe and viable. It's pure Catch 22.
>=20
> My personal view is that it is very useful to have a single IANA registry=
 that lists all IPv6 extension headers.=A0 I would like to think I am fairl=
y knowledgable about IPv6, and it's hard for me to find them all.=A0 This i=
s a win independent of what policy we recommend that firewall/middlebox/etc=
. vendors support.=A0 Let's not loose that.

Indeed. That is one of the two proposals in the draft.

The other proposal is to specify what firewalls should do to make extension
headers deployable (subject to site policy). I think this is complementary =
to
the oversized-header-chain draft, which is necessary to remove some cases
that are unreasonable for any firewall to handle.

=A0 =A0 Brian


--1179469976-717550784-1361145932=:64319
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


At this point, it seems like the best thing t=
o do is draft two separate proposals: 
1)   list extension hea=
ders, and 
2)   a separate one to deal with firewalls and how they =
deal with extensions.  

That way, we can get the first one thru=
 fairly quickly (it doesn't seem like there is actually much room for contr=
oversy there, but that may be naive on my part).  And then focus more =
narrowly on the second one in the rest of this discussion. 

Bill
=

> Just to focus on=
 one area at the moment: 
> 
>>> If an extension proves i=
tself safe, easily parse-able, and useful, it
>>> will be trans=
ported over the public Internet. If it doesn't, it will get
>>>
 dropped.
>> At the moment this is impossible. There is no place f=
or firewall
>> implementors to find a master list of all well-defi=
ned extension headers
>> and no way for site IT managers to config=
ure firewalls to block or allow
>> specific extension headers. So =
there is no way for a new extension
>> header to prove itself safe=
 and viable. It's pure Catch 22.
> 
> My personal view is that =
it is very useful to have a single IANA registry that lists all IPv6 extens=
ion headers.  I would like to think I am fairly knowledgable about IPv=
6, and it's hard for me to find them all.  This is a win independent o=
f what policy we recommend that firewall/middlebox/etc. vendors support.&nb=
sp; Let's not loose that.

Indeed. That is one of the two proposals i=
n the draft.

The other proposal is to specify what firewalls should =
do to make extension
headers deployable (subject to site policy).
 I think this is complementary to
the oversized-header-chain draft, whic=
h is necessary to remove some cases
that are unreasonable for any firewa=
ll to handle.

    Brian


--1179469976-717550784-1361145932=:64319--

From brian.e.carpenter@gmail.com  Mon Feb 18 03:13: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 A110221F8863 for ; Mon, 18 Feb 2013 03:13:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.109
X-Spam-Level: 
X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06Jc7E3pzKwT for ; Mon, 18 Feb 2013 03:13:05 -0800 (PST)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id E2D9321F884F for ; Mon, 18 Feb 2013 03:13:04 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id fn15so4627463wgb.32 for ; Mon, 18 Feb 2013 03:13:04 -0800 (PST)
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=gyojdTTiwXpjf5IVKb7fXwOAn3SeTABwhDwjPrYkkRc=; b=W7AKsl1FMYaRpxZT2Dd39OmwQMm0aL+jzd9nDKVJPiSbdV4CJVBE+g2kVhvfyA4Q5Z GszKOArmLVZ6kSQdanmLh4iboTVpEO7JOgp17Wa2JSTZNJ1X/zPxARR3eUXOhTQKh0r5 Fud0yBRFu2+8s2SZRJDqEQ+cfkT/UfCPPjRLxVepp0Ev3lyIaDQQOxeYAXbH7lERYFLD 1Nvqc4gfWuKN1qGR9b7X0XiCGmo/PINWY4xEZ/ss61BgG1EB9tX1cP5TZtUcXoYYLw/o yrIQyhMQy/Vix131R5YZ4A2I98VIVIthjYtOyvoLAl/D3fZTd8XSPe0ttetoG+1nULSx qX7A==
X-Received: by 10.180.73.238 with SMTP id o14mr16030139wiv.32.1361185968447; Mon, 18 Feb 2013 03:12:48 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-219-95.as13285.net. [2.102.219.95]) by mx.google.com with ESMTPS id cg4sm6122207wib.3.2013.02.18.03.12.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 03:12:47 -0800 (PST)
Message-ID: <51220CB1.7050709@gmail.com>
Date: Mon, 18 Feb 2013 11:12:49 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Bill Jouris 
Subject: Re: draft-carpenter-6man-ext-transmit-01.txt
References: <1361145932.64319.YahooMailClassic@web2819.biz.mail.ne1.yahoo.com>
In-Reply-To: <1361145932.64319.YahooMailClassic@web2819.biz.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
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: Mon, 18 Feb 2013 11:13:05 -0000

Bill,

On 18/02/2013 00:05, Bill Jouris wrote:
> At this point, it seems like the best thing to do is draft two separate proposals: 
> 1)   list extension headers, and 
> 2)   a separate one to deal with firewalls and how they deal with extensions.  

This isn't going to happen before IETF86, because of deadlines. We'll see
whether it's necessary after the next version is discussed.

   Brian

> That way, we can get the first one thru fairly quickly (it doesn't seem like there is actually much room for controversy there, but that may be naive on my part).  And then focus more narrowly on the second one in the rest of this discussion. 
> 
> Bill
> 
>> Just to focus on one area at the moment: 
>>
>>>> If an extension proves itself safe, easily parse-able, and useful, it
>>>> will be transported over the public Internet. If it doesn't, it will get
>>>> dropped.
>>> At the moment this is impossible. There is no place for firewall
>>> implementors to find a master list of all well-defined extension headers
>>> and no way for site IT managers to configure firewalls to block or allow
>>> specific extension headers. So there is no way for a new extension
>>> header to prove itself safe and viable. It's pure Catch 22.
>> My personal view is that it is very useful to have a single IANA registry that lists all IPv6 extension headers.  I would like to think I am fairly knowledgable about IPv6, and it's hard for me to find them all.  This is a win independent of what policy we recommend that firewall/middlebox/etc. vendors support.  Let's not loose that.
> 
> Indeed. That is one of the two proposals in the draft.
> 
> The other proposal is to specify what firewalls should do to make extension
> headers deployable (subject to site policy). I think this is complementary to
> the oversized-header-chain draft, which is necessary to remove some cases
> that are unreasonable for any firewall to handle.
> 
>     Brian
> 
> 

From sofiane.imadali.ietf@gmail.com  Mon Feb 18 10:49: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 9FD7721F8AA3 for ; Mon, 18 Feb 2013 10:49:19 -0800 (PST)
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.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEZMpBML-69b for ; Mon, 18 Feb 2013 10:49:17 -0800 (PST)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id E956321F88DB for ; Mon, 18 Feb 2013 10:49:16 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id m4so4526605lbo.0 for ; Mon, 18 Feb 2013 10:49:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=9/ntsJNCATy1Wni49AgNoFqMALEa7l9YR7QnhcvwH5s=; b=sP2sJKVcYQj+arR8pX12D1u86uHXEDAmdbJ4nRWXp49vA+Fpc7jOrZXUJ/sGmaKVpw q1c8ljaPa/4mkG8j3hTPMhxaDCa1TAfGKCjL1Cmy6aAwnWdhN1sSSgjphjHyhUfXgRuD oAKWQdRUVP+2OyTOcMTO7AKOcIvy2jsBpUTcsrhgq8tQH/PwvnvZ8wkO2Yi07oEVIyZs P21RX2E5HqnW/WgoT4hVbL+FVGk5c5bBUicnIi5jA4UMqDeejLefwMzId9cfON8f96WS SIJk+kBQRUNlpqXHt+VSTc7n+pD7+TUzgAk0WWmk0A8WYefqrx732wcY9En4TYvpa/WM SLJw==
MIME-Version: 1.0
X-Received: by 10.152.123.194 with SMTP id mc2mr11721139lab.7.1361213355850; Mon, 18 Feb 2013 10:49:15 -0800 (PST)
Received: by 10.152.127.6 with HTTP; Mon, 18 Feb 2013 10:49:15 -0800 (PST)
Date: Mon, 18 Feb 2013 19:49:15 +0100
Message-ID: 
Subject: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
From: sofiane Imadali 
To: ipv6@ietf.org
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: Mon, 18 Feb 2013 18:49:19 -0000

Hello 6MAN folks,

I would like to announce, on behalf of the co-authors, the submission
of 2 drafts relating to VIN-based IPv6 addressing.
VIN stands for Vehicle Identification Number, and it is specifically
used in a context of IPv6 vehicular communications. These proposals
aim at providing discussion about a new mapping/conversion method from
VIN to ULA prefixes (guaranteed unique) and Interface Identifiers.

Please find the above mentioned documents at:
1) Vehicle Identification Number-Based IPv6 Interface Identifier
(VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
Addresses (VULA), at:
http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00

Your comments are welcome,

Cheers,
Sofiane.

From swb@internet2.edu  Mon Feb 18 12:37: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 DEB5721F8CA8 for ; Mon, 18 Feb 2013 12:37:06 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haK+A-ezidsP for ; Mon, 18 Feb 2013 12:37:06 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C204121F8C87 for ; Mon, 18 Feb 2013 12:37:05 -0800 (PST)
Received: from mail155-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Feb 2013 20:37:03 +0000
Received: from mail155-va3 (localhost [127.0.0.1])	by mail155-va3-R.bigfish.com (Postfix) with ESMTP id C219A3C01F8; Mon, 18 Feb 2013 20:37:03 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT004.namprd08.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: S-20(zzbb2dIdb82h98dI1432Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dhz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1155h)
Received: from mail155-va3 (localhost.localdomain [127.0.0.1]) by mail155-va3 (MessageSwitch) id 1361219821673379_32070; Mon, 18 Feb 2013 20:37:01 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.242])	by mail155-va3.bigfish.com (Postfix) with ESMTP id 97634C0249; Mon, 18 Feb 2013 20:37:01 +0000 (UTC)
Received: from CH1PRD0811HT004.namprd08.prod.outlook.com (157.56.245.85) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Feb 2013 20:37:00 +0000
Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.155.39) with Microsoft SMTP Server (TLS) id 14.16.263.1; Mon, 18 Feb 2013 20:36:57 +0000
Message-ID: <512290E7.3070407@internet2.edu>
Date: Mon, 18 Feb 2013 15:36:55 -0500
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: sofiane Imadali 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References: 
In-Reply-To: 
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [67.241.75.185]
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, 18 Feb 2013 20:37:07 -0000

I have the usual concerns about privacy.  I have no problem with someone
knowing the endpoint that is communicating is associated with a vehicle
(or that I, a human, am communicating from a vehicle).  However, if
someone can map easily from an IP address to a VIN (thus knowing the
specific vehicle from which the communication is happening), and I have
no choice but to reveal that information in order to communicate at all,
I am not comfortable.  In general, as an architectural principle, I want
the option to control how much personal information I reveal.  That's
called privacy.

... Scott

On 02/18/13 13:49, sofiane Imadali allegedly wrote:
> Hello 6MAN folks,
> 
> I would like to announce, on behalf of the co-authors, the submission
> of 2 drafts relating to VIN-based IPv6 addressing.
> VIN stands for Vehicle Identification Number, and it is specifically
> used in a context of IPv6 vehicular communications. These proposals
> aim at providing discussion about a new mapping/conversion method from
> VIN to ULA prefixes (guaranteed unique) and Interface Identifiers.
> 
> Please find the above mentioned documents at:
> 1) Vehicle Identification Number-Based IPv6 Interface Identifier
> (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
> 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
> Addresses (VULA), at:
> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00
> 
> Your comments are welcome,
> 
> Cheers,
> Sofiane.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From rogerj@gmail.com  Mon Feb 18 13:07: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 BA15621F8653 for ; Mon, 18 Feb 2013 13:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfpo1Ng3yTCa for ; Mon, 18 Feb 2013 13:07:55 -0800 (PST)
Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id F2FD021F873C for ; Mon, 18 Feb 2013 13:07:51 -0800 (PST)
Received: by mail-oa0-f48.google.com with SMTP id j1so6242169oag.21 for ; Mon, 18 Feb 2013 13:07:51 -0800 (PST)
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=kZDS3ZYRWVNFR5R1SGkadWUgE5uisWV2jZkJUIjWoNI=; b=imJrEESgo17/PJbcO6naM92WvWLfrITtPd/ZTimbpuXi4YSdwGIniRnF/Ug7Bh2uvj flWvPg5MTcgT35fDnz+jH7tBfZVxJZlAnVgcaKcTUPYhbCos8VCLPFlqHkzuFDGl3Rv8 oL5j1Xs3u+Slo0YjgDjm4ih8sWM/cJ/yLbZi+FpnWjVGz4I6BHHG9kksENgvR3rsiFfE fy6z6xZIDOIUtuG5vbZVR/24TpWQvtYVLEd0wIa1ss+WJIs/J0ebn0pqiw45xsuRwlKs sW9Z2JYogcd0SbZ9hWxgGZTd7gCKREMiLqBAiq2Nx1Ov33DmCG/t5OuMiK6OFt+GFGiK XN/g==
MIME-Version: 1.0
X-Received: by 10.60.169.231 with SMTP id ah7mr6469117oec.142.1361221671598; Mon, 18 Feb 2013 13:07:51 -0800 (PST)
Received: by 10.76.167.106 with HTTP; Mon, 18 Feb 2013 13:07:51 -0800 (PST)
In-Reply-To: <512290E7.3070407@internet2.edu>
References:  <512290E7.3070407@internet2.edu>
Date: Mon, 18 Feb 2013 22:07:51 +0100
Message-ID: 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Scott Brim , sofiane Imadali 
Content-Type: text/plain; charset=ISO-8859-1
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, 18 Feb 2013 21:07:56 -0000

On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim  wrote:
> I have the usual concerns about privacy.  I have no problem with someone
> knowing the endpoint that is communicating is associated with a vehicle
> (or that I, a human, am communicating from a vehicle).  However, if
> someone can map easily from an IP address to a VIN (thus knowing the
> specific vehicle from which the communication is happening), and I have
> no choice but to reveal that information in order to communicate at all,
> I am not comfortable.  In general, as an architectural principle, I want
> the option to control how much personal information I reveal.  That's
> called privacy.

Actual the problem is much simpler, it's not that easy to get the
unique ID of a vehicle today, however with the proposed solution it
become extremely easy.
Sort of the same idea that caused IPv6 to create all IPs based on the
mac address... we know how that ended, we created the privacy option.

Do we want todo it all over again?



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger@jorgensen.no

From swb@internet2.edu  Mon Feb 18 13:16: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 1C69C21F8CE2 for ; Mon, 18 Feb 2013 13:16:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-+zjat7vOqJ for ; Mon, 18 Feb 2013 13:16:18 -0800 (PST)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 99D8221F8CE7 for ; Mon, 18 Feb 2013 13:16:17 -0800 (PST)
Received: from mail51-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Feb 2013 21:16:16 +0000
Received: from mail51-am1 (localhost [127.0.0.1])	by mail51-am1-R.bigfish.com (Postfix) with ESMTP id 90ADF460193; Mon, 18 Feb 2013 21:16:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: S-1(zzbb2dI98dI9371Ic89bh1432Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kz8dhzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1155h)
Received: from mail51-am1 (localhost.localdomain [127.0.0.1]) by mail51-am1 (MessageSwitch) id 1361222174305658_22124; Mon, 18 Feb 2013 21:16:14 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.225])	by mail51-am1.bigfish.com (Postfix) with ESMTP id 4855A1E0247; Mon, 18 Feb 2013 21:16:14 +0000 (UTC)
Received: from CH1PRD0811HT005.namprd08.prod.outlook.com (157.56.245.85) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Feb 2013 21:16:14 +0000
Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.155.40) with Microsoft SMTP Server (TLS) id 14.16.263.1; Mon, 18 Feb 2013 21:16:08 +0000
Message-ID: <51229A16.1080402@internet2.edu>
Date: Mon, 18 Feb 2013 16:16:06 -0500
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu> 
In-Reply-To: 
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
X-Originating-IP: [67.241.75.185]
Content-Transfer-Encoding: quoted-printable
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, 18 Feb 2013 21:16:20 -0000

On 02/18/13 16:07, Roger J=F8rgensen allegedly wrote:
> On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim  wrote:
>> I have the usual concerns about privacy.  I have no problem with someo=
ne
>> knowing the endpoint that is communicating is associated with a vehicl=
e
>> (or that I, a human, am communicating from a vehicle).  However, if
>> someone can map easily from an IP address to a VIN (thus knowing the
>> specific vehicle from which the communication is happening), and I hav=
e
>> no choice but to reveal that information in order to communicate at al=
l,
>> I am not comfortable.  In general, as an architectural principle, I wa=
nt
>> the option to control how much personal information I reveal.  That's
>> called privacy.
>=20
> Actual the problem is much simpler, it's not that easy to get the
> unique ID of a vehicle today, however with the proposed solution it
> become extremely easy.
> Sort of the same idea that caused IPv6 to create all IPs based on the
> mac address... we know how that ended, we created the privacy option.
>=20
> Do we want todo it all over again?

... and that argument isn't really over.  And the legalities have not
been tested yet, particularly in Europe.  I'm not comfortable.


From thierry.ernst@inria.fr  Mon Feb 18 15:06: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 406AF21F8CEA for ; Mon, 18 Feb 2013 15:06:38 -0800 (PST)
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_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up3pMkElkOET for ; Mon, 18 Feb 2013 15:06:37 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 283BB21F8CE5 for ; Mon, 18 Feb 2013 15:06:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,691,1355094000"; d="vcf'?scan'208";a="2646875"
Received: from leeuwenbrug.speedxs.nl (HELO Mont-Ventoux-2.local) ([83.98.239.161]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 19 Feb 2013 00:06:35 +0100
Message-ID: <5122B3FC.8000206@inria.fr>
Date: Tue, 19 Feb 2013 00:06:36 +0100
From: Thierry Ernst 
Organization: INRIA
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu>
In-Reply-To: <512290E7.3070407@internet2.edu>
Content-Type: multipart/mixed; boundary="------------090801000801030606030605"
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, 18 Feb 2013 23:06:38 -0000

This is a multi-part message in MIME format.
--------------090801000801030606030605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


I also think a VIN-based IPv6 addressing is a bad idea.

People involved in ITS (Intelligent Transportation System) in other SDOs 
(ISO, ETSI, CEN) are using pseudonyms at L2 (see the SeVeCom project, or 
the PRESERVE project) and NEMO at L3 (see GeoNet, CVIS and the ITSSv6 
projects) so that location privacy is maintained when the vehicle is moving.

Regards,
Thierry Ernst.




On 18/02/13 21:36, Scott Brim wrote:
> I have the usual concerns about privacy.  I have no problem with someone
> knowing the endpoint that is communicating is associated with a vehicle
> (or that I, a human, am communicating from a vehicle).  However, if
> someone can map easily from an IP address to a VIN (thus knowing the
> specific vehicle from which the communication is happening), and I have
> no choice but to reveal that information in order to communicate at all,
> I am not comfortable.  In general, as an architectural principle, I want
> the option to control how much personal information I reveal.  That's
> called privacy.
>
> ... Scott
>
> On 02/18/13 13:49, sofiane Imadali allegedly wrote:
>> Hello 6MAN folks,
>>
>> I would like to announce, on behalf of the co-authors, the submission
>> of 2 drafts relating to VIN-based IPv6 addressing.
>> VIN stands for Vehicle Identification Number, and it is specifically
>> used in a context of IPv6 vehicular communications. These proposals
>> aim at providing discussion about a new mapping/conversion method from
>> VIN to ULA prefixes (guaranteed unique) and Interface Identifiers.
>>
>> Please find the above mentioned documents at:
>> 1) Vehicle Identification Number-Based IPv6 Interface Identifier
>> (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
>> 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
>> Addresses (VULA), at:
>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00
>>
>> Your comments are welcome,
>>
>> Cheers,
>> Sofiane.
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------


--------------090801000801030606030605
Content-Type: text/x-vcard; charset=utf-8;
 name="thierry_ernst.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="thierry_ernst.vcf"

begin:vcard
fn:Thierry  Ernst
n:Ernst;Thierry 
org:INRIA - Project Team IMARA - LaRA JRU
tel;work:+33 1 3963 59 30
tel;fax:+33 1 39 63 54 91
tel;cell:+33 6 76 56 25 96
url:http://www.lara.prd.fr
version:2.1
end:vcard


--------------090801000801030606030605--

From joelja@bogus.com  Mon Feb 18 23:14: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 A3B5B21F8D6F for ; Mon, 18 Feb 2013 23:14:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.328
X-Spam-Level: 
X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnm1koA-Km0a for ; Mon, 18 Feb 2013 23:14:04 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0F021F8D6E for ; Mon, 18 Feb 2013 23:14:04 -0800 (PST)
Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1J7E0M0000359 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 07:14:01 GMT (envelope-from joelja@bogus.com)
Message-ID: <51232633.9000201@bogus.com>
Date: Mon, 18 Feb 2013 23:13:55 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , Scott Brim , sofiane Imadali 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu> 
In-Reply-To: 
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]); Tue, 19 Feb 2013 07:14:01 +0000 (UTC)
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, 19 Feb 2013 07:14:04 -0000

On 2/18/13 1:07 PM, Roger Jørgensen wrote:
> On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim  wrote:
>> I have the usual concerns about privacy.  I have no problem with someone
>> knowing the endpoint that is communicating is associated with a vehicle
>> (or that I, a human, am communicating from a vehicle).  However, if
>> someone can map easily from an IP address to a VIN (thus knowing the
>> specific vehicle from which the communication is happening), and I have
>> no choice but to reveal that information in order to communicate at all,
>> I am not comfortable.  In general, as an architectural principle, I want
>> the option to control how much personal information I reveal.  That's
>> called privacy.
> Actual the problem is much simpler, it's not that easy to get the
> unique ID of a vehicle today, however with the proposed solution it
> become extremely easy.
In my experience the VIN is readily visible on most stationary vehicles 
(by virtue of  of of the locations being behind the windshield). using 
it as a host address certainly implies that it's being broadcast more 
widely.
> Sort of the same idea that caused IPv6 to create all IPs based on the
> mac address... we know how that ended, we created the privacy option.
>
> Do we want todo it all over again?
>
>
>


From hesham@elevatemobile.com  Mon Feb 18 23:46: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 8897E21F888E for ; Mon, 18 Feb 2013 23:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.124
X-Spam-Level: 
X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkw-2-f4t8uI for ; Mon, 18 Feb 2013 23:46:42 -0800 (PST)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0A21F8438 for ; Mon, 18 Feb 2013 23:46:41 -0800 (PST)
Received: from [118.209.87.64] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1U7huL-00006L-4T; Tue, 19 Feb 2013 18:46:34 +1100
User-Agent: Microsoft-MacOutlook/14.3.0.121105
Date: Tue, 19 Feb 2013 18:46:25 +1100
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
From: Hesham Soliman 
To: Roger =?ISO-8859-1?B?SvhyZ2Vuc2Vu?= , Scott Brim , sofiane Imadali 
Message-ID: 
Thread-Topic: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-User: hesham@elevatemobile.com
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, 19 Feb 2013 07:46:43 -0000

>On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim  wrote:
>> I have the usual concerns about privacy.  I have no problem with someone
>> knowing the endpoint that is communicating is associated with a vehicle
>> (or that I, a human, am communicating from a vehicle).  However, if
>> someone can map easily from an IP address to a VIN (thus knowing the
>> specific vehicle from which the communication is happening), and I have
>> no choice but to reveal that information in order to communicate at all,
>> I am not comfortable.  In general, as an architectural principle, I want
>> the option to control how much personal information I reveal.  That's
>> called privacy.
>
>Actual the problem is much simpler, it's not that easy to get the
>unique ID of a vehicle today, however with the proposed solution it
>become extremely easy.
>Sort of the same idea that caused IPv6 to create all IPs based on the
>mac address... we know how that ended, we created the privacy option.
>
>Do we want todo it all over again?
>

=> Someone, somewhere (perhaps the IAB) needs to write an architectural
document to tell various industries to _stop_ doing that.
The IID is a set of bits that have no meaning, please stop trying to
create it in an industry/link layer technology-specific manner. It does do
anything and it's meaningless. If you want the correspondent to know that
you're a car with a particular VIN then put that in your application!

Hesham


>
>
>-- 
>
>Roger Jorgensen           | ROJO9-RIPE
>rogerj@gmail.com          | - IPv6 is The Key!
>http://www.jorgensen.no   | roger@jorgensen.no
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------



From otroan@employees.org  Tue Feb 19 02:26: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 2C92721F8C53 for ; Tue, 19 Feb 2013 02:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4upXhD7Nryok for ; Tue, 19 Feb 2013 02:26:36 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0421F84F5 for ; Tue, 19 Feb 2013 02:26:33 -0800 (PST)
Received: from dhcp-lys01-vla250-10-147-112-98.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 83BD65EBB for ; Tue, 19 Feb 2013 02:26:31 -0800 (PST)
From: Ole Troan 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: 6man IETF86 Call for agenda items
Message-Id: <0A82409F-5C0D-4D0E-A821-9523B0A93CAC@employees.org>
Date: Tue, 19 Feb 2013 11:26:29 +0100
To: "ipv6@ietf.org 6man-wg" 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
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, 19 Feb 2013 10:26:37 -0000

6MAN has a two hour slot allocated for Orlando:

  6man Session (2:00)
  2013-03-15
  Friday Afternoon Session I 1120 - 1220
  Friday Afternoon Session II 1230 - 1330
  Room Name: Caribbean 4

If you have a draft you would like to discuss, please send your request =
for agenda time to the 6man chairs.
Please include in the request, the title and file name of the draft, the =
speakers name (and email),
and how much time you need.

We will prioritise drafts that are working group items and drafts that =
have been actively discussed on the list.
We expect about half the presentation time to be used for open =
discussion,
please plan your presentation accordingly.

New drafts not discussed on the mailing list prior to the meeting,
or drafts that do not appear to have support from the working group are =
unlikely to get time at the meeting.

Please have agenda items to us by 2013-02-27 and also note the following =
deadlines for IETF86:

 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC =
24:00

Regards,

Bob & Ole=

From alexandru.petrescu@gmail.com  Tue Feb 19 06:17: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 96FFD21F8628 for ; Tue, 19 Feb 2013 06:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.48
X-Spam-Level: 
X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMWJaRtwTPoA for ; Tue, 19 Feb 2013 06:17:49 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3BA21F853C for ; Tue, 19 Feb 2013 06:17:49 -0800 (PST)
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 r1JEHjmE023768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Feb 2013 15:17:45 +0100
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 r1JEHigl030078 for ; Tue, 19 Feb 2013 15:17:44 +0100 (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 r1JEHY14028243 for ; Tue, 19 Feb 2013 15:17:43 +0100
Message-ID: <5123897E.60905@gmail.com>
Date: Tue, 19 Feb 2013 15:17:34 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References: 
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: Tue, 19 Feb 2013 14:17:50 -0000

Le 19/02/2013 08:46, Hesham Soliman a écrit :
>
>> On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim 
>> wrote:
>>> I have the usual concerns about privacy.  I have no problem with
>>> someone knowing the endpoint that is communicating is associated
>>> with a vehicle (or that I, a human, am communicating from a
>>> vehicle).  However, if someone can map easily from an IP address
>>> to a VIN (thus knowing the specific vehicle from which the
>>> communication is happening), and I have no choice but to reveal
>>> that information in order to communicate at all, I am not
>>> comfortable.  In general, as an architectural principle, I want
>>> the option to control how much personal information I reveal.
>>> That's called privacy.
>>
>> Actual the problem is much simpler, it's not that easy to get the
>> unique ID of a vehicle today, however with the proposed solution
>> it become extremely easy. Sort of the same idea that caused IPv6 to
>> create all IPs based on the mac address... we know how that ended,
>> we created the privacy option.
>>
>> Do we want todo it all over again?
>>
>
> => Someone, somewhere (perhaps the IAB) needs to write an
> architectural document to tell various industries to _stop_ doing
> that. The IID is a set of bits that have no meaning, please stop
> trying to create it in an industry/link layer technology-specific
> manner. It does do anything and it's meaningless.

I think you're too strong with statements.  Many IPv-over-foo documents
exist and they do just that - create IID in a industry-specific manner.

> If you want the correspondent to know that you're a car with a
> particular VIN then put that in your application!

That is a good point - if one wants a Server to determine that some
end-node is actually a vehicle (with details about vehicle type -
electrical) then better use a UDP payload, not necessarily an IP address
for it.

But I think you make an assumption which may be true or false.  It is
not necessarily true that we do that only for the application.

The need comes from further, and it may look simpler: we need to form
IPv6 addresses within a vehicle.

There are a number of solutions to realize it, but each has its
advantages and inconvenients.  Forming it from VIN has some advantages.

We can discuss this.

Alex


>
> Hesham
>
>
>>
>>
>> --
>>
>> Roger Jorgensen           | ROJO9-RIPE rogerj@gmail.com          |
>> - IPv6 is The Key! http://www.jorgensen.no   | roger@jorgensen.no
>> --------------------------------------------------------------------
>>
>>
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  Tue Feb 19 06:23: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 221B521F8956 for ; Tue, 19 Feb 2013 06:23:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.476
X-Spam-Level: 
X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5T9tDuxMMW0 for ; Tue, 19 Feb 2013 06:23:21 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 41CE121F8873 for ; Tue, 19 Feb 2013 06:23:16 -0800 (PST)
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 r1JENFdO026997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Feb 2013 15:23:15 +0100
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 r1JENEGc000978 for ; Tue, 19 Feb 2013 15:23:15 +0100 (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 r1JEN9rT032752 for ; Tue, 19 Feb 2013 15:23:14 +0100
Message-ID: <51238ACD.6000506@gmail.com>
Date: Tue, 19 Feb 2013 15:23:09 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu> 
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: Tue, 19 Feb 2013 14:23:22 -0000

Le 18/02/2013 22:07, Roger Jørgensen a écrit :
> On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim 
> wrote:
>> I have the usual concerns about privacy.  I have no problem with
>> someone knowing the endpoint that is communicating is associated
>> with a vehicle (or that I, a human, am communicating from a
>> vehicle).  However, if someone can map easily from an IP address
>> to a VIN (thus knowing the specific vehicle from which the
>> communication is happening), and I have no choice but to reveal
>> that information in order to communicate at all, I am not
>> comfortable.  In general, as an architectural principle, I want
>> the option to control how much personal information I reveal.
>> That's called privacy.
>
> Actual the problem is much simpler, it's not that easy to get the
> unique ID of a vehicle today, however with the proposed solution it
> become extremely easy. Sort of the same idea that caused IPv6 to
> create all IPs based on the mac address... we know how that ended,
> we created the privacy option.

Well I agree with you in a sense.  Connecting a vehicle to the Internet
in that way makes it easier than before to find its VIN.

However, may I add that the VIN of a vehicle is very easy to get.  It is
displayed under the shield and by legislation it must be visible, for
cases like e.g. recover at accident scenes.  Despite its little font,
it's as visible as the license plate (I can send a photo if you wish, or
you could check a car's windshield bordering the frame).  Nobody 
complains about the visibility of the license plate.

> Do we want todo it all over again?

No.

Privacy is a strong concern and we should take it into account, yes.

Alex

>
>
>



From alexandru.petrescu@gmail.com  Tue Feb 19 06:31: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 CC6AC21F8B6C for ; Tue, 19 Feb 2013 06:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.472
X-Spam-Level: 
X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9AhhZM86FVZ for ; Tue, 19 Feb 2013 06:31:58 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 90A8421F8A56 for ; Tue, 19 Feb 2013 06:31:58 -0800 (PST)
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 r1JEVvLw008174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Feb 2013 15:31:57 +0100
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 r1JEVu5T007168 for ; Tue, 19 Feb 2013 15:31:57 +0100 (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 r1JEVqIa009981 for ; Tue, 19 Feb 2013 15:31:56 +0100
Message-ID: <51238CD8.6030805@gmail.com>
Date: Tue, 19 Feb 2013 15:31:52 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu> 
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: Tue, 19 Feb 2013 14:31:59 -0000

Le 18/02/2013 22:07, Roger Jørgensen a écrit :
> On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim 
> wrote:
>> I have the usual concerns about privacy.  I have no problem with
>> someone knowing the endpoint that is communicating is associated
>> with a vehicle (or that I, a human, am communicating from a
>> vehicle).  However, if someone can map easily from an IP address to
>> a VIN (thus knowing the specific vehicle from which the
>> communication is happening), and I have no choice but to reveal
>> that information in order to communicate at all, I am not
>> comfortable.  In general, as an architectural principle, I want the
>> option to control how much personal information I reveal.  That's
>> called privacy.

Scott,

I agree privacy is important.

An alternative method from R. Bless proposes to use a SHA output in the
prefix field of an address.  This has an advantage with respect to
privacy - it's hardly feasible to reversely derive the VIN of the
vehicle from the IPv6 address, slide 6 of
http://www.lara.prd.fr/_media/ipv6-its/2012-03-26-seis-kit-ietf83-its.pdf

That method alone has certain advantages, but also drawbacks.

If we consider the problem to be as simple as "how to form IPv6
addresses in a vehicle?" then one realizes that just forming a ULA
prefix for _within_ the vehicle may not be enough.  Communication
outside the vehicle (e.g. between two vehicles) may involve links which
may not be just plain Ethernet, and hence impossible to just use RFC2464
LL addresses on the outside of the vehicle.

In some cases it _is_ possible to get along with just LL/Ethernet
addresses between vehicles, but if/when
geonetworking/other-vehicular-link-layers are used, then that may not be
enough.

All in all, depending on the problem, the VIN-based addresses may be
necessary, provided that privacy concerns are addressed.

Alex



>
> Actual the problem is much simpler, it's not that easy to get the
> unique ID of a vehicle today, however with the proposed solution it
> become extremely easy. Sort of the same idea that caused IPv6 to
> create all IPs based on the mac address... we know how that ended, we
> created the privacy option.
>
> Do we want todo it all over again?
>
>
>



From alexandru.petrescu@gmail.com  Tue Feb 19 06:36: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 DD62521F8DDA for ; Tue, 19 Feb 2013 06:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.468
X-Spam-Level: 
X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPUB-bMsLiTm for ; Tue, 19 Feb 2013 06:36:43 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 69EB521F8DDB for ; Tue, 19 Feb 2013 06:36:40 -0800 (PST)
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 r1JEadjA011195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Feb 2013 15:36:39 +0100
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 r1JEad05009743 for ; Tue, 19 Feb 2013 15:36:39 +0100 (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 r1JEac4r013399 for ; Tue, 19 Feb 2013 15:36:39 +0100
Message-ID: <51238DF6.8040708@gmail.com>
Date: Tue, 19 Feb 2013 15:36:38 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu> <5122B3FC.8000206@inria.fr>
In-Reply-To: <5122B3FC.8000206@inria.fr>
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: Tue, 19 Feb 2013 14:36:44 -0000

Le 19/02/2013 00:06, Thierry Ernst a écrit :
>
> I also think a VIN-based IPv6 addressing is a bad idea.
>
> People involved in ITS (Intelligent Transportation System) in other
> SDOs (ISO, ETSI, CEN) are using pseudonyms at L2 (see the SeVeCom
> project, or the PRESERVE project) and NEMO at L3 (see GeoNet, CVIS
> and the ITSSv6 projects) so that location privacy is maintained when
> the vehicle is moving.

It's good location privacy is maintained, with these techniques.

The other privacy aspect mentioned seems to relate to protecting an
individual from attacker reversely deriving his/her VIN from the IP address.

One doesn't want a java-hacked Facebook in the Internet to allow all my
friends know my request came from a vehicle of type Fiat (I pretend
Ferrari :-)

I agree to the privacy concerns.

Alex

>
> Regards, Thierry Ernst.
>
>
>
>
> On 18/02/13 21:36, Scott Brim wrote:
>> I have the usual concerns about privacy.  I have no problem with
>> someone knowing the endpoint that is communicating is associated
>> with a vehicle (or that I, a human, am communicating from a
>> vehicle).  However, if someone can map easily from an IP address to
>> a VIN (thus knowing the specific vehicle from which the
>> communication is happening), and I have no choice but to reveal
>> that information in order to communicate at all, I am not
>> comfortable.  In general, as an architectural principle, I want the
>> option to control how much personal information I reveal.  That's
>> called privacy.
>>
>> ... Scott
>>
>> On 02/18/13 13:49, sofiane Imadali allegedly wrote:
>>> Hello 6MAN folks,
>>>
>>> I would like to announce, on behalf of the co-authors, the
>>> submission of 2 drafts relating to VIN-based IPv6 addressing. VIN
>>> stands for Vehicle Identification Number, and it is specifically
>>> used in a context of IPv6 vehicular communications. These
>>> proposals aim at providing discussion about a new
>>> mapping/conversion method from VIN to ULA prefixes (guaranteed
>>> unique) and Interface Identifiers.
>>>
>>> Please find the above mentioned documents at: 1) Vehicle
>>> Identification Number-Based IPv6 Interface Identifier (VIID), at:
>>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00 2)
>>> Vehicle Identification Number-Based Unique Local IPv6 Unicast
>>> Addresses (VULA), at:
>>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00
>>>
>>> Your comments are welcome,
>>>
>>> Cheers, Sofiane.
>>> --------------------------------------------------------------------
>>>
>>>
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
>> --------------------------------------------------------------------
>
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



From brian.e.carpenter@gmail.com  Tue Feb 19 06:40: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 4556521F894E for ; Tue, 19 Feb 2013 06:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.857
X-Spam-Level: 
X-Spam-Status: No, score=-101.857 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JON79OJBj3GP for ; Tue, 19 Feb 2013 06:40:50 -0800 (PST)
Received: from mail-we0-x231.google.com (we-in-x0231.1e100.net [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90521F886B for ; Tue, 19 Feb 2013 06:40:50 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id d7so5613545wer.36 for ; Tue, 19 Feb 2013 06:40:49 -0800 (PST)
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:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9ylWV0q7l7SU9MrYUDrKwWLlP6gtpjlFM19YA1UfC6I=; b=G9jHPa1L3v7JotFLK3+jr6/WCAV+lnxPin+rGCRM5ziIUQnQkXwmlF6J0e2q3UEgHa etE+uNYtj3DHWNgac24HUKfq1lLhPX8i+lfJicCPd8WzbMuYn5Vp2R8KMkxS7A5D3OYM 3B5d5IRITeJNS0aVVPYW7FXqhzGSrEj35O99vCSupItswUhtjB7V3HXao2kwNHJ1zX18 aft68mW5sOJHsLuj7PNylYEDUzBBhTMDvYwHMunMDRff1PYzGUDAihUtQoDfb8Pq2VPU NG1a59YZlDc1CfHh5Fla9o4EJf/5tdDSoNpa5vMu/6RAesOKmtSA00Mft0nCTfyZrTzf uNhg==
X-Received: by 10.194.158.165 with SMTP id wv5mr26781341wjb.45.1361284842186;  Tue, 19 Feb 2013 06:40:42 -0800 (PST)
Received: from [128.232.110.79] (c079.al.cl.cam.ac.uk. [128.232.110.79]) by mx.google.com with ESMTPS id bs6sm28182915wib.4.2013.02.19.06.40.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 06:40:40 -0800 (PST)
Message-ID: <51238EEE.8060804@gmail.com>
Date: Tue, 19 Feb 2013 14:40:46 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man 
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com>
In-Reply-To: <20130218183623.2809.21129.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
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: Tue, 19 Feb 2013 14:40:51 -0000

I do not understand the following:

>    Bits 55 and 56 that correspond to U/L bits are set accordingly to the
>    recommendations. 

I suppose the reference is to the U and G bits (in positions 6 and 7
in the IID, or 70 and 71 in the IPv6 address, in IETF notation).
But what "recommendations" apply? The description in RFC 4291
refers to the equivalent bits in an IEEE address, so there is
no recommendation that is relevant to a VIN.

Also, I do not wish to broadcast my VIN number to the world.
While VIN numbers are not a big secret, associating my on line
transactions with my car's identity is definitely a big no-no.

Regards
   Brian

From swb@internet2.edu  Tue Feb 19 06:49: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 9DB8121F8A4F for ; Tue, 19 Feb 2013 06:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.049
X-Spam-Level: 
X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da6Z02Z3FNIn for ; Tue, 19 Feb 2013 06:49:49 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id DC7C221F89EF for ; Tue, 19 Feb 2013 06:49:48 -0800 (PST)
Received: from mail236-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Feb 2013 14:49:48 +0000
Received: from mail236-ch1 (localhost [127.0.0.1])	by mail236-ch1-R.bigfish.com (Postfix) with ESMTP id 38719F80121; Tue, 19 Feb 2013 14:49:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: S1(zzbb2dI98dI1432Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1889i1155h)
Received: from mail236-ch1 (localhost.localdomain [127.0.0.1]) by mail236-ch1 (MessageSwitch) id 1361285386629525_8464; Tue, 19 Feb 2013 14:49:46 +0000 (UTC)
Received: from CH1EHSMHS011.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230])	by mail236-ch1.bigfish.com (Postfix) with ESMTP id 955F219000B1;	Tue, 19 Feb 2013 14:49:46 +0000 (UTC)
Received: from CH1PRD0811HT001.namprd08.prod.outlook.com (157.56.245.85) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Feb 2013 14:49:45 +0000
Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.155.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 19 Feb 2013 14:49:45 +0000
Message-ID: <51239107.5080105@internet2.edu>
Date: Tue, 19 Feb 2013 09:49:43 -0500
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Alexandru Petrescu 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu>  <51238ACD.6000506@gmail.com>
In-Reply-To: <51238ACD.6000506@gmail.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [67.241.75.185]
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: Tue, 19 Feb 2013 14:49:49 -0000

On 02/19/13 09:23, Alexandru Petrescu allegedly wrote:
> Well I agree with you in a sense.  Connecting a vehicle to the Internet
> in that way makes it easier than before to find its VIN.
> 
> However, may I add that the VIN of a vehicle is very easy to get.  It is
> displayed under the shield and by legislation it must be visible, for
> cases like e.g. recover at accident scenes.  Despite its little font,
> it's as visible as the license plate (I can send a photo if you wish, or
> you could check a car's windshield bordering the frame).  Nobody
> complains about the visibility of the license plate.

How someone might walk along the street and see a VIN has nothing to do
with Internet privacy.  If this mapping mechanism is adopted, one MUST
reveal the specific vehicle communicating in order to communicate at
all.  That is not "taking privacy into account".  Most people have no
idea what can be derived from correlated data.


From swb@internet2.edu  Tue Feb 19 06:50: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 835AD21F8B8B for ; Tue, 19 Feb 2013 06:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.937
X-Spam-Level: 
X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkhFfLGG9x8e for ; Tue, 19 Feb 2013 06:50:40 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0C94421F89EF for ; Tue, 19 Feb 2013 06:50:40 -0800 (PST)
Received: from mail171-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Feb 2013 14:50:31 +0000
Received: from mail171-ch1 (localhost [127.0.0.1])	by mail171-ch1-R.bigfish.com (Postfix) with ESMTP id BC3201401AC; Tue, 19 Feb 2013 14:50:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.232.53; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0811HT002.namprd08.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 2
X-BigFish: S2(zzbb2dI98dIda00hd799hzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1889i1155h)
Received: from mail171-ch1 (localhost.localdomain [127.0.0.1]) by mail171-ch1 (MessageSwitch) id 1361285429746567_1152; Tue, 19 Feb 2013 14:50:29 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236])	by mail171-ch1.bigfish.com (Postfix) with ESMTP id A8A0BA01E5;	Tue, 19 Feb 2013 14:50:29 +0000 (UTC)
Received: from BLUPRD0811HT002.namprd08.prod.outlook.com (157.56.232.53) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Feb 2013 14:50:29 +0000
Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.123.37) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 19 Feb 2013 14:50:28 +0000
Message-ID: <51239132.2040906@internet2.edu>
Date: Tue, 19 Feb 2013 09:50:26 -0500
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Brian E Carpenter 
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com>
In-Reply-To: <51238EEE.8060804@gmail.com>
X-Enigmail-Version: 1.5
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 
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, 19 Feb 2013 14:50:46 -0000

On 02/19/13 09:40, Brian E Carpenter allegedly wrote:
> Also, I do not wish to broadcast my VIN number to the world.
> While VIN numbers are not a big secret, associating my on line
> transactions with my car's identity is definitely a big no-no.

Right.


From swb@internet2.edu  Tue Feb 19 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 4700221F8D08 for ; Tue, 19 Feb 2013 06:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.869
X-Spam-Level: 
X-Spam-Status: No, score=-3.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD2YnJiAXO4q for ; Tue, 19 Feb 2013 06:52:02 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id C0E7821F8B6C for ; Tue, 19 Feb 2013 06:52:02 -0800 (PST)
Received: from mail121-co1-R.bigfish.com (10.243.78.215) by CO1EHSOBE019.bigfish.com (10.243.66.82) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Feb 2013 14:52:01 +0000
Received: from mail121-co1 (localhost [127.0.0.1])	by mail121-co1-R.bigfish.com (Postfix) with ESMTP id ED1897C00DE; Tue, 19 Feb 2013 14:52:01 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.232.53; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 2
X-BigFish: S2(zzbb2dI98dIda00hzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1889i1155h)
Received: from mail121-co1 (localhost.localdomain [127.0.0.1]) by mail121-co1 (MessageSwitch) id 1361285519212195_20941; Tue, 19 Feb 2013 14:51:59 +0000 (UTC)
Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.222])	by mail121-co1.bigfish.com (Postfix) with ESMTP id 2775FA400FE; Tue, 19 Feb 2013 14:51:59 +0000 (UTC)
Received: from BLUPRD0811HT005.namprd08.prod.outlook.com (157.56.232.53) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Feb 2013 14:51:55 +0000
Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.123.40) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 19 Feb 2013 14:51:54 +0000
Message-ID: <51239188.1050802@internet2.edu>
Date: Tue, 19 Feb 2013 09:51:52 -0500
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Alexandru Petrescu 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu> <5122B3FC.8000206@inria.fr> <51238DF6.8040708@gmail.com>
In-Reply-To: <51238DF6.8040708@gmail.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [67.241.75.185]
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: Tue, 19 Feb 2013 14:52:03 -0000

On 02/19/13 09:36, Alexandru Petrescu allegedly wrote:
> I agree to the privacy concerns.

Great.  Thanks.


From brian.e.carpenter@gmail.com  Tue Feb 19 06:56: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 C365421F8C61 for ; Tue, 19 Feb 2013 06:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.81
X-Spam-Level: 
X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT92lfpT3jTP for ; Tue, 19 Feb 2013 06:56:58 -0800 (PST)
Received: from mail-we0-x22c.google.com (we-in-x022c.1e100.net [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ABE4621F8C4C for ; Tue, 19 Feb 2013 06:56:57 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id x10so5819707wey.17 for ; Tue, 19 Feb 2013 06:56:56 -0800 (PST)
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:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JGRNDt5Zl+LFHtr7iIMNqtPhR6R2oC480xqftP9D1iU=; b=nlElPdoIR94YQR6PBwaTl1SM8tUXk30UueDt3yA+kU4Fg3wHzOqu+aJerKw8gyq2nX cS4+IZHdp+eet4BT2oV+xlM1yGieBsVtWni98qIPzxbog4tifP7ab+bVHRqoUwAlZatW UAoVvxQq7ebAWc9W+SJ0qR7WMlMAkzV6yBMyOfWzRm8DTL+KKLTpVINFHlkrPgV8zzHr Ah/oE5ixEBDmAGRKWVmpHmShITi6vSzezIpYj37r9dYWtYLfgXRaRyXEsOP82qYu7vmo ncmn4/Boc7xgr6vRaIwcL2QVtMzyvJIA4dl7UjVq8O5kD4wxR62E1HUq0RSi+1E22x3h 8W0Q==
X-Received: by 10.180.73.238 with SMTP id o14mr24528561wiv.32.1361285815682; Tue, 19 Feb 2013 06:56:55 -0800 (PST)
Received: from [128.232.110.79] (c079.al.cl.cam.ac.uk. [128.232.110.79]) by mx.google.com with ESMTPS id gy2sm28271232wib.3.2013.02.19.06.56.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 06:56:54 -0800 (PST)
Message-ID: <512392BB.8040909@gmail.com>
Date: Tue, 19 Feb 2013 14:56:59 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man 
Subject: Re: I-D Action: draft-imadali-its-vinipv6-vula-00.txt
References: <20130218183751.22385.4373.idtracker@ietfa.amsl.com>
In-Reply-To: <20130218183751.22385.4373.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
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: Tue, 19 Feb 2013 14:56:58 -0000

> 3.3.  Examples of use
> 
>    The Mobile Router (MR) that executes the previous algorithm, is
>    capable of announcing the generated prefix on one or several internal
>    interfaces and configure one or several external interfaces,
>    depending on the scenario.  For instance, under some conditions,
>    knowing the VIN code of a vehicle, one can deduce the internally
>    advertised prefix and remotely access a well-known internal device
>    (with a certain MAC address).  This access might be possible for
>    vehicle manufacturers in order to perform remote diagnostic, or other
>    car rental companies depending on the application.
> 
>    Using the vehicle's VIN and the above method, the MR can deduce the
>    same VULA prefix and advertise it internally or use it to configure
>    its own external interfaces. 

By definition, any prefix that can be used like this is not a ULA prefix,
and has no place under fc00::/7. ULA prefixes are not to be routed externally.

> 4.1.  Method 1: RFC 4193 compliant Unique  Local IPv6 Unicast Address
>       generation
> 
>    The VIN is, according to section 3.2.2 of RFC 4193, a suitably unique
>    identifier that could be used locally to the MR for the generation of
>    an IPv6 ULA prefix and can thus be used in the algorithm described in
>    the same section.  Basically, step 2 of the aforementioned algorithm
>    is transformed in order to take the local VIN code as input.  The
>    resulting ULA prefix is advertised on MR's ingress interface, or used
>    to configure any other local interface.
> 
>    Since RFC 4193 algorithm relies on a pseudo-random generation method
>    for the ULA prefix, and introduces, for example, the timestamp at the
>    moment of the execution, two different instances of the same
>    algorithm given the same VIN code, will result in two different
>    prefixes. 

Yes. That's why, in any ULA deployment where some stability is needed,
you will only regenerate the ULA prefix in extreme circumstances
(typically a "factory reset").

...
>    Also, the VIN code is hashed and
>    partly present in the Global ID, which makes it impossible to guess
>    from a given ULA prefix.

Yes, which is a very good thing from the privacy point of view.

> 4.2.  Method 2: VIN-based Unique Local  IPv6 Unicast Address generation
> 
>    The conversion method described in Section 3.2 defines a new VULA
>    prefix format (as depicted in Figure 5) which is guaranteed unique
>    amongst the VIN-based generated prefixes.  Knowing a VIN code, it is
>    possible to derive the related ULA prefix and use this information
>    for a remote access.

This is completely unacceptable as it contradicts the most basic aspect
of ULAs: the L stands for Local.

>    This subtype of ULA prefixes which has enhanced uniqueness guarantees
>    may be defined in a separate category that requests specific /8
>    prefix (for example) that are expected to be globally routed.

Something that is globally routed or externally accessible is by definition
not a ULA.

Regards
   Brian

From joelja@bogus.com  Tue Feb 19 07:37: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 2559A21F8CF4 for ; Tue, 19 Feb 2013 07:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.468
X-Spam-Level: 
X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxYwoCJw-xiu for ; Tue, 19 Feb 2013 07:37:55 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9521F8CD3 for ; Tue, 19 Feb 2013 07:37:55 -0800 (PST)
Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1JFbq99005992 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 15:37:53 GMT (envelope-from joelja@bogus.com)
Message-ID: <51239C4B.8080103@bogus.com>
Date: Tue, 19 Feb 2013 07:37:47 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: Alexandru Petrescu , ipv6@ietf.org
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com>
In-Reply-To: <51238CD8.6030805@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]); Tue, 19 Feb 2013 15:37:53 +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: Tue, 19 Feb 2013 15:37:56 -0000

On 2/19/13 6:31 AM, Alexandru Petrescu wrote:
> Le 18/02/2013 22:07, Roger Jørgensen a écrit :
>> On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim 
>> wrote:
>>> I have the usual concerns about privacy.  I have no problem with
>>> someone knowing the endpoint that is communicating is associated
>>> with a vehicle (or that I, a human, am communicating from a
>>> vehicle).  However, if someone can map easily from an IP address to
>>> a VIN (thus knowing the specific vehicle from which the
>>> communication is happening), and I have no choice but to reveal
>>> that information in order to communicate at all, I am not
>>> comfortable.  In general, as an architectural principle, I want the
>>> option to control how much personal information I reveal. That's
>>> called privacy.
>
> Scott,
>
> I agree privacy is important.
>
> An alternative method from R. Bless proposes to use a SHA output in the
> prefix field of an address.  This has an advantage with respect to
> privacy - it's hardly feasible to reversely derive the VIN of the
> vehicle from the IPv6 address, slide 6 of
> http://www.lara.prd.fr/_media/ipv6-its/2012-03-26-seis-kit-ietf83-its.pdf
>
> That method alone has certain advantages, but also drawbacks.
>
> If we consider the problem to be as simple as "how to form IPv6
> addresses in a vehicle?" then one realizes that just forming a ULA
> prefix for _within_ the vehicle may not be enough.  Communication
> outside the vehicle (e.g. between two vehicles) may involve links which
> may not be just plain Ethernet, and hence impossible to just use RFC2464
> LL addresses on the outside of the vehicle.
>
> In some cases it _is_ possible to get along with just LL/Ethernet
> addresses between vehicles, but if/when
> geonetworking/other-vehicular-link-layers are used, then that may not be
> enough.
I'm pretty sure one of my cars has an IMEI, a bluetooth mac address and 
one on the wifi.

I would imagine that link layer technology would drive what sort of L2 
identifer is used for a given technology e.g. wifi bluetooth


      802.15.4 and so on. and that if that's a mac address it's
      available for use as an upper layer identifier in a fashion we
      understand.

>
> All in all, depending on the problem, the VIN-based addresses may be
> necessary, provided that privacy concerns are addressed.
A vin uniquely identifies a vehicle not a link layer interface. If you 
application requires that (toll transponder does that effectively) then 
need to expose that in some way to the application. address selection or 
mac addresses for that matter is far too weak a mechanism to serve as an 
identity token.
> Alex
>
>
>
>>
>> Actual the problem is much simpler, it's not that easy to get the
>> unique ID of a vehicle today, however with the proposed solution it
>> become extremely easy. Sort of the same idea that caused IPv6 to
>> create all IPs based on the mac address... we know how that ended, we
>> created the privacy option.
>>
>> Do we want todo it all over again?
>>
>>
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From alexandru.petrescu@gmail.com  Tue Feb 19 07:40: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 89FD321F8DE8 for ; Tue, 19 Feb 2013 07:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.465
X-Spam-Level: 
X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSaPy-RzHRKp for ; Tue, 19 Feb 2013 07:40:10 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id BFE9D21F8DD9 for ; Tue, 19 Feb 2013 07:40:09 -0800 (PST)
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 r1JFe8x6006943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Feb 2013 16:40:08 +0100
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 r1JFe8bi009518 for ; Tue, 19 Feb 2013 16:40:08 +0100 (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 r1JFe7BG019113 for ; Tue, 19 Feb 2013 16:40:08 +0100
Message-ID: <51239CD7.6060004@gmail.com>
Date: Tue, 19 Feb 2013 16:40:07 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com>
In-Reply-To: <51238EEE.8060804@gmail.com>
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: Tue, 19 Feb 2013 15:40:10 -0000

Le 19/02/2013 15:40, Brian E Carpenter a écrit :
> I do not understand the following:
>
>> Bits 55 and 56 that correspond to U/L bits are set accordingly to
>> the recommendations.
>
> I suppose the reference is to the U and G bits (in positions 6 and 7
> in the IID, or 70 and 71 in the IPv6 address, in IETF notation). But
> what "recommendations" apply? The description in RFC 4291 refers to
> the equivalent bits in an IEEE address, so there is no recommendation
> that is relevant to a VIN.

(will check)

> Also, I do not wish to broadcast my VIN number to the world. While
> VIN numbers are not a big secret, associating my on line transactions
> with my car's identity is definitely a big no-no.

YEs, I agree with the concern.

Such a concern would be all the more valid if there were a specification
which said 'each vehicle MUST form its IIDs based on their VINs'.  But
this is not the case.  We are not trying for such a definitive document.

We are certain that some vehicles will never use this VIN-based
addressing scheme.  At that point, someone receiving a packet with a
certain source address will never know whether that packet is from a
vehicle or from something else.  A reversal of the IP into a number will
never be sure to be a VIN.

Alex

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



From alexandru.petrescu@gmail.com  Tue Feb 19 07:46: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 95CB021F8D0F for ; Tue, 19 Feb 2013 07:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.462
X-Spam-Level: 
X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia8AVuC4HD7r for ; Tue, 19 Feb 2013 07:46:14 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE821F8D08 for ; Tue, 19 Feb 2013 07:46:14 -0800 (PST)
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 r1JFkD8n009949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Feb 2013 16:46:13 +0100
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 r1JFkDCq012499 for ; Tue, 19 Feb 2013 16:46:13 +0100 (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 r1JFk8k7029333 for ; Tue, 19 Feb 2013 16:46:13 +0100
Message-ID: <51239E40.2030006@gmail.com>
Date: Tue, 19 Feb 2013 16:46:08 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu>  <51238ACD.6000506@gmail.com> <51239107.5080105@internet2.edu>
In-Reply-To: <51239107.5080105@internet2.edu>
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: Tue, 19 Feb 2013 15:46:15 -0000

Le 19/02/2013 15:49, Scott Brim a écrit :
> On 02/19/13 09:23, Alexandru Petrescu allegedly wrote:
>> Well I agree with you in a sense.  Connecting a vehicle to the
>> Internet in that way makes it easier than before to find its VIN.
>>
>> However, may I add that the VIN of a vehicle is very easy to get.
>> It is displayed under the shield and by legislation it must be
>> visible, for cases like e.g. recover at accident scenes.  Despite
>> its little font, it's as visible as the license plate (I can send a
>> photo if you wish, or you could check a car's windshield bordering
>> the frame).  Nobody complains about the visibility of the license
>> plate.
>
> How someone might walk along the street and see a VIN has nothing to
>  do with Internet privacy.  If this mapping mechanism is adopted, one
>  MUST reveal the specific vehicle communicating in order to
> communicate at all.  That is not "taking privacy into account".

The picture is finer.  It may be that the address formed from VIN is
actually an ULA, which reaches some Servers in a domain, but not the
Internet at large. (maybe reach another vehicle in the same highway).

It may also be that the protocol Mobile IP/NEMO is used, or not.  When
it is used, it may be that the tunnel between MR and HA is protected by
ESP, hence the address inside the tunnel (the ULA derived from VIN) is
not visible.

The HA - Home Agent - in the infrastructure is controlled by the same
entity who gave birth to that vehicle, so it may rightfully need to know
its identity. (garage recall a vehicle because of particular fault).

> Most people have no idea what can be derived from correlated data.

Yes, I am part of that most people.  I have no idea and I am personally
afraid of what may be correlated about what I send on Internet.

Any method of predictive mapping should take care of privacy.

Alex

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



From alexandru.petrescu@gmail.com  Tue Feb 19 07:56: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 7988C21F8AC0 for ; Tue, 19 Feb 2013 07:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.458
X-Spam-Level: 
X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvT7IKTjX374 for ; Tue, 19 Feb 2013 07:56:41 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCF421F8B71 for ; Tue, 19 Feb 2013 07:56:34 -0800 (PST)
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 r1JFuYIq019857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Feb 2013 16:56:34 +0100
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 r1JFuYWW017309 for ; Tue, 19 Feb 2013 16:56:34 +0100 (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 r1JFuXa5028723 for ; Tue, 19 Feb 2013 16:56:33 +0100
Message-ID: <5123A0B1.2050001@gmail.com>
Date: Tue, 19 Feb 2013 16:56:33 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-imadali-its-vinipv6-vula-00.txt
References: <20130218183751.22385.4373.idtracker@ietfa.amsl.com> <512392BB.8040909@gmail.com>
In-Reply-To: <512392BB.8040909@gmail.com>
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: Tue, 19 Feb 2013 15:56:49 -0000

Le 19/02/2013 15:56, Brian E Carpenter a écrit :
>> 3.3.  Examples of use
>>
>>     The Mobile Router (MR) that executes the previous algorithm, is
>>     capable of announcing the generated prefix on one or several internal
>>     interfaces and configure one or several external interfaces,
>>     depending on the scenario.  For instance, under some conditions,
>>     knowing the VIN code of a vehicle, one can deduce the internally
>>     advertised prefix and remotely access a well-known internal device
>>     (with a certain MAC address).  This access might be possible for
>>     vehicle manufacturers in order to perform remote diagnostic, or other
>>     car rental companies depending on the application.
>>
>>     Using the vehicle's VIN and the above method, the MR can deduce the
>>     same VULA prefix and advertise it internally or use it to configure
>>     its own external interfaces.
>
> By definition, any prefix that can be used like this is not a ULA prefix,
> and has no place under fc00::/7. ULA prefixes are not to be routed externally.

ULA prefixes are not to be routed externally, as long as we're clear 
about what is external and internal.

In the vehicular communications scope, one often talks about 'inside a 
vehicle' (V) and 'outside of vehicle' (V2V or V2I).  But it's not clear 
as of yet whether two vehicles form a domain ('inside the two vehicles') 
or each vehicle is a domain in itself.

It's not clear whether the Border Router of ULAs is the same as the 
Mobile Router in vehicular context (the Router deployed in a vehicle).

The number of IP devices in one vehicle is not that large as the number 
of IP devices at a classical 'site', although several IP subnets may be 
present in one vehicle.

One may see several such neighboring vehicles to form a 'domain'.  This 
may be even truer if none is connected to infrastructure.

At that point it may be that ULAs span several vehicles.

I dont see what may forbid the use of ULAs between several vehicles. 
(although I may be wrong).

>> 4.1.  Method 1: RFC 4193 compliant Unique  Local IPv6 Unicast Address
>>        generation
>>
>>     The VIN is, according to section 3.2.2 of RFC 4193, a suitably unique
>>     identifier that could be used locally to the MR for the generation of
>>     an IPv6 ULA prefix and can thus be used in the algorithm described in
>>     the same section.  Basically, step 2 of the aforementioned algorithm
>>     is transformed in order to take the local VIN code as input.  The
>>     resulting ULA prefix is advertised on MR's ingress interface, or used
>>     to configure any other local interface.
>>
>>     Since RFC 4193 algorithm relies on a pseudo-random generation method
>>     for the ULA prefix, and introduces, for example, the timestamp at the
>>     moment of the execution, two different instances of the same
>>     algorithm given the same VIN code, will result in two different
>>     prefixes.
>
> Yes. That's why, in any ULA deployment where some stability is needed,
> you will only regenerate the ULA prefix in extreme circumstances
> (typically a "factory reset").
>
> ...
>>     Also, the VIN code is hashed and
>>     partly present in the Global ID, which makes it impossible to guess
>>     from a given ULA prefix.
>
> Yes, which is a very good thing from the privacy point of view.
>
>> 4.2.  Method 2: VIN-based Unique Local  IPv6 Unicast Address generation
>>
>>     The conversion method described in Section 3.2 defines a new VULA
>>     prefix format (as depicted in Figure 5) which is guaranteed unique
>>     amongst the VIN-based generated prefixes.  Knowing a VIN code, it is
>>     possible to derive the related ULA prefix and use this information
>>     for a remote access.
>
> This is completely unacceptable as it contradicts the most basic aspect
> of ULAs: the L stands for Local.

I agree.  We'll correct this.

>>     This subtype of ULA prefixes which has enhanced uniqueness guarantees
>>     may be defined in a separate category that requests specific /8
>>     prefix (for example) that are expected to be globally routed.
>
> Something that is globally routed or externally accessible is by definition
> not a ULA.

Yes, and if I am not wrong, ULAs are globally unique.

A ULA is not globally routable.  We need to clarify this in the draft.

Alex


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



From rogerj@gmail.com  Tue Feb 19 07:59:16 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 F3EF621F8B71 for ; Tue, 19 Feb 2013 07:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajMyaJvlASlG for ; Tue, 19 Feb 2013 07:59:15 -0800 (PST)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9E621F88BE for ; Tue, 19 Feb 2013 07:59:15 -0800 (PST)
Received: by mail-oa0-f47.google.com with SMTP id o17so6982755oag.20 for ; Tue, 19 Feb 2013 07:59:15 -0800 (PST)
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=jErTXnS74pEJZV24qweby7G8lNeI3iciHcXlDyhhJys=; b=gmRZNEGcTcQs3+msIqKBhJlbSakviY3bGSTEowcXrR3LvznAp2fIeAgpC91bFCeBEf Rrxeo0Jnk/EPyrhg3nlVmXhEQ8x1tPazj0l/j89H0xFUgl33wVNgSZ6RNapJ0lxK+Tny VVWwGqlFgXkFM5iIG0ROv5WlO4hsu6mvLBQUX0UAJ2tKWGj/b/o/uOHcgbnjMSZk69gT pMgAp+NTjTolazMqacpgkJkcC7RyL7pd5XXIsQnU2otCQ1QFUN8BhWmACNsnq4G4rDbX Md6Ghlm4rxBQFlqeeYd2XCSaqydAi2VjXrNzjj5yQVC5Vr5FS2Sy+QbEPoWP57RcIXJ9 YyTw==
MIME-Version: 1.0
X-Received: by 10.182.161.39 with SMTP id xp7mr7976026obb.71.1361289554985; Tue, 19 Feb 2013 07:59:14 -0800 (PST)
Received: by 10.76.167.106 with HTTP; Tue, 19 Feb 2013 07:59:14 -0800 (PST)
In-Reply-To: <5123A0B1.2050001@gmail.com>
References: <20130218183751.22385.4373.idtracker@ietfa.amsl.com> <512392BB.8040909@gmail.com> <5123A0B1.2050001@gmail.com>
Date: Tue, 19 Feb 2013 16:59:14 +0100
Message-ID: 
Subject: Re: I-D Action: draft-imadali-its-vinipv6-vula-00.txt
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Alexandru Petrescu 
Content-Type: text/plain; charset=ISO-8859-1
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, 19 Feb 2013 15:59:16 -0000

On Tue, Feb 19, 2013 at 4:56 PM, Alexandru Petrescu
 wrote:

> Yes, and if I am not wrong, ULAs are globally unique.

There is no guaranty that it will ever be unique, just that the chance
of a collision are quite low.



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger@jorgensen.no

From alexandru.petrescu@gmail.com  Tue Feb 19 08:04: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 412A021F8C3E for ; Tue, 19 Feb 2013 08:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.305
X-Spam-Level: 
X-Spam-Status: No, score=-10.305 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD192PxBFoFi for ; Tue, 19 Feb 2013 08:04:22 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7502821F8C22 for ; Tue, 19 Feb 2013 08:04:22 -0800 (PST)
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 r1JG4L5S025601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 17:04:21 +0100
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 r1JG4K8f020326; Tue, 19 Feb 2013 17:04:20 +0100 (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 r1JG4J4B000582; Tue, 19 Feb 2013 17:04:20 +0100
Message-ID: <5123A283.8010907@gmail.com>
Date: Tue, 19 Feb 2013 17:04:19 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
Subject: Re: I-D Action: draft-imadali-its-vinipv6-vula-00.txt
References: <20130218183751.22385.4373.idtracker@ietfa.amsl.com> <512392BB.8040909@gmail.com> <5123A0B1.2050001@gmail.com> 
In-Reply-To: 
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: Tue, 19 Feb 2013 16:04:23 -0000

Le 19/02/2013 16:59, Roger Jørgensen a écrit :
> On Tue, Feb 19, 2013 at 4:56 PM, Alexandru Petrescu
>  wrote: 
>> Yes, and if I am not wrong, ULAs are globally unique.
>
> There is no guaranty that it will ever be unique, just that the
> chance of a collision are quite low.

I agree.  The same with VINs - they are globally unique, with a
probability of collision.  There exists a paying non-IETF standard
document which requires each VIN to be unique, but implementations may
fault.

I think there is no risk of tainting one's uniqueness properties when
mapping.

Alex




From dougb@dougbarton.us  Tue Feb 19 09:39: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 1EF2921F8C49 for ; Tue, 19 Feb 2013 09:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level: 
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.228,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-2cXEcwlHOK for ; Tue, 19 Feb 2013 09:39:11 -0800 (PST)
Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 687A321F8904 for ; Tue, 19 Feb 2013 09:39:11 -0800 (PST)
Received: from [IPv6:2001:470:d:5e7:d03d:1907:b847:f75b] (unknown [IPv6:2001:470:d:5e7:d03d:1907:b847:f75b]) by dougbarton.us (Postfix) with ESMTPSA id 9F8D922B1D for ; Tue, 19 Feb 2013 17:39:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1361295550; bh=6/rnt/tG6zYPeHAt5AEsTCTwhwI2WZrWCRwKiSA4JKQ=; h=Date:From:To:Subject:References:In-Reply-To; b=dgHo1398iCYQVMwfmHt7lOvn43AmETQCdt+r9fYeuwlA1O2pnS1DGedG1iZ97PuvY /OOGcgMAN0exEDzra4sFCkBwwcEHdSrXNrp5ycb/3I/ukDKxK/O/MqN61pECVAN4HV 5oGO/IcJBmlvALTzTs+Wp3OZwbKTuEz3mrq7saPs=
Message-ID: <5123B8BE.5080304@dougbarton.us>
Date: Tue, 19 Feb 2013 09:39:10 -0800
From: Doug Barton 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com> <51239CD7.6060004@gmail.com>
In-Reply-To: <51239CD7.6060004@gmail.com>
X-Enigmail-Version: 1.4.6
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: Tue, 19 Feb 2013 17:39:12 -0000

On 02/19/2013 07:40 AM, Alexandru Petrescu wrote:
> Such a concern would be all the more valid if there were a specification
> which said 'each vehicle MUST form its IIDs based on their VINs'.  But
> this is not the case.  We are not trying for such a definitive document.
>
> We are certain that some vehicles will never use this VIN-based
> addressing scheme.  At that point, someone receiving a packet with a
> certain source address will never know whether that packet is from a
> vehicle or from something else.  A reversal of the IP into a number will
> never be sure to be a VIN.

But the fact that _some_ of them may be VINs make it a potential source 
of data mining, which should be avoided if at all possible.

There is no reason that manufacturers cannot keep their own mapping of 
VIN to IID, and making this process NON-standard (that is, not 
documenting a standard way to do it) will slightly decrease the value of 
that data, although wouldn't necessarily help the Ferrari-nee-Fiat 
problem. :)

Doug


From warren@kumari.net  Tue Feb 19 12:14: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 8E68721F8956 for ; Tue, 19 Feb 2013 12:14:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level: 
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZX-Jcl6Xrk7 for ; Tue, 19 Feb 2013 12:14:37 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94E521F88BC for ; Tue, 19 Feb 2013 12:14:37 -0800 (PST)
Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 82F131B4115F; Tue, 19 Feb 2013 15:14:36 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [6MAN] Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
From: Warren Kumari 
In-Reply-To: <51238CD8.6030805@gmail.com>
Date: Tue, 19 Feb 2013 15:14:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <054E400A-F41D-4941-95B5-06C9EB0515B4@kumari.net>
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1499)
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, 19 Feb 2013 20:14:38 -0000

On Feb 19, 2013, at 9:31 AM, Alexandru Petrescu =
 wrote:

> Le 18/02/2013 22:07, Roger J=F8rgensen a =E9crit :
>> On Mon, Feb 18, 2013 at 9:36 PM, Scott Brim 
>> wrote:
>>> I have the usual concerns about privacy.  I have no problem with
>>> someone knowing the endpoint that is communicating is associated
>>> with a vehicle (or that I, a human, am communicating from a
>>> vehicle).  However, if someone can map easily from an IP address to
>>> a VIN (thus knowing the specific vehicle from which the
>>> communication is happening), and I have no choice but to reveal
>>> that information in order to communicate at all, I am not
>>> comfortable.  In general, as an architectural principle, I want the
>>> option to control how much personal information I reveal.  That's
>>> called privacy.
>=20
> Scott,
>=20
> I agree privacy is important.
>=20
> An alternative method from R. Bless proposes to use a SHA output in =
the
> prefix field of an address.  This has an advantage with respect to
> privacy - it's hardly feasible to reversely derive the VIN of the
> vehicle from the IPv6 address, slide 6 of
> =
http://www.lara.prd.fr/_media/ipv6-its/2012-03-26-seis-kit-ietf83-its.pdf

Actually, I suspect that if the "OEM-specific-256bit Key" gets exposed =
then determining the VIN will be fairly trivial -- I guess the answer is =
simply "well, don't leak the key then"?

It is unclear to me who exactly generates the address -- if the =
manufacturer calculates it before it leaves the factory then this isn't =
as likely as if the vehicle does (because it would then need the key =
somewhere)=85

W

>=20
> That method alone has certain advantages, but also drawbacks.
>=20
> If we consider the problem to be as simple as "how to form IPv6
> addresses in a vehicle?" then one realizes that just forming a ULA
> prefix for _within_ the vehicle may not be enough.  Communication
> outside the vehicle (e.g. between two vehicles) may involve links =
which
> may not be just plain Ethernet, and hence impossible to just use =
RFC2464
> LL addresses on the outside of the vehicle.
>=20
> In some cases it _is_ possible to get along with just LL/Ethernet
> addresses between vehicles, but if/when
> geonetworking/other-vehicular-link-layers are used, then that may not =
be
> enough.
>=20
> All in all, depending on the problem, the VIN-based addresses may be
> necessary, provided that privacy concerns are addressed.
>=20
> Alex
>=20
>=20
>=20
>>=20
>> Actual the problem is much simpler, it's not that easy to get the
>> unique ID of a vehicle today, however with the proposed solution it
>> become extremely easy. Sort of the same idea that caused IPv6 to
>> create all IPs based on the mac address... we know how that ended, we
>> created the privacy option.
>>=20
>> Do we want todo it all over again?
>>=20
>>=20
>>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20

--
It's a mistake trying to cheer up camels. You might as well drop =
meringues into a black hole. -- Terry Prachett



From alexandru.petrescu@gmail.com  Tue Feb 19 12:40: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 D4FE021F8956 for ; Tue, 19 Feb 2013 12:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.39
X-Spam-Level: *
X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaHvh02DfrRG for ; Tue, 19 Feb 2013 12:40:27 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0D72221F8903 for ; Tue, 19 Feb 2013 12:40:25 -0800 (PST)
Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C2E429401AC for ; Tue, 19 Feb 2013 21:40:16 +0100 (CET)
Message-ID: <5123E32E.7060708@gmail.com>
Date: Tue, 19 Feb 2013 21:40:14 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com> <51239CD7.6060004@gmail.com> <5123B8BE.5080304@dougbarton.us>
In-Reply-To: <5123B8BE.5080304@dougbarton.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 130219-1, 19/02/2013), Outbound message
X-Antivirus-Status: Clean
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, 19 Feb 2013 20:40:28 -0000

Le 19/02/2013 18:39, Doug Barton a écrit :
> On 02/19/2013 07:40 AM, Alexandru Petrescu wrote:
>> Such a concern would be all the more valid if there were a
>> specification which said 'each vehicle MUST form its IIDs based on
>>  their VINs'.  But this is not the case.  We are not trying for
>> such a definitive document.
>>
>> We are certain that some vehicles will never use this VIN-based
>> addressing scheme.  At that point, someone receiving a packet with
>>  a certain source address will never know whether that packet is
>> from a vehicle or from something else.  A reversal of the IP into a
>> number will never be sure to be a VIN.
>
> But the fact that _some_ of them may be VINs make it a potential
> source of data mining, which should be avoided if at all possible.

Data mining should be avoided if possible.  The methods proposed are not
final, and they should be improved.

I would like to add about data mining.

Outside the VIN discussion, it is already possible to not use Privacy
Addresses.  For example, a recent experiment with IPv6 cellular client
shows me that the IPv6 addresses of the smartphone has the IID derived
from a manufacturer's ID.

To some extent this is a privacy issue, because data mining could find
out that the manufacturer of my equipment is that brand, and propose me
that brand when I buy a tablet on amazon.

In that sense, I doubt it is possible for anybody to impose the use of
Privacy Addresses (randon number in IID, if I am not wrong) to e.g. many
cellular operators.  It is still seen as an option (I think).

The same for VIN - if a use is found about the conversion of VIN to an
IP address, it is good to build in privacy, in a certain sense.  But
it's hard to make sure it's accepted.

Rejecting VIN-based addresses just because of privacy aspects is
debatable, IMHO.

> There is no reason that manufacturers cannot keep their own mapping
> of VIN to IID, and making this process NON-standard (that is, not
> documenting a standard way to do it) will slightly decrease the value
> of that data, although wouldn't necessarily help the Ferrari-nee-Fiat
> problem. :)

I agree.  Manufacturers may indeed keep their own mapping VIN-to-IID, or
other VIN-to-prefix mappings.  This would not be visible to Internet.

I would to stress further that the two drafts we propose are simply
methods.  One is to generate an IID and the other is to generate a ULA
prefix, each from same VIN.

Depending on how IID and ULA are combined, and how the connection to
Internet is made (tunnel or not, IPsec or not, etc) and how the address
architecture plan for vehicles is made, various Privacy issues may
arise, or may not.

I think I may need to actually better expose the problem: how to form
IPv6 addresses for vehicles. (yes we know these already exist: DHPCv6,
PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).

Alex

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


From swb@internet2.edu  Tue Feb 19 13:07: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 16C8621F8AC0 for ; Tue, 19 Feb 2013 13:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.824
X-Spam-Level: 
X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sETSgnphEcs for ; Tue, 19 Feb 2013 13:07:44 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC5721F8ABA for ; Tue, 19 Feb 2013 13:07:42 -0800 (PST)
Received: from mail195-co1-R.bigfish.com (10.243.78.218) by CO1EHSOBE031.bigfish.com (10.243.66.96) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Feb 2013 21:07:41 +0000
Received: from mail195-co1 (localhost [127.0.0.1])	by mail195-co1-R.bigfish.com (Postfix) with ESMTP id CFA60CC00DC; Tue, 19 Feb 2013 21:07:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: S-1(zzbb2dI98dI9371Ic89bh1432Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h190ch1946h19b4h19c3h19ceh1155h)
Received: from mail195-co1 (localhost.localdomain [127.0.0.1]) by mail195-co1 (MessageSwitch) id 1361308060411559_17506; Tue, 19 Feb 2013 21:07:40 +0000 (UTC)
Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.199])	by mail195-co1.bigfish.com (Postfix) with ESMTP id 56540A8004F; Tue, 19 Feb 2013 21:07:40 +0000 (UTC)
Received: from CH1PRD0811HT001.namprd08.prod.outlook.com (157.56.245.85) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Feb 2013 21:07:39 +0000
Received: from swbi2mbp.local (67.241.75.185) by pod51019.outlook.com (10.255.155.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 19 Feb 2013 21:07:35 +0000
Message-ID: <5123E995.40905@internet2.edu>
Date: Tue, 19 Feb 2013 16:07:33 -0500
From: Scott Brim 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Alexandru Petrescu 
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com> <51239CD7.6060004@gmail.com> <5123B8BE.5080304@dougbarton.us> <5123E32E.7060708@gmail.com>
In-Reply-To: <5123E32E.7060708@gmail.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="windows-1252"
X-Originating-IP: [67.241.75.185]
Content-Transfer-Encoding: quoted-printable
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: Tue, 19 Feb 2013 21:07:45 -0000

On 02/19/13 15:40, Alexandru Petrescu allegedly wrote:
> Le 19/02/2013 18:39, Doug Barton a =E9crit :
>> On 02/19/2013 07:40 AM, Alexandru Petrescu wrote:
>>> Such a concern would be all the more valid if there were a
>>> specification which said 'each vehicle MUST form its IIDs based on
>>>  their VINs'.  But this is not the case.  We are not trying for
>>> such a definitive document.
>>>
>>> We are certain that some vehicles will never use this VIN-based
>>> addressing scheme.  At that point, someone receiving a packet with
>>>  a certain source address will never know whether that packet is
>>> from a vehicle or from something else.  A reversal of the IP into a
>>> number will never be sure to be a VIN.
>>
>> But the fact that _some_ of them may be VINs make it a potential
>> source of data mining, which should be avoided if at all possible.
>=20
> Data mining should be avoided if possible.  The methods proposed are no=
t
> final, and they should be improved.

Great.

> Outside the VIN discussion, it is already possible to not use Privacy
> Addresses.  For example, a recent experiment with IPv6 cellular client
> shows me that the IPv6 addresses of the smartphone has the IID derived
> from a manufacturer's ID.

...

> The same for VIN - if a use is found about the conversion of VIN to an
> IP address, it is good to build in privacy, in a certain sense.  But
> it's hard to make sure it's accepted.
>=20
> Rejecting VIN-based addresses just because of privacy aspects is
> debatable, IMHO.

"Here we need a change of approach: Businesses must use their power of
innovation to improve the protection of privacy and personal data from
the very beginning of the development cycle. Privacy by Design is a
principle that is in the interest of both citizens and businesses.
Privacy by Design will lead to better protection for individuals, as
well as to trust and confidence in new services and products that will
in turn have a positive impact on the economy. I have seen some
encouraging examples, but much more needs to be done." -- Viviane
Reding, Jan 2010

> I think I may need to actually better expose the problem: how to form
> IPv6 addresses for vehicles. (yes we know these already exist: DHPCv6,
> PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).

That would be good.


From joelja@bogus.com  Tue Feb 19 13:08: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 0FA1621F8A85 for ; Tue, 19 Feb 2013 13:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciPREDLkpDcJ for ; Tue, 19 Feb 2013 13:08:29 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4421F8536 for ; Tue, 19 Feb 2013 13:08:29 -0800 (PST)
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 r1JL8REE010420 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 21:08:27 GMT (envelope-from joelja@bogus.com)
Message-ID: <5123E9C5.4080507@bogus.com>
Date: Tue, 19 Feb 2013 13:08:21 -0800
From: joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: Alexandru Petrescu , ipv6@ietf.org
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com> <51239CD7.6060004@gmail.com> <5123B8BE.5080304@dougbarton.us> <5123E32E.7060708@gmail.com>
In-Reply-To: <5123E32E.7060708@gmail.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]); Tue, 19 Feb 2013 21:08:27 +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: Tue, 19 Feb 2013 21:08:30 -0000

On 2/19/13 12:40 PM, Alexandru Petrescu wrote:
>
>
> I think I may need to actually better expose the problem: how to form
> IPv6 addresses for vehicles. (yes we know these already exist: DHPCv6,
> PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).
>
One of the questions I have in that context what special property of 
cars make them need a new method?
> Alex
>
>>
>> Doug
>>
>> --------------------------------------------------------------------
>> 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 ales.vizdal@t-mobile.cz  Tue Feb 19 13:49: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 7E15F21F87D5 for ; Tue, 19 Feb 2013 13:49:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.786
X-Spam-Level: 
X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.164,  BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+OP-NXZh4gU for ; Tue, 19 Feb 2013 13:49:44 -0800 (PST)
Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id BFE3221E805E for ; Tue, 19 Feb 2013 13:49:42 -0800 (PST)
Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id CE29C285804; Tue, 19 Feb 2013 22:49:40 +0100 (CET)
Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 19 Feb 2013 22:49:40 +0100
From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= 
To: Alexandru Petrescu , "ipv6@ietf.org" 
Date: Tue, 19 Feb 2013 22:49:41 +0100
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: Ac4O4WcMp6VfW++PRV+pIHFBp1cIfgACKdQQ
Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFB3BD43@SRVHKE02.rdm.cz>
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com> <51239CD7.6060004@gmail.com> <5123B8BE.5080304@dougbarton.us> <5123E32E.7060708@gmail.com>
In-Reply-To: <5123E32E.7060708@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Forwarded
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, 19 Feb 2013 21:49:44 -0000

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of A=
lexandru
> Petrescu
> Sent: Tuesday, February 19, 2013 9:40 PM
> To: ipv6@ietf.org
> Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
=20
> Outside the VIN discussion, it is already possible to not use Privacy
> Addresses.  For example, a recent experiment with IPv6 cellular client
> shows me that the IPv6 addresses of the smartphone has the IID derived
> from a manufacturer's ID.

Of course it is, if it is not enabled, it's not enabled ...=20

btw. The 3GPP specs forbid to base the IID on your number/MSISDN, IMSI=20
or any other identifier. (just in case someone would want to make their lif=
e=20
easier)

> To some extent this is a privacy issue, because data mining could find
> out that the manufacturer of my equipment is that brand, and propose me
> that brand when I buy a tablet on amazon.
>=20
> In that sense, I doubt it is possible for anybody to impose the use of
> Privacy Addresses (randon number in IID, if I am not wrong) to e.g. many
> cellular operators.  It is still seen as an option (I think).

Mobile Operators (following their Privacy departments) are very likely to r=
equest=20
handsets with Privacy Extensions enabled by default, the same could be the =
case=20
for all 'good' mobile stuff vendors.

Ales

From hesham@elevatemobile.com  Tue Feb 19 16:01: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 0551321F874C for ; Tue, 19 Feb 2013 16:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.309
X-Spam-Level: 
X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXD8h+KfQxae for ; Tue, 19 Feb 2013 16:01:14 -0800 (PST)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5D821F8740 for ; Tue, 19 Feb 2013 16:01:13 -0800 (PST)
Received: from [118.209.87.64] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1U7x7V-00081t-M4; Wed, 20 Feb 2013 11:01:11 +1100
User-Agent: Microsoft-MacOutlook/14.3.0.121105
Date: Wed, 20 Feb 2013 11:01:06 +1100
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
From: Hesham Soliman 
To: Alexandru Petrescu , 
Message-ID: 
Thread-Topic: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
In-Reply-To: <5123897E.60905@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-User: hesham@elevatemobile.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: Wed, 20 Feb 2013 00:01:15 -0000

>>
>>=> Someone, somewhere (perhaps the IAB) needs to write an
>> architectural document to tell various industries to _stop_ doing
>> that. The IID is a set of bits that have no meaning, please stop
>> trying to create it in an industry/link layer technology-specific
>> manner. It does do anything and it's meaningless.
>
>I think you're too strong with statements.  Many IPv-over-foo documents
>exist and they do just that - create IID in a industry-specific manner.

=> My opinion covers those cases too. It's a broken concept. I think an
RNG is find as a generic method. We don't need to do some magic to create
an IID for each case.

>The need comes from further, and it may look simpler: we need to form
>IPv6 addresses within a vehicle.

=> Use an RNG to create the 64 bits then run DAD, it's pretty straight
forward.

Hesham


>
>There are a number of solutions to realize it, but each has its
>advantages and inconvenients.  Forming it from VIN has some advantages.
>
>We can discuss this.
>
>Alex
>
>
>>
>> Hesham
>>
>>
>>>
>>>
>>> --
>>>
>>> Roger Jorgensen           | ROJO9-RIPE rogerj@gmail.com          |
>>> - IPv6 is The Key! http://www.jorgensen.no   | roger@jorgensen.no
>>> --------------------------------------------------------------------
>>>
>>>
>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
>> --------------------------------------------------------------------
>>
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------



From dougb@dougbarton.us  Tue Feb 19 19:19: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 4413C21F8814 for ; Tue, 19 Feb 2013 19:19:23 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXBdx+h9jti0 for ; Tue, 19 Feb 2013 19:19:22 -0800 (PST)
Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 15DC221F8810 for ; Tue, 19 Feb 2013 19:19:22 -0800 (PST)
Received: from [IPv6:2001:470:d:5e7:5cad:5a38:9a3c:5828] (unknown [IPv6:2001:470:d:5e7:5cad:5a38:9a3c:5828]) by dougbarton.us (Postfix) with ESMTPSA id 9540122B0F for ; Wed, 20 Feb 2013 03:19:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1361330361; bh=fCidIaJP1hzqQYwY8PD6DaFUk1Gh4mYdQgafKTG4vVc=; h=Date:From:To:Subject:References:In-Reply-To; b=sa6cH2MAp+LqlMPtBoJp3sD70+zTmsxSaDg/TI49efKqqQY01+FeoMR7x+KTQQoPb OGQKxY0GDtgcQgPDrLYux/Fzngyu0brRMHkP2x/MKkNEN0zQOfqbYrMidZ5/NWsS+l LCtkYu/n4FlYEpQenmUpk5Uz+BomFoB1hDzASpg0=
Message-ID: <512440B9.7010106@dougbarton.us>
Date: Tue, 19 Feb 2013 19:19:21 -0800
From: Doug Barton 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt
References: <20130218183623.2809.21129.idtracker@ietfa.amsl.com> <51238EEE.8060804@gmail.com> <51239CD7.6060004@gmail.com> <5123B8BE.5080304@dougbarton.us> <5123E32E.7060708@gmail.com>
In-Reply-To: <5123E32E.7060708@gmail.com>
X-Enigmail-Version: 1.4.6
OpenPGP: id=1A1ABC84
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, 20 Feb 2013 03:19:23 -0000

On 02/19/2013 12:40 PM, Alexandru Petrescu wrote:
> Le 19/02/2013 18:39, Doug Barton a écrit :
>> On 02/19/2013 07:40 AM, Alexandru Petrescu wrote:
>>> Such a concern would be all the more valid if there were a
>>> specification which said 'each vehicle MUST form its IIDs based on
>>>  their VINs'.  But this is not the case.  We are not trying for
>>> such a definitive document.
>>>
>>> We are certain that some vehicles will never use this VIN-based
>>> addressing scheme.  At that point, someone receiving a packet with
>>>  a certain source address will never know whether that packet is
>>> from a vehicle or from something else.  A reversal of the IP into a
>>> number will never be sure to be a VIN.
>>
>> But the fact that _some_ of them may be VINs make it a potential
>> source of data mining, which should be avoided if at all possible.
>
> Data mining should be avoided if possible.  The methods proposed are not
> final, and they should be improved.

What the replies so far have said is that they should not be done at all.

> I would like to add about data mining.
>
> Outside the VIN discussion, it is already possible to not use Privacy
> Addresses.

The fact that it's possible for people to voluntarily configure their 
system to be less private doesn't have anything to do with creating a 
system to tie VINs and IIDs that the user will not be able to opt out 
of. There are valid reasons not to use privacy addresses, there are no 
good reasons to do the latter at all, and many reasons that you shouldn't.

I snipped the rest of your argument along this line because it falls 
into the "faulty premises lead to faulty conclusions" fallacy.

> Rejecting VIN-based addresses just because of privacy aspects is
> debatable, IMHO.

Any argument to the effect that there should be a way to tie together 
VINs and IIDs should come with sufficient justification to overcome the 
privacy concerns that have been almost universally expressed by a wide 
variety of posters (at least twice now). I haven't seen such a 
justification.

>> There is no reason that manufacturers cannot keep their own mapping
>> of VIN to IID, and making this process NON-standard (that is, not
>> documenting a standard way to do it) will slightly decrease the value
>> of that data, although wouldn't necessarily help the Ferrari-nee-Fiat
>> problem. :)
>
> I agree.  Manufacturers may indeed keep their own mapping VIN-to-IID, or
> other VIN-to-prefix mappings.  This would not be visible to Internet.

Then the problem is solved, full stop.

Doug


From roland.bless@kit.edu  Wed Feb 20 01:56: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 1E7F121F8775 for ; Wed, 20 Feb 2013 01:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.082
X-Spam-Level: 
X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72XsAT9QNZD1 for ; Wed, 20 Feb 2013 01:56:53 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 528D521F8780 for ; Wed, 20 Feb 2013 01:56:53 -0800 (PST)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25  id 1U86Ps-0001Ea-0W; Wed, 20 Feb 2013 10:56:52 +0100
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 1U86Pr-0004Zy-Ps; Wed, 20 Feb 2013 10:56:43 +0100
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 9F50DA80682; Wed, 20 Feb 2013 10:56:43 +0100 (CET)
Message-ID: <51249DDB.5020704@kit.edu>
Date: Wed, 20 Feb 2013 10:56:43 +0100
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: Alexandru Petrescu 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com>
In-Reply-To: <51238CD8.6030805@gmail.com>
X-Enigmail-Version: 1.5
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 1361354212.664656000
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, 20 Feb 2013 09:56:55 -0000

Hi Alex,

On 19.02.2013 15:31, Alexandru Petrescu wrote:
> I agree privacy is important.
> 
> An alternative method from R. Bless proposes to use a SHA output in the
> prefix field of an address.  This has an advantage with respect to
> privacy - it's hardly feasible to reversely derive the VIN of the
> vehicle from the IPv6 address, slide 6 of
> http://www.lara.prd.fr/_media/ipv6-its/2012-03-26-seis-kit-ietf83-its.pdf
> 
> That method alone has certain advantages, but also drawbacks.

> If we consider the problem to be as simple as "how to form IPv6
> addresses in a vehicle?" then one realizes that just forming a ULA
> prefix for _within_ the vehicle may not be enough.  Communication

This is sufficient for the onboard communication network, which was
the problem we addressed. ULAs are a good match, since these addresses
should not leak.

> outside the vehicle (e.g. between two vehicles) may involve links which
> may not be just plain Ethernet, and hence impossible to just use RFC2464
> LL addresses on the outside of the vehicle.

Our model was to have a security gateway for external connectivity
and we assume that we may have various different access technologies
such as LTE, WLAN, Bluetooth, and so on, i.e., multi-homing and
changing addresses.

I don't see any requirement to use algorithmically
defined VIN-based addresses _between_ two vehicles:
usually cars don't know which other cars are currently around them
and especially they cannot know their VINs a priori.
So usually you would need some kind of discovery protocol using
well-known group addresses in order to figure out the unicast IPv6
addresses.

> All in all, depending on the problem, the VIN-based addresses may be
> necessary, provided that privacy concerns are addressed.

I don't see the need yet if external communication is concerned.

Regards,
 Roland


From randy@psg.com  Wed Feb 20 03:09: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 A042121F873C for ; Wed, 20 Feb 2013 03:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Level: 
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsW6TgRMSDVn for ; Wed, 20 Feb 2013 03:09:53 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 36D5021F8716 for ; Wed, 20 Feb 2013 03:09:53 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U87Yb-0001RS-7O; Wed, 20 Feb 2013 11:09:49 +0000
Date: Wed, 20 Feb 2013 20:09:48 +0900
Message-ID: 
From: Randy Bush 
To: Roland Bless 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
In-Reply-To: <51249DDB.5020704@kit.edu>
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Cc: Alexandru Petrescu , 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, 20 Feb 2013 11:09:54 -0000

> This is sufficient for the onboard communication network, which was
> the problem we addressed. ULAs are a good match, since these addresses
> should not leak.

and rfc1918 should not leak

randy

From roland.bless@kit.edu  Wed Feb 20 03:37: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 69D7E21F8793 for ; Wed, 20 Feb 2013 03:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.098
X-Spam-Level: 
X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hQbdNhPcrqo for ; Wed, 20 Feb 2013 03:37:29 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id D6D9921F8788 for ; Wed, 20 Feb 2013 03:37:27 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1U87zA-0002kJ-Vj; Wed, 20 Feb 2013 12:37:26 +0100
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 6C03FA80682; Wed, 20 Feb 2013 12:37:16 +0100 (CET)
Message-ID: <5124B56C.1050103@kit.edu>
Date: Wed, 20 Feb 2013 12:37:16 +0100
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: Randy Bush 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu> 
In-Reply-To: 
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 1361360246.819678000
Cc: Alexandru Petrescu , 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, 20 Feb 2013 11:37:29 -0000

Hi Randy,

On 20.02.2013 12:09, Randy Bush wrote:
>> This is sufficient for the onboard communication network, which was
>> the problem we addressed. ULAs are a good match, since these addresses
>> should not leak.
> 
> and rfc1918 should not leak

Yes, I know in practice they do leak, that's why I wrote "should".
My statement was a little bit imprecise - I apologize.
No leakage wasn't actually my point rather than internal use only.
So no matter which kind of addresses you employ for "internal
use" only, they may accidentally leak due to misconfiguration,
failures etc. The advantage of ULAs is though: if they leak, they
are still unique with a high probability, hopefully causing less
harm than rfc1918 addresses.

Regards,
 Roland


From randy@psg.com  Wed Feb 20 03:40: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 4D12B21F8797 for ; Wed, 20 Feb 2013 03:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Level: 
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAfW2Jlb8ps3 for ; Wed, 20 Feb 2013 03:40:46 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D03F721F8792 for ; Wed, 20 Feb 2013 03:40:46 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U882X-0001Wp-2g; Wed, 20 Feb 2013 11:40:45 +0000
Date: Wed, 20 Feb 2013 20:40:44 +0900
Message-ID: 
From: Randy Bush 
To: Roland Bless 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
In-Reply-To: <5124B56C.1050103@kit.edu>
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu>  <5124B56C.1050103@kit.edu>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Cc: IPv6 Deployment Prevention 
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, 20 Feb 2013 11:40:47 -0000

> Yes, I know in practice they do leak, that's why I wrote "should".  My
> statement was a little bit imprecise - I apologize.  No leakage wasn't
> actually my point rather than internal use only.  So no matter which
> kind of addresses you employ for "internal use" only, they may
> accidentally leak due to misconfiguration, failures etc. The advantage
> of ULAs is though: if they leak, they are still unique with a high
> probability, hopefully causing less harm than rfc1918 addresses.

for more assurance of such wonderful properties, and no probabilities,
you may want to check out ipv6 global address space

randy

From roland.bless@kit.edu  Wed Feb 20 04:49: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 4FA1B21F8788 for ; Wed, 20 Feb 2013 04:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.112
X-Spam-Level: 
X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.137,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tceab4b5S3-v for ; Wed, 20 Feb 2013 04:49:44 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 95F1621F8722 for ; Wed, 20 Feb 2013 04:49:44 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1U897C-0001RF-IL; Wed, 20 Feb 2013 13:49:43 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 66466A80682; Wed, 20 Feb 2013 13:49:38 +0100 (CET)
Message-ID: <5124C662.3070408@kit.edu>
Date: Wed, 20 Feb 2013 13:49:38 +0100
From: "Bless, Roland (TM)" 
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Randy Bush 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu>  <5124B56C.1050103@kit.edu> 
In-Reply-To: 
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 1361364583.945108000
Cc: IPv6 maintenance 
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, 20 Feb 2013 12:49:45 -0000

Hi Randy,

On 20.02.2013 12:40, Randy Bush wrote:
>> Yes, I know in practice they do leak, that's why I wrote "should".  My
>> statement was a little bit imprecise - I apologize.  No leakage wasn't
>> actually my point rather than internal use only.  So no matter which
>> kind of addresses you employ for "internal use" only, they may
>> accidentally leak due to misconfiguration, failures etc. The advantage
>> of ULAs is though: if they leak, they are still unique with a high
>> probability, hopefully causing less harm than rfc1918 addresses.
> 
> for more assurance of such wonderful properties, and no probabilities,
> you may want to check out ipv6 global address space

Agreed, this is probably even a better choice, however,
some manufacturers do not want to pay for non-routable
IPv6 global address space and depending on the number
of manufactured automotives, they need a larger prefix.

Regards,
 Roland


From randy@psg.com  Wed Feb 20 04:51: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 CC6DE21F87AF for ; Wed, 20 Feb 2013 04:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Level: 
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4WKkm7O3wmo for ; Wed, 20 Feb 2013 04:51:52 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2921F8722 for ; Wed, 20 Feb 2013 04:51:48 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U899E-0001ju-Hn; Wed, 20 Feb 2013 12:51:44 +0000
Date: Wed, 20 Feb 2013 21:51:44 +0900
Message-ID: 
From: Randy Bush 
To: "Bless, Roland (TM)" 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
In-Reply-To: <5124C662.3070408@kit.edu>
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu>  <5124B56C.1050103@kit.edu>  <5124C662.3070408@kit.edu>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Cc: IPv6 maintenance 
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, 20 Feb 2013 12:51:54 -0000

>> for more assurance of such wonderful properties, and no
>> probabilities, you may want to check out ipv6 global address space
> Agreed, this is probably even a better choice, however,
> some manufacturers do not want to pay for non-routable
> IPv6 global address space and depending on the number
> of manufactured automotives, they need a larger prefix.

ahh.  so this is really just another end-run around the registry
system.  instead, fix the registries.

randy

From warren@kumari.net  Wed Feb 20 05:57: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 CB04B21F87CD for ; Wed, 20 Feb 2013 05:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfE3Ib-rpR6S for ; Wed, 20 Feb 2013 05:57:49 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216D021F8634 for ; Wed, 20 Feb 2013 05:57:48 -0800 (PST)
Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 00B111B40706; Wed, 20 Feb 2013 08:57:47 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [6MAN] Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
From: Warren Kumari 
In-Reply-To: <5124C662.3070408@kit.edu>
Date: Wed, 20 Feb 2013 08:57:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E44F607-2DFB-47F5-AEE5-4087742AB27A@kumari.net>
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu>  <5124B56C.1050103@kit.edu>  <5124C662.3070408@kit.edu>
To: "Bless, Roland (TM)" 
X-Mailer: Apple Mail (2.1499)
Cc: IPv6 maintenance 
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, 20 Feb 2013 13:57:49 -0000

On Feb 20, 2013, at 7:49 AM, "Bless, Roland (TM)"  =
wrote:

> Hi Randy,
>=20
> On 20.02.2013 12:40, Randy Bush wrote:
>>> Yes, I know in practice they do leak, that's why I wrote "should".  =
My
>>> statement was a little bit imprecise - I apologize.  No leakage =
wasn't
>>> actually my point rather than internal use only.  So no matter which
>>> kind of addresses you employ for "internal use" only, they may
>>> accidentally leak due to misconfiguration, failures etc. The =
advantage
>>> of ULAs is though: if they leak, they are still unique with a high
>>> probability, hopefully causing less harm than rfc1918 addresses.
>>=20
>> for more assurance of such wonderful properties, and no =
probabilities,
>> you may want to check out ipv6 global address space
>=20
> Agreed, this is probably even a better choice, however,
> some manufacturers do not want to pay for non-routable
> IPv6 global address space and depending on the number
> of manufactured automotives, they need a larger prefix.

What?! A large manufacturer, selling enough vehciles that they exhaust a =
large prefix *doesn't want to pay*?=20

I'm shocked=85 shocked I tell you=85

W


>=20
> Regards,
> Roland
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and =
he'll be warm for the rest of his life." -- Terry Pratchett



From bob.hinden@gmail.com  Wed Feb 20 07:41: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 5D29021F87C6 for ; Wed, 20 Feb 2013 07:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.322
X-Spam-Level: 
X-Spam-Status: No, score=-103.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbXihFLujGeR for ; Wed, 20 Feb 2013 07:41:48 -0800 (PST)
Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 99C5D21F87BA for ; Wed, 20 Feb 2013 07:41:48 -0800 (PST)
Received: by mail-ea0-f182.google.com with SMTP id a12so3536863eaa.41 for ; Wed, 20 Feb 2013 07:41:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=gBQ+rX43Wf/xnHBMAK5H4880gG0P4eEUZr3IGgEG0uk=; b=j8zR4Kdq4sjTstQML1mYtZh7LAjVFhHNfeDkCSVmfYNoWhfesH3bYreNOK0WbvmNX0 EBF2sadwuGDiItbJjCY0Bkiui53MpSJBmKF+DzK9gZ27np5Zp08571TySQ+/7hEHIp6b esJ35g40ITG5PhyPA/yLSGHJWTO9MUl6BVyTHLSVraEcL2PNzjT3L/bL4fKLLLpDtewt W6u8CdNlYp+NZbZROcPDqXjPCmyOdwmJC0vLgtliddPGnEdnssAcgZRyvHHD3I6xnkjr vVL5YlEH/Q3VXZ9NCusNKYhF+shOai/oO8nyZrEsrfVNqYhfXswgfvLTUCH/IL9k055o X6JA==
X-Received: by 10.14.209.131 with SMTP id s3mr69872417eeo.26.1361374907813; Wed, 20 Feb 2013 07:41:47 -0800 (PST)
Received: from [172.24.248.238] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPS id s3sm39463052eem.4.2013.02.20.07.41.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Feb 2013 07:41:46 -0800 (PST)
From: Bob Hinden 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Chairs Conclusion on 
Date: Wed, 20 Feb 2013 17:41:44 +0200
Message-Id: <3119D9E7-E1A3-4C04-A489-09D15ED8B34F@gmail.com>
To: 6man List 
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Cc: Bob Hinden 
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, 20 Feb 2013 15:41:49 -0000

After reading the email thread on , the =
6man chairs think the sense of the work group is:

1) The "u and g" bits did not end up being as useful as was thought when =
RFC4291 was standardized.  Consequently, we don't think there is any =
need to continue the notion that an IID with "u" set to 1 means the IID =
contains a globally unique token.

2) Under the current scheme defined in RFC4291, the "u" bit only means =
that the node creating the IID asserts that it is globally unique.  It =
is incorrect to make any other assumptions about what is in the IID.  =
The IID should be viewed as opaque by third parties.

3) There isn't any need to change any running code.  There isn't any =
operational problem with the current definition of the "u" and "g" bits. =
  Removing the properties for these bits should only apply to new =
standards that define new methods to create IIDs.

4) DAD should, of course, continue to be used as is specified.

5) Having  become a w.g. document to =
clarify these issues would be useful and we think there is support in =
the w.g. for this.

Bob & Ole
6man chairs

p.s. We are reviewing the discussion on  and =
will send another email on that topic later.


From roland.bless@kit.edu  Wed Feb 20 08:38: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 D847B21F872C for ; Wed, 20 Feb 2013 08:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.04
X-Spam-Level: 
X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.209,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TP9nnMywsJZ for ; Wed, 20 Feb 2013 08:38:38 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4863821F8703 for ; Wed, 20 Feb 2013 08:38:38 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  id 1U8Cgf-0000bl-HA for ; Wed, 20 Feb 2013 17:38:37 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 68FBAA80682 for ; Wed, 20 Feb 2013 17:38:29 +0100 (CET)
Message-ID: <5124FC05.5060309@kit.edu>
Date: Wed, 20 Feb 2013 17:38:29 +0100
From: "Bless, Roland (TM)" 
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Chairs Conclusion on 
References: <3119D9E7-E1A3-4C04-A489-09D15ED8B34F@gmail.com>
In-Reply-To: <3119D9E7-E1A3-4C04-A489-09D15ED8B34F@gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 1361378317.659923000
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, 20 Feb 2013 16:38:39 -0000

Hi,

> After reading the email thread on ,
the 6man chairs think the sense of the work group is:
> 
> 1) The "u and g" bits did not end up being as useful as was thought when RFC4291 was standardized.  Consequently, we don't think there is any need to continue the notion that an IID with "u" set to 1 means the IID contains a globally unique token.
> 
> 2) Under the current scheme defined in RFC4291, the "u" bit only means that the node creating the IID asserts that it is globally unique.  It is incorrect to make any other assumptions about what is in the IID.  The IID should be viewed as opaque by third parties.
> 
> 3) There isn't any need to change any running code.  There isn't any operational problem with the current definition of the "u" and "g" bits.   Removing the properties for these bits should only apply to new standards that define new methods to create IIDs.
> 
> 4) DAD should, of course, continue to be used as is specified.
> 
> 5) Having  become a w.g. document to clarify these issues would be useful and we think there is support in the w.g. for this.

+1

Roland


From brian.e.carpenter@gmail.com  Wed Feb 20 08:39: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 796B121F87D7 for ; Wed, 20 Feb 2013 08:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.901
X-Spam-Level: 
X-Spam-Status: No, score=-100.901 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8akhyzsN9jNM for ; Wed, 20 Feb 2013 08:39:46 -0800 (PST)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 929AF21F8703 for ; Wed, 20 Feb 2013 08:39:46 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id fn15so6813143wgb.32 for ; Wed, 20 Feb 2013 08:39:45 -0800 (PST)
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=WRjCT/pdlFf0IyX02L9SQnPuZth6OsSK78oEwcuC29Q=; b=AlA16cTmDEq0JYzsY3cUT4IMt+ZqfsQIYEQyYYYvKB6qoKpZOsZYjjwjCqxTZUOMAx yl+KXSQ6SkguGiwkAZ7PFjwMl2xYudKEPDOXWD/1OWaf04xTr9Hj0UJPCL/2ODmyF5JZ yz3Xp/56FJ5KLZx3T+LhqGs1G/vtRWS2tmaUGinPq1sedKaPZZ1BddBxFMS0EaWK6Uh5 afcIYCJC35Wnl9dnYouWlQe2rlfLKhfQZa+UCTFpglUjdGM0R3BiN1U1lazTcwgQT4iA 1Jy5QrIoXiDxQ4+XFGz+zBCEq4odddE2C2urz4s7VGD8bGCnHJsgAW9eBnCQzDaJD8ox LUVA==
X-Received: by 10.180.81.164 with SMTP id b4mr33989742wiy.34.1361378385768; Wed, 20 Feb 2013 08:39:45 -0800 (PST)
Received: from [192.168.1.65] (host-2-101-189-229.as13285.net. [2.101.189.229]) by mx.google.com with ESMTPS id gy2sm34918527wib.3.2013.02.20.08.39.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 08:39:44 -0800 (PST)
Message-ID: <5124FC58.6060805@gmail.com>
Date: Wed, 20 Feb 2013 16:39:52 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Bob Hinden 
Subject: Re: Chairs Conclusion on 
References: <3119D9E7-E1A3-4C04-A489-09D15ED8B34F@gmail.com>
In-Reply-To: <3119D9E7-E1A3-4C04-A489-09D15ED8B34F@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: 6man 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: Wed, 20 Feb 2013 16:39:47 -0000

Bob,

That's very much what the authors got from the discussion. We plan
a -01 draft before the cutoff, with many clarifications in the text.

Regards
   Brian

On 20/02/2013 15:41, Bob Hinden wrote:
> After reading the email thread on , the 6man chairs think the sense of the work group is:
> 
> 1) The "u and g" bits did not end up being as useful as was thought when RFC4291 was standardized.  Consequently, we don't think there is any need to continue the notion that an IID with "u" set to 1 means the IID contains a globally unique token.
> 
> 2) Under the current scheme defined in RFC4291, the "u" bit only means that the node creating the IID asserts that it is globally unique.  It is incorrect to make any other assumptions about what is in the IID.  The IID should be viewed as opaque by third parties.
> 
> 3) There isn't any need to change any running code.  There isn't any operational problem with the current definition of the "u" and "g" bits.   Removing the properties for these bits should only apply to new standards that define new methods to create IIDs.
> 
> 4) DAD should, of course, continue to be used as is specified.
> 
> 5) Having  become a w.g. document to clarify these issues would be useful and we think there is support in the w.g. for this.
> 
> Bob & Ole
> 6man chairs
> 
> p.s. We are reviewing the discussion on  and will send another email on that topic later.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

From sofiane.imadali.ietf@gmail.com  Wed Feb 20 09:14: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 CFF3521F886B; Wed, 20 Feb 2013 09:14:35 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5udIQB0-wodI; Wed, 20 Feb 2013 09:14:34 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 058B321F84C7; Wed, 20 Feb 2013 09:14:33 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id gw10so7956134lab.27 for ; Wed, 20 Feb 2013 09:14:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Wqspu2H0/XjTcKVMSfuM+cs8e9YbCJcu6AlmM146Jxw=; b=tD/cAUCZKfKX/0Ykh/VK42HS0xwjIExV2WzoEixMALnGo6j2TUzw2WAkxjA91BgGuj 2gemmEYpM5u7g0x5ZWdGCjzpDCt/urzUdglscLXeGgXxgZKRpHiDdDe3VveC5oDUcq13 rUxnCaclnVClQ/FYy+wAmCVx4oPJFENB97trUjXep8Qyx8pU385GMzgK/ZMDQpdJCnbG BeQnT0BxwCIntmkVNjVG8/SvDQ83hNJN8ofJ+c8Khj3t1EX6Hw6iR5mzmnu8JqGS8dlF xKO4b50kDlEVtQTV82tis1yTouYjuiJAb4CwumK9PsIHKxttuoHfmUBsmZY07Oxan6TP QIwg==
MIME-Version: 1.0
X-Received: by 10.112.13.200 with SMTP id j8mr5277990lbc.68.1361380472803; Wed, 20 Feb 2013 09:14:32 -0800 (PST)
Received: by 10.152.127.6 with HTTP; Wed, 20 Feb 2013 09:14:32 -0800 (PST)
Date: Wed, 20 Feb 2013 18:14:32 +0100
Message-ID: 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
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: ipv6@ietf.org, 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, 20 Feb 2013 17:14:36 -0000

Hi,
Thanks for your interest Roger, your question is very pertinent and I
wanted to share it with the group (hope you don't mind bringing this
offlist mail to the list).

Indeed, one needs to understand the context before understanding the
possible uses of the method.

First, a bit of state of the art that couldn't appear in the drafts.
VIN is not a private information. It is meant to be public. I gave a
list of ISO specifications that say exactly How a VIN is built, Where
it should appear, How to reverse engineer it. In a nutshell, the VIN
is alphanumeric, it appears on your wind shield, and you can break it
down to 3 pieces: the manufacturer ID, the vehicle's description, and
the vehicle ID.

     - What networking questions/perspectives should these VIN-related
data trigger  ?
     - Today in a closed operator domain, the vehicle (Mobile Router)
can generate a ULA prefix for site-scoped communications. It is
subject to collisions if used on a large number of vehicles (10^4 or
more - RFC4193). In the vehicular context you're facing this
limitation.
For applications such as remote diagnosis, or other services
(involving access to in-vehicle Machines), the solution we propose
allows to create a predictable (deterministic manner) unique
(collision-free) prefix, that in a closed loop (operator domain,
manufacturer domain) allows you to determine which vehicle to access
with which prefix: No DNS, No Prefix Delegation, No DHCPv6, nor any
other additional artefact involved.
Again, with this proposal, if you are an operator/manufacturer with a
list of your vehicles fleet, you can determine a list of ULA prefixes
to access each one of them: No additional protocol involved, no
collisions.

     - What applications can be enabled by the use of this kind of
VIN-based Prefixes and IDs ?
     - This also answers the question of regarding those 2 proposals
only from a privacy-concerns standpoint. Vendor web-based apps where
you give a VIN code and  returns the history of a vehicle already
exists. When selling your car, a buyer can look up your VIN in a
database and get a history of car accidents, repairs ...etc all
related to your vehicle. This is no science-fiction, it has already
been used in the US for quite a while. Here is on example googling the
keywords (second hand car VIN history):
http://www.edmunds.com/car-buying/vin-check.html

     - About the privacy concerns.
     - I am no expert in the field of privacy. I do understand the
concerns though, and this is why I chose to trigger them in the draft
and in my research work before it is evoked in the mailling list. My
humble opinion about the subject is that we should not mistake VIN for
a MAC. Not compare them, and not apply blindly the concepts of MAC
randomization for VIN-based IIDs/Prefixes. The compromise of
(Uniqueness/randomization And Privacy) that is studied and
standardized in RFC 4941 for IID, should not directly apply to VIN
with no regard to the nature of the object we are using. Please have a
look at: http://en.wikipedia.org/wiki/VIN_Etching, which should inform
you more about another possible application of VIN (in general, not
just networking) which is car theft prevention, to understand why
*your VIN is a public good and not a private property that you buy
with your car*.

To sum up; in order not to trigger (too soon) the privacy concerns and
be blocked by that, the primal use case (domain, site) would be a
closed operator network, or car manufacturer in the manufacture
(closed loop). This method allows us to set internal routing to access
the in-vehicle devices, by a deterministic manner: VIN --> ULA prefix.
No additional protocol is needed to do that. Any service provided by
this devices (monitoring vehicle state for example) is a use case that
applies to this addressing approach.

Thanks for reading and feedback;
Cheers
Sofiane




On Mon, Feb 18, 2013 at 11:11 PM, Roger J=F8rgensen  wrot=
e:
> Hi,
>
> What I wonder about is why we need this, what are the usecases and the
> _intention_ behind these two draft from you?
>
> just... why?
>
>
> The reason I ask is that I try to understand it, and see if the
> privacy option is a real concern in _your_ context or not.
>
>
>
> --- Roger J ---
>
> On Mon, Feb 18, 2013 at 7:49 PM, sofiane Imadali
>  wrote:
>> Hello 6MAN folks,
>>
>> I would like to announce, on behalf of the co-authors, the submission
>> of 2 drafts relating to VIN-based IPv6 addressing.
>> VIN stands for Vehicle Identification Number, and it is specifically
>> used in a context of IPv6 vehicular communications. These proposals
>> aim at providing discussion about a new mapping/conversion method from
>> VIN to ULA prefixes (guaranteed unique) and Interface Identifiers.
>>
>> Please find the above mentioned documents at:
>> 1) Vehicle Identification Number-Based IPv6 Interface Identifier
>> (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
>> 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
>> Addresses (VULA), at:
>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00
>>
>> Your comments are welcome,
>>
>> Cheers,
>> Sofiane.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
>
> --
>
> Roger Jorgensen           | ROJO9-RIPE
> rogerj@gmail.com          | - IPv6 is The Key!
> http://www.jorgensen.no   | roger@jorgensen.no

From warren@kumari.net  Wed Feb 20 11: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 4757C21E8041 for ; Wed, 20 Feb 2013 11:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.608
X-Spam-Level: 
X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDt4KwlGqkdR for ; Wed, 20 Feb 2013 11:44:47 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC6221E803C for ; Wed, 20 Feb 2013 11:44:47 -0800 (PST)
Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4A2841B409D3; Wed, 20 Feb 2013 14:44:43 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Fwd: New Version Notification for draft-wkumari-long-headers-00.txt
From: Warren Kumari 
Date: Wed, 20 Feb 2013 14:44:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D8BB2F4-F65F-469F-ADA6-07FCDC754D9C@kumari.net>
References: <20130204150759.12582.52282.idtracker@ietfa.amsl.com>
To: IPv6 maintenance 
X-Mailer: Apple Mail (2.1499)
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, 20 Feb 2013 19:44:48 -0000

Hello all,

We wanted to make you aware of a document we submitted a while back =
--unfortunately *someone*[0] forgot to put -6man- somewhere in the =
title.

This document explains issues that *operators* have with "long header =
chains" and devices that need to see the L4 information.

We understand that this is likely to be a controversial document, and =
will spark lively discussion[1].=20

W

[0]: Ok, it was me=85
[1]: AKA Nomex underwear time.

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-wkumari-long-headers-00.txt
> Date: February 4, 2013 10:07:59 AM EST
> To: warren@kumari.net
> Cc: internet-drafts@bonica.org, jjaeggli@zynga.com
>=20
>=20
> A new version of I-D, draft-wkumari-long-headers-00.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
>=20
> Filename:	 draft-wkumari-long-headers
> Revision:	 00
> Title:		 Operational Issues Associated With Long IPv6 =
Extension Header Chains
> Creation date:	 2013-02-04
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:             =
http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-00.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-wkumari-long-headers
> Htmlized:        =
http://tools.ietf.org/html/draft-wkumari-long-headers-00
>=20
>=20
> Abstract:
>   This document outlines a set of issues with the use of long IPv6
>   extension header chains.  It considers their use in the context of
>   today's IPv6 Internet and potential interaction with forwarding
>   devices that require upper-layer headers.
>=20
>=20
>=20
>=20
> The IETF Secretariat
>=20

--
Do not meddle in the affairs of dragons, for you are crunchy and taste =
good with ketchup.=20




From albert.e.manfredi@boeing.com  Wed Feb 20 12:09: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 9A06621F8806 for ; Wed, 20 Feb 2013 12:09:21 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90ZCy9B4IQPi for ; Wed, 20 Feb 2013 12:09:21 -0800 (PST)
Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id E080221F8802 for ; Wed, 20 Feb 2013 12:09:20 -0800 (PST)
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 r1KK9ktZ025709 for ; Wed, 20 Feb 2013 12:09:46 -0800
Received: from XCH-PHX-306.sw.nos.boeing.com (xch-phx-306.sw.nos.boeing.com [137.136.239.30]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1KK9jgr025678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 20 Feb 2013 12:09:46 -0800
Received: from XCH-PHX-401.sw.nos.boeing.com (137.136.239.36) by XCH-PHX-306.sw.nos.boeing.com (137.136.239.30) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 20 Feb 2013 12:09:19 -0800
Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.138]) by XCH-PHX-401.sw.nos.boeing.com ([169.254.1.67]) with mapi id 14.02.0328.011; Wed, 20 Feb 2013 12:09:19 -0800
From: "Manfredi, Albert E" 
To: Randy Bush 
Subject: RE: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
Thread-Topic: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
Thread-Index: AQHOD1ClDaOLbKr+G0ei5xzTrUh0n5iDHRIAgAAHrQCAAAD3AIAAE0EAgAAAlgD///OJ4A==
Date: Wed, 20 Feb 2013 20:09:18 +0000
Message-ID: <021E64FECA7E5A4699562F4E667164818B37@XCH-PHX-503.sw.nos.boeing.com>
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu>  <5124B56C.1050103@kit.edu>  <5124C662.3070408@kit.edu> 
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: No
Cc: IPv6 maintenance 
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, 20 Feb 2013 20:09:21 -0000

> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Randy Bush

[ULAs]

> ahh.  so this is really just another end-run around the registry
> system.  instead, fix the registries.

Of course, but what's wrong with that? I too would be in favor of using ULA=
s for this in-vehicle purpose.

Bert


From markzzzsmith@yahoo.com.au  Wed Feb 20 11:25: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 3539521F883E for ; Wed, 20 Feb 2013 11:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.563
X-Spam-Level: 
X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.536,  BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqH+NqP6lNCZ for ; Wed, 20 Feb 2013 11:25:44 -0800 (PST)
Received: from nm9.bullet.mail.bf1.yahoo.com (nm9.bullet.mail.bf1.yahoo.com [98.139.212.168]) by ietfa.amsl.com (Postfix) with SMTP id F41A321F8833 for <6man@ietf.org>; Wed, 20 Feb 2013 11:25:40 -0800 (PST)
Received: from [98.139.212.153] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 19:25:40 -0000
Received: from [98.139.212.197] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 19:25:40 -0000
Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 19:25:40 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 423704.28559.bm@omp1006.mail.bf1.yahoo.com
Received: (qmail 56848 invoked by uid 60001); 20 Feb 2013 19:25:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361388340; bh=DdPo9/2arMhOcuh46QNwvf+kqcTQq5toHFj9cAW49DI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xqUulSNtViUfq9FCRYIqWd3Qsbuq2xEUwa73qJZD7cWwFrPU+71X18eYIyldO9FRmFFtF3/WS7So6e3pol/+DLcIi0UsqYNVEC9blqoEM0hx3uqX/JJ6+GLN1+XuH40D7dpp0XaEvDr+dSqtdJ7fLXDmJqFSxQwF3drr1gM5y0M=
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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=M3gnFqFi4UDs79nSauZaVhNKHK3w5nylkm624Lm/k7Rnwu8G+kPs2nqUzrPds3Q8Z3Wz8925rIyg5tlVHVxNn0cdCwM8OkDzbT++MB7XnnJ/Lq31zjP9kuxcJH+OWwgv8o7rSf8sPyxkUU1kaNzBP6xBB/FTVdaNs3kNp1LLby4=;
X-YMail-OSG: NE05HpgVM1ncqcROShbjoQITxnmLRVziuZtxkhHl6ZVv_Dj gCbrmCno3Rw68k2DV.qu5h4wGgcxRY0nWbbfKAxsWx7JumI0sppHbcHsN_.B fp_Lwp72GY7h4pi7EHjuPk4g51u3fBgiopKkPRrlpco834Ds_SNFNlORQEAd D3q4IpqQXJtB5Totn0d86RhmpSD_Jj8Jxhqi073_9jNFZblTd67hDgz78ygv A7Hb20hYLsF7mTcuZTD3s0l_W3EYy1ivM9V0QPmRpKcT22s9huu9GyMyDbPq 9rfZFkJaMTnNlRhyvekR7IJ_jsG132vH4P0nHt4lrKJINdwRygvecWgIy37B pRSQG7izLRbg2PD4vZ6aTt811_D1Y6JOHLBwIqcEgk_KoNF7IIJ0JazjcSrO TlSgTDQazsuvgXbcwNGk8GPGqjsN.QTI3mI4aNaW5nSBnSd9i73q.N6EjCJM zVHLQblE8solEbVZFVXCjRrKUGPIleltUpUI92P2Q4.taoaDeEUYYMCobr2. I3ERv39K2PF1yOClIYcltWg0-
Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 20 Feb 2013 11:25:40 PST
X-Rocket-MIMEInfo: 001.001, SGksCgpIZXJlIGlzIGEgbmV3IHZlcnNpb24gb2YgbXkgIlN0YXRlbGVzcyBORCIgZHJhZnQsIGFsdGhvdWdoIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIGl0IGhhcyBjaGFuZ2VkLgoKRHVyaW5nIGFuIG9mZi1saXN0IGRpc2N1c3Npb24gd2l0aCBSYXkgSHVudGVyLCBJIGNhbWUgcmVhbGlzZSB0aGF0IGNhbGxpbmcgaXQgIlN0YXRlbGVzcyBORCIgd2FzIHRvbyBnZW5lcmFsLCBhcyBpdCBpbXBsaWVkIHRoYXQgYWxsIG9mIHRoZSBORCBmdW5jdGlvbnMgd2VyZSBiZWluZyBtYWRlIHN0YXRlbGVzcy4gSSByZWEBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <20130220191455.12104.7080.idtracker@ietfa.amsl.com>
Message-ID: <1361388340.55779.YahooMailNeo@web142504.mail.bf1.yahoo.com>
Date: Wed, 20 Feb 2013 11:25:40 -0800 (PST)
From: Mark Smith 
Subject: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt
To: "6man@ietf.org" <6man@ietf.org>
In-Reply-To: <20130220191455.12104.7080.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 20 Feb 2013 13:06:13 -0800
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, 20 Feb 2013 19:25:45 -0000

Hi,=0A=0AHere is a new version of my "Stateless ND" draft, although a signi=
ficant amount of it has changed.=0A=0ADuring an off-list discussion with Ra=
y Hunter, I came realise that calling it "Stateless ND" was too general, as=
 it implied that all of the ND functions were being made stateless. I reali=
sed that what I was actually describing was making the discovery of the pre=
sence of neighbors (which I've called "Neighbor Presence Discovery") statel=
ess when a ND DoS Attack appeared to be occurring. Consequently I needed to=
 rewrite a fair bit of the text describing the problem.=0A=0AThe other chan=
ges are -=0A=0A=A0 =A0 o =A0don't ignore Neighbor Advertisements that may b=
e part of a=0A=A0 =A0 =A0 =A0previous stateful neighbor discovery transacti=
on=0A=A0=0A=A0 =A0 o =A0use a count down timer to allow outstanding SLNPD t=
ransactions to=0A=A0 =A0 =A0 =A0complete=0A=A0=0A=A0 =A0 o =A0mention issue=
s regarding trusting packet attributes=0A=0AMy thanks to the reviewers. Fur=
ther review welcome and appreciated.=0A=0ARegards,=0AMark.=0A=0A=0A----- Fo=
rwarded Message -----=0A> From: "internet-drafts@ietf.org" =0A> To: markzzzsmith@yahoo.com.au=0A> Cc: =0A> Sent: Thursday, 2=
1 February 2013 6:14 AM=0A> Subject: New Version Notification for draft-smi=
th-6man-mitigate-nd-cache-dos-slnd-06.txt=0A> =0A> =0A> A new version of I-=
D, draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt=0A> has been successf=
ully submitted by Mark Smith and posted to the=0A> IETF repository.=0A> =0A=
> Filename:=A0=A0=A0  draft-smith-6man-mitigate-nd-cache-dos-slnd=0A> Revis=
ion:=A0=A0=A0  06=0A> Title:=A0=A0=A0 =A0=A0=A0  Mitigating IPv6 Neighbor D=
iscovery DoS Attack Using Stateless =0A> Neighbor Presence Discovery=0A> Cr=
eation date:=A0=A0=A0  2013-02-20=0A> Group:=A0=A0=A0 =A0=A0=A0  Individual=
 Submission=0A> Number of pages: 14=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A> ht=
tp://www.ietf.org/internet-drafts/draft-smith-6man-mitigate-nd-cache-dos-sl=
nd-06.txt=0A> Status:=A0 =A0 =A0 =A0 =A0 =0A> http://datatracker.ietf.org/d=
oc/draft-smith-6man-mitigate-nd-cache-dos-slnd=0A> Htmlized:=A0 =A0 =A0 =A0=
 =0A> http://tools.ietf.org/html/draft-smith-6man-mitigate-nd-cache-dos-sln=
d-06=0A> Diff:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/rfcdiff?url2=
=3Ddraft-smith-6man-mitigate-nd-cache-dos-slnd-06=0A> =0A> Abstract:=0A> =
=A0  One of the functions of IPv6 Neighbor Discovery is to discover=0A> =A0=
  whether a specified neighbor is present.=A0 During the neighbor=0A> =A0  =
presence discovery process state is created.=A0 A node's capacity for=0A> =
=A0  this state can be intentionally exhausted to perform a denial of=0A> =
=A0  service attack, known as the "Neighbor Discovery DoS Attack".=A0 This=
=0A> =A0  memo proposes a stateless form of neighbor presence discovery to=
=0A> =A0  prevent this Neighbor Discovery 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 =A0 =A0 =A0 =A0 =
=0A> =A0 =0A> =0A> =0A> The IETF Secretariat=0A> 

From randy@psg.com  Wed Feb 20 13:20: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 4232521F8700 for ; Wed, 20 Feb 2013 13:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Level: 
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dq4lhNiF2t9 for ; Wed, 20 Feb 2013 13:20:36 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B098121F86F0 for ; Wed, 20 Feb 2013 13:20:36 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8H5e-0003LN-W3; Wed, 20 Feb 2013 21:20:35 +0000
Date: Thu, 21 Feb 2013 06:20:34 +0900
Message-ID: 
From: Randy Bush 
To: "Manfredi, Albert E" 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
In-Reply-To: <021E64FECA7E5A4699562F4E667164818B37@XCH-PHX-503.sw.nos.boeing.com>
References:  <512290E7.3070407@internet2.edu>  <51238CD8.6030805@gmail.com> <51249DDB.5020704@kit.edu>  <5124B56C.1050103@kit.edu>  <5124C662.3070408@kit.edu>  <021E64FECA7E5A4699562F4E667164818B37@XCH-PHX-503.sw.nos.boeing.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Cc: IPv6 maintenance 
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, 20 Feb 2013 21:20:37 -0000

> I too would be in favor of using ULAs for this in-vehicle purpose.

it would be very appropriate, as in vehicles, there is always a
probability of collision.

randy

From rogerj@gmail.com  Wed Feb 20 14:03: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 A80FF21E8053; Wed, 20 Feb 2013 14:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hgWx-DwRwA3; Wed, 20 Feb 2013 14:03:03 -0800 (PST)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id C62D121E8051; Wed, 20 Feb 2013 14:03:03 -0800 (PST)
Received: by mail-oa0-f41.google.com with SMTP id i10so8693637oag.14 for ; Wed, 20 Feb 2013 14:03:03 -0800 (PST)
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=lLRHxiFzL4QlUmbyEFiOpViTidVlYtWajJqDzze37UM=; b=DBb3vvIshXp/jh+vqol/m2STZ2qbtno46sbKmIYKaosif2aVjj5Jjlsl2XaWBzhKTA VikyCUjvsFPLRvUxbvTggw0SM7xB/o4Wh2jBUUE6G/BvhDY6a0EuKVyQ8dGXO1tBQb1G n/HwtG3jvI1AzzhfyO2LdJlE84/Hg9IoXWw08YbgWJOvJvwBIqJ6JD2MtitfRe8x7Ncx vgcI5aIaHSCBRWnDbvyLUZ8VlfmSPwpzEGZnKBOkoFKQJ6HHZDXP3/Y1RSeU/Hz2ihXX tSguf6WDFWrASmTCkX2Sq8QOX/EQtUgM1h+yLWWdJzBOV+cFjY90ysT2Xjnxgi8/0lj0 EaeQ==
MIME-Version: 1.0
X-Received: by 10.182.49.102 with SMTP id t6mr9794628obn.75.1361397783287; Wed, 20 Feb 2013 14:03:03 -0800 (PST)
Received: by 10.76.167.106 with HTTP; Wed, 20 Feb 2013 14:03:03 -0800 (PST)
In-Reply-To: 
References: 
Date: Wed, 20 Feb 2013 23:03:03 +0100
Message-ID: 
Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: sofiane Imadali 
Content-Type: text/plain; charset=ISO-8859-1
Cc: ipv6@ietf.org, 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, 20 Feb 2013 22:03:04 -0000

On Wed, Feb 20, 2013 at 6:14 PM, sofiane Imadali
 wrote:
> Hi,
> Thanks for your interest Roger, your question is very pertinent and I
> wanted to share it with the group (hope you don't mind bringing this
> offlist mail to the list).

no I don't mind, I'll comment on your answer inline



>      - Today in a closed operator domain, the vehicle (Mobile Router)
> can generate a ULA prefix for site-scoped communications. It is
> subject to collisions if used on a large number of vehicles (10^4 or
> more - RFC4193). In the vehicular context you're facing this
> limitation.
> For applications such as remote diagnosis, or other services
> (involving access to in-vehicle Machines), the solution we propose
> allows to create a predictable (deterministic manner) unique
> (collision-free) prefix, that in a closed loop (operator domain,
> manufacturer domain) allows you to determine which vehicle to access
> with which prefix: No DNS, No Prefix Delegation, No DHCPv6, nor any
> other additional artefact involved.
> Again, with this proposal, if you are an operator/manufacturer with a
> list of your vehicles fleet, you can determine a list of ULA prefixes
> to access each one of them: No additional protocol involved, no
> collisions.

I don't think it's  clear enough in the draft that we're talking about
closed circuit system, not communicated initiated from within the car
to outside, any outside device  including other cars. The case of
accessing the car's network from a service point of view are still
inside the car's domain.

Am I understanding this correct?


Another issue is the use of the term site, you could explain how you
are using that term.
I personal would consider any inner car communication to be within a
site, including when I connect my phone to the on-board media-system
to stream music or movie. Any communication toward outside the car are
out of the site.




> To sum up; in order not to trigger (too soon) the privacy concerns and
> be blocked by that, the primal use case (domain, site) would be a
> closed operator network, or car manufacturer in the manufacture
> (closed loop). This method allows us to set internal routing to access
> the in-vehicle devices, by a deterministic manner: VIN --> ULA prefix.
> No additional protocol is needed to do that. Any service provided by
> this devices (monitoring vehicle state for example) is a use case that
> applies to this addressing approach.

as said above, I understand those two draft to talk about inner car
communication, not communication toward _any_ device outside the car.
That include communication to other nearby cars, parking automate and
more.

Or to sum it up as I see it with regard to the privacy issue - the
issue is when the car, or someone in the car use an IP toward _any_
outside device that can be traced back to the VIN of any car
(vehicles).



> Thanks for reading and feedback;

no problem, good to get such a good explanation back :)



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger@jorgensen.no

From kauer@biplane.com.au  Wed Feb 20 23:12: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 A5C3A21F8DD2 for ; Wed, 20 Feb 2013 23:12:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level: 
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRlimv+DE3T4 for ; Wed, 20 Feb 2013 23:12:09 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 911EC21F8DCD for ; Wed, 20 Feb 2013 23:12:08 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AngDAAzIJVGWZX+7/2dsb2JhbAANOMBpAoEchVABErUNkyCORoQPA4gwmU6ILQ
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 21 Feb 2013 17:42:05 +1030
Message-ID: <1361430723.28479.391.camel@karl>
Subject: first hop routing - visible in user space?
From: Karl Auer 
To: IETF IPv6 , IPv6 Tech 
Date: Thu, 21 Feb 2013 18:12:03 +1100
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: Thu, 21 Feb 2013 07:12:10 -0000

Are the data structures involved in first hop routing for IPv6 (see RFC
2461, 4861 and 491 "conceptual models") visible in user space?That is,
is it possible to see what's going on as it happens? If so, how? Or is
it a black box?

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

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 brian.e.carpenter@gmail.com  Thu Feb 21 00:15: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 C470C21F8E0B for ; Thu, 21 Feb 2013 00:15:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.122
X-Spam-Level: 
X-Spam-Status: No, score=-101.122 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5iDZb3qCW-b for ; Thu, 21 Feb 2013 00:15:07 -0800 (PST)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0B50521F8DF6 for ; Thu, 21 Feb 2013 00:15:06 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id dr13so7286921wgb.14 for ; Thu, 21 Feb 2013 00:15:06 -0800 (PST)
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:subject:content-type:content-transfer-encoding; bh=o97sKQ1sAi5K2QpA2iGzF8aiEF2NBYE3v1WRl6h3aA8=; b=Sof5vvjbvQZ0Ipkc8hRZOyRYwwSiVmDHBwF4z+34f0KDhkl/yIji7HPcIZPpirZG8g m4vCx09kzks8o8uVXNg9bFNdHmhD7EzS0bM3ajPC4I7qyJSGm0nf5Wloct4zFNKl9E+f dtsKNaIWdDSoxIvLG7ETLuwrEYo/cTBpc2sXwsfl20w963zn0JCbS6CvgVd647KPYaS6 fkp9mCSUZsHAfdxMTmSiQ8PDfHeDLNLdm8TPQcCbXhoGXSva3sb0/VsHbwfGMByR8fA8 0uZUprN5PM2Mg19bU8Yb1GDYtCkQMr78yejH1OTx9lntLDj4dX1IP/wF/h6Jwq0DP+qj zJFQ==
X-Received: by 10.180.94.69 with SMTP id da5mr39577366wib.30.1361434506193; Thu, 21 Feb 2013 00:15:06 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-54.as13285.net. [2.102.216.54]) by mx.google.com with ESMTPS id du2sm35403701wib.0.2013.02.21.00.15.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 00:15:05 -0800 (PST)
Message-ID: <5125D793.70300@gmail.com>
Date: Thu, 21 Feb 2013 08:15:15 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man 
Subject: [Fwd: I-D Action: draft-carpenter-6man-ug-01.txt]
Content-Type: text/plain; charset=ISO-8859-1
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, 21 Feb 2013 08:15:07 -0000

Hi,

This version is very much clarified following the WG discussion, and
we hope that it reflects the Chairs' summary from yesterday. Please
read it as a new document; there are too many changes for the diffs
from the previous version to be useful.

   Brian + Sheng

-------- Original Message --------
Subject: I-D Action: draft-carpenter-6man-ug-01.txt
Date: Thu, 21 Feb 2013 00:07:19 -0800
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : The U and G bits in IPv6 Interface Identifiers
	Author(s)       : Brian Carpenter
                          Sheng Jiang
	Filename        : draft-carpenter-6man-ug-01.txt
	Pages           : 9
	Date            : 2013-02-21

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-carpenter-6man-ug

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-carpenter-6man-ug-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ug-01


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


-- 
Regards
   Brian Carpenter



From internet-drafts@ietf.org  Thu Feb 21 01:29: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 56CF121F8E46; Thu, 21 Feb 2013 01:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level: 
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pByQDsOux9b1; Thu, 21 Feb 2013 01:29:28 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AD721F8E4F; Thu, 21 Feb 2013 01:29:28 -0800 (PST)
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-udpzero-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130221092928.3612.32110.idtracker@ietfa.amsl.com>
Date: Thu, 21 Feb 2013 01:29:28 -0800
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, 21 Feb 2013 09:29:29 -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           : Applicability Statement for the use of IPv6 UDP Datagram=
s with Zero Checksums
	Author(s)       : Godred Fairhurst
                          Magnus Westerlund
	Filename        : draft-ietf-6man-udpzero-11.txt
	Pages           : 41
	Date            : 2013-02-21

Abstract:
   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 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 updates use of
   the UDP checksum with IPv6.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-udpzero-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpzero-11


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


From internet-drafts@ietf.org  Thu Feb 21 01:30: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 A17F221F8E4E; Thu, 21 Feb 2013 01:30:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.567
X-Spam-Level: 
X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qhu31Vgg-iPJ; Thu, 21 Feb 2013 01:30:49 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2055E21F8E5B; Thu, 21 Feb 2013 01:30:48 -0800 (PST)
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-udpchecksums-08.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130221093048.28129.58447.idtracker@ietfa.amsl.com>
Date: Thu, 21 Feb 2013 01:30:48 -0800
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, 21 Feb 2013 09:30:54 -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           : IPv6 and UDP Checksums for Tunneled Packets
	Author(s)       : Marshall Eubanks
                          AmericaFree.TV LLC
                          P.F. Chimento
                          Magnus Westerlund
	Filename        : draft-ietf-6man-udpchecksums-08.txt
	Pages           : 13
	Date            : 2013-02-21

Abstract:
   This document provides an update of the Internet Protocol version 6
   (IPv6) specification (RFC2460) to improve the performance in the use
   case where a tunnel protocol uses UDP with IPv6 to tunnel packets.
   The performance improvement is obtained by relaxing the IPv6 UDP
   checksum requirement for any suitable tunnel protocol where header
   information is protected on the "inner" packet being carried.  This
   relaxation removes the overhead associated with the computation of
   UDP checksums on IPv6 packets used to carry tunnel protocols.  The
   specification describes how the IPv6 UDP checksum requirement can be
   relaxed for the situation where the encapsulated packet itself
   contains a checksum.  The limitations and risks of this approach are
   described, and restrictions specified on the use of the method.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpchecksums-08


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


From magnus.westerlund@ericsson.com  Thu Feb 21 02:01: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 B898221F8DC3 for ; Thu, 21 Feb 2013 02:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.737
X-Spam-Level: 
X-Spam-Status: No, score=-105.737 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4AMgSkwaRBm for ; Thu, 21 Feb 2013 02:01:13 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A350321F8AB8 for ; Thu, 21 Feb 2013 02:01:12 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-1d-5125f0671300
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 01.20.32353.760F5215; Thu, 21 Feb 2013 11:01:11 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 21 Feb 2013 11:01:11 +0100
Message-ID: <5125F066.2050207@ericsson.com>
Date: Thu, 21 Feb 2013 11:01:10 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "ipv6@ietf.org" 
Subject: Re: I-D Action: draft-ietf-6man-udpzero-11.txt
References: <20130221092928.3612.32110.idtracker@ietfa.amsl.com>
In-Reply-To: <20130221092928.3612.32110.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+JvjW76B9VAg52NxhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvOZUQXfxCvaj2xjamD8LdTFyMEhIWAiMXOBRhcjJ5ApJnHh 3nq2LkYuDiGBk4wSb3Zuh3KWM0osP/qQFaSKV0BbYuvOe8wgzSwCqhJfnomDhNkELCRu/mhk A7FFBYIlNhxcxQRRLihxcuYTFhBbREBZYkb3ObAaYQFzifWv3oLZQgIOEu/vfwezOQUcJabf nsMKcZu4xJo3HCBhZgE9iSlXWxghbHmJ5q2zmSFatSUamjpYJzAKzkKybRaSlllIWhYwMq9i ZM9NzMxJLzffxAgMvINbfhvsYNx0X+wQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjGksi3m+ppz0fNXHJN+zf8bPI04fzj3M3h59dLuJqInRxrVapmEPPN6aaHxbKciQ aLD4q54hw2QrqWtSDiwqryb+EtJRbY4rnJkZceK4b5zHhM2vjlj2OMiFbTw1v7Oki0uCmf9g xG/OZR6W+09eZUjZ0MN37sPUr/pLI41if/Nq+FzOvv9PXImlOCPRUIu5qDgRAHMp6SgKAgAA
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, 21 Feb 2013 10:01:13 -0000

WG,

This version of the document has gotten some changes due to IESG
discussion. The changes that has been applied of significance are:

- Clarification on the relation to regular UDP and UDP-Lite and when
zero UDP makes sense. (Section 2.4 + some other places)

- Discussion of what a protocol designer needs to consider when dealing
with router fast path implementations.

- A security issue with the previous bullet.

- Various tweaking of some formulations.

I recommend that anyone interest to review the new version.

Cheers

Magnus

On 2013-02-21 10:29, internet-drafts@ietf.org wrote:
> 
> 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           : Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums
> 	Author(s)       : Godred Fairhurst
>                           Magnus Westerlund
> 	Filename        : draft-ietf-6man-udpzero-11.txt
> 	Pages           : 41
> 	Date            : 2013-02-21
> 
> Abstract:
>    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 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 updates use of
>    the UDP checksum with IPv6.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6man-udpzero-11
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-udpzero-11
> 
> 
> 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
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Thu Feb 21 02:07: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 60F2521F8E33 for ; Thu, 21 Feb 2013 02:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.874
X-Spam-Level: 
X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRQ42SEPJElZ for ; Thu, 21 Feb 2013 02:07:45 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A39921F8DF0 for ; Thu, 21 Feb 2013 02:07:44 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-b9-5125f1efaa4a
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F2.D6.10459.FE1F5215; Thu, 21 Feb 2013 11:07:43 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 21 Feb 2013 11:07:43 +0100
Message-ID: <5125F1EE.7050804@ericsson.com>
Date: Thu, 21 Feb 2013 11:07:42 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-ietf-6man-udpchecksums-08.txt
References: <20130221093048.28129.58447.idtracker@ietfa.amsl.com>
In-Reply-To: <20130221093048.28129.58447.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvje77j6qBBp87dCxenn3P5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG0HQwvuilXMvz6TrYHxqWAXIyeHhICJxLqvD5kgbDGJC/fW s3UxcnEICZxklGhecRfKWc4osebBGjaQKl4BbYmj56+yg9gsAqoS+75cButmE7CQuPmjEaxG VCBYYsPBVUwQ9YISJ2c+YQGxRYDs7Q9+ANkcHMICNhL39qaChIUEHCUebYJo5RRwkpj74B1Y iYSAuMSaNxwgYWYBPYkpV1sYIWx5ieats5khWrUlGpo6WCcwCs5CsmwWkpZZSFoWMDKvYmTP TczMSS833MQIDL2DW37r7mA8dU7kEKM0B4uSOG+Y64UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYw28l0LPstXvL6xyKr8QdGJztRTtVYyU+7/Xlh6bZdFbpnXNfMlP9VWHnKZulYm6saO eFbVxnn7tK24jTdz7Bef0DzrvwN75dqe+xWxoQ+3VN5lWi353+uJSVju82mGIq8aZ+Z4r5e0 3xsVqHLY/eDjl2VNy6fppBiefGJ7WK1pvYPwak39jQlKLMUZiYZazEXFiQAqqE8sCwIAAA==
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, 21 Feb 2013 10:07:49 -0000

WG,

This document has less changes than UDP zero document. However, please
review also these changes.

The largest change is the expansion of the security consideration.

Cheers

Magnus

On 2013-02-21 10:30, internet-drafts@ietf.org wrote:
> 
> 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           : IPv6 and UDP Checksums for Tunneled Packets
> 	Author(s)       : Marshall Eubanks
>                           AmericaFree.TV LLC
>                           P.F. Chimento
>                           Magnus Westerlund
> 	Filename        : draft-ietf-6man-udpchecksums-08.txt
> 	Pages           : 13
> 	Date            : 2013-02-21
> 
> Abstract:
>    This document provides an update of the Internet Protocol version 6
>    (IPv6) specification (RFC2460) to improve the performance in the use
>    case where a tunnel protocol uses UDP with IPv6 to tunnel packets.
>    The performance improvement is obtained by relaxing the IPv6 UDP
>    checksum requirement for any suitable tunnel protocol where header
>    information is protected on the "inner" packet being carried.  This
>    relaxation removes the overhead associated with the computation of
>    UDP checksums on IPv6 packets used to carry tunnel protocols.  The
>    specification describes how the IPv6 UDP checksum requirement can be
>    relaxed for the situation where the encapsulated packet itself
>    contains a checksum.  The limitations and risks of this approach are
>    described, and restrictions specified on the use of the method.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-08
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-udpchecksums-08
> 
> 
> 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
> --------------------------------------------------------------------
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From v6ops@globis.net  Thu Feb 21 02:12: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 58EB321F8E3E; Thu, 21 Feb 2013 02:12:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.876
X-Spam-Level: 
X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8btSzDxSmKUQ; Thu, 21 Feb 2013 02:12:33 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 98EC521F8E45; Thu, 21 Feb 2013 02:12:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 38944870099; Thu, 21 Feb 2013 11:02:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
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 cLQ+4MeiOr3d; Thu, 21 Feb 2013 11:01:42 +0100 (CET)
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 58B2087005B; Thu, 21 Feb 2013 11:01:42 +0100 (CET)
Message-ID: <5125F080.90100@globis.net>
Date: Thu, 21 Feb 2013 11:01:36 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.7 (Macintosh/20130119)
MIME-Version: 1.0
To: sofiane Imadali 
Subject: Re: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: ipv6@ietf.org, 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: Thu, 21 Feb 2013 10:12:34 -0000

A similar issue is likely to emerge with other mobile device - mobile
device communication,where there are a large number of mobile devices
circulating globally, but relatively few of them are present in any one
given area at any given time e.g. wearable computing, medical monitors,
RFID tags attached to small articles in transit, pet ID chips that warn
the owner if they stray......

IMHO it is a bad idea to define any sort of static mapping between L8
identifiers and L3/L2.

64 bits of IID are simply not going to be enough to encode adequate
semantics for all envisioned mobile applications.

SLAAC (using MAC as the universal seed) is almost certainly going to be
less likely to suffer collisions than any number of competing
industry-specific standards that overload the IID space.

IMHVO The industry should generate prefixes/addresses based on existing
standards, and then perform any dynamic VIN / Pet ID / L8 ID mapping via
some (industry-specific) protocol to identify the specific vehicle/ pet/
shirt as appropriate. There is perhaps a role here for the IETF to
assist in defining a L3<->L8 mapping protocol, especially for links with
rapidly changing members, and which includes an industry identifier and
an industry specific portion.

regards,
RayH

sofiane Imadali wrote:
> Hi,
> Thanks for your interest Roger, your question is very pertinent and I
> wanted to share it with the group (hope you don't mind bringing this
> offlist mail to the list).
>
> Indeed, one needs to understand the context before understanding the
> possible uses of the method.
>
> First, a bit of state of the art that couldn't appear in the drafts.
> VIN is not a private information. It is meant to be public. I gave a
> list of ISO specifications that say exactly How a VIN is built, Where
> it should appear, How to reverse engineer it. In a nutshell, the VIN
> is alphanumeric, it appears on your wind shield, and you can break it
> down to 3 pieces: the manufacturer ID, the vehicle's description, and
> the vehicle ID.
>
>      - What networking questions/perspectives should these VIN-related
> data trigger  ?
>      - Today in a closed operator domain, the vehicle (Mobile Router)
> can generate a ULA prefix for site-scoped communications. It is
> subject to collisions if used on a large number of vehicles (10^4 or
> more - RFC4193). In the vehicular context you're facing this
> limitation.
> For applications such as remote diagnosis, or other services
> (involving access to in-vehicle Machines), the solution we propose
> allows to create a predictable (deterministic manner) unique
> (collision-free) prefix, that in a closed loop (operator domain,
> manufacturer domain) allows you to determine which vehicle to access
> with which prefix: No DNS, No Prefix Delegation, No DHCPv6, nor any
> other additional artefact involved.
> Again, with this proposal, if you are an operator/manufacturer with a
> list of your vehicles fleet, you can determine a list of ULA prefixes
> to access each one of them: No additional protocol involved, no
> collisions.
>
>      - What applications can be enabled by the use of this kind of
> VIN-based Prefixes and IDs ?
>      - This also answers the question of regarding those 2 proposals
> only from a privacy-concerns standpoint. Vendor web-based apps where
> you give a VIN code and  returns the history of a vehicle already
> exists. When selling your car, a buyer can look up your VIN in a
> database and get a history of car accidents, repairs ...etc all
> related to your vehicle. This is no science-fiction, it has already
> been used in the US for quite a while. Here is on example googling the
> keywords (second hand car VIN history):
> http://www.edmunds.com/car-buying/vin-check.html
>
>      - About the privacy concerns.
>      - I am no expert in the field of privacy. I do understand the
> concerns though, and this is why I chose to trigger them in the draft
> and in my research work before it is evoked in the mailling list. My
> humble opinion about the subject is that we should not mistake VIN for
> a MAC. Not compare them, and not apply blindly the concepts of MAC
> randomization for VIN-based IIDs/Prefixes. The compromise of
> (Uniqueness/randomization And Privacy) that is studied and
> standardized in RFC 4941 for IID, should not directly apply to VIN
> with no regard to the nature of the object we are using. Please have a
> look at: http://en.wikipedia.org/wiki/VIN_Etching, which should inform
> you more about another possible application of VIN (in general, not
> just networking) which is car theft prevention, to understand why
> *your VIN is a public good and not a private property that you buy
> with your car*.
>
> To sum up; in order not to trigger (too soon) the privacy concerns and
> be blocked by that, the primal use case (domain, site) would be a
> closed operator network, or car manufacturer in the manufacture
> (closed loop). This method allows us to set internal routing to access
> the in-vehicle devices, by a deterministic manner: VIN --> ULA prefix.
> No additional protocol is needed to do that. Any service provided by
> this devices (monitoring vehicle state for example) is a use case that
> applies to this addressing approach.
>
> Thanks for reading and feedback;
> Cheers
> Sofiane
>
>
>
>
> On Mon, Feb 18, 2013 at 11:11 PM, Roger Jørgensen  wrote:
>> Hi,
>>
>> What I wonder about is why we need this, what are the usecases and the
>> _intention_ behind these two draft from you?
>>
>> just... why?
>>
>>
>> The reason I ask is that I try to understand it, and see if the
>> privacy option is a real concern in _your_ context or not.
>>
>>
>>
>> --- Roger J ---
>>
>> On Mon, Feb 18, 2013 at 7:49 PM, sofiane Imadali
>>  wrote:
>>> Hello 6MAN folks,
>>>
>>> I would like to announce, on behalf of the co-authors, the submission
>>> of 2 drafts relating to VIN-based IPv6 addressing.
>>> VIN stands for Vehicle Identification Number, and it is specifically
>>> used in a context of IPv6 vehicular communications. These proposals
>>> aim at providing discussion about a new mapping/conversion method from
>>> VIN to ULA prefixes (guaranteed unique) and Interface Identifiers.
>>>
>>> Please find the above mentioned documents at:
>>> 1) Vehicle Identification Number-Based IPv6 Interface Identifier
>>> (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
>>> 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
>>> Addresses (VULA), at:
>>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00
>>>
>>> Your comments are welcome,
>>>
>>> Cheers,
>>> Sofiane.
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>> --
>>
>> 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 Feb 21 04:55: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 7BBFF21F8CA5 for ; Thu, 21 Feb 2013 04:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.75
X-Spam-Level: 
X-Spam-Status: No, score=-99.75 tagged_above=-999 required=5 tests=[AWL=-0.829, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCfKKeF4Am1L for ; Thu, 21 Feb 2013 04:55:29 -0800 (PST)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9412321F87A6 for ; Thu, 21 Feb 2013 04:55:29 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id s43so7713316wey.35 for ; Thu, 21 Feb 2013 04:55:28 -0800 (PST)
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=BXNQaVzgGuximSRSNI16BjQotRMaaomPxPwLbaQH9/Q=; b=gBsSqD3a8U+PAa6aM/o2//aX/pTbN5GaG/Qw773ubzKMfrs4CFX2+lpdHxHypHc3OU T7x+FYvcFSOuUnUlAUwTv4EcPnc1bAxITdJsByvOjso17V+GeSOXkQeNAC83sQzAyoK6 OQ5Ln3NzlKMFy7Qgd8ySb+0kXRyd1ZCnJj+fsiH5+GJW3gHCU+Wb15MXB8JAoMFVkCCG ZOJIT2ZTsUX2QCayqozbz1NlrKEBxenEwJ3+VYArDHPFSy5XgG2CTwembHKIflJD0gaJ 4JtOAzV9QFPFlPrxFwo9OmNT0uGQuwtVF8GtPYZVA1PnjUb9zcy5YYaQT8tM4En0Oxbz KfRg==
X-Received: by 10.180.109.131 with SMTP id hs3mr34398469wib.18.1361451328384;  Thu, 21 Feb 2013 04:55:28 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-54.as13285.net. [2.102.216.54]) by mx.google.com with ESMTPS id fv2sm36672660wib.6.2013.02.21.04.55.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 04:55:27 -0800 (PST)
Message-ID: <5126194A.6030200@gmail.com>
Date: Thu, 21 Feb 2013 12:55:38 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Warren Kumari 
Subject: Re: Fwd: New Version Notification for draft-wkumari-long-headers-00.txt
References: <20130204150759.12582.52282.idtracker@ietfa.amsl.com> <0D8BB2F4-F65F-469F-ADA6-07FCDC754D9C@kumari.net>
In-Reply-To: <0D8BB2F4-F65F-469F-ADA6-07FCDC754D9C@kumari.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 maintenance 
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, 21 Feb 2013 12:55:35 -0000

Hi,

I suggest that the draft should focus only on describing the operational
issues with as much precision as possible. It's only the last paragraph
of section 3 and the brief section 4 that will be controversial, and
as always it's best to start with the facts, all the facts, before
reaching conclusions.

A missing topic is load balancers, where the issue is of considerable
importance. There's some discussion of the extension header issue
in draft-ietf-intarea-flow-label-balancing.

I'm surprised there's no reference to draft-ietf-6man-oversized-header-ch=
ain.

Regards
   Brian

On 20/02/2013 19:44, Warren Kumari wrote:
> Hello all,
>=20
> We wanted to make you aware of a document we submitted a while back --u=
nfortunately *someone*[0] forgot to put -6man- somewhere in the title.
>=20
> This document explains issues that *operators* have with "long header c=
hains" and devices that need to see the L4 information.
>=20
> We understand that this is likely to be a controversial document, and w=
ill spark lively discussion[1].=20
>=20
> W
>=20
> [0]: Ok, it was me=E2=80=A6
> [1]: AKA Nomex underwear time.
>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-wkumari-long-headers-00.tx=
t
>> Date: February 4, 2013 10:07:59 AM EST
>> To: warren@kumari.net
>> Cc: internet-drafts@bonica.org, jjaeggli@zynga.com
>>
>>
>> A new version of I-D, draft-wkumari-long-headers-00.txt
>> has been successfully submitted by Warren Kumari and posted to the
>> IETF repository.
>>
>> Filename:	 draft-wkumari-long-headers
>> Revision:	 00
>> Title:		 Operational Issues Associated With Long IPv6 Extension Header=
 Chains
>> Creation date:	 2013-02-04
>> WG ID:		 Individual Submission
>> Number of pages: 9
>> URL:             http://www.ietf.org/internet-drafts/draft-wkumari-lon=
g-headers-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-wkumari-long-he=
aders
>> Htmlized:        http://tools.ietf.org/html/draft-wkumari-long-headers=
-00
>>
>>
>> Abstract:
>>   This document outlines a set of issues with the use of long IPv6
>>   extension header chains.  It considers their use in the context of
>>   today's IPv6 Internet and potential interaction with forwarding
>>   devices that require upper-layer headers.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>=20
> --
> Do not meddle in the affairs of dragons, for you are crunchy and taste =
good with ketchup.=20
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From warren@kumari.net  Thu Feb 21 07:30: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 AA30F21F8EAA for ; Thu, 21 Feb 2013 07:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.607
X-Spam-Level: 
X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtIczeAcZKTC for ; Thu, 21 Feb 2013 07:30:54 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F01D21F8E9E for ; Thu, 21 Feb 2013 07:30:52 -0800 (PST)
Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 9DB821B41867; Thu, 21 Feb 2013 10:30:51 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: New Version Notification for draft-wkumari-long-headers-00.txt
From: Warren Kumari 
In-Reply-To: <5126194A.6030200@gmail.com>
Date: Thu, 21 Feb 2013 10:30:50 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4FCC31D2-031E-4A92-80D6-AA110317849D@kumari.net>
References: <20130204150759.12582.52282.idtracker@ietfa.amsl.com> <0D8BB2F4-F65F-469F-ADA6-07FCDC754D9C@kumari.net> <5126194A.6030200@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1499)
Cc: IPv6 maintenance 
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, 21 Feb 2013 15:30:56 -0000

On Feb 21, 2013, at 7:55 AM, Brian E Carpenter =
 wrote:

> Hi,
>=20
> I suggest that the draft should focus only on describing the =
operational
> issues with as much precision as possible. It's only the last =
paragraph
> of section 3 and the brief section 4 that will be controversial, and
> as always it's best to start with the facts, all the facts, before
> reaching conclusions.
>=20

Yup. The conclusion isn't (yet!) "Long headers are hard, let's just =
deprecate them" -- the draft is intended to explain the problems, start =
discussions and make folk aware of the fact that a number of folk are =
dropping these sorts of packets.=20

The last parts of the draft are there for a few reasons:
1: Drafts that simply say "Here is an issue" without bothering to =
propose any sort of solution always feels (to me at least) as though the =
authors haven't bothered and are expecting someone else to solve all =
their issues for them=85.

2: This is a strawman proposal -- it is (IMO) easier to discuss the =
issues if there is a proposal. This may not be *the* solution, but at =
the moment it is at least something we can use for discussions / poke =
holes in. We did discuss at length what all solutions there could be, =
and they went something like this:

a: the network should never have to look at L4 info / look past the IP / =
HbH bits --- unfortunately this misses real world requirements (which we =
reed to capture in the draft)

b: hardware vendors should simply solve the architectural / performance =
issues  -- this required too much pixie dust. It also doesn't solve the =
issue of already deployed boxes.

c: L4 info could be copied to *just* after the IP header (and then some =
handwaving to make sure that the L4 info here matches the L4 info in the =
upper-layer protocol) -- this has many issues..

d: what we suggested / formally deprecating all headers=20

e: hopefully the IETF / 6MAN will point at some really obvious solution =
and we can breath a sign of relief and abandon the draft.


3: Having something slightly controversial sparks discussion and helps =
to get folk involved :-P


> A missing topic is load balancers, where the issue is of considerable
> importance. There's some discussion of the extension header issue
> in draft-ietf-intarea-flow-label-balancing.
>=20
> I'm surprised there's no reference to =
draft-ietf-6man-oversized-header-chain.

Yup, both of those were an oversight, for which I apologize -- =
oversized-header-chain was referenced, but got eaten during an 'svn =
merge' that wen't horribly wrong (which also ate the -6man- in the =
title). Not referencing / discussing =
draft-ietf-intarea-flow-label-balancing was simply a stupid omission.=20
I'm sure y'all know how it goes -- you start writing a draft with much =
energy, then $DayJob gets in the way=85 Suddenly you realize that the =
next meeting is fast approaching, and you scurry to get everyones text =
in. For some reason this always happens during some other crisis and you =
forget something important=85

W

>=20
> Regards
>   Brian
>=20
> On 20/02/2013 19:44, Warren Kumari wrote:
>> Hello all,
>>=20
>> We wanted to make you aware of a document we submitted a while back =
--unfortunately *someone*[0] forgot to put -6man- somewhere in the =
title.
>>=20
>> This document explains issues that *operators* have with "long header =
chains" and devices that need to see the L4 information.
>>=20
>> We understand that this is likely to be a controversial document, and =
will spark lively discussion[1].=20
>>=20
>> W
>>=20
>> [0]: Ok, it was me=85
>> [1]: AKA Nomex underwear time.
>>=20
>> Begin forwarded message:
>>=20
>>> From: internet-drafts@ietf.org
>>> Subject: New Version Notification for =
draft-wkumari-long-headers-00.txt
>>> Date: February 4, 2013 10:07:59 AM EST
>>> To: warren@kumari.net
>>> Cc: internet-drafts@bonica.org, jjaeggli@zynga.com
>>>=20
>>>=20
>>> A new version of I-D, draft-wkumari-long-headers-00.txt
>>> has been successfully submitted by Warren Kumari and posted to the
>>> IETF repository.
>>>=20
>>> Filename:	 draft-wkumari-long-headers
>>> Revision:	 00
>>> Title:		 Operational Issues Associated With Long IPv6 =
Extension Header Chains
>>> Creation date:	 2013-02-04
>>> WG ID:		 Individual Submission
>>> Number of pages: 9
>>> URL:             =
http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-00.txt
>>> Status:          =
http://datatracker.ietf.org/doc/draft-wkumari-long-headers
>>> Htmlized:        =
http://tools.ietf.org/html/draft-wkumari-long-headers-00
>>>=20
>>>=20
>>> Abstract:
>>>  This document outlines a set of issues with the use of long IPv6
>>>  extension header chains.  It considers their use in the context of
>>>  today's IPv6 Internet and potential interaction with forwarding
>>>  devices that require upper-layer headers.
>>>=20
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat
>>>=20
>>=20
>> --
>> Do not meddle in the affairs of dragons, for you are crunchy and =
taste good with ketchup.=20
>>=20
>>=20
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>=20
>=20

--
"Real children don't go hoppity-skip unless they are on drugs."

    -- Susan, the ultimate sensible governess (Terry Pratchett, =
Hogfather)





From brian.e.carpenter@gmail.com  Thu Feb 21 09:07: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 8D49421F8EDE for ; Thu, 21 Feb 2013 09:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.117
X-Spam-Level: 
X-Spam-Status: No, score=-101.117 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtjT3+q6BIOr for ; Thu, 21 Feb 2013 09:07:19 -0800 (PST)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id E025421F8E7F for ; Thu, 21 Feb 2013 09:07:18 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id hn17so7801146wib.16 for ; Thu, 21 Feb 2013 09:07:18 -0800 (PST)
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=uhRhE+Pfog9jnWEzFXxmwCaxSTACQUYoyvb08cHnmPk=; b=qJgHEde4lASM6swGGwvjWZMOXoz7UNQDTwYeK/MdCbZg5J8DK0Gun9aPb8e+pE6gii 13Hzf4rQ8XacINed+ozTFmr+DttMoRbNAgooUY4j1OjRoZp7t69rc1CS/I6hUiZKLySa 5KfMqNkGmAaW+dMeuUykZtKiYAWW1nzJ/8G2ObuBsgbU61j8NF+ohzDq0BbJR1CTGTFo QMFNBWFSoR4RUlcPzU2B24P1WSqLusE4TzpoN0wTSXps5d8hqknO/RJNu3WAXXQSJuFu x8cNZlfrhiXER/W5wGlIRSpUkIQXWQBeMRl4erG4Cjd2FYCp3OZYZyTZQfEfxpdfagoC Q6HQ==
X-Received: by 10.180.91.106 with SMTP id cd10mr24498015wib.6.1361466438028; Thu, 21 Feb 2013 09:07:18 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-54.as13285.net. [2.102.216.54]) by mx.google.com with ESMTPS id du2sm38109760wib.0.2013.02.21.09.07.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 09:07:16 -0800 (PST)
Message-ID: <5126544D.40503@gmail.com>
Date: Thu, 21 Feb 2013 17:07:25 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Warren Kumari 
Subject: Re: New Version Notification for draft-wkumari-long-headers-00.txt
References: <20130204150759.12582.52282.idtracker@ietfa.amsl.com> <0D8BB2F4-F65F-469F-ADA6-07FCDC754D9C@kumari.net> <5126194A.6030200@gmail.com> <4FCC31D2-031E-4A92-80D6-AA110317849D@kumari.net>
In-Reply-To: <4FCC31D2-031E-4A92-80D6-AA110317849D@kumari.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 maintenance 
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, 21 Feb 2013 17:07:19 -0000

On 21/02/2013 15:30, Warren Kumari wrote:
> On Feb 21, 2013, at 7:55 AM, Brian E Carpenter  wrote:
>=20
>> Hi,
>>
>> I suggest that the draft should focus only on describing the operation=
al
>> issues with as much precision as possible. It's only the last paragrap=
h
>> of section 3 and the brief section 4 that will be controversial, and
>> as always it's best to start with the facts, all the facts, before
>> reaching conclusions.
>>
>=20
> Yup. The conclusion isn't (yet!) "Long headers are hard, let's just dep=
recate them" -- the draft is intended to explain the problems, start disc=
ussions and make folk aware of the fact that a number of folk are droppin=
g these sorts of packets.=20
>=20
> The last parts of the draft are there for a few reasons:
> 1: Drafts that simply say "Here is an issue" without bothering to propo=
se any sort of solution always feels (to me at least) as though the autho=
rs haven't bothered and are expecting someone else to solve all their iss=
ues for them=E2=80=A6.

Sure, but a proposal that removes a major part of the design of IPv6
simply can't fly right out of the box (excuse my metaphor).

=2E..
> b: hardware vendors should simply solve the architectural / performance=
 issues  -- this required too much pixie dust. It also doesn't solve the =
issue of already deployed boxes.

I suspect that there are solutions that don't need pixie dust, but which
do require product redesign, and the IETF often enough calls for product
redesign. Anyway... I do think that discussion is premature.

   Brian


From v6ops@globis.net  Thu Feb 21 10:05: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 E439521F8F54 for ; Thu, 21 Feb 2013 10:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.362
X-Spam-Level: 
X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=0.237,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D9QXBVFUUed for ; Thu, 21 Feb 2013 10:05:12 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id ED93021F8F48 for ; Thu, 21 Feb 2013 10:05:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DBFFE870126; Thu, 21 Feb 2013 18:59:54 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
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 ldNvnYsKcZD2; Thu, 21 Feb 2013 18:59:25 +0100 (CET)
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 9C3BB870125; Thu, 21 Feb 2013 18:59:25 +0100 (CET)
Message-ID: <51266077.10102@globis.net>
Date: Thu, 21 Feb 2013 18:59:19 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.7 (Macintosh/20130119)
MIME-Version: 1.0
To: Brian E Carpenter 
Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-01.txt]
References: <5125D793.70300@gmail.com>
In-Reply-To: <5125D793.70300@gmail.com>
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: Thu, 21 Feb 2013 18:05:13 -0000

I have read this draft, and it looks good. I support it.

Brian E Carpenter wrote:
> Hi,
>
> This version is very much clarified following the WG discussion, and
> we hope that it reflects the Chairs' summary from yesterday. Please
> read it as a new document; there are too many changes for the diffs
> from the previous version to be useful.
>
>    Brian + Sheng
>
> -------- Original Message --------
> Subject: I-D Action: draft-carpenter-6man-ug-01.txt
> Date: Thu, 21 Feb 2013 00:07:19 -0800
> From: internet-drafts@ietf.org
> Reply-To: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title           : The U and G bits in IPv6 Interface Identifiers
> 	Author(s)       : Brian Carpenter
>                           Sheng Jiang
> 	Filename        : draft-carpenter-6man-ug-01.txt
> 	Pages           : 9
> 	Date            : 2013-02-21
>
> 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-carpenter-6man-ug
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-carpenter-6man-ug-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ug-01
>
>
> 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 markzzzsmith@yahoo.com.au  Thu Feb 21 10:57: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 5367E21F8F20 for ; Thu, 21 Feb 2013 10:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.322
X-Spam-Level: 
X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=0.177,  BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF4hB0P3wfAB for ; Thu, 21 Feb 2013 10:57:43 -0800 (PST)
Received: from nm35.bullet.mail.bf1.yahoo.com (nm35.bullet.mail.bf1.yahoo.com [72.30.238.197]) by ietfa.amsl.com (Postfix) with ESMTP id 8076E21F8EC9 for ; Thu, 21 Feb 2013 10:57:43 -0800 (PST)
Received: from [98.139.214.32] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 18:57:42 -0000
Received: from [98.139.212.203] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 18:57:42 -0000
Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 18:57:42 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 187345.9596.bm@omp1012.mail.bf1.yahoo.com
Received: (qmail 82246 invoked by uid 60001); 21 Feb 2013 18:57:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361473061; bh=EytHHqR/tzZXZKvL4PKuPNwSFSu33IQZKn/+mFwYGgI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B4xTwhnhIeaQ0n3URwsTAnQfWYc0sKjAcpGRiXKgZTS3eWNfBJQp3BJsYjmttRQMKG3FIbTgba1HHVziyFPM1WkMWewFKEL7tpZ+azNpsjmYxbRGg4cR2C8Eh0JXUk6lFJR2Itv2kSocCwol79DO3NcJLzk1QA8GtFota9AO4TI=
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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=exxkCyZ6n0Z2uHnG4xgwuGBlhq8qezYr/qxJaKQyQEFwqKpAHlotKQ7QwJ1QWsXqvUmsVkTYheZ8LkaLS9ZfaCd/q4SyVWaMF3VsRjr6QnchsAfHGi8qsLs9sb9+T3T28pE2WbDxX11Z0gKkqKLimIGF89EiW2L4osv2tinNg+s=;
X-YMail-OSG: 1pBckVYVM1lXrlijSDlcUE2rnb7z3K8kMnSHP1qJXPpRy6W dgriwqsZFnkToLtGPNBtNrCnHQCRI32oZOnAbCczUkZ30qErv8mnmMCCZuuS jGO4IkPZdIlOiqfI9z2xu9hmexWBs8_eEF47CxkDWTkJ0lYsL7dwtWRrbUbB .GHSr8.WIna5sWgYGtoMRRLrrzRhWNQN1T1H6DhbrJM8R4z_IvqtlWIoYS7. XvrAOqdZxYOPibiz81ZEYre6fYQStXBwbBTEuN7RBV3kpb2UsZ_ERpT8_8Nf iIdc0uzdZId8CntfsZXWXVdDtF3xbgv9VIQC.fAJOR22fvoV6yGZRfVwZW70 rW8LCMSwuncEqN0sZ2XSra71Lx5Y69ZmNCX41wltDZMZ4IqlPNn3agl8_SNh DTq860.1fm0i0rTkmS88o4wI7fsUK4PpR2H5I0HpEBZNowtzFzoz3G.aUfRy QZJdOvQIWQ3xCKGoijTa86IHDH0gHvwyySBUtCERW4h0p5TOYa.fc4oKCcEZ W1CPL_kPiHe9ECeD1Btd6
Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Thu, 21 Feb 2013 10:57:41 PST
X-Rocket-MIMEInfo: 001.001, SGkgS2FybCwKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogS2FybCBBdWVyIDxrYXVlckBiaXBsYW5lLmNvbS5hdT4KPiBUbzogSUVURiBJUHY2IDxpcHY2QGlldGYub3JnPjsgSVB2NiBUZWNoIDxpcHY2dGVjaEBsaXN0cy5pcHY2Lm9yZy5hdT4KPiBDYzogCj4gU2VudDogVGh1cnNkYXksIDIxIEZlYnJ1YXJ5IDIwMTMgNjoxMiBQTQo.IFN1YmplY3Q6IGZpcnN0IGhvcCByb3V0aW5nIC0gdmlzaWJsZSBpbiB1c2VyIHNwYWNlPwo.IAo.IEFyZSB0aGUgZGF0YSBzdHJ1Y3R1cmVzIGludm8BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <1361430723.28479.391.camel@karl>
Message-ID: <1361473061.79515.YahooMailNeo@web142504.mail.bf1.yahoo.com>
Date: Thu, 21 Feb 2013 10:57:41 -0800 (PST)
From: Mark Smith 
Subject: Re: first hop routing - visible in user space?
To: Karl Auer , IETF IPv6 , IPv6 Tech 
In-Reply-To: <1361430723.28479.391.camel@karl>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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, 21 Feb 2013 18:57:44 -0000

Hi Karl,=0A=0A=0A----- Original Message -----=0A> From: Karl Auer =0A> To: IETF IPv6 ; IPv6 Tech =0A> Cc: =0A> Sent: Thursday, 21 February 2013 6:12 PM=0A> Subj=
ect: first hop routing - visible in user space?=0A> =0A> Are the data struc=
tures involved in first hop routing for IPv6 (see RFC=0A> 2461, 4861 and 49=
1 "conceptual models") visible in user space?That is,=0A> is it possible to=
 see what's going on as it happens? If so, how? Or is=0A> it a black box?=
=0A>=A0=0A=0ALinux exposes some of this information to user space e.g.=0A=
=0Aip -6 route show table cache=0A=0Aand the=A0=0A=0Aip -6 neigh show=0A=0A=
command shows the router flag for neighbors that are routers.=0A=0AMy under=
standing though is that Linux doesn't implement the described data structur=
es specifically.=0A=0ARegards,=0AMark.

From brian.e.carpenter@gmail.com  Fri Feb 22 00:02: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 25A6521F8F23 for ; Fri, 22 Feb 2013 00:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.129
X-Spam-Level: 
X-Spam-Status: No, score=-101.129 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZKKnwvnEZXD for ; Fri, 22 Feb 2013 00:02:18 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2A60021F8EF0 for ; Fri, 22 Feb 2013 00:02:18 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hm6so372312wib.14 for ; Fri, 22 Feb 2013 00:02:17 -0800 (PST)
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:subject:content-type:content-transfer-encoding; bh=lHEDt3v/oSsnrb1NB/HW1kafXWSt43brEwzN8fP+o1I=; b=NAJ9b6Ms8mjePmkJbDcAVJTv7ROdTYcuPO9dJCvxKqEG3O3yQWhMfejQ5f0FfYrsFW Js8qdufOP8bYxCK/QAtoykdwNswAp1p3XOLUSHAor2NkP0BfMFQQM2JRiL4dUbaCIOA7 624S3MwqPZtTCHeFv6g8qXHwwtrOZlvdSbs0PTNkZm8MV9ywpXRxkTRau8ZxgO1654bI TBoDocYMPnuHIidXWdDP0MuZYvLqKNrwH9/uaqjzX8JxvlSIXagydwEUnDBGAgwDzEdx tYnDf4KOtE/K3eBb9d0JFayVfmsmwILMOvxGt6bHL0CTWJ9ppK9qYTHk+zCrHdCf0Mqh E3MQ==
X-Received: by 10.180.95.199 with SMTP id dm7mr1460502wib.20.1361520137036; Fri, 22 Feb 2013 00:02:17 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-217-222.as13285.net. [2.102.217.222]) by mx.google.com with ESMTPS id bg5sm1932922wib.8.2013.02.22.00.02.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 00:02:16 -0800 (PST)
Message-ID: <51272615.1090701@gmail.com>
Date: Fri, 22 Feb 2013 08:02:29 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man 
Subject: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-02.txt]
Content-Type: text/plain; charset=ISO-8859-1
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, 22 Feb 2013 08:02:25 -0000

Hi,

This is a significant update compared to the -01 version: better justification,
and carefully updated firewall requirements (in terms of SHOULD, MUST,
and defaults). There are also editorial changes for clarity.

   Brian + Sheng


-------- Original Message --------
Subject: I-D Action: draft-carpenter-6man-ext-transmit-02.txt
Date: Thu, 21 Feb 2013 23:49:52 -0800
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : Transmission of IPv6 Extension Headers
	Author(s)       : Brian Carpenter
                          Sheng Jiang
	Filename        : draft-carpenter-6man-ext-transmit-02.txt
	Pages           : 9
	Date            : 2013-02-21

Abstract:
   Various IPv6 extension headers have been defined since the IPv6
   standard was first published.  This document updates RFC 2460 to
   clarify how intermediate nodes should deal with such extension
   headers and with any that are defined in future.  It also specifies
   how extension headers should be registered by IANA, with a
   corresponding minor update to RFC 2780.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-02


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 wwwrun@rfc-editor.org  Fri Feb 22 12:27: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 47B4D21F8EBE; Fri, 22 Feb 2013 12:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.047
X-Spam-Level: 
X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCKzP-DQCVw2; Fri, 22 Feb 2013 12:27:41 -0800 (PST)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D30BE21F8EB9; Fri, 22 Feb 2013 12:27:41 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 9605FB1E003; Fri, 22 Feb 2013 12:26:43 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: RFC 6874 on Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
From: rfc-editor@rfc-editor.org
Message-Id: <20130222202643.9605FB1E003@rfc-editor.org>
Date: Fri, 22 Feb 2013 12:26:43 -0800 (PST)
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: Fri, 22 Feb 2013 20:27:42 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6874

        Title:      Representing IPv6 Zone Identifiers in 
                    Address Literals and Uniform Resource Identifiers 
        Author:     B. Carpenter,
                    S. Cheshire,
                    R. Hinden
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2013
        Mailbox:    brian.e.carpenter@gmail.com, 
                    cheshire@apple.com, 
                    bob.hinden@gmail.com
        Pages:      10
        Characters: 19361
        Updates:    RFC3986

        I-D Tag:    draft-ietf-6man-uri-zoneid-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6874.txt

This document describes how the zone identifier of an IPv6 scoped
address, defined as  in the IPv6 Scoped Address Architecture
(RFC 4007), can be represented in a literal IPv6 address and in a
Uniform Resource Identifier that includes such a literal address.  It
updates the URI Generic Syntax specification (RFC 3986) accordingly. 

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 brian.e.carpenter@gmail.com  Sat Feb 23 05:46: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 DF5F521F8EC6 for ; Sat, 23 Feb 2013 05:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.82
X-Spam-Level: 
X-Spam-Status: No, score=-100.82 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qviWlmZIj77 for ; Sat, 23 Feb 2013 05:46:13 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id E218521F8E8F for ; Sat, 23 Feb 2013 05:46:12 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id hm14so1714834wib.10 for ; Sat, 23 Feb 2013 05:46:12 -0800 (PST)
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:subject:content-type:content-transfer-encoding; bh=L08cQZsi9kSOZIJVaE0k7c1rY/Cjpi9eAgPYedC5fbY=; b=bM9GQSO/gbVKLyToJIKZh7mc9cpS8lJTPqPFlcftLwwwmC4vTcy9cbX0tU8gH//oOh oQmTu271cymLw9qIoJQUzzLcL93Y7h4io1V8WSdBfw8FHMe2HOKoPrW019o5f4AvdQQu pLgxgO5Zs2UqwkL5LiCZHDD2E9eLPfGypaAhpGpCLQQGS/+JyPdJilPPCwfi0DwCM3PS BZ6W1w7AJudej0wyqnayuk4uy820fUXXe+88WlYv6on3bVUWMwGZuF7ajrDXPRXkctJZ 3KtEqmvQpPq+Rp/uaKS0rkYq59pSj7yOUUJjKE4uvrfZ7bOow69WhYFHK3nrCoSS8nsN QQ4Q==
X-Received: by 10.180.98.232 with SMTP id el8mr2707149wib.22.1361627171753; Sat, 23 Feb 2013 05:46:11 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-117.as13285.net. [2.102.216.117]) by mx.google.com with ESMTPS id fg6sm4041869wib.10.2013.02.23.05.46.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 05:46:10 -0800 (PST)
Message-ID: <5128C833.8020405@gmail.com>
Date: Sat, 23 Feb 2013 13:46:27 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man 
Subject: [Fwd: RFC 6874 on Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers]
Content-Type: text/plain; charset=UTF-8
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: Sat, 23 Feb 2013 13:46:14 -0000

fyi

-------- Original Message --------
Subject: RFC 6874 on Representing IPv6 Zone Identifiers in Address Literals	and Uniform Resource Identifiers
Date: Fri, 22 Feb 2013 12:26:43 -0800 (PST)
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: ipv6@ietf.org, rfc-editor@rfc-editor.org


A new Request for Comments is now available in online RFC libraries.


        RFC 6874

        Title:      Representing IPv6 Zone Identifiers in
                    Address Literals and Uniform Resource Identifiers
        Author:     B. Carpenter,
                    S. Cheshire,
                    R. Hinden
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2013
        Mailbox:    brian.e.carpenter@gmail.com,
                    cheshire@apple.com,
                    bob.hinden@gmail.com
        Pages:      10
        Characters: 19361
        Updates:    RFC3986

        I-D Tag:    draft-ietf-6man-uri-zoneid-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6874.txt

This document describes how the zone identifier of an IPv6 scoped
address, defined as  in the IPv6 Scoped Address Architecture
(RFC 4007), can be represented in a literal IPv6 address and in a
Uniform Resource Identifier that includes such a literal address.  It
updates the URI Generic Syntax specification (RFC 3986) accordingly.

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 internet-drafts@ietf.org  Mon Feb 25 08:33: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 5B77221F95B7; Mon, 25 Feb 2013 08:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcL+YKYS493o; Mon, 25 Feb 2013 08:33:56 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EA721F94D5; Mon, 25 Feb 2013 08:33:52 -0800 (PST)
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-06.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130225163352.30956.60376.idtracker@ietfa.amsl.com>
Date: Mon, 25 Feb 2013 08:33:52 -0800
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, 25 Feb 2013 16:33:58 -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-06.txt
	Pages           : 14
	Date            : 2013-02-25

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-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-dad-proxy-06


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


From internet-drafts@ietf.org  Mon Feb 25 13:00: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 91F4621E80CF; Mon, 25 Feb 2013 13:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.404
X-Spam-Level: 
X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpKpaiM63LQ9; Mon, 25 Feb 2013 13:00:22 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F0521F91F4; Mon, 25 Feb 2013 13:00:16 -0800 (PST)
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-udpzero-12.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130225210016.28757.20154.idtracker@ietfa.amsl.com>
Date: Mon, 25 Feb 2013 13:00:16 -0800
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, 25 Feb 2013 21:00: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           : Applicability Statement for the use of IPv6 UDP Datagram=
s with Zero Checksums
	Author(s)       : Godred Fairhurst
                          Magnus Westerlund
	Filename        : draft-ietf-6man-udpzero-12.txt
	Pages           : 41
	Date            : 2013-02-25

Abstract:
   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 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 updates use of
   the UDP checksum with IPv6.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-udpzero-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpzero-12


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


From bob.hinden@gmail.com  Mon Feb 25 15:58: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 7E02021F8419 for ; Mon, 25 Feb 2013 15:58:11 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvE7VtcTItmU for ; Mon, 25 Feb 2013 15:58:10 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 325B721F8202 for ; Mon, 25 Feb 2013 15:58:00 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id l6so2150973vcl.3 for ; Mon, 25 Feb 2013 15:57:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=xNuiqY0L2eVcEqopSac3/ShSVJI4MjRw86ZR4oTghd4=; b=A+ImYD6Zsmqz44HdGHdQSXVINwQrV0A0mwIxg6Uto30+1yPHaEfCCsywGXawa4U97o D32U+bXM8H2nFcRPXKGohOqKEKFUnA98isuPr9PKKcvXxtgxFfaMCIism8ncEEZktYNc MB43ebdtcJFh9pz0V88o7yOFa1ylehUR0/0QXW/2GVD2SEBY314fEADYUGaqtdjUfZjc iU6GSM7Hi3/ThrmV2z40pauwpwLjn5CTu6y2rWpxmYpYc6Rbuhf03VUt3aYevXQzY6Px TsJsTdubOXiGmbFCbnpryAMMgom0AeWw8RpkM7e478yHBa0HoNmo/MEftoorbyeGgcZs c3ww==
X-Received: by 10.58.134.16 with SMTP id pg16mr11133812veb.12.1361836672180; Mon, 25 Feb 2013 15:57:52 -0800 (PST)
Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPS id l5sm11358685vdi.4.2013.02.25.15.57.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 25 Feb 2013 15:57:51 -0800 (PST)
From: Bob Hinden 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: 6MAN WG Last Call: 
Date: Mon, 25 Feb 2013 15:57:49 -0800
Message-Id: <6BBD3BA4-6A2B-431B-A006-E029E7A3CBCA@gmail.com>
To: IPv6 List 
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Cc: Bob Hinden 
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, 25 Feb 2013 23:58:11 -0000

All,

This message starts a one week 6MAN Working Group on advancing:

	Title           : IPv6 and UDP Checksums for Tunneled Packets
	Author(s)       : Marshall Eubanks
                          P.F. Chimento
                          Magnus Westerlund
	Filename        : draft-ietf-6man-udpchecksums-08.txt
	Pages           : 13
	Date            : 2013-02-21

as Proposed Standard, and

	Title           : Applicability Statement for the use of IPv6 =
UDP Datagrams with Zero Checksums
	Author(s)       : Godred Fairhurst
                          Magnus Westerlund
	Filename        : draft-ietf-6man-udpzero-12.txt
	Pages           : 41
	Date            : 2013-02-25

as an Informational RFC.

This last call is being done given the number of changes made to resolve =
issues raised during the IESG review.  All of the IESG discussed have =
been cleared based on the changes in these versions of the documents. =20=


Substantive comments and statements of support for advancing this =
document should be directed to the mailing list.  Editorial suggestions =
can be sent to the authors.  This last call will end on 4 March 2013.

Regards,

Bob Hinden & Ole Tr=F8an



From leo.liubing@huawei.com  Mon Feb 25 23: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 0C46621F9668; Mon, 25 Feb 2013 23:14:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level: 
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JcVsdbBpbf1; Mon, 25 Feb 2013 23:14:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1169E21F960B; Mon, 25 Feb 2013 23:14:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQB42294; Tue, 26 Feb 2013 07:14:31 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 07:13:38 +0000
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 07:14:30 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 15:14:27 +0800
From: "Liubing (Leo)" 
To: "ipv6@ietf.org" , "v6ops@ietf.org" 
Subject: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cA==
Date: Tue, 26 Feb 2013 07:14:27 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com>
In-Reply-To: <20130225095210.8863.75094.idtracker@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 26 Feb 2013 07:14:44 -0000

SGksIDZtYW4gJiB2Nm9wcw0KDQpXZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyB0
aGUgU0xBQUMvREhDUHY2IGludGVyYWN0aW9uIGdhcHMuDQoNCkFzIHdlIGtub3cgdGhlcmUgYXJl
IHNldmVyYWwgZmxhZ3MgaW4gUkEgbWVzc2FnZXMgcmVnYXJkaW5nIHdpdGggdGhlIGhvc3QgY29u
ZmlndXJhdGlvbiBiZWhhdmlvciwgd2hpY2ggYXJlIEEgKEF1dG9ub21vdXMpIGZsYWcsIE0gKE1h
bmFnZWQpIGZsYWcsIGFuZCBPIChPdGhlcmNvbmZpZykgZmxhZy4NCkZvciBzb21lIHJlYXNvbiwg
dGhlIGhvc3QgYmVoYXZpb3Igb2YgaW50ZXJwcmV0aW5nIHRoZSBmbGFncyBpcyBhbWJpZ3VvdXMg
aW4gdGhlIHN0YW5kYXJkIChtYWlubHkgUkZDNDg2MikuIEkgcHJlc2VudGVkIGEgZHJhZnQgZGlz
Y3Vzc2luZyBNIGZsYWcgYmVoYXZpb3IgaW4gNm1hbiBAaWV0Zjg0LCBhbmQgdGhlcmUgd2VyZSBz
b21lIGZlZWRiYWNrcyBhcmd1aW5nIHRoZSBzYW1lIGlzc3VlLiBUaGlzIGRyYWZ0IGFuYWx5emVk
IGFsbCB0aGUgdGhyZWUgZmxhZ3MsIGFuZCBwcm92aWRlZCB0ZXN0IHJlc3VsdCBvZiBjdXJyZW50
IGltcGxlbWVudGF0aW9ucywgaXQgc2hvd2VkIHRoZSBiZWhhdmlvciBvZiBkaWZmZXJlbnQgbWFp
bnN0cmVhbSBkZXNrdG9wIE9TZXMgaGF2ZSB2YXJpZWQuIFRoZSBhbWJpZ3VvdXMgYW5kIHZhcmlh
dGlvbiBtaWdodCBjYXVzZSBvcGVyYXRpb25hbCBwcm9ibGVtcywgc3VjaCBhcyByZW51bWJlcmlu
ZyAodXNlZCB0byBkaXNjdXNzIGluIDZyZW51bSBXRyBhbmQgYmVlbiBkb2N1bWVudGVkIGluIHRo
ZSBXRyBkcmFmdHMpLCBjb2xkIHN0YXJ0IHByb2JsZW0sIGFuZCBtYW5hZ2VtZW50IGdhcHMgLmV0
Yy4NCg0KWW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIGFwcHJlY2lhdGVkIHZlcnkg
bXVjaC4gDQoNCkFsbCB0aGUgYmVzdCwNCkJpbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjUsIDIwMTMgNTo1MiBQ
TQ0KPiBUbzogTGl1YmluZyAoTGVvKQ0KPiBDYzogcmJvbmljYUBqdW5pcGVyLm5ldA0KPiBTdWJq
ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LWxpdS1ib25pY2EtZGhj
cHY2LXNsYWFjLXByb2JsZW0tMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs
IGRyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDEudHh0DQo+IGhhcyBiZWVu
IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmluZyBMaXUgYW5kIHBvc3RlZCB0byB0aGUNCj4g
SUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC1saXUtYm9uaWNhLWRoY3B2
Ni1zbGFhYy1wcm9ibGVtDQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkgREhDUHY2L1NMQUFD
IEFkZHJlc3MgQ29uZmlndXJhdGlvbiBJbnRlcmFjdGlvbiBQcm9ibGVtDQo+IFN0YXRlbWVudA0K
PiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0yNQ0KPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1p
c3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAxMg0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5v
cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0t
DQo+IDAxLnR4dA0KPiBTdGF0dXM6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPiBIdG1saXplZDoNCj4gaHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJv
YmxlbS0wMQ0KPiBEaWZmOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm
dC1saXUtYm9uaWNhLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4g
ICAgVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgaG9zdCBiZWhhdmlvciBvZiBESENQdjYvU0xB
QUMgaW50ZXJhY3Rpb24NCj4gICAgaXNzdWUuIEl0IHJldmlld3MgdGhlIHN0YW5kYXJkIGRlZmlu
aXRpb24gb2YgdGhlIGhvc3QgYmVoYXZpb3JzIGFuZA0KPiAgICBwcm92aWRlcyB0aGUgdGVzdCBy
ZXN1bHRzIG9mIGN1cnJlbnQgbWFpbnN0cmVhbSBpbXBsZW1lbnRhdGlvbnMuIFNvbWUNCj4gICAg
cG90ZW50aWFsIG9wZXJhdGlvbmFsIGdhcHMgb2YgdGhlIGludGVyYWN0aW9uIGFyZSBhbHNvIGRl
c2NyaWJlZC4NCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==

From arturo.servin@gmail.com  Tue Feb 26 01:28: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 852D521F892D for ; Tue, 26 Feb 2013 01:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB8Sq-o5Qefu for ; Tue, 26 Feb 2013 01:28:47 -0800 (PST)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6602F21F8996 for ; Tue, 26 Feb 2013 01:28:47 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id fa11so2322653pad.9 for ; Tue, 26 Feb 2013 01:28:41 -0800 (PST)
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:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=M6InXr4gJtOwOKwO+RnxaanC0nJ5czWnco6e3KJfamA=; b=h7zyexd2Pm+7sUGAsDUQafGY7M3qwEr75ntTEQaXDGjqCdmCttUAG/Ep8we5bZzz/7 UGlvHnEtn4U+j1MCHDa6BsNLloh+FN/ccwEdeQQpdJvrqzTRWtxtNqCVu/J5qtiLvbDK h54cwt4gR1cj6PVWAHiDai58zR5AMWkEONuShvpt0YOpdOiNDSl2qBbmWJS8g6beIF4Q 0LJvEM2qEPzC/TaPwfjYG0UHS3r57dFDQlF78ml1fJtyGPE6Z/CMQqZlhN+Vlc6iuEUL 8tE0PgDiLzzGsAuuxp3okaSgTCre6b4LmrxPCcH3vKxrcwBf3+4xORisvIqUktVWHKC/ Tteg==
X-Received: by 10.66.251.102 with SMTP id zj6mr888783pac.7.1361870921474; Tue, 26 Feb 2013 01:28:41 -0800 (PST)
Received: from 187.150.dhcp.conference.apricot.net ([220.247.150.187]) by mx.google.com with ESMTPS id km10sm342092pbc.9.2013.02.26.01.28.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 01:28:40 -0800 (PST)
Message-ID: <512C8044.3050103@gmail.com>
Date: Tue, 26 Feb 2013 17:28:36 +0800
From: Arturo Servin 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 26 Feb 2013 09:28:48 -0000

Dear authors,

	Very interesting document and very valuable to document the current
behavior of the A, M and O flags (that have caused some headaches to
some including myself when troubleshooting IPv6).

	I see that has been submitted as "Proposed Standard" but I failed to
find what you are proposing.

	Would it better to be submitted as "Informational" and then look how to
indicate the correct behavior of the flags? or just as "Informational"?

Regards.
as
	

On 26/02/2013 15:14, Liubing (Leo) wrote:
> Hi, 6man & v6ops
> 
> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
> 
> As we know there are several flags in RA messages regarding with the host configuration behavior, which are A (Autonomous) flag, M (Managed) flag, and O (Otherconfig) flag.
> For some reason, the host behavior of interpreting the flags is ambiguous in the standard (mainly RFC4862). I presented a draft discussing M flag behavior in 6man @ietf84, and there were some feedbacks arguing the same issue. This draft analyzed all the three flags, and provided test result of current implementations, it showed the behavior of different mainstream desktop OSes have varied. The ambiguous and variation might cause operational problems, such as renumbering (used to discuss in 6renum WG and been documented in the WG drafts), cold start problem, and management gaps .etc.
> 
> Your review and comments would be appreciated very much. 
> 
> All the best,
> Bing
> 
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Monday, February 25, 2013 5:52 PM
>> To: Liubing (Leo)
>> Cc: rbonica@juniper.net
>> Subject: New Version Notification for
>> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>>
>>
>> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>> has been successfully submitted by Bing Liu and posted to the
>> IETF repository.
>>
>> Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
>> Revision:	 01
>> Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
>> Statement
>> Creation date:	 2013-02-25
>> Group:		 Individual Submission
>> Number of pages: 12
>> URL:
>> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem-
>> 01.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
>> Htmlized:
>> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem-01
>>
>> Abstract:
>>    This document analyzes the host behavior of DHCPv6/SLAAC interaction
>>    issue. It reviews the standard definition of the host behaviors and
>>    provides the test results of current mainstream implementations. Some
>>    potential operational gaps of the interaction are also described.
>>
>>
>>
>>
>> The IETF Secretariat
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

From leo.liubing@huawei.com  Tue Feb 26 01:53: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 E1B1621F86BA; Tue, 26 Feb 2013 01:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVmwubHw7B1E; Tue, 26 Feb 2013 01:53:14 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 452D821F891D; Tue, 26 Feb 2013 01:53:13 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOU58190; Tue, 26 Feb 2013 09:53:11 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 09:52:17 +0000
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 09:53:10 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 17:53:03 +0800
From: "Liubing (Leo)" 
To: Arturo Servin , "ipv6@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiLWU8AgACLyDA=
Date: Tue, 26 Feb 2013 09:53:02 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC132@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <512C8044.3050103@gmail.com>
In-Reply-To: <512C8044.3050103@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "v6ops@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, 26 Feb 2013 09:53:17 -0000

Hi, Arturo and all

That was my mistake. I derived this draft from a template and forgot to cha=
nge it.=20
It should be "Informational", thanks for finding this bug.

B.R.
Bing

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Arturo Servin
> Sent: Tuesday, February 26, 2013 5:29 PM
> To: ipv6@ietf.org
> Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
>=20
> Dear authors,
>=20
> 	Very interesting document and very valuable to document the current
> behavior of the A, M and O flags (that have caused some headaches to
> some including myself when troubleshooting IPv6).
>=20
> 	I see that has been submitted as "Proposed Standard" but I failed to
> find what you are proposing.
>=20
> 	Would it better to be submitted as "Informational" and then look how
> to
> indicate the correct behavior of the flags? or just as "Informational"?
>=20
> Regards.
> as
>=20
>=20
> On 26/02/2013 15:14, Liubing (Leo) wrote:
> > Hi, 6man & v6ops
> >
> > We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
> >
> > As we know there are several flags in RA messages regarding with the ho=
st
> configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
> and O (Otherconfig) flag.
> > For some reason, the host behavior of interpreting the flags is ambiguo=
us
> in the standard (mainly RFC4862). I presented a draft discussing M flag
> behavior in 6man @ietf84, and there were some feedbacks arguing the same
> issue. This draft analyzed all the three flags, and provided test result =
of
> current implementations, it showed the behavior of different mainstream
> desktop OSes have varied. The ambiguous and variation might cause
> operational problems, such as renumbering (used to discuss in 6renum WG
> and been documented in the WG drafts), cold start problem, and
> management gaps .etc.
> >
> > Your review and comments would be appreciated very much.
> >
> > All the best,
> > Bing
> >
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Monday, February 25, 2013 5:52 PM
> >> To: Liubing (Leo)
> >> Cc: rbonica@juniper.net
> >> Subject: New Version Notification for
> >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >>
> >>
> >> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >> has been successfully submitted by Bing Liu and posted to the
> >> IETF repository.
> >>
> >> Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
> >> Revision:	 01
> >> Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
> >> Statement
> >> Creation date:	 2013-02-25
> >> Group:		 Individual Submission
> >> Number of pages: 12
> >> URL:
> >>
> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem=
-
> >> 01.txt
> >> Status:
> >> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
> >> Htmlized:
> >> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
> >> Diff:
> >>
> http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-problem-=
01
> >>
> >> Abstract:
> >>    This document analyzes the host behavior of DHCPv6/SLAAC
> interaction
> >>    issue. It reviews the standard definition of the host behaviors and
> >>    provides the test results of current mainstream implementations.
> Some
> >>    potential operational gaps of the interaction are also described.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >
> > --------------------------------------------------------------------
> > 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 arturo.servin@gmail.com  Tue Feb 26 02:09: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 3BFF521F89AA; Tue, 26 Feb 2013 02:09:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGDqvZ9jKZp0; Tue, 26 Feb 2013 02:09:58 -0800 (PST)
Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 73F0621F899E; Tue, 26 Feb 2013 02:09:58 -0800 (PST)
Received: by mail-da0-f42.google.com with SMTP id z17so1951888dal.29 for ; Tue, 26 Feb 2013 02:09:58 -0800 (PST)
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=BF8Ubp62vq3Nck9h01k6J/XGabaaDnx9AT4AHgeTbG0=; b=xqx8F6+/xfUnLGPo9V0rVSCHJOHmc5VwMP1XxrhSgVyM9FxxJ6sgKMr9c5jOL+r31a 8RaZhCIh78O8h7sgM0SHyr7ZSpODagYThhWrY3mdMwyUrRHYQPv/k7cZuO2uysK7guxC Ys1bFmIuueHNnAyepShpJg5BYomBuQJBlIujWtQ12zJTy7bKytfhyIZiNbpr7Pw8aO2K hjJb2HiVfJKS8IChxVN6UuLIw+wh3o+wKjzTX3+nTmcpEOQ/PjUwVBbJwQkj7kEmN4kF n6xTfeoH6nmG9b4NmJCvXkXSSgE1xwuEDMGNUdS+//P4YBGBdiR+vIPdGE47PXDcnAsZ gC2A==
X-Received: by 10.68.191.106 with SMTP id gx10mr23272550pbc.151.1361873397863;  Tue, 26 Feb 2013 02:09:57 -0800 (PST)
Received: from MiniR2D2.local ([203.126.139.254]) by mx.google.com with ESMTPS id ab1sm432045pbd.37.2013.02.26.02.09.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 02:09:56 -0800 (PST)
Message-ID: <512C89EE.8090800@gmail.com>
Date: Tue, 26 Feb 2013 18:09:50 +0800
From: Arturo Servin 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Liubing (Leo)" 
Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <512C8044.3050103@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC132@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC132@nkgeml506-mbx.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "v6ops@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: Tue, 26 Feb 2013 10:09:59 -0000

	Good.

	Regarding a possible next step. Are you guys planning to propose a
"correct" behavior of the flags? It may be worth to try.

Regards,
as

On 26/02/2013 17:53, Liubing (Leo) wrote:
> Hi, Arturo and all
> 
> That was my mistake. I derived this draft from a template and forgot to change it. 
> It should be "Informational", thanks for finding this bug.
> 
> B.R.
> Bing
> 
>> -----Original Message-----
>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
>> Arturo Servin
>> Sent: Tuesday, February 26, 2013 5:29 PM
>> To: ipv6@ietf.org
>> Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
>>
>> Dear authors,
>>
>> 	Very interesting document and very valuable to document the current
>> behavior of the A, M and O flags (that have caused some headaches to
>> some including myself when troubleshooting IPv6).
>>
>> 	I see that has been submitted as "Proposed Standard" but I failed to
>> find what you are proposing.
>>
>> 	Would it better to be submitted as "Informational" and then look how
>> to
>> indicate the correct behavior of the flags? or just as "Informational"?
>>
>> Regards.
>> as
>>
>>
>> On 26/02/2013 15:14, Liubing (Leo) wrote:
>>> Hi, 6man & v6ops
>>>
>>> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
>>>
>>> As we know there are several flags in RA messages regarding with the host
>> configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
>> and O (Otherconfig) flag.
>>> For some reason, the host behavior of interpreting the flags is ambiguous
>> in the standard (mainly RFC4862). I presented a draft discussing M flag
>> behavior in 6man @ietf84, and there were some feedbacks arguing the same
>> issue. This draft analyzed all the three flags, and provided test result of
>> current implementations, it showed the behavior of different mainstream
>> desktop OSes have varied. The ambiguous and variation might cause
>> operational problems, such as renumbering (used to discuss in 6renum WG
>> and been documented in the WG drafts), cold start problem, and
>> management gaps .etc.
>>>
>>> Your review and comments would be appreciated very much.
>>>
>>> All the best,
>>> Bing
>>>
>>>> -----Original Message-----
>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>> Sent: Monday, February 25, 2013 5:52 PM
>>>> To: Liubing (Leo)
>>>> Cc: rbonica@juniper.net
>>>> Subject: New Version Notification for
>>>> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>>>>
>>>>
>>>> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>>>> has been successfully submitted by Bing Liu and posted to the
>>>> IETF repository.
>>>>
>>>> Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
>>>> Revision:	 01
>>>> Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
>>>> Statement
>>>> Creation date:	 2013-02-25
>>>> Group:		 Individual Submission
>>>> Number of pages: 12
>>>> URL:
>>>>
>> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem-
>>>> 01.txt
>>>> Status:
>>>> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
>>>> Diff:
>>>>
>> http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem-01
>>>>
>>>> Abstract:
>>>>    This document analyzes the host behavior of DHCPv6/SLAAC
>> interaction
>>>>    issue. It reviews the standard definition of the host behaviors and
>>>>    provides the test results of current mainstream implementations.
>> Some
>>>>    potential operational gaps of the interaction are also described.
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>
>>> --------------------------------------------------------------------
>>> 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 sarikaya2012@gmail.com  Mon Feb 25 12:18: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 135BC21F8F43; Mon, 25 Feb 2013 12:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.528
X-Spam-Level: 
X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqbMtfsYvcqS; Mon, 25 Feb 2013 12:18:17 -0800 (PST)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id DA29C21F8FAA; Mon, 25 Feb 2013 12:18:13 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id go11so2559634lbb.36 for ; Mon, 25 Feb 2013 12:18:12 -0800 (PST)
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:content-type; bh=red1U+EGqr8lg4a21Y4//WCl+KyBuqbpm0YKxB2TXLQ=; b=yHoadUJ5bVD7aOqtgOwtPM4UJUtP1oNXQ1yh6BGnnEZlblMxr0kFBWNEgBbyjTOaXu C3c/dUM+7CmULbRwVdu6Eg8opV1Xb6+T3Ex+Ax2bL0hMkJxqpys2gS0vrMo8c2hjFsL5 +qGZHfsRdwLsDyIwo48AgHe/X6CTEJGA4thdqU9HVL4mpyOvwwAT2+0DjuuWLqvFoCsG sUSTqrocW1ser73gDVqN3Tq7R/fpJX4JV1JBVDVc3VtbkbTFe3Rqqi3LehOqHA0c1l3x +prNfCmYG963n15UmFrGbwrfTCi0ckfs/GD8c7UuaHdzP6F/tjL1SAzA2VTNZjPL02y5 crxQ==
MIME-Version: 1.0
X-Received: by 10.152.104.36 with SMTP id gb4mr11193184lab.13.1361823492823; Mon, 25 Feb 2013 12:18:12 -0800 (PST)
Received: by 10.114.28.168 with HTTP; Mon, 25 Feb 2013 12:18:12 -0800 (PST)
In-Reply-To: <20130225201655.26126.49424.idtracker@ietfa.amsl.com>
References: <20130225201655.26126.49424.idtracker@ietfa.amsl.com>
Date: Mon, 25 Feb 2013 14:18:12 -0600
Message-ID: 
Subject: New Version Notification for draft-sarikaya-mif-6man-ra-route-02.txt
From: Behcet Sarikaya 
To: 6man@ietf.org, mif@ietf.org
Content-Type: multipart/alternative; boundary=f46d04083d1589587d04d6923dc9
X-Mailman-Approved-At: Tue, 26 Feb 2013 03:00:27 -0800
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, 25 Feb 2013 20:18:18 -0000

--f46d04083d1589587d04d6923dc9
Content-Type: text/plain; charset=ISO-8859-1

A new version of I-D, draft-sarikaya-mif-6man-ra-route-02.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename:        draft-sarikaya-mif-6man-ra-route
Revision:        02
Title:           IPv6 RA Options for Multiple Interface Next Hop Routes
Creation date:   2013-02-25
Group:           Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-02.txt
Status:
http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route
Htmlized:
http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-02

Abstract:
   This draft defines new Router Advertisement options for configuring
   next hop routes on the mobile or fixed nodes.  Using these options,
   an operator can easily configure nodes with multiple interfaces (or
   otherwise multi-homed) to enable them to select the routes to a
   destination.  Each option is defined together with definitions of
   host and router behaviors.




The IETF Secretariat

--f46d04083d1589587d04d6923dc9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





A new version of I-D, draft-sarikaya-mif-6man-ra-route-02.txt

has been successfully submitted by Behcet Sarikaya and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-sarikaya-mif-6man-ra-route

Revision: =A0 =A0 =A0 =A002

Title: =A0 =A0 =A0 =A0 =A0 IPv6 RA Options for Multiple Interface Next Hop =
Routes

Creation date: =A0 2013-02-25

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 9

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf=
.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-02.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/=
doc/draft-sarikaya-mif-6man-ra-route

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft=
-sarikaya-mif-6man-ra-route-02

Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/=
rfcdiff?url2=3Ddraft-sarikaya-mif-6man-ra-route-02



Abstract:

=A0 =A0This draft defines new Router Advertisement options for configuring<=
br>
=A0 =A0next hop routes on the mobile or fixed nodes. =A0Using these options=
,

=A0 =A0an operator can easily configure nodes with multiple interfaces (or<=
br>
=A0 =A0otherwise multi-homed) to enable them to select the routes to a

=A0 =A0destination. =A0Each option is defined together with definitions of<=
br>
=A0 =A0host and router behaviors.









The IETF Secretariat







--f46d04083d1589587d04d6923dc9--

From victor.kuarsingh@gmail.com  Tue Feb 26 05:28: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 EE24821F8942; Tue, 26 Feb 2013 05:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.164
X-Spam-Level: 
X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Newtwd06mdXF; Tue, 26 Feb 2013 05:28:29 -0800 (PST)
Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56E21F89A5; Tue, 26 Feb 2013 05:28:29 -0800 (PST)
Received: by mail-ia0-f177.google.com with SMTP id o25so3461359iad.22 for ; Tue, 26 Feb 2013 05:28:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=iae8H5wdyiqptN1wbjXJHXdtE3oScMSMnXurp5fvnW8=; b=z/oNzNGI/y9cEc//QTyHAfAvyOfuWFmsMmBBv+hdp75reyIZnIdmpcLLLGZKbE6Ucm +ZT0nL7rEmNcaOk/j35tZj7uh8CSURkBAy+BP+sWEngEd/Yct3lik7k6EZSiNL61WGs5 NVOEbq7QK2E7FFCnyWbFHQ8hmBzaaGzoxa/Dj2kOsf33vDUqW5K1AXBs+KfEfvoCJELH JLYxer+jWt+Pe3r9jCvGUGHIvx/VYaY8IpRVY7sRvlE1bXp2KCXXTuZ4lSTAWmVKxi6W 7rsGd7B7QG5iVLCa+uhlwkzGQ9XhCVAlIvM92NCwhjc3r1CrPrzp8VCH66EXXr2vK8em DBXg==
X-Received: by 10.50.42.168 with SMTP id p8mr5446698igl.106.1361885308791; Tue, 26 Feb 2013 05:28:28 -0800 (PST)
Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id ur12sm334146igb.8.2013.02.26.05.28.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 26 Feb 2013 05:28:27 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.10.0.110310
Date: Tue, 26 Feb 2013 08:28:22 -0500
Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
From: Victor Kuarsingh 
To: "Liubing (Leo)" , "ipv6@ietf.org" , "v6ops@ietf.org" 
Message-ID: 
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "renum@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, 26 Feb 2013 13:28:30 -0000

Bing,

I as able to review the draft and agree this needs to be documented and
discussed.  I have had many frustrating nights dealing with my multiple
OSs at home and figuring out what behaviour I was trying to expect when
changing the upstream router's settings (M/O/A).

I think the problem space discussion within the draft should be enough to
have a preliminary discussion in the WG.  I know there have been issues in
the past with various opinions on what the M/O bits (for example) should
or should not be used for - or how authoritative they should be.

If the groups can agree that there is in fact a problem, then I would
agree with Arturo that we can have a constructive follow-up
draft/discussion on the corrective action.

Lets get past step 1 and agree there is an issue (or not); then go down
the more sensitive path of agreeing to the corrective action.

Thanks for putting this together.

Regards,

Victor Kuarsingh



On 2013-02-26 2:14 AM, "Liubing (Leo)"  wrote:

>Hi, 6man & v6ops
>
>We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
>
>As we know there are several flags in RA messages regarding with the host
>configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
>and O (Otherconfig) flag.
>For some reason, the host behavior of interpreting the flags is ambiguous
>in the standard (mainly RFC4862). I presented a draft discussing M flag
>behavior in 6man @ietf84, and there were some feedbacks arguing the same
>issue. This draft analyzed all the three flags, and provided test result
>of current implementations, it showed the behavior of different
>mainstream desktop OSes have varied. The ambiguous and variation might
>cause operational problems, such as renumbering (used to discuss in
>6renum WG and been documented in the WG drafts), cold start problem, and
>management gaps .etc.
>
>Your review and comments would be appreciated very much.
>
>All the best,
>Bing
>
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Monday, February 25, 2013 5:52 PM
>> To: Liubing (Leo)
>> Cc: rbonica@juniper.net
>> Subject: New Version Notification for
>> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>> 
>> 
>> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>> has been successfully submitted by Bing Liu and posted to the
>> IETF repository.
>> 
>> Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
>> Revision:	 01
>> Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
>> Statement
>> Creation date:	 2013-02-25
>> Group:		 Individual Submission
>> Number of pages: 12
>> URL:
>> 
>>http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem
>>-
>> 01.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
>> Htmlized:
>> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
>> Diff:
>> 
>>http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem-01
>> 
>> Abstract:
>>    This document analyzes the host behavior of DHCPv6/SLAAC interaction
>>    issue. It reviews the standard definition of the host behaviors and
>>    provides the test results of current mainstream implementations. Some
>>    potential operational gaps of the interaction are also described.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------



From pthubert@cisco.com  Tue Feb 26 07:10: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 191EE21F879D for ; Tue, 26 Feb 2013 07:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level: 
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhrFP-5L8Qj4 for ; Tue, 26 Feb 2013 07:10:47 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1326121F8651 for ; Tue, 26 Feb 2013 07:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5346; q=dns/txt; s=iport; t=1361891447; x=1363101047; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0Hpyp7bLGTS04rrBAB5AgKWH+u8EKyLxQQa3pkRXS5A=; b=Y1JzCWqvXOkUpekv/xGytin7zh9epWFqF16ZcZvdHsAJ+2ElXokx2Q79 v91C7hFefu5Mf59c6F27VLnztTIKG1KzJibBFWrv0hwz5OlQo/nLnp5uq mDJTM3WBNUNGQrSbST4XaHdYZfPXJgx5COaLUNzfavv8wIGun9zwT3mDB Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAC/QLFGtJV2a/2dsb2JhbABFg3iCV7saDXEWc4IfAQEBBCMRQw4GAQgRBAEBAwIGHQMCBDAUAQYBAQUEAQQTCAGICgcFnkiOVYJAj2iBI4wxgQ8mGIInMmEDkn+EX49KgwiCJw
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; d="scan'208";a="181304011"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 26 Feb 2013 15:10:46 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1QFAkJp028116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Feb 2013 15:10:46 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 09:10:46 -0600
From: "Pascal Thubert (pthubert)" 
To: 6man 
Subject: FW: New Version Notification for draft-thubert-6lowpan-backbone-router-03.txt
Thread-Topic: New Version Notification for draft-thubert-6lowpan-backbone-router-03.txt
Thread-Index: Ac4UMzhLc6AYE86kR0atXKb8SlF+tQ==
Date: Tue, 26 Feb 2013 15:10:45 +0000
Deferred-Delivery: Tue, 26 Feb 2013 15:10:00 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.88.253]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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, 26 Feb 2013 15:10:49 -0000

SGk6DQoNClRoaXMgaXMgd29yayB0aGF0IHN0YXJ0ZWQgYXQgNkxvV1BBTiBhbmQgd2FzIHBhcnQg
b2YgdGhlIGVhcmx5IDZMb1dQQU4gTkQgV0cgZG9jLiBJdCBpcyBub3cgY29udGlndW91cyB0byA2
TUFOIHdvcmsgd2l0aCB0aGUgRWZmaWNpZW5jeSBhd2FyZSBJUHY2IE5laWdoYm9yIERpc2NvdmVy
eS4NCg0KVGhlIGNvbnRleHQgaXMgYSBiYWNrYm9uZSBsaW5rLCBpbiBhIHNpdHVhdGlvbiB3aGVy
ZSB0aGUgNkxvV1BBTiBORCBvciB0aGUgRWZmaWNpZW5jeSBhd2FyZSBJUHY2IE5laWdoYm9yIERp
c2NvdmVyeSByZXNlcnZhdGlvbiBtZWNoYW5pc20gIGlzIHVzZWQgYXMgb3Bwb3NlZCB0bywgb3Ig
dG9nZXRoZXIgd2l0aCwgIHRoZSBjbGFzc2ljYWwgSVB2NiBOZWlnaGJvciBkaXNjb3ZlcnkuIFdp
dGggYSBzaW5nbGUgcm91dGVyLCBhY3RpbmcgYXMgcmVnaXN0cmFyIChha2EgTkVBUiwgb3IgNkxC
UiksIGFuZCB0aGUgc3VibmV0IHByZWZpeCBkZWNsYXJlZCBhcyBub3Rfb25saW5rLCBjb25uZWN0
aXZpdHkgY2FuIGJlIGVuc3VyZWQgYmV0d2VlbiBlbmVyZ3kgZWZmaWNpZW50IGRldmljZXMgYW5k
IGJldHdlZW4gdGhvc2UgYW5kIGNsYXNzaWNhbCBkZXZpY2VzIHZpYSB0aGUgcmVnaXN0cmFyIHJv
dXRlciwgYXMgZGVzY3JpYmVkIGJ5IHRoZSBFZmZpY2llbmN5IGF3YXJlIElQdjYgTmVpZ2hib3Ig
RGlzY292ZXJ5IGRyYWZ0IGFuZC9vciA2TG9XUEFOIE5ELg0KDQpCdXQgc2F5IHRoYXQgdGhlIG5l
dHdvcmsgZ3Jvd3MgbGFyZ2UgYW5kIHdlIHdhbnQgdG8gaGF2ZSBtb3JlIHRoYW4gb25lIHJvdXRl
ciBhY3RpbmcgYXMgcmVnaXN0cmFyLiBIb3cgZG8gdGhlIHJvdXRlcnMgaW50ZXJhY3Qgd2hlbiBh
IHBhY2tldCByZWFjaGVzIG9uZSByZWdpc3RyYXIgYnV0IHRoZSB0YXJnZXQgZW5lcmd5IGVmZmlj
aWVudCBkZXZpY2UgaXMgcmVnaXN0ZXJlZCB0byB0aGUgb3RoZXI/DQoNCkFuZCB0aGVuLCBzYXkg
dGhhdCB0aGUgc2FtZSBJUHY2IGFkZHJlc3MgaXMgbm93IHJlZ2lzdGVyZWQgdG8gdGhlIHNlY29u
ZCByb3V0ZXIuIElzIHRoaXMgYSBtb3ZlbWVudCwgb3IgYSBkdXBsaWNhdGlvbj8gU2hvdWxkIHRo
ZSByZWdpc3RyYXRpb24gYmUgYWNjZXB0ZWQ/IFdoYXQgYWJvdXQgc3RhdGVzIGluIHRoZSBmaXJz
dCByb3V0ZXI/DQoNClRoZSBkcmFmdCB1c2VzIHByb3h5IG5laWdoYm9yIGRpc2NvdmVyeSB3aXRo
IGFuIGVuaGFuY2VkICBBUk8gb3B0aW9uIHRvIHJlc29sdmUgdGhpcy4gVGhlIHJlZ2lzdHJhciBh
ZHZlcnRpc2VzIHRoZSBkZXZpY2UgSVB2NiBhZGRyZXNzIHdpdGggaXRzIG93biBNQUMgYWRkcmVz
cyBhcyB0YXJnZXQuIFRoaXMgd2F5LCBpbiBhIGZhc2hpb24gdmVyeSBzaW1pbGFyIHRvIGEgSG9t
ZSBBZ2VudCwgaXQgYXR0cmFjdHMgcGFja2V0cyB0byByZWdpc3RlcmVkIGRldmljZXMsIGFuZCB0
aGVuIGl0IGNhbiByb3V0ZSB0aGUgcGFja2V0cyBiYXNlZCBvbiBpdHMgcmVnaXN0cmF0aW9uIHN0
YXRlLiBBIHNlcXVlbmNlIG51bWJlciAoVElEKSBpcyBhZGRlZCB0byB0aGUgQVJPIHRvIHJlc29s
dmUgdGhlIGZyZXNoZXN0IGxvY2F0aW9uIG9mIGEgZGV2aWNlIGluIGNhc2Ugb2YgbW92ZW1lbnQs
IHdoaWxlIHRoZSBleGlzdGluZyB1bmlxdWUgSUQgaXMgdXNlZCB0byBkaXNjcmltaW5hdGUgZHVw
bGljYXRpb25zLg0KDQpPbmUgc2lkZSBiZW5lZml0IG9mIHRoZSBkcmFmdCBpcyB0aGF0IHRoZSBw
cmVmaXggZG9lcyBub3QgbmVlZCB0byBiZSBkZWNsYXJlZCBhcyBub3Rfb25saW5rIGFueW1vcmUs
IGFuZCBzdGlsbCBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSBjbGFzc2ljYWwgZGV2aWNlIGFuZCBh
IDZMb1dQQU4gZGV2aWNlIGNhbiBiZSBhY2hpZXZlZCB0cmFuc3BhcmVudGx5IHRvIHRoZSBkZXZp
Y2UuIEFub3RoZXIgaXMgdGhhdCBzdGF0ZWZ1bCBkZXZpY2VzIHN1Y2ggYXMgU0FWSSBzd2l0Y2hl
cyBnZXQgYSBtb3JlIHNvbGlkIGluZm9ybWF0aW9uIHRvIGJhc2UgdGhlaXIgc3RhdGVzIHVwb24u
IEZpbmFsbHksIHRoaXMgY2FuIGJlIHVzZWZ1bCBmb3IgVk0gZGVwbG95bWVudHMgdGhhdCB1c2Ug
TUFDIHJld3JpdGVzIGluIHRoZSBzd2l0Y2hlcy4NCg0KSSBjYW4gb25seSBpbnNpc3QgdGhhdCB0
aGUgcmVnaXN0cmF0aW9uIG1vZGVsIGlzIGEgbXVjaCBuZWVkZWQgZmVhdHVyZSBmb3IgbG93IHBv
d2VyIGRldmljZXMuIEluIHRoZSBpbmR1c3RyaWFsIGNhc2UsIHdlIGZvcmVzZWUgYSBiYWNrYm9u
ZSB3aXRoIHRlbnMgdG8gYSBodW5kcmVkIHJlZ2lzdHJhcnMgKGJhY2tib25lIHJvdXRlcnMpLCBh
bmQgdGVucyBvZiB0aG91c2FuZHMgb2YgNkxvV1BBTiBkZXZpY2VzIGF0dGFjaGVkLiBBbmQgaXQg
aXMgY3JpdGljYWwgdGhhdCB0aGUgTkQgb3BlcmF0aW9uIG9uIHRoZSBiYWNrYm9uZSBzdGF5IHZl
cnkgbGlnaHQgaW4gb3JkZXIgdG8gb2J0YWluIHN1Y2ggbnVtYmVycywgaW4gcGFydGljdWxhciB3
aXRoIGEgZHJhc3RpYyBlY29ub215IG9uIG11bHRpY2FzdHMgc3VjaCBhcyBncmF0dWl0b3VzIE5B
cy4NCg0KTW9yZSBpbiB0aGUgZHJhZnQgOiApDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl
cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogbHVuZGkgMjUgZsOpdnJpZXIgMjAxMyAxODow
Mg0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v
dGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC02bG93cGFuLWJhY2tib25lLXJvdXRlci0wMy50
eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGh1YmVydC02bG93cGFuLWJhY2ti
b25lLXJvdXRlci0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFz
Y2FsIFRodWJlcnQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFt
ZToJIGRyYWZ0LXRodWJlcnQtNmxvd3Bhbi1iYWNrYm9uZS1yb3V0ZXINClJldmlzaW9uOgkgMDMN
ClRpdGxlOgkJIDZMb1dQQU4gQmFja2JvbmUgUm91dGVyDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0w
Mi0yNQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIw
DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LXRodWJlcnQtNmxvd3Bhbi1iYWNrYm9uZS1yb3V0ZXItMDMudHh0DQpTdGF0dXM6ICAgICAg
ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC02bG93cGFu
LWJhY2tib25lLXJvdXRlcg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC10aHViZXJ0LTZsb3dwYW4tYmFja2JvbmUtcm91dGVyLTAzDQpEaWZmOiAgICAg
ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRodWJlcnQtNmxv
d3Bhbi1iYWNrYm9uZS1yb3V0ZXItMDMNCg0KQWJzdHJhY3Q6DQogICBTb21lIExMTiBzdWJuZXRz
IGFyZSBleHBlY3RlZCB0byBzY2FsZSB1cCB0byB0aGUgdGhvdXNhbmRzIG9mIG5vZGVzDQogICBh
bmQgaHVuZHJlZHMgb2Ygcm91dGVycy4gIFRoaXMgcGFwZXIgcHJvcG9zZXMgYW4gSVB2NiB2ZXJz
aW9uIG9mIHRoZQ0KICAgQmFja2JvbmUgUm91dGVyIGNvbmNlcHQgdGhhdCBlbmFibGVzIHN1Y2gg
YSBkZWdyZWUgb2Ygc2NhbGFiaWxpdHkNCiAgIHVzaW5nIGEgaGlnaCBzcGVlZCBuZXR3b3JrIGFz
IGEgYmFja2JvbmUgdG8gdGhlIHN1Ym5ldC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==

From bs7652@att.com  Tue Feb 26 10:06: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 A947B21F8A54; Tue, 26 Feb 2013 10:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.099
X-Spam-Level: 
X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxrMPFkOp46H; Tue, 26 Feb 2013 10:06:42 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1747821F886B; Tue, 26 Feb 2013 10:06:42 -0800 (PST)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 2b9fc215.53c06940.4288268.00-533.11847790.nbfkord-smmo07.seg.att.com (envelope-from );  Tue, 26 Feb 2013 18:06:42 +0000 (UTC)
X-MXL-Hash: 512cf9b24a1a8ee4-7de3abe4ef9469d00e2360082cd6e3c605c42217
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ea9fc215.0.4288249.00-496.11847726.nbfkord-smmo07.seg.att.com (envelope-from );  Tue, 26 Feb 2013 18:06:40 +0000 (UTC)
X-MXL-Hash: 512cf9b022ec96b0-34130cba56638fea4099aab599ab43fa530cfdd5
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1QI6c7i028467; Tue, 26 Feb 2013 13:06:38 -0500
Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1QI6Tnk028206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 13:06:33 -0500
Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Tue, 26 Feb 2013 13:02:16 -0500
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 13:02:05 -0500
From: "STARK, BARBARA H" 
To: "Liubing (Leo)" , "ipv6@ietf.org" ,  "v6ops@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiMZZ8g
Date: Tue, 26 Feb 2013 18:02:04 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130255AE0@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.174.97]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=Ob0v+GvY c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=SawaiHsxiTQA:10 a=mjfWdd7OfzUA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=qIRfQioSgDsA:10 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8]
X-AnalysisOut: [ a=IrhkzyA9JQ-jOgXrGygA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA]
X-AnalysisOut: [:10 a=peF9eE_zjQwA:10 a=_nbaV8ywFon7Z7Y3:21 a=l_Yy1O5uc6Fl]
X-AnalysisOut: [zOYM:21]
Cc: "renum@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, 26 Feb 2013 18:06:43 -0000

This is interesting. Thanks for doing these tests and submitting the result=
s.

When testing the switching behavior, I'm curious for the " SLAAC-only host =
receiving A=3D0&M=3D1 " case as to what you set the Preferred Lifetime to, =
when you set A=3D0. I'm guessing Preferred Lifetime > 0?
Since RFC 4862 states "A preferred address becomes deprecated when its pref=
erred lifetime expires", I would only have expected a host to deprecate a S=
LAAC-obtained address if the RA message set Preferred Lifetime to zero. It =
sounds like the case where the RA is changed from A=3D1 and Preferred Lifet=
ime > 0 to A=3D0 and Preferred Lifetime > 0 is ambiguous. I'm not quite sur=
e what the use case is for separating the A flag and Preferred Lifetime set=
tings. Did you also run the test by changing to A=3D0 and Preferred Lifetim=
e =3D 0? I would hope that there would be consistent behavior in that case.

For the "DHCPv6-only host receiving A=3D1&M=3D0" case, I'm curious as to wh=
ether you also tried sending a DHCPv6 Reconfigure message and forcing the h=
ost to release the DHCPv6-assigned address; and send A=3D1&M=3D0 in an RA d=
irectly after sending the Reconfigure. I'm not sure what the use case is fo=
r trying to force the release or deprecation of a DHCPv6 address via flags =
in an RA message. Once a host has a DHCPv6 address, I would have expected i=
ts subsequent behavior relating to that address and that DHCPv6 server to b=
e governed by RFC 3315. The Linux/MAC behavior appears consistent with what=
 I would have expected. The Windows 7 does not. I'm unaware of even a "hint=
" that suggests RA flags have a role in governing DHCPv6 behavior once RFC =
3315 is in play.
Barbara

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Liubing (Leo)
> Sent: Tuesday, February 26, 2013 2:14 AM
> To: ipv6@ietf.org; v6ops@ietf.org
> Cc: renum@ietf.org
> Subject: SLAAC/DHCPv6 addr-conf operational gaps
>=20
> Hi, 6man & v6ops
>=20
> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
>=20
> As we know there are several flags in RA messages regarding with the host
> configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
> and O (Otherconfig) flag.
> For some reason, the host behavior of interpreting the flags is ambiguous=
 in
> the standard (mainly RFC4862). I presented a draft discussing M flag beha=
vior
> in 6man @ietf84, and there were some feedbacks arguing the same issue.
> This draft analyzed all the three flags, and provided test result of curr=
ent
> implementations, it showed the behavior of different mainstream desktop
> OSes have varied. The ambiguous and variation might cause operational
> problems, such as renumbering (used to discuss in 6renum WG and been
> documented in the WG drafts), cold start problem, and management gaps
> .etc.
>=20
> Your review and comments would be appreciated very much.
>=20
> All the best,
> Bing
>=20
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Monday, February 25, 2013 5:52 PM
> > To: Liubing (Leo)
> > Cc: rbonica@juniper.net
> > Subject: New Version Notification for
> > draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >
> >
> > A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> > has been successfully submitted by Bing Liu and posted to the IETF
> > repository.
> >
> > Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
> > Revision:	 01
> > Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
> > Statement
> > Creation date:	 2013-02-25
> > Group:		 Individual Submission
> > Number of pages: 12
> > URL:
> > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-prob
> > lem-
> > 01.txt
> > Status:
> > http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
> > Htmlized:
> > http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
> > Diff:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-proble=
m
> > -01
> >
> > Abstract:
> >    This document analyzes the host behavior of DHCPv6/SLAAC interaction
> >    issue. It reviews the standard definition of the host behaviors and
> >    provides the test results of current mainstream implementations. Som=
e
> >    potential operational gaps of the interaction are also described.
> >
> >
> >
> >
> > The IETF Secretariat
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From markzzzsmith@yahoo.com.au  Tue Feb 26 12:34: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 60C6F21F891D for ; Tue, 26 Feb 2013 12:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.337
X-Spam-Level: 
X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=0.162,  BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFBPhrO+15AJ for ; Tue, 26 Feb 2013 12:34:34 -0800 (PST)
Received: from nm21-vm1.bullet.mail.bf1.yahoo.com (nm21-vm1.bullet.mail.bf1.yahoo.com [98.139.213.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53721F8871 for ; Tue, 26 Feb 2013 12:34:34 -0800 (PST)
Received: from [98.139.215.143] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 26 Feb 2013 20:34:33 -0000
Received: from [98.139.212.205] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 26 Feb 2013 20:34:33 -0000
Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 26 Feb 2013 20:34:33 -0000
X-Yahoo-Newman-Property: ymail-5
X-Yahoo-Newman-Id: 634789.95864.bm@omp1014.mail.bf1.yahoo.com
Received: (qmail 79426 invoked by uid 60001); 26 Feb 2013 20:34:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361910873; bh=y6gH6gNPjZdYi+d8xQFSX48JcT3R04YZd4dbpDBnytA=; 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=19sfM13tdRNw/DhE3RJeK02PIKUvHNIHfTZF/yUCX3hpbNle19/n440hJk8C6u7oiJZgbLFAPZBZ/wrKSD1C0uoCFdudnPkuEtLilxgxz/wDTfLUoGB3ChJHWHcR1ObPZ7DrUsJMsuDoBViWmUaTQCN63P1N7s4tPMyr4I+zDDI=
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=LDmFVUuiRsA0/a3S4HrrQryt/SPb9Ac/3cmtGq1WXO3kj+9o2lR9NeMsY9Bs90UY+IjcdcZNc5FXNqC/7ws6vCN0HX6yAM1TUpxaaliXHntTnJnVaRXOFrBWuaQHzXDyIlyNDVfJ4hol9EtCiz3p/KHwU9XW1qE7v1EQ+sGZZBw=;
X-YMail-OSG: BO43t_QVM1mM5KX2avIH5Y.WJ3tCS9ay0Zms5nY0c7aAncp xoe12iQHGKXLAJx4WEzAFX6N4P2pbAN7scj2lCGh1faPZN8Bn1PUSG8.AD78 CzZuKpkthHoXuPKyu3bL8J2kgQEoqkjgtVgCAwveeSi60u7sVk5IieO0nFce Nb2ND3oMDaweJnH.iPCbse8xRn_V.Yn9ZI9MJTSGBNXX3_PpJIAlvAQzssM5 q0vEHxwsMsh.lLoJypL4IL.4Wg9gBgckZXjKtadO9mr58pIiJMSKL89JNokT cySQmyjgDwFeHXSeFudiCm3YcB6Exl1TXbENfncoKBk52VpzPib1taSuAu7t DW3l91VDkX946fOl5fNzzPHzvHFXkM0AEurIAccKbyN.TU8..3wYuf9fOhMi oR6pRnZsfHgFqTyYWcfI4WPkdPbv4Vfm1T_X7lZFmhkJbgCTTGL14I0uBSLW Vb6np.IpknccnLfnv.ywM6C3W2JH0IvebrUn8VdU9oo8XKgeaCcxbmRbZoSo GQd6o7etlWfme8DmQkhp7A23HCooC
Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Tue, 26 Feb 2013 12:34:33 PST
X-Rocket-MIMEInfo: 001.001, SGksCgpJJ3ZlIGhhZCBhIHF1aWNrIHJlYWQgdGhvdWdoLCBJJ2xsIHRyeSB0byBkbyBhIHRob3JvdWdoIG9uZSBpbiB0aGUgbmV4dCB3ZWVrIG9yIHNvLgoKVGhhbmtzIGZvciB3cml0aW5nIHRoaXMsIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCBkb2luZyBzb21ldGhpbmcgc2ltaWxhciBvdmVyIHRoZSBsYXN0IGZldyBtb250aHMgc2luY2UsIElJUkMsIEkgaGVhcmQgYWJvdXQgV2luZG93cyA3IGludmFsaWRhdGluZyBJUHY2IGFkZHJlc3NlcyBsZWFybmVkIHZpYSBESENQdjYgd2hlbiBTTEFBQyB3YXMgZW4BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
Message-ID: <1361910873.78397.YahooMailNeo@web142503.mail.bf1.yahoo.com>
Date: Tue, 26 Feb 2013 12:34:33 -0800 (PST)
From: Mark Smith 
Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
To: "Liubing \(Leo\)" , "ipv6@ietf.org" , "v6ops@ietf.org" 
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "renum@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: Tue, 26 Feb 2013 20:34:37 -0000

Hi,=0A=0AI've had a quick read though, I'll try to do a thorough one in the=
 next week or so.=0A=0AThanks for writing this, I've been thinking about do=
ing something similar over the last few months since, IIRC, I heard about W=
indows 7 invalidating IPv6 addresses learned via DHCPv6 when SLAAC was enab=
led and DHCPv6 was disabled on a link.=0A=0AA few thoughts I've had which m=
ay be useful -=0A=0AFirstly, I came to realise that the mistake being made =
by Windows 7 was the assumption that the aging of the assigned IPv6 address=
es was tightly coupled to the DHCPv6 session state, meaning that if DHCPv6 =
went away, so would the assigned addresses. This is generally the way DHCPv=
4 has worked. However, in IPv6/DHCPv6, it seems the address lifetime values=
 in the IA_NA are not coupled to the T1 and T2 times, so if DHCPv6 goes awa=
y (perhaps because the M bit was switched off in a latter RA), the configur=
ed IPv6 addresses should be left to age out as per their preferred and vali=
d lifetimes.=0A=0AThe other thing I noticed was that the M RA flag and the =
PIO A flags aren't mutually exclusive - I couldn't find any text in RFC4861=
 that says if the M bit is switched on, the PIO A flags must be switched of=
f and vice-versa. So that suggests that the DHCPv6 and SLAAC can co-exist, =
and I think that is quite reasonable if you're transitioning a link from DH=
CPv6 to SLAAC address configuration or vice-versa.=0A=0AThinking about it m=
ore, I came realise that DHCPv6 and SLAAC are _address configuration_ metho=
ds, but are not address aging methods - IPv6 takes care of address aging vi=
a it's preferred and valid aging mechanisms, regardless of the address conf=
iguration method. Static assignment is also just an address configuration m=
ethod, although typically the addresses don't age out, but only because the=
y're normally set to infinity. Perhaps in the future there might be other a=
ddress configuration methods.=0A=0AI didn't seem to be able to find an RFC =
that made it clear that address configuration and address aging are quite s=
eparate, so perhaps this ID could be the one.=0A=0ARegarding this text:=0A=
=0A'For the host behavior, there is an explicit rule in the SLAAC specifica=
tion [RFC4862]: "If the Autonomous flag is not set, silently ignore the Pre=
fix Information option."'=0A=0AI think RFC5942, "IPv6 Subnet Model: The Rel=
ationship between Links and Subnet Prefixes." updates that advice, as the P=
IO option is used to indicates which prefix/range of addresses are on-link,=
 via the PIO O bit, even if the PIO A bit is switched off.=0A=0ABest regard=
s,=0AMark.=0A=0A>________________________________=0A> From: Liubing (Leo) <=
leo.liubing@huawei.com>=0A>To: "ipv6@ietf.org" ; "v6ops@ietf=
.org"  =0A>Cc: "renum@ietf.org"  =0A>Sent: =
Tuesday, 26 February 2013 6:14 PM=0A>Subject: SLAAC/DHCPv6 addr-conf operat=
ional gaps=0A> =0A>Hi, 6man & v6ops=0A>=0A>We submitted a new draft to disc=
uss the SLAAC/DHCPv6 interaction gaps.=0A>=0A>As we know there are several =
flags in RA messages regarding with the host configuration behavior, which =
are A (Autonomous) flag, M (Managed) flag, and O (Otherconfig) flag.=0A>For=
 some reason, the host behavior of interpreting the flags is ambiguous in t=
he standard (mainly RFC4862). I presented a draft discussing M flag behavio=
r in 6man @ietf84, and there were some feedbacks arguing the same issue. Th=
is draft analyzed all the three flags, and provided test result of current =
implementations, it showed the behavior of different mainstream desktop OSe=
s have varied. The ambiguous and variation might cause operational problems=
, such as renumbering (used to discuss in 6renum WG and been documented in =
the WG drafts), cold start problem, and management gaps .etc.=0A>=0A>Your r=
eview and comments would be appreciated very much. =0A>=0A>All the best,=0A=
>Bing=0A>=0A>> -----Original Message-----=0A>> From: internet-drafts@ietf.o=
rg [mailto:internet-drafts@ietf.org]=0A>> Sent: Monday, February 25, 2013 5=
:52 PM=0A>> To: Liubing (Leo)=0A>> Cc: rbonica@juniper.net=0A>> Subject: Ne=
w Version Notification for=0A>> draft-liu-bonica-dhcpv6-slaac-problem-01.tx=
t=0A>> =0A>> =0A>> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-prob=
lem-01.txt=0A>> has been successfully submitted by Bing Liu and posted to t=
he=0A>> IETF repository.=0A>> =0A>> Filename:=A0=A0=A0=A0=A0draft-liu-bonic=
a-dhcpv6-slaac-problem=0A>> Revision:=A0=A0=A0=A0=A001=0A>> Title:=A0=A0=A0=
 =A0=A0=A0=A0=A0DHCPv6/SLAAC Address Configuration Interaction Problem=0A>>=
 Statement=0A>> Creation date:=A0=A0=A0=A0=A02013-02-25=0A>> Group:=A0=A0=
=A0 =A0=A0=A0=A0=A0Individual Submission=0A>> Number of pages: 12=0A>> URL:=
=0A>> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-pro=
blem-=0A>> 01.txt=0A>> Status:=0A>> http://datatracker.ietf.org/doc/draft-l=
iu-bonica-dhcpv6-slaac-problem=0A>> Htmlized:=0A>> http://tools.ietf.org/ht=
ml/draft-liu-bonica-dhcpv6-slaac-problem-01=0A>> Diff:=0A>> http://www.ietf=
.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-problem-01=0A>> =0A>> Abs=
tract:=0A>>=A0 =A0 This document analyzes the host behavior of DHCPv6/SLAAC=
 interaction=0A>>=A0 =A0 issue. It reviews the standard definition of the h=
ost behaviors and=0A>>=A0 =A0 provides the test results of current mainstre=
am implementations. Some=0A>>=A0 =A0 potential operational gaps of the inte=
raction are also described.=0A>> =0A>> =0A>> =0A>> =0A>> The IETF Secretari=
at=0A>=0A>-----------------------------------------------------------------=
---=0A>IETF IPv6 working group mailing list=0A>ipv6@ietf.org=0A>Administrat=
ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A>---------------=
-----------------------------------------------------=0A>=0A>=0A>

From kauer@biplane.com.au  Tue Feb 26 13: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 38A0821F8644 for ; Tue, 26 Feb 2013 13:20:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level: 
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRpo7vMT7fOi for ; Tue, 26 Feb 2013 13:20:16 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 358EF21F8551 for ; Tue, 26 Feb 2013 13:20:14 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBANclLVGWZX+7/2dsb2JhbAANOMFsCYEWgxIBAQEEgQkLGC5XGbRsk0COTE+DQAOINJlgiDA
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 27 Feb 2013 07:50:12 +1030
Message-ID: <1361913610.24824.138.camel@karl>
Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
From: Karl Auer 
To: ipv6@ietf.org
Date: Wed, 27 Feb 2013 08:20:10 +1100
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.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, 26 Feb 2013 21:20:20 -0000

On Tue, 2013-02-26 at 07:14 +0000, Liubing (Leo) wrote:
> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.

Some time ago I wrote quite a long reply on this list about it. I've
changed my mind on a few points, and here's my current thinking, for
what it's worth. I think an update to the relevant RFCs (4861?) should
be written that makes the following unambiguous statements about the
flags.

1: The O and M flags are independent of each other.

The O flag implies nothing about address configuration, and the M flag
implies nothing about whether ancillary information is available.
However, DHCPv6 itself will supply ancillary information along with
address information, so a host doing stateful DHCPv6 SHOULD accept and
use the information returned with addresses rather than do additional,
separate stateless DHCPv6 queries. If a host accepts the ancillary
information in response to a stateful DHCPv6 query, then the valid and
preferred lifetimes of the ancillary data MUST be set to those of the
received address(es).

2: A valid RA can have both the O and the M flags set.

3: The M flag, if set, means that a DHCPv6 service is available for
stateful automatic address configuration by the hosts on the link. The
presence of a set M flag makes no statement about whether hosts should
use the service. The absence of a set M flag makes no statement about
whether a DHCPv6 service is available.

A host SHOULD perform stateful DHCPv6 address configuration if it sees a
set M flag in an RA. However, it SHOULD NOT do so if it already has one
or more addresses on the receiving interface that were acquired via
stateful DHCPv6.

A host MAY attempt to obtain addresses via DHCPv6 without seeing an RA
at all. Rationale: The host may be in a network containing a DHCPv6
server, but no router.

A host MAY attempt to obtain addresses via DHCPv6 even if it sees an RA
with no M flag set. Rationale: There may be multiple routers on a link,
not all of which are advertising an M flag.

4: The O flag, if set, means that a stateless DHCPv6 service is
available. The presence of a set O flag makes no statement about whether
hosts should use the service. The absence of a set O flag makes no
statement about whether a DHCPv6 service is available.

A host SHOULD perform a stateless DHCPv6 query when it sees a set O flag
in an RA. However, it SHOULD NOT do so if it has already acquired
information via stateless DHCPv6 and the preferred lifetime of that
information has not yet expired.

A host MAY attempt stateless DHCPv6 without seeing an RA at all.
Rationale: The host may be in a network containing a DHCPv6 server, but
no router.

A host MAY attempt stateless DHCPv6 even if it sees an RA with no O flag
set. Rationale: There may be multiple routers on a link, not all of
which are advertising an O flag.

5: Once configured, a DHCPv6 address SHOULD NOT be deconfigured until
its valid lifetime has expired.

Also, an address MUST NOT be deconfigured solely because an RA is seen
with no set M flag. However, a host MAY reduce the valid lifetime of an
address to two hours if an RA is seen with no set M flag. Rationale:
There may be multiple routers in a network, not all of which are
advertising a set M flag. Deconfiguring an address based solely on an RA
with no set M flag could result in an address "flap", where one RA
causes the address to be configured, the next causes it to be
deconfigured. Furthermore, the "contract" between the DHCPv6 server and
the host has stipulated that the host may use the address for the extent
of the stated valid lifetime. Reducing the valid lifetime to no less
than two hours prevents a trivial denial of service attack while
permitting an administrator to renumber more quickly if necessary.

6: Information obtained via stateless DHCPv6 SHOULD be considered valid
until the valid lifetime of the address(es) to which it pertains expires
OR the valid lifetime of the ancillary information expires OR until
another successful stateless DHCP query is performed for the relevant
address(es), whichever comes first.

Also, information obtained via stateless DHCPv6 MUST NOT be discarded
solely because an RA is seen with no set O flag. Rationale: There may be
multiple routers in a network, not all of which are advertising a set O
flag. Discarding information based on an RA with no set O flag could
result in the information "flapping", where one RA causes the
information to be obtained, the next causes it to be discarded.
Furthermore, the "contract" between the DHCPv6 server and the host has
stipulated that the host may use the information for the extent of the
stated valid lifetime.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

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 leo.liubing@huawei.com  Tue Feb 26 19:07: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 ED03E21F8673; Tue, 26 Feb 2013 19:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.982
X-Spam-Level: 
X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQuSdv6j77QQ; Tue, 26 Feb 2013 19:07:10 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1A31121F8602; Tue, 26 Feb 2013 19:07:09 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV20200; Wed, 27 Feb 2013 03:07:08 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:06:13 +0000
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:07:07 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 11:07:02 +0800
From: "Liubing (Leo)" 
To: Victor Kuarsingh , "arturo.servin@gmail.com" , "ipv6@ietf.org" , "v6ops@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiLnE0AgAFog0A=
Date: Wed, 27 Feb 2013 03:07:02 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC74E@nkgeml506-mbx.china.huawei.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 27 Feb 2013 03:07:12 -0000

Hi, Victor & Arturo

Thanks for the comments.
We do plan to write a draft of subsequence solution. But as Victor said, st=
ep 1 is to see if the groups agree there are problems. So hope more people =
could feed back on this.

Many thanks.

B.R.
Bing

> -----Original Message-----
> From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]
> Sent: Tuesday, February 26, 2013 9:28 PM
> To: Liubing (Leo); ipv6@ietf.org; v6ops@ietf.org
> Cc: renum@ietf.org
> Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
>=20
> Bing,
>=20
> I as able to review the draft and agree this needs to be documented and
> discussed.  I have had many frustrating nights dealing with my multiple
> OSs at home and figuring out what behaviour I was trying to expect when
> changing the upstream router's settings (M/O/A).
>=20
> I think the problem space discussion within the draft should be enough to
> have a preliminary discussion in the WG.  I know there have been issues i=
n
> the past with various opinions on what the M/O bits (for example) should
> or should not be used for - or how authoritative they should be.
>=20
> If the groups can agree that there is in fact a problem, then I would
> agree with Arturo that we can have a constructive follow-up
> draft/discussion on the corrective action.
>=20
> Lets get past step 1 and agree there is an issue (or not); then go down
> the more sensitive path of agreeing to the corrective action.
>=20
> Thanks for putting this together.
>=20
> Regards,
>=20
> Victor Kuarsingh
>=20
>=20
>=20
> On 2013-02-26 2:14 AM, "Liubing (Leo)"  wrote:
>=20
> >Hi, 6man & v6ops
> >
> >We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
> >
> >As we know there are several flags in RA messages regarding with the hos=
t
> >configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
> >and O (Otherconfig) flag.
> >For some reason, the host behavior of interpreting the flags is ambiguou=
s
> >in the standard (mainly RFC4862). I presented a draft discussing M flag
> >behavior in 6man @ietf84, and there were some feedbacks arguing the
> same
> >issue. This draft analyzed all the three flags, and provided test result
> >of current implementations, it showed the behavior of different
> >mainstream desktop OSes have varied. The ambiguous and variation might
> >cause operational problems, such as renumbering (used to discuss in
> >6renum WG and been documented in the WG drafts), cold start problem,
> and
> >management gaps .etc.
> >
> >Your review and comments would be appreciated very much.
> >
> >All the best,
> >Bing
> >
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Monday, February 25, 2013 5:52 PM
> >> To: Liubing (Leo)
> >> Cc: rbonica@juniper.net
> >> Subject: New Version Notification for
> >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >>
> >>
> >> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >> has been successfully submitted by Bing Liu and posted to the
> >> IETF repository.
> >>
> >> Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
> >> Revision:	 01
> >> Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
> >> Statement
> >> Creation date:	 2013-02-25
> >> Group:		 Individual Submission
> >> Number of pages: 12
> >> URL:
> >>
> >>http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-probl=
e
> m
> >>-
> >> 01.txt
> >> Status:
> >> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
> >> Htmlized:
> >> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
> >> Diff:
> >>
> >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-proble=
m-0
> 1
> >>
> >> Abstract:
> >>    This document analyzes the host behavior of DHCPv6/SLAAC
> interaction
> >>    issue. It reviews the standard definition of the host behaviors and
> >>    provides the test results of current mainstream implementations.
> Some
> >>    potential operational gaps of the interaction are also described.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >
> >--------------------------------------------------------------------
> >IETF IPv6 working group mailing list
> >ipv6@ietf.org
> >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >--------------------------------------------------------------------
>=20


From jiangsheng@huawei.com  Tue Feb 26 19:36: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 9F40D21F85CB; Tue, 26 Feb 2013 19:36:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.111
X-Spam-Level: 
X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DA59Rs9cBrw; Tue, 26 Feb 2013 19:36:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1486E21F863C; Tue, 26 Feb 2013 19:36:40 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV21817; Wed, 27 Feb 2013 03:36:39 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:36:34 +0000
Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:36:39 +0000
Received: from szxeml545-mbx.china.huawei.com ([169.254.1.45]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 11:36:31 +0800
From: Sheng Jiang 
To: "Liubing (Leo)" , "ipv6@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiNDEUQ
Date: Wed, 27 Feb 2013 03:36:30 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A00E022@szxeml545-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 27 Feb 2013 03:36:42 -0000

VGhpcyBoYXMgYmVlbiBhIGhpc3RvcmljIGlzc3VlLiBBbHRob3VnaCB0aGVyZSB3YXMgZGlzY3Vz
c2lvbnMgc2V2ZXJhbCB0aW1lcywgdGhlIHNwZWNpZmljYXRpb24gc3RpbGwgcmVtYWluIGFtYmln
dW91cy4gVGhlIGRpZmZlcmVuY2VzIGluIE9TIGltcGxlbWVudGF0aW9ucyBhcmUgZ29vZCBwcm9v
ZiB0aGF0IHdlIG5lZWQgdG8gZG8gc29tZXRoaW5nIGluIElFVEYuDQoNClRoaXMgZG9jdW1lbnQg
aGFzIHdlbGwgZGVzY3JpYmVkIHRoZSBjdXJyZW50IHN0YW5kYXJkIHN0YXR1cyBhbmQgcmVhbGl0
eSBvcGVyYXRpb25hbCBpc3N1ZXMuIEhvd2V2ZXIsIGZvciBtZSwgdGhpcyBkb2N1bWVudCBmYWls
cyB0byBzdWdnZXN0IHdoYXQgd2UgbWF5IGRvIHRvIGZpeCB0aGlzIGlzc3VlLCBuZWl0aGVyIGlu
IHRoZSBnYXAgc2VjdGlvbiBvciBhcyBjb25jbHVzaW9uLiBJdCBpcyBjbGVhciB0aGF0IHBhcnQg
b2YgUkZDNDg2MiBuZWVkcyB0byBiZSB1cGRhdGVkIHRvIG1ha2UgdGhlIGNvbmZpZ3VyYXRpb24g
YmVoYXZpb3IgY2xlYXIgYW5kIGNvbnNpc3RlbnQuIEZvciB0aGF0LCB0aGlzIGRvY3VtZW50IGZh
aWxzIHRvIGdpdmUgYSBmZWFzaWJsZSBwcm9wb3NhbC4gTWF5YmUsIHRoZSBhdXRob3JzIGhhcyBz
YXZlZCB0aGF0IGZvciBhbm90aGVyIGZvbGxvdyB1cCBzdGFuZGFyZCB0cmFjayBkb2N1bWVudC4N
Cg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj5Gcm9tOiByZW51bS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cmVudW0tYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmDQo+T2YgTGl1YmluZyAoTGVvKQ0KPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1
YXJ5IDI2LCAyMDEzIDM6MTQgUE0NCj5UbzogaXB2NkBpZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcN
Cj5DYzogcmVudW1AaWV0Zi5vcmcNCj5TdWJqZWN0OiBbcmVudW1dIFNMQUFDL0RIQ1B2NiBhZGRy
LWNvbmYgb3BlcmF0aW9uYWwgZ2Fwcw0KPg0KPkhpLCA2bWFuICYgdjZvcHMNCj4NCj5XZSBzdWJt
aXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyB0aGUgU0xBQUMvREhDUHY2IGludGVyYWN0aW9u
IGdhcHMuDQo+DQo+QXMgd2Uga25vdyB0aGVyZSBhcmUgc2V2ZXJhbCBmbGFncyBpbiBSQSBtZXNz
YWdlcyByZWdhcmRpbmcgd2l0aCB0aGUgaG9zdA0KPmNvbmZpZ3VyYXRpb24gYmVoYXZpb3IsIHdo
aWNoIGFyZSBBIChBdXRvbm9tb3VzKSBmbGFnLCBNIChNYW5hZ2VkKSBmbGFnLA0KPmFuZCBPIChP
dGhlcmNvbmZpZykgZmxhZy4NCj5Gb3Igc29tZSByZWFzb24sIHRoZSBob3N0IGJlaGF2aW9yIG9m
IGludGVycHJldGluZyB0aGUgZmxhZ3MgaXMgYW1iaWd1b3VzIGluDQo+dGhlIHN0YW5kYXJkICht
YWlubHkgUkZDNDg2MikuIEkgcHJlc2VudGVkIGEgZHJhZnQgZGlzY3Vzc2luZyBNIGZsYWcgYmVo
YXZpb3INCj5pbiA2bWFuIEBpZXRmODQsIGFuZCB0aGVyZSB3ZXJlIHNvbWUgZmVlZGJhY2tzIGFy
Z3VpbmcgdGhlIHNhbWUgaXNzdWUuDQo+VGhpcyBkcmFmdCBhbmFseXplZCBhbGwgdGhlIHRocmVl
IGZsYWdzLCBhbmQgcHJvdmlkZWQgdGVzdCByZXN1bHQgb2YgY3VycmVudA0KPmltcGxlbWVudGF0
aW9ucywgaXQgc2hvd2VkIHRoZSBiZWhhdmlvciBvZiBkaWZmZXJlbnQgbWFpbnN0cmVhbSBkZXNr
dG9wDQo+T1NlcyBoYXZlIHZhcmllZC4gVGhlIGFtYmlndW91cyBhbmQgdmFyaWF0aW9uIG1pZ2h0
IGNhdXNlIG9wZXJhdGlvbmFsDQo+cHJvYmxlbXMsIHN1Y2ggYXMgcmVudW1iZXJpbmcgKHVzZWQg
dG8gZGlzY3VzcyBpbiA2cmVudW0gV0cgYW5kIGJlZW4NCj5kb2N1bWVudGVkIGluIHRoZSBXRyBk
cmFmdHMpLCBjb2xkIHN0YXJ0IHByb2JsZW0sIGFuZCBtYW5hZ2VtZW50DQo+Z2FwcyAuZXRjLg0K
Pg0KPllvdXIgcmV2aWV3IGFuZCBjb21tZW50cyB3b3VsZCBiZSBhcHByZWNpYXRlZCB2ZXJ5IG11
Y2guDQo+DQo+QWxsIHRoZSBiZXN0LA0KPkJpbmcNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l
dC1kcmFmdHNAaWV0Zi5vcmddDQo+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDU6
NTIgUE0NCj4+IFRvOiBMaXViaW5nIChMZW8pDQo+PiBDYzogcmJvbmljYUBqdW5pcGVyLm5ldA0K
Pj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4gZHJhZnQtbGl1LWJv
bmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wMS50eHQNCj4+DQo+Pg0KPj4gQSBuZXcgdmVyc2lv
biBvZiBJLUQsIGRyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDEudHh0DQo+
PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQg
dG8gdGhlDQo+PiBJRVRGIHJlcG9zaXRvcnkuDQo+Pg0KPj4gRmlsZW5hbWU6CSBkcmFmdC1saXUt
Ym9uaWNhLWRoY3B2Ni1zbGFhYy1wcm9ibGVtDQo+PiBSZXZpc2lvbjoJIDAxDQo+PiBUaXRsZToJ
CSBESENQdjYvU0xBQUMgQWRkcmVzcyBDb25maWd1cmF0aW9uIEludGVyYWN0aW9uIFByb2JsZW0N
Cj4+IFN0YXRlbWVudA0KPj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDItMjUNCj4+IEdyb3VwOgkJ
IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gTnVtYmVyIG9mIHBhZ2VzOiAxMg0KPj4gVVJMOg0K
Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LWJvbmljYS1k
aGNwdjYtc2xhYWMtcHJvYmxlbS0NCj4+IDAxLnR4dA0KPj4gU3RhdHVzOg0KPj4gaHR0cDovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtYm9uaWNhLWRoY3B2Ni1zbGFhYy1wcm9i
bGVtDQo+PiBIdG1saXplZDoNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxp
dS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDENCj4+IERpZmY6DQo+PiBodHRwOi8vd3d3
LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saXUtYm9uaWNhLWRoY3B2Ni1zbGFhYy1wcm9i
bGVtLTAxDQo+Pg0KPj4gQWJzdHJhY3Q6DQo+PiAgICBUaGlzIGRvY3VtZW50IGFuYWx5emVzIHRo
ZSBob3N0IGJlaGF2aW9yIG9mIERIQ1B2Ni9TTEFBQyBpbnRlcmFjdGlvbg0KPj4gICAgaXNzdWUu
IEl0IHJldmlld3MgdGhlIHN0YW5kYXJkIGRlZmluaXRpb24gb2YgdGhlIGhvc3QgYmVoYXZpb3Jz
IGFuZA0KPj4gICAgcHJvdmlkZXMgdGhlIHRlc3QgcmVzdWx0cyBvZiBjdXJyZW50IG1haW5zdHJl
YW0gaW1wbGVtZW50YXRpb25zLiBTb21lDQo+PiAgICBwb3RlbnRpYWwgb3BlcmF0aW9uYWwgZ2Fw
cyBvZiB0aGUgaW50ZXJhY3Rpb24gYXJlIGFsc28gZGVzY3JpYmVkLg0KPj4NCj4+DQo+Pg0KPj4N
Cj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj5yZW51bSBtYWlsaW5nIGxpc3QNCj5yZW51bUBpZXRmLm9y
Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmVudW0NCg==

From leo.liubing@huawei.com  Tue Feb 26 20:01: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 7831B21F86D5; Tue, 26 Feb 2013 20:01:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.004
X-Spam-Level: 
X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b8bfnf6D-ST; Tue, 26 Feb 2013 20:01:31 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 89ECD21F86A8; Tue, 26 Feb 2013 20:01:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV23270; Wed, 27 Feb 2013 04:01:28 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 04:00:33 +0000
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 04:01:27 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 12:01:20 +0800
From: "Liubing (Leo)" 
To: "STARK, BARBARA H" , "ipv6@ietf.org" , "v6ops@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiMZZ8ggACi1xA=
Date: Wed, 27 Feb 2013 04:01:19 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC7D7@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <2D09D61DDFA73D4C884805CC7865E61130255AE0@GAALPA1MSGUSR9L.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130255AE0@GAALPA1MSGUSR9L.ITServices.sbc.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 27 Feb 2013 04:01:32 -0000

Hi, Barbara

Thanks for your comments. Please see replies inline.

> -----Original Message-----
> From: STARK, BARBARA H [mailto:bs7652@att.com]
> Sent: Wednesday, February 27, 2013 2:02 AM
> To: Liubing (Leo); ipv6@ietf.org; v6ops@ietf.org
> Cc: renum@ietf.org
> Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
>=20
> This is interesting. Thanks for doing these tests and submitting the resu=
lts.
>=20
> When testing the switching behavior, I'm curious for the " SLAAC-only hos=
t
> receiving A=3D0&M=3D1 " case as to what you set the Preferred Lifetime to=
,
> when you set A=3D0. I'm guessing Preferred Lifetime > 0?

[Bing] Yes, we just leave the Preferred Lifetime as default, it should be >=
 0

> Since RFC 4862 states "A preferred address becomes deprecated when its
> preferred lifetime expires", I would only have expected a host to depreca=
te a
> SLAAC-obtained address if the RA message set Preferred Lifetime to zero. =
It
> sounds like the case where the RA is changed from A=3D1 and Preferred
> Lifetime > 0 to A=3D0 and Preferred Lifetime > 0 is ambiguous.=20

[Bing] As I learned from RFC4862, it is ambiguous.

>I'm not quite
> sure what the use case is for separating the A flag and Preferred Lifetim=
e
> settings. Did you also run the test by changing to A=3D0 and Preferred Li=
fetime
> =3D 0? I would hope that there would be consistent behavior in that case.

[Bing] We haven't run that, but could do it later. Thanks for the remind.
For separating A flag and Preferred Lifetime, it is just the concept of sep=
arating "_address configuration_ methods" and "address aging" raised by Mar=
k Smith in another mail on this thread. I think it is a good point of view,=
 and if we can initiate subsequence revision of host behavior, we should co=
nsider it.

> For the "DHCPv6-only host receiving A=3D1&M=3D0" case, I'm curious as to
> whether you also tried sending a DHCPv6 Reconfigure message and forcing
> the host to release the DHCPv6-assigned address; and send A=3D1&M=3D0 in =
an
> RA directly after sending the Reconfigure. I'm not sure what the use case=
 is
> for trying to force the release or deprecation of a DHCPv6 address via fl=
ags
> in an RA message. Once a host has a DHCPv6 address, I would have expected
> its subsequent behavior relating to that address and that DHCPv6 server t=
o
> be governed by RFC 3315.=20

[Bing] We haven't tried this, could do later. But we used to talk about it =
in 6renum WG. DHCPv6-Reconfiguration is considered not suitable for bulk us=
age, since it is stateful and unicast, might cause heavy load for the DHCPv=
6 server, this has been documented in [draft-ietf-6renum-gap-analysis]. Mor=
eover, it is more difficult for administration to simultaneously operate DH=
CPv6 and ND together. =20

The Linux/MAC behavior appears consistent with
> what I would have expected. The Windows 7 does not. I'm unaware of even
> a "hint" that suggests RA flags have a role in governing DHCPv6 behavior
> once RFC 3315 is in play.

[Bing] That is just the ambiguous of the RA flags behavior. IMHO, we need t=
o specify it clear in the standard. Whether the RA flags should govern DHCP=
v6 behavior or not, we can discuss it in the next step if the groups agree =
we should deal with the ambiguous problem firstly.

B.R.
Bing


> Barbara
>=20
> > -----Original Message-----
> > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> > Liubing (Leo)
> > Sent: Tuesday, February 26, 2013 2:14 AM
> > To: ipv6@ietf.org; v6ops@ietf.org
> > Cc: renum@ietf.org
> > Subject: SLAAC/DHCPv6 addr-conf operational gaps
> >
> > Hi, 6man & v6ops
> >
> > We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
> >
> > As we know there are several flags in RA messages regarding with the ho=
st
> > configuration behavior, which are A (Autonomous) flag, M (Managed) flag=
,
> > and O (Otherconfig) flag.
> > For some reason, the host behavior of interpreting the flags is ambiguo=
us
> in
> > the standard (mainly RFC4862). I presented a draft discussing M flag
> behavior
> > in 6man @ietf84, and there were some feedbacks arguing the same issue.
> > This draft analyzed all the three flags, and provided test result of cu=
rrent
> > implementations, it showed the behavior of different mainstream desktop
> > OSes have varied. The ambiguous and variation might cause operational
> > problems, such as renumbering (used to discuss in 6renum WG and been
> > documented in the WG drafts), cold start problem, and management gaps
> > .etc.
> >
> > Your review and comments would be appreciated very much.
> >
> > All the best,
> > Bing
> >
> > > -----Original Message-----
> > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > Sent: Monday, February 25, 2013 5:52 PM
> > > To: Liubing (Leo)
> > > Cc: rbonica@juniper.net
> > > Subject: New Version Notification for
> > > draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> > >
> > >
> > > A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> > > has been successfully submitted by Bing Liu and posted to the IETF
> > > repository.
> > >
> > > Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
> > > Revision:	 01
> > > Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
> > > Statement
> > > Creation date:	 2013-02-25
> > > Group:		 Individual Submission
> > > Number of pages: 12
> > > URL:
> > > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-pro=
b
> > > lem-
> > > 01.txt
> > > Status:
> > > http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
> > > Htmlized:
> > > http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
> > > Diff:
> > > http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-prob=
lem
> > > -01
> > >
> > > Abstract:
> > >    This document analyzes the host behavior of DHCPv6/SLAAC
> interaction
> > >    issue. It reviews the standard definition of the host behaviors an=
d
> > >    provides the test results of current mainstream implementations.
> Some
> > >    potential operational gaps of the interaction are also described.
> > >
> > >
> > >
> > >
> > > The IETF Secretariat
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

From leo.liubing@huawei.com  Tue Feb 26 21: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 E2B0721F86E3; Tue, 26 Feb 2013 21:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.004
X-Spam-Level: 
X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj8B2Y-xL30p; Tue, 26 Feb 2013 21:56:18 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7821F85D7; Tue, 26 Feb 2013 21:56:15 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV29444; Wed, 27 Feb 2013 05:56:13 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 05:55:17 +0000
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 05:56:12 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 13:56:04 +0800
From: "Liubing (Leo)" 
To: Mark Smith , "ipv6@ietf.org" , "v6ops@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiME2CAgAEfplA=
Date: Wed, 27 Feb 2013 05:56:03 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC83E@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <1361910873.78397.YahooMailNeo@web142503.mail.bf1.yahoo.com>
In-Reply-To: <1361910873.78397.YahooMailNeo@web142503.mail.bf1.yahoo.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 27 Feb 2013 05:56:23 -0000

Hi, Mark

Thanks for your comment.=20
I like the concept of separating "_address configuration_ methods" and "add=
ress aging methods", if we could initiate the subsequence work, it should b=
e considered.

All the best
Bing

> -----Original Message-----
> From: Mark Smith [mailto:markzzzsmith@yahoo.com.au]
> Sent: Wednesday, February 27, 2013 4:35 AM
> To: Liubing (Leo); ipv6@ietf.org; v6ops@ietf.org
> Cc: renum@ietf.org
> Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
>=20
> Hi,
>=20
> I've had a quick read though, I'll try to do a thorough one in the next w=
eek or
> so.
>=20
> Thanks for writing this, I've been thinking about doing something similar=
 over
> the last few months since, IIRC, I heard about Windows 7 invalidating IPv=
6
> addresses learned via DHCPv6 when SLAAC was enabled and DHCPv6 was
> disabled on a link.
>=20
> A few thoughts I've had which may be useful -
>=20
> Firstly, I came to realise that the mistake being made by Windows 7 was t=
he
> assumption that the aging of the assigned IPv6 addresses was tightly coup=
led
> to the DHCPv6 session state, meaning that if DHCPv6 went away, so would
> the assigned addresses. This is generally the way DHCPv4 has worked.
> However, in IPv6/DHCPv6, it seems the address lifetime values in the IA_N=
A
> are not coupled to the T1 and T2 times, so if DHCPv6 goes away (perhaps
> because the M bit was switched off in a latter RA), the configured IPv6
> addresses should be left to age out as per their preferred and valid life=
times.
>=20
> The other thing I noticed was that the M RA flag and the PIO A flags aren=
't
> mutually exclusive - I couldn't find any text in RFC4861 that says if the=
 M bit
> is switched on, the PIO A flags must be switched off and vice-versa. So t=
hat
> suggests that the DHCPv6 and SLAAC can co-exist, and I think that is quit=
e
> reasonable if you're transitioning a link from DHCPv6 to SLAAC address
> configuration or vice-versa.
>=20
> Thinking about it more, I came realise that DHCPv6 and SLAAC are _address
> configuration_ methods, but are not address aging methods - IPv6 takes ca=
re
> of address aging via it's preferred and valid aging mechanisms, regardles=
s of
> the address configuration method. Static assignment is also just an addre=
ss
> configuration method, although typically the addresses don't age out, but
> only because they're normally set to infinity. Perhaps in the future ther=
e
> might be other address configuration methods.
>=20
> I didn't seem to be able to find an RFC that made it clear that address
> configuration and address aging are quite separate, so perhaps this ID co=
uld
> be the one.
>=20
> Regarding this text:
>=20
> 'For the host behavior, there is an explicit rule in the SLAAC specificat=
ion
> [RFC4862]: "If the Autonomous flag is not set, silently ignore the Prefix
> Information option."'
>=20
> I think RFC5942, "IPv6 Subnet Model: The Relationship between Links and
> Subnet Prefixes." updates that advice, as the PIO option is used to indic=
ates
> which prefix/range of addresses are on-link, via the PIO O bit, even if t=
he PIO
> A bit is switched off.
>=20
> Best regards,
> Mark.
>=20
> >________________________________
> > From: Liubing (Leo) 
> >To: "ipv6@ietf.org" ; "v6ops@ietf.org" 
> >Cc: "renum@ietf.org" 
> >Sent: Tuesday, 26 February 2013 6:14 PM
> >Subject: SLAAC/DHCPv6 addr-conf operational gaps
> >
> >Hi, 6man & v6ops
> >
> >We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
> >
> >As we know there are several flags in RA messages regarding with the hos=
t
> configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
> and O (Otherconfig) flag.
> >For some reason, the host behavior of interpreting the flags is ambiguou=
s in
> the standard (mainly RFC4862). I presented a draft discussing M flag
> behavior in 6man @ietf84, and there were some feedbacks arguing the same
> issue. This draft analyzed all the three flags, and provided test result =
of
> current implementations, it showed the behavior of different mainstream
> desktop OSes have varied. The ambiguous and variation might cause
> operational problems, such as renumbering (used to discuss in 6renum WG
> and been documented in the WG drafts), cold start problem, and
> management gaps .etc.
> >
> >Your review and comments would be appreciated very much.
> >
> >All the best,
> >Bing
> >
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Monday, February 25, 2013 5:52 PM
> >> To: Liubing (Leo)
> >> Cc: rbonica@juniper.net
> >> Subject: New Version Notification for
> >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >>
> >>
> >> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> >> has been successfully submitted by Bing Liu and posted to the
> >> IETF repository.
> >>
> >> Filename:=A0=A0=A0=A0=A0draft-liu-bonica-dhcpv6-slaac-problem
> >> Revision:=A0=A0=A0=A0=A001
> >> Title:=A0=A0=A0 =A0=A0=A0=A0=A0DHCPv6/SLAAC Address Configuration Inte=
raction
> Problem
> >> Statement
> >> Creation date:=A0=A0=A0=A0=A02013-02-25
> >> Group:=A0=A0=A0 =A0=A0=A0=A0=A0Individual Submission
> >> Number of pages: 12
> >> URL:
> >>
> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem=
-
> >> 01.txt
> >> Status:
> >> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
> >> Htmlized:
> >> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
> >> Diff:
> >>
> http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-problem-=
01
> >>
> >> Abstract:
> >>=A0 =A0 This document analyzes the host behavior of DHCPv6/SLAAC
> interaction
> >>=A0 =A0 issue. It reviews the standard definition of the host behaviors=
 and
> >>=A0 =A0 provides the test results of current mainstream implementations=
.
> Some
> >>=A0 =A0 potential operational gaps of the interaction are also describe=
d.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >
> >--------------------------------------------------------------------
> >IETF IPv6 working group mailing list
> >ipv6@ietf.org
> >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >--------------------------------------------------------------------
> >
> >
> >

From kauer@biplane.com.au  Tue Feb 26 22:00: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 5D54321F8722 for ; Tue, 26 Feb 2013 22:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level: 
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVJPRVl5iso5 for ; Tue, 26 Feb 2013 22:00:32 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7B921F8704 for ; Tue, 26 Feb 2013 22:00:31 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAHKfLVGWZX+7/2dsb2JhbAANOMIEgReDEgEBAQSBCQsYLlcZs22TM45MTxaDKgOINJlgiDA
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 27 Feb 2013 16:30:29 +1030
Message-ID: <1361944828.24824.175.camel@karl>
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
From: Karl Auer 
To: ipv6@ietf.org
Date: Wed, 27 Feb 2013 17:00:28 +1100
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC83E@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <1361910873.78397.YahooMailNeo@web142503.mail.bf1.yahoo.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC83E@nkgeml506-mbx.china.huawei.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: Wed, 27 Feb 2013 06:00:37 -0000

On Wed, 2013-02-27 at 05:56 +0000, Liubing (Leo) wrote:
> I like the concept of separating "_address configuration_ methods" and
> "address aging methods", if we could initiate the subsequence work, it
> should be considered.

Hear, hear!

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

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 leo.liubing@huawei.com  Tue Feb 26 22:16: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 DDECF21F87B3; Tue, 26 Feb 2013 22:16:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.003
X-Spam-Level: 
X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SjaqQ-J2xLt; Tue, 26 Feb 2013 22:16:48 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE621F8722; Tue, 26 Feb 2013 22:16:47 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQC30124; Wed, 27 Feb 2013 06:16:46 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 06:15:50 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 06:16:45 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 14:16:36 +0800
From: "Liubing (Leo)" 
To: Sheng Jiang , "ipv6@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiNDEUQgAAsV0A=
Date: Wed, 27 Feb 2013 06:16:35 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC86A@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923A00E022@szxeml545-mbx.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923A00E022@szxeml545-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 27 Feb 2013 06:16:49 -0000

SGksIFNoZW5nDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NClRoaXMgaXMgdGhlIGZpcnN0
IHN0ZXAsIHRvIHNlZSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgb2YgYWdyZWVpbmcgdGhlIHByb2Js
ZW1zIHNob3VsZCBiZSBmaXhlZCBpbiBjdXJyZW50IHN0YW5kYXJkLiBJZiBzbywgd2UnbGwgc3Vi
bWl0IGEgZHJhZnQgdG8gZml4IHRoZSBhbWJpZ3VvdXMgaXNzdWUuDQoNCkIuUi4NCkJpbmcNCg0K
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNoZW5nIEppYW5nDQo+IFNl
bnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjcsIDIwMTMgMTE6MzcgQU0NCj4gVG86IExpdWJpbmcg
KExlbyk7IGlwdjZAaWV0Zi5vcmcNCj4gQ2M6IHJlbnVtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJF
OiBTTEFBQy9ESENQdjYgYWRkci1jb25mIG9wZXJhdGlvbmFsIGdhcHMNCj4gDQo+IFRoaXMgaGFz
IGJlZW4gYSBoaXN0b3JpYyBpc3N1ZS4gQWx0aG91Z2ggdGhlcmUgd2FzIGRpc2N1c3Npb25zIHNl
dmVyYWwgdGltZXMsDQo+IHRoZSBzcGVjaWZpY2F0aW9uIHN0aWxsIHJlbWFpbiBhbWJpZ3VvdXMu
IFRoZSBkaWZmZXJlbmNlcyBpbiBPUw0KPiBpbXBsZW1lbnRhdGlvbnMgYXJlIGdvb2QgcHJvb2Yg
dGhhdCB3ZSBuZWVkIHRvIGRvIHNvbWV0aGluZyBpbiBJRVRGLg0KPiANCj4gVGhpcyBkb2N1bWVu
dCBoYXMgd2VsbCBkZXNjcmliZWQgdGhlIGN1cnJlbnQgc3RhbmRhcmQgc3RhdHVzIGFuZCByZWFs
aXR5DQo+IG9wZXJhdGlvbmFsIGlzc3Vlcy4gSG93ZXZlciwgZm9yIG1lLCB0aGlzIGRvY3VtZW50
IGZhaWxzIHRvIHN1Z2dlc3Qgd2hhdCB3ZQ0KPiBtYXkgZG8gdG8gZml4IHRoaXMgaXNzdWUsIG5l
aXRoZXIgaW4gdGhlIGdhcCBzZWN0aW9uIG9yIGFzIGNvbmNsdXNpb24uIEl0IGlzIGNsZWFyDQo+
IHRoYXQgcGFydCBvZiBSRkM0ODYyIG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8gbWFrZSB0aGUgY29u
ZmlndXJhdGlvbg0KPiBiZWhhdmlvciBjbGVhciBhbmQgY29uc2lzdGVudC4gRm9yIHRoYXQsIHRo
aXMgZG9jdW1lbnQgZmFpbHMgdG8gZ2l2ZSBhIGZlYXNpYmxlDQo+IHByb3Bvc2FsLiBNYXliZSwg
dGhlIGF1dGhvcnMgaGFzIHNhdmVkIHRoYXQgZm9yIGFub3RoZXIgZm9sbG93IHVwIHN0YW5kYXJk
DQo+IHRyYWNrIGRvY3VtZW50Lg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gU2hlbmcNCj4g
DQo+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+RnJvbTogcmVudW0tYm91bmNlc0Bp
ZXRmLm9yZyBbbWFpbHRvOnJlbnVtLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+
T2YgTGl1YmluZyAoTGVvKQ0KPiA+U2VudDogVHVlc2RheSwgRmVicnVhcnkgMjYsIDIwMTMgMzox
NCBQTQ0KPiA+VG86IGlwdjZAaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnDQo+ID5DYzogcmVudW1A
aWV0Zi5vcmcNCj4gPlN1YmplY3Q6IFtyZW51bV0gU0xBQUMvREhDUHY2IGFkZHItY29uZiBvcGVy
YXRpb25hbCBnYXBzDQo+ID4NCj4gPkhpLCA2bWFuICYgdjZvcHMNCj4gPg0KPiA+V2Ugc3VibWl0
dGVkIGEgbmV3IGRyYWZ0IHRvIGRpc2N1c3MgdGhlIFNMQUFDL0RIQ1B2NiBpbnRlcmFjdGlvbiBn
YXBzLg0KPiA+DQo+ID5BcyB3ZSBrbm93IHRoZXJlIGFyZSBzZXZlcmFsIGZsYWdzIGluIFJBIG1l
c3NhZ2VzIHJlZ2FyZGluZyB3aXRoIHRoZSBob3N0DQo+ID5jb25maWd1cmF0aW9uIGJlaGF2aW9y
LCB3aGljaCBhcmUgQSAoQXV0b25vbW91cykgZmxhZywgTSAoTWFuYWdlZCkgZmxhZywNCj4gPmFu
ZCBPIChPdGhlcmNvbmZpZykgZmxhZy4NCj4gPkZvciBzb21lIHJlYXNvbiwgdGhlIGhvc3QgYmVo
YXZpb3Igb2YgaW50ZXJwcmV0aW5nIHRoZSBmbGFncyBpcyBhbWJpZ3VvdXMgaW4NCj4gPnRoZSBz
dGFuZGFyZCAobWFpbmx5IFJGQzQ4NjIpLiBJIHByZXNlbnRlZCBhIGRyYWZ0IGRpc2N1c3Npbmcg
TSBmbGFnDQo+IGJlaGF2aW9yDQo+ID5pbiA2bWFuIEBpZXRmODQsIGFuZCB0aGVyZSB3ZXJlIHNv
bWUgZmVlZGJhY2tzIGFyZ3VpbmcgdGhlIHNhbWUgaXNzdWUuDQo+ID5UaGlzIGRyYWZ0IGFuYWx5
emVkIGFsbCB0aGUgdGhyZWUgZmxhZ3MsIGFuZCBwcm92aWRlZCB0ZXN0IHJlc3VsdCBvZiBjdXJy
ZW50DQo+ID5pbXBsZW1lbnRhdGlvbnMsIGl0IHNob3dlZCB0aGUgYmVoYXZpb3Igb2YgZGlmZmVy
ZW50IG1haW5zdHJlYW0gZGVza3RvcA0KPiA+T1NlcyBoYXZlIHZhcmllZC4gVGhlIGFtYmlndW91
cyBhbmQgdmFyaWF0aW9uIG1pZ2h0IGNhdXNlIG9wZXJhdGlvbmFsDQo+ID5wcm9ibGVtcywgc3Vj
aCBhcyByZW51bWJlcmluZyAodXNlZCB0byBkaXNjdXNzIGluIDZyZW51bSBXRyBhbmQgYmVlbg0K
PiA+ZG9jdW1lbnRlZCBpbiB0aGUgV0cgZHJhZnRzKSwgY29sZCBzdGFydCBwcm9ibGVtLCBhbmQg
bWFuYWdlbWVudA0KPiA+Z2FwcyAuZXRjLg0KPiA+DQo+ID5Zb3VyIHJldmlldyBhbmQgY29tbWVu
dHMgd291bGQgYmUgYXBwcmVjaWF0ZWQgdmVyeSBtdWNoLg0KPiA+DQo+ID5BbGwgdGhlIGJlc3Qs
DQo+ID5CaW5nDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJv
bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu
b3JnXQ0KPiA+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDU6NTIgUE0NCj4gPj4g
VG86IExpdWJpbmcgKExlbykNCj4gPj4gQ2M6IHJib25pY2FAanVuaXBlci5uZXQNCj4gPj4gU3Vi
amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+PiBkcmFmdC1saXUtYm9uaWNh
LWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTAxLnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIG5ldyB2ZXJz
aW9uIG9mIEktRCwgZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wMS50eHQN
Cj4gPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9z
dGVkIHRvIHRoZQ0KPiA+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4+DQo+ID4+IEZpbGVuYW1lOgkg
ZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPiA+PiBSZXZpc2lvbjoJIDAx
DQo+ID4+IFRpdGxlOgkJIERIQ1B2Ni9TTEFBQyBBZGRyZXNzIENvbmZpZ3VyYXRpb24gSW50ZXJh
Y3Rpb24gUHJvYmxlbQ0KPiA+PiBTdGF0ZW1lbnQNCj4gPj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMt
MDItMjUNCj4gPj4gR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4+IE51bWJlciBv
ZiBwYWdlczogMTINCj4gPj4gVVJMOg0KPiA+Pg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy9kcmFmdC1saXUtYm9uaWNhLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLQ0KPiA+PiAw
MS50eHQNCj4gPj4gU3RhdHVzOg0KPiA+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0NCj4gPj4gSHRtbGl6ZWQ6DQo+
ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNs
YWFjLXByb2JsZW0tMDENCj4gPj4gRGlmZjoNCj4gPj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9y
ZmNkaWZmP3VybDI9ZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wMQ0KPiA+
Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgaG9z
dCBiZWhhdmlvciBvZiBESENQdjYvU0xBQUMNCj4gaW50ZXJhY3Rpb24NCj4gPj4gICAgaXNzdWUu
IEl0IHJldmlld3MgdGhlIHN0YW5kYXJkIGRlZmluaXRpb24gb2YgdGhlIGhvc3QgYmVoYXZpb3Jz
IGFuZA0KPiA+PiAgICBwcm92aWRlcyB0aGUgdGVzdCByZXN1bHRzIG9mIGN1cnJlbnQgbWFpbnN0
cmVhbSBpbXBsZW1lbnRhdGlvbnMuDQo+IFNvbWUNCj4gPj4gICAgcG90ZW50aWFsIG9wZXJhdGlv
bmFsIGdhcHMgb2YgdGhlIGludGVyYWN0aW9uIGFyZSBhbHNvIGRlc2NyaWJlZC4NCj4gPj4NCj4g
Pj4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPnJlbnVtIG1haWxp
bmcgbGlzdA0KPiA+cmVudW1AaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vcmVudW0NCg==

From jiangsheng@huawei.com  Tue Feb 26 22:45: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 B964C21F8733; Tue, 26 Feb 2013 22:45:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.119
X-Spam-Level: 
X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cBeiONLngYC; Tue, 26 Feb 2013 22:45:11 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB021F8716; Tue, 26 Feb 2013 22:45:10 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV32857; Wed, 27 Feb 2013 06:45:09 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 06:44:13 +0000
Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 06:45:08 +0000
Received: from szxeml545-mbx.china.huawei.com ([169.254.1.45]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 14:44:56 +0800
From: Sheng Jiang 
To: "Liubing (Leo)" , "ipv6@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiNDEUQgAAsV0CAAAivUA==
Date: Wed, 27 Feb 2013 06:44:55 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A00E1D3@szxeml545-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923A00E022@szxeml545-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC86A@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC86A@nkgeml506-mbx.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 27 Feb 2013 06:45:12 -0000

SGksIEJpbmcsDQoNCkl0IGlzIGJldHRlciB0byBhdCBsZWFzdCBtZW50aW9uIHRoZSBkaXJlY3Rp
b24gb2YgbmV4dCBzdGVwIC0gY2xlYXJseSByZWRlZmluZSB0aGUgZmxhZyBjb3JyZXNwb25kZW50
IGhvc3QgYmVoYXZpb3IgaW4gc3RhbmRhcmRzLg0KDQpBIGNvdXBsZSBvZiBtb3JlIGRldGFpbGVk
IGNvbW1lbnRzOiB5b3UgaGF2ZSB1c2VkIHdvcmQgImdhcCIgc2V2ZXJhbCB0aW1lcywgd2hpbGUg
eW91IGRpZCBub3QgY2xlYXIgZGVzY3JpYmUgd2hhdCBnYXAgaXQgaXMuIFlvdSBoYXZlIG9ubHkg
ZGVzY3JpYmVkIGlzc3Vlcy9wcm9ibGVtcy4gR2FwcyBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQg
aXNzdWUgc29sdmVkIGlmIHlvdSBjb3VsZCBmaWxsIHRoZW0uIFN1YnNlY3Rpb25zIG9mIFNlY3Rp
b24gMyBhcmUgcHJvYmxlbSBzY2VuYXJpb3MuIEJ1dCB5b3VyIHN1YnNlY3Rpb24gdGl0bGVzIGRv
IG5vdCBjbGVhciBleHByZXNzIHRoZSBtZWFuaW5nLg0KDQpDaGVlcnMsDQoNClNoZW5nDQoNCj4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IExpdWJpbmcgKExlbykNCj5TZW50OiBX
ZWRuZXNkYXksIEZlYnJ1YXJ5IDI3LCAyMDEzIDI6MTcgUE0NCj5UbzogU2hlbmcgSmlhbmc7IGlw
djZAaWV0Zi5vcmcNCj5DYzogcmVudW1AaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogU0xBQUMvREhD
UHY2IGFkZHItY29uZiBvcGVyYXRpb25hbCBnYXBzDQo+DQo+SGksIFNoZW5nDQo+DQo+VGhhbmtz
IGZvciB5b3VyIGNvbW1lbnRzLg0KPlRoaXMgaXMgdGhlIGZpcnN0IHN0ZXAsIHRvIHNlZSBpZiB0
aGVyZSBpcyBjb25zZW5zdXMgb2YgYWdyZWVpbmcgdGhlIHByb2JsZW1zDQo+c2hvdWxkIGJlIGZp
eGVkIGluIGN1cnJlbnQgc3RhbmRhcmQuIElmIHNvLCB3ZSdsbCBzdWJtaXQgYSBkcmFmdCB0byBm
aXggdGhlDQo+YW1iaWd1b3VzIGlzc3VlLg0KPg0KPkIuUi4NCj5CaW5nDQo+DQo+DQo+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogU2hlbmcgSmlhbmcNCj4+IFNlbnQ6IFdl
ZG5lc2RheSwgRmVicnVhcnkgMjcsIDIwMTMgMTE6MzcgQU0NCj4+IFRvOiBMaXViaW5nIChMZW8p
OyBpcHY2QGlldGYub3JnDQo+PiBDYzogcmVudW1AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBT
TEFBQy9ESENQdjYgYWRkci1jb25mIG9wZXJhdGlvbmFsIGdhcHMNCj4+DQo+PiBUaGlzIGhhcyBi
ZWVuIGEgaGlzdG9yaWMgaXNzdWUuIEFsdGhvdWdoIHRoZXJlIHdhcyBkaXNjdXNzaW9ucyBzZXZl
cmFsIHRpbWVzLA0KPj4gdGhlIHNwZWNpZmljYXRpb24gc3RpbGwgcmVtYWluIGFtYmlndW91cy4g
VGhlIGRpZmZlcmVuY2VzIGluIE9TDQo+PiBpbXBsZW1lbnRhdGlvbnMgYXJlIGdvb2QgcHJvb2Yg
dGhhdCB3ZSBuZWVkIHRvIGRvIHNvbWV0aGluZyBpbiBJRVRGLg0KPj4NCj4+IFRoaXMgZG9jdW1l
bnQgaGFzIHdlbGwgZGVzY3JpYmVkIHRoZSBjdXJyZW50IHN0YW5kYXJkIHN0YXR1cyBhbmQgcmVh
bGl0eQ0KPj4gb3BlcmF0aW9uYWwgaXNzdWVzLiBIb3dldmVyLCBmb3IgbWUsIHRoaXMgZG9jdW1l
bnQgZmFpbHMgdG8gc3VnZ2VzdCB3aGF0DQo+d2UNCj4+IG1heSBkbyB0byBmaXggdGhpcyBpc3N1
ZSwgbmVpdGhlciBpbiB0aGUgZ2FwIHNlY3Rpb24gb3IgYXMgY29uY2x1c2lvbi4gSXQgaXMNCj5j
bGVhcg0KPj4gdGhhdCBwYXJ0IG9mIFJGQzQ4NjIgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBtYWtl
IHRoZSBjb25maWd1cmF0aW9uDQo+PiBiZWhhdmlvciBjbGVhciBhbmQgY29uc2lzdGVudC4gRm9y
IHRoYXQsIHRoaXMgZG9jdW1lbnQgZmFpbHMgdG8gZ2l2ZSBhIGZlYXNpYmxlDQo+PiBwcm9wb3Nh
bC4gTWF5YmUsIHRoZSBhdXRob3JzIGhhcyBzYXZlZCB0aGF0IGZvciBhbm90aGVyIGZvbGxvdyB1
cCBzdGFuZGFyZA0KPj4gdHJhY2sgZG9jdW1lbnQuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4N
Cj4+IFNoZW5nDQo+Pg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTog
cmVudW0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJlbnVtLWJvdW5jZXNAaWV0Zi5vcmddIE9u
DQo+PiBCZWhhbGYNCj4+ID5PZiBMaXViaW5nIChMZW8pDQo+PiA+U2VudDogVHVlc2RheSwgRmVi
cnVhcnkgMjYsIDIwMTMgMzoxNCBQTQ0KPj4gPlRvOiBpcHY2QGlldGYub3JnOyB2Nm9wc0BpZXRm
Lm9yZw0KPj4gPkNjOiByZW51bUBpZXRmLm9yZw0KPj4gPlN1YmplY3Q6IFtyZW51bV0gU0xBQUMv
REhDUHY2IGFkZHItY29uZiBvcGVyYXRpb25hbCBnYXBzDQo+PiA+DQo+PiA+SGksIDZtYW4gJiB2
Nm9wcw0KPj4gPg0KPj4gPldlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB0byBkaXNjdXNzIHRoZSBT
TEFBQy9ESENQdjYgaW50ZXJhY3Rpb24gZ2Fwcy4NCj4+ID4NCj4+ID5BcyB3ZSBrbm93IHRoZXJl
IGFyZSBzZXZlcmFsIGZsYWdzIGluIFJBIG1lc3NhZ2VzIHJlZ2FyZGluZyB3aXRoIHRoZSBob3N0
DQo+PiA+Y29uZmlndXJhdGlvbiBiZWhhdmlvciwgd2hpY2ggYXJlIEEgKEF1dG9ub21vdXMpIGZs
YWcsIE0gKE1hbmFnZWQpIGZsYWcsDQo+PiA+YW5kIE8gKE90aGVyY29uZmlnKSBmbGFnLg0KPj4g
PkZvciBzb21lIHJlYXNvbiwgdGhlIGhvc3QgYmVoYXZpb3Igb2YgaW50ZXJwcmV0aW5nIHRoZSBm
bGFncyBpcyBhbWJpZ3VvdXMNCj5pbg0KPj4gPnRoZSBzdGFuZGFyZCAobWFpbmx5IFJGQzQ4NjIp
LiBJIHByZXNlbnRlZCBhIGRyYWZ0IGRpc2N1c3NpbmcgTSBmbGFnDQo+PiBiZWhhdmlvcg0KPj4g
PmluIDZtYW4gQGlldGY4NCwgYW5kIHRoZXJlIHdlcmUgc29tZSBmZWVkYmFja3MgYXJndWluZyB0
aGUgc2FtZSBpc3N1ZS4NCj4+ID5UaGlzIGRyYWZ0IGFuYWx5emVkIGFsbCB0aGUgdGhyZWUgZmxh
Z3MsIGFuZCBwcm92aWRlZCB0ZXN0IHJlc3VsdCBvZiBjdXJyZW50DQo+PiA+aW1wbGVtZW50YXRp
b25zLCBpdCBzaG93ZWQgdGhlIGJlaGF2aW9yIG9mIGRpZmZlcmVudCBtYWluc3RyZWFtIGRlc2t0
b3ANCj4+ID5PU2VzIGhhdmUgdmFyaWVkLiBUaGUgYW1iaWd1b3VzIGFuZCB2YXJpYXRpb24gbWln
aHQgY2F1c2Ugb3BlcmF0aW9uYWwNCj4+ID5wcm9ibGVtcywgc3VjaCBhcyByZW51bWJlcmluZyAo
dXNlZCB0byBkaXNjdXNzIGluIDZyZW51bSBXRyBhbmQgYmVlbg0KPj4gPmRvY3VtZW50ZWQgaW4g
dGhlIFdHIGRyYWZ0cyksIGNvbGQgc3RhcnQgcHJvYmxlbSwgYW5kIG1hbmFnZW1lbnQNCj4+ID5n
YXBzIC5ldGMuDQo+PiA+DQo+PiA+WW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIGFw
cHJlY2lhdGVkIHZlcnkgbXVjaC4NCj4+ID4NCj4+ID5BbGwgdGhlIGJlc3QsDQo+PiA+QmluZw0K
Pj4gPg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IGludGVy
bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4+
ID4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjUsIDIwMTMgNTo1MiBQTQ0KPj4gPj4gVG86IExp
dWJpbmcgKExlbykNCj4+ID4+IENjOiByYm9uaWNhQGp1bmlwZXIubmV0DQo+PiA+PiBTdWJqZWN0
OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+PiA+PiBkcmFmdC1saXUtYm9uaWNhLWRo
Y3B2Ni1zbGFhYy1wcm9ibGVtLTAxLnR4dA0KPj4gPj4NCj4+ID4+DQo+PiA+PiBBIG5ldyB2ZXJz
aW9uIG9mIEktRCwgZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wMS50eHQN
Cj4+ID4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmluZyBMaXUgYW5kIHBv
c3RlZCB0byB0aGUNCj4+ID4+IElFVEYgcmVwb3NpdG9yeS4NCj4+ID4+DQo+PiA+PiBGaWxlbmFt
ZToJIGRyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0NCj4+ID4+IFJldmlzaW9u
OgkgMDENCj4+ID4+IFRpdGxlOgkJIERIQ1B2Ni9TTEFBQyBBZGRyZXNzIENvbmZpZ3VyYXRpb24g
SW50ZXJhY3Rpb24NCj5Qcm9ibGVtDQo+PiA+PiBTdGF0ZW1lbnQNCj4+ID4+IENyZWF0aW9uIGRh
dGU6CSAyMDEzLTAyLTI1DQo+PiA+PiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+
ID4+IE51bWJlciBvZiBwYWdlczogMTINCj4+ID4+IFVSTDoNCj4+ID4+DQo+PiBodHRwOi8vd3d3
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtYm9uaWNhLWRoY3B2Ni1zbGFhYy1w
cm9ibGVtLQ0KPj4gPj4gMDEudHh0DQo+PiA+PiBTdGF0dXM6DQo+PiA+PiBodHRwOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0N
Cj4+ID4+IEh0bWxpemVkOg0KPj4gPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
bGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wMQ0KPj4gPj4gRGlmZjoNCj4+ID4+DQo+
PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saXUtYm9uaWNhLWRoY3B2
Ni1zbGFhYy1wcm9ibGVtLTAxDQo+PiA+Pg0KPj4gPj4gQWJzdHJhY3Q6DQo+PiA+PiAgICBUaGlz
IGRvY3VtZW50IGFuYWx5emVzIHRoZSBob3N0IGJlaGF2aW9yIG9mIERIQ1B2Ni9TTEFBQw0KPj4g
aW50ZXJhY3Rpb24NCj4+ID4+ICAgIGlzc3VlLiBJdCByZXZpZXdzIHRoZSBzdGFuZGFyZCBkZWZp
bml0aW9uIG9mIHRoZSBob3N0IGJlaGF2aW9ycyBhbmQNCj4+ID4+ICAgIHByb3ZpZGVzIHRoZSB0
ZXN0IHJlc3VsdHMgb2YgY3VycmVudCBtYWluc3RyZWFtIGltcGxlbWVudGF0aW9ucy4NCj4+IFNv
bWUNCj4+ID4+ICAgIHBvdGVudGlhbCBvcGVyYXRpb25hbCBnYXBzIG9mIHRoZSBpbnRlcmFjdGlv
biBhcmUgYWxzbyBkZXNjcmliZWQuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4g
VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPnJlbnVtIG1haWxpbmcgbGlzdA0KPj4gPnJlbnVt
QGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZW51
bQ0K

From leo.liubing@huawei.com  Tue Feb 26 23:17: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 8D59221F8814; Tue, 26 Feb 2013 23:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.003
X-Spam-Level: 
X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsLa9Wo3J95p; Tue, 26 Feb 2013 23:17:46 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1516E21F87FB; Tue, 26 Feb 2013 23:17:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV35449; Wed, 27 Feb 2013 07:17:44 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 07:17:37 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 07:17:42 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 15:17:34 +0800
From: "Liubing (Leo)" 
To: Sheng Jiang , "ipv6@ietf.org" 
Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps
Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiNDEUQgAAsV0CAAAivUIAACN5A
Date: Wed, 27 Feb 2013 07:17:33 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC914@nkgeml506-mbx.china.huawei.com>
References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923A00E022@szxeml545-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC86A@nkgeml506-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923A00E1D3@szxeml545-mbx.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923A00E1D3@szxeml545-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "renum@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, 27 Feb 2013 07:17:47 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaGVuZyBKaWFuZw0KPiBTZW50
OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI3LCAyMDEzIDI6NDUgUE0NCj4gVG86IExpdWJpbmcgKExl
byk7IGlwdjZAaWV0Zi5vcmcNCj4gQ2M6IHJlbnVtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBT
TEFBQy9ESENQdjYgYWRkci1jb25mIG9wZXJhdGlvbmFsIGdhcHMNCj4gDQo+IEhpLCBCaW5nLA0K
PiANCj4gSXQgaXMgYmV0dGVyIHRvIGF0IGxlYXN0IG1lbnRpb24gdGhlIGRpcmVjdGlvbiBvZiBu
ZXh0IHN0ZXAgLSBjbGVhcmx5IHJlZGVmaW5lIHRoZQ0KPiBmbGFnIGNvcnJlc3BvbmRlbnQgaG9z
dCBiZWhhdmlvciBpbiBzdGFuZGFyZHMuDQoNCltCaW5nXSBBZ3JlZS4gVGhhbmtzIGZvciB5b3Vy
IGNsYXJpZmljYXRpb24uDQoNCj4gDQo+IEEgY291cGxlIG9mIG1vcmUgZGV0YWlsZWQgY29tbWVu
dHM6IHlvdSBoYXZlIHVzZWQgd29yZCAiZ2FwIiBzZXZlcmFsDQo+IHRpbWVzLCB3aGlsZSB5b3Ug
ZGlkIG5vdCBjbGVhciBkZXNjcmliZSB3aGF0IGdhcCBpdCBpcy4gWW91IGhhdmUgb25seQ0KPiBk
ZXNjcmliZWQgaXNzdWVzL3Byb2JsZW1zLiBHYXBzIHNob3VsZCBiZSBzb21ldGhpbmcgdGhhdCBp
c3N1ZSBzb2x2ZWQgaWYNCj4geW91IGNvdWxkIGZpbGwgdGhlbS4gU3Vic2VjdGlvbnMgb2YgU2Vj
dGlvbiAzIGFyZSBwcm9ibGVtIHNjZW5hcmlvcy4gQnV0IHlvdXINCj4gc3Vic2VjdGlvbiB0aXRs
ZXMgZG8gbm90IGNsZWFyIGV4cHJlc3MgdGhlIG1lYW5pbmcuDQoNCltCaW5nXSBPSywgSSBjYW4g
bWFrZSBpdCBtb3JlIGNsZWFyIGluIHRoZSBuZXh0IHZlcnNpb24gb3IgaW4gdGhlIG5ldyBzb2x1
dGlvbiBkcmFmdC4gVGhhbmtzIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3Lg0KDQpCLlIuDQpCaW5n
DQoNCj4gDQo+IENoZWVycywNCj4gDQo+IFNoZW5nDQo+IA0KPiA+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gPkZyb206IExpdWJpbmcgKExlbykNCj4gPlNlbnQ6IFdlZG5lc2RheSwgRmVi
cnVhcnkgMjcsIDIwMTMgMjoxNyBQTQ0KPiA+VG86IFNoZW5nIEppYW5nOyBpcHY2QGlldGYub3Jn
DQo+ID5DYzogcmVudW1AaWV0Zi5vcmcNCj4gPlN1YmplY3Q6IFJFOiBTTEFBQy9ESENQdjYgYWRk
ci1jb25mIG9wZXJhdGlvbmFsIGdhcHMNCj4gPg0KPiA+SGksIFNoZW5nDQo+ID4NCj4gPlRoYW5r
cyBmb3IgeW91ciBjb21tZW50cy4NCj4gPlRoaXMgaXMgdGhlIGZpcnN0IHN0ZXAsIHRvIHNlZSBp
ZiB0aGVyZSBpcyBjb25zZW5zdXMgb2YgYWdyZWVpbmcgdGhlIHByb2JsZW1zDQo+ID5zaG91bGQg
YmUgZml4ZWQgaW4gY3VycmVudCBzdGFuZGFyZC4gSWYgc28sIHdlJ2xsIHN1Ym1pdCBhIGRyYWZ0
IHRvIGZpeCB0aGUNCj4gPmFtYmlndW91cyBpc3N1ZS4NCj4gPg0KPiA+Qi5SLg0KPiA+QmluZw0K
PiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogU2hl
bmcgSmlhbmcNCj4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNywgMjAxMyAxMTozNyBB
TQ0KPiA+PiBUbzogTGl1YmluZyAoTGVvKTsgaXB2NkBpZXRmLm9yZw0KPiA+PiBDYzogcmVudW1A
aWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUkU6IFNMQUFDL0RIQ1B2NiBhZGRyLWNvbmYgb3BlcmF0
aW9uYWwgZ2Fwcw0KPiA+Pg0KPiA+PiBUaGlzIGhhcyBiZWVuIGEgaGlzdG9yaWMgaXNzdWUuIEFs
dGhvdWdoIHRoZXJlIHdhcyBkaXNjdXNzaW9ucyBzZXZlcmFsDQo+IHRpbWVzLA0KPiA+PiB0aGUg
c3BlY2lmaWNhdGlvbiBzdGlsbCByZW1haW4gYW1iaWd1b3VzLiBUaGUgZGlmZmVyZW5jZXMgaW4g
T1MNCj4gPj4gaW1wbGVtZW50YXRpb25zIGFyZSBnb29kIHByb29mIHRoYXQgd2UgbmVlZCB0byBk
byBzb21ldGhpbmcgaW4gSUVURi4NCj4gPj4NCj4gPj4gVGhpcyBkb2N1bWVudCBoYXMgd2VsbCBk
ZXNjcmliZWQgdGhlIGN1cnJlbnQgc3RhbmRhcmQgc3RhdHVzIGFuZCByZWFsaXR5DQo+ID4+IG9w
ZXJhdGlvbmFsIGlzc3Vlcy4gSG93ZXZlciwgZm9yIG1lLCB0aGlzIGRvY3VtZW50IGZhaWxzIHRv
IHN1Z2dlc3Qgd2hhdA0KPiA+d2UNCj4gPj4gbWF5IGRvIHRvIGZpeCB0aGlzIGlzc3VlLCBuZWl0
aGVyIGluIHRoZSBnYXAgc2VjdGlvbiBvciBhcyBjb25jbHVzaW9uLiBJdCBpcw0KPiA+Y2xlYXIN
Cj4gPj4gdGhhdCBwYXJ0IG9mIFJGQzQ4NjIgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBtYWtlIHRo
ZSBjb25maWd1cmF0aW9uDQo+ID4+IGJlaGF2aW9yIGNsZWFyIGFuZCBjb25zaXN0ZW50LiBGb3Ig
dGhhdCwgdGhpcyBkb2N1bWVudCBmYWlscyB0byBnaXZlIGENCj4gZmVhc2libGUNCj4gPj4gcHJv
cG9zYWwuIE1heWJlLCB0aGUgYXV0aG9ycyBoYXMgc2F2ZWQgdGhhdCBmb3IgYW5vdGhlciBmb2xs
b3cgdXANCj4gc3RhbmRhcmQNCj4gPj4gdHJhY2sgZG9jdW1lbnQuDQo+ID4+DQo+ID4+IEJlc3Qg
cmVnYXJkcywNCj4gPj4NCj4gPj4gU2hlbmcNCj4gPj4NCj4gPj4gPi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+ID4+ID5Gcm9tOiByZW51bS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cmVu
dW0tYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4gQmVoYWxmDQo+ID4+ID5PZiBMaXViaW5nIChM
ZW8pDQo+ID4+ID5TZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNiwgMjAxMyAzOjE0IFBNDQo+ID4+
ID5UbzogaXB2NkBpZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcNCj4gPj4gPkNjOiByZW51bUBpZXRm
Lm9yZw0KPiA+PiA+U3ViamVjdDogW3JlbnVtXSBTTEFBQy9ESENQdjYgYWRkci1jb25mIG9wZXJh
dGlvbmFsIGdhcHMNCj4gPj4gPg0KPiA+PiA+SGksIDZtYW4gJiB2Nm9wcw0KPiA+PiA+DQo+ID4+
ID5XZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyB0aGUgU0xBQUMvREhDUHY2IGlu
dGVyYWN0aW9uDQo+IGdhcHMuDQo+ID4+ID4NCj4gPj4gPkFzIHdlIGtub3cgdGhlcmUgYXJlIHNl
dmVyYWwgZmxhZ3MgaW4gUkEgbWVzc2FnZXMgcmVnYXJkaW5nIHdpdGggdGhlDQo+IGhvc3QNCj4g
Pj4gPmNvbmZpZ3VyYXRpb24gYmVoYXZpb3IsIHdoaWNoIGFyZSBBIChBdXRvbm9tb3VzKSBmbGFn
LCBNIChNYW5hZ2VkKQ0KPiBmbGFnLA0KPiA+PiA+YW5kIE8gKE90aGVyY29uZmlnKSBmbGFnLg0K
PiA+PiA+Rm9yIHNvbWUgcmVhc29uLCB0aGUgaG9zdCBiZWhhdmlvciBvZiBpbnRlcnByZXRpbmcg
dGhlIGZsYWdzIGlzDQo+IGFtYmlndW91cw0KPiA+aW4NCj4gPj4gPnRoZSBzdGFuZGFyZCAobWFp
bmx5IFJGQzQ4NjIpLiBJIHByZXNlbnRlZCBhIGRyYWZ0IGRpc2N1c3NpbmcgTSBmbGFnDQo+ID4+
IGJlaGF2aW9yDQo+ID4+ID5pbiA2bWFuIEBpZXRmODQsIGFuZCB0aGVyZSB3ZXJlIHNvbWUgZmVl
ZGJhY2tzIGFyZ3VpbmcgdGhlIHNhbWUNCj4gaXNzdWUuDQo+ID4+ID5UaGlzIGRyYWZ0IGFuYWx5
emVkIGFsbCB0aGUgdGhyZWUgZmxhZ3MsIGFuZCBwcm92aWRlZCB0ZXN0IHJlc3VsdCBvZiBjdXJy
ZW50DQo+ID4+ID5pbXBsZW1lbnRhdGlvbnMsIGl0IHNob3dlZCB0aGUgYmVoYXZpb3Igb2YgZGlm
ZmVyZW50IG1haW5zdHJlYW0NCj4gZGVza3RvcA0KPiA+PiA+T1NlcyBoYXZlIHZhcmllZC4gVGhl
IGFtYmlndW91cyBhbmQgdmFyaWF0aW9uIG1pZ2h0IGNhdXNlIG9wZXJhdGlvbmFsDQo+ID4+ID5w
cm9ibGVtcywgc3VjaCBhcyByZW51bWJlcmluZyAodXNlZCB0byBkaXNjdXNzIGluIDZyZW51bSBX
RyBhbmQgYmVlbg0KPiA+PiA+ZG9jdW1lbnRlZCBpbiB0aGUgV0cgZHJhZnRzKSwgY29sZCBzdGFy
dCBwcm9ibGVtLCBhbmQgbWFuYWdlbWVudA0KPiA+PiA+Z2FwcyAuZXRjLg0KPiA+PiA+DQo+ID4+
ID5Zb3VyIHJldmlldyBhbmQgY29tbWVudHMgd291bGQgYmUgYXBwcmVjaWF0ZWQgdmVyeSBtdWNo
Lg0KPiA+PiA+DQo+ID4+ID5BbGwgdGhlIGJlc3QsDQo+ID4+ID5CaW5nDQo+ID4+ID4NCj4gPj4g
Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4gRnJvbTogaW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+PiA+PiBT
ZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDU6NTIgUE0NCj4gPj4gPj4gVG86IExpdWJp
bmcgKExlbykNCj4gPj4gPj4gQ2M6IHJib25pY2FAanVuaXBlci5uZXQNCj4gPj4gPj4gU3ViamVj
dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+PiA+PiBkcmFmdC1saXUtYm9uaWNh
LWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTAxLnR4dA0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBB
IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxl
bS0wMS50eHQNCj4gPj4gPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5n
IExpdSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+PiA+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4+ID4+
DQo+ID4+ID4+IEZpbGVuYW1lOgkgZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxl
bQ0KPiA+PiA+PiBSZXZpc2lvbjoJIDAxDQo+ID4+ID4+IFRpdGxlOgkJIERIQ1B2Ni9TTEFBQyBB
ZGRyZXNzIENvbmZpZ3VyYXRpb24gSW50ZXJhY3Rpb24NCj4gPlByb2JsZW0NCj4gPj4gPj4gU3Rh
dGVtZW50DQo+ID4+ID4+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTAyLTI1DQo+ID4+ID4+IEdyb3Vw
OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+PiA+PiBOdW1iZXIgb2YgcGFnZXM6IDEyDQo+
ID4+ID4+IFVSTDoNCj4gPj4gPj4NCj4gPj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l
dC1kcmFmdHMvZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbS0NCj4gPj4gPj4g
MDEudHh0DQo+ID4+ID4+IFN0YXR1czoNCj4gPj4gPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1saXUtYm9uaWNhLWRoY3B2Ni1zbGFhYy1wcm9ibGVtDQo+ID4+ID4+IEh0
bWxpemVkOg0KPiA+PiA+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtYm9u
aWNhLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTAxDQo+ID4+ID4+IERpZmY6DQo+ID4+ID4+DQo+ID4+
DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpdS1ib25pY2EtZGhj
cHY2LXNsYWFjLXByb2JsZW0tMDENCj4gPj4gPj4NCj4gPj4gPj4gQWJzdHJhY3Q6DQo+ID4+ID4+
ICAgIFRoaXMgZG9jdW1lbnQgYW5hbHl6ZXMgdGhlIGhvc3QgYmVoYXZpb3Igb2YgREhDUHY2L1NM
QUFDDQo+ID4+IGludGVyYWN0aW9uDQo+ID4+ID4+ICAgIGlzc3VlLiBJdCByZXZpZXdzIHRoZSBz
dGFuZGFyZCBkZWZpbml0aW9uIG9mIHRoZSBob3N0IGJlaGF2aW9ycyBhbmQNCj4gPj4gPj4gICAg
cHJvdmlkZXMgdGhlIHRlc3QgcmVzdWx0cyBvZiBjdXJyZW50IG1haW5zdHJlYW0gaW1wbGVtZW50
YXRpb25zLg0KPiA+PiBTb21lDQo+ID4+ID4+ICAgIHBvdGVudGlhbCBvcGVyYXRpb25hbCBnYXBz
IG9mIHRoZSBpbnRlcmFjdGlvbiBhcmUgYWxzbyBkZXNjcmliZWQuDQo+ID4+ID4+DQo+ID4+ID4+
DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4+ID4N
Cj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4+ID5yZW51bSBtYWlsaW5nIGxpc3QNCj4gPj4gPnJlbnVtQGlldGYub3JnDQo+ID4+ID5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JlbnVtDQo=

From Anders_Brandt@sigmadesigns.com  Thu Feb 28 02:22: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 7496121F8B78; Thu, 28 Feb 2013 02:22:46 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMkP1qEGnIf8; Thu, 28 Feb 2013 02:22:45 -0800 (PST)
Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 685BF21F8B88; Thu, 28 Feb 2013 02:22:45 -0800 (PST)
From: Anders Brandt 
To: "ipv6@ietf.org" 
Subject: Adoption of draft-brandt-6man-lowpanz as a new 6man WG document
Thread-Topic: Adoption of draft-brandt-6man-lowpanz as a new 6man WG document
Thread-Index: Ac4VnF/Yw3UtKZdGR8K+4XZMBDry3g==
Date: Thu, 28 Feb 2013 10:22:40 +0000
Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD1D1733EA@cph-ex1>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.10.56]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "6lowpan@ietf.org" <6lowpan@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, 28 Feb 2013 10:22:46 -0000

(CC'ed to 6lowpan@ietf.org)

The Internet Draft http://tools.ietf.org/html/draft-brandt-6man-lowpanz-00 =
was submitted on Feb. 8.

The authors would like to ask that the document as adopted as a 6man WG doc=
ument.

This document SHOULD be owned by the 6LoWPAN WG. 6LoWPAN is however not act=
ive.
The 6man WG is therefore proposed as the home of this document.


Thanks,
  Anders Brandt

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of And=
ers Brandt
Sent: 8. februar 2013 13:17
To: ipv6@ietf.org; 6lowpan@ietf.org
Subject: FW: New Version Notification for draft-brandt-6man-lowpanz-00.txt

Greetings,

A new "IPv6 over foo" I-D has been posted at http://tools.ietf.org/html/dra=
ft-brandt-6man-lowpanz-00.

This I-D specifies an IPv6 encapsulation for ITU-T G.9959 radio networks th=
at I'd describe as an alternative to IEEE 802.15.4 in home and building aut=
omation.=20

The I-D provides some background material on ITU-T G.9959 (addressing, etc.=
) as well as the required IPv6 stuff.  The encapsulation and header compres=
sion schemes are derived from (and compatible with) 6LoWPAN.

I hope to get a few minutes on the 6man agenda in Orlando to discuss the I-=
D and where it belongs.

Thanks,
  Anders

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: 8. februar 2013 13:02
To: Anders Brandt
Cc: Jakob Buron
Subject: New Version Notification for draft-brandt-6man-lowpanz-00.txt


A new version of I-D, draft-brandt-6man-lowpanz-00.txt has been successfull=
y submitted by Anders Brandt and posted to the IETF repository.

Filename:	 draft-brandt-6man-lowpanz
Revision:	 00
Title:		 Transmission of IPv6 packets over ITU-T G.9959 Networks
Creation date:	 2013-02-08
WG ID:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-brandt-6man-lowp=
anz-00.txt
Status:          http://datatracker.ietf.org/doc/draft-brandt-6man-lowpanz
Htmlized:        http://tools.ietf.org/html/draft-brandt-6man-lowpanz-00


Abstract:
   This document describes the frame format for transmission of IPv6
   packets and a method of forming IPv6 link-local addresses and
   statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.


                                                                           =
      =20


The IETF Secretariat

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

From otroan@employees.org  Thu Feb 28 11:51: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 BD88E21F87EA for ; Thu, 28 Feb 2013 11:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKuaaPcV5itN for ; Thu, 28 Feb 2013 11:51:47 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 967EA21F87AD for ; Thu, 28 Feb 2013 11:51:42 -0800 (PST)
Received: from dhcp-10-61-97-83.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7B8255ECA for ; Thu, 28 Feb 2013 11:51:40 -0800 (PST)
From: Ole Troan 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Next steps for draft-gont-6man-predictable-fragment-id
Message-Id: <1D5AC9C6-2FC2-455D-930E-A8BA83C37D5B@employees.org>
Date: Thu, 28 Feb 2013 20:51:38 +0100
To: "ipv6@ietf.org 6man-wg" 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
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, 28 Feb 2013 19:51:49 -0000

Hi,

The draft-gont-6man-predictable-fragment-id document has been discussed =
a few times.
At the IETF84 (minutes attached below), and in the thread:
http://www.ietf.org/mail-archive/web/ipv6/current/msg15836.html

Could we get the working groups opinion on what to do with the document?

- Is there interest in working on it in 6man?
  (if yes, you must be willing to contribute, if no, then say why)

Best regards,
Ole & Bob



IETF84 minutes:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fernando Gont presented the draft about Security Implications of
Predictable Fragment Identification Values,
(draft-gont-6man-predictable-fragment-id-02.txt)

Ole Troan wanted to make this document more generic and discuss the
implications of using predictable values in Internet
protocols. Fernando=20

Bob Hinden wanted to see a longer list of OSs. He was also curious as
to whether this was problem that needed to be fixed in IETF or was
this already common knowledge.

Erik Kline wanted to know if there was an IAB document that
recommended the use of non-predictable values if there was an integer
field that did not need specific values.

Thomas Narten was not sure what to do with this. This fell under the
category of "don't do anything stupid". e.g. Why do a document for
IPv6 for things that were well known in IPv4?

Lorenzo Colitti thought that this work was not harmful and should be
pursued irrespective of any iab work.

Brian Haberman did not want to have a point solution for every field
and he would like to see a more general document applicable across the
IETF. Fernando was concerned on whether implementers would read this
generic document. Brian believed that this generic document could be
referred to in the node requirements document, thus ensuring that IPv6
implementers would read it.

Joel Jaeggli thought that it was a worthwhile activity to look at
existing implementations and flag this as a potential issue that was
common across multiple implementations. Thomas Narten and Erik Kline
agreed with Joel.

Dave mentioned that RFC4732 (Internet DOS considerations) talked about
using unpredictable values for session ids. Fernando talked about
other issues discovered after 4732 that still had this issue. Dave
believed that this sort of work needs to be done by the saag and if
this was included in a statement from saag as something to look for in
SecDir reviews, it would have the largest impact.

Chairs wanted to continue discussion on mailing list and requested
Fernando to discuss potential changes with Joel J.=

From mcr@sandelman.ca  Thu Feb 28 14:05: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 348D221F87EA for ; Thu, 28 Feb 2013 14:05:28 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLWEzQx6yRKr for ; Thu, 28 Feb 2013 14:05:27 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBCD21F8667 for ; Thu, 28 Feb 2013 14:05:22 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8508420168 for ; Thu, 28 Feb 2013 17:12:34 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 1F5ED10473; Thu, 28 Feb 2013 17:04:04 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0447520049 for ; Thu, 28 Feb 2013 17:04:04 -0500 (EST)
From: Michael Richardson 
To: ipv6@ietf.org
Subject: draft-ietf-6man-addr-select-opt-08
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, 28 Feb 2013 22:05:28 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


I was reading this while waiting for my mom at the airport, so maybe I
missed something.

1) I understand that source prefixes and destination prefixes are matched
together by the label, but I don't understand how I know which is a
source prefix and which is a destination prefix?

2) can someone tell me operationally why one would set A=3D0?
   I understand A=3D1 is just permission to use the local policy about row
   addition, but why would the host trust the network the other way?

=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)

iQCVAwUAUS/UU4qHRg3pndX9AQLzaQQAp1iVOebo9DXaPx6DbD+pqGmR0kY7BGjI
QrFY0iZ1XpTTTeRUH/ymu6fvoCYjItoyONwK2GVH83mwCm9Leem/X1ITC41Pq1gm
X7j9ySiMk8tEb2S86msj+9DM9HyLJ0xYK2QKstSoEpNyw+M3dDTi1tfqF+8Tvuzp
nv2mNx5ofV0=
=cWcW
-----END PGP SIGNATURE-----
--=-=-=--