From exim@www1.ietf.org Fri Sep 12 09:56:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23344 for ; Fri, 12 Sep 2003 09:56:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoOg-0007vZ-Kb for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 09:55:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CDtc7n030467 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 09:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoOg-0007v4-EY for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 09:55:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23213 for ; Fri, 12 Sep 2003 09:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoO7-0007i8-D0; Fri, 12 Sep 2003 09:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoNG-0007hH-Vv for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 09:54:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23107 for ; Fri, 12 Sep 2003 09:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xoNF-0006sT-00 for ipv6@ietf.org; Fri, 12 Sep 2003 09:54:09 -0400 Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19xoNE-0006rV-00 for ipv6@ietf.org; Fri, 12 Sep 2003 09:54:08 -0400 Received: from btm34m.sh.bel.alcatel.be (btm34m.sh.bel.alcatel.be [138.203.192.124]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h8CEKMLM012081 for ; Fri, 12 Sep 2003 16:20:22 +0200 Received: from alcatel.be (btm42k [138.203.193.224]) by btm34m.sh.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id PAA28554 for ; Fri, 12 Sep 2003 15:53:36 +0200 (MET DST) Message-ID: <3F61CFE0.594F904@alcatel.be> Date: Fri, 12 Sep 2003 15:53:36 +0200 From: FIGEN CETIN Organization: ALCATEL X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 10:30:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26218 for ; Fri, 12 Sep 2003 10:30:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xowE-0001AP-0i for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 10:30:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CEUH11004479 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 10:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xowD-0001AA-S4 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 10:30:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26156 for ; Fri, 12 Sep 2003 10:30:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xowB-0007TK-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 10:30:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xowA-0007TF-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 10:30:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xow0-00015m-5e; Fri, 12 Sep 2003 10:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xovX-00014X-Hg for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 10:29:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26113 for ; Fri, 12 Sep 2003 10:29:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xovV-0007Ss-00 for ipv6@ietf.org; Fri, 12 Sep 2003 10:29:33 -0400 Received: from uberwoo.osburn.com ([209.112.175.66] helo=osburn.com ident=daemon) by ietf-mx with esmtp (Exim 4.12) id 19xovU-0007Sp-00 for ipv6@ietf.org; Fri, 12 Sep 2003 10:29:32 -0400 Received: from localhost (osburn@localhost) by osburn.com (8.12.9/8.12.9) with ESMTP id h8CETS9Q010779 for ; Fri, 12 Sep 2003 07:29:28 -0700 (PDT) Date: Fri, 12 Sep 2003 07:29:28 -0700 (PDT) From: Tim Osburn X-X-Sender: osburn@uberwoo.osburn.com To: ipv6@ietf.org Subject: Re: (no subject) In-Reply-To: <3F61CFE0.594F904@alcatel.be> Message-ID: References: <3F61CFE0.594F904@alcatel.be> X-Personal-Webpage: www.osburn.com X-PGP-Key-Fingerprint: C97A 3831 18C4 7CC6 9852 CF09 86DD 21FA BB29 A64E X-Amateur-Radio: W7RSZ X-quote: Never stop seeking what seems unobtainable X-IRC: EFNET - carrar X-Woo-Woo: Woo Woo :) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi!! :) This list becoming active? Tim Osburn www.osburn.com Network Architect 800.675.3196 On Fri, 12 Sep 2003, FIGEN CETIN wrote: > Date: Fri, 12 Sep 2003 15:53:36 +0200 > From: FIGEN CETIN > To: ipv6@ietf.org > Subject: (no subject) > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 12:12:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00907 for ; Fri, 12 Sep 2003 12:12:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqWO-00084M-Ts for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:11:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGBiXT031012 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqWO-000847-Pt for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:11:44 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00800 for ; Fri, 12 Sep 2003 12:11:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqVj-0007jX-Rh; Fri, 12 Sep 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqUl-0007dS-Ge for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 12:10:03 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00526 for ; Fri, 12 Sep 2003 12:09:53 -0400 (EDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8CG9An13573; Fri, 12 Sep 2003 09:09:10 -0700 X-mProtect: <200309121609> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCjo3jK; Fri, 12 Sep 2003 09:09:09 PDT Message-Id: <4.3.2.7.2.20030912090639.03b0eaa0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Sep 2003 09:07:05 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: test Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Test, please ignore. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 12:20:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01454 for ; Fri, 12 Sep 2003 12:20:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqdj-0000Td-EY for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:19:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGJJIb001827 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqdj-0000TO-8g for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:19:19 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01362 for ; Fri, 12 Sep 2003 12:19:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqaY-0008Qm-5w; Fri, 12 Sep 2003 12:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqZa-0008Nx-8m for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 12:15:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01109 for ; Fri, 12 Sep 2003 12:14:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqZY-00019Q-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:15:00 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19xqZY-000193-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:15:00 -0400 Subject: RE: test MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Sep 2003 09:14:25 -0700 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: test Thread-Index: AcN5SHgn8rK7Zu+kTiW3DYV6cCb9ogAAGlMQ From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Got it, the new mailing list appears to work -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Bob Hinden Sent: Friday, September 12, 2003 9:07 AM To: ipv6@ietf.org Cc: Bob Hinden Subject: test Test, please ignore. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 12:24:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01785 for ; Fri, 12 Sep 2003 12:24:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqhw-0000s1-IA for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:23:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGNei6003339 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqht-0000rl-Rx for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:23:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01688 for ; Fri, 12 Sep 2003 12:23:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqhJ-0000eW-PO; Fri, 12 Sep 2003 12:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqgT-0000cq-8l for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 12:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01609 for ; Fri, 12 Sep 2003 12:22:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqgR-0001K1-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:22:07 -0400 Received: from blackhole.x-tec.de ([62.180.107.114] helo=x-tec.de) by ietf-mx with esmtp (Exim 4.12) id 19xqgQ-0001Iv-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:22:07 -0400 Received: from hermes.x-tec.de ([192.168.1.250]) by hades.x-tec.de with ESMTP id <119065>; Fri, 12 Sep 2003 18:20:37 +0200 Message-ID: <3F61F065.2050403@x-tec.de> Date: Fri, 12 Sep 2003 17:12:21 +0100 From: Christian Hoheisel Organization: X-tec GmbH - ICNS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xuke , ipv6@ietf.org Subject: Re: IPv4 over IPv6 tunnel References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090609070906090203040803" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms090609070906090203040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit xuke wrote: >Hi,all > >Does anybody know there is any RFC or draft about IPv4 over IPv6 tunnel? >I can't find it in IETF website. > >Thanks a lot. > >xuke > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > > > Hi, as far as I know, most implementations of v4overv6 use the IPv4 in IPv6 addresses. One draft I know is at http://www.globecom.net/ietf/draft/draft-blanchet-ngtrans-tsp-dstm-profile-00.html but its allready expired. Dont know if theres a new one. Best regards Chris -- _________________________________________________________________ Mit freundlichen Grüßen Christian Hoheisel IT Security Engineer X-tec GmbH - ICNS Institute for Computer- and Network Security Ludwigsplatz 4 83022 Rosenheim / Germany Tel. : 0049 8031 3669 34 Fax : 0049 8031 3669 36 Mobile : 0170 96 300 26 _________________________________________________________________ --------------ms090609070906090203040803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVDCC BaYwggSOoAMCAQICAQUwDQYJKoZIhvcNAQEEBQAwgYsxCzAJBgNVBAYTAkRFMRAwDgYDVQQI EwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoTClgtdGVjIEdtYkgxDTAL BgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1QgQ0ExGjAYBgkqhkiG9w0BCQEWC2Nh QHgtdGVjLmRlMB4XDTAzMDUwODA3NTczMFoXDTA0MDUwNzA3NTczMFowgZgxCzAJBgNVBAYT AkRFMRAwDgYDVQQIEwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoTClgt dGVjIEdtYkgxDTALBgNVBAsTBElDTlMxGzAZBgNVBAMTEkNocmlzdGlhbiBIb2hlaXNlbDEi MCAGCSqGSIb3DQEJARYTYy5ob2hlaXNlbEB4LXRlYy5kZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMbT9rkd2kroI4ugzqiABiVYX+q15Slgs8TrX2KdsmGjqyp6v55RaNvE ++9zI/5hjjqtaNd1Pydvo8amSN9XbcmkFQ+Z6kivWNDk6hJbpF/bM5/hfmi7aqd3qAsr8Ji6 jjPTEcTo0bqrJ3SQOsm63vTBtzKHGLqHWL8ojouuo7GCQneE8UrnSq+MuVGniHM13l5D1hks C9zSPyhYBbYmPjmorvn825fngrHXw//AmD//Dck3x+Cy2fbbe+S4OEG91kctW2jr2vvwYHj5 fkfRozfx+6XUEMw3aZu0y3k/xU+KKLLARJLgU5czC1FiQdydBYUUIiUhlkVnG+uYN6BXV2cC AwEAAaOCAgQwggIAMAsGA1UdDwQEAwIDqDAdBgNVHQ4EFgQUJ0ysruBgrSCel6mpJ84jNWDM RdkwgbgGA1UdIwSBsDCBrYAUBiMUT7kjhY3EwQ0290IpQD+7+quhgZGkgY4wgYsxCzAJBgNV BAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoT ClgtdGVjIEdtYkgxDTALBgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1QgQ0ExGjAY BgkqhkiG9w0BCQEWC2NhQHgtdGVjLmRlggEAMB4GA1UdEQQXMBWBE2MuaG9oZWlzZWxAeC10 ZWMuZGUwFgYDVR0SBA8wDYELY2FAeC10ZWMuZGUwLAYDVR0fBCUwIzAhoB+gHYYbaHR0cHM6 Ly9jYS54LXRlYy5kZS9VQ0EuY3JsMBEGCWCGSAGG+EIBAQQEAwIFoDAjBglghkgBhvhCAQIE FhYUaHR0cHM6Ly9jYS54LXRlYy5kZS8wLgYJYIZIAYb4QgEIBCEWH2h0dHBzOi8vY2EueC10 ZWMuZGUvcG9saWN5Lmh0bWwwSQYJYIZIAYb4QgENBDwWOlRoaXMgY2VydGlmaWNhdGUgd2Fz IGlzc3VlZCBieSBhIFgtdGVjIEdtYkggLSBJQ05TIFVzZXIgQ0EwDQYJKoZIhvcNAQEEBQAD ggEBABdeSmeWQ3qzxtemIbDnfpe9wkTpBs0k3c5Z+xhXVt3GtTMsk8Je5rKCZLJunLllFVLG gwU7sMvb3769NDM5o9/OLjt59KWtNBBkj2BMU8cqFi8HkcVUrsjfW/bTY1/tvUnBi3izyNZm Wiw0dTK8w8yQFai8Ce5cr8wjEPUjLfMQf6MaN6RlOahX5BltEkjjh63ZbtqXmw2Jgu0Rq8Vf HUcj19qWmejBPr5LxdvOQM34bb0rYqxtmeJbwTXbZ+M0YGbZxtwaJNB6KcDlPEwlzwDr5m7I q/OVQL3DNa21iG/1Ehbg9vZB7VWSP9fs8ITNeb9jQD8oI58Q1XWTJgk907EwggWmMIIEjqAD AgECAgEFMA0GCSqGSIb3DQEBBAUAMIGLMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJp YTESMBAGA1UEBxMJUm9zZW5oZWltMRMwEQYDVQQKEwpYLXRlYyBHbWJIMQ0wCwYDVQQLEwRJ Q05TMRYwFAYDVQQDEw1YLXRlYyBST09UIENBMRowGAYJKoZIhvcNAQkBFgtjYUB4LXRlYy5k ZTAeFw0wMzA1MDgwNzU3MzBaFw0wNDA1MDcwNzU3MzBaMIGYMQswCQYDVQQGEwJERTEQMA4G A1UECBMHQmF2YXJpYTESMBAGA1UEBxMJUm9zZW5oZWltMRMwEQYDVQQKEwpYLXRlYyBHbWJI MQ0wCwYDVQQLEwRJQ05TMRswGQYDVQQDExJDaHJpc3RpYW4gSG9oZWlzZWwxIjAgBgkqhkiG 9w0BCQEWE2MuaG9oZWlzZWxAeC10ZWMuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDG0/a5HdpK6COLoM6ogAYlWF/qteUpYLPE619inbJho6sqer+eUWjbxPvvcyP+YY46 rWjXdT8nb6PGpkjfV23JpBUPmepIr1jQ5OoSW6Rf2zOf4X5ou2qnd6gLK/CYuo4z0xHE6NG6 qyd0kDrJut70wbcyhxi6h1i/KI6LrqOxgkJ3hPFK50qvjLlRp4hzNd5eQ9YZLAvc0j8oWAW2 Jj45qK75/NuX54Kx18P/wJg//w3JN8fgstn223vkuDhBvdZHLVto69r78GB4+X5H0aM38ful 1BDMN2mbtMt5P8VPiiiywESS4FOXMwtRYkHcnQWFFCIlIZZFZxvrmDegV1dnAgMBAAGjggIE MIICADALBgNVHQ8EBAMCA6gwHQYDVR0OBBYEFCdMrK7gYK0gnpepqSfOIzVgzEXZMIG4BgNV HSMEgbAwga2AFAYjFE+5I4WNxMENNvdCKUA/u/qroYGRpIGOMIGLMQswCQYDVQQGEwJERTEQ MA4GA1UECBMHQmF2YXJpYTESMBAGA1UEBxMJUm9zZW5oZWltMRMwEQYDVQQKEwpYLXRlYyBH bWJIMQ0wCwYDVQQLEwRJQ05TMRYwFAYDVQQDEw1YLXRlYyBST09UIENBMRowGAYJKoZIhvcN AQkBFgtjYUB4LXRlYy5kZYIBADAeBgNVHREEFzAVgRNjLmhvaGVpc2VsQHgtdGVjLmRlMBYG A1UdEgQPMA2BC2NhQHgtdGVjLmRlMCwGA1UdHwQlMCMwIaAfoB2GG2h0dHBzOi8vY2EueC10 ZWMuZGUvVUNBLmNybDARBglghkgBhvhCAQEEBAMCBaAwIwYJYIZIAYb4QgECBBYWFGh0dHBz Oi8vY2EueC10ZWMuZGUvMC4GCWCGSAGG+EIBCAQhFh9odHRwczovL2NhLngtdGVjLmRlL3Bv bGljeS5odG1sMEkGCWCGSAGG+EIBDQQ8FjpUaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg YnkgYSBYLXRlYyBHbWJIIC0gSUNOUyBVc2VyIENBMA0GCSqGSIb3DQEBBAUAA4IBAQAXXkpn lkN6s8bXpiGw536XvcJE6QbNJN3OWfsYV1bdxrUzLJPCXuaygmSybpy5ZRVSxoMFO7DL29++ vTQzOaPfzi47efSlrTQQZI9gTFPHKhYvB5HFVK7I31v202Nf7b1JwYt4s8jWZlosNHUyvMPM kBWovAnuXK/MIxD1Iy3zEH+jGjekZTmoV+QZbRJI44et2W7al5sNiYLtEavFXx1HI9falpno wT6+S8XbzkDN+G29K2KsbZniW8E122fjNGBm2cbcGiTQeinA5TxMJc8A6+ZuyKvzlUC9wzWt tYhv9RIW4Pb2Qe1Vkj/X7PCEzXm/Y0A/KCOfENV1kyYJPdOxMYIDujCCA7YCAQEwgZEwgYsx CzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzAR BgNVBAoTClgtdGVjIEdtYkgxDTALBgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1Qg Q0ExGjAYBgkqhkiG9w0BCQEWC2NhQHgtdGVjLmRlAgEFMAkGBSsOAwIaBQCgggH9MBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkxMjE2MTIyMVowIwYJ KoZIhvcNAQkEMRYEFOLw6KpaPJ37iIhPS4F1K69pRfsqMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGiBgkrBgEEAYI3EAQxgZQwgZEwgYsxCzAJBgNVBAYTAkRFMRAwDgYDVQQI EwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoTClgtdGVjIEdtYkgxDTAL BgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1QgQ0ExGjAYBgkqhkiG9w0BCQEWC2Nh QHgtdGVjLmRlAgEFMIGkBgsqhkiG9w0BCRACCzGBlKCBkTCBizELMAkGA1UEBhMCREUxEDAO BgNVBAgTB0JhdmFyaWExEjAQBgNVBAcTCVJvc2VuaGVpbTETMBEGA1UEChMKWC10ZWMgR21i SDENMAsGA1UECxMESUNOUzEWMBQGA1UEAxMNWC10ZWMgUk9PVCBDQTEaMBgGCSqGSIb3DQEJ ARYLY2FAeC10ZWMuZGUCAQUwDQYJKoZIhvcNAQEBBQAEggEAny51qk7FqZ3BV+C+6E9zduIU vldYezHRyrZQoVHBfwxSzHAGnbrsvuMw0NBuQ/nRzBHq58sW/UUfZC6XZwF+/1XudUw+4Jaz gys9XLvYT605KmMibSlGXh0SigxYcKWjqSrY9Elp7ZFL9/4AWy7DZ3rkzpB+J30hlWKa6adx EdbrTVdz3Zs2z5rdAmsztryfMvlufF+iwzXEco0OIEjpeGdp/SrqmEqHHXZKjOifjwNUoB2E HqOu6iSRwUsRzie9txk4ow/CGXc9YDj5HIRzggS9hYbUvpIf4keOrk1x4i2lk0coXxk6X6ez JEu2zoqB09XY465FkGepG4/GOrTZ9QAAAAAAAA== --------------ms090609070906090203040803-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 12:32:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02470 for ; Fri, 12 Sep 2003 12:32:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqpf-0001cE-6l for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:31:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGVdvA006204 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqpe-0001bz-WD for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:31:39 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02334 for ; Fri, 12 Sep 2003 12:31:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqp3-0001SN-SZ; Fri, 12 Sep 2003 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqo8-0001Qf-Mv for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 12:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02202 for ; Fri, 12 Sep 2003 12:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqo7-0001VC-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:30:03 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19xqo6-0001Um-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:30:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8CGTHj32586; Fri, 12 Sep 2003 09:29:17 -0700 X-mProtect: <200309121629> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrNzjA1; Fri, 12 Sep 2003 09:29:14 PDT Message-Id: <4.3.2.7.2.20030912090542.02390b20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Sep 2003 09:27:08 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: New list (ipv6@ietf.org) Active Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The new mailing list for the IPv6 working is now setup and operational. Everyone previously subscribed should have received a "Welcome" message. There are 1,935 entries on the new mailing list (some of which are exploders). If you did not receive a "Welcome" message, let me know and go to https://www1.ietf.org/mailman/listinfo/ipv6 and re-subscribe. Please start using the new list. The old list will be deactivated later today. Any mail sent to the old list will receive a fixed error message telling the poster to resend the email to the new list. Mail will not be automatically forwarded. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 12:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03084 for ; Fri, 12 Sep 2003 12:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqys-0002gq-3k for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGfAeQ010334 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqyr-0002gb-UX for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:41:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02995 for ; Fri, 12 Sep 2003 12:41:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqyq-0001lZ-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 12:41:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xqyp-0001lI-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 12:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqxo-0002MR-Cb; Fri, 12 Sep 2003 12:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqx7-0002LG-Oh for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 12:39:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02868 for ; Fri, 12 Sep 2003 12:39:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqx6-0001iG-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:39:20 -0400 Received: from blackhole.x-tec.de ([62.180.107.114] helo=x-tec.de) by ietf-mx with esmtp (Exim 4.12) id 19xqx5-0001i8-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:39:19 -0400 Received: from hermes.x-tec.de ([192.168.1.250]) by hades.x-tec.de with ESMTP id <119065>; Fri, 12 Sep 2003 18:38:09 +0200 Message-ID: <3F61F474.9030501@x-tec.de> Date: Fri, 12 Sep 2003 17:29:40 +0100 From: Christian Hoheisel Organization: X-tec GmbH - ICNS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Commercial IDS? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060607040804040508090000" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms060607040804040508090000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, well a few fendors announced IPv6 support for IDS (like ISS). Does anyone have some "live" experience with those beta versions? Was a little confused what ISS thought, what IPv6 support should look like. But maybe I missed some evolution in this sector, in the last few months. Best regards Chris -- _________________________________________________________________ Mit freundlichen Grüßen Christian Hoheisel IT Security Engineer X-tec GmbH - ICNS Institute for Computer- and Network Security Ludwigsplatz 4 83022 Rosenheim / Germany Tel. : 0049 8031 3669 34 Fax : 0049 8031 3669 36 Mobile : 0170 96 300 26 _________________________________________________________________ --------------ms060607040804040508090000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVDCC BaYwggSOoAMCAQICAQUwDQYJKoZIhvcNAQEEBQAwgYsxCzAJBgNVBAYTAkRFMRAwDgYDVQQI EwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoTClgtdGVjIEdtYkgxDTAL BgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1QgQ0ExGjAYBgkqhkiG9w0BCQEWC2Nh QHgtdGVjLmRlMB4XDTAzMDUwODA3NTczMFoXDTA0MDUwNzA3NTczMFowgZgxCzAJBgNVBAYT AkRFMRAwDgYDVQQIEwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoTClgt dGVjIEdtYkgxDTALBgNVBAsTBElDTlMxGzAZBgNVBAMTEkNocmlzdGlhbiBIb2hlaXNlbDEi MCAGCSqGSIb3DQEJARYTYy5ob2hlaXNlbEB4LXRlYy5kZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMbT9rkd2kroI4ugzqiABiVYX+q15Slgs8TrX2KdsmGjqyp6v55RaNvE ++9zI/5hjjqtaNd1Pydvo8amSN9XbcmkFQ+Z6kivWNDk6hJbpF/bM5/hfmi7aqd3qAsr8Ji6 jjPTEcTo0bqrJ3SQOsm63vTBtzKHGLqHWL8ojouuo7GCQneE8UrnSq+MuVGniHM13l5D1hks C9zSPyhYBbYmPjmorvn825fngrHXw//AmD//Dck3x+Cy2fbbe+S4OEG91kctW2jr2vvwYHj5 fkfRozfx+6XUEMw3aZu0y3k/xU+KKLLARJLgU5czC1FiQdydBYUUIiUhlkVnG+uYN6BXV2cC AwEAAaOCAgQwggIAMAsGA1UdDwQEAwIDqDAdBgNVHQ4EFgQUJ0ysruBgrSCel6mpJ84jNWDM RdkwgbgGA1UdIwSBsDCBrYAUBiMUT7kjhY3EwQ0290IpQD+7+quhgZGkgY4wgYsxCzAJBgNV BAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoT ClgtdGVjIEdtYkgxDTALBgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1QgQ0ExGjAY BgkqhkiG9w0BCQEWC2NhQHgtdGVjLmRlggEAMB4GA1UdEQQXMBWBE2MuaG9oZWlzZWxAeC10 ZWMuZGUwFgYDVR0SBA8wDYELY2FAeC10ZWMuZGUwLAYDVR0fBCUwIzAhoB+gHYYbaHR0cHM6 Ly9jYS54LXRlYy5kZS9VQ0EuY3JsMBEGCWCGSAGG+EIBAQQEAwIFoDAjBglghkgBhvhCAQIE FhYUaHR0cHM6Ly9jYS54LXRlYy5kZS8wLgYJYIZIAYb4QgEIBCEWH2h0dHBzOi8vY2EueC10 ZWMuZGUvcG9saWN5Lmh0bWwwSQYJYIZIAYb4QgENBDwWOlRoaXMgY2VydGlmaWNhdGUgd2Fz IGlzc3VlZCBieSBhIFgtdGVjIEdtYkggLSBJQ05TIFVzZXIgQ0EwDQYJKoZIhvcNAQEEBQAD ggEBABdeSmeWQ3qzxtemIbDnfpe9wkTpBs0k3c5Z+xhXVt3GtTMsk8Je5rKCZLJunLllFVLG gwU7sMvb3769NDM5o9/OLjt59KWtNBBkj2BMU8cqFi8HkcVUrsjfW/bTY1/tvUnBi3izyNZm Wiw0dTK8w8yQFai8Ce5cr8wjEPUjLfMQf6MaN6RlOahX5BltEkjjh63ZbtqXmw2Jgu0Rq8Vf HUcj19qWmejBPr5LxdvOQM34bb0rYqxtmeJbwTXbZ+M0YGbZxtwaJNB6KcDlPEwlzwDr5m7I q/OVQL3DNa21iG/1Ehbg9vZB7VWSP9fs8ITNeb9jQD8oI58Q1XWTJgk907EwggWmMIIEjqAD AgECAgEFMA0GCSqGSIb3DQEBBAUAMIGLMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJp YTESMBAGA1UEBxMJUm9zZW5oZWltMRMwEQYDVQQKEwpYLXRlYyBHbWJIMQ0wCwYDVQQLEwRJ Q05TMRYwFAYDVQQDEw1YLXRlYyBST09UIENBMRowGAYJKoZIhvcNAQkBFgtjYUB4LXRlYy5k ZTAeFw0wMzA1MDgwNzU3MzBaFw0wNDA1MDcwNzU3MzBaMIGYMQswCQYDVQQGEwJERTEQMA4G A1UECBMHQmF2YXJpYTESMBAGA1UEBxMJUm9zZW5oZWltMRMwEQYDVQQKEwpYLXRlYyBHbWJI MQ0wCwYDVQQLEwRJQ05TMRswGQYDVQQDExJDaHJpc3RpYW4gSG9oZWlzZWwxIjAgBgkqhkiG 9w0BCQEWE2MuaG9oZWlzZWxAeC10ZWMuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDG0/a5HdpK6COLoM6ogAYlWF/qteUpYLPE619inbJho6sqer+eUWjbxPvvcyP+YY46 rWjXdT8nb6PGpkjfV23JpBUPmepIr1jQ5OoSW6Rf2zOf4X5ou2qnd6gLK/CYuo4z0xHE6NG6 qyd0kDrJut70wbcyhxi6h1i/KI6LrqOxgkJ3hPFK50qvjLlRp4hzNd5eQ9YZLAvc0j8oWAW2 Jj45qK75/NuX54Kx18P/wJg//w3JN8fgstn223vkuDhBvdZHLVto69r78GB4+X5H0aM38ful 1BDMN2mbtMt5P8VPiiiywESS4FOXMwtRYkHcnQWFFCIlIZZFZxvrmDegV1dnAgMBAAGjggIE MIICADALBgNVHQ8EBAMCA6gwHQYDVR0OBBYEFCdMrK7gYK0gnpepqSfOIzVgzEXZMIG4BgNV HSMEgbAwga2AFAYjFE+5I4WNxMENNvdCKUA/u/qroYGRpIGOMIGLMQswCQYDVQQGEwJERTEQ MA4GA1UECBMHQmF2YXJpYTESMBAGA1UEBxMJUm9zZW5oZWltMRMwEQYDVQQKEwpYLXRlYyBH bWJIMQ0wCwYDVQQLEwRJQ05TMRYwFAYDVQQDEw1YLXRlYyBST09UIENBMRowGAYJKoZIhvcN AQkBFgtjYUB4LXRlYy5kZYIBADAeBgNVHREEFzAVgRNjLmhvaGVpc2VsQHgtdGVjLmRlMBYG A1UdEgQPMA2BC2NhQHgtdGVjLmRlMCwGA1UdHwQlMCMwIaAfoB2GG2h0dHBzOi8vY2EueC10 ZWMuZGUvVUNBLmNybDARBglghkgBhvhCAQEEBAMCBaAwIwYJYIZIAYb4QgECBBYWFGh0dHBz Oi8vY2EueC10ZWMuZGUvMC4GCWCGSAGG+EIBCAQhFh9odHRwczovL2NhLngtdGVjLmRlL3Bv bGljeS5odG1sMEkGCWCGSAGG+EIBDQQ8FjpUaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg YnkgYSBYLXRlYyBHbWJIIC0gSUNOUyBVc2VyIENBMA0GCSqGSIb3DQEBBAUAA4IBAQAXXkpn lkN6s8bXpiGw536XvcJE6QbNJN3OWfsYV1bdxrUzLJPCXuaygmSybpy5ZRVSxoMFO7DL29++ vTQzOaPfzi47efSlrTQQZI9gTFPHKhYvB5HFVK7I31v202Nf7b1JwYt4s8jWZlosNHUyvMPM kBWovAnuXK/MIxD1Iy3zEH+jGjekZTmoV+QZbRJI44et2W7al5sNiYLtEavFXx1HI9falpno wT6+S8XbzkDN+G29K2KsbZniW8E122fjNGBm2cbcGiTQeinA5TxMJc8A6+ZuyKvzlUC9wzWt tYhv9RIW4Pb2Qe1Vkj/X7PCEzXm/Y0A/KCOfENV1kyYJPdOxMYIDujCCA7YCAQEwgZEwgYsx CzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzAR BgNVBAoTClgtdGVjIEdtYkgxDTALBgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1Qg Q0ExGjAYBgkqhkiG9w0BCQEWC2NhQHgtdGVjLmRlAgEFMAkGBSsOAwIaBQCgggH9MBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkxMjE2Mjk0MFowIwYJ KoZIhvcNAQkEMRYEFB3uDz/3wwVZPnuzleIB2yPzuEpcMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGiBgkrBgEEAYI3EAQxgZQwgZEwgYsxCzAJBgNVBAYTAkRFMRAwDgYDVQQI EwdCYXZhcmlhMRIwEAYDVQQHEwlSb3NlbmhlaW0xEzARBgNVBAoTClgtdGVjIEdtYkgxDTAL BgNVBAsTBElDTlMxFjAUBgNVBAMTDVgtdGVjIFJPT1QgQ0ExGjAYBgkqhkiG9w0BCQEWC2Nh QHgtdGVjLmRlAgEFMIGkBgsqhkiG9w0BCRACCzGBlKCBkTCBizELMAkGA1UEBhMCREUxEDAO BgNVBAgTB0JhdmFyaWExEjAQBgNVBAcTCVJvc2VuaGVpbTETMBEGA1UEChMKWC10ZWMgR21i SDENMAsGA1UECxMESUNOUzEWMBQGA1UEAxMNWC10ZWMgUk9PVCBDQTEaMBgGCSqGSIb3DQEJ ARYLY2FAeC10ZWMuZGUCAQUwDQYJKoZIhvcNAQEBBQAEggEAWXgZGL+/tV8E2NVfTWerQlzb A8euk9XHXv7QeO84pSI3a585gqEoq43RtSPpvfW4oD+tXgT9biQxEaVSuGZ0O/yp0wEXZncX 77ZHBe9IeatEf30a2pYHCyqMeFOgMo5b7WPosBq5oSgbPD9GDGXXYwOYfB1hFE4QG2/q4UzV yWicgHxP3Caji/jU+LpGlGd66pASNpXTycBQ6gG67owPG1j2m8ZMa7zEYsmOmEN6ZbpSvrGK BaEJzWdIzWtzdQpEKzSpE7Tm28YrygJhTAitP/c5ox4EmfE92arYNDcV4OUHE0I9AMteIREA CDqc9OpkjjBYoYX5hNRd8ueT6HrhogAAAAAAAA== --------------ms060607040804040508090000-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 12:42:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03318 for ; Fri, 12 Sep 2003 12:42:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqzL-0002yV-3o for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:41:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGfdPG011426 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqzK-0002y8-02 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:41:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03057 for ; Fri, 12 Sep 2003 12:41:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqzI-0001mr-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 12:41:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xqzG-0001mo-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 12:41:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqym-0002bq-4y; Fri, 12 Sep 2003 12:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqyg-0002YW-M8 for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 12:40:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02945 for ; Fri, 12 Sep 2003 12:40:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqyf-0001jz-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:40:57 -0400 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19xqyc-0001jg-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:40:55 -0400 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19xqyP-0004vX-00; Fri, 12 Sep 2003 17:40:41 +0100 Date: Fri, 12 Sep 2003 17:40:41 +0100 To: George Gross Cc: ipv6@ietf.org Subject: Re: set Global ID field to SHA hash of domain name Message-ID: <20030912164041.GI21333@fysh.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , George Gross wrote: > At the risk of triggering another firestorm of pro/con debate, is >there any reason why the centrally assigned Global ID defined by >hinden-ipv6-global-local-addr-02.txt could not be simply the low-order 40 >bits of a SHA hash of a domain name? i.e. if you own the domain name, you >get the IP-v6 global ID for "free"? That sounds like a decent way of generating a locally assigned ID, but it doesn't have the uniqueness guarantee that is the raison d'etre for the central registry. You Have Missed The Point, as one of my favourite games can be provoked into saying. -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 12:53:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04022 for ; Fri, 12 Sep 2003 12:53:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrAX-0003fv-5a for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:53:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGrDeN014121 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrAW-0003fg-WC for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:53:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03958 for ; Fri, 12 Sep 2003 12:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrAV-00023O-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 12:53:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xrAU-00023L-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 12:53:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrAL-0003al-Bk; Fri, 12 Sep 2003 12:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrA5-0003aL-Sq for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 12:52:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03931 for ; Fri, 12 Sep 2003 12:52:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrA4-00022f-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:52:44 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19xrA3-00022c-00 for ipv6@ietf.org; Fri, 12 Sep 2003 12:52:43 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8CGqvxS061601; Fri, 12 Sep 2003 18:52:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 12 Sep 2003 18:52:41 +0200 Subject: Re: set Global ID field to SHA hash of domain name Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: George Gross From: Iljitsch van Beijnum In-Reply-To: Message-Id: <864B084D-E541-11D7-A80C-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On vrijdag, sep 12, 2003, at 11:07 Europe/Amsterdam, George Gross wrote: > At the risk of triggering another firestorm of pro/con debate, is > there any reason why the centrally assigned Global ID defined by > hinden-ipv6-global-local-addr-02.txt could not be simply the low-order > 40 > bits of a SHA hash of a domain name? i.e. if you own the domain name, > you > get the IP-v6 global ID for "free"? This would side step the angst of > setting up yet another global registry... Hm, with 2^40 possible prefixes and already something in the order of 2^25 domains in use, I expect collisions will be a definite factor. I would also be interested in seeing how the SHA-1 algorithm holds up. Anyone care to get a suitably large list of domain names (a million or so) and do some statistics on the lower 40 bits of the associated SHA-1 hash? It did occur to me that the domain name sellers are in a better position to give out these prefixes than the traditional IP address registries, though. Especially if you consider that they'd just be selling domain names under c.f.ip6.arpa. :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 13:06:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04863 for ; Fri, 12 Sep 2003 13:06:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrMZ-0004qP-HQ for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 13:05:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CH5dDW018613 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 13:05:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrMZ-0004q8-98 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 13:05:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04823 for ; Fri, 12 Sep 2003 13:05:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrMX-0002KT-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 13:05:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xrMX-0002KQ-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 13:05:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrLz-0004hN-Kl; Fri, 12 Sep 2003 13:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrLc-0004gg-1P for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 13:04:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04762 for ; Fri, 12 Sep 2003 13:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrLa-0002JB-00 for ipv6@ietf.org; Fri, 12 Sep 2003 13:04:38 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19xrLZ-0002Ia-00 for ipv6@ietf.org; Fri, 12 Sep 2003 13:04:37 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8CH99P21976 for ; Fri, 12 Sep 2003 10:09:09 -0700 Date: Fri, 12 Sep 2003 10:04:05 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1770226320.20030912100405@brandenburg.com> To: IPV6 WG Subject: Re: domain names as end-point identifiers? In-Reply-To: <3F5F150A.62ACA5C8@zurich.ibm.com> References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Thanks for the responses. I decided to send one, aggregate response, rather than a flood of smaller ones: Dredging up some graduate school discussions, I suspect that this topic is differentiated between the classic "network" model of host to host communication, versus the "distributed processing" model of process to process communication. In the early 70's, for example, the Irvine Ring project (and, by the way, Netbios, later) use the process-oriented model. For wide-area networking, this has not gained much traction, at the lower packet-handling levels. (It was even interesting to watch MIT take over the Irvine work and eliminate the process addressing function.) My point is that I'm suspecting some folks are trying to lay a very different reference model onto the Internet than we have been using for the last 30 years. Hence, the discussion about multihoming and mobility gets changed into what is really an effort to change the Internet's communication reference paradigm. BEC> If you are looking for stable identifiers for "stacks" (in the BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely BEC> that an FQDN is a safe answer. It is probably worth noting that the NSRG report uses domain names to label the different stacks, in its own examples and in discussion. Whatever the reasons for that choice, I obviously find it interesting that they were used for that purpose. BEC> FQDNs are (mis)used in many ways; BEC> a name like www.example.com certainly doesn't identify a given IP stack BEC> on a given interface on a given host 1. When someone starts talking about identifying _interfaces_ I suspect they mean address, rather than 'end point identifier'. On the assumption that that is not what Brian meant, it's worth having this clarified. I'm confused by Bill's comment on this: " if there is an entity at a point in the topology, then the name maps nicely into the DNS". Domain names are not tied to network topology. They are tied to an administrative "topology", which is an entirely different thing. 2. If I understand the concern, here, it is that not _all_ domain names are endpoint identifiers. Erik also raised the point that domain names are used for different (and inconsistent?) purposes. One might be a host, another a service. When there are multiple records returned, they might refer to alternative systems or they might be alternate paths to the same service. My question is: so why does that mean that the ones that _are_ EIDs are not acceptable? What problems are caused by having multiple uses? BEC> I don't see that this has any functional advantage over an IPv6 address BEC> for that stack, and it introduces a DNS dependency for the transport layer. 1. I thought an IPv6 address was an address, not an end-point identifier. No? 2. The concern about introducing a DNS dependency into a lower layer, like transport, strikes me as pretty important, too. However, if we invent a new construct for an EID, we are a) introducing a new global administration requirement, and b) creating a dependency on it in that lower layer. So the concern with this new dependency is on the need for an EID, rather than the fact that it might be a domain name. No? MT> In the case of mobility and multihoming, you might want a stable MT> identifier on a per-packet basis which is independent of the routing MT> layer. A number of folks clearly have in mind using the identifier in every packet. My question is: Why is this needed? What requires putting the identifier in every packet, rather than using it a occasional, special points of an interaction, such as initial rendezvous? Erik's comments are particularly helpful for considering the requirements that folks are trying to satisfy: EN> It might be useful to split your question apart into two questions: EN> 1. Using current domain names and their mapping to AAAA records (or A records or even MX records or SRV records?) At any rate, this is the rendezvous function. EN> 2. Using variable length identifiers Or, to turn this one around, explaining when and why fixed-length IDs might be needed. EN> For #1 folks have pointed out that a currently domain names are often used EN> as service names and not host names, and one can't tell... my question is what problems are caused by multiple uses for domain names? how does it break the usage as endpoint ids? EN> I've also seen statements in the past that current domain name usage isn't EN> one that guarantees uniqness. I guess this underscores the need to be clear about the set of problems being tackled. Let's remember that IP datagrams are pretty basic. There are lots of very clever, useful things they do _not_ do. Are we, perhaps, trying to add other functionality to the IP service, beyond simply providing the current IP service, enhanced to support multihoming and mobility? For example, are we trying to add extra levels of security to the basic service, beyond simply making the use of multiple addresses carry the same, minimal security functions present for current, single-address IP? The "security" associated with a current, bare-bones mono-address host-to-host IP exchange is pretty darn small. I'd summarize it as simply being the assertion that a datagram probably did come from the IP address in the relevant field of the datagram. That's why MAST only tries to ensure an equivalent degree of assurance that latter datagrams with different IP addresses came from the same "system" that sent the first one. If you really need stronger security, use IPSEC, TLS, or whatever. Why do we need more, at the IP level for multihoming or mobility? EN> One example of this are cases when EN> www.example.com brings you to different http content from the inside of the EN> company than from the outside of the company. Clearly this is an important behavior. But should it be discerned at the IP level, or is this better suited to something above, say, transport? EN> I think all these can be addressed and still use FQDNs as identifiers. EN> (For instance by having some different RRtype which allows telling "service" EN> apart from "host".) Not surprisingly, I agree. EN> The issues around #2 has to do with how the protocols above IP operate. EN> If the identifier is only used to establish some state which is only used EN> when the locators change, then it is possible to have the upper layer protocols EN> operate on the locators when sending and receiving packets. Thus you'd have EN> multi-locator ULPs. ... EN> An alternate approach, which requires fixed length identifiers which can fit EN> into existing 128 bit fields, is to have a shim layer above IP which handles EN> id<->locator mappings and have the ULPs operate on the identifiers. Given the MAST proposal, obviously I favor the latter. However it's also clear that I do not believe the EID needs to be in every packet. I think it is a question of where some state information goes. One is to have the ID in every packet, making the IP address irrelevant. (The packet carries its own 'state' about the EID.) The alternative is to have a table of IP addresses that the EID maps to, and maintain the table in the participating hosts. Hence the IP address in the packet indexes to the EID when it is received.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 14:07:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07465 for ; Fri, 12 Sep 2003 14:07:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsJY-0007ce-VM for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 14:06:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CI6aJD029294 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 14:06:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsJY-0007cP-QT for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 14:06:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07396 for ; Fri, 12 Sep 2003 14:06:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xsJW-00039M-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:06:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xsJV-00039J-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:06:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsJ0-0007Tj-Ve; Fri, 12 Sep 2003 14:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsIu-0007TM-J3 for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 14:05:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07378 for ; Fri, 12 Sep 2003 14:05:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xsIs-00038u-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:05:54 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 19xsIr-00038X-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:05:53 -0400 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2939B1C; Fri, 12 Sep 2003 21:18:41 +0300 (EEST) Message-ID: <3F620ADF.2050005@nomadiclab.com> Date: Fri, 12 Sep 2003 21:05:19 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: IPV6 WG Subject: Re: About DHTs, byzantine robustness, and security (was Re: A roadmap for end-point identifiers? ...) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch, Iljitsch van Beijnum wrote: > So you're afraid that when to people communicate without proper security > mechanisms in place, others might suffer? Exactly. That I have been trying to say all the way along. > I agree that we shouldn't add to existing attack vectors, Good! > but I doubt that we can solve this general case here and now. I don't know what you mean with the general case. My point has been that if we do introduce the id/loc separation then we have to take care of security, in order to not to add new vulnerabilities. Perhaps I have not been able to say this clearly enough. If you don't care about security when you do the separation, the consequences can be severe. We do need crypto to fix the potential problems. We do not necessarily need cryptographic identifiers, but cryptographic identifiers help, and potentially make the system much more secure. Once more: There is no intrinsic need to protect the actual data traffic (even though I think it would be good in most cases), but we do have to protect the signalling traffic that verifies and updates the id->locs mappings in the end-hosts. Since we have to place the appopriate protection mechanisms there, I do not think that we can easily allow zillions of different protocols there, as you were suggesting. Two or three maybe (LIN6, HIP, MAST, counting.... :-), but more than that may have difficulties in getting through the IESG due to the security requirements. > Hm, I think Smurf attacks were pretty successful in singlehomed fixed > location IPv4 networks. There is a huge difference between someone getting nodes to reflect single spoofed packets and someone legitimately redirecting complete data streams, and only *then* starting to spoof acoknowledgements to keep those data streams running. I know, the MIPv6 RO security background draft is long. But I don't have time to try to distill a shorter version of it right now. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 14:13:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08106 for ; Fri, 12 Sep 2003 14:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsPs-0000JG-15 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 14:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CID72p001184 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 14:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsPr-0000J1-S3 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 14:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08047 for ; Fri, 12 Sep 2003 14:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xsPp-0003PY-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:13:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xsPp-0003PV-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsPm-0000Ed-KW; Fri, 12 Sep 2003 14:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsPZ-0000Db-Hq for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 14:12:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08016 for ; Fri, 12 Sep 2003 14:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xsPX-0003OP-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:12:47 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx with smtp (Exim 4.12) id 19xsPW-0003OB-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:12:46 -0400 Received: (qmail 73400 invoked by uid 1000); 12 Sep 2003 18:12:43 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.04989 secs); 12 Sep 2003 18:12:43 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 12 Sep 2003 18:12:42 -0000 Received: (qmail 91687 invoked from network); 12 Sep 2003 18:12:34 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.174) by smtp-auth.nac.net with SMTP; 12 Sep 2003 18:12:34 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8CG3Q603956; Fri, 12 Sep 2003 12:03:26 -0400 Date: Fri, 12 Sep 2003 12:03:26 -0400 (EDT) From: George Gross To: Zefram cc: Subject: Re: set Global ID field to SHA hash of domain name In-Reply-To: <20030912164041.GI21333@fysh.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Zefram, On Fri, 12 Sep 2003, Zefram wrote: > George Gross wrote: > > At the risk of triggering another firestorm of pro/con debate, is > >there any reason why the centrally assigned Global ID defined by > >hinden-ipv6-global-local-addr-02.txt could not be simply the low-order 40 > >bits of a SHA hash of a domain name? i.e. if you own the domain name, you > >get the IP-v6 global ID for "free"? > > That sounds like a decent way of generating a locally assigned ID, but > it doesn't have the uniqueness guarantee that is the raison d'etre for > the central registry. You Have Missed The Point, as one of my favourite > games can be provoked into saying. hmmm... I'm not religous about whether the mechanism gets used locally only or centrally or both. For the central registry, could we define a reverse DNS lookup to verify the hash's uniquesness? Even if the first reverse DNS probe proved not to be unique, one could append a well-specified computed string, such as "0", "1", "2", ... to the domain name on each successive attempt, until the hash's uniqueness was confirmed. George > > -zefram > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 14:43:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09297 for ; Fri, 12 Sep 2003 14:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xst1-0001ul-3J for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 14:43:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CIhFm7007353 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 14:43:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xst0-0001uW-TZ for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 14:43:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09246 for ; Fri, 12 Sep 2003 14:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xssy-0003jX-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:43:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xssx-0003jU-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsso-0001qP-Vc; Fri, 12 Sep 2003 14:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xssM-0001pq-IN for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 14:42:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09221 for ; Fri, 12 Sep 2003 14:42:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xssJ-0003iX-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:42:31 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx with smtp (Exim 4.12) id 19xssJ-0003iU-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:42:31 -0400 Received: (qmail 44696 invoked by uid 1000); 12 Sep 2003 18:42:31 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.045616 secs); 12 Sep 2003 18:42:31 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 12 Sep 2003 18:42:31 -0000 Received: (qmail 71685 invoked from network); 12 Sep 2003 18:42:19 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.174) by smtp-auth.nac.net with SMTP; 12 Sep 2003 18:42:19 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8CGXCX03986; Fri, 12 Sep 2003 12:33:12 -0400 Date: Fri, 12 Sep 2003 12:33:12 -0400 (EDT) From: George Gross To: Iljitsch van Beijnum cc: George Gross , Subject: Re: set Global ID field to SHA hash of domain name In-Reply-To: <864B084D-E541-11D7-A80C-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Iljitsch, On Fri, 12 Sep 2003, Iljitsch van Beijnum wrote: > On vrijdag, sep 12, 2003, at 11:07 Europe/Amsterdam, George Gross wrote: > > > At the risk of triggering another firestorm of pro/con debate, is > > there any reason why the centrally assigned Global ID defined by > > hinden-ipv6-global-local-addr-02.txt could not be simply the low-order > > 40 > > bits of a SHA hash of a domain name? i.e. if you own the domain name, > > you > > get the IP-v6 global ID for "free"? This would side step the angst of > > setting up yet another global registry... > > Hm, with 2^40 possible prefixes and already something in the order of > 2^25 domains in use, I expect collisions will be a definite factor. In a parallel e-mail to Zefram, I offered an algorithm for probing for uniqueness, and then retrying. OTOH, if you merely want a genuinely local pseudo-random number, then the collision factor is moot. > I would also be interested in seeing how the SHA-1 algorithm holds up. > Anyone care to get a suitably large list of domain names (a million or > so) and do some statistics on the lower 40 bits of the associated > SHA-1 hash? SHA-1 has fairly strong hashing properties, even changing one bit in the input yields a reasonably diverse output. OTOH, I'm not a cryptographer, though I'll add that most of what I've heard about SHA-1 is that it is held in high regard. FYI, you may wish to dredge the IRTF CFRG e-mail archives for the thread with the Subject line of "one question about hash" that occured in July of this year. The good news about those 2^25 domain name holders is that they are the most likely consumers of this local IP-v6 address prefix, and they would immediately inherit their's for free without doing anything. > > It did occur to me that the domain name sellers are in a better > position to give out these prefixes than the traditional IP address > registries, though. Especially if you consider that they'd just be > selling domain names under c.f.ip6.arpa. :-) > Another implicit benefit is that every domain name holder already has a local IP-v6 prefix allocated on the shelf waiting for them. Musing outloud, I wonder how that could be leveraged to automatically compute the IP-v6 address of any IP-v4 endpoint for which you know the FQDN and your DNS query returned an IP-v4 address record. br, George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 15:05:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10343 for ; Fri, 12 Sep 2003 15:05:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtDm-0002x9-69 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 15:04:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CJ4g6E011351 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 15:04:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtDl-0002x0-V6 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 15:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10228 for ; Fri, 12 Sep 2003 15:04:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtDh-000460-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 15:04:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xtDh-00045w-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 15:04:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtD7-0002o6-V8; Fri, 12 Sep 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtCo-0002nM-LA for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 15:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10101 for ; Fri, 12 Sep 2003 15:03:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtCk-00044N-00 for ipv6@ietf.org; Fri, 12 Sep 2003 15:03:38 -0400 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 19xtCj-00044J-00 for ipv6@ietf.org; Fri, 12 Sep 2003 15:03:37 -0400 Received: from ssprunk (ip135.post-vineyard.dfw.interquest.net [66.135.181.135]) by ns2.sea (8.12.9/8.12.5) with SMTP id h8CJ3HCr023124; Fri, 12 Sep 2003 12:03:17 -0700 Message-ID: <00d601c37960$89c29d40$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "George Gross" , "Iljitsch van Beijnum" Cc: References: <864B084D-E541-11D7-A80C-00039388672E@muada.com> Subject: Re: set Global ID field to SHA hash of domain name Date: Fri, 12 Sep 2003 13:50:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Iljitsch van Beijnum" > It did occur to me that the domain name sellers are in a better > position to give out these prefixes than the traditional IP address > registries, though. Especially if you consider that they'd just be > selling domain names under c.f.ip6.arpa. :-) The same thought occurred to me several months ago; the draft even references the .org registry -- not an RIR -- as a model of how the allocating authority could be structured. Also, thinking of this in a domain mindset caused me to rethink whether local addresses should be in the global DNS. I can understand the arguments against it, but as the draft says, there's no harm. Given the (expected) sparse population of FC00::/8, the only reason anyone is likely to go looking for a PTR record is if they received a packet from that prefix -- meaning they probably have a legitimate reason to know who sent it. A specific example would be two private sites, such as business partners, that use their local addresses to communicate; these sites should be able to resolve each others' addresses without mucking around with every DNS server to list "special" zones that aren't in the global DNS. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 16:35:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14509 for ; Fri, 12 Sep 2003 16:35:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xud0-00076X-Ba for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 16:34:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CKYoC7027303 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 16:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xud0-00076I-5S for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 16:34:50 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14442 for ; Fri, 12 Sep 2003 16:34:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xuaI-0006fk-DM; Fri, 12 Sep 2003 16:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xtW8-0003u1-KG for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 15:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12039 for ; Fri, 12 Sep 2003 15:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtW6-0004LT-00 for ipv6@ietf.org; Fri, 12 Sep 2003 15:23:38 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19xtW6-0004LI-00 for ipv6@ietf.org; Fri, 12 Sep 2003 15:23:38 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3A05D14088; Fri, 12 Sep 2003 15:23:38 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21920-08; Fri, 12 Sep 2003 15:23:37 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8169814001; Fri, 12 Sep 2003 15:23:37 -0400 (EDT) Date: Fri, 12 Sep 2003 15:23:37 -0400 From: Keith Moore To: Dave Crocker Cc: moore@cs.utk.edu, dhc2@dcrocker.net, ipv6@ietf.org Subject: Re: domain names as end-point identifiers? Message-Id: <20030912152337.45c24ee8.moore@cs.utk.edu> In-Reply-To: <1770226320.20030912100405@brandenburg.com> References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> <1770226320.20030912100405@brandenburg.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Dredging up some graduate school discussions, I suspect that this > topic is differentiated between the classic "network" model of host to > host communication, versus the "distributed processing" model of > process to process communication. I think this is an exaggeration. But as long as primary memory is private to hosts and processes (i.e. not accessible by other hosts or processes running the same applications or services), there will be a need to rendezvous with, and refer to, specific hosts running specific processes that have sole access to state that is critical for continued operation of an instance of an application. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 17:08:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16400 for ; Fri, 12 Sep 2003 17:08:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xv9I-0000WO-SR for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 17:08:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CL8Chu001997 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 17:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xv9H-0000W8-6X for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 17:08:11 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16280 for ; Fri, 12 Sep 2003 17:08:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xv7C-0008TT-Kv; Fri, 12 Sep 2003 17:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xv6t-0008Sc-7h for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 17:05:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16154 for ; Fri, 12 Sep 2003 17:05:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xv6o-0005a3-00 for ipv6@ietf.org; Fri, 12 Sep 2003 17:05:38 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19xv6m-0005a0-00 for ipv6@ietf.org; Fri, 12 Sep 2003 17:05:37 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3234E140D9 for ; Fri, 12 Sep 2003 17:05:34 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01148-07; Fri, 12 Sep 2003 17:05:33 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8AD2213FCD; Fri, 12 Sep 2003 17:05:32 -0400 (EDT) X-Original-To: moore@cs.utk.edu Date: Fri, 12 Sep 2003 16:57:39 -0400 From: Keith Moore To: "Randall R. Stewart (home)" Cc: moore@cs.utk.edu, alh-ietf@tndh.net, ietf@ietf.org, ipng@sunroof.eng.sun.com Message-Id: <20030912165739.50b3866b.moore@cs.utk.edu> In-Reply-To: <3F61EAC2.7020304@stewart.chicago.il.us> References: <01df01c36a7b$840dbb80$63124104@eagleswings> <3F61EAC2.7020304@stewart.chicago.il.us> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Resent-Date: Fri, 12 Sep 2003 17:02:28 -0400 Resent-From: Keith Moore Resent-To: ipv6@ietf.org Resent-To: moore@cs.utk.edu Subject: Re: Solving the right problems ... Resent-Message-Id: <20030912170228.07481a0f.moore@cs.utk.edu> X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Tony Hain wrote: > > >In the ongoing saga about topology reality vs. application perception of > >stability, it occurs to me we are not working on the right problem. In > >short we have established a sacred invariant in the application / transport > >interface, and the demands on either side of that interface are the root of > >conflict. > > > >Mobile IP, and the multi6 DHT work are attempts to mitigate it through > >slight of hand at the IP layer, while SCTP attempts to mask the topology > >reality in the transport layer. (These are probably not the only examples, > >but they are the ones that come to mind this morning.) Yet none of these > >really do the job in all cases. > > > > SCTP seems to me to do most of what you propose in this "layer"... assuming > an SCTP that includes the ADD-IP extension I can (and I have done this > with the KAME stack) [...] Yes, SCTP does *most* of this. It can handle the case where one party of a connection moves, and it is able to tell its peer that it has moved. IIRC, it doesn't handle concurrent moving of both connection endpoints (even if both endpoints are in the same network), nor does it handle cases where timely notice cannot be provided. Nor does it handle rendezvous or referral because in those cases there's not a constantly-open connection over which to signal locator changes. So I don't view the SCTP approach as a complete solution, but it might be useful as part of a solution. Also, I'm not insisting on a separate layer. As far as I can tell, some of the changes needed could take the form of backward-compatible modifications to TCP and UDP and perhaps SCTP also, and I certainly think it's worth considering those techniques. Whether this is best handled by changes to layer 4 (and perhaps layer 3 also if we need support from the routers), or a new layer between 3 and 4, is not something I claim to have analyzed in detail. (OTOH, I am insisting that it's not reasonable to try to solve the entire problem above layer 4. For different reasons - mostly economic - I suspect it's not reasonable to try to solve the entire problem below layer 4 either, but I'm less sure of this.) > We could do has Keith has proposed.. put it at a layer BELOW the > transport. Now, what do we end up with? > > 1) A NAT like thing that is playing games with the IP addresses and > checksums (aka the psuedo-header) > > 2) Putting a psuedo IP address (the identifier) on the machine for the > app to use apart and > seperate from the real physical IP address in use. I don't think the two are inherently that different. Say you define a new identifier that can be associated with a connection endpoint, and you build a mechanism that allows a host to map that identifier to one or more locators. Now you can tweak TCP to allow it to define either or both of its connection endpoints (what is now the pseudo-header) in terms of those identifiers rather than in terms of the locators currently in use, and you tweak the demux layer on hosts that support this extension so that it can accept multiple source,destination locator pairs and map each of them into the same TCP channel that is defined in terms of endpoint identifiers. Then you define ways of doing signalling via TCP options so that the hosts can learn about new locators and deprecated locators for their peers. I see this as a variant of your #2, but it also has a vague resemblance to NAT. However, I don't think this has any of the problems of NAT. Essentially what it would accomplish is to cleanly separate connection endpoint identifiers from locators, which people have been saying was a good idea for a long time. And I think it could be done in such a way that it is fairly compatible with existing apps that use TCP. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 17:48:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18258 for ; Fri, 12 Sep 2003 17:48:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvmL-00034Q-Ig for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 17:48:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CLmXJ4011792 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 17:48:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvmL-000347-8i for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 17:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18209 for ; Fri, 12 Sep 2003 17:48:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xvmI-0006HW-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 17:48:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xvmI-0006HO-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 17:48:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvlq-0002w5-Sa; Fri, 12 Sep 2003 17:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvle-0002vd-VL for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 17:47:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18192 for ; Fri, 12 Sep 2003 17:47:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xvlc-0006Gm-00 for ipv6@ietf.org; Fri, 12 Sep 2003 17:47:48 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 19xvlb-0006GK-00 for ipv6@ietf.org; Fri, 12 Sep 2003 17:47:47 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h8CLlHv8014581 for ; Fri, 12 Sep 2003 16:47:17 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Fri, 12 Sep 2003 16:46:58 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830837B0F0@eammlex037.lmc.ericsson.se> From: "Suresh Krishnan (QB/EMC)" To: "'ipv6@ietf.org'" Subject: Test - please ignore Date: Fri, 12 Sep 2003 16:47:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37977.69B04176" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37977.69B04176 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C37977.69B04176 Content-Type: text/html; charset="iso-8859-1"
 
------_=_NextPart_001_01C37977.69B04176-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 19:45:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22318 for ; Fri, 12 Sep 2003 19:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xxbA-0007AC-Ta for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 19:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CNj85b027530 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 19:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xxbA-00079x-Ow for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 19:45:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22258 for ; Fri, 12 Sep 2003 19:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xxb9-0007Jr-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 19:45:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xxb8-0007Jo-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 19:45:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xxa5-00071M-Gr; Fri, 12 Sep 2003 19:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xxZj-00070t-AO for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 19:43:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22217 for ; Fri, 12 Sep 2003 19:43:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xxZh-0007Ic-00 for ipv6@ietf.org; Fri, 12 Sep 2003 19:43:37 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19xxZg-0007IT-00 for ipv6@ietf.org; Fri, 12 Sep 2003 19:43:37 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8CNmAP13618 for ; Fri, 12 Sep 2003 16:48:10 -0700 Date: Fri, 12 Sep 2003 16:43:04 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <15294165342.20030912164304@brandenburg.com> To: IPV6 WG Subject: Re: domain names as end-point identifiers? In-Reply-To: <3F5F150A.62ACA5C8@zurich.ibm.com> References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Thanks for the responses. I decided to send one, aggregate response, rather than a flood of smaller ones.: Dredging up some graduate school discussions, I suspect that this topic is differentiated between the classic "network" model of host to host communication, versus the "distributed processing" model of process to process communication. In the early 70's, for example, the Irvine Ring project (and, by the way, Netbios, later) use this process model. For wide-area networking, this has not gained much traction, at the lower packet-handling levels. (It was even interesting to watch MIT take over the Irvine work and eliminate the process addressing function.) My point is that I'm suspecting some folks are trying to lay a very different reference model onto the Internet than we have been using for the last 30 years. BEC> If you are looking for stable identifiers for "stacks" (in the BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely BEC> that an FQDN is a safe answer. It is probably worth noting that the NSRG report uses domain names to label the different stacks, in its own examples and in discussion. Whatever the reasons for that choice, I obviously find it interesting that they were used for that purpose. BEC> FQDNs are (mis)used in many ways; BEC> a name like www.example.com certainly doesn't identify a given IP stack BEC> on a given interface on a given host 1. When someone starts talking about identifying _interfaces_ I suspect they mean address, rather than 'end point identifier'. On the assumption that that is not what Brian meant, it's worth having this clarified. I'm confused by Bill's comment on this: " if there is an entity at a point in the topology, then the name maps nicely into the DNS". Domain names are not tied to network topology. They are tied to an administrative "topology", which is an entirely different thing. 2. If I understand the concern, here, it is that not _all_ domain names are endpoint identifiers. Erik also raised the point that domain names are used for different (and inconsistent?) purposes. One might be a host, another a service. When there are multiple records returned, they might refer to alternative systems or they might be alternate paths to the same service. My question is: so why does that mean that the ones that _are_ EIDs are not acceptable? What problems are caused by having multiple uses? BEC> I don't see that this has any functional advantage over an IPv6 address BEC> for that stack, and it introduces a DNS dependency for the transport layer. 1. I thought an IPv6 address was an address, not an end-point identifier. No? 2. The concern about introducing a DNS dependency into a lower layer, like transport, strikes me as pretty important, too. However, if we invent a new construct for an EID, we are a) introducing a new global administration requirement, and b) creating a dependency on it in that lower layer. So the concern with this new dependency is on the need for an EID, rather than the fact that it might be a domain name. No? MT> In the case of mobility and multihoming, you might want a stable MT> identifier on a per-packet basis which is independent of the routing MT> layer. A number of folks clearly have in mind using the identifier in every packet. My question is: Why is this needed? What requires putting the identifier in every packet, rather than using it a occasional, special points of an interaction, such as initial rendezvous? Erik's comments are particularly helpful for considering the requirements that folks are trying to satisfy: EN> It might be useful to split your question apart into two questions: EN> 1. Using current domain names and their mapping to AAAA records (or A records or even MX records or SRV records?) At any rate, this is the rendezvous function. EN> 2. Using variable length identifiers Or, to turn this one around, explaining when and why fixed-length IDs might be needed. EN> For #1 folks have pointed out that a currently domain names are often used EN> as service names and not host names, and one can't tell... my question is what problems are caused by multiple uses for domain names? how does it break the usage as endpoint ids? EN> I've also seen statements in the past that current domain name usage isn't EN> one that guarantees uniqness. I guess this underscores the need to be clear about the set of problems being tackled. Let's remember that IP datagrams are pretty basic. There are lots of very clever, useful things they do _not_ do. Are we, perhaps, trying to add other functionality to the IP service, beyond simply providing the current IP service, enhanced to support multihoming and mobility? For example, are we trying to add extra levels of security to the basic service, beyond simply making the use of multiple addresses carry the same, minimal security functions present for current, single-address IP? The "security" associated with a current, bare-bones mono-address host-to-host IP exchange is pretty darn small. I'd summarize it as simply being the assertion that a datagram probably did come from the IP address in the relevant field of the datagram. That's why MAST only tries to ensure an equivalent degree of assurance that latter datagrams with different IP addresses came from the same "system" that sent the first one. If you really need stronger security, use IPSEC, TLS, or whatever. Why do we need more, at the IP level for multihoming or mobility? EN> One example of this are cases when EN> www.example.com brings you to different http content from the inside of the EN> company than from the outside of the company. Clearly this is an important behavior. But should it be discerned at the IP level, or is this better suited to something above, say, transport? EN> I think all these can be addressed and still use FQDNs as identifiers. EN> (For instance by having some different RRtype which allows telling "service" EN> apart from "host".) Not surprisingly, I agree. EN> The issues around #2 has to do with how the protocols above IP operate. EN> If the identifier is only used to establish some state which is only used EN> when the locators change, then it is possible to have the upper layer protocols EN> operate on the locators when sending and receiving packets. Thus you'd have EN> multi-locator ULPs. ... EN> An alternate approach, which requires fixed length identifiers which can fit EN> into existing 128 bit fields, is to have a shim layer above IP which handles EN> id<->locator mappings and have the ULPs operate on the identifiers. Given the MAST proposal, obviously I favor the latter. However it's also clear that I do not believe the EID needs to be in every packet. I think it is a question of where some state information goes. One is to have the ID in every packet, making the IP address irrelevant. (The packet carries its own 'state' about the EID.) The alternative is to have a table of IP addresses that the EID maps to, and maintain the table in the participating hosts. Hence the IP address in the packet indexes to the EID when it is received.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 12 20:52:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23839 for ; Fri, 12 Sep 2003 20:52:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xyeA-0000uy-Jn for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 20:52:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8D0qI4s003517 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 20:52:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xyeA-0000ue-6j for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 20:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23779 for ; Fri, 12 Sep 2003 20:52:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xye7-00003v-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 20:52:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xye7-00003p-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 20:52:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xycx-0000lb-Ms; Fri, 12 Sep 2003 20:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xybw-0000l6-9n for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 20:50:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23733 for ; Fri, 12 Sep 2003 20:49:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xybt-00001z-00 for ipv6@ietf.org; Fri, 12 Sep 2003 20:49:57 -0400 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 19xybt-00001t-00 for ipv6@ietf.org; Fri, 12 Sep 2003 20:49:57 -0400 Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8D0nOHB073313; Fri, 12 Sep 2003 17:49:24 -0700 (PDT) (envelope-from gene@alicia.nttmcl.com) Received: (from gene@localhost) by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8D0nMUJ073312; Fri, 12 Sep 2003 17:49:22 -0700 (PDT) (envelope-from gene) Date: Fri, 12 Sep 2003 17:49:22 -0700 From: "Eugene M. Kim" To: Iljitsch van Beijnum Cc: George Gross , ipv6@ietf.org Subject: Re: set Global ID field to SHA hash of domain name Message-ID: <20030913004921.GB70788@alicia.nttmcl.com> References: <864B084D-E541-11D7-A80C-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <864B084D-E541-11D7-A80C-00039388672E@muada.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hello, I asked a coworker (she's a cryptographer) about this, and she said that output of SHA-1 is random enough that it should not exhibit any noticeable trait in its result even if we fed it with inputs that all exhibit a common trait (e.g. domain names). Assuming this uniformity, the probability of no 40-bit hash values colliding out of 2^25 ones is: (1 - 0 / 2^40)(1 - 1 / 2^40)(1 - 2 / 2^40)(1 - 3/2^40)...(1 - (2^25 - 1) / 2^40) So the probability of *any* collision is one minus this probability (this is the formula she gave me): 1 - (1 - 1 / 2^40)(1 - 2 / 2^40)(1 - 3/2^40)...(1 - (2^25 - 1) / 2^40) Because even (2^25 - 1) / 2^40 is really close to 0, the dominant term would be 1, and the probabilty of collision in turn will be really close to 0. Eugene On Fri, Sep 12, 2003 at 06:52:41PM +0200, Iljitsch van Beijnum wrote: > On vrijdag, sep 12, 2003, at 11:07 Europe/Amsterdam, George Gross wrote: > > > At the risk of triggering another firestorm of pro/con debate, is > >there any reason why the centrally assigned Global ID defined by > >hinden-ipv6-global-local-addr-02.txt could not be simply the low-order > >40 > >bits of a SHA hash of a domain name? i.e. if you own the domain name, > >you > >get the IP-v6 global ID for "free"? This would side step the angst of > >setting up yet another global registry... > > Hm, with 2^40 possible prefixes and already something in the order of > 2^25 domains in use, I expect collisions will be a definite factor. I > would also be interested in seeing how the SHA-1 algorithm holds up. > Anyone care to get a suitably large list of domain names (a million or > so) and do some statistics on the lower 40 bits of the associated SHA-1 > hash? > > It did occur to me that the domain name sellers are in a better > position to give out these prefixes than the traditional IP address > registries, though. Especially if you consider that they'd just be > selling domain names under c.f.ip6.arpa. :-) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 13 10:51:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20654 for ; Sat, 13 Sep 2003 10:51:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yBjs-00073f-De for ipv6-archive@odin.ietf.org; Sat, 13 Sep 2003 10:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8DEp4gV027128 for ipv6-archive@odin.ietf.org; Sat, 13 Sep 2003 10:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yBjs-00073T-2o for ipv6-web-archive@optimus.ietf.org; Sat, 13 Sep 2003 10:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20611 for ; Sat, 13 Sep 2003 10:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yBjp-0004af-00 for ipv6-web-archive@ietf.org; Sat, 13 Sep 2003 10:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yBjp-0004ac-00 for ipv6-web-archive@ietf.org; Sat, 13 Sep 2003 10:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yBis-0006yn-Ub; Sat, 13 Sep 2003 10:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yBij-0006yM-W2 for ipv6@optimus.ietf.org; Sat, 13 Sep 2003 10:49:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20598 for ; Sat, 13 Sep 2003 10:49:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yBih-0004aO-00 for ipv6@ietf.org; Sat, 13 Sep 2003 10:49:51 -0400 Received: from mail.ssvl.kth.se ([192.16.125.102]) by ietf-mx with esmtp (Exim 4.12) id 19yBig-0004aL-00 for ipv6@ietf.org; Sat, 13 Sep 2003 10:49:50 -0400 Received: from scintsvante (h4n2fls31o1121.telia.com [217.208.141.4]) by mail.ssvl.kth.se (8.12.8/8.12.8) with SMTP id h8DEnmod023190 for ; Sat, 13 Sep 2003 16:49:48 +0200 Message-ID: <000201c37a06$48ca5d40$2000a8c0@scintsvante> From: "B.Svante Eriksson" To: Date: Fri, 12 Sep 2003 20:03:42 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0110_01C37968.F6DD6510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: (no subject) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0110_01C37968.F6DD6510 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0111_01C37968.F6DD6510" ------=_NextPart_001_0111_01C37968.F6DD6510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscription ------=_NextPart_001_0111_01C37968.F6DD6510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscription
 
 
------=_NextPart_001_0111_01C37968.F6DD6510-- ------=_NextPart_000_0110_01C37968.F6DD6510 Content-Type: text/x-vcard; name="B. Svante Eriksson.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="B. Svante Eriksson.vcf" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Eriksson;B. Svante FN:B. Svante Eriksson ORG:SCINT TITLE:Principle Analyst TEL;WORK;VOICE:+46705880495 TEL;CELL;VOICE:+46705880495 TEL;WORK;FAX:+46706191484 X-WAB-GENDER:2 URL;WORK:http://www.scint.org EMAIL;PREF;INTERNET:bse@scint.org REV:20030912T180342Z END:VCARD ------=_NextPart_000_0110_01C37968.F6DD6510-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 14 00:02:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06145 for ; Sun, 14 Sep 2003 00:02:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yO5D-0001v6-OT for ipv6-archive@odin.ietf.org; Sun, 14 Sep 2003 00:01:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8E41to6007374 for ipv6-archive@odin.ietf.org; Sun, 14 Sep 2003 00:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yO5D-0001ur-He for ipv6-web-archive@optimus.ietf.org; Sun, 14 Sep 2003 00:01:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06105 for ; Sun, 14 Sep 2003 00:01:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yO5B-0001st-00 for ipv6-web-archive@ietf.org; Sun, 14 Sep 2003 00:01:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yO5A-0001sp-00 for ipv6-web-archive@ietf.org; Sun, 14 Sep 2003 00:01:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yO4N-0001ju-8O; Sun, 14 Sep 2003 00:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yO4I-0001iV-L8 for ipv6@optimus.ietf.org; Sun, 14 Sep 2003 00:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06067 for ; Sun, 14 Sep 2003 00:00:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yO4G-0001ph-00 for ipv6@ietf.org; Sun, 14 Sep 2003 00:00:56 -0400 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 19yO4F-0001pG-00 for ipv6@ietf.org; Sun, 14 Sep 2003 00:00:55 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 7B94A554 for ; Sun, 14 Sep 2003 00:00:25 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 14 Sep 2003 00:00:25 -0400 Message-Id: <20030914040025.7B94A554@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.82% | 10 | 13.20% | 61715 | pekkas@netcore.fi 10.26% | 8 | 13.08% | 61130 | iljitsch@muada.com 10.26% | 8 | 7.53% | 35205 | michel@arneill-py.sacramento.ca.us 6.41% | 5 | 9.83% | 45954 | dhc2@dcrocker.net 6.41% | 5 | 9.68% | 45255 | pekka.nikander@nomadiclab.com 6.41% | 5 | 6.69% | 31279 | brc@zurich.ibm.com 6.41% | 5 | 5.78% | 27009 | moore@cs.utk.edu 6.41% | 5 | 4.08% | 19048 | hinden@iprg.nokia.com 3.85% | 3 | 2.94% | 13730 | gmgross@nac.net 2.56% | 2 | 4.06% | 18970 | c.hoheisel@x-tec.de 2.56% | 2 | 2.50% | 11666 | kruse@ohio.edu 2.56% | 2 | 2.47% | 11526 | jeroen@unfix.org 2.56% | 2 | 2.43% | 11338 | gene@nttmcl.com 1.28% | 1 | 1.50% | 7023 | mat@cisco.com 1.28% | 1 | 1.50% | 7018 | lear@cisco.com 1.28% | 1 | 1.38% | 6455 | andrew.e.white@motorola.com 1.28% | 1 | 1.26% | 5902 | internet-drafts@ietf.org 1.28% | 1 | 1.06% | 4946 | erik.nordmark@sun.com 1.28% | 1 | 0.98% | 4583 | sra+ipng@hactrn.net 1.28% | 1 | 0.93% | 4345 | stephen@sprunk.org 1.28% | 1 | 0.91% | 4245 | bse@scint.org 1.28% | 1 | 0.83% | 3889 | bmanning@isi.edu 1.28% | 1 | 0.82% | 3824 | ipv6-request@ietf.org 1.28% | 1 | 0.79% | 3699 | alain.durand@sun.com 1.28% | 1 | 0.78% | 3658 | narten@us.ibm.com 1.28% | 1 | 0.77% | 3600 | robert@digi-data.com 1.28% | 1 | 0.76% | 3539 | tim@osburn.com 1.28% | 1 | 0.74% | 3449 | zefram@fysh.org 1.28% | 1 | 0.73% | 3431 | suresh.krishnan@ericsson.com --------+------+--------+----------+------------------------ 100.00% | 78 |100.00% | 467431 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 00:14:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26571 for ; Mon, 15 Sep 2003 00:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ykkV-0007Az-F5 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 00:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F4E3XJ027579 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 00:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ykkV-0007Aj-7L for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 00:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26525 for ; Mon, 15 Sep 2003 00:13:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ykkS-0002fQ-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 00:14:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ykkS-0002fM-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 00:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ykjV-000712-TP; Mon, 15 Sep 2003 00:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ykjD-0006yg-8a for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 00:12:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26477 for ; Mon, 15 Sep 2003 00:12:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ykjA-0002Wz-00 for ipv6@ietf.org; Mon, 15 Sep 2003 00:12:40 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19ykjA-0002Wq-00 for ipv6@ietf.org; Mon, 15 Sep 2003 00:12:40 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h8F4Cek3007597 for ; Sun, 14 Sep 2003 21:12:40 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h8F4CaVo011926 for ; Sun, 14 Sep 2003 23:12:37 -0500 Received: from motorola.com (pcwks381.miel.mot.com [217.1.125.106]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.2) id RQ7ZWJT5; Mon, 15 Sep 2003 09:42:30 +0530 Message-ID: <3F653C32.806C6566@motorola.com> Date: Mon, 15 Sep 2003 09:42:34 +0530 From: Bhaskar S Organization: Motorola India Electronics Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Example for IPv4 compatible IPv6 address? References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> <15294165342.20030912164304@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Please could someone explain how IPv4 compatible IPv6 address is used? -- Regards, Bhaskar S. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 01:36:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29220 for ; Mon, 15 Sep 2003 01:36:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ym23-0007qg-NS for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 01:36:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F5aF7C030164 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 01:36:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ym23-0007qQ-H4 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 01:36:15 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29109 for ; Mon, 15 Sep 2003 01:36:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ym0u-0007SO-Un; Mon, 15 Sep 2003 01:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ym06-0007Lu-AQ for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 01:34:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28832 for ; Mon, 15 Sep 2003 01:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ym03-0002Dv-00 for ipv6@ietf.org; Mon, 15 Sep 2003 01:34:11 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19ym02-00029c-00 for ipv6@ietf.org; Mon, 15 Sep 2003 01:34:10 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8F5XZf26309 for ; Mon, 15 Sep 2003 08:33:35 +0300 Date: Mon, 15 Sep 2003 08:33:35 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org Subject: Writeups on why RFC1918 is bad? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, Regarding the local addressing debate... I had the misfortune to having to participate in a discussion where a multiple-branch (20-30+) enterprise, which has deployed private addresses and network-to-network VPN's inside it, wants to start using IPv6. I'm wondering whether there exist any educational material why RFC1918-like addressing is really *NOT* a good idea (or even, list and evaluate the tradeoffs), and how to get around it. ("If one can state clearly arguments why they shouldn't be doing it with IPv4, maybe it's easier to convince them not to do so with IPv6"). It seems to me that there is a very severe need for a way to enlighten folks like that if we ever want to be successful.. http://www.cs.utk.edu/~moore/what-nats-break.html is interesting, but not focused enough for RFC1918-like addressing itself. I.e., what I'd like to see is whether anyone has written up something regarding either "why local addressing would be a bad idea with IPv6", or "why local addressing is a bad idea with IPv4", especially from the security point-of-view. btw., one way to probably avoid the two-faced DNS issues with local addressing is probably to simply use a different naming for internal commuications like with example.com --> example.internal. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 02:45:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13309 for ; Mon, 15 Sep 2003 02:45:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yn6H-0000O2-D0 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 02:44:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F6ier6001228 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 02:44:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yn6E-0000Jg-Ga for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 02:44:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13265 for ; Mon, 15 Sep 2003 02:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yn6A-0000c2-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 02:44:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yn69-0000bz-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 02:44:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yn5f-0000Cb-7s; Mon, 15 Sep 2003 02:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yn4x-00007y-A5 for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 02:43:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13237 for ; Mon, 15 Sep 2003 02:43:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yn4t-0000VK-00 for ipv6@ietf.org; Mon, 15 Sep 2003 02:43:15 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 19yn4s-0000V9-00 for ipv6@ietf.org; Mon, 15 Sep 2003 02:43:14 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id HAA05862; Mon, 15 Sep 2003 07:43:09 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id HAA07476; Mon, 15 Sep 2003 07:43:01 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h8F6h9801044; Mon, 15 Sep 2003 07:43:09 +0100 Date: Mon, 15 Sep 2003 07:43:09 +0100 From: Tim Chown To: Bhaskar S Cc: ipv6@ietf.org Subject: Re: Example for IPv4 compatible IPv6 address? Message-ID: <20030915064309.GD888@login.ecs.soton.ac.uk> References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> <15294165342.20030912164304@brandenburg.com> <3F653C32.806C6566@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F653C32.806C6566@motorola.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , See http://www.ist-long.com/long/045Guidelines/LONG_Trans_app_IPv6.pdf for examples of IPv4-IPv6 interactions, and where IPv4-mapped addresses are used. Tim On Mon, Sep 15, 2003 at 09:42:34AM +0530, Bhaskar S wrote: > Hi, > > Please could someone explain how IPv4 compatible IPv6 address is > used? > > -- > Regards, > > Bhaskar S. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 02:49:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13733 for ; Mon, 15 Sep 2003 02:49:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ynA7-0001Hb-Kd for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 02:48:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F6md4r004918 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 02:48:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ynA6-0001HE-Qt for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 02:48:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13611 for ; Mon, 15 Sep 2003 02:48:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yn9X-000106-4B; Mon, 15 Sep 2003 02:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yn9Q-0000zE-1C for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 02:47:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13570 for ; Mon, 15 Sep 2003 02:47:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yn9M-0000wh-00 for ipv6@ietf.org; Mon, 15 Sep 2003 02:47:52 -0400 Received: from 116.cust8.nsw.dsl.ozemail.com.au ([203.102.235.116] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 19yn9K-0000td-00 for ipv6@ietf.org; Mon, 15 Sep 2003 02:47:51 -0400 Received: from Dupy2.nosense.org (116.cust8.nsw.dsl.ozemail.com.au [203.102.235.116]) by nosense.org (Postfix) with SMTP id 7E2B73F024 for ; Mon, 15 Sep 2003 16:18:01 +0930 (CST) Date: Mon, 15 Sep 2003 16:18:00 +0930 From: Mark Smith To: ipv6@ietf.org Subject: Re: Writeups on why RFC1918 is bad? Message-Id: <20030915161800.5cf8ba12.ipv6@nosense.org> In-Reply-To: References: Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka, I haven't looked at Keith's document, but having had to develop VPN / NAT solutions, and also witnessed a number of NAT's short comings I'd be quite willing to contribute to a document like this. As an observation, it seems that a lot of "non-IETF" networking people aren't aware of the architectual principles of the Internet. I had sat Cisco, Novell and Microsoft TCP/IP courses, and had deployed NAT on a few occasions, but it wasn't until I read the first chapter of Christian Huitema's "Routing In The Internet" did I gain an understanding of the Internet architectual principles, and therefore, why NAT was not a good solution. I'd suggest most TCP/IP courses just don't cover it, but they do cover NAT, usually in a positive manner. Information about NATs weaknesses exist in a number of places, but as you have pointed out, not in one place - at least that I've come across. If a single document is to be prepared, I'd suggest the following topics, not necessarily in this order : * An overview of the architectual principles of the Internet, in broad, lay-networking-person terms. * An overview of how NAT works. * How it doesn't fit the architectual principles of the Internet, both a broad description, and specific areas where it doesn't fit. * Security and availablility examples where NAT doesn't work, or doesn't work as people think it does. * Myths that have driven the use of NAT eg. running out of IPv4 addresses, perceived security advantages etc. and statements that discredit them. I know a number of these topics are already covered in a number of RFCs, some of the job may just be to re-write them in less technical / theoretical terms, and to consolidate them in one place. I'd see the target audience for this document to be the type of people you've been talking to. Hopefully, a one-stop "this is how the Internet is supposed to work, and this is why NAT stops it working that way" document might go some way into changing the IPv4 NAT mindset. On Mon, 15 Sep 2003 08:33:35 +0300 (EEST) Pekka Savola wrote: > Hi, > > Regarding the local addressing debate... > > I had the misfortune to having to participate in a discussion where a > multiple-branch (20-30+) enterprise, which has deployed private addresses > and network-to-network VPN's inside it, wants to start using IPv6. > > I'm wondering whether there exist any educational material why > RFC1918-like addressing is really *NOT* a good idea (or even, list and > evaluate the tradeoffs), and how to get around it. ("If one can state > clearly arguments why they shouldn't be doing it with IPv4, maybe it's > easier to convince them not to do so with IPv6"). > > It seems to me that there is a very severe need for a way to enlighten > folks like that if we ever want to be successful.. > > http://www.cs.utk.edu/~moore/what-nats-break.html is interesting, but not > focused enough for RFC1918-like addressing itself. > > I.e., what I'd like to see is whether anyone has written up something > regarding either "why local addressing would be a bad idea with IPv6", or > "why local addressing is a bad idea with IPv4", especially from the > security point-of-view. > > btw., one way to probably avoid the two-faced DNS issues with local > addressing is probably to simply use a different naming for internal > commuications like with example.com --> example.internal. > If I understand your example correctly, I might have done a similar thing a couple of years or so ago. I created a sub-domain for site-locals eg sl.example.com, and stuck all the site local AAAA's under that sub-domain, where as all the global addresses were under example.com, or general sub-domains of it. To prevent public Internet nodes from querying this private name space, you could delegate the local addressing sub-domain to a DNS server that only answers queries from local addresses. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 03:04:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14189 for ; Mon, 15 Sep 2003 03:04:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ynPA-00034R-01 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 03:04:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F74BEk011795 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 03:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ynP9-000348-8n for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 03:04:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14131 for ; Mon, 15 Sep 2003 03:04:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ynP5-0002NK-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 03:04:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ynP5-0002NH-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 03:04:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ynP1-0002zX-Ku; Mon, 15 Sep 2003 03:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ynOT-0002w6-VB for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 03:03:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14113 for ; Mon, 15 Sep 2003 03:03:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ynOQ-0002Jh-00 for ipv6@ietf.org; Mon, 15 Sep 2003 03:03:26 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26] helo=mail.messagingengine.com) by ietf-mx with esmtp (Exim 4.12) id 19ynOP-0002Je-00 for ipv6@ietf.org; Mon, 15 Sep 2003 03:03:25 -0400 Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 425291D018B; Mon, 15 Sep 2003 03:03:26 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Mon, 15 Sep 2003 03:03:26 -0400 X-Epoch: 1063609406 X-Sasl-enc: PoSeuGjWTxJ0Wml93rRsOQ Received: from moon (unknown [202.142.102.54]) by mail.messagingengine.com (Postfix) with ESMTP id 287C01CFFEC; Mon, 15 Sep 2003 03:03:23 -0400 (EDT) From: "Chirayu Patel" To: Cc: "'Bhaskar S'" Subject: RE: Example for IPv4 compatible IPv6 address? Date: Mon, 15 Sep 2003 12:36:43 +0530 Message-ID: <010701c37b57$f02e1930$010aa8c0@chirayu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <3F653C32.806C6566@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit RFC 2893. > Please could someone explain how IPv4 compatible IPv6 address is > used? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 03:50:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15599 for ; Mon, 15 Sep 2003 03:50:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yo77-00006W-RJ for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 03:49:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F7nb7T000393 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 03:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yo76-00006E-Cj for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 03:49:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15498 for ; Mon, 15 Sep 2003 03:49:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yo73-0006FR-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 03:49:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yo73-0006FO-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 03:49:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yo6Z-0008Ql-8o; Mon, 15 Sep 2003 03:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yo65-0008Ne-Dl for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 03:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15472 for ; Mon, 15 Sep 2003 03:48:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yo62-00069t-00 for ipv6@ietf.org; Mon, 15 Sep 2003 03:48:30 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19yo62-00069k-00 for ipv6@ietf.org; Mon, 15 Sep 2003 03:48:30 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8F7mixS004266; Mon, 15 Sep 2003 09:48:44 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 15 Sep 2003 09:48:29 +0200 Subject: Re: Writeups on why RFC1918 is bad? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On maandag, sep 15, 2003, at 07:33 Europe/Amsterdam, Pekka Savola wrote: > I'm wondering whether there exist any educational material why > RFC1918-like addressing is really *NOT* a good idea (or even, list and > evaluate the tradeoffs), and how to get around it. ("If one can state > clearly arguments why they shouldn't be doing it with IPv4, maybe it's > easier to convince them not to do so with IPv6"). Have a look at RFC 1627. However, it's probably a bit too old to be exactly what you're looking for. And if any of you kids out there reading this are confused by the reference to RFC 1597: that's the predecessor to RFC 1918. :-) I think it's important to make the distinction between the use of private address space and the use of NAT, though. NAT is evil and anyone who wants to use it in IPv6 should be tarred and feathered, because it breaks communication that isn't simple client/server. But it's possible for reasonable people to have different views on the use of private addressing as stable address space. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 04:00:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16148 for ; Mon, 15 Sep 2003 04:00:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoHP-0001fj-BX for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 04:00:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F80FqR006373 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 04:00:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoHM-0001dW-3I for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 04:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16082 for ; Mon, 15 Sep 2003 04:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoHJ-0007Dj-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 04:00:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yoHI-0007Dg-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 04:00:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoHE-0001aZ-VT; Mon, 15 Sep 2003 04:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoGE-0001Ti-Fb for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 03:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16040 for ; Mon, 15 Sep 2003 03:58:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoGB-00077j-00 for ipv6@ietf.org; Mon, 15 Sep 2003 03:58:59 -0400 Received: from h013.c001.snv.cp.net ([209.228.32.127] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19yoGB-00077f-00 for ipv6@ietf.org; Mon, 15 Sep 2003 03:58:59 -0400 Received: (cpmta 6311 invoked from network); 15 Sep 2003 00:58:59 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 15 Sep 2003 00:58:59 -0700 X-Sent: 15 Sep 2003 07:58:59 GMT Message-ID: <001601c37b5f$4d063d70$a1051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: Writeups on why RFC1918 is bad? Date: Mon, 15 Sep 2003 10:59:31 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, Unfortunately, if someone had this they probably would have used it to explain why local addresses should be removed from IPv6. Since no one was able to produce it then, I doubt it exists now. But I would love to see it if there is one, as this would help close the issue, because it would need to explain why they are bad and what can be used to replace the perceived good that people (like the enterprise that you mention) see in them. Eric ----- Original Message ----- From: "Pekka Savola" To: Sent: Monday, September 15, 2003 8:33 AM Subject: Writeups on why RFC1918 is bad? > Hi, > > Regarding the local addressing debate... > > I had the misfortune to having to participate in a discussion where a > multiple-branch (20-30+) enterprise, which has deployed private addresses > and network-to-network VPN's inside it, wants to start using IPv6. > > I'm wondering whether there exist any educational material why > RFC1918-like addressing is really *NOT* a good idea (or even, list and > evaluate the tradeoffs), and how to get around it. ("If one can state > clearly arguments why they shouldn't be doing it with IPv4, maybe it's > easier to convince them not to do so with IPv6"). > > It seems to me that there is a very severe need for a way to enlighten > folks like that if we ever want to be successful.. > > http://www.cs.utk.edu/~moore/what-nats-break.html is interesting, but not > focused enough for RFC1918-like addressing itself. > > I.e., what I'd like to see is whether anyone has written up something > regarding either "why local addressing would be a bad idea with IPv6", or > "why local addressing is a bad idea with IPv4", especially from the > security point-of-view. > > btw., one way to probably avoid the two-faced DNS issues with local > addressing is probably to simply use a different naming for internal > commuications like with example.com --> example.internal. > > -- --------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 04:44:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17762 for ; Mon, 15 Sep 2003 04:44:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoxz-00073Z-UF for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 04:44:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F8iFjW027123 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 04:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoxz-00073N-7a for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 04:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17707 for ; Mon, 15 Sep 2003 04:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoxw-00035E-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 04:44:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yoxv-000358-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 04:44:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoxn-0006y4-1K; Mon, 15 Sep 2003 04:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yox6-0006tn-0y for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 04:43:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17672 for ; Mon, 15 Sep 2003 04:43:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yox2-0002za-00 for ipv6@ietf.org; Mon, 15 Sep 2003 04:43:17 -0400 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by ietf-mx with esmtp (Exim 4.12) id 19yox2-0002vi-00 for ipv6@ietf.org; Mon, 15 Sep 2003 04:43:16 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8F8gaMD093678; Mon, 15 Sep 2003 10:42:41 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8F8gZhD252314; Mon, 15 Sep 2003 10:42:36 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA30170; Mon, 15 Sep 2003 10:42:35 +0200 Message-ID: <3F657B6C.DCA6C09@zurich.ibm.com> Date: Mon, 15 Sep 2003 10:42:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: Writeups on why RFC1918 is bad? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, I believe RFC 2993 actually covers all the issues (including the one of VPNs between RFC 1918 sites, especially in section 7.6). Given how difficult it was to get that RFC published, I wonder if it is worth the effort of writing what would efefctively be the same document, but with an emphasis on ambiguity instead of translation. Brian Pekka Savola wrote: > > Hi, > > Regarding the local addressing debate... > > I had the misfortune to having to participate in a discussion where a > multiple-branch (20-30+) enterprise, which has deployed private addresses > and network-to-network VPN's inside it, wants to start using IPv6. > > I'm wondering whether there exist any educational material why > RFC1918-like addressing is really *NOT* a good idea (or even, list and > evaluate the tradeoffs), and how to get around it. ("If one can state > clearly arguments why they shouldn't be doing it with IPv4, maybe it's > easier to convince them not to do so with IPv6"). > > It seems to me that there is a very severe need for a way to enlighten > folks like that if we ever want to be successful.. > > http://www.cs.utk.edu/~moore/what-nats-break.html is interesting, but not > focused enough for RFC1918-like addressing itself. > > I.e., what I'd like to see is whether anyone has written up something > regarding either "why local addressing would be a bad idea with IPv6", or > "why local addressing is a bad idea with IPv4", especially from the > security point-of-view. > > btw., one way to probably avoid the two-faced DNS issues with local > addressing is probably to simply use a different naming for internal > commuications like with example.com --> example.internal. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 05:06:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18677 for ; Mon, 15 Sep 2003 05:06:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypIj-0001JS-Un for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 05:05:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F95f2h005046 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 05:05:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypIj-0001JI-Fy for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 05:05:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18617 for ; Mon, 15 Sep 2003 05:05:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypIg-00057C-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 05:05:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ypIf-000576-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 05:05:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypI8-00017e-2x; Mon, 15 Sep 2003 05:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypHM-000135-OM for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 05:04:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18535 for ; Mon, 15 Sep 2003 05:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypHJ-0004zE-00 for ipv6@ietf.org; Mon, 15 Sep 2003 05:04:13 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 19ypHI-0004wY-00 for ipv6@ietf.org; Mon, 15 Sep 2003 05:04:12 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8F93ZYG112016; Mon, 15 Sep 2003 11:03:35 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8F93ZhD235264; Mon, 15 Sep 2003 11:03:35 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA26058; Mon, 15 Sep 2003 11:03:33 +0200 Message-ID: <3F658057.E2233AEF@zurich.ibm.com> Date: Mon, 15 Sep 2003 11:03:19 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Dave Crocker CC: IPV6 WG Subject: Re: domain names as end-point identifiers? References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> <17230000648.20030911225339@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dave Crocker wrote: ... > > BEC> If you are looking for stable identifiers for "stacks" (in the > BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely > BEC> that an FQDN is a safe answer. > > It is probably worth noting that the NSRG report uses domain names to label > the different stacks, in its own examples and in discussion. Whatever the > reasons for that choice, I obviously find it interesting that they were used > for that purpose. As I recall that was a pragmatic choice... > > BEC> FQDNs are (mis)used in many ways; > BEC> a name like www.example.com certainly doesn't identify a given IP stack > BEC> on a given interface on a given host > > 1. When someone starts talking about identifying _interfaces_ I suspect they > mean address, rather than 'end point identifier'. On the assumption that that > is not what Brian meant, it's worth having this clarified. I meant an interface. That could mean a physical interface, or it could mean a virtual interface such as a tunnel termination or a 6to4 interface. BTW, these concepts are all made a bit fuzzy by virtualization at level 2. A given Ethernet address may well refer to different connectors simultaeously, if some level 2 box is doing fancy footwork to distribute transport connections around a server cluster. As far a I'm concerned, an address is just a string of bits. Whether it's a locator or an identifier depends on context. What it locates or identifies depends on context. > I'm confused by > Bill's comment on this: " if there is an entity at a point in the topology, > then the name maps nicely into the DNS". Domain names are not tied to network > topology. They are tied to an administrative "topology", which is an entirely > different thing. > > 2. If I understand the concern, here, it is that not _all_ domain names are > endpoint identifiers. Erik also raised the point that domain names are used > for different (and inconsistent?) purposes. One might be a host, another a > service. When there are multiple records returned, they might refer to > alternative systems or they might be alternate paths to the same service. > > My question is: so why does that mean that the ones that _are_ EIDs are > not acceptable? What problems are caused by having multiple uses? Possibly none, but exactly the same argument applies to the bit strings formerly known as address. As Lewis Carroll would perhaps have said, they mean what we want them to mean. > > BEC> I don't see that this has any functional advantage over an IPv6 address > BEC> for that stack, and it introduces a DNS dependency for the transport layer. > > 1. I thought an IPv6 address was an address, not an end-point identifier. No? No. "Address" is an overloaded concept in IPvN {N=1,4}. They will do just fine as identifiers if we want. > > 2. The concern about introducing a DNS dependency into a lower layer, like > transport, strikes me as pretty important, too. However, if we invent a new > construct for an EID, we are a) introducing a new global administration > requirement, and b) creating a dependency on it in that lower layer. So the > concern with this new dependency is on the need for an EID, rather than the > fact that it might be a domain name. No? If we use "address" bit strings as identifiers, we are *not* adding either a new administration or a dependency. We are just being a bit clearer about the double semantics of "addresses" (id and locator). Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 05:29:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19645 for ; Mon, 15 Sep 2003 05:29:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypfW-00049d-9e for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 05:29:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F9TEDl015962 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 05:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypfW-00049L-4u for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 05:29:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19595 for ; Mon, 15 Sep 2003 05:29:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypfS-0007Iv-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 05:29:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ypfS-0007Ir-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 05:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypfK-00043C-IK; Mon, 15 Sep 2003 05:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypey-00040M-6E for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 05:28:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19580 for ; Mon, 15 Sep 2003 05:28:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypeu-0007Fe-00 for ipv6@ietf.org; Mon, 15 Sep 2003 05:28:36 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 19ypeu-0007CP-00 for ipv6@ietf.org; Mon, 15 Sep 2003 05:28:36 -0400 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 26D271C; Mon, 15 Sep 2003 12:41:29 +0300 (EEST) Message-ID: <3F658628.1020302@nomadiclab.com> Date: Mon, 15 Sep 2003 12:28:08 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py Cc: IPV6 WG , hipsec@honor.trusecure.com Subject: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michel, [Sorry for the late reply. Cross-posted to HIPSEC since there is the specific question about HIT length. Please adjust your reply list.] Iljitsch van Beijnum wrote: >>> Are you saying that we should make a clear distinction between >>> identifiers and locators, and not have any values that are valid >>> in both realms? Pekka Nikander wrote: >> Yes, in the long run. > > Would that include going to identifiers that are longer than 128 > bits? [I think I answered this separately already elsewhere. Anyway.] No, just making a clear distinction does not necessarily mean that we have to go into identifiers longer than 128 bits. On the other hand, I do think that there are other reasons for going to primary identifiers that are (considerably) longer than 128 bits. > Sorry if I ask a stupid question, but the main deployment issue HIP > has is basically that every host would need an HIP stack. Yes. If HIP is a solution for something, the hosts that want to benefit from that solution have to implement HIP in their stack. On the other hand, HIP does not prevent nodes from using legacy IPv4/IPv6 in parallel with HIP. > Since there is not much you can't do about [requiring a HIP stack in > participating hosts], why haven't you pushed the reasoning further > and opted for an extended HIT that would not have some of the current > limitations (background: we did discuss the issue in Atlanta and one > of the things I recalled is that we both wished we had more bits). Yes, we discussed this in Atlanta. And yes, I think we could fairly easily go to e.g. 256 bit HITs, if desired. However, the probability of collisions with 126 bit HITs seems to be low enough so that I don't see any specific reasons to go to 256 bit HITs, at least not yet. I don't remember any more what might have been the reasons for having more bits. Could you please remind me? Anyway, this is certainly something that needs to be reconsidered if HIP ever becomes a standards track protocol. >> I do understand [the] point about the benefits of an identifier >> also being a locator, but I also believe that the benefits of clean >> separation will more than pay the drawbacks in the long run. (I >> don't have any analysis or data to support this belief, though.) > > I'd be interested in some vague rationale about this. In a separate mail (CC:d to IPv6 list only). >> Nodes with well-known addresses, such as servers and those using >> stateful configuration, are most vulnerable. Nodes that are a part >> of the network infrastructure, such as DNS servers, are >> particularly interesting targets for attackers, > > To put this in context, the paragraph above assumes that the server > is being accessed using the identifier, and that the hackers targets > the id/loc mapping mechanism in order to map the id to _his_ locs, > not the legit ones. Actually, not quite. In its most simple form, it merely states that if you know someone's address, it is easy to launch a flooding DoS attack towards that someone. On the other hand, if you don't know the address, it is much harder. But there are also other, more complex reasons buried within the sentence, if I recall correctly. And again: The potential flooding DoS attacks opened by mobility and multi-address multi-homing are much more serious than the currently possible ICMP/UDP/TCP SYN DDoS reflection attacks. Without proper protection, mobility and/or multi-address multi-homing allow an attacker to redirect whole packet streams, and even keep them running with a fairly simple bit of acknowledgement prediction. > Did I get this right? And if I did, what difference does it make if > the locators and the identifiers are segregated? If the identifiers and locators are separated, it is no longer important to defend individual IP address of *most* nodes. That is, in the most typical case you don't care what your IP address is, and if one address doesn't work, you can try to pick a new one. However, at least DNS servers (or id/loc mapping servers) would continue to need having stable IP addresses. Hence, their address would still need to be protected. Whether this really presents a difference remains to be fully analyzed. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 05:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20606 for ; Mon, 15 Sep 2003 05:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yq5b-0007Sp-Ds for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 05:56:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F9uBBj028689 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 05:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yq5b-0007Sc-8R for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 05:56:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20573 for ; Mon, 15 Sep 2003 05:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yq5X-00022h-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 05:56:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yq5X-00022e-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 05:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yq5T-0007Nb-JP; Mon, 15 Sep 2003 05:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yq4p-0007Jd-Hi for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 05:55:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20540 for ; Mon, 15 Sep 2003 05:55:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yq4l-0001xk-00 for ipv6@ietf.org; Mon, 15 Sep 2003 05:55:19 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 19yq4l-0001uf-00 for ipv6@ietf.org; Mon, 15 Sep 2003 05:55:19 -0400 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id D0F8225; Mon, 15 Sep 2003 13:08:12 +0300 (EEST) Message-ID: <3F658C6B.1040700@nomadiclab.com> Date: Mon, 15 Sep 2003 12:54:51 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py Cc: IPV6 WG Subject: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michel, Pekka Nikander wrote: >> I do understand your point about the benefits of an >> identifier also being a locator, but I also believe >> that the benefits of clean separation will more than >> pay the drawbacks in the long run. (I don't have any >> analysis or data to support this belief, though.) Michel Py replied: > I'd be interested in some vague rationale about this. So, the question is about either using identifiers that sometimes are also locators vs. using identifiers that never are locators. If we could use identifiers that are always also locators, we would not need this discussion at all; the current IP addresses should do well. Now, if we use identifiers that are never locators, the situation seems to be semantically simple to me. An identifier identifies a (potential) end-point of communication. However, it alone is not enough for communication. You also need to get the locator (the address), in some way or another. On the other hand, if we use identifiers that are sometimes also locators, I'm afraid of semantic confusion. How do you know if a given identifier can be used as a locator or not? If you encode it somehow to the bits, then you are actually going into the clean separation anyway, and could can proceed and create distinct APIs, if that is useful. If you do not encode the difference into the bits, then you have to "try" in some way or another. That is, you may try to use the identifier as a locator and see what happens, or use some infrastructure to find out. These all seem to be complicated. The reason why some people seem to dislike non-locator identifiers is that they may be hard to be used for referral. That is, if you send just an non-locator identifier to another host in an p2p kind of application, that other host may not be able to use the identifier to contact the host. I think this concern is a consequence of less than perfect understanding of the situation. I just want to remind that identification and rendezvous are different functions. In my opinion, identifiers should be used for identification, i.e., to make sure that the peer is really the end-point that it is thought to be. (Hence I also believe that identifiers should be self-authenticating, i.e., public keys.) For rendezvous, we obviously need either a locator or a name that can be convered into an address. Given this background, I don't see any immediate drawbacks from the following approach to referral. When a host want to send an end-point identifier to another host, it always includes either a currently known working address for the identifier, a name (e.g. DNS name) that can be easily converted to an address, or both. Of course, if identifiers were DNS names, this would always be the case. On the other hand, the DNS names do not fulfil the identifiability and security goals that I have in mind. Hence, it looks like that sending an or pair would be a fairly decent practise. [Sidenote: Taking another angle, we could even define that an identifier is always a triplet. In that way we would have identifiers that are both secure (without a PKI) and resolvable.] --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 07:03:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22510 for ; Mon, 15 Sep 2003 07:03:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yr82-0006n3-96 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 07:02:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FB2kuZ026101 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 07:02:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yr82-0006mu-3k for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 07:02:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22443 for ; Mon, 15 Sep 2003 07:02:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yr7x-0000JE-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 07:02:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yr7x-0000J0-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 07:02:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yr7K-0006YI-2Z; Mon, 15 Sep 2003 07:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yr6K-0006RQ-Ne for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 07:01:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22387 for ; Mon, 15 Sep 2003 07:00:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yr6F-000099-00 for ipv6@ietf.org; Mon, 15 Sep 2003 07:00:55 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19yr6F-000090-00 for ipv6@ietf.org; Mon, 15 Sep 2003 07:00:55 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8FB17xS006543; Mon, 15 Sep 2003 13:01:07 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 15 Sep 2003 13:00:51 +0200 Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: IPV6 WG To: Pekka Nikander From: Iljitsch van Beijnum In-Reply-To: <3F658C6B.1040700@nomadiclab.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On maandag, sep 15, 2003, at 11:54 Europe/Amsterdam, Pekka Nikander wrote: > So, the question is about either using identifiers that > sometimes are also locators vs. using identifiers that > never are locators. > Now, if we use identifiers that are never locators, the > situation seems to be semantically simple to me. Maybe in theory. In practice, when you see a 128 bit value in a place where you would expect an IPv6 address, you not only want to know whether it's an identifier or a locator (this part would be easy) but also if it's used in the context of multihomed communication or in the context of single homed communication. That's the hard part. It should be possible to make the three (legacy, id and loc) not overlap, but that doesn't solve all potential problems. For instance, when a group of hosts participate in a group session, the multihoming aware hosts would probably exchange the identifiers to new group members, but if a host that doesn't support multihoming receives a reference to an identifier, it can't do anything useful with it. > On the other hand, if we use identifiers that are sometimes > also locators, I'm afraid of semantic confusion. How do > you know if a given identifier can be used as a locator > or not? You can either assume the identifier is a reachable locator (having the identifier be an _unreachable_ locator isn't very smart) and use it. This is what non multihoming aware systems will be doing anyway. Or you can look up the identifier in the mapping database to get the full set of locators. What I'd like to see is doing #1 first, and only do #2 when #1 doesn't work. But if you don't like the ambiguity of having an identifier that may or may not be a locator, stamp on the letters "ID" in large type in a bright color and only use values that you encounter in an identifier context only as id. Then do the locator lookup when you need locators. The fact that a locator happens to be the same 128 bit value as your identifier shouldn't matter. > The reason why some people seem to dislike non-locator > identifiers is that they may be hard to be used for referral. > That is, if you send just an non-locator identifier to > another host in an p2p kind of application, that other > host may not be able to use the identifier to contact > the host. I think this concern is a consequence of less > than perfect understanding of the situation. No, it's a backward compatibility issue, as I described above. > [Sidenote: Taking another angle, we could even define that > an identifier is always a > triplet. In that way we would have identifiers that are > both secure (without a PKI) and resolvable.] The usefulness of public key mechanisms for authentication is that it moves the authentication checks largely offline: you can see if someone is who they claim to be without having to contact some kind of authority. Using these mechanisms in cases where the availability of an authority can be assumed (i.e., when you can look the whole thing up in the DNS) doesn't make much sense to me. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 07:27:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23351 for ; Mon, 15 Sep 2003 07:27:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yrVr-0001UA-P1 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 07:27:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FBRNW1005710 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 07:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yrVr-0001U1-JM for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 07:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23272 for ; Mon, 15 Sep 2003 07:27:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yrVr-0002a8-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 07:27:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yrVq-0002a4-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 07:27:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yrVX-0001I2-2Y; Mon, 15 Sep 2003 07:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yrVS-0001HQ-RW for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 07:26:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23259 for ; Mon, 15 Sep 2003 07:26:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yrVS-0002Xt-00 for ipv6@ietf.org; Mon, 15 Sep 2003 07:26:58 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 19yrVR-0002Ui-00 for ipv6@ietf.org; Mon, 15 Sep 2003 07:26:57 -0400 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 24E3526; Mon, 15 Sep 2003 14:39:49 +0300 (EEST) Message-ID: <3F65A1E3.4090207@nomadiclab.com> Date: Mon, 15 Sep 2003 14:26:27 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: IPV6 WG Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch, It looks like that we are speaking about different issues. I was trying to analyse the long term consequences of various practises. I fully agree that we most probably need to have identifiers that are also locators for quite some time. (That's why I think Hinden/Haberman addresses are probably good, even though they act as locators only locally.) Furthermore, I am not so much concerned about multi-homing. Multi-homing is only one aspect. Remember that I was not posting the message to multi6. There are also other needs for stable end-point identifiers. >> Now, if we use identifiers that are never locators, the >> situation seems to be semantically simple to me. > > Maybe in theory. In practice, when you see a 128 bit value in a place > where you would expect an IPv6 address, I was not really discussing backwards API issues either. If we go for a real separation of locators and identifiers, we will also have to define new APIs in the longer run. And slightly revised transport protocols, too. (I know, the need to revise is actually *a* reason for doing the separation at the transport, e.g. using SCTP. But there are other issues that make a separate layer more attractive, IMHO.) > you not only want to know whether it's an identifier or > a locator (this part would be easy) but also if it's used > in the context of multihomed communication or in the > context of single homed communication. That's the hard part. Sorry, but now I don't understand your thinking at all. Firstly, I still think that if we mix the two, it would be hard to know which one an item is. Secondly, I honestly don't understand why one should see any difference between singly homed or multi-homed communication. It really looks like that we are speaking about really different things. Would you please clarify? >> On the other hand, if we use identifiers that are sometimes >> also locators, I'm afraid of semantic confusion. How do >> you know if a given identifier can be used as a locator >> or not? > > You can either assume the identifier is a reachable locator (having the > identifier be an _unreachable_ locator isn't very smart) and use it. To me it looks like that you are going back to the current situation, where the locators and identifiers are overloaded. >> The reason why some people seem to dislike non-locator >> identifiers is that they may be hard to be used for referral. > > No, it's a backward compatibility issue, as I described above. I still don't understand. I am sorry, but seemingly I just cannot grasp your reference of thinking. > The usefulness of public key mechanisms for authentication is that it > moves the authentication checks largely offline: you can see if someone > is who they claim to be without having to contact some kind of > authority. Indeed... > Using these mechanisms in cases where the availability of an > authority can be assumed (i.e., when you can look the whole thing up in > the DNS) doesn't make much sense to me. Firstly, we still don't have secure DNS. Secondly, having to rely on an authority seems like a bad approach to me. At least when compared to one where you don't need to rely on authority. (Just can't resist: Could we compare this to the difference between Aristolean scholastics and Baconian science? :-) --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 08:24:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25281 for ; Mon, 15 Sep 2003 08:24:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysP5-00081n-3n for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 08:24:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FCORRA030851 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 08:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysP4-00081U-QX for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 08:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25186 for ; Mon, 15 Sep 2003 08:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ysP3-00009j-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 08:24:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ysP3-00009g-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 08:24:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysOg-0007sb-FS; Mon, 15 Sep 2003 08:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysNo-0007nN-0n for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 08:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25135 for ; Mon, 15 Sep 2003 08:23:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ysNm-00001U-00 for ipv6@ietf.org; Mon, 15 Sep 2003 08:23:06 -0400 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 19ysNm-00000i-00 for ipv6@ietf.org; Mon, 15 Sep 2003 08:23:06 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id 04FA28C; Mon, 15 Sep 2003 21:22:59 +0900 (JST) To: Bhaskar.S@motorola.com Cc: ipv6@ietf.org Subject: Re: Example for IPv4 compatible IPv6 address? In-Reply-To: Your message of "Mon, 15 Sep 2003 09:42:34 +0530" <3F653C32.806C6566@motorola.com> References: <3F653C32.806C6566@motorola.com> X-Mailer: Cue version 0.6 (030716-1832/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20030915122259.04FA28C@coconut.itojun.org> Date: Mon, 15 Sep 2003 21:22:59 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Please could someone explain how IPv4 compatible IPv6 address is > used? its use is deprecated. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 08:36:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25826 for ; Mon, 15 Sep 2003 08:36:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysaP-00013G-7R for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 08:36:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FCa9Kp004036 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 08:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysaP-000131-2n for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 08:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25743 for ; Mon, 15 Sep 2003 08:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ysaN-0001Gq-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 08:36:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ysaN-0001Gl-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 08:36:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysaI-0000yB-T0; Mon, 15 Sep 2003 08:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysZW-0000t8-SK for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 08:35:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25711 for ; Mon, 15 Sep 2003 08:35:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ysZV-0001BJ-00 for ipv6@ietf.org; Mon, 15 Sep 2003 08:35:13 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19ysZV-0001BF-00 for ipv6@ietf.org; Mon, 15 Sep 2003 08:35:13 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id BED7A13FC2; Mon, 15 Sep 2003 08:35:12 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18207-12; Mon, 15 Sep 2003 08:35:12 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7592814062; Mon, 15 Sep 2003 08:35:11 -0400 (EDT) Date: Mon, 15 Sep 2003 08:31:56 -0400 From: Keith Moore To: Pekka Nikander Cc: moore@cs.utk.edu, michel@arneill-py.sacramento.ca.us, ipv6@ietf.org Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Message-Id: <20030915083156.4581ae3f.moore@cs.utk.edu> In-Reply-To: <3F658C6B.1040700@nomadiclab.com> References: <3F658C6B.1040700@nomadiclab.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Given this background, I don't see any immediate drawbacks > from the following approach to referral. When a host want > to send an end-point identifier to another host, it always > includes either a currently known working address for the > identifier, a name (e.g. DNS name) that can be easily > converted to an address, or both. DNS names are not sufficient for rendezvous or referral. see http://www.cs.utk.edu/~moore/opinions/ipv6/dns-as-endpoint-id.html In a world where IP addresses change without notice, IP addresses aren't sufficient for rendezvous or referral either. While there might be reasons to have identifiers instead of locators other than the fact that IP address-to-host bindings are becoming ephemeral, the immediate problem is that we don't have good host identifiers that can be used for rendezvous or referral. -- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 08:53:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26430 for ; Mon, 15 Sep 2003 08:53:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysqu-0003Vw-3a for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 08:53:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FCrCrG013507 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 08:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysqt-0003Vm-TC for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 08:53:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26377 for ; Mon, 15 Sep 2003 08:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ysqs-0002rP-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 08:53:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ysqr-0002rJ-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 08:53:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysqk-0003Qy-0R; Mon, 15 Sep 2003 08:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ysqK-0003OS-Gg for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 08:52:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26363 for ; Mon, 15 Sep 2003 08:52:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ysqJ-0002oC-00 for ipv6@ietf.org; Mon, 15 Sep 2003 08:52:35 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19ysqI-0002lQ-00 for ipv6@ietf.org; Mon, 15 Sep 2003 08:52:34 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8FCpxs29848; Mon, 15 Sep 2003 15:52:00 +0300 Date: Mon, 15 Sep 2003 15:51:58 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: ipv6@ietf.org Subject: Re: Writeups on why RFC1918 is bad? In-Reply-To: <3F657B6C.DCA6C09@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, On Mon, 15 Sep 2003, Brian E Carpenter wrote: > I believe RFC 2993 actually covers all the issues (including the one > of VPNs between RFC 1918 sites, especially in section 7.6). Thanks for the pointer. Yes, RFC 2993 seems to cover many aspects which seem surprisingly familiar ;-), but I'm not sure if it answers questions like : "I want to use NAT or RFC1918 for purpose X. Why shouldn't I do it? (Why might I want to do it anyway?) What other feasible ways are there to do it without such mechanisms?" In other words, the document seems to cover the scenarios using a broad overview -- it may not be applicable to the most common cases of deployment. But then again, I'll have to go read the RFC in detail. > Given how difficult it was to get that RFC published, I wonder if it > is worth the effort of writing what would efefctively be the same > document, but with an emphasis on ambiguity instead of translation. I can certainly envision how this could turn ugly. Could you elaborate a bit on the difficulties that came across? Pekka > Pekka Savola wrote: > > > > Hi, > > > > Regarding the local addressing debate... > > > > I had the misfortune to having to participate in a discussion where a > > multiple-branch (20-30+) enterprise, which has deployed private addresses > > and network-to-network VPN's inside it, wants to start using IPv6. > > > > I'm wondering whether there exist any educational material why > > RFC1918-like addressing is really *NOT* a good idea (or even, list and > > evaluate the tradeoffs), and how to get around it. ("If one can state > > clearly arguments why they shouldn't be doing it with IPv4, maybe it's > > easier to convince them not to do so with IPv6"). > > > > It seems to me that there is a very severe need for a way to enlighten > > folks like that if we ever want to be successful.. > > > > http://www.cs.utk.edu/~moore/what-nats-break.html is interesting, but not > > focused enough for RFC1918-like addressing itself. > > > > I.e., what I'd like to see is whether anyone has written up something > > regarding either "why local addressing would be a bad idea with IPv6", or > > "why local addressing is a bad idea with IPv4", especially from the > > security point-of-view. > > > > btw., one way to probably avoid the two-faced DNS issues with local > > addressing is probably to simply use a different naming for internal > > commuications like with example.com --> example.internal. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 09:06:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27263 for ; Mon, 15 Sep 2003 09:06:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yt3d-0005WS-Uj for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 09:06:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FD6LWk021222 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 09:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yt3d-0005W4-2i for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 09:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27168 for ; Mon, 15 Sep 2003 09:06:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yt3b-0004Co-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 09:06:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yt3b-0004Cl-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 09:06:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yt3L-0005KF-Jq; Mon, 15 Sep 2003 09:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yt2f-0005Fr-KL for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 09:05:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27123 for ; Mon, 15 Sep 2003 09:05:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yt2e-00047G-00 for ipv6@ietf.org; Mon, 15 Sep 2003 09:05:20 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 19yt2d-000478-00 for ipv6@ietf.org; Mon, 15 Sep 2003 09:05:19 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA16582; Mon, 15 Sep 2003 14:05:14 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id OAA25231; Mon, 15 Sep 2003 14:05:07 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h8FD5Er08365; Mon, 15 Sep 2003 14:05:14 +0100 Date: Mon, 15 Sep 2003 14:05:14 +0100 From: Tim Chown To: Bhaskar.S@motorola.com, ipv6@ietf.org Subject: Re: Example for IPv4 compatible IPv6 address? Message-ID: <20030915130514.GJ7945@login.ecs.soton.ac.uk> References: <3F653C32.806C6566@motorola.com> <20030915122259.04FA28C@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030915122259.04FA28C@coconut.itojun.org> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, Sep 15, 2003 at 09:22:59PM +0900, Jun-ichiro itojun Hagino wrote: > > Please could someone explain how IPv4 compatible IPv6 address is > > used? > > its use is deprecated. Ah, misread compatible for mapped. Don't see compatible mentioned very often now as Itojun says :) Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 13:06:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12067 for ; Mon, 15 Sep 2003 13:06:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywnO-0007sS-PP for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 13:05:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FH5oDT030280 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 13:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywnO-0007sJ-Jb for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 13:05:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11961 for ; Mon, 15 Sep 2003 13:05:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ywnJ-0001sp-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 13:05:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ywnI-0001si-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 13:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywme-0007kV-TH; Mon, 15 Sep 2003 13:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywlq-0007jV-OQ for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 13:04:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11891 for ; Mon, 15 Sep 2003 13:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ywlo-0001r2-00 for ipv6@ietf.org; Mon, 15 Sep 2003 13:04:12 -0400 Received: from mail.internetbrasil.net ([200.153.64.2]) by ietf-mx with smtp (Exim 4.12) id 19ywlo-0001qy-00 for ipv6@ietf.org; Mon, 15 Sep 2003 13:04:12 -0400 Received: (qmail 79893 invoked by uid 89); 15 Sep 2003 16:58:23 -0000 Received: from unknown (HELO ipv6brspw2k) (robson.oliveira@ipv6dobrasil.com.br@200.148.119.131) by 0 with SMTP; 15 Sep 2003 16:58:23 -0000 From: "Robson Oliveira" To: "Jun-ichiro itojun Hagino" Cc: Subject: RE: Example for IPv4 compatible IPv6 address? Date: Mon, 15 Sep 2003 13:59:48 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030915122259.04FA28C@coconut.itojun.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Itojun, Could you let us know where is documented the IPv4 compatible deprecation? I believe that some future confusions could be prevented regarding which address continue to be used if a new documentation has been published. robson -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of Jun-ichiro itojun Hagino Sent: Monday, September 15, 2003 9:23 AM To: Bhaskar.S@motorola.com Cc: ipv6@ietf.org Subject: Re: Example for IPv4 compatible IPv6 address? > Please could someone explain how IPv4 compatible IPv6 address is > used? its use is deprecated. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 13:13:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12817 for ; Mon, 15 Sep 2003 13:13:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywuW-0000OL-5X for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 13:13:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FHDCNH001499 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 13:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywuU-0000O6-Fy for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 13:13:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12696 for ; Mon, 15 Sep 2003 13:13:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ywuS-00028M-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 13:13:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ywuS-00028J-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 13:13:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywuN-0000Jm-7Z; Mon, 15 Sep 2003 13:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywtj-0000I6-5G for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 13:12:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12621 for ; Mon, 15 Sep 2003 13:12:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ywth-00026Z-00 for ipv6@ietf.org; Mon, 15 Sep 2003 13:12:21 -0400 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 19ywtf-00025y-00 for ipv6@ietf.org; Mon, 15 Sep 2003 13:12:20 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 4B12D431E7; Mon, 15 Sep 2003 19:11:40 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.67]) by smtp02.uc3m.es (Postfix) with SMTP id 577E899FCB; Mon, 15 Sep 2003 19:11:39 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Pekka Nikander" , "Michel Py" Cc: "IPV6 WG" Subject: RE: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Date: Mon, 15 Sep 2003 19:07:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3F658C6B.1040700@nomadiclab.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka, [...] > The reason why some people seem to dislike non-locator > identifiers is that they may be hard to be used for referral. IMHO an important benefit of having locator identifier is that it just works without additional stuff for a big number of hosts. I mean, regular non mobile non multi-homed hosts (which i think they are a lot) just do not need all this stuff. So having locator identifiers just works fine for them. Regards, marcelo -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 13:46:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14701 for ; Mon, 15 Sep 2003 13:46:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yxQV-0002EP-Pe for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 13:46:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FHkFtU008577 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 13:46:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yxQV-0002EG-EE for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 13:46:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14622 for ; Mon, 15 Sep 2003 13:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yxQT-0002mQ-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 13:46:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yxQR-0002mN-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 13:46:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yxQJ-00023X-F6; Mon, 15 Sep 2003 13:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yxPq-00022C-RA for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 13:45:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14576; Mon, 15 Sep 2003 13:45:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yxPo-0002lC-00; Mon, 15 Sep 2003 13:45:32 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 19yxPn-0002ke-00; Mon, 15 Sep 2003 13:45:32 -0400 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id DB5591C; Mon, 15 Sep 2003 20:58:23 +0300 (EEST) Message-ID: <3F65FA9E.2010801@nomadiclab.com> Date: Mon, 15 Sep 2003 20:45:02 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall R. Stewart (home)" Cc: ietf@ietf.org, ipv6@ietf.org Subject: Spoofing and SCTP ADD-IP (was Re: Solving the right problems ...) References: <3F6239E0.8090001@stewart.chicago.il.us> <01df01c36a7b$840dbb80$63124104@eagleswings> <3F61EAC2.7020304@stewart.chicago.il.us> <20030912165739.50b3866b.moore@cs.utk.edu> <3F6239E0.8090001@stewart.chicago.il.us> <5.2.0.9.2.20030913095009.0301ea40@pop.mcilink.com> <3F6373FD.1020308@stewart.chicago.il.us> In-Reply-To: <3F6373FD.1020308@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit vinton g. cerf wrote: >> We would also want to look very carefully at the potential spoofing >> opportunity that rebinding would likely introduce. Randall R. Stewart (home) wrote: > This is one of the reasons the authors of ADD-IP have NOT pushed to get > it done.. some more > work needs to be done on this area... http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt is a background document, produced by the MIPv6 route optimization security design team, that tries to explain the security desing in MIPv6 RO. I think that most of the threats and much of the solution model would most probably apply also to SCTP ADD-IP and, of course, also other multi-address multi-homing solutions. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 14:56:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19285 for ; Mon, 15 Sep 2003 14:56:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyVm-0006CJ-1B for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 14:55:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FItj9A023817 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 14:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyVl-0006C0-H8 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 14:55:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19225 for ; Mon, 15 Sep 2003 14:55:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyVi-0004Pr-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 14:55:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yyVi-0004Po-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 14:55:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyV6-0005uU-Ow; Mon, 15 Sep 2003 14:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyUr-0005tw-Om for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 14:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19149; Mon, 15 Sep 2003 14:54:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyUo-0004Nw-00; Mon, 15 Sep 2003 14:54:46 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19yyUo-0004Ne-00; Mon, 15 Sep 2003 14:54:46 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h8FIs63D055919; Mon, 15 Sep 2003 13:54:13 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F660ACD.90603@stewart.chicago.il.us> Date: Mon, 15 Sep 2003 13:54:05 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: ietf@ietf.org, ipv6@ietf.org Subject: Re: Spoofing and SCTP ADD-IP (was Re: Solving the right problems ...) References: <3F6239E0.8090001@stewart.chicago.il.us> <01df01c36a7b$840dbb80$63124104@eagleswings> <3F61EAC2.7020304@stewart.chicago.il.us> <20030912165739.50b3866b.moore@cs.utk.edu> <3F6239E0.8090001@stewart.chicago.il.us> <5.2.0.9.2.20030913095009.0301ea40@pop.mcilink.com> <3F6373FD.1020308@stewart.chicago.il.us> <3F65FA9E.2010801@nomadiclab.com> In-Reply-To: <3F65FA9E.2010801@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > vinton g. cerf wrote: > >>> We would also want to look very carefully at the potential spoofing >>> opportunity that rebinding would likely introduce. >> > > Randall R. Stewart (home) wrote: > >> This is one of the reasons the authors of ADD-IP have NOT pushed to >> get it done.. some more >> work needs to be done on this area... > > > http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt > is a background document, produced by the MIPv6 route optimization > security design team, that tries to explain the security desing > in MIPv6 RO. I think that most of the threats and much of the solution > model would most probably apply also to SCTP ADD-IP and, of course, > also other multi-address multi-homing solutions. > > --Pekka Nikander > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > Pekka: Interesting reading.. I had heard of the RR check from someone but had not researched it in detail.. nice document :> Now as to the applicability in SCTP and ADD-IP... There is a difference with mobile-ip in that an SCTP association is already established. Each node CN and MN have "connection" state. There has been a 64bit random value exchanged and the "ADD-IP" which is equivialant of the "BU" can be verified with this random state that the ends are maintaining. The real issue shows up in that if you are worried about an ease-dropper that can "see" the initial INIT/INIT-ACK exchange between the two peers. In that case it would then have the 64bits of randomness and could "inject" the false ADD/DEL that would hi-jack the association. Of course it could do other things too like knock down your assocation as well by sending a false ABORT chunk.... It is good to see that the routing infrastructure is believed to be non-compromised in MIP case. If we can make the same assumption then with one minor tweak we can add a mechanism to SCTP to authenticate the ADD-IP with private-public key pairs shared in the INIT/INIT-ACK. The obvious problem with this would be if the infrastructure was compromised and you had a true man in the middle who could intercept the INIT/INIT-ACK packets and change the keys... but that goes away if we make the same assumption MIP did :> Michael Tuexen and I were working on a seperate draft for this.. and were also somewhat concerned about the compromised routing structure too. If we don't have to worry about that our job just got easier :> Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 15:22:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21658 for ; Mon, 15 Sep 2003 15:22:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyvW-0007n5-FK for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 15:22:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FJMM9J029939 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 15:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyvV-0007mo-KA for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 15:22:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21577 for ; Mon, 15 Sep 2003 15:22:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyvU-0004tJ-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 15:22:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yyvT-0004tA-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 15:22:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyvC-0007c4-UY; Mon, 15 Sep 2003 15:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyuu-0007b9-Th for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 15:21:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21526; Mon, 15 Sep 2003 15:21:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyut-0004rx-00; Mon, 15 Sep 2003 15:21:43 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 19yyus-0004rr-00; Mon, 15 Sep 2003 15:21:42 -0400 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E6EDD6A903; Mon, 15 Sep 2003 22:21:35 +0300 (EEST) Message-ID: <3F66107F.4020401@kolumbus.fi> Date: Mon, 15 Sep 2003 22:18:23 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall R. Stewart (home)" Cc: Pekka Nikander , ietf@ietf.org, ipv6@ietf.org Subject: Re: Spoofing and SCTP ADD-IP (was Re: Solving the right problems ...) References: <3F6239E0.8090001@stewart.chicago.il.us> <01df01c36a7b$840dbb80$63124104@eagleswings> <3F61EAC2.7020304@stewart.chicago.il.us> <20030912165739.50b3866b.moore@cs.utk.edu> <3F6239E0.8090001@stewart.chicago.il.us> <5.2.0.9.2.20030913095009.0301ea40@pop.mcilink.com> <3F6373FD.1020308@stewart.chicago.il.us> <3F65FA9E.2010801@nomadiclab.com> <3F660ACD.90603@stewart.chicago.il.us> In-Reply-To: <3F660ACD.90603@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall R. Stewart (home) wrote: > Now as to the applicability in SCTP and ADD-IP... > > There is a difference with mobile-ip in that an SCTP association is already > established. Each node CN and MN have "connection" state. There has > been a 64bit random value exchanged and the "ADD-IP" which is equivialant > of the "BU" can be verified with this random state that the ends are > maintaining. The real issue shows up in that if you are worried about > an ease-dropper that can "see" the initial INIT/INIT-ACK exchange > between the two peers. In that case it would then have the 64bits of > randomness > and could "inject" the false ADD/DEL that would hi-jack the association. Of > course it could do other things too like knock down your assocation as well > by sending a false ABORT chunk.... Yes. Unless you are encrypting the whole session, on-path attackers can already do almost anything. They can start a session for you. They can abort a session for you. They can hijack a session from you. They can modify a session. > It is good to see that the routing infrastructure is believed to be > non-compromised > in MIP case. If we can make the same assumption then with one minor > tweak we can add a mechanism to SCTP to authenticate the ADD-IP with > private-public key pairs shared in the INIT/INIT-ACK. The obvious > problem with this would be if the infrastructure was compromised and you > had a true man in the middle who could intercept the INIT/INIT-ACK > packets and > change the keys... but that goes away if we make the same assumption MIP > did :> The question you have to ask is: What is the difference between the "Internet as is" and "Internet with ADD-IP (or MIP)". You can do the analysis case by case, such as for plaintext communications and for cryptographically protected communications and with or without the compromised infrastructure. For instance, assuming plaintext SCTP packets, presumably in the current Internet all on-path attackers will be able launch the attacks I listed above. But I hope that not everyone in the whole Internet will be able to e.g. disconnect SCTP sessions from a given host. The same properties should stay if you add a feature such as ADD-IP. On the other hand, if we assume that the routing infrastructure is compromised, then even in the current Internet I can go and intercept your plain sessions and cause all kinds of interesting problems. I would allow this to happen even with ADD-IP, as long as it does not make the problem worse. With cryptographic protection (e.g. IPsec) on the SCTP packets, you should be safe even from on-path attackers. Again, if you add ADD-IP feature the same property should stay. Note that there are some DoS attacks that remain regardless of cryptographic protection. For instance, by interfering with ARP/ND you could block the flow of packets. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 18:01:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27789 for ; Mon, 15 Sep 2003 18:01:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1OL-0005si-Sh for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:00:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FM0HYp022600 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1OL-0005p4-F2 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 18:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27681 for ; Mon, 15 Sep 2003 18:00:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1OI-0006mQ-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:00:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z1OH-0006mN-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:00:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1N7-0005gq-Py; Mon, 15 Sep 2003 17:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1MT-0005gH-2n for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 17:58:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27615; Mon, 15 Sep 2003 17:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1MP-0006kO-00; Mon, 15 Sep 2003 17:58:17 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19z1MO-0006jR-00; Mon, 15 Sep 2003 17:58:16 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8FLuar14139; Mon, 15 Sep 2003 14:56:36 -0700 X-mProtect: <200309152156> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcylVQW; Mon, 15 Sep 2003 14:56:34 PDT Message-Id: <4.3.2.7.2.20030915144051.02dad4a8@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Sep 2003 14:54:15 -0700 To: Margaret Wasserman , Thomas Narten From: Bob Hinden & Brian Haberman Subject: Request to Advance "MIB for the Internet Protocol (IP)" Cc: ipv6@ietf.org, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Margaret, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-04.txt Pages : 114 Date : 2003-9-15 A working group last call for this document was completed on 16 July 2003. This draft resolves issues raised during the last call. Bob Hinden / Brian Haberman IPv6 Working Group Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 18:18:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29457 for ; Mon, 15 Sep 2003 18:18:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1fz-0006ub-62 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:18:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FMIVhi026568 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1fz-0006uR-13 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 18:18:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29363 for ; Mon, 15 Sep 2003 18:18:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1fw-000706-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:18:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z1fv-000703-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:18:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1fW-0006kG-AK; Mon, 15 Sep 2003 18:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1fF-0006jF-1u for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 18:17:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29284 for ; Mon, 15 Sep 2003 18:17:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1fC-0006zP-00 for ipv6@ietf.org; Mon, 15 Sep 2003 18:17:42 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19z1fB-0006zM-00 for ipv6@ietf.org; Mon, 15 Sep 2003 18:17:41 -0400 Message-ID: <050701c37bd7$35f88390$956015ac@dclkempt40> From: "James Kempf" To: "Dave Crocker" , "IPV6 WG" References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> <17230000648.20030911225339@brandenburg.com> Subject: Re: domain names as end-point identifiers? Date: Mon, 15 Sep 2003 15:17:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dave, I've been trying to stay out of this discussion, but there's one point in your email that I think needs comment, and since I haven't seen anybody else make it, I guess it's up to me. > Are we, perhaps, trying to add other functionality to the IP service, beyond > simply providing the current IP service, enhanced to support multihoming and > mobility? For example, are we trying to add extra levels of security to the > basic service, beyond simply making the use of multiple addresses carry the > same, minimal security functions present for current, single-address IP? > > The "security" associated with a current, bare-bones mono-address host-to-host > IP exchange is pretty darn small. I'd summarize it as simply being the > assertion that a datagram probably did come from the IP address in the > relevant field of the datagram. Well, I think an argument could be made that even this isn't guaranteed. Given the lax security on address translation for the link between the last hop router and the host, various kinds of attacks could be mounted that would allow an attacker to send a packet that looked as if it originated from a particular IP address claimed by a victim on the subnet. In addition, from what I've heard, some ISPs don't have any ingress filters in place, so such an attack could even originate from another subnet. With wired networks, this isn't so much of a problem because the physical access to the last hop can be restricted, or (in the case of serial access) restricted using PPP or other means. With wireless networks and broadband networks that use shared access media, there may be an issue, however. > That's why MAST only tries to ensure an > equivalent degree of assurance that latter datagrams with different IP > addresses came from the same "system" that sent the first one. If you really > need stronger security, use IPSEC, TLS, or whatever. > > Why do we need more, at the IP level for multihoming or mobility? > For mobile networks, there's a need if the mobile host is allowed to send a routing update to the correspondent host. The correspondent host needs some assurance that the routing update came from a node that is authorized to issue such an update. This is only a problem because, unlike the presumed security of the routing infrastructure itself, end hosts presumably cannot be trusted to issue routing updates only on their own behalf. I don't know enough about the specific problems of multihoming to make a comment on that. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 18:23:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29749 for ; Mon, 15 Sep 2003 18:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1kX-0007Ks-BU for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:23:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FMNDCo028198 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1kX-0007Kj-3g for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 18:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29712 for ; Mon, 15 Sep 2003 18:23:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1kU-00077V-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:23:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z1kT-00077S-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1kN-0007EN-AS; Mon, 15 Sep 2003 18:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1jh-0007Dc-7W for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 18:22:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29694 for ; Mon, 15 Sep 2003 18:22:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1je-00076z-00 for ipv6@ietf.org; Mon, 15 Sep 2003 18:22:18 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19z1jd-00076w-00 for ipv6@ietf.org; Mon, 15 Sep 2003 18:22:17 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8FMMQxS013874; Tue, 16 Sep 2003 00:22:26 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 16 Sep 2003 00:22:12 +0200 Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: IPV6 WG To: Pekka Nikander From: Iljitsch van Beijnum In-Reply-To: <3F65A1E3.4090207@nomadiclab.com> Message-Id: <0DA833F5-E7CB-11D7-8D68-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka, On maandag, sep 15, 2003, at 13:26 Europe/Amsterdam, Pekka Nikander wrote: > It looks like that we are speaking about different issues. > I was trying to analyse the long term consequences of > various practises. I fully agree that we most probably > need to have identifiers that are also locators for quite > some time. (That's why I think Hinden/Haberman addresses > are probably good, even though they act as locators only > locally.) We may indeed be talking about different aspects of this huge multi-faceted problem/opportunity. I think unique local addresses can make for good identifiers that are also locators, but only if you make the assumption they're only used as reachable legacy addresses or locators if there is nothing else available. If you're not going to be able to reach the identifier as a locator, your _really_ want to know that immediately so you can proceed to do a locator lookup rather than first timeout on a single homed compatible connect. This implies that when two different organizations merge their networks clients will continue to use the PA addresses if these are available. It also means those addresses are of little use for legacy operation. > Furthermore, I am not so much concerned about multi-homing. > Multi-homing is only one aspect. Remember that I was not > posting the message to multi6. There are also other needs for > stable end-point identifiers. Like what? :-) Multihoming is the most pressing problem because there is no good alternative. >>> Now, if we use identifiers that are never locators, the >>> situation seems to be semantically simple to me. >> Maybe in theory. In practice, when you see a 128 bit value in a place >> where you would expect an IPv6 address, > I was not really discussing backwards API issues either. > If we go for a real separation of locators and identifiers, > we will also have to define new APIs in the longer run. > And slightly revised transport protocols, too. Are you sure we won't be seeing IP version number depletion before that? What exactly do you want to change about the APIs and transport protocols? > (I know, the need to revise is actually *a* reason for doing > the separation at the transport, e.g. using SCTP. Note that SCTP is cool in some regards but it in no way does a locator/identifier separation. Actually SCTP only makes things worse as you now have even more addresses to worry about at the application level. >> you not only want to know whether it's an identifier or >> a locator (this part would be easy) but also if it's used >> in the context of multihomed communication or in the context of >> single homed communication. That's the hard part. > Sorry, but now I don't understand your thinking at all. Firstly, > I still think that if we mix the two, it would be hard to know > which one an item is. The question here is whether we're going to see those locators and/or identifiers outside of a locator of identifier context, and, if we do, whether it's important that we can regain such a context. > Secondly, I honestly don't understand > why one should see any difference between singly homed or > multi-homed communication. It really looks like that we are > speaking about really different things. Not so much multihomed or single homed, but mulithoming (loc/id) aware or non multihoming aware. >>> On the other hand, if we use identifiers that are sometimes >>> also locators, I'm afraid of semantic confusion. How do >>> you know if a given identifier can be used as a locator >>> or not? >> You can either assume the identifier is a reachable locator (having >> the identifier be an _unreachable_ locator isn't very smart) and use >> it. > To me it looks like that you are going back to the current > situation, where the locators and identifiers are overloaded. Not really. An identifier is fixed, a locator is subject to change. That doesn't mean they can't be the same at one time or another, as long as the value can be changed in the places where it's a locator while it stays the same in the places where it acts as an identifier. >> Using these mechanisms in cases where the availability of an >> authority can be assumed (i.e., when you can look the whole thing up >> in the DNS) doesn't make much sense to me. > Firstly, we still don't have secure DNS. The DNS is secure enough more than 99% of the time. > Secondly, having to > rely on an authority seems like a bad approach to me. At least > when compared to one where you don't need to rely on authority. I agree that the current way of doing it where I go ask some root nameservers to give me a pointer to my neighbor can be pretty pathetic at times. On the other hand it's the only way to find unknown correspondents that makes sense. > (Just can't resist: Could we compare this to the difference > between Aristolean scholastics and Baconian science? :-) Feel free... Me, I'm more of the Cartesian persuasion when it comes to this. From another message: > I think that most of the threats and much of the solution > model would most probably apply also to SCTP ADD-IP and, of course, > also other multi-address multi-homing solutions. You're assuming a view of the world that is very much MIP-inspired. There are other ways to do it. One would be a distributed database where the id->loc mappings are kept for everyone to find, another is setting up shared state at the start of an association and use that to authenticate address jumps. Then, unless you're dealing with a man in the middle, you can be sure you're still talking to the same person as before. Iljitsch -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 18:41:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00764 for ; Mon, 15 Sep 2003 18:41:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z21Y-0000S3-M3 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:40:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FMemjQ001729 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 18:40:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z21Y-0000Ro-Gf for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 18:40:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00609 for ; Mon, 15 Sep 2003 18:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z21J-0007RI-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:40:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z21I-0007RD-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 18:40:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z20s-00004r-Iq; Mon, 15 Sep 2003 18:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z20K-0008Uz-QX for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 18:39:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00494 for ; Mon, 15 Sep 2003 18:39:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z20H-0007O8-00 for ipv6@ietf.org; Mon, 15 Sep 2003 18:39:29 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19z20G-0007N8-00 for ipv6@ietf.org; Mon, 15 Sep 2003 18:39:29 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8FMi4P17641; Mon, 15 Sep 2003 15:44:04 -0700 Date: Mon, 15 Sep 2003 15:38:56 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <88175974167.20030915153856@brandenburg.com> To: "James Kempf" CC: "IPV6 WG" Subject: Re: domain names as end-point identifiers? In-Reply-To: <050701c37bd7$35f88390$956015ac@dclkempt40> References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> <17230000648.20030911225339@brandenburg.com> <050701c37bd7$35f88390$956015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, >> The "security" associated with a current, bare-bones mono-address >> host-to-host IP exchange is pretty darn small. I'd summarize it as simply >> being the assertion that a datagram probably did come from the IP address >> in the relevant field of the datagram. JK> Well, I think an argument could be made that even this isn't guaranteed. That's why I said "probably". But my real point is that relying on that "probably" is at the core of most TCP and UDP use today. By suggesting that additional security issues go beyond the specific needs of multiaddressing, I am certainly not suggesting that those issues are minor. However I find that clarity about the goals being served helps design processes quite a bit. At the least it can help avoid feature creep, and thereby facilitate simpler design and easier adoption. JK> For mobile networks, there's a need if the mobile host is allowed to send a JK> routing update to the correspondent host. I cannot imagine anyone seriously disagreeing with you. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 20:05:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03297 for ; Mon, 15 Sep 2003 20:05:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3Km-0004HR-Qa for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 20:04:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G04iSi016447 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 20:04:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3Km-0004HC-Ly for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 20:04:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03194 for ; Mon, 15 Sep 2003 20:04:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z3Kk-0000Wl-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 20:04:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z3Kk-0000Wh-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 20:04:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3K6-00045t-Gc; Mon, 15 Sep 2003 20:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3K4-00045e-8x for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 20:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03110 for ; Mon, 15 Sep 2003 20:03:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z3K2-0000U8-00 for ipv6@ietf.org; Mon, 15 Sep 2003 20:03:58 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19z3K1-0000Sy-00 for ipv6@ietf.org; Mon, 15 Sep 2003 20:03:57 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8G03Koj018682; Mon, 15 Sep 2003 17:03:21 -0700 (PDT) Received: from par (par.Eng.Sun.COM [129.146.89.82]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8G03JQ19751; Tue, 16 Sep 2003 02:03:19 +0200 (MEST) Date: Mon, 15 Sep 2003 17:03:12 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: domain names as end-point identifiers? To: Dave Crocker Cc: IPV6 WG In-Reply-To: "Your message with ID" <17030979015.20030911230958@brandenburg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > MT> In the case of mobility and multihoming, you might want a stable > MT> identifier on a per-packet basis which is independent of the routing > MT> layer. > > A number of folks clearly have in mind using the identifier in every packet. > My question is: Why is this needed? What requires putting the identifier in > every packet, rather than using it a occasional, special points of an > interaction, such as initial rendezvous? I don't think an identifier is necessary in every packet. But I do think it makes sense to have a shim layer above IP which uses locators in the packets below (for IP's routing) and presents fixed length identifiers in the pseudo-headers passed to/from the upper layer protocols. The reason having identifiers in every packet isn't useful is that if you want to avoid facilitating redirection attacks of packet flows, then the receiver needs to verify at some level the relationship between locators and identifiers. The state (which can be soft-state created dynamically using a protocol similar to MAST) needed for this verification allows the receiver to recreate a packet with the same identifiers as what was sent by the peer ULP. Thus between the ULPs the shim provides a service which passes what looks like packets containing 128 bit identifiers, even though on the wire the packets have 128 bit locators. > Are we, perhaps, trying to add other functionality to the IP service, beyond > simply providing the current IP service, enhanced to support multihoming and > mobility? For example, are we trying to add extra levels of security to the > basic service, beyond simply making the use of multiple addresses carry the > same, minimal security functions present for current, single-address IP? I think the goal should be to not be any worse than the current IPv4 internet. In that Internet it is relatively easy for an attacker on the path between the two endpoints to redirect the packet flow - for instance it can use ARP spoofing like attacks to siphon off packets. But attackers that are not on this path can at most inject packets - with bogus source addresses in many cases. > The "security" associated with a current, bare-bones mono-address > host-to-host IP exchange is pretty darn small. I'd summarize it as simply > being the assertion that a datagram probably did come from the IP address in > the relevant field of the datagram. That's why MAST only tries to ensure an > equivalent degree of assurance that latter datagrams with different IP > addresses came from the same "system" that sent the first one. If you really > need stronger security, use IPSEC, TLS, or whatever. To analyze the security you have to look a more than just the IP layer. With TCP the initial sequence number makes it a tad bit harder (especially with non-guessable ISNs) for an off-path attacker to spoof a connection. While other protocols, such as DNS over UDP, require just guessing a 16 bit number in order to spoof a DNS response. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 20:47:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04607 for ; Mon, 15 Sep 2003 20:47:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3zx-00068l-Tw for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 20:47:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G0lHxB023602 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 20:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3zx-00068b-PG for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 20:47:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04488 for ; Mon, 15 Sep 2003 20:47:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z3zv-0000yf-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 20:47:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z3zv-0000yc-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 20:47:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3zi-0005xz-EZ; Mon, 15 Sep 2003 20:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3z2-0005xN-PK for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 20:46:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04456 for ; Mon, 15 Sep 2003 20:46:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z3z0-0000xu-00 for ipv6@ietf.org; Mon, 15 Sep 2003 20:46:18 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19z3yz-0000xi-00 for ipv6@ietf.org; Mon, 15 Sep 2003 20:46:17 -0400 Subject: RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) Date: Mon, 15 Sep 2003 17:45:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?) Thread-Index: AcN7dc/HRj2+1deYQtKSWsT6Ye0LaAAc0B5A From: "Michel Py" To: "Pekka Nikander" Cc: "IPV6 WG" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, > Pekka Nikander wrote: > I don't remember any more what might have been the reasons > for having more bits. Could you please remind me? Darn, I was hoping _you_ could refresh my memory. I think that there were two things: crypto and hints about the locators. If my recollection is correct (which can be doubted) here it is: - For HIP, one of the issues you have is latency with the initial negotiation, and I think I remember you saying that you could use some extra bits to embed some crypto in order to reduce the number of round trips necessary. Or maybe that is what you wished you had if you were to apply HIP security to MHAP, can't remember. - For MHAP, there were two things I think: 1. I had wished at some point that I could embed a part of the locator's address in the identifier in order to provide enough clue to take a crapshoot at bypassing the loc/id centralized mapping. 2. We discussed CGIs and came to the conclusion that besides the Intellectual Property issues with them there was no way to make them workable with the MHAP identifier being only 128 bits. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 21:27:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06026 for ; Mon, 15 Sep 2003 21:27:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4ct-0007nN-3m for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 21:27:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G1RVuD029964 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 21:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4cs-0007nD-V7 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 21:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05935 for ; Mon, 15 Sep 2003 21:27:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z4cq-0001Qp-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 21:27:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z4cp-0001Qm-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 21:27:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4cQ-0007cN-Rx; Mon, 15 Sep 2003 21:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4bw-0007bi-Ud for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 21:26:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05878 for ; Mon, 15 Sep 2003 21:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z4bu-0001Pk-00 for ipv6@ietf.org; Mon, 15 Sep 2003 21:26:30 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19z4bt-0001PG-00 for ipv6@ietf.org; Mon, 15 Sep 2003 21:26:29 -0400 Subject: RE: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Date: Mon, 15 Sep 2003 18:25:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Thread-Index: AcN7cKFV3J5sMgT/SSS9vqOBNjWHHgAe+ohQ From: "Michel Py" To: "Pekka Nikander" Cc: "IPV6 WG" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, > Pekka Nikander wrote: > So, the question is about either using identifiers that > sometimes are also locators vs. using identifiers that > never are locators. If we could use identifiers that > are always also locators, we would not need this discussion > at all; the current IP addresses should do well. Indeed, this the existing situation; the issue being size and even more important stability of the GRT. > Now, if we use identifiers that are never locators, the > situation seems to be semantically simple to me. An > identifier identifies a (potential) end-point of > communication. However, it alone is not enough for > communication. You also need to get the locator (the > address), in some way or another. Crystal. > On the other hand, if we use identifiers that are sometimes > also locators, I'm afraid of semantic confusion. How do you > know if a given identifier can be used as a locator or not? [note that I am being the devil's advocate here. I will cc: you on a related thread on the MHAP list soon, as I will likely adopt the same line as you but for different reasons]. Please explain me why does knowing matter if the locator and the identifier have the same semantics? I mean, host A wants to talk to host B; host A gets host B's {address|identifier} from DNS. Host A sends the packet to the router with B's {address|identifier} as the destination. Why should host A care at all if the {address|identifier} is a PA locator (because B is singlehomed) or a PI identifier? I can understand the reasoning when the id/loc mapping mechanism resides in the source host, but not when it resides within the routing system. There is a huge advantage in terms of bootstrapping the protocol: imagine you can make a non-HIP host talk to a HIP host and still benefit from the HIP functionality or some of it. > If you encode it somehow to the bits, then you are actually > going into the clean separation anyway. Indeed; note that I insisted that we keep the "u" bit for the time being precisely for this reason even though we don't know what to do with it as of now. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 15 21:30:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06415 for ; Mon, 15 Sep 2003 21:30:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4fk-0008R1-5g for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 21:30:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G1USE6032417 for ipv6-archive@odin.ietf.org; Mon, 15 Sep 2003 21:30:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4fj-0008Qm-Uw for ipv6-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 21:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06270 for ; Mon, 15 Sep 2003 21:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z4fh-0001aZ-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 21:30:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z4fg-0001aW-00 for ipv6-web-archive@ietf.org; Mon, 15 Sep 2003 21:30:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4fM-00086a-NS; Mon, 15 Sep 2003 21:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4f6-00085j-2G for ipv6@optimus.ietf.org; Mon, 15 Sep 2003 21:29:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06238 for ; Mon, 15 Sep 2003 21:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z4f3-0001ZE-00 for ipv6@ietf.org; Mon, 15 Sep 2003 21:29:45 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19z4f2-0001Ym-00 for ipv6@ietf.org; Mon, 15 Sep 2003 21:29:45 -0400 Subject: RE: domain names as end-point identifiers? Date: Mon, 15 Sep 2003 18:29:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: domain names as end-point identifiers? Thread-Index: AcN75g7gkL+oVYLnSV6bKr3IsbdhIgAB6sYw From: "Michel Py" To: "Erik Nordmark" Cc: "IPV6 WG" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Erik, > Erik Nordmark wrote: > I don't think an identifier is necessary in every packet. > But I do think it makes sense to have a shim layer above IP which > uses locators in the packets below (for IP's routing) and presents > fixed length identifiers in the pseudo-headers passed to/from the > upper layer protocols. > The reason having identifiers in every packet isn't useful is that > if you want to avoid facilitating redirection attacks of packet flows, > then the receiver needs to verify at some level the relationship between > locators and identifiers. The state (which can be soft-state created > dynamically using a protocol similar to MAST) needed for this > verification allows the receiver to recreate a packet with the same > identifiers as what was sent by the peer ULP. Thus between the ULPs the > shim provides a service which passes what looks like packets containing > 128 bit identifiers, even though on the wire the packets have 128 bit > locators. You just described MHAP. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 16 01:42:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12541 for ; Tue, 16 Sep 2003 01:42:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8b8-0006mr-Kb for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 01:41:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G5fwWB026083 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 01:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8b8-0006mc-Fv for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 01:41:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12516 for ; Tue, 16 Sep 2003 01:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z8b5-0003jz-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 01:41:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z8b4-0003jv-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 01:41:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8aD-0006iM-Qu; Tue, 16 Sep 2003 01:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8ZZ-0006hW-Mh for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 01:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12494 for ; Tue, 16 Sep 2003 01:40:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z8ZW-0003jW-00 for ipv6@ietf.org; Tue, 16 Sep 2003 01:40:18 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 19z8ZV-0003iy-00 for ipv6@ietf.org; Tue, 16 Sep 2003 01:40:17 -0400 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 767DF24; Tue, 16 Sep 2003 08:53:10 +0300 (EEST) Message-ID: <3F66A227.6050809@nomadiclab.com> Date: Tue, 16 Sep 2003 08:39:51 +0300 From: Pekka Nikander Reply-To: IPV6 WG , Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPV6 WG , hipsec@honor.trusecure.com Subject: What end-point identifiers are needed for? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Cross-posting to hipsec since this analysis seems to be important for HIP, too. CC:s appropriately, please.] The recent discussion on the ML has led me to believe that we have a fairly poor understanding on what we are speaking about. (Dave Crocker has also privately pointed this out, thereby making my mind clearer.) This is yet another strawman attempt to try to clarify the problem scope, or at least something. After some thought, I think that we have at least three main classes of needs for (loosely speaking) end-point identifiers, and some subclasses: 1) Identification 1a) identification for the purpose of mobility and multi-homing 1b) identification for the purpose of referral or rendezvous (related to 1a but slightly different) 1c) identification for other, e.g. administrative, purposes 2) Referral 3) Rendezvous 3a) initial rendezvous with no existing connection 3b) subsequent rendezvous, e.g., after concurrent movement There are probably others, but these are the ones that my poor brains managed to (small pun) identify. The *point* of this mail is that the different needs have different requirements, and that it may be very difficult or even impossible to design one class of identifiers that would fulfil all of the primary needs plus the related secondary needs, such as privacy and security. Let me try to brefly analyze the above outlined needs one by one, in reverse order. 3) Rendezvous ------------- I haven't seen any good definition for rendezvous in the meaning that we seem to be using it. (If you have, please post a reference). So, here is an attempt: End-point rendezvous refers to the situation where one end-point makes a contact with an explicitly identified other end-point over the network. To be able to perform rendezvous, the first end point seems to need - a means to identify the second end-point (1a or 1b) - a means to reach the second end-point, i.e., locator In the case of 3b), the end-points have been in contact with each other and share explicit "fresh" state. Hence, they can identify each other just based on this state, and they do not necessarily need any stable, long-living end-point identifiers. Due to mobility, they need a service that gives the currently active locator for the other end-point, i.e., the equivalent of mobile IP home agent. In the case of 3a), the end-points have not been in contact with each other, and the only "state" that they share is that the first end-point has an identifier that denotes the second one. The service giving locators does not seem to be very fast or dynamic, as long as the given locator will reach the given end-point. That is, if we have the equivalent of mobile ip home agent, the locator used for 3a) can be the equivalent of mobile ip home address. 2) Referral ----------- Again, I haven't seen any good definitions (and again, please post if you have). Another attempt: Inter-end-point referral refers to a situation where one end-point hands over information about a second end-point to a third end-point, with the purpose of allowing the third end-point to make a rendezvous with the second end-point. For referral to succeed, the transferred information must give the receiving end-point - a means to identify the second end-point (1b) - a means to reach the second end-point Note that in this case the "means to reach" does not need to be a locator. It can be a name that the rendezvous (3b) service is able to convert to a locator. 1) Identification ----------------- Now we get to the real business. Just to refresh the mind, here are again the suggested subclasses: 1a) identification for mobility and multi-homing 1b) identification for referral or rendezvous 1c) identification for other, e.g. administrative, purposes 1a) To me, identification for mobility and multi-homing seems to be the easiest one. There we are only interested in gaining assurance that the peer remains the same. That is, for the sole purpose of mobility or multi-homing, we do not really care with whom we are communicating with, but only that the peer end-point is not changed in mid-communication due to mobility, multi-homing, or attacks based on mobility or multi-homing mechanisms. [There is also the need of keeping the apparent identifier to TCP or UDP stable, but that is really a secondary need, created by the desire of backwards compatibility.] For the purposes of 1a) it seems to be sufficient to create an ephemeral identifier, only known to the participating end-points (and a sufficiently limited class of potential attackers). There is no need for long-lasting stable identifiers. Identification at the mobility related rendezvous (3b) is really a special case of the generic mobility related identification, and therefore the argumentation above holds. 1b) For initial rendezvous and referral, we need something stable. That is, we need to have an identifier that allows us to identify the peer end-point even if it does not share any state (but the identifier/identity) with us. Note that I have explicitly separated the function of locating the end-point from the function of identifying the end-point. For rendezvous and referral we naturally need both. However, they are distinct functions, and it is technically *possible* to use different tokes for these purposes. On the other hand, if there is a need for two tokens, we can also define that the end-point identifier (for referral or initial rendezvous) consists of a *pair* of tokens, ones used for identification and one used for finding the current address. 1c) The final class of needs for identification seems to have nothing to do with mobility, multi-homing or even referral or even rendezvous. There are other needs for identifying end-points: - Human GUI needs: to allow humans to type in names that refer to end-points - Various administrative needs: - configuration management - inventory management - monitoring and intrusion detection - etc. - (running out of coffee.... can't think of others) ------------------------------------------------------------- The next step is to analyse the security and privacy threats associated with all of the above mentioned needs for identifiers. However, that is a subject of another mail. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 16 10:07:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14277 for ; Tue, 16 Sep 2003 10:07:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGTk-0000Br-69 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 10:06:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GE6qOQ000727 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 10:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGTj-0000Be-RD for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 10:06:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14172 for ; Tue, 16 Sep 2003 10:06:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGTh-00024k-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 10:06:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zGTh-00024h-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 10:06:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGSx-0008Un-Vf; Tue, 16 Sep 2003 10:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGSg-0008Tt-Ho for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 10:05:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14030 for ; Tue, 16 Sep 2003 10:05:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGSe-00023H-00 for ipv6@ietf.org; Tue, 16 Sep 2003 10:05:44 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19zGSd-00023E-00 for ipv6@ietf.org; Tue, 16 Sep 2003 10:05:43 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A14E61406D; Tue, 16 Sep 2003 10:05:43 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02300-10; Tue, 16 Sep 2003 10:05:42 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id BCD1714052; Tue, 16 Sep 2003 10:05:41 -0400 (EDT) Date: Tue, 16 Sep 2003 10:02:22 -0400 From: Keith Moore To: IPV6 WG , Pekka Nikander Cc: moore@cs.utk.edu, pekka.nikander@nomadiclab.com, ipv6@ietf.org, hipsec@honor.trusecure.com Subject: Re: What end-point identifiers are needed for? Message-Id: <20030916100222.44a7fa95.moore@cs.utk.edu> In-Reply-To: <3F66A227.6050809@nomadiclab.com> References: <3F66A227.6050809@nomadiclab.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 1) Identification > > 1a) identification for the purpose of mobility and > multi-homing > > 1b) identification for the purpose of referral > or rendezvous (related to 1a but slightly > different) > > 1c) identification for other, e.g. administrative, > purposes > > 2) Referral > > 3) Rendezvous > > 3a) initial rendezvous with no existing connection > > 3b) subsequent rendezvous, e.g., after concurrent movement this is similar to what I had come up with. > 3) Rendezvous > ------------- > To be able to perform rendezvous, the first end point seems > to need > > - a means to identify the second end-point (1a or 1b) > - a means to reach the second end-point, i.e., locator agreed. note that currently these tend to involve the same address, which means that the distinction looks subtle. but basically you do have to do both of these things. > In the case of 3b), the end-points have been in contact > with each other and share explicit "fresh" state. Hence, > they can identify each other just based on this state, > and they do not necessarily need any stable, long-living > end-point identifiers. this would require apps to define their own unique identifiers, which is harder than it might seem at first. (they can't use an IP address since these change. they could use the MAC address of an interface but interfaces can be unplugged, etc.) > In the case of 3a), the end-points have not been in contact > with each other, and the only "state" that they share is > that the first end-point has an identifier that denotes > the second one. this is what I have been calling referral - the end point wishing to make the connection needs to talk to a specific process but hasn't made contact with it yet. > The service giving locators does not seem > to be very fast or dynamic, as long as the given locator > will reach the given end-point. this seems like a dubious assertion to me. > That is, if we have the > equivalent of mobile ip home agent, the locator used for > 3a) can be the equivalent of mobile ip home address. maybe, but it's hard to know what you mean by "equivalent" here. > 2) Referral > ----------- > > Again, I haven't seen any good definitions (and again, > please post if you have). Another attempt: > > Inter-end-point referral refers to a situation where one > end-point hands over information about a second end-point > to a third end-point, with the purpose of allowing the > third end-point to make a rendezvous with the second end-point. > > For referral to succeed, the transferred information must give > the receiving end-point > > - a means to identify the second end-point (1b) > - a means to reach the second end-point > > Note that in this case the "means to reach" does not need > to be a locator. It can be a name that the rendezvous (3b) > service is able to convert to a locator. > right. it's just like what you were calling 3b except with the added constraint that the identifiers need to have the same meaning and be resolvable to locators from any point in the network. > 1) Identification > ----------------- > > Now we get to the real business. in your way of thinking :) > Just to refresh the mind, > here are again the suggested subclasses: > > 1a) identification for mobility and multi-homing > 1b) identification for referral or rendezvous > 1c) identification for other, e.g. administrative, purposes > > 1a) To me, identification for mobility and multi-homing seems to > be the easiest one. There we are only interested in gaining > assurance that the peer remains the same. That is, for the > sole purpose of mobility or multi-homing, we do not really > care with whom we are communicating with, but only that the > peer end-point is not changed in mid-communication due to > mobility, multi-homing, or attacks based on mobility or > multi-homing mechanisms. > > [There is also the need of keeping the apparent identifier to > TCP or UDP stable, but that is really a secondary need, created > by the desire of backwards compatibility.] > > For the purposes of 1a) it seems to be sufficient to create > an ephemeral identifier, only known to the participating end-points > (and a sufficiently limited class of potential attackers). > There is no need for long-lasting stable identifiers. disagree. the problem is that you don't always know how many participating end points there will be. and an application - especially one that encompasses large numbers of hosts - can run indefinitely, meaning that the identifiers may need to last indefinitely. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 16 14:00:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29333 for ; Tue, 16 Sep 2003 14:00:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zK7j-0001e3-Ix for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 14:00:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GI0NcA006323 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 14:00:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zK7j-0001du-Ds for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 14:00:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29305 for ; Tue, 16 Sep 2003 14:00:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zK7h-0006rQ-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 14:00:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zK7g-0006rN-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 14:00:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zK6Q-0001S1-97; Tue, 16 Sep 2003 13:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zK5p-0001RY-9L for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 13:58:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29237 for ; Tue, 16 Sep 2003 13:58:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zK5n-0006pY-00 for ipv6@ietf.org; Tue, 16 Sep 2003 13:58:23 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19zK5m-0006om-00 for ipv6@ietf.org; Tue, 16 Sep 2003 13:58:22 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8GHvpM27039; Tue, 16 Sep 2003 10:57:51 -0700 X-mProtect: <200309161757> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHCZc8J; Tue, 16 Sep 2003 10:57:48 PDT Message-Id: <4.3.2.7.2.20030916105118.032a2928@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Sep 2003 10:55:33 -0700 To: ipv6@ietf.org From: Bob Hinden & Brian Haberman Subject: Results of Poll Cc: hinden@iprg.nokia.com, Brian Haberman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The results of the poll (appended below) started by the chairs in early August to get more feed back from the working about how to deprecate site-local are as follows: Preference A 32 45% Preference B 31 44% Preference C 8 11% -------------------------- Total Votes 71 100% The raw votes are available at: http://people.nokia.net/~hinden/ipv6-choices.html If we missed your preference or got it wrong, please let us know. There are a few conclusions that can be seen in this poll. Only 11% of the people responding wanted to defer the deprecation of site-local until an alternative was deployed. 89% wanted to deprecate prior to an alternative being standardized or at the same time an alternative was standardized. There was not a consensus about tieing the deprecation of site-local to defining an alternative or do the deprecation before defining an alternative. The working group is closely split on this. Even combing preferences B & C (i.e., 55%) does not form a consensus. Based on this, the chairs will plan to move the deprecation document and the local addressing specification forward at approximately the same time, but will not do anything to officially tie them together. Bob Hinden / Brian Haberman IPv6 w.g. chairs >Date: Mon, 04 Aug 2003 11:06:55 -0700 >To: ipng@sunroof.eng.sun.com >From: Bob Hinden >Subject: Moving forward on Site-Local and Local Addressing >Cc: hinden@iprg.nokia.com > >[IPv6 working group chair hat on] > >I think the working group has been making good progress on replacing >site-local addresses and wanted to get feed back from the working group on >how we should move forward. This is not intended to directly relate to >the ongoing appeal of the working groups decision to deprecate the usage >site-local addresses, but to get feedback on how to proceed. I think it >is very important that we move forward on this issue and not rehash what >has happened in the past. > >We now have a combined local addressing requirements document >, a specific alternative to >site-local addresses draft >(accepted as a working group item at the Vienna IETF), and will soon have >a draft describing why site-local addresses are being deprecated and doing >the formal deprecation (authors identified and outline discussed at the >Vienna IETF). Note that all of these documents will proceed through the >normal working group and IETF processes of last calls and review. > >I think legitimate questions have been raised about how the working group >should go about deprecating site-local addresses given their maturity in >the current specifications and use in deployed products. Specifically >should they be deprecated independently from having an alternative >solution available, at the same time an alternative is available, or >sometime after an alternative is available. A forth alternative is to not >replace site-local addresses in any form, but I think the working group >has made it clear that this is not a reasonable alternative. > >I would like to hear from the working group on how we should proceed. I >think the choices are: > >A) Deprecate Site-Local addresses independently from having an alternative >solution available. This would mean that the working group should treat >the deprecation, and requirements and solution documents outlined above >independently from each other. If there was no consensus on an >alternative a replacement would not happen. > >B) Deprecate Site-Local addresses at the same time as a alternative >solution is agreed to. This would mean advancing both documents at the >same time and making them include normative references to each other to >insure that they were published at the same time. This would result in >the deprecation only happening if a consensus was reached on an alternative. > >C) Deprecate Site-Local addresses after an alternative is defined, >standardized, and in operational practice. This would mean not advancing >a deprecation document until there was operational evidence that the >alternative was working and shown to be an improvement over Site-Local >addresses. > >Note: In the above choices "Deprecate Site-Local addresses" means >publishing an RFC that does the formal deprecation. > >Please respond to the list with your preference, or if there is an >alternative approach that is an improvement from the ones I outlined. I >hope that many of you will respond. > >Thanks, >Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 16 17:57:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15249 for ; Tue, 16 Sep 2003 17:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zNod-0003JZ-SE for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 17:57:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GLutmw012735 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 17:56:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zNod-0003JK-MS for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 17:56:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15159 for ; Tue, 16 Sep 2003 17:56:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zNob-0003ak-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 17:56:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zNoa-0003ah-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 17:56:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zNmo-0002oU-Sv; Tue, 16 Sep 2003 17:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zNmZ-0002o1-4L for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 17:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14998 for ; Tue, 16 Sep 2003 17:54:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zNmU-0003WD-00 for ipv6@ietf.org; Tue, 16 Sep 2003 17:54:43 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19zNmU-0003WA-00 for ipv6@ietf.org; Tue, 16 Sep 2003 17:54:42 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8GLsdp3000205; Tue, 16 Sep 2003 15:54:40 -0600 (MDT) Received: from par (par.Eng.Sun.COM [129.146.89.82]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8GLsbQ03521; Tue, 16 Sep 2003 23:54:37 +0200 (MEST) Date: Tue, 16 Sep 2003 14:54:30 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: What end-point identifiers are needed for? To: IPV6 WG , Pekka Nikander Cc: hipsec@honor.trusecure.com In-Reply-To: "Your message with ID" <3F66A227.6050809@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > For the purposes of 1a) it seems to be sufficient to create > an ephemeral identifier, only known to the participating end-points > (and a sufficiently limited class of potential attackers). > There is no need for long-lasting stable identifiers. Even if it is ephemeral you still need to be concerned about two parties, both attempting to communicate with a particular node, claiming to have the same identifier. Thus a high probability of uniqueness is a requirement. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 16 18:11:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16852 for ; Tue, 16 Sep 2003 18:11:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zO2p-0004Dm-26 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 18:11:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GMBZOJ016220 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 18:11:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zO2o-0004DX-Pt for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 18:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16701 for ; Tue, 16 Sep 2003 18:11:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zO2l-0003wJ-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 18:11:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zO2l-0003wE-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 18:11:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zO1L-0003pB-Ot; Tue, 16 Sep 2003 18:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zO17-0003oc-R2 for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 18:09:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16353 for ; Tue, 16 Sep 2003 18:09:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zO14-0003pT-00 for ipv6@ietf.org; Tue, 16 Sep 2003 18:09:46 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19zO14-0003oR-00 for ipv6@ietf.org; Tue, 16 Sep 2003 18:09:46 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8GM12oj017352; Tue, 16 Sep 2003 15:01:03 -0700 (PDT) Received: from par (par.Eng.Sun.COM [129.146.89.82]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8GM0wQ04134; Wed, 17 Sep 2003 00:00:59 +0200 (MEST) Date: Tue, 16 Sep 2003 15:00:52 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: domain names as end-point identifiers? To: Michel Py Cc: Erik Nordmark , IPV6 WG In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > You just described MHAP. I think I described the some high-level aspects of a potential class of solutions, thus I interpret your comment as MHAP belonging to that class or that it at least is consistent with the approach I described. Lots of important details might differ between different possible solution following that approach; for instance if you want to allow routers to rewrite source locators (in order to dynamically detect new locators to use for the peer) and also prevent redirection attacks, then there are some important details to work out. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 16 21:10:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22293 for ; Tue, 16 Sep 2003 21:10:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zQpS-0001U4-63 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 21:09:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H19waO005698 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 21:09:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zQpR-0001Tp-T0 for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 21:09:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22245 for ; Tue, 16 Sep 2003 21:09:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zQpP-0005pU-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 21:09:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zQpO-0005pO-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 21:09:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zQnb-0001C0-1X; Tue, 16 Sep 2003 21:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zQnX-0001B1-91 for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 21:07:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22074 for ; Tue, 16 Sep 2003 21:07:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zQnU-0005kc-00 for ipv6@ietf.org; Tue, 16 Sep 2003 21:07:56 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19zQnU-0005kN-00 for ipv6@ietf.org; Tue, 16 Sep 2003 21:07:56 -0400 Subject: RE: What end-point identifiers are needed for? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Sep 2003 18:07:23 -0700 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: What end-point identifiers are needed for? Thread-Index: AcN8G/uJYljfvIaxQHK2xfaIjhPGYwAm6NBA From: "Michel Py" To: "IPV6 WG" , "Pekka Nikander" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, > Pekka Nikander wrote: > 1a) To me, identification for mobility and multi-homing seems > to be the easiest one. There we are only interested in > gaining assurance that the peer remains the same. That is, > for the sole purpose of mobility or multi-homing, we do not > really care with whom we are communicating with, but only > that the peer end-point is not changed in mid-communication > due to mobility, multi-homing, or attacks based on mobility > or multi-homing mechanisms. This initially made me scream; after re-reading the text I understood the depth of it. I will point out though that I we have never inventoried a multi-homing solution that did not need referral and initial rendez-vous, which is why I wonder why you split the issue in two here. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 16 23:45:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26871 for ; Tue, 16 Sep 2003 23:45:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTF7-0006rb-8t for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 23:44:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H3ibBP026380 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 23:44:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTF7-0006rP-23 for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 23:44:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26795 for ; Tue, 16 Sep 2003 23:44:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zTF4-0007V3-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 23:44:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zTF4-0007V0-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 23:44:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTEY-0006jA-9N; Tue, 16 Sep 2003 23:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTDo-0006ik-7W for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 23:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26743 for ; Tue, 16 Sep 2003 23:43:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zTDl-0007Tg-00 for ipv6@ietf.org; Tue, 16 Sep 2003 23:43:13 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19zTDl-0007Td-00 for ipv6@ietf.org; Tue, 16 Sep 2003 23:43:13 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id F190014070; Tue, 16 Sep 2003 23:43:13 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27883-13; Tue, 16 Sep 2003 23:43:13 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id A63661405C; Tue, 16 Sep 2003 23:43:12 -0400 (EDT) Date: Tue, 16 Sep 2003 23:39:51 -0400 From: Keith Moore To: "Michel Py" Cc: moore@cs.utk.edu, Erik.Nordmark@sun.com, ipv6@ietf.org Subject: Re: domain names as end-point identifiers? Message-Id: <20030916233951.610feb8b.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 16 Sep 2003 18:57:29 -0700 "Michel Py" wrote: > I will point out though that these issues are not limited to a system > where routers are rewriting packets and that it is likely going to be > easier to tackle them by containing the translation into a smaller > number of devices (routers) vs. doing the the id/loc mapping in each and > every host. I have serious doubts about that; to me the boundary between API and host-to-network interface seems much cleaner and more definite than the boundary between one side of a router and another. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 00:16:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27862 for ; Wed, 17 Sep 2003 00:16:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTjP-000872-9w for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 00:15:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H4FtGg031181 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 00:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTjP-00086q-0j for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 00:15:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27759 for ; Wed, 17 Sep 2003 00:15:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zTjM-00003g-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 00:15:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zTjM-00003b-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 00:15:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTiZ-0007tO-Pc; Wed, 17 Sep 2003 00:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTiH-0007si-U5 for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 00:14:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27685 for ; Wed, 17 Sep 2003 00:14:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zTiF-000014-00 for ipv6@ietf.org; Wed, 17 Sep 2003 00:14:43 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19zTiF-00000c-00 for ipv6@ietf.org; Wed, 17 Sep 2003 00:14:43 -0400 Subject: RE: domain names as end-point identifiers? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Sep 2003 21:14:13 -0700 Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: domain names as end-point identifiers? Thread-Index: AcN8zdMt+9RoYfKqQcyUok79OefsqAAAWX4A From: "Michel Py" To: "Keith Moore" Cc: , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >> Michel Py wrote: >> I will point out though that these issues are not limited to a system >> where routers are rewriting packets and that it is likely going to be >> easier to tackle them by containing the translation into a smaller >> number of devices (routers) vs. doing the the id/loc mapping in each and >> every host. > Keith Moore wrote: > I have serious doubts about that; to me the boundary between API > and host-to-network interface seems much cleaner and more definite > than the boundary between one side of a router and another. That's only half the picture; host people tend to like host solutions and router people tend to like router solutions. You missed that half of the picture with NAT: yes NAT sucks, it does not change the fact that nowadays there are more NAT hosts than non-NAT hosts. And you also missed that half of the picture by pissing so many vendors about the NAT issue that made a point of not implementing 6to4 in their NAT boxes just to piss you off in return, where having 6to4 implemented in NAT boxes would have been by far the best promotion avenue for 6to4. Don't try to sell me that crap, I'm not buying it. Anyway, you missed the point: Although there are things (such as NAT) that eventually are worthy adopting the ideology-only "just say no" line (if done right), you can't apply this to everything and in the case of where the id/loc occurs we are looking more at a "whatever works" situation. Ideology is one thing, first try to overcome the handicap that id/loc mapping at the host level will generate hundreds or thousands more _times_ requests than on a router-based basis, two or three orders magnitude more. Given what you have posted recently, I guess it's not going to be DNS based. When you have solved the issue, come back and argue the argument again. Michel. =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 01:54:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00990 for ; Wed, 17 Sep 2003 01:54:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVGH-0002ON-QQ for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 01:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H5rvCB009189 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 01:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVGH-0002O8-Jz for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 01:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00945 for ; Wed, 17 Sep 2003 01:53:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zVGE-00019j-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 01:53:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zVGE-00019f-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 01:53:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVFN-0002K6-Vw; Wed, 17 Sep 2003 01:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVEk-0002Hi-5n for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 01:52:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00897 for ; Wed, 17 Sep 2003 01:52:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zVEg-00018q-00 for ipv6@ietf.org; Wed, 17 Sep 2003 01:52:18 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19zVEg-00018Q-00 for ipv6@ietf.org; Wed, 17 Sep 2003 01:52:18 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8H5uvP26406; Tue, 16 Sep 2003 22:56:57 -0700 Date: Tue, 16 Sep 2003 22:51:46 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <66100493311.20030916225146@brandenburg.com> To: IPV6 WG , hipsec@honor.trusecure.com Subject: Re: What end-point identifiers are needed for? In-Reply-To: <3F66A227.6050809@nomadiclab.com> References: <3F66A227.6050809@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, PN> [Cross-posting to hipsec since this analysis seems to PN> be important for HIP, too. CC:s appropriately, please.] I have to admit to being pretty confused about choosing the right venue for the various discussion going on. Absent better guidance, I am pointing mobility/multihoming discussions to multi6. I just sent that list the following announcement, which includes an I-D that discusses choices including endpoint identifier. Hence, it tries to go through some of the exercise in Pekka's query. - - - - - I've just submitted some new mobility/multihoming I-Ds for distribution. Meanwhile, they are available from my website, in text and MS Word formats. The first breaks out the "discussion" section of the original MAST paper and expands on it: Choices for Support of Multiaddressing Text: MSWord : The second is the revised draft proposal: Multiple Address Service For Transport (MAST): An Extended Proposal Text: MSWord: d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 08:23:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08261 for ; Wed, 17 Sep 2003 08:23:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbKb-0002gJ-TO for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 08:22:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HCMnba010308 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 08:22:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbKb-0002gB-Nh for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 08:22:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08212 for ; Wed, 17 Sep 2003 08:22:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbKa-00050A-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 08:22:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zbKa-000507-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 08:22:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbJr-0002bw-7l; Wed, 17 Sep 2003 08:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbJL-0002bX-DO for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 08:21:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08164 for ; Wed, 17 Sep 2003 08:21:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbJK-0004zZ-00 for ipv6@ietf.org; Wed, 17 Sep 2003 08:21:30 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbJJ-0004zK-00 for ipv6@ietf.org; Wed, 17 Sep 2003 08:21:29 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8HCKvx17836 for ; Wed, 17 Sep 2003 15:20:58 +0300 Date: Wed, 17 Sep 2003 15:20:56 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org Subject: comments on deprecate-site-local-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, A couple of comments on deprecate-site-local draft. In general, I think the doc is very good, but could use a bit boosting in a couple of areas (which -00 draft wouldn't.. :-) substantial ----------- Although the consensus was far from unanimous, the working group decided in its meeting in July 2003 to document these issues and the consequent decision to deprecate IPv6 site-local unicast addresses. ==> was this really the case? Didn't the WG decide on that already earlier, not at Vienna?? 2 Adverse effects of site local addresses ==> I showed this draft to a believer of site-local addressing, who had had very little experience with IPv6. He was not convinced of the arguments. This may be for one of the many reasons. One fix is to also refer to some documents which include more verbiage than this document, e.g. Margaret Wasserman's SL impact document -- note that such would necessarily have to be a normative reference then, requiring the publication of it as an Informational doc. 2.2 Manager pain, leaks ==> regarding the previous comment, this section should probably focus a bit more on the non-trivial leaks (any leak w/ RFC1918 addresses in the source/destination address is trivial), such as reverse DNS queries for RFC1918 addresses, passing RFC1918 addresses in the application payloads in general, etc. (pick non-NAT specific topics e.g. from Keith Moore's "What NATs break" paper or "NAT architectural considerations" RFC). 5 Security Considerations The link-local unicast prefix allows for some blocking action in firewall rules and address selection rules, which are commonly viewed as a security feature since they prevent packets crossing administrative boundaries. However, such blocking rules can be configured for any prefix, including the expected future replacement for the site-local prefix. Thus the deprecation of the site-local prefix does not endanger security. ==> s/link/site/, obviously. ==> I think the security considerations considers only one, but important aspect of the site-locals. One should also discuss the effect of stability to the availability (which is part of security), and the effect of explicit scope to the address selection -- e.g., the case with intra-domain VPN's which route some traffic directly to the Internet but some to through the VPN to the infrastructure: how to ensure that the traffic destined to internal hosts over the VPN doesn't end up in the Internet by accident (e.g. if the VPN is down). editorial --------- example in DNS or trace-route requests, causing the request to fail, ==> s/trace-/trace/ The leakage issue is largely unavoidable. While some applications are intrinsically scoped (eg. RA, ND), most applications have no ==> have to spell out RA & ND The current definition of scopes follows an idealized "concentric scope" model. ==> I don't understand the use of "concentric" in this context ? perhaps reword? boundaries, QOS boundaries, administrative boundaries, funding boundaries, some other kinds of boundaries, or a combination. It is ==> s/combination/combination of these/ ? Having non ambiguous address solves a large part of the developers' ==> s/non ambiguous/non-ambiguous/ (everywhere) ? This document formally deprecates the IPv6 link-local unicast prefix defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The special behavior of this prefix MUST no longer be supported in new implementations. ==> if the uppercase keywords are used, one has to add the reference to the definition of them up front in section 1 or thereabouts. 9 Acknowledgements ==> should probably be non-empty :-) 10 References ==> you're missing a ref to [Bradner, 1996]. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 08:23:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08324 for ; Wed, 17 Sep 2003 08:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbKs-0002l5-B8 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 08:23:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HCN6k2010597 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 08:23:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbKs-0002kq-5B for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 08:23:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08224 for ; Wed, 17 Sep 2003 08:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbKr-00050V-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 08:23:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zbKq-00050R-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 08:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbKp-0002gw-GL; Wed, 17 Sep 2003 08:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbKh-0002gU-Pn for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 08:22:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08216 for ; Wed, 17 Sep 2003 08:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbKg-00050G-00 for ipv6@ietf.org; Wed, 17 Sep 2003 08:22:54 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 19zbKf-0004zx-00 for ipv6@ietf.org; Wed, 17 Sep 2003 08:22:53 -0400 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 8E55C1C; Wed, 17 Sep 2003 15:35:40 +0300 (EEST) Message-ID: <3F6851F9.9000108@nomadiclab.com> Date: Wed, 17 Sep 2003 15:22:17 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: IPV6 WG Subject: APIs, locator-identifiers, DNS security, [and Cartesius] (was Re: A strawman analysis...) References: <0DA833F5-E7CB-11D7-8D68-00039388672E@muada.com> In-Reply-To: <0DA833F5-E7CB-11D7-8D68-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch, >> I was not really discussing backwards API issues either. If we go >> for a real separation of locators and identifiers, we will also >> have to define new APIs in the longer run. And slightly revised >> transport protocols, too. > > > > What exactly do you want to change about the APIs and transport > protocols? Well, I do not exactly /want/ to change the APIs or tranport protocols. I only *anticipate* that due to mobility, multi-address multi-homing, and intermittend connectivity, we end up making changes to the transport protocols, anyway. I also anticipate that if we take the id/loc separation to its logical end, we will create a new set of APIs that will slowly replace the current socket APIs in new applications. >>> you not only want to know whether it's an identifier or a locator >>> (this part would be easy) but also if it's used in the context of >>> multihomed communication or in the context of single homed >>> communication. That's the hard part. > >> Sorry, but now I don't understand your thinking at all. Firstly, I >> still think that if we mix the two, it would be hard to know which >> one an item is. > > The question here is whether we're going to see those locators and/or > identifiers outside of a locator of identifier context, and, if we > do, whether it's important that we can regain such a context. Sorry, but I still don't understand. What is "a locator of identifier context"? > Not really. An identifier is fixed, a locator is subject to change. > That doesn't mean they can't be the same at one time or another, as > long as the value can be changed in the places where it's a locator > while it stays the same in the places where it acts as an identifier. That really sounds like Mobile IP to me. You explicitly seem to expect that some identifiers will (most of the time) work as locators. That may work for the common multi-homing cases today, but it fails to address the most common multi-homing case tomorrow: mobile devices that have multiple radio interfaces that they use at the same time. > The DNS is secure enough more than 99% of the time. YMMV. Especially with DynDNS. >> (Just can't resist: Could we compare this to the difference >> between Aristolean scholastics and Baconian science? :-) > > Feel free... Me, I'm more of the Cartesian persuasion when it comes > to this. Ah, that explains a lot. :-) I gave up the idea of the Cartesian theatre already a few years ago. You really must start reading Dennet and Dawkings. :-) --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 09:03:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09791 for ; Wed, 17 Sep 2003 09:03:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbxl-0004eb-S4 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 09:03:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HD3HuS017888 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 09:03:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbxl-0004eR-Ka for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 09:03:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09749 for ; Wed, 17 Sep 2003 09:03:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbxk-0005WU-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 09:03:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zbxj-0005WR-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 09:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbxW-0004aM-Pj; Wed, 17 Sep 2003 09:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbwY-0004ZV-QJ for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 09:02:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09724 for ; Wed, 17 Sep 2003 09:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbwX-0005Vp-00 for ipv6@ietf.org; Wed, 17 Sep 2003 09:02:01 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19zbwW-0005Vk-00 for ipv6@ietf.org; Wed, 17 Sep 2003 09:02:00 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D190C1416F; Wed, 17 Sep 2003 09:01:59 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06802-11; Wed, 17 Sep 2003 09:01:58 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id B72001418B; Wed, 17 Sep 2003 09:01:57 -0400 (EDT) Date: Wed, 17 Sep 2003 08:58:34 -0400 From: Keith Moore To: "Michel Py" Cc: moore@cs.utk.edu, Erik.Nordmark@sun.com, ipv6@ietf.org Subject: Re: domain names as end-point identifiers? Message-Id: <20030917085834.0fb9e444.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > first try to overcome the handicap that id/loc > mapping at the host level will generate hundreds or thousands more > _times_ requests than on a router-based basis, two or three orders > magnitude more. Having the routers cache id-to-loc mappings is one thing; having them perform id-to-loc mappings is something else entirely. Yes, the hosts will still generate such requests, but those requests don't have to traverse the entire network if the local router knows what to do with them. But a lot is being assumed by the above statement. I am fairly convinced that id-to-loc mapping needs to be more like mobile-ip where you send a packet to the id and get a redirect to the loc if the network can't route to the id, than like DNS where you make an explicit query across the network and get a response. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 11:31:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17348 for ; Wed, 17 Sep 2003 11:31:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zeH5-0002ZL-UH for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 11:31:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HFVNtL009876 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 11:31:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zeH5-0002ZD-8l for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 11:31:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17281 for ; Wed, 17 Sep 2003 11:31:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zeH4-0007dX-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 11:31:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zeH3-0007dP-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 11:31:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zeFq-0002Lt-Fm; Wed, 17 Sep 2003 11:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zeFi-0002KF-DR for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 11:29:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17124 for ; Wed, 17 Sep 2003 11:29:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zeFg-0007aT-00 for ipv6@ietf.org; Wed, 17 Sep 2003 11:29:56 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 19zeFf-0007aO-00 for ipv6@ietf.org; Wed, 17 Sep 2003 11:29:55 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6522D9628; Wed, 17 Sep 2003 11:29:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 17 Sep 2003 11:29:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: APIs, locator-identifiers, DNS security, [and Cartesius] (was Re: A strawman analysis...) Date: Wed, 17 Sep 2003 11:29:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA03A@tayexc13.americas.cpqcorp.net> Thread-Topic: APIs, locator-identifiers, DNS security, [and Cartesius] (was Re: A strawman analysis...) Thread-Index: AcN9FsPqrX8dbwp+TmCy+DUpukU5HwAFvZOg From: "Bound, Jim" To: "Pekka Nikander" , "Iljitsch van Beijnum" Cc: "IPV6 WG" X-OriginalArrivalTime: 17 Sep 2003 15:29:53.0477 (UTC) FILETIME=[8AA97750:01C37D30] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pekka, > Well, I do not exactly /want/ to change the APIs or tranport=20 > protocols. I only *anticipate* that due to mobility,=20 > multi-address multi-homing, and intermittend connectivity, we=20 > end up making changes to the transport protocols, anyway. I=20 > also anticipate that if we take the id/loc separation to its=20 > logical end, we will create a new set of APIs that will=20 > slowly replace the current socket APIs in new applications. I don't believe we need new base APIs, but just extensions to the new 3493 APIs for getaddrinfo, getaddrinfo, and more importantly asynchronous event notification. Getaddrinfo and getnameinfo can have flags to parse the future if we do figure out EID an Locator separation and I will look at that as engineer/architect/implementer once I personally believe a real proposal within the IETF and implementer community for consensus exists, which is not the case today. What we will need for much of the paradigm and architecture discussions I am hearing is a need to notify applications in an asynchronous manner of changes (e.g. state of network, new addresses, new security parameters) in the IP stack. What will be required that is new, is an application asynchronous listener mechanism added to applications (similar to how POSIX Pthreads can be integrated into an application module) for the asynchronous network kernel events for multiple paradigms and architecture changes under discussion, in the case where the IP stack selects variations for communications like new addresses or security parameters. I also am thinking this would be better done as an IEEE exercise for these APIs rather than IETF too. But, first order of business is get consensus on the perceived paradigm and architecture changes for any new features for IPv6 to be implemented. API debates at this point I think are premature, other than making sure new paradigms or architecture does not break existing implementations in the market, the latter being a better use of WG time is my 2 cents. As a note I am reviewing Dave Crocker's MAST proposal and analysis in technical depth, and will respond in the near future on MULTI6 list (could be three weeks given my work load), and this statement is not a support of MAST solution, but that I will do technical investigation as one member in our IETF community. Lastly, I believe we need to view the identifier and locator as unary operation. What I mean by that, is identification and location must be in an IPv6 address (I don't care about IPv4 anymore for this discussion). This does not preclude rendezvous points or processes to determine that address at all in solutions, as a note. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 15:57:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26656 for ; Wed, 17 Sep 2003 15:57:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziPz-0003MX-CK for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 15:56:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HJupta012925 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 15:56:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziPz-0003MO-3b for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 15:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26617 for ; Wed, 17 Sep 2003 15:56:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziPx-0002et-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 15:56:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ziPx-0002ep-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 15:56:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziPD-0003G7-MT; Wed, 17 Sep 2003 15:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziOy-0003Fm-6S for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 15:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26610 for ; Wed, 17 Sep 2003 15:55:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziOw-0002ek-00 for ipv6@ietf.org; Wed, 17 Sep 2003 15:55:46 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19ziOw-0002eg-00 for ipv6@ietf.org; Wed, 17 Sep 2003 15:55:46 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8HJtrxS044534; Wed, 17 Sep 2003 21:55:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 17 Sep 2003 21:55:38 +0200 Subject: Re: APIs, locator-identifiers, DNS security, [and Cartesius] (was Re: A strawman analysis...) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: IPV6 WG To: Pekka Nikander From: Iljitsch van Beijnum In-Reply-To: <3F6851F9.9000108@nomadiclab.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On woensdag, sep 17, 2003, at 14:22 Europe/Amsterdam, Pekka Nikander wrote: >> What exactly do you want to change about the APIs and transport >> protocols? > Well, I do not exactly /want/ to change the APIs or tranport protocols. > I only *anticipate* that due to mobility, multi-address multi-homing, > and intermittend connectivity, we end up making changes to the > transport protocols, anyway. I see. I'm 100% with Jim here. >> The question here is whether we're going to see those locators and/or >> identifiers outside of a locator of identifier context, and, if we >> do, whether it's important that we can regain such a context. > Sorry, but I still don't understand. What is "a locator of identifier > context"? Sorry, Dutch bleeding into English. I have the nasty tendency to type "of" when I mean "or". ("Of" is Dutch for "or".) What I mean: is it likely we'll be looking at 128 bit values and wonder whether those are identifiers or locators? I think there will (nearly) always be enough context to know which we're dealing with. >> Not really. An identifier is fixed, a locator is subject to change. >> That doesn't mean they can't be the same at one time or another, as >> long as the value can be changed in the places where it's a locator >> while it stays the same in the places where it acts as an identifier. > That really sounds like Mobile IP to me. Strange. > You explicitly seem to expect that some identifiers will (most of the > time) work as locators. If we design them that way, certainly. > That may work for the common multi-homing cases > today, but it fails to address the most common multi-homing > case tomorrow: mobile devices that have multiple radio > interfaces that they use at the same time. Then don't use identifiers that are also reachable locators. However, in this case you probably have the problem that you can't put the locators in a mapping system beforehand. >> The DNS is secure enough more than 99% of the time. > YMMV. Especially with DynDNS. Dynamic DNS is so secure that _I_ can't even dynamically change my zones. :-) > >>> (Just can't resist: Could we compare this to the difference between >>> Aristolean scholastics and Baconian science? :-) >> Feel free... Me, I'm more of the Cartesian persuasion when it comes >> to this. > Ah, that explains a lot. :-) I gave up the idea of the > Cartesian theatre already a few years ago. You really > must start reading Dennet and Dawkings. :-) Ok, I'll put them on my list. But generally I like the somewhat older stuff better as I'm always amazed by the bizarre stuff they come up with. :-) Compared to that things like Putnam's brains in a vat are almost a cop-out. The Descartes reference is towards the "doubt everything" doctrine in his meditations, by the way. Not a bad rule when doing network security... > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 16:03:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26938 for ; Wed, 17 Sep 2003 16:03:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziW3-0003mW-0x for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 16:03:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HK36Gc014530 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 16:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziW2-0003mH-SG for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 16:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26900 for ; Wed, 17 Sep 2003 16:02:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziW1-0002ki-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 16:03:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ziW0-0002kf-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 16:03:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziVy-0003iZ-Te; Wed, 17 Sep 2003 16:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ziVQ-0003i5-GS for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 16:02:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26866 for ; Wed, 17 Sep 2003 16:02:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziVO-0002kJ-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:02:26 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19ziVO-0002kG-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:02:26 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8HK2axS044625; Wed, 17 Sep 2003 22:02:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 17 Sep 2003 22:02:21 +0200 Subject: Re: domain names as end-point identifiers? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030917085834.0fb9e444.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On woensdag, sep 17, 2003, at 14:58 Europe/Amsterdam, Keith Moore wrote: > Having the routers cache id-to-loc mappings is one thing; having them > perform id-to-loc mappings is something else entirely. Yes, the hosts > will still generate such requests, but those requests don't have to > traverse the entire network if the local router knows what to do with > them. You're making a host of assumptions here. One of them is that even though the info is requested per-host, it exists as per-site. This doesn't follow: it could very well be that each host has its own mapping, mostly independent from that of other hosts in the same site. This would probably be necessary in a mobility setup. > But a lot is being assumed by the above statement. Ah. :-) > I am fairly convinced that id-to-loc mapping needs to be more like > mobile-ip where you send a packet to the id and get a redirect to the > loc if the network can't route to the id, But what if the network silently (or seemingly silently, re ICMP filtering) drops your packet? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 16:41:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28497 for ; Wed, 17 Sep 2003 16:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj6w-0005ZD-1e for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 16:41:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HKfEon021392 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 16:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj6v-0005Yx-TF for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 16:41:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28469 for ; Wed, 17 Sep 2003 16:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zj6t-0003Do-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 16:41:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zj6t-0003Dl-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 16:41:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj6k-0005Ux-As; Wed, 17 Sep 2003 16:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zj5p-0005Sv-Hz for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 16:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28369 for ; Wed, 17 Sep 2003 16:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zj5n-0003Br-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:40:03 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19zj5n-0003Bo-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:40:03 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B7C8614057; Wed, 17 Sep 2003 16:40:03 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06527-04; Wed, 17 Sep 2003 16:40:03 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id EB16C14029; Wed, 17 Sep 2003 16:40:02 -0400 (EDT) Date: Wed, 17 Sep 2003 16:40:02 -0400 From: Keith Moore To: Iljitsch van Beijnum Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: domain names as end-point identifiers? Message-Id: <20030917164002.7c7c5acf.moore@cs.utk.edu> In-Reply-To: References: <20030917085834.0fb9e444.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Having the routers cache id-to-loc mappings is one thing; having > > them perform id-to-loc mappings is something else entirely. Yes, > > the hosts will still generate such requests, but those requests > > don't have to traverse the entire network if the local router knows > > what to do with them. > > You're making a host of assumptions here. One of them is that even > though the info is requested per-host, it exists as per-site. no, I'm not making that assumption. the only assumption I'm making is that the mappings from id->loc are the same for every host, so that they can be cached if they are used by multiple hosts. > > I am fairly convinced that id-to-loc mapping needs to be more like > > mobile-ip where you send a packet to the id and get a redirect to > > the loc if the network can't route to the id, > > But what if the network silently (or seemingly silently, re ICMP > filtering) drops your packet? if the network does that, it's broken. we can design protocols to tolerate transient failures; but we cannot design protocols that work no matter what arbitrary filtering the network imposes. the network has a responsibility to make a best effort to deliver packets to their destination intact. this is nothing new. (note that I never said that the protocol would use ICMP for signalling such things.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 16:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29060 for ; Wed, 17 Sep 2003 16:53:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjIV-0006F3-KV for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 16:53:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HKrBYO023987 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 16:53:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjIV-0006Eo-GA for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 16:53:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29031 for ; Wed, 17 Sep 2003 16:53:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjIT-0003OW-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 16:53:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zjIT-0003OT-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 16:53:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjIM-00067N-JF; Wed, 17 Sep 2003 16:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjHe-00066h-9h for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 16:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28964 for ; Wed, 17 Sep 2003 16:52:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjHc-0003NT-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:52:16 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19zjHb-0003NQ-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:52:15 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8HKqIxS045208; Wed, 17 Sep 2003 22:52:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 17 Sep 2003 22:52:02 +0200 Subject: Re: domain names as end-point identifiers? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030917164002.7c7c5acf.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On woensdag, sep 17, 2003, at 22:40 Europe/Amsterdam, Keith Moore wrote: >> You're making a host of assumptions here. One of them is that even >> though the info is requested per-host, it exists as per-site. > no, I'm not making that assumption. the only assumption I'm making > is that the mappings from id->loc are the same for every host, so that > they can be cached if they are used by multiple hosts. Yes, that was what I was saying. >>> I am fairly convinced that id-to-loc mapping needs to be more like >>> mobile-ip where you send a packet to the id and get a redirect to >>> the loc if the network can't route to the id, >> But what if the network silently (or seemingly silently, re ICMP >> filtering) drops your packet? > if the network does that, it's broken. Surprise: the network IS broken. Operators have turned to large scale ICMP filtering to be able to keep limping along during the recent worm season. > we can design protocols to > tolerate transient failures; but we cannot design protocols that work > no > matter what arbitrary filtering the network imposes. I agree in principle but in practice a protocol that depends on the random kindness of remote routers won't fly. > the network has > a responsibility to make a best effort to deliver packets to their > destination intact. this is nothing new. Best effort may not be enough, not new either. > (note that I never said that the protocol would use ICMP for signalling > such things.) Neither did I, I only cited ICMP filtering as an example. But ICMP is the protocol of choice for control messages. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 17:01:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29714 for ; Wed, 17 Sep 2003 17:01:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjPk-0006mH-Ug for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 17:00:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HL0ewP026042 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 17:00:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjPj-0006lx-UC for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 17:00:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29578 for ; Wed, 17 Sep 2003 17:00:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjPh-0003ae-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 17:00:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zjPh-0003aQ-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 17:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjPJ-0006b9-Rq; Wed, 17 Sep 2003 17:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjOy-0006Y6-JG for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 16:59:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29384 for ; Wed, 17 Sep 2003 16:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjOw-0003Vs-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:59:50 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19zjOw-0003Vn-00 for ipv6@ietf.org; Wed, 17 Sep 2003 16:59:50 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A51F81413D; Wed, 17 Sep 2003 16:59:50 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08801-07; Wed, 17 Sep 2003 16:59:49 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 930DF14102; Wed, 17 Sep 2003 16:59:49 -0400 (EDT) Date: Wed, 17 Sep 2003 16:59:49 -0400 From: Keith Moore To: Iljitsch van Beijnum Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: domain names as end-point identifiers? Message-Id: <20030917165949.6d3302b2.moore@cs.utk.edu> In-Reply-To: References: <20030917164002.7c7c5acf.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > we can design protocols to tolerate transient failures; but we > > cannot design protocols that work no matter what arbitrary > > filtering the network imposes. > > I agree in principle but in practice a protocol that depends on the > random kindness of remote routers won't fly. Obviously IP will never work then. I don't know why we've bothered with it all these years, we must have been wasting our time. I have no problem with trying to choose a signaling protocol that won't look like an attractive target to ignorant sysadmins, or with trying to pick a signalling protocol that is easy to distinguish from traffic that sysadmins will be tempted to filter. But vague assertions of the form "sysadmins will filter X" are unsupportable. If we pay them too much heed we'll end up trying to design a protocol to meet an unrealistic set of conditions, and either we'll never finish or we'll put the robustness in the wrong place. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 17:08:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29906 for ; Wed, 17 Sep 2003 17:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjX0-0007a5-Rh for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 17:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HL8Ask029135 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 17:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjX0-0007Zq-MP for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 17:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29882 for ; Wed, 17 Sep 2003 17:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjWy-0003h8-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 17:08:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zjWx-0003h5-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 17:08:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjWs-0007U6-OB; Wed, 17 Sep 2003 17:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjWY-0007Pp-8Q for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 17:07:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29877 for ; Wed, 17 Sep 2003 17:07:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjWU-0003gv-00 for ipv6@ietf.org; Wed, 17 Sep 2003 17:07:38 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19zjWU-0003gr-00 for ipv6@ietf.org; Wed, 17 Sep 2003 17:07:38 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8HLCGP12204; Wed, 17 Sep 2003 14:12:16 -0700 Date: Wed, 17 Sep 2003 14:07:02 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <7053020359.20030917140702@brandenburg.com> To: Erik Nordmark CC: IPV6 WG Subject: Re: domain names as end-point identifiers? In-Reply-To: References: "Your message with ID" <17030979015.20030911230958@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik, EN> I don't think an identifier is necessary in every packet. EN> But I do think it makes sense to have a shim layer above IP which EN> uses locators in the packets below (for IP's routing) and presents EN> fixed length identifiers in the pseudo-headers passed to/from the upper layer EN> protocols. I believe you have described the common characteristic to the set of solutions I classed as "IP Endpoint" in the -analysis- paper I issued last night. It distinguishes a "shim" approach from an "ip-es" approach with a shim being more backward compatible for the upper layers, but that is a nicety, rather than a key point, I believe. EN> The reason having identifiers in every packet isn't useful is that if EN> you want to avoid facilitating redirection attacks of packet flows, EN> then the receiver needs to verify at some level the relationship between EN> locators and identifiers. yes! EN> Thus between the ULPs the shim provides a service which EN> passes what looks like packets containing 128 bit identifiers, even though on EN> the wire the packets have 128 bit locators. Yes. I've come to the view that that is really what MAST (and I believe LIN6 and HIP) are trying to do, though I originally described it in NAT terms. 128bits vs. 32 is a v4/v6 distinction, not an architectural distinction. The point is that transport sees something that is like what it is used to, but it no longer is really a locator. Instead it is an identifer that the new layer (shim, ip-es, or whatever) maps to the locator. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 18:31:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03745 for ; Wed, 17 Sep 2003 18:31:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkox-0001gC-Lh for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 18:30:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HMUlBb006452 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 18:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkox-0001fz-Hg for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 18:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03691 for ; Wed, 17 Sep 2003 18:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zkou-0004b9-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 18:30:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zkou-0004b6-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 18:30:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkoG-0001Tr-Mf; Wed, 17 Sep 2003 18:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zknq-0001Sl-RD for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 18:29:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03641 for ; Wed, 17 Sep 2003 18:29:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zknn-0004Zy-00 for ipv6@ietf.org; Wed, 17 Sep 2003 18:29:35 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19zknn-0004Zb-00 for ipv6@ietf.org; Wed, 17 Sep 2003 18:29:35 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8HMSxxS046280; Thu, 18 Sep 2003 00:28:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 18 Sep 2003 00:28:43 +0200 Subject: Re: domain names as end-point identifiers? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Keith Moore From: Iljitsch van Beijnum In-Reply-To: <20030917165949.6d3302b2.moore@cs.utk.edu> Message-Id: <4BA6F590-E95E-11D7-9188-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On woensdag, sep 17, 2003, at 22:59 Europe/Amsterdam, Keith Moore wrote: >> a protocol that depends on the random kindness of remote routers >> won't fly. > I have no problem with trying to choose a signaling protocol that won't > look like an attractive target to ignorant sysadmins, or with trying > to pick a signalling protocol that is easy to distinguish from traffic > that sysadmins will be tempted to filter. That's only a tiny part of the problem. Marcelo Bagnulo proposed a multi6 solution that was based on catching traffic that can't be forwarded. But we came to the conclusion that this won't fly because there is always the possibility that the last router in the path isn't aware of a failure situation. Now for nice-to-have functionality such as MTU optimization this shouldn't be a huge problem as you can fall back to some kind of conservative behavior when you don't get the desired feedback. For multihoming this is very different as the whole idea is to provide _better_ reachability. Having to depend on a router somehwere that isn't under the control of either endpoint to do something that routers often don't do today is asking for trouble. In a private network this _might_ possibly work. On the internet, it's useless. > But vague assertions of the > form "sysadmins will filter X" are unsupportable. If we pay them too > much heed we'll end up trying to design a protocol to meet an > unrealistic set of conditions, and either we'll never finish or we'll > put the robustness in the wrong place. Again, I agree in principle. But this can never be an excuse for lazy protocol design or implementation. Didn't we learn anything from the PMTUD disaster? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 18:36:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03896 for ; Wed, 17 Sep 2003 18:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zku6-00024M-No for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 18:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HMa6uv007948 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 18:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zku6-000247-Iz for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 18:36:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03874 for ; Wed, 17 Sep 2003 18:35:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zku3-0004fR-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 18:36:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zku3-0004fO-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 18:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zku2-0001zN-LV; Wed, 17 Sep 2003 18:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zkt2-0001yF-Or for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 18:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03860 for ; Wed, 17 Sep 2003 18:34:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zksz-0004eo-00 for ipv6@ietf.org; Wed, 17 Sep 2003 18:34:57 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19zksz-0004ee-00 for ipv6@ietf.org; Wed, 17 Sep 2003 18:34:57 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8HMdaP17674; Wed, 17 Sep 2003 15:39:36 -0700 Date: Wed, 17 Sep 2003 15:34:25 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <15758260584.20030917153425@brandenburg.com> To: Keith Moore CC: ipv6@ietf.org Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) In-Reply-To: <20030915083156.4581ae3f.moore@cs.utk.edu> References: <3F658C6B.1040700@nomadiclab.com> <20030915083156.4581ae3f.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, KM> DNS names are not sufficient for rendezvous or referral. Here are the arguments about the names, themselves, that you put forward: KM> * Incompatible with existing transport protocols. If you mean that they are too long to be carried in IP packet headers, you are of course correct. If you mean something else, please explain. However, your concern presupposes that the identifiers must be carried in those protocol -- or rather, that they must be carried in them frequently. KM> * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to a host. So? What problem does that cause? Specifically, please provide a usage example that would cause a problem. KM> Instead it refers to a service (as in imap.example.com or www.example.com) KM> which might map to numerous hosts. And it might not. So? Again, please provide a usage scenario that is problematic. KM> There can also be many domains KM> associated with a single host and yet be semantically different; How is this a problem? KM> What this means among other things is that existing domain names that we KM> use cannot be expected to be host identifiers. It depends upon how they are used. KM> Even when they are KM> sufficient to identify a host for initial connection purposes, resolving KM> the same DNS name again may not produce a locator for the same host as KM> before. You are assuming all sorts of semantics to the use of a DNS string that might or might not be true, for any specific proposal to use domain names. KM> * Not organized favorably. Existing DNS names are organized according to a KM> hierarchy of administrative entities, This is a strength, not a weakness. If the requirement is for a globally-registered and unique string, there is not other administrative model for which we have global experience. Feel free to cite a counter-example. KM> and write access to DNS RRs is also KM> organized in this fashion. Whether frequently written RRs is required is, again, dependent upon what proposal is made. KM> The components of domain names are usually KM> intended to be recognizable by humans, and humans therefore attach meaning KM> to those names. This is a feature that serves to improve the mnemonic potential of the strings. So? KM> This further implies that those administrative entities KM> often want to restrict use of their domains, so that their names aren't KM> associated with behavior that they cannot control. I cannot even guess what you mean by the above. KM> Of course, it would still be possible to create a new tree of domain names KM> that did not have these characteristics, but this would remove what many KM> see as the primary advantage of using DNS names - the ability to avoid KM> creating new infrastructure. depends upon the nature of the new registration policies. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 17 22:28:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10265 for ; Wed, 17 Sep 2003 22:28:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zoWF-0007hn-O7 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 22:27:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I2RhFn029619 for ipv6-archive@odin.ietf.org; Wed, 17 Sep 2003 22:27:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zoWF-0007he-Jb for ipv6-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 22:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10232 for ; Wed, 17 Sep 2003 22:27:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zoWC-00073C-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 22:27:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zoWC-000739-00 for ipv6-web-archive@ietf.org; Wed, 17 Sep 2003 22:27:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zoUb-0007b3-W6; Wed, 17 Sep 2003 22:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zoU0-0007aS-0X for ipv6@optimus.ietf.org; Wed, 17 Sep 2003 22:25:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10203 for ; Wed, 17 Sep 2003 22:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zoTw-00072K-00 for ipv6@ietf.org; Wed, 17 Sep 2003 22:25:20 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 19zoTw-00072H-00 for ipv6@ietf.org; Wed, 17 Sep 2003 22:25:20 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6591D140E5; Wed, 17 Sep 2003 22:25:21 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09258-07; Wed, 17 Sep 2003 22:25:20 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7F890140C4; Wed, 17 Sep 2003 22:25:19 -0400 (EDT) Date: Wed, 17 Sep 2003 22:21:54 -0400 From: Keith Moore To: Dave Crocker Cc: moore@cs.utk.edu, dhc2@dcrocker.net, ipv6@ietf.org Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Message-Id: <20030917222154.218e173d.moore@cs.utk.edu> In-Reply-To: <15758260584.20030917153425@brandenburg.com> References: <3F658C6B.1040700@nomadiclab.com> <20030915083156.4581ae3f.moore@cs.utk.edu> <15758260584.20030917153425@brandenburg.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 17 Sep 2003 15:34:25 -0700 Dave Crocker wrote: > Keith, > > KM> DNS names are not sufficient for rendezvous or referral. > > Here are the arguments about the names, themselves, that you put forward: > > KM> * Incompatible with existing transport protocols. > > If you mean that they are too long to be carried in IP packet headers, you > are of course correct. If you mean something else, please explain. > > However, your concern presupposes that the identifiers must be carried in > those protocol -- or rather, that they must be carried in them frequently. > > > KM> * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to > KM> a host. > > So? What problem does that cause? Specifically, please provide a usage > example that would cause a problem. Name EXAMPLE.COM maps to hosts B and C. Hosts B ausing addresses B1 and C1, respectively. Host A looks up EXAMPLE.COM, gets addresses B1 and C1, chooses B1, and starts talking to it. The application now has some state that is only accessible to host B. For some reason the connection gets broken. Maybe host B changes its address from B1 to B2. A needs to re-establish a connection to host B - host C will not work because the application now relies on state that only B can access. EXAMPLE.COM does not name host B uniquely; it names the service provided by hosts B and C, so it is not suitble for an endpoint identifier to refer to B. What is really needed is a unique name for each host that is stably bound to the host, and which is different from the DNS name used to identify the service. > KM> There can also be many domains > KM> associated with a single host and yet be semantically different; > > How is this a problem? Service names X, Y, and Z resolve to host A. Service names W, X, and Y resolve to host B. A process on host A is talking with one on host B. They need to provide a referral to a process on host C that lets C communicate with each of them. What names do they give to C? Note that applications really have no way of knowing either the semantic bindings of DNS names (what they're supposed to mean to humans). Just because a name resolves to an address of a particular host does not mean that it's valid to use that name in a referral. For that matter, there's often no way for an application to know what names will resolve to a particular host - but even if the app did know this it would not mean that the application was justified in using a particular name in a referral. Whether it's valid to use the name in a referral depends on what the name was intended to mean. > KM> What this means among other things is that existing domain names that we > KM> use cannot be expected to be host identifiers. > > It depends upon how they are used. A wide variety of uses for DNS names is now well established; it would be very difficult to restrict this variety of use in a significant way. > KM> Even when they are > KM> sufficient to identify a host for initial connection purposes, resolving > KM> the same DNS name again may not produce a locator for the same host as > KM> before. > > You are assuming all sorts of semantics to the use of a DNS string that > might or might not be true, for any specific proposal to use domain names. The above arguments are assuming that we'd be using the same DNS names for hosts/services that we're already using. Could you create a different set of DNS names (e.g. a different class or different TLDs, or *maybe* different RRs) and insist that they be bound explicitly to hosts so that you can use them in referrals? Maybe, but it's very hard to get people to use human-readable names the way you want them to. (I've got the scars from the URN wars to prove it) > KM> * Not organized favorably. Existing DNS names are organized according to > KM> a hierarchy of administrative entities, > > This is a strength, not a weakness. If the requirement is for a > globally-registered and unique string, there is not other administrative > model for which we have global experience. Feel free to cite a > counter-example. The problem is not so much that the names are assigned in a hierarchy, but the fact that the existing hierarchy isn't a good model for how real-world hosts are used. > KM> The components of domain names are usually > KM> intended to be recognizable by humans, and humans therefore attach > KM> meaning to those names. > > This is a feature that serves to improve the mnemonic potential of the > strings. So? So it means that there are inevitably conflicts over uses of those names when a host (or its owner) has multiple roles. If you want an identifier to be bound to a host (and you need it to be, given the other problems) forcing that host to live at some point in a human-meaningful hierarchy creates conflicts because it won't always be serving in the role that goes along with the human meaning. To take a familiar example, lots of people are now encouraged (sometimes forced) to use multiple email addresses because their employer doesn't want their personal mail to be associated with the employer's domain name. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 18 03:36:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00786 for ; Thu, 18 Sep 2003 03:36:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ztKj-0001Jc-MJ for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 03:36:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I7a9oC005046 for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 03:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ztKh-0001JH-4D for ipv6-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 03:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00734 for ; Thu, 18 Sep 2003 03:36:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ztKe-00026J-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 03:36:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ztKe-00026G-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 03:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ztIh-00011z-Kx; Thu, 18 Sep 2003 03:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ztIN-00011M-Rz for ipv6@optimus.ietf.org; Thu, 18 Sep 2003 03:33:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00616 for ; Thu, 18 Sep 2003 03:33:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ztIL-00024X-00 for ipv6@ietf.org; Thu, 18 Sep 2003 03:33:41 -0400 Received: from [205.242.250.76] (helo=avenir1.avenir.net) by ietf-mx with esmtp (Exim 4.12) id 19ztIH-00024H-00 for ipv6@ietf.org; Thu, 18 Sep 2003 03:33:37 -0400 Received: from cijuobaby (203.200.150.2 [203.200.150.2]) by avenir1.avenir.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPW986L2; Thu, 18 Sep 2003 03:28:28 -0400 Message-ID: <004801c37db7$4aa12db0$d600000a@cijuobaby> Reply-To: "C i j u O. B a b y" From: "C i j u O. B a b y" Cc: References: <3F658C6B.1040700@nomadiclab.com><20030915083156.4581ae3f.moore@cs.utk.edu><15758260584.20030917153425@brandenburg.com> <20030917222154.218e173d.moore@cs.utk.edu> Subject: Scope_Id Date: Thu, 18 Sep 2003 13:04:20 +0530 Organization: Avenir MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear All, I am involved in the development of an application with IPv6 protocol support. I encountered a problem which i will explain . Suppose i want to connect to a Server Socket through the interface index X, i have to use the Scope_Id (member of struct sockaddr_in6)as X-1 if the server is running on the same machine as the client runs. But if the server is running on a different machine, i can connect it with scope index X. Why does this anomaly happen? Here X is the index that i got from the rtnetlink calls. My machine is Redhat 7.2 with only one network interface card. Please help me with your replies . Also please respond if my query is not clear . Regards Ciju O. Baby -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 18 10:33:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15379 for ; Thu, 18 Sep 2003 10:33:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zzq8-0006mK-Kn for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 10:33:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IEX0AW026048 for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zzq8-0006m3-Fe for ipv6-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 10:33:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15329 for ; Thu, 18 Sep 2003 10:32:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zzq6-0006ob-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 10:32:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zzq5-0006oY-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 10:32:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zzpD-0006fK-9G; Thu, 18 Sep 2003 10:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zzot-0006ej-Ki for ipv6@optimus.ietf.org; Thu, 18 Sep 2003 10:31:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15270 for ; Thu, 18 Sep 2003 10:31:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zzor-0006mY-00 for ipv6@ietf.org; Thu, 18 Sep 2003 10:31:41 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19zzop-0006lp-00 for ipv6@ietf.org; Thu, 18 Sep 2003 10:31:39 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8IEV0q19939 for ; Thu, 18 Sep 2003 17:31:00 +0300 Date: Thu, 18 Sep 2003 17:30:59 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org Subject: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, As I sent some thoughts on RFC1918 to the IAB, we had a short personal discussion with Geoff, and he made a very good question: "Why did the market pick up NATs and run so hard with them despite their evident complications and technical compromises?" I made a few observations of my own, which I believe are not so technical (because I don't think picking NATs has been a very technical decision, most of the times.) This discussion -- while maybe off-topic, chairs please speak up if so -- may be relevant when considering whether there is something missing in the IPv6 protocol set. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Mon, 15 Sep 2003 15:34:34 +0300 (EEST) From: Pekka Savola To: Geoff Huston Subject: Re: Writeups on why RFC1918 is bad? (fwd) On Mon, 15 Sep 2003, Geoff Huston wrote: > At 11:19 AM 15/09/2003 +0300, Pekka Savola wrote: [...] > So the question that strikes right at the heart of this is: > "Why did the market pick up NATs and run so hard with them despite > their evident complications and technical compromises?" > > And if you can provide some insights into market behaviours in > answering the above question then you will gain some valuable > insights in answering the related questions listed above. (hmm.. perhaps we'd have had this discussion on a larger forum, like the ipv6 list or the IAB list.. feel free to forward or whatever if you feel the latter would be warranted.) I have thought up four reasons for this; I think all of them, especially the first two, are pretty obvious, and should not be technology-driven. 1) they provide for easy, extensible networking. When you install a NAT box in the network, the user doesn't have to configure static routes or anything like that; the NAT box is "transparent" (in a weird sense) to the network. The same argument applies to bridging compared to routing; if we wanted to get rid of NAT's e.g. in home or SOHO environments for IPv6, I'm pretty certain we'd have to go and specify a bridging architecture (remember J. Noel Chiappa's posts on why he thinks he made a mistake by advocating routing instead of bridging at the start of 80's). 2) NAT's have security properties which are understandable and settable even by those who don't have any security expertise. Just plug it in, and bam.. you prevent any incoming traffic except to those nodes which have been explicitly configured. The same would be doable with total-blockage access lists as well, but many folks really don't understand this. 3) IP address space conservation and ISP business models. ISPs feel that they cannot give enough IP addresses to the users (e.g. home), unless they want to spend considerable amount of energy fighting the respective RIR to get the address space (e.g., our hostmaster boggled when I proposed he'd apply for some /20 or /21 for a thousand or so DSL users). On the other hand, some ISPs do even have a business model of not giving the home users anything but one address, to get them to get premium service; I don't know the details of such arrangements. The bottom line is that getting IP addresses to those folks that need them (e.g. homes), _easily_, is just too difficult, impossible or costs too much. 4) the evident complications and technical compromises are not really so evident (as in, you don't typically notice or understand them outright, and when you do, it's already too late), and your favourite vendor is more than happy to code workarounds to these complications (e.g. ALG's) to gain you as a customer. Do you have any answers of your own to the question you posed? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 18 11:45:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18883 for ; Thu, 18 Sep 2003 11:45:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00xZ-000231-Ee for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 11:44:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IFij6J007865 for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 11:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00xZ-00022m-95 for ipv6-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 11:44:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18838 for ; Thu, 18 Sep 2003 11:44:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00xY-00007H-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 11:44:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A00xX-00007E-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 11:44:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00ws-0001vm-7Z; Thu, 18 Sep 2003 11:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00wE-0001v9-P7 for ipv6@optimus.ietf.org; Thu, 18 Sep 2003 11:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18799 for ; Thu, 18 Sep 2003 11:43:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00wD-00006J-00 for ipv6@ietf.org; Thu, 18 Sep 2003 11:43:21 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1A00wC-00006E-00 for ipv6@ietf.org; Thu, 18 Sep 2003 11:43:21 -0400 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 17:42:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37DFB.81E58A00" Subject: comment/question on deprecate-site-local-00.txt Date: Thu, 18 Sep 2003 17:42:46 +0200 Message-ID: Thread-Topic: comment/question on deprecate-site-local-00.txt Thread-Index: AcN9+4ESYBW7UtVTQfKnLjzlMD5biQ== From: "BAUDOT Alain FTRD/DMI/CAE" To: X-OriginalArrivalTime: 18 Sep 2003 15:42:49.0584 (UTC) FILETIME=[83ABBF00:01C37DFB] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C37DFB.81E58A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a comment and actually a question about section 5 on security = considerations. - this section does not make any difference between a blocking rule that = applies to a given prefix at a given boundary, and a common blocking = rule that applies to a well known prefix at every administrative = boundary. I think the two cases are different since the later one = enables a kind of global non-routable address space (if possible = non-ambiguous), while the former one does not. - I wonder if such a distinction is suitable or may provide some kind of = usefull higher level of non-rechability. Alain. ---------------------------------------------------------------- Alain Baudot France Telecom R&D FTR&D/DMI/SIR/IPI e-mail : alain.baudot@francetelecom.com 42, rue des Coutures Tel : +33 2 31 75 94 27 B.P. 6243 Fax : +33 2 31 75 56 26 14066 CAEN Cedex 4 ---------------------------------------------------------------- ------_=_NextPart_001_01C37DFB.81E58A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable comment/question on deprecate-site-local-00.txt

Hi,

I have a comment and actually a = question about section 5 on security considerations.
- this section does not make any = difference between a blocking rule that applies to a given prefix at a = given boundary, and a common blocking rule that applies to  a well = known prefix at every administrative boundary. I think the two cases are = different since the later one enables a kind of global non-routable = address space (if possible non-ambiguous), while the former one does = not.

- I wonder if such a distinction is = suitable or may provide some kind of usefull higher level of = non-rechability.

Alain.
----------------------------------------------------------= ------
Alain Baudot
France = Telecom R&D
FTR&D/DMI/SIR/IPI      &= nbsp; e-mail : alain.baudot@francetelecom.com
42, rue des = Coutures     Tel : +33  2 31 75 94 27
B.P. = 6243           &nb= sp;    Fax : +33  2 31 75 56 26
14066 CAEN Cedex 4
----------------------------------------------------------= ------


------_=_NextPart_001_01C37DFB.81E58A00-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 18 11:52:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19156 for ; Thu, 18 Sep 2003 11:52:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A014k-0002Uh-8O for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 11:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IFqA4q009581 for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 11:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A014k-0002UO-23 for ipv6-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 11:52:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19119 for ; Thu, 18 Sep 2003 11:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A014i-0000EG-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 11:52:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A014i-0000ED-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 11:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A014c-0002QN-He; Thu, 18 Sep 2003 11:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0143-0002Pk-9t for ipv6@optimus.ietf.org; Thu, 18 Sep 2003 11:51:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19069 for ; Thu, 18 Sep 2003 11:51:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0142-0000DG-00 for ipv6@ietf.org; Thu, 18 Sep 2003 11:51:26 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0141-0000Cr-00 for ipv6@ietf.org; Thu, 18 Sep 2003 11:51:25 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8IFopm20954; Thu, 18 Sep 2003 18:50:51 +0300 Date: Thu, 18 Sep 2003 18:50:51 +0300 (EEST) From: Pekka Savola To: BAUDOT Alain FTRD/DMI/CAE cc: ipv6@ietf.org Subject: Re: comment/question on deprecate-site-local-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 18 Sep 2003, BAUDOT Alain FTRD/DMI/CAE wrote: > I have a comment and actually a question about section 5 on security > considerations. - this section does not make any difference between a > blocking rule that applies to a given prefix at a given boundary, and a > common blocking rule that applies to a well known prefix at every > administrative boundary. I think the two cases are different since the > later one enables a kind of global non-routable address space (if > possible non-ambiguous), while the former one does not. This might need a clarification. There is *no* guarantee at all that there is any "common blocking rule" implemented in all the administrative boundaries. Just look at how far RFC1918 source addresses go in the backbone networks and such.. Therefore, I don't think there is a large *real* difference here. There may be some *perception* of a difference, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 18 12:47:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23066 for ; Thu, 18 Sep 2003 12:47:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01vX-0006Xt-AD for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 12:46:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IGkhJ5025155 for ipv6-archive@odin.ietf.org; Thu, 18 Sep 2003 12:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01vX-0006Xd-1K for ipv6-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 12:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23027 for ; Thu, 18 Sep 2003 12:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01vV-0002BM-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 12:46:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A01vV-0002BJ-00 for ipv6-web-archive@ietf.org; Thu, 18 Sep 2003 12:46:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01ut-0006My-Pm; Thu, 18 Sep 2003 12:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01uT-0006JV-Bg for ipv6@optimus.ietf.org; Thu, 18 Sep 2003 12:45:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22929 for ; Thu, 18 Sep 2003 12:45:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01uR-000249-00 for ipv6@ietf.org; Thu, 18 Sep 2003 12:45:35 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1A01uF-0001zP-00 for ipv6@ietf.org; Thu, 18 Sep 2003 12:45:34 -0400 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 18:44:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comment/question on deprecate-site-local-00.txt Date: Thu, 18 Sep 2003 18:43:41 +0200 Message-ID: Thread-Topic: comment/question on deprecate-site-local-00.txt Thread-Index: AcN9/KvIVS6cAQVXTvavWvXZW8+WqAAANynA From: "BAUDOT Alain FTRD/DMI/CAE" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 18 Sep 2003 16:44:34.0804 (UTC) FILETIME=[24277340:01C37E04] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > This might need a clarification. >=20 > There is *no* guarantee at all that there is any "common=20 > blocking rule"=20 > implemented in all the administrative boundaries. Just look=20 > at how far=20 > RFC1918 source addresses go in the backbone networks and such.. >=20 > Therefore, I don't think there is a large *real* difference=20 > here. There=20 > may be some *perception* of a difference, though. > Thanks for the clarification, Pekka. =20 However, I think it is difficult to convince that something would be bad because the equivalent is currently poorly done. =20 So, let ask the question in another way: assuming that the "common blocking rule" is guaranted, does it provide some "real" interresting feature ? If yes, then comes the question on how to make this rule guaranted and possibly in a simple and efficient way. If no, we are done. My point is just to have some strong arguments. =20 Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 19 21:37:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01248 for ; Fri, 19 Sep 2003 21:37:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCF020140 for ; Fri, 19 Sep 2003 21:36:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CG6cbv024262 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:06:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqRR-0006Im-F9 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:06:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29675 for ; Fri, 12 Sep 2003 12:06:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqP9-0005Tv-Gn; Fri, 12 Sep 2003 12:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xh8Z-00070s-4Z for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 02:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08027 for ; Fri, 12 Sep 2003 02:10:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xh8V-0002R4-00 for ipv6@ietf.org; Fri, 12 Sep 2003 02:10:27 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19xh8U-0002R1-00 for ipv6@ietf.org; Fri, 12 Sep 2003 02:10:27 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8C6ExP21941 for ; Thu, 11 Sep 2003 23:14:59 -0700 Date: Thu, 11 Sep 2003 23:09:58 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <17030979015.20030911230958@brandenburg.com> To: IPV6 WG Subject: Re: domain names as end-point identifiers? In-Reply-To: <3F5F150A.62ACA5C8@zurich.ibm.com> References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Thanks for the responses. I decided to send one, aggregate response, rather than a flood of smaller ones.: Dredging up some graduate school discussions, I suspect that this topic is differentiated between the classic "network" model of host to host communication, versus the "distributed processing" model of process to process communication. In the early 70's, for example, the Irvine Ring project (and, by the way, Netbios, later) use this process model. For wide-area networking, this has not gained much traction, at the lower packet-handling levels. (It was even interesting to watch MIT take over the Irvine work and eliminate the process addressing function.) My point is that I'm suspecting some folks are trying to lay a very different reference model onto the Internet than we have been using for the last 30 years. BEC> If you are looking for stable identifiers for "stacks" (in the BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely BEC> that an FQDN is a safe answer. It is probably worth noting that the NSRG report uses domain names to label the different stacks, in its own examples and in discussion. Whatever the reasons for that choice, I obviously find it interesting that they were used for that purpose. BEC> FQDNs are (mis)used in many ways; BEC> a name like www.example.com certainly doesn't identify a given IP stack BEC> on a given interface on a given host 1. When someone starts talking about identifying _interfaces_ I suspect they mean address, rather than 'end point identifier'. On the assumption that that is not what Brian meant, it's worth having this clarified. I'm confused by Bill's comment on this: " if there is an entity at a point in the topology, then the name maps nicely into the DNS". Domain names are not tied to network topology. They are tied to an administrative "topology", which is an entirely different thing. 2. If I understand the concern, here, it is that not _all_ domain names are endpoint identifiers. Erik also raised the point that domain names are used for different (and inconsistent?) purposes. One might be a host, another a service. When there are multiple records returned, they might refer to alternative systems or they might be alternate paths to the same service. My question is: so why does that mean that the ones that _are_ EIDs are not acceptable? What problems are caused by having multiple uses? BEC> I don't see that this has any functional advantage over an IPv6 address BEC> for that stack, and it introduces a DNS dependency for the transport layer. 1. I thought an IPv6 address was an address, not an end-point identifier. No? 2. The concern about introducing a DNS dependency into a lower layer, like transport, strikes me as pretty important, too. However, if we invent a new construct for an EID, we are a) introducing a new global administration requirement, and b) creating a dependency on it in that lower layer. So the concern with this new dependency is on the need for an EID, rather than the fact that it might be a domain name. No? MT> In the case of mobility and multihoming, you might want a stable MT> identifier on a per-packet basis which is independent of the routing MT> layer. A number of folks clearly have in mind using the identifier in every packet. My question is: Why is this needed? What requires putting the identifier in every packet, rather than using it a occasional, special points of an interaction, such as initial rendezvous? Erik's comments are particularly helpful for considering the requirements that folks are trying to satisfy: EN> It might be useful to split your question apart into two questions: EN> 1. Using current domain names and their mapping to AAAA records (or A records or even MX records or SRV records?) At any rate, this is the rendezvous function. EN> 2. Using variable length identifiers Or, to turn this one around, explaining when and why fixed-length IDs might be needed. EN> For #1 folks have pointed out that a currently domain names are often used EN> as service names and not host names, and one can't tell... my question is what problems are caused by multiple uses for domain names? how does it break the usage as endpoint ids? EN> I've also seen statements in the past that current domain name usage isn't EN> one that guarantees uniqness. I guess this underscores the need to be clear about the set of problems being tackled. Let's remember that IP datagrams are pretty basic. There are lots of very clever, useful things they do _not_ do. Are we, perhaps, trying to add other functionality to the IP service, beyond simply providing the current IP service, enhanced to support multihoming and mobility? For example, are we trying to add extra levels of security to the basic service, beyond simply making the use of multiple addresses carry the same, minimal security functions present for current, single-address IP? The "security" associated with a current, bare-bones mono-address host-to-host IP exchange is pretty darn small. I'd summarize it as simply being the assertion that a datagram probably did come from the IP address in the relevant field of the datagram. That's why MAST only tries to ensure an equivalent degree of assurance that latter datagrams with different IP addresses came from the same "system" that sent the first one. If you really need stronger security, use IPSEC, TLS, or whatever. Why do we need more, at the IP level for multihoming or mobility? EN> One example of this are cases when EN> www.example.com brings you to different http content from the inside of the EN> company than from the outside of the company. Clearly this is an important behavior. But should it be discerned at the IP level, or is this better suited to something above, say, transport? EN> I think all these can be addressed and still use FQDNs as identifiers. EN> (For instance by having some different RRtype which allows telling "service" EN> apart from "host".) Not surprisingly, I agree. EN> The issues around #2 has to do with how the protocols above IP operate. EN> If the identifier is only used to establish some state which is only used EN> when the locators change, then it is possible to have the upper layer protocols EN> operate on the locators when sending and receiving packets. Thus you'd have EN> multi-locator ULPs. ... EN> An alternate approach, which requires fixed length identifiers which can fit EN> into existing 128 bit fields, is to have a shim layer above IP which handles EN> id<->locator mappings and have the ULPs operate on the identifiers. Given the MAST proposal, obviously I favor the latter. However it's also clear that I do not believe the EID needs to be in every packet. I think it is a question of where some state information goes. One is to have the ID in every packet, making the IP address irrelevant. (The packet carries its own 'state' about the EID.) The alternative is to have a table of IP addresses that the EID maps to, and maintain the table in the participating hosts. Hence the IP address in the packet indexes to the EID when it is received.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 19 22:02:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01304 for ; Fri, 19 Sep 2003 21:37:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCN020140 for ; Fri, 19 Sep 2003 21:36:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CG6uQX024390 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqRV-0006JF-Rg for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:06:41 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29756 for ; Fri, 12 Sep 2003 12:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqP6-0005TX-NL; Fri, 12 Sep 2003 12:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xeAR-0001DP-7r for ipv6@optimus.ietf.org; Thu, 11 Sep 2003 23:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23354 for ; Thu, 11 Sep 2003 23:00:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xeAN-000155-00 for ipv6@ietf.org; Thu, 11 Sep 2003 23:00:11 -0400 Received: from [211.151.90.137] (helo=server2) by ietf-mx with esmtp (Exim 4.12) id 19xeAM-000152-00 for ipv6@ietf.org; Thu, 11 Sep 2003 23:00:11 -0400 Received: from xuke-ibm ([166.111.68.231]) by server2 (Lotus Domino Release 5.0.3 (Intl)) with ESMTP id 2003091311011833:145 ; Sat, 13 Sep 2003 11:01:18 +0800 From: "xuke" To: "ipv6@ietf.org" Subject: IPv4 over IPv6 tunnel X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Date: Fri, 12 Sep 2003 11:0:7 +0800 X-MIMETrack: Itemize by SMTP Server on server2/bwmail(Release 5.0.3 (Intl)|21 March 2000) at 2003-09-13 11:01:18, Serialize by Router on server2/bwmail(Release 5.0.3 (Intl)|21 March 2000) at 2003-09-13 11:01:23, Serialize complete at 2003-09-13 11:01:23 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi,all Does anybody know there is any RFC or draft about IPv4 over IPv6 tunnel? I can't find it in IETF website. Thanks a lot. xuke -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 19 22:03:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01633 for ; Fri, 19 Sep 2003 21:37:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhE5020140 for ; Fri, 19 Sep 2003 21:37:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CG6uEg024391 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqRV-0006JA-Pg for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:06:41 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29758 for ; Fri, 12 Sep 2003 12:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqPB-0005U7-1L; Fri, 12 Sep 2003 12:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xlug-0000Oc-6q for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 07:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16562 for ; Fri, 12 Sep 2003 07:16:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xluf-0004mx-00 for ipv6@ietf.org; Fri, 12 Sep 2003 07:16:29 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx with smtp (Exim 4.12) id 19xluf-0004mu-00 for ipv6@ietf.org; Fri, 12 Sep 2003 07:16:29 -0400 Received: (qmail 87807 invoked by uid 1000); 12 Sep 2003 11:16:28 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.021432 secs); 12 Sep 2003 11:16:28 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 12 Sep 2003 11:16:28 -0000 Received: (qmail 29540 invoked from network); 12 Sep 2003 11:16:27 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.160) by smtp-auth.nac.net with SMTP; 12 Sep 2003 11:16:27 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8C97NG02699; Fri, 12 Sep 2003 05:07:23 -0400 Date: Fri, 12 Sep 2003 05:07:23 -0400 (EDT) From: George Gross To: cc: Subject: set Global ID field to SHA hash of domain name Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, At the risk of triggering another firestorm of pro/con debate, is there any reason why the centrally assigned Global ID defined by hinden-ipv6-global-local-addr-02.txt could not be simply the low-order 40 bits of a SHA hash of a domain name? i.e. if you own the domain name, you get the IP-v6 global ID for "free"? This would side step the angst of setting up yet another global registry... if this has already been discussed on this list, just let me know when and the Subject line... br, George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 19 22:04:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01639 for ; Fri, 19 Sep 2003 21:37:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhEH020140 for ; Fri, 19 Sep 2003 21:37:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H209ru011781 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 22:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zRbt-00033k-CW for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 22:00:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23546 for ; Tue, 16 Sep 2003 21:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zRbq-0006L0-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 21:59:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zRbp-0006Kx-00 for ipv6-web-archive@ietf.org; Tue, 16 Sep 2003 21:59:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zRay-0002h4-AR; Tue, 16 Sep 2003 21:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zRZy-0002g8-R7 for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 21:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23410 for ; Tue, 16 Sep 2003 21:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zRZv-0006GK-00 for ipv6@ietf.org; Tue, 16 Sep 2003 21:57:59 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 19zRZv-0006Fv-00 for ipv6@ietf.org; Tue, 16 Sep 2003 21:57:59 -0400 Subject: RE: domain names as end-point identifiers? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Sep 2003 18:57:29 -0700 Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: domain names as end-point identifiers? Thread-Index: AcN8pXyBNk0xj9WzQ267iTLy7aJRWQAFT9XQ From: "Michel Py" To: "Erik Nordmark" Cc: "IPV6 WG" Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Erik, > Erik Nordmark wrote: > Lots of important details might differ between different possible > solution following that approach; for instance if you want to > allow routers to rewrite source locators (in order to dynamically > detect new locators to use for the peer) and also prevent > redirection attacks, then there are some important details to > work out. Indeed. I am not sure if "rewrite" is the appropriate generic wording (although it certainly is for MHAP) but we are indeed talking about some shim layer between network and transport where the identifier would be replaced by a locator and vice versa. I will point out though that these issues are not limited to a system where routers are rewriting packets and that it is likely going to be easier to tackle them by containing the translation into a smaller number of devices (routers) vs. doing the the id/loc mapping in each and every host. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 19 22:05:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01265 for ; Fri, 19 Sep 2003 21:37:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCH020140 for ; Fri, 19 Sep 2003 21:36:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CG6ucK024392 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 12:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqRU-0006J5-7h for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 12:06:40 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29725 for ; Fri, 12 Sep 2003 12:06:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqP8-0005Tj-1h; Fri, 12 Sep 2003 12:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xgsn-0005jk-SN for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 01:54:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27114 for ; Fri, 12 Sep 2003 01:54:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xgsk-0002IK-00 for ipv6@ietf.org; Fri, 12 Sep 2003 01:54:10 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19xgsj-0002Gt-00 for ipv6@ietf.org; Fri, 12 Sep 2003 01:54:09 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8C5wfP21368 for ; Thu, 11 Sep 2003 22:58:41 -0700 Date: Thu, 11 Sep 2003 22:53:39 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <17230000648.20030911225339@brandenburg.com> To: IPV6 WG Subject: Re: domain names as end-point identifiers? In-Reply-To: <3F5F150A.62ACA5C8@zurich.ibm.com> References: <2157349954.20030909235250@brandenburg.com> <3F5F150A.62ACA5C8@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Thanks for the responses. I decided to send one, aggregate response, rather than a flood of smaller ones.: Dredging up some graduate school discussions, I suspect that this topic is differentiated between the classic "network" model of host to host communication, versus the "distributed processing" model of process to process communication. In the early 70's, for example, the Irvine Ring project (and, by the way, Netbios, later) use this process model. For wide-area networking, this has not gained much traction, at the lower packet-handling levels. (It was even interesting to watch MIT take over the Irvine work and eliminate the process addressing function.) My point is that I'm suspecting some folks are trying to lay a very different reference model onto the Internet than we have been using for the last 30 years. BEC> If you are looking for stable identifiers for "stacks" (in the BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely BEC> that an FQDN is a safe answer. It is probably worth noting that the NSRG report uses domain names to label the different stacks, in its own examples and in discussion. Whatever the reasons for that choice, I obviously find it interesting that they were used for that purpose. BEC> FQDNs are (mis)used in many ways; BEC> a name like www.example.com certainly doesn't identify a given IP stack BEC> on a given interface on a given host 1. When someone starts talking about identifying _interfaces_ I suspect they mean address, rather than 'end point identifier'. On the assumption that that is not what Brian meant, it's worth having this clarified. I'm confused by Bill's comment on this: " if there is an entity at a point in the topology, then the name maps nicely into the DNS". Domain names are not tied to network topology. They are tied to an administrative "topology", which is an entirely different thing. 2. If I understand the concern, here, it is that not _all_ domain names are endpoint identifiers. Erik also raised the point that domain names are used for different (and inconsistent?) purposes. One might be a host, another a service. When there are multiple records returned, they might refer to alternative systems or they might be alternate paths to the same service. My question is: so why does that mean that the ones that _are_ EIDs are not acceptable? What problems are caused by having multiple uses? BEC> I don't see that this has any functional advantage over an IPv6 address BEC> for that stack, and it introduces a DNS dependency for the transport layer. 1. I thought an IPv6 address was an address, not an end-point identifier. No? 2. The concern about introducing a DNS dependency into a lower layer, like transport, strikes me as pretty important, too. However, if we invent a new construct for an EID, we are a) introducing a new global administration requirement, and b) creating a dependency on it in that lower layer. So the concern with this new dependency is on the need for an EID, rather than the fact that it might be a domain name. No? MT> In the case of mobility and multihoming, you might want a stable MT> identifier on a per-packet basis which is independent of the routing MT> layer. A number of folks clearly have in mind using the identifier in every packet. My question is: Why is this needed? What requires putting the identifier in every packet, rather than using it a occasional, special points of an interaction, such as initial rendezvous? Erik's comments are particularly helpful for considering the requirements that folks are trying to satisfy: EN> It might be useful to split your question apart into two questions: EN> 1. Using current domain names and their mapping to AAAA records (or A records or even MX records or SRV records?) At any rate, this is the rendezvous function. EN> 2. Using variable length identifiers Or, to turn this one around, explaining when and why fixed-length IDs might be needed. EN> For #1 folks have pointed out that a currently domain names are often used EN> as service names and not host names, and one can't tell... my question is what problems are caused by multiple uses for domain names? how does it break the usage as endpoint ids? EN> I've also seen statements in the past that current domain name usage isn't EN> one that guarantees uniqness. I guess this underscores the need to be clear about the set of problems being tackled. Let's remember that IP datagrams are pretty basic. There are lots of very clever, useful things they do _not_ do. Are we, perhaps, trying to add other functionality to the IP service, beyond simply providing the current IP service, enhanced to support multihoming and mobility? For example, are we trying to add extra levels of security to the basic service, beyond simply making the use of multiple addresses carry the same, minimal security functions present for current, single-address IP? The "security" associated with a current, bare-bones mono-address host-to-host IP exchange is pretty darn small. I'd summarize it as simply being the assertion that a datagram probably did come from the IP address in the relevant field of the datagram. That's why MAST only tries to ensure an equivalent degree of assurance that latter datagrams with different IP addresses came from the same "system" that sent the first one. If you really need stronger security, use IPSEC, TLS, or whatever. Why do we need more, at the IP level for multihoming or mobility? EN> One example of this are cases when EN> www.example.com brings you to different http content from the inside of the EN> company than from the outside of the company. Clearly this is an important behavior. But should it be discerned at the IP level, or is this better suited to something above, say, transport? EN> I think all these can be addressed and still use FQDNs as identifiers. EN> (For instance by having some different RRtype which allows telling "service" EN> apart from "host".) Not surprisingly, I agree. EN> The issues around #2 has to do with how the protocols above IP operate. EN> If the identifier is only used to establish some state which is only used EN> when the locators change, then it is possible to have the upper layer protocols EN> operate on the locators when sending and receiving packets. Thus you'd have EN> multi-locator ULPs. ... EN> An alternate approach, which requires fixed length identifiers which can fit EN> into existing 128 bit fields, is to have a shim layer above IP which handles EN> id<->locator mappings and have the ULPs operate on the identifiers. Given the MAST proposal, obviously I favor the latter. However it's also clear that I do not believe the EID needs to be in every packet. I think it is a question of where some state information goes. One is to have the ID in every packet, making the IP address irrelevant. (The packet carries its own 'state' about the EID.) The alternative is to have a table of IP addresses that the EID maps to, and maintain the table in the participating hosts. Hence the IP address in the packet indexes to the EID when it is received.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 19 22:37:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04659 for ; Fri, 19 Sep 2003 22:37:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhFx020140 for ; Fri, 19 Sep 2003 21:37:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GMOiwp018743 for ipv6-archive@odin.ietf.org; Tue, 16 Sep 2003 18:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOFX-0004s8-M7 for ipv6-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 18:24:43 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17690 for ; Tue, 16 Sep 2003 18:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOEs-0004ZP-KB; Tue, 16 Sep 2003 18:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOEJ-0004Ys-J0 for ipv6@optimus.ietf.org; Tue, 16 Sep 2003 18:23:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17622 for ; Tue, 16 Sep 2003 18:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zOEG-00046Y-00 for ipv6@ietf.org; Tue, 16 Sep 2003 18:23:24 -0400 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak1a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 19zOEF-00046V-00 for ipv6@ietf.org; Tue, 16 Sep 2003 18:23:24 -0400 Received: from 132.235.232.96 by pm3 (PureMessage); Tue Sep 16 17:09:05 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h8GL93BG649645 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 16 Sep 2003 17:09:04 -0400 (EDT) Date: Tue, 16 Sep 2003 17:08:47 -0400 From: Hans Kruse To: ipv6@ietf.org Subject: Re: Results of Poll Message-ID: <30654578.1063732127@hkruse2003a> In-Reply-To: <4.3.2.7.2.20030916105118.032a2928@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030916105118.032a2928@mailhost.iprg.nokia.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.3.73602 (pm3) X-PMX-Start: Tue Sep 16 17:09:04 2003 X-PMX-Stop: Tue Sep 16 17:09:05 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First, could you please be clear where your cutoff is? I am pretty sure this poll indeed does not show consensus, but the original deprecation call was based on percentages that were only quantitatively, but maybe not qualitatively clearer. I would also point out that the poll indicates that there is no consensus for moving the deprecation document by itself. Having said that, the stated course of action seems the right one. However, the numbers suggest to me that moving the documents together through WG last call -- with a well worked out "replacement" document -- will be much less likely to result in an e-mail bloodbath than the (to some tempting) approach of pushing deprecation and then conveniently forgetting the other document. --On Tuesday, September 16, 2003 10:55 -0700 Bob Hinden & Brian Haberman wrote: > There was not a consensus about tieing the deprecation of site-local to > defining an alternative or do the deprecation before defining an > alternative. The working group is closely split on this. Even combing > preferences B & C (i.e., 55%) does not form a consensus. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 19 22:37:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04562 for ; Fri, 19 Sep 2003 22:37:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhFr020140 for ; Fri, 19 Sep 2003 21:37:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CI9Aop031968 for ipv6-archive@odin.ietf.org; Fri, 12 Sep 2003 14:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsM1-0008JW-Ss for ipv6-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 14:09:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07684 for ; Fri, 12 Sep 2003 14:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xsLz-0003GF-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:09:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xsLz-0003GC-00 for ipv6-web-archive@ietf.org; Fri, 12 Sep 2003 14:09:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsLv-0008BP-DI; Fri, 12 Sep 2003 14:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xsLZ-0008Ak-5e for ipv6@optimus.ietf.org; Fri, 12 Sep 2003 14:08:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07664 for ; Fri, 12 Sep 2003 14:08:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xsLW-0003FT-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:08:38 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19xsLV-0003Dz-00 for ipv6@ietf.org; Fri, 12 Sep 2003 14:08:38 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h8CI81Pt285824; Fri, 12 Sep 2003 14:08:01 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8CI80Q5290384; Fri, 12 Sep 2003 12:08:00 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h8CI7nGB011582; Fri, 12 Sep 2003 14:07:49 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id h8CI7niD011578; Fri, 12 Sep 2003 14:07:49 -0400 Message-Id: <200309121807.h8CI7niD011578@rotala.raleigh.ibm.com> To: ipv6@ietf.org cc: Bob Hinden , Brian Haberman , Margaret Wasserman Subject: New IPv6 co-chair Date: Fri, 12 Sep 2003 14:07:49 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I'm pleased to report that Brian Haberman has agreed to become the new co-chair of the IPv6 WG working group, working together with Bob Hinden, the other co-chair. With a new co-chair in place, Margaret Wasserman has now officially stepped down as co-chair of the IPv6 WG and will become the new Area Advisor for the IPv6 WG in her role as Area Director for the Internet Area. I believe I speak for many in thanking Margaret for the job she's done as co-chair of the IPv6 WG and am looking forward to working with Bob and Brian. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 09:52:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03980 for ; Sat, 20 Sep 2003 09:52:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Plo-00005e-2w for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 14:14:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JIEGpS000340 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 14:14:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Pln-00005P-U7 for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 14:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18258 for ; Fri, 19 Sep 2003 14:14:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Pll-0007aC-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 14:14:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PWX-00074V-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0No7-0002KS-9D; Fri, 19 Sep 2003 12:08:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nn5-0001pe-QX for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:07:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07640 for ; Fri, 19 Sep 2003 12:07:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A07gU-0004ub-00 for ipv6@ietf.org; Thu, 18 Sep 2003 18:55:34 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A07TU-00038a-00 for ipv6@ietf.org; Thu, 18 Sep 2003 18:42:08 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8IMgIed062563; Fri, 19 Sep 2003 00:42:19 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 19 Sep 2003 00:42:05 +0200 Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: <54087754-EA29-11D7-AF86-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On donderdag, sep 18, 2003, at 16:30 Europe/Amsterdam, Pekka Savola wrote: > "Why did the market pick up NATs and run so hard with them despite > their evident complications and technical compromises?" The short answer is of course: because NAT was easier than either (a) getting new addresses, or (b) renumbering. Also, NAT adoption was a fairly gradual process. As far as I can remember, the first time I heard about it was as a Cisco feature but this was "straight" NAT where address range A was replaced with address range B without touching the port numbers. This was an enterprise feature for avoiding renumbering. Not much later "IP masquerading" showed up as a feature in the Linux firewalling mechanism and after that NAT started showing up in SOHO routers under names such as "single user account". Then at some point NAT became a more or less respectable technology rather than a dirty hack, just when applications that really don't mesh well with NAT, with the result that incompatibility with NAT became a problem for the application writers rather than for the user who was silly enough to try this flakey address translation thing. > 3) IP address space conservation and ISP business models. ISPs feel > that > they cannot give enough IP addresses to the users (e.g. home), unless > they > want to spend considerable amount of energy fighting the respective > RIR to > get the address space (e.g., our hostmaster boggled when I proposed > he'd > apply for some /20 or /21 for a thousand or so DSL users). Note that there is no good way for an ISP to give a customer just a few individual IP addresses. It's either a single address or a subnet, which means a minimum of 8 address of which 3 are wasted. And the RIRs require ISPs to register /29s or larger assignments individually in the database. > On the other > hand, some ISPs do even have a business model of not giving the home > users > anything but one address, to get them to get premium service; I don't > know > the details of such arrangements. The bottom line is that getting IP > addresses to those folks that need them (e.g. homes), _easily_, is just > too difficult, impossible or costs too much. Yes, for many reasons, but the addresses being unavailable per se isn't one of them. > 4) the evident complications and technical compromises are not really > so > evident (as in, you don't typically notice or understand them outright, > and when you do, it's already too late), and your favourite vendor is > more > than happy to code workarounds to these complications (e.g. ALG's) to > gain > you as a customer. Right. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 09:52:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04089 for ; Sat, 20 Sep 2003 09:52:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PX4-0007IX-IW for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 13:59:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHx2GN028043 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 13:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PX3-0007I2-IF for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 13:59:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17486 for ; Fri, 19 Sep 2003 13:58:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0PWz-0007Cn-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PWX-000797-02 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Olk-0002Gt-1Q; Fri, 19 Sep 2003 13:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nkz-00014u-Va for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:05:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06047 for ; Fri, 19 Sep 2003 12:05:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Ep4-0004wS-00 for ipv6@ietf.org; Fri, 19 Sep 2003 02:32:54 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Ed4-0002Xl-00 for ipv6@ietf.org; Fri, 19 Sep 2003 02:20:30 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8J6JxX28429; Fri, 19 Sep 2003 09:19:59 +0300 Date: Fri, 19 Sep 2003 09:19:59 +0300 (EEST) From: Pekka Savola To: BAUDOT Alain FTRD/DMI/CAE cc: ipv6@ietf.org Subject: RE: comment/question on deprecate-site-local-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 18 Sep 2003, BAUDOT Alain FTRD/DMI/CAE wrote: [...] > So, let ask the question in another way: assuming that the "common > blocking rule" is guaranted, does it provide some "real" interresting > feature ? If yes, then comes the question on how to make this rule > guaranted and possibly in a simple and efficient way. If no, we are > done. I think this is kind of a moot point, because we can *never* guarantee that, any more than we can guarantee that source addresses are not being used (except at *our* administrative border, to an extent). A different question would be whether a slightly lower "guarantee" (e.g. "implemented and enabled on most but not all platforms" or "almost always enabled, unless disabled manually") -- or "warm fuzzy feeling" -- would be useful. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 09:52:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04010 for ; Sat, 20 Sep 2003 09:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PZa-0007Wo-5j for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 14:01:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JI1c2L028932 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 14:01:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PZa-0007WZ-1y for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 14:01:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17635 for ; Fri, 19 Sep 2003 14:01:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0PZX-0007Gs-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 14:01:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PZS-0007Gp-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 14:01:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NoM-0002QU-Ls; Fri, 19 Sep 2003 12:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NnE-0001sj-0N for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:07:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07827 for ; Fri, 19 Sep 2003 12:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A06xx-0007Sz-00 for ipv6@ietf.org; Thu, 18 Sep 2003 18:09:33 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1A06jd-0005zm-00 for ipv6@ietf.org; Thu, 18 Sep 2003 17:54:45 -0400 Received: from gih505.telstra.net (dhcp4.potaroo.net [203.10.60.4]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h8ILsARf038299 for ; Fri, 19 Sep 2003 07:54:14 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030919073510.01b2b9d0@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Sep 2003 07:41:07 +1000 To: ipv6@ietf.org From: Geoff Huston Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , With the indulcence of the working group perhaps a preface to the question I posed to Pekka might help here, to understand where I was coming from:... Why are NATs so prevalent.? I have this personal hunch that technologists are not natural economists, and the dynamics of the market leaves the technologist mystified. Why is it that NATs are so popular when you and I know that they are a rather uncomfortable compromise. Why was QoS simply not a goer? Why has multicast gone nowhere? And what's happening with IPv6? I have this feeling that the technology approach is "well if you liked IP then you _will_ like everything else we have to offer!" Markets are somewhat different. Markets were willing to ditch CPM-M in favour of DOS (old analogy, but if you'd ever tried to make both of them do anything useful you'd see what I mean about the market making a poor decision!), wiling to ditch the MAC in favour of the IBM PC architecture, and, in general markets are just as willing to ignore good technology as they are likely to pick it up and run with it. That lead onto the question I posed Pakka about NATs. Geoff At 05:30 PM 18/09/2003 +0300, Pekka Savola wrote: >Hi, > >As I sent some thoughts on RFC1918 to the IAB, we had a short personal >discussion with Geoff, and he made a very good question: > >"Why did the market pick up NATs and run so hard with them despite > their evident complications and technical compromises?" > >I made a few observations of my own, which I believe are not so technical >(because I don't think picking NATs has been a very technical decision, >most of the times.) > >This discussion -- while maybe off-topic, chairs please speak up if so -- >may be relevant when considering whether there is something missing in the >IPv6 protocol set. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >---------- Forwarded message ---------- >Date: Mon, 15 Sep 2003 15:34:34 +0300 (EEST) >From: Pekka Savola >To: Geoff Huston >Subject: Re: Writeups on why RFC1918 is bad? (fwd) > >On Mon, 15 Sep 2003, Geoff Huston wrote: > > At 11:19 AM 15/09/2003 +0300, Pekka Savola wrote: >[...] > > So the question that strikes right at the heart of this is: > > "Why did the market pick up NATs and run so hard with them despite > > their evident complications and technical compromises?" > > > > And if you can provide some insights into market behaviours in > > answering the above question then you will gain some valuable > > insights in answering the related questions listed above. > >(hmm.. perhaps we'd have had this discussion on a larger forum, like the >ipv6 list or the IAB list.. feel free to forward or whatever if you feel >the latter would be warranted.) > >I have thought up four reasons for this; I think all of them, especially >the first two, are pretty obvious, and should not be technology-driven. > > 1) they provide for easy, extensible networking. When you install a NAT >box in the network, the user doesn't have to configure static routes or >anything like that; the NAT box is "transparent" (in a weird sense) to the >network. The same argument applies to bridging compared to routing; if we >wanted to get rid of NAT's e.g. in home or SOHO environments for IPv6, I'm >pretty certain we'd have to go and specify a bridging architecture >(remember J. Noel Chiappa's posts on why he thinks he made a mistake by >advocating routing instead of bridging at the start of 80's). > > 2) NAT's have security properties which are understandable and settable >even by those who don't have any security expertise. Just plug it in, and >bam.. you prevent any incoming traffic except to those nodes which have >been explicitly configured. The same would be doable with total-blockage >access lists as well, but many folks really don't understand this. > > 3) IP address space conservation and ISP business models. ISPs feel that >they cannot give enough IP addresses to the users (e.g. home), unless they >want to spend considerable amount of energy fighting the respective RIR to >get the address space (e.g., our hostmaster boggled when I proposed he'd >apply for some /20 or /21 for a thousand or so DSL users). On the other >hand, some ISPs do even have a business model of not giving the home users >anything but one address, to get them to get premium service; I don't know >the details of such arrangements. The bottom line is that getting IP >addresses to those folks that need them (e.g. homes), _easily_, is just >too difficult, impossible or costs too much. > > 4) the evident complications and technical compromises are not really so >evident (as in, you don't typically notice or understand them outright, >and when you do, it's already too late), and your favourite vendor is more >than happy to code workarounds to these complications (e.g. ALG's) to gain >you as a customer. > >Do you have any answers of your own to the question you posed? > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 09:52:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03994 for ; Sat, 20 Sep 2003 09:52:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Pli-00005G-9H for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 14:14:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JIEAPC000316 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 14:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Plc-000050-VS for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 14:14:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18252 for ; Fri, 19 Sep 2003 14:13:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Pla-0007Zp-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 14:14:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PWW-000747-01 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OsR-0003FF-4a; Fri, 19 Sep 2003 13:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nki-00010V-WD for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05639 for ; Fri, 19 Sep 2003 12:04:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0GAd-0002wc-00 for ipv6@ietf.org; Fri, 19 Sep 2003 03:59:15 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1A0G2U-0001YX-00 for ipv6@ietf.org; Fri, 19 Sep 2003 03:50:50 -0400 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id EFD8B1C; Fri, 19 Sep 2003 11:03:41 +0300 (EEST) Message-ID: <3F6AB53D.8010005@nomadiclab.com> Date: Fri, 19 Sep 2003 10:50:21 +0300 From: Pekka Nikander Reply-To: hipsec@honor.trusecure.com User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 WG , Multi6 WG Cc: hipsec@honor.trusecure.com Subject: Renewed HIP mailing list & BOF and WG proposals Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Aplogies for cross-posting] Folks, The Host Identity Protocol (HIP) mailing list was restored in July at @honor.trusecure.com. The mailing list existed previously @lists.freeswan.org, but there were some technical problems which necessitated the move of the mailing list. We have now started a discussion on a possible HIP BOF and WG. If you want to participate to the discussion, join the mailing list. However, before doing so, please read the archives, at least the most recent ones. The archive is available at http://honor.trusecure.com/pipermail/hipsec/ The most important messages at this point, related to the WG proposal, are the following: http://honor.trusecure.com/pipermail/hipsec/2003-July/000004.html http://honor.trusecure.com/pipermail/hipsec/2003-September/000070.html http://honor.trusecure.com/pipermail/hipsec/2003-September/000071.html Subscription information is available at: http://honor.trusecure.com/mailman/listinfo/hipsec --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 09:53:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04360 for ; Sat, 20 Sep 2003 09:53:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Om0-0002QH-5c for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 13:10:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHAOdi009307 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 13:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Oly-0002Px-I3 for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 13:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15093 for ; Fri, 19 Sep 2003 13:10:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Olv-0006S5-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 13:10:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0Olp-0006Qg-03 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 13:10:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NpB-0002qa-37; Fri, 19 Sep 2003 12:09:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NnU-00021h-Aa for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:07:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07985 for ; Fri, 19 Sep 2003 12:07:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A06HP-0002uU-00 for ipv6@ietf.org; Thu, 18 Sep 2003 17:25:36 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1A05yJ-0000sO-00 for ipv6@ietf.org; Thu, 18 Sep 2003 17:05:51 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8ILAVP23243; Thu, 18 Sep 2003 14:10:31 -0700 Date: Thu, 18 Sep 2003 14:05:15 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <10139310537.20030918140515@brandenburg.com> To: Keith Moore CC: ipv6@ietf.org Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) In-Reply-To: <20030917222154.218e173d.moore@cs.utk.edu> References: <3F658C6B.1040700@nomadiclab.com> <20030915083156.4581ae3f.moore@cs.utk.edu> <15758260584.20030917153425@brandenburg.com> <20030917222154.218e173d.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, >> KM> * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to >> KM> a host. >> So? What problem does that cause? Specifically, please provide a usage >> example that would cause a problem. KM> Name EXAMPLE.COM maps to hosts B and C. Hosts B ausing addresses B1 and C1, KM> respectively. Host A looks up EXAMPLE.COM, gets addresses B1 and C1, chooses KM> B1, and starts talking to it. The application now has some state that is only KM> accessible to host B. KM> For some reason the connection gets broken. Maybe host B changes its KM> address from B1 to B2. A needs to re-establish a connection to host B - KM> host C will not work because the application now relies on state that only KM> B can access. EXAMPLE.COM does not name host B uniquely; I am guessing that you have not read the MAST proposal and have not been noting the details that a number of us are seeking about actual requirements for an endpoint identifier.. I'm suspecting you also are not familiar with the other proposals. So, yes, you have invented a scenario that uses domain names in a way that will not work. Unfortunately, no one is proposing such a broken scenario. So let me rephrase the question more simply and more rigidly: What is it that _requires_ specifying using domain names in a way that causes problems? If that question is not clear enough, then try: What is _inherent_ in domain names that prevents their use as endpoint identifiers? Inherent, not merely "possible". It is always possible to create a broken design. Citing such an example is not overly helpful. However I really should thank you. Much of these discussions have been marked by attempts to make design choices based on very abstract issues, rather than on looking on plausible and probable actual usage. This makes much of the discussion fundamentally not grounded, both literally and figuratively. We now have quite a few concrete proposals and specifications. We should make a point of using these data points as concrete examples of the solution space. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 09:54:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04894 for ; Sat, 20 Sep 2003 09:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O87-0007CN-Lf for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 12:29:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGTBcF027665 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 12:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O86-0007Bm-2E for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 12:29:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11155 for ; Fri, 19 Sep 2003 12:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0O84-0005bG-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 12:29:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0O7y-0005b6-01 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 12:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NqF-0003EZ-In; Fri, 19 Sep 2003 12:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0No0-0002HV-KX for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08149 for ; Fri, 19 Sep 2003 12:07:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A05iJ-00070e-00 for ipv6@ietf.org; Thu, 18 Sep 2003 16:49:19 -0400 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1A05Wk-0005uG-00 for ipv6@ietf.org; Thu, 18 Sep 2003 16:37:22 -0400 Received: from daal (dhcp245.nttmcl.com [216.69.69.245]) by alicia.nttmcl.com (8.12.9/8.12.5) with SMTP id h8IKaZHB096132; Thu, 18 Sep 2003 13:36:35 -0700 (PDT) (envelope-from gene@nttmcl.com) Message-ID: <00ac01c37e24$8ccbe140$f54545d8@daal> From: "Eugene M. Kim" To: "Keith Moore" Cc: "Dave Crocker" , , , References: <3F658C6B.1040700@nomadiclab.com><20030915083156.4581ae3f.moore@cs.utk.edu><15758260584.20030917153425@brandenburg.com> <20030917222154.218e173d.moore@cs.utk.edu> Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) Date: Thu, 18 Sep 2003 13:36:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Comments inline below: ----- Original Message ----- From: "Keith Moore" To: "Dave Crocker" Cc: ; ; Sent: Wednesday, September 17, 2003 7:21 PM Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) > On Wed, 17 Sep 2003 15:34:25 -0700 > Dave Crocker wrote: > > > Keith, > > > > KM> DNS names are not sufficient for rendezvous or referral. > > > > Here are the arguments about the names, themselves, that you put forward: > > > > KM> * Incompatible with existing transport protocols. > > > > If you mean that they are too long to be carried in IP packet headers, you > > are of course correct. If you mean something else, please explain. > > > > However, your concern presupposes that the identifiers must be carried in > > those protocol -- or rather, that they must be carried in them frequently. > > > > > > KM> * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to > > KM> a host. > > > > So? What problem does that cause? Specifically, please provide a usage > > example that would cause a problem. > > Name EXAMPLE.COM maps to hosts B and C. Hosts B ausing addresses B1 and C1, > respectively. Host A looks up EXAMPLE.COM, gets addresses B1 and C1, chooses > B1, and starts talking to it. The application now has some state that is only > accessible to host B. > > For some reason the connection gets broken. Maybe host B changes its > address from B1 to B2. A needs to re-establish a connection to host B - > host C will not work because the application now relies on state that only > B can access. EXAMPLE.COM does not name host B uniquely; it names the > service provided by hosts B and C, so it is not suitble for an endpoint > identifier to refer to B. What is really needed is a unique name for each > host that is stably bound to the host, and which is different from the > DNS name used to identify the service. How about B saying in the earliest possible stage of conversation with A: `Okay, I don't know what name you looked up in DNS to reach me, but in the future please use this domain name (that uniquely identifies me) to reach me again later'? This could, but need not, happen in the application layer; some other layer that handles the id-loc mapping could do this. My assumption is that each host has knowledge about what domain name is its unique identifier. Host/site administrators can configure one into each host using various ways such as (heaven forbid) manual configuration, or DHCP e.g. by looking up the client's link-layer address in a link-layer-address-to-identifier table and, if not found in the table, defaulting to the link-layer address combined with the network identifier to form one like `EUI64-003048FFFE234C67.MARKETINGNET1.EXAMPLE.COM'. Then it really comes down to the application figuring out what the identifier for the host it is running on. gethostname(3) comes to mind first; if the common practice dictates that it's already being used for something else (e.g. a service identifier), we could invent and propose something else like confstr(_CS_HOSTID) in 4.4BSD. > > > KM> There can also be many domains > > KM> associated with a single host and yet be semantically different; > > > > How is this a problem? > > Service names X, Y, and Z resolve to host A. Service names W, X, and Y > resolve to host B. A process on host A is talking with one on host B. They > need to provide a referral to a process on host C that lets C communicate with > each of them. What names do they give to C? Note that applications really > have no way of knowing either the semantic bindings of DNS names (what they're > supposed to mean to humans). Just because a name resolves to an address > of a particular host does not mean that it's valid to use that name in a > referral. For that matter, there's often no way for an application to know > what names will resolve to a particular host - but even if the app did know > this it would not mean that the application was justified in using a > particular name in a referral. Whether it's valid to use the name in a > referral depends on what the name was intended to mean. Please see the above. > > > KM> What this means among other things is that existing domain names that we > > KM> use cannot be expected to be host identifiers. > > > > It depends upon how they are used. > > A wide variety of uses for DNS names is now well established; it would be > very difficult to restrict this variety of use in a significant way. > > KM> Even when they are > > KM> sufficient to identify a host for initial connection purposes, resolving > > KM> the same DNS name again may not produce a locator for the same host as > > KM> before. > > > > You are assuming all sorts of semantics to the use of a DNS string that > > might or might not be true, for any specific proposal to use domain names. > > The above arguments are assuming that we'd be using the same DNS names for > hosts/services that we're already using. Could you create a different set > of DNS names (e.g. a different class or different TLDs, or *maybe* different > RRs) and insist that they be bound explicitly to hosts so that you can > use them in referrals? Maybe, but it's very hard to get people to use > human-readable names the way you want them to. (I've got the scars from the > URN wars to prove it) How about making the name used as an identifier (at least to those ones that configure it to DNS zones) suggest `No, this isn't a typical domain name you could do anything you wish; don't overload this for anything else'? One example could be a SRV RR with _HOSTID._IP as the _Service._Proto part. IMO, actually a SRV-like syntax is ugly to human eyes (because it starts with an underscore =p) so DNS administrators are less tempted to overload that name for other purposes. > > > KM> * Not organized favorably. Existing DNS names are organized according to > > KM> a hierarchy of administrative entities, > > > > This is a strength, not a weakness. If the requirement is for a > > globally-registered and unique string, there is not other administrative > > model for which we have global experience. Feel free to cite a > > counter-example. > > The problem is not so much that the names are assigned in a hierarchy, but the > fact that the existing hierarchy isn't a good model for how real-world hosts > are used. Could you (give a pointer to some documents that) elaborate on the subject? Regards, Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 09:53:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04533 for ; Sat, 20 Sep 2003 09:53:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OOE-0008VM-TY for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 12:45:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGjoYe032692 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 12:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OOE-0008VD-Op for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 12:45:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13663 for ; Fri, 19 Sep 2003 12:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0OOD-0005xd-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 12:45:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0O7l-0005WC-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 12:28:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nqd-0003S4-SP; Fri, 19 Sep 2003 12:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NoE-0002O9-PG for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:08:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08562 for ; Fri, 19 Sep 2003 12:08:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A04G8-0006Sc-00 for ipv6@ietf.org; Thu, 18 Sep 2003 15:16:08 -0400 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1A03wM-0004cF-00 for ipv6@ietf.org; Thu, 18 Sep 2003 14:55:42 -0400 Received: from daal (dhcp245.nttmcl.com [216.69.69.245]) by alicia.nttmcl.com (8.12.9/8.12.5) with SMTP id h8IIsuHB093507; Thu, 18 Sep 2003 11:55:03 -0700 (PDT) (envelope-from gene@nttmcl.com) Message-ID: <006e01c37e16$5ae82750$f54545d8@daal> From: "Eugene M. Kim" To: "Iljitsch van Beijnum" Cc: "Keith Moore" , References: <4BA6F590-E95E-11D7-9188-00039388672E@muada.com> Subject: Re: domain names as end-point identifiers? Date: Thu, 18 Sep 2003 11:53:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IMHO it is more of a matter of who does what first. If there is some existing and well-established practice among network administrators that would not work with the new protocol, the protocol has to be modified to avoid that. However, if the protocol is first established then deployed then later sysadmins do something that interferes with the protocol, it is not the protocol designers' fault but the sysadmins' fault that broke existing protocols. (Chances are, in fact, that if the new protocol is found to be useful among users and widely deployed, sysadmins probably wouldn't want to take steps that break the protocol.) If there were two alternatives, one of which works even with some pessimistic foresights about what sysadmins *might* do in the future and the other doesn't, but both being similar or same in their functionality, it would do make a total sense that we must choose the former. However, if there is only one alternative, we should not reject it but opt for it at least tentatively until a better alternative comes forward. Regards, Eugene ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Keith Moore" Cc: Sent: Wednesday, September 17, 2003 3:28 PM Subject: Re: domain names as end-point identifiers? > > But vague assertions of the > > form "sysadmins will filter X" are unsupportable. If we pay them too > > much heed we'll end up trying to design a protocol to meet an > > unrealistic set of conditions, and either we'll never finish or we'll > > put the robustness in the wrong place. > > Again, I agree in principle. But this can never be an excuse for lazy > protocol design or implementation. Didn't we learn anything from the > PMTUD disaster? > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 10:40:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04452 for ; Sat, 20 Sep 2003 09:53:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OQ3-0000D3-S7 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 12:47:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGlhET000799 for ipv6-archive@odin.ietf.org; Fri, 19 Sep 2003 12:47:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OQ3-0000Cn-M4 for ipv6-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 12:47:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13811 for ; Fri, 19 Sep 2003 12:47:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0OQ2-00060h-00 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 12:47:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0O7y-0005YE-01 for ipv6-web-archive@ietf.org; Fri, 19 Sep 2003 12:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NqA-0003CC-O1; Fri, 19 Sep 2003 12:10:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nnp-0002Cw-By for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 12:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08070 for ; Fri, 19 Sep 2003 12:07:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A069o-00021Q-00 for ipv6@ietf.org; Thu, 18 Sep 2003 17:17:44 -0400 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1A05nW-0007aQ-00 for ipv6@ietf.org; Thu, 18 Sep 2003 16:54:42 -0400 Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8IKs0HB096524; Thu, 18 Sep 2003 13:54:00 -0700 (PDT) (envelope-from gene@alicia.nttmcl.com) Received: (from gene@localhost) by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8IKs0an096523; Thu, 18 Sep 2003 13:54:00 -0700 (PDT) (envelope-from gene) Date: Thu, 18 Sep 2003 13:54:00 -0700 From: "Eugene M. Kim" To: Keith Moore Cc: Dave Crocker , dhc2@dcrocker.net, ipv6@ietf.org Subject: OT: Argh, mea culpa ;_; (was Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?)) Message-ID: <20030918205400.GA96501@alicia.nttmcl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I apologize for the bad formatting of my previous message (from which an excerpt is quoted below). Really have to find another e-mail program for Windows that properly reformats the quote so it can be within 72 characters per line... (Suggestions?) /me bonks head against wall Thanks, Eugene ----- Original Message ----- > > Keith, > > > > KM> DNS names are not sufficient for rendezvous or referral. > > > > Here are the arguments about the names, themselves, that you put forward: > > > > KM> * Incompatible with existing transport protocols. > > > > If you mean that they are too long to be carried in IP packet headers, you > > are of course correct. If you mean something else, please explain. > > > > However, your concern presupposes that the identifiers must be carried in > > those protocol -- or rather, that they must be carried in them frequently. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Sep 20 11:26:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11906 for ; Sat, 20 Sep 2003 11:26:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jcY-0005Qe-MU for ipv6-archive@odin.ietf.org; Sat, 20 Sep 2003 11:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFQ2PG020860 for ipv6-archive@odin.ietf.org; Sat, 20 Sep 2003 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jcT-0005Me-9Y for ipv6-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 11:26:02 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11729 for ; Sat, 20 Sep 2003 11:25:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jYq-0004F7-R7; Sat, 20 Sep 2003 11:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0iZv-0006f7-1k for ipv6@optimus.ietf.org; Sat, 20 Sep 2003 10:19:15 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11387 for ; Sat, 20 Sep 2003 00:51:59 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8K4pUg17246; Sat, 20 Sep 2003 07:51:31 +0300 Date: Sat, 20 Sep 2003 07:51:30 +0300 (EEST) From: Pekka Savola To: BAUDOT Alain FTRD/DMI/CAE cc: ipv6@ietf.org Subject: RE: comment/question on deprecate-site-local-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, 19 Sep 2003, Pekka Savola wrote: > On Thu, 18 Sep 2003, BAUDOT Alain FTRD/DMI/CAE wrote: > [...] > > So, let ask the question in another way: assuming that the "common > > blocking rule" is guaranted, does it provide some "real" interresting > > feature ? If yes, then comes the question on how to make this rule > > guaranted and possibly in a simple and efficient way. If no, we are > > done. > > I think this is kind of a moot point, because we can *never* guarantee > that, any more than we can guarantee that source addresses are not being > used (except at *our* administrative border, to an extent). ^^^^ meant spoofed, here; sorry. > A different question would be whether a slightly lower "guarantee" (e.g. > "implemented and enabled on most but not all platforms" or "almost always > enabled, unless disabled manually") -- or "warm fuzzy feeling" -- would be > useful. > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 21 00:04:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03684 for ; Sun, 21 Sep 2003 00:04:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0vRo-0007FC-Qn for ipv6-archive@odin.ietf.org; Sun, 21 Sep 2003 00:03:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8L43iXW027840 for ipv6-archive@odin.ietf.org; Sun, 21 Sep 2003 00:03:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0vRo-0007Ex-GF for ipv6-web-archive@optimus.ietf.org; Sun, 21 Sep 2003 00:03:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03657 for ; Sun, 21 Sep 2003 00:03:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0vRm-0005ZL-00 for ipv6-web-archive@ietf.org; Sun, 21 Sep 2003 00:03:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0vRg-0005Z1-00 for ipv6-web-archive@ietf.org; Sun, 21 Sep 2003 00:03:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0vQA-00078c-Nu; Sun, 21 Sep 2003 00:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0vPs-00078A-La for ipv6@optimus.ietf.org; Sun, 21 Sep 2003 00:01:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03629 for ; Sun, 21 Sep 2003 00:01:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0vPg-0005WF-00 for ipv6@ietf.org; Sun, 21 Sep 2003 00:01:32 -0400 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1A0vPV-0005Tk-00 for ipv6@ietf.org; Sun, 21 Sep 2003 00:01:21 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id B42B940E for ; Sun, 21 Sep 2003 00:00:26 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 21 Sep 2003 00:00:26 -0400 Message-Id: <20030921040026.B42B940E@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.27% | 8 | 12.31% | 44792 | moore@cs.utk.edu 11.27% | 8 | 11.84% | 43093 | iljitsch@muada.com 9.86% | 7 | 11.84% | 43066 | pekka.nikander@nomadiclab.com 9.86% | 7 | 9.36% | 34070 | pekkas@netcore.fi 8.45% | 6 | 6.87% | 24993 | michel@arneill-py.sacramento.ca.us 7.04% | 5 | 6.80% | 24732 | dhc2@dcrocker.net 4.23% | 3 | 5.17% | 18822 | gene@nttmcl.com 4.23% | 3 | 3.55% | 12926 | erik.nordmark@sun.com 2.82% | 2 | 3.44% | 12516 | brc@zurich.ibm.com 2.82% | 2 | 3.01% | 10936 | hinden@iprg.nokia.com 2.82% | 2 | 2.87% | 10451 | alain.baudot@rd.francetelecom.com 2.82% | 2 | 2.00% | 7264 | tjc@ecs.soton.ac.uk 1.41% | 1 | 2.31% | 8396 | gih@telstra.net 1.41% | 1 | 1.89% | 6882 | ipv6@nosense.org 1.41% | 1 | 1.70% | 6184 | jari.arkko@kolumbus.fi 1.41% | 1 | 1.69% | 6133 | randall@stewart.chicago.il.us 1.41% | 1 | 1.66% | 6031 | jim.bound@hp.com 1.41% | 1 | 1.43% | 5202 | kempf@docomolabs-usa.com 1.41% | 1 | 1.36% | 4953 | ericlklein@softhome.net 1.41% | 1 | 1.36% | 4939 | kruse@ohio.edu 1.41% | 1 | 1.27% | 4613 | sra+ipng@hactrn.net 1.41% | 1 | 1.07% | 3911 | robson.oliveira@ipv6dobrasil.com.br 1.41% | 1 | 1.04% | 3776 | ciju@avenir.net 1.41% | 1 | 1.02% | 3707 | marcelo@it.uc3m.es 1.41% | 1 | 0.94% | 3436 | bhaskar.s@motorola.com 1.41% | 1 | 0.94% | 3403 | chirayu@chirayu.org 1.41% | 1 | 0.79% | 2863 | itojun@itojun.org 1.41% | 1 | 0.48% | 1730 | bruce.campbell@ripe.net --------+------+--------+----------+------------------------ 100.00% | 71 |100.00% | 363820 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 06:12:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08015 for ; Mon, 22 Sep 2003 06:12:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Nff-0002rO-2o for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 06:11:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MABtPr010990 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 06:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Nfe-0002rB-U4 for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 06:11:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07992 for ; Mon, 22 Sep 2003 06:11:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Nfb-00050q-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 06:11:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1NfV-00050j-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 06:11:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Ndr-0002f3-1x; Mon, 22 Sep 2003 06:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Ncp-0002cW-MD for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 06:09:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07915 for ; Mon, 22 Sep 2003 06:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Nch-0004zH-00 for ipv6@ietf.org; Mon, 22 Sep 2003 06:08:51 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A1NcH-0004yP-00 for ipv6@ietf.org; Mon, 22 Sep 2003 06:08:25 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8MA6ax1071730; Mon, 22 Sep 2003 12:06:36 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8MA6a83229648; Mon, 22 Sep 2003 12:06:36 +0200 Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id MAA56444; Mon, 22 Sep 2003 12:06:33 +0200 Message-ID: <3F6EC995.DE1D494@zurich.ibm.com> Date: Mon, 22 Sep 2003 12:06:14 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: BAUDOT Alain FTRD/DMI/CAE , ipv6@ietf.org Subject: Re: comment/question on deprecate-site-local-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My feeling is that Pekka is correct. Experience shows that whatever words we write in RFCs, prefixes leak. But it does seem reasonable to be clear that FEC0::/10 should be blocked at every administrative boundary. Brian Pekka Savola wrote: > > On Fri, 19 Sep 2003, Pekka Savola wrote: > > On Thu, 18 Sep 2003, BAUDOT Alain FTRD/DMI/CAE wrote: > > [...] > > > So, let ask the question in another way: assuming that the "common > > > blocking rule" is guaranted, does it provide some "real" interresting > > > feature ? If yes, then comes the question on how to make this rule > > > guaranted and possibly in a simple and efficient way. If no, we are > > > done. > > > > I think this is kind of a moot point, because we can *never* guarantee > > that, any more than we can guarantee that source addresses are not being > > used (except at *our* administrative border, to an extent). > ^^^^ > meant spoofed, here; sorry. > > > A different question would be whether a slightly lower "guarantee" (e.g. > > "implemented and enabled on most but not all platforms" or "almost always > > enabled, unless disabled manually") -- or "warm fuzzy feeling" -- would be > > useful. > > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 06:17:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08199 for ; Mon, 22 Sep 2003 06:17:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1NkT-0003Qo-Ee for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 06:16:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MAGrln013184 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 06:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1NkT-0003QZ-AT for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 06:16:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08157 for ; Mon, 22 Sep 2003 06:16:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1NkP-00054U-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 06:16:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1NkK-00054R-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 06:16:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Njf-0003Al-Bo; Mon, 22 Sep 2003 06:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1NjU-00039r-2i for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 06:15:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08105 for ; Mon, 22 Sep 2003 06:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1NjQ-00053A-00 for ipv6@ietf.org; Mon, 22 Sep 2003 06:15:48 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A1Niz-00052T-00 for ipv6@ietf.org; Mon, 22 Sep 2003 06:15:22 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8MAESx1030060; Mon, 22 Sep 2003 12:14:28 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8MAES83240978; Mon, 22 Sep 2003 12:14:28 +0200 Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id MAA32784; Mon, 22 Sep 2003 12:14:26 +0200 Message-ID: <3F6ECB6F.1F536826@zurich.ibm.com> Date: Mon, 22 Sep 2003 12:14:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: comments on deprecate-site-local-00 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, Thanks for the review. Pekka Savola wrote: > > Hi, > > A couple of comments on deprecate-site-local draft. In general, I think > the doc is very good, but could use a bit boosting in a couple of areas > (which -00 draft wouldn't.. :-) > > substantial > ----------- > > Although the consensus was far > from unanimous, the working group decided in its meeting in July > 2003 to document these issues and the consequent decision to > deprecate IPv6 site-local unicast addresses. > > ==> was this really the case? Didn't the WG decide on that already earlier, > not at Vienna?? It seems to me that the documentation decision was definitely not made in San Francisco. But we can fix this by s/decided/confirmed/ > > 2 Adverse effects of site local addresses > > ==> I showed this draft to a believer of site-local addressing, who had had > very little experience with IPv6. He was not convinced of the arguments. > This may be for one of the many reasons. One fix is to also refer to some > documents which include more verbiage than this document, e.g. Margaret > Wasserman's SL impact document -- note that such would necessarily have to > be a normative reference then, requiring the publication of it as an > Informational doc. People who don't understand the down side of RFC 1918 are hard to convince by more verbiage, in my experience. So I don't think this would be a good use of our collective effort. Are there any specific weak points? > > 2.2 Manager pain, leaks > > ==> regarding the previous comment, this section should probably > focus a bit more on the non-trivial leaks (any leak w/ RFC1918 addresses in > the source/destination address is trivial), such as reverse DNS queries for > RFC1918 addresses, passing RFC1918 addresses in the application payloads in > general, etc. (pick non-NAT specific topics e.g. from Keith Moore's "What > NATs break" paper or "NAT architectural considerations" RFC). > > 5 Security Considerations > > The link-local unicast prefix allows for some blocking action in > firewall rules and address selection rules, which are commonly > viewed as a security feature since they prevent packets crossing > administrative boundaries. However, such blocking rules can be > configured for any prefix, including the expected future replacement > for the site-local prefix. Thus the deprecation of the site-local > prefix does not endanger security. > > ==> s/link/site/, obviously. > > ==> I think the security considerations considers only one, but important > aspect of the site-locals. One should also discuss the effect of stability > to the availability (which is part of security), and the effect of explicit > scope to the address selection -- e.g., the case with intra-domain > VPN's which route some traffic directly to the Internet but some to through > the VPN to the infrastructure: how to ensure that the traffic destined to > internal hosts over the VPN doesn't end up in the Internet by accident > (e.g. if the VPN is down). I'm not disagreeing with your points, but does this document really need an extended security analysis? That belongs in the specification for the replacement (if any) of site locals, surely? Brian > > editorial > --------- > > example in DNS or trace-route requests, causing the request to fail, > > ==> s/trace-/trace/ > > The leakage issue is largely unavoidable. While some applications > are intrinsically scoped (eg. RA, ND), most applications have no > > ==> have to spell out RA & ND > > The current definition of scopes follows an idealized "concentric > scope" model. > > ==> I don't understand the use of "concentric" in this context ? > perhaps reword? > > boundaries, QOS boundaries, administrative boundaries, funding > boundaries, some other kinds of boundaries, or a combination. It is > > ==> s/combination/combination of these/ ? > > Having non ambiguous address solves a large part of the developers' > > ==> s/non ambiguous/non-ambiguous/ (everywhere) ? > > This document formally deprecates the IPv6 link-local unicast prefix > defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The > special behavior of this prefix MUST no longer be supported in new > implementations. > > ==> if the uppercase keywords are used, one has to add the reference to the > definition of them up front in section 1 or thereabouts. > > 9 Acknowledgements > > ==> should probably be non-empty :-) > > 10 References > > ==> you're missing a ref to [Bradner, 1996]. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 08:08:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11618 for ; Mon, 22 Sep 2003 08:08:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1PTn-0008BW-KF for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 08:07:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MC7k8p031398 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 08:07:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1PTa-00086L-Vn for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 08:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11590 for ; Mon, 22 Sep 2003 08:07:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1PTa-0006FG-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 08:07:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1PTU-0006FD-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 08:07:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1PS5-0007d0-Rn; Mon, 22 Sep 2003 08:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1PR8-0007bl-G9 for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 08:05:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11554 for ; Mon, 22 Sep 2003 08:04:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1PR2-0006Dr-00 for ipv6@ietf.org; Mon, 22 Sep 2003 08:04:56 -0400 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A1PQc-0006Cy-00 for ipv6@ietf.org; Mon, 22 Sep 2003 08:04:30 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8MC3GoU093502; Mon, 22 Sep 2003 14:03:16 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8MC3G1Q240582; Mon, 22 Sep 2003 14:03:16 +0200 Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id OAA57442; Mon, 22 Sep 2003 14:03:14 +0200 Message-ID: <3F6EE4EE.C7F7BB9@zurich.ibm.com> Date: Mon, 22 Sep 2003 14:02:54 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: Writeups on why RFC1918 is bad? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, The document came out of the IAB, while the NAT WG was active, so there was a lot of diplomacy between the IAB, the IESG, and the NAT WG chairs, to get to a version of the document that everybody was happy with. Since we don't have a NAT WG today, that side of it might be easier, but it can very easily become a religious war. Brian Pekka Savola wrote: > > Hi, > > On Mon, 15 Sep 2003, Brian E Carpenter wrote: > > I believe RFC 2993 actually covers all the issues (including the one > > of VPNs between RFC 1918 sites, especially in section 7.6). > > Thanks for the pointer. Yes, RFC 2993 seems to cover many aspects which > seem surprisingly familiar ;-), but I'm not sure if it answers questions > like : "I want to use NAT or RFC1918 for purpose X. Why shouldn't I do > it? (Why might I want to do it anyway?) What other feasible ways are > there to do it without such mechanisms?" > > In other words, the document seems to cover the scenarios using a broad > overview -- it may not be applicable to the most common cases of > deployment. > > But then again, I'll have to go read the RFC in detail. > > > Given how difficult it was to get that RFC published, I wonder if it > > is worth the effort of writing what would efefctively be the same > > document, but with an emphasis on ambiguity instead of translation. > > I can certainly envision how this could turn ugly. Could you elaborate a > bit on the difficulties that came across? > > Pekka > > > Pekka Savola wrote: > > > > > > Hi, > > > > > > Regarding the local addressing debate... > > > > > > I had the misfortune to having to participate in a discussion where a > > > multiple-branch (20-30+) enterprise, which has deployed private addresses > > > and network-to-network VPN's inside it, wants to start using IPv6. > > > > > > I'm wondering whether there exist any educational material why > > > RFC1918-like addressing is really *NOT* a good idea (or even, list and > > > evaluate the tradeoffs), and how to get around it. ("If one can state > > > clearly arguments why they shouldn't be doing it with IPv4, maybe it's > > > easier to convince them not to do so with IPv6"). > > > > > > It seems to me that there is a very severe need for a way to enlighten > > > folks like that if we ever want to be successful.. > > > > > > http://www.cs.utk.edu/~moore/what-nats-break.html is interesting, but not > > > focused enough for RFC1918-like addressing itself. > > > > > > I.e., what I'd like to see is whether anyone has written up something > > > regarding either "why local addressing would be a bad idea with IPv6", or > > > "why local addressing is a bad idea with IPv4", especially from the > > > security point-of-view. > > > > > > btw., one way to probably avoid the two-faced DNS issues with local > > > addressing is probably to simply use a different naming for internal > > > commuications like with example.com --> example.internal. > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 20:39:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19439 for ; Mon, 22 Sep 2003 20:39:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bCZ-0004HV-5I for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 20:38:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N0clGC016451 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 20:38:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bCX-0004DM-GL for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 20:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19380 for ; Mon, 22 Sep 2003 20:38:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1bCV-0002tn-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 20:38:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1bCU-0002tk-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 20:38:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bBp-00044X-KB; Mon, 22 Sep 2003 20:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bBb-00042h-BR for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 20:37:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19340 for ; Mon, 22 Sep 2003 20:37:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1bBY-0002oo-00 for ipv6@ietf.org; Mon, 22 Sep 2003 20:37:44 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1A1bBY-0002lg-00 for ipv6@ietf.org; Mon, 22 Sep 2003 20:37:44 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h8N0bBVo027975; Mon, 22 Sep 2003 17:37:12 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8N0b9Q00740; Tue, 23 Sep 2003 02:37:09 +0200 (MEST) Date: Tue, 23 Sep 2003 02:32:19 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] To: Pekka Savola Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Pekka, I think there is an overarching issue about deployment/transition that relates to the NAT thing; providing a new service/feature/capability by only adding one box to the network is a lot easier sell than for instance - requring a box in the peer's network - requring all the routers in the path to do something new - requring the ISP to do something new Thus even though NATs cause lots of problems, many would be swayed by the low entry cost of just adding a box to get some particular new capability. And NATs are used as a technology as part of providing different user visible capabilities such as - "connection sharing" from home - load balancers (without needing any support in the servers behind the LB) - multihoming boxes (some combining NAT and a DNS server for inbound and outbound multihoming support without ISP involvement or host awareness) It isn't clear to me at what point the pain caused by NAT in different cases will be high enough to motivate a transition to some different technology, or whether there must be new capabilities (such as the ability to have multiple servers at the same port number in a home) that are perceived important enough to cause migration away from NAT solutions. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 20:55:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19980 for ; Mon, 22 Sep 2003 20:55:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bSR-0006AT-B9 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 20:55:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N0tBQA023700 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 20:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bSR-0006A9-4y for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 20:55:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19929 for ; Mon, 22 Sep 2003 20:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1bSO-0004Ey-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 20:55:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1bSO-0004Es-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 20:55:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bSI-00065c-T7; Mon, 22 Sep 2003 20:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1bRm-00062o-6E for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 20:54:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19885 for ; Mon, 22 Sep 2003 20:54:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1bRj-0004BA-00 for ipv6@ietf.org; Mon, 22 Sep 2003 20:54:27 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1bRj-00048Z-00 for ipv6@ietf.org; Mon, 22 Sep 2003 20:54:27 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8N0rtHm015042; Mon, 22 Sep 2003 17:53:55 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIJ28974; Mon, 22 Sep 2003 17:53:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA16363; Mon, 22 Sep 2003 17:53:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16239.39330.308606.237915@thomasm-u1.cisco.com> Date: Mon, 22 Sep 2003 17:53:54 -0700 (PDT) To: Erik Nordmark Cc: Pekka Savola , ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark writes: > And NATs are used as a technology as part of providing different > user visible capabilities such as > - "connection sharing" from home From my SF-centric Nexus-of-the-web-trendiod standpoint: for residential use (especially with broadband) it is simply impossible to have an argument about the evils of NAT. Those who try are on a different planet and and they look awfully small and green to the native denizens. You might be able to convince network IT types given enough ROI's and TCO's and all the rest of the PHBisms, but until IPv6 is at the same level of complete user-idiocy-bliss as a linksys-like NAT box, you might as well be trying to sell them on a new religion because it requires that much of a leap of faith. Mike -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 22:43:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04118 for ; Mon, 22 Sep 2003 22:43:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1d8Q-00022t-0G for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 22:42:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N2gbJj007857 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 22:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1d8P-00022e-QI for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 22:42:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04075 for ; Mon, 22 Sep 2003 22:42:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1d8M-00032n-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 22:42:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1d8M-00032k-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 22:42:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1d7p-0001pg-SP; Mon, 22 Sep 2003 22:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1d7n-0001p1-BM for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 22:41:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04046 for ; Mon, 22 Sep 2003 22:41:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1d7k-0002yd-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:41:56 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A1d7j-0002yZ-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:41:55 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 57E40140BF; Mon, 22 Sep 2003 22:41:56 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30203-14; Mon, 22 Sep 2003 22:41:56 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1EE0F140B9; Mon, 22 Sep 2003 22:41:55 -0400 (EDT) Date: Mon, 22 Sep 2003 22:38:12 -0400 From: Keith Moore To: Michael Thomas Cc: moore@cs.utk.edu, Erik.Nordmark@sun.com, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030922223812.7b62d08c.moore@cs.utk.edu> In-Reply-To: <16239.39330.308606.237915@thomasm-u1.cisco.com> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > From my SF-centric Nexus-of-the-web-trendiod > standpoint: for residential use (especially with > broadband) it is simply impossible to have an > argument about the evils of NAT. that's the stupidest thing that's been said here in a long time. NATs are at least as harmful in a residential environment as in any other environment. It's just that residential customers are slower to realize the problems with NAT and they have less ability to get blocks of addresses routed to them at reasonable prices than other customers. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 22:51:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04638 for ; Mon, 22 Sep 2003 22:51:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dGG-0003TT-6P for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 22:50:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N2oiwk013349 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 22:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dGG-0003St-0f for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 22:50:44 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04579 for ; Mon, 22 Sep 2003 22:50:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dFa-0003Bs-Of; Mon, 22 Sep 2003 22:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dEf-00033C-IH for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 22:49:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04545 for ; Mon, 22 Sep 2003 22:48:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dEc-0003ig-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:49:02 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1A1dEb-0003eu-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:49:01 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HLN00G04BSUMZ@mailout3.samsung.com> for ipv6@ietf.org; Tue, 23 Sep 2003 11:48:30 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLN0066LBSU7N@mailout3.samsung.com> for ipv6@ietf.org; Tue, 23 Sep 2003 11:48:30 +0900 (KST) Received: from LocalHost ([165.213.91.136]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HLN00G6PBSU2V@mmp1.samsung.com> for ipv6@ietf.org; Tue, 23 Sep 2003 11:48:30 +0900 (KST) Date: Tue, 23 Sep 2003 11:48:31 +0900 From: Ron Lee Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] In-reply-to: To: "'Pekka Savola'" , ipv6@ietf.org Message-id: <000701c3817d$2ce07af0$885bd5a5@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello, Is it really true that most of the market chose to use NAT rather than tunneling or dual-stack for IPv6 transition mechanism? As far as I know, many providers in Japan have long been servicing IPv6 service, and their choice was never NAT. It was mostly tunneling, with small number of dual-stack services. Am I mistaken? Thanks in advance for any comments. Ron -------------------------- Ron Lee Senior Engineer/ Ph.D. Samsung Electronics Suwon, South Korea ' spamcontrol ' -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Pekka Savola Sent: Thursday, September 18, 2003 11:31 PM To: ipv6@ietf.org Subject: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Hi, As I sent some thoughts on RFC1918 to the IAB, we had a short personal discussion with Geoff, and he made a very good question: "Why did the market pick up NATs and run so hard with them despite their evident complications and technical compromises?" I made a few observations of my own, which I believe are not so technical (because I don't think picking NATs has been a very technical decision, most of the times.) This discussion -- while maybe off-topic, chairs please speak up if so - - may be relevant when considering whether there is something missing in the IPv6 protocol set. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Mon, 15 Sep 2003 15:34:34 +0300 (EEST) From: Pekka Savola To: Geoff Huston Subject: Re: Writeups on why RFC1918 is bad? (fwd) On Mon, 15 Sep 2003, Geoff Huston wrote: > At 11:19 AM 15/09/2003 +0300, Pekka Savola wrote: [...] > So the question that strikes right at the heart of this is: "Why did > the market pick up NATs and run so hard with them despite their > evident complications and technical compromises?" > > And if you can provide some insights into market behaviours in > answering the above question then you will gain some valuable insights > in answering the related questions listed above. (hmm.. perhaps we'd have had this discussion on a larger forum, like the ipv6 list or the IAB list.. feel free to forward or whatever if you feel the latter would be warranted.) I have thought up four reasons for this; I think all of them, especially the first two, are pretty obvious, and should not be technology-driven. 1) they provide for easy, extensible networking. When you install a NAT box in the network, the user doesn't have to configure static routes or anything like that; the NAT box is "transparent" (in a weird sense) to the network. The same argument applies to bridging compared to routing; if we wanted to get rid of NAT's e.g. in home or SOHO environments for IPv6, I'm pretty certain we'd have to go and specify a bridging architecture (remember J. Noel Chiappa's posts on why he thinks he made a mistake by advocating routing instead of bridging at the start of 80's). 2) NAT's have security properties which are understandable and settable even by those who don't have any security expertise. Just plug it in, and bam.. you prevent any incoming traffic except to those nodes which have been explicitly configured. The same would be doable with total- blockage access lists as well, but many folks really don't understand this. 3) IP address space conservation and ISP business models. ISPs feel that they cannot give enough IP addresses to the users (e.g. home), unless they want to spend considerable amount of energy fighting the respective RIR to get the address space (e.g., our hostmaster boggled when I proposed he'd apply for some /20 or /21 for a thousand or so DSL users). On the other hand, some ISPs do even have a business model of not giving the home users anything but one address, to get them to get premium service; I don't know the details of such arrangements. The bottom line is that getting IP addresses to those folks that need them (e.g. homes), _easily_, is just too difficult, impossible or costs too much. 4) the evident complications and technical compromises are not really so evident (as in, you don't typically notice or understand them outright, and when you do, it's already too late), and your favourite vendor is more than happy to code workarounds to these complications (e. g. ALG's) to gain you as a customer. Do you have any answers of your own to the question you posed? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 22 22:54:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04862 for ; Mon, 22 Sep 2003 22:54:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dJB-000481-KD for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 22:53:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N2rjWZ015863 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 22:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dJB-00047m-E4 for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 22:53:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04770 for ; Mon, 22 Sep 2003 22:53:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dIU-0003oJ-GB; Mon, 22 Sep 2003 22:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dII-0003lo-BV for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 22:52:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04705 for ; Mon, 22 Sep 2003 22:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dIF-00044D-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:52:47 -0400 Received: from 198.cust3.nsw.dsl.ozemail.com.au ([203.103.158.198] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1A1dIE-00041F-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:52:46 -0400 Received: from Dupy2.nosense.org (198.cust3.nsw.dsl.ozemail.com.au [203.103.158.198]) by nosense.org (Postfix) with SMTP id 6FDBF3F05E for ; Tue, 23 Sep 2003 12:22:59 +0930 (CST) Date: Tue, 23 Sep 2003 12:22:59 +0930 From: Mark Smith To: ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030923122259.38bb8bad.ipv6@nosense.org> In-Reply-To: <20030922223812.7b62d08c.moore@cs.utk.edu> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As a datapoint, it might be worth reading the comments posted to slashdot relating to this story End Of the Line for SpeakFreely: NATed to Death http://slashdot.org/article.pl?sid=03/09/20/1556253&mode=thread&tid=126&tid=185&tid=95 (And yes, I got sucked into it, and ended up looking like I'd just stepped out of my spaceship) On Mon, 22 Sep 2003 22:38:12 -0400 Keith Moore wrote: > > From my SF-centric Nexus-of-the-web-trendiod > > standpoint: for residential use (especially with > > broadband) it is simply impossible to have an > > argument about the evils of NAT. > > that's the stupidest thing that's been said here in a long time. > > NATs are at least as harmful in a residential environment as in any other > environment. It's just that residential customers are slower to realize > the problems with NAT and they have less ability to get blocks of addresses > routed to them at reasonable prices than other customers. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 00:00:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07719 for ; Tue, 23 Sep 2003 00:00:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eL1-0004FX-8N for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 23:59:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N3xhUR016329 for ipv6-archive@odin.ietf.org; Mon, 22 Sep 2003 23:59:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eL1-0004FI-1v for ipv6-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 23:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07660 for ; Mon, 22 Sep 2003 23:59:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1eKy-0002gY-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 23:59:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1eKy-0002gV-00 for ipv6-web-archive@ietf.org; Mon, 22 Sep 2003 23:59:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eKM-000425-SC; Mon, 22 Sep 2003 23:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eKH-00041E-61 for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 23:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07625 for ; Mon, 22 Sep 2003 23:58:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1eKF-0002cE-00 for ipv6@ietf.org; Mon, 22 Sep 2003 23:58:55 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A1eKE-0002cA-00 for ipv6@ietf.org; Mon, 22 Sep 2003 23:58:54 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A7CB0140C6; Mon, 22 Sep 2003 23:58:55 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04642-11; Mon, 22 Sep 2003 23:58:55 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7BB4A13FD4; Mon, 22 Sep 2003 23:58:54 -0400 (EDT) Date: Mon, 22 Sep 2003 23:55:11 -0400 From: Keith Moore To: Ron Lee Cc: moore@cs.utk.edu, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030922235511.1a00af27.moore@cs.utk.edu> In-Reply-To: <000701c3817d$2ce07af0$885bd5a5@LocalHost> References: <000701c3817d$2ce07af0$885bd5a5@LocalHost> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Is it really true that most of the market chose to use NAT rather than > tunneling or dual-stack for IPv6 transition mechanism? there is zero truth to that. if you're going to use NAT there is (almost) no point in using IPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 00:21:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08569 for ; Tue, 23 Sep 2003 00:21:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1efu-0007Ph-Qf for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 00:21:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N4LIVF028496 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 00:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1efu-0007PU-Jw for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 00:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08515 for ; Tue, 23 Sep 2003 00:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1efs-0004hP-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 00:21:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1efs-0004hK-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 00:21:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1efe-0007F2-Qu; Tue, 23 Sep 2003 00:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eez-0007Ah-7J for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 00:20:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08464 for ; Tue, 23 Sep 2003 00:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1eew-0004bd-00 for ipv6@ietf.org; Tue, 23 Sep 2003 00:20:19 -0400 Received: from mx1sophos.cqu.edu.au ([138.77.5.125]) by ietf-mx with esmtp (Exim 4.12) id 1A1eew-0004ak-00 for ipv6@ietf.org; Tue, 23 Sep 2003 00:20:18 -0400 Received: from proton.staff.ad.cqu.edu.au ([138.77.34.41] helo=ROKEMAIL.staff.ad.cqu.edu.au) by mx1sophos.cqu.edu.au with esmtp (Exim 4.22) id 1A1een-0001SF-4L; Tue, 23 Sep 2003 14:20:09 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Date: Tue, 23 Sep 2003 14:20:08 +1000 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOBhyX6mQiHO1DbRVS12DbRpBRKFwAAl1Kg From: "Amoakoh Gyasi-Agyei" To: "Keith Moore" , "Ron Lee" Cc: , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If you continue to be bound by NAT how are you going to connect all the many many mobile devices to the Internet to exploit the services of upcoming mobile Internet? Is NAT useful for mobile devices? -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, 23 September 2003 1:55 PM To: Ron Lee Cc: moore@cs.utk.edu; pekkas@netcore.fi; ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] > Is it really true that most of the market chose to use NAT rather than > tunneling or dual-stack for IPv6 transition mechanism? there is zero truth to that. if you're going to use NAT there is (almost) no point in using IPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 01:05:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10445 for ; Tue, 23 Sep 2003 01:05:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1fMe-0004b6-RS for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 01:05:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N55SSv017673 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 01:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1fMe-0004ay-Lt for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 01:05:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10404 for ; Tue, 23 Sep 2003 01:05:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1fMc-0001CK-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 01:05:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1fMb-0001CH-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 01:05:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1fMF-0004Sy-DX; Tue, 23 Sep 2003 01:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1fLH-0004Lz-Qo for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 01:04:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10357 for ; Tue, 23 Sep 2003 01:03:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1fLF-00014b-00 for ipv6@ietf.org; Tue, 23 Sep 2003 01:04:01 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A1fLE-00010L-00 for ipv6@ietf.org; Tue, 23 Sep 2003 01:04:00 -0400 Subject: RE: why market picked up NATs [Re: Write-ups on why RFC1918 is bad?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Sep 2003 22:03:24 -0700 Content-class: urn:content-classes:message Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: why market picked up NATs [Re: Write-ups on why RFC1918 is bad?] Thread-Index: AcOBa5vEqgzSwqNnR5mO5528xr/DpgAInRUA From: "Michel Py" To: "Erik Nordmark" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Erik, > Erik Nordmark wrote: > It isn't clear to me at what point the pain caused by NAT in > different cases will be high enough to motivate a transition > to some different technology, or whether there must be new > capabilities (such as the ability to have multiple servers > at the same port number in a home) that are perceived > important enough to cause migration away from NAT solutions. I don't think that the ability to have multiple servers on the same port is significant enough to trigger a migration; there would need to be a more significant change. Bottom line is that on my single IP at home, I host all the services I want, use H.323, peer-to-peer apps, and whatever else I please and yes it does work. The annoyance at this point in time is manual configuration to make it work, but with things such as UPNP and STUN it gets easier and easier. If we were in a world where we did not need stateful firewalls, NAT would be a lot more of a hassle than it is today; unfortunately dealing with a stateful firewall with or without NAT is about the same amount of work, so NAT is here to stay. I have to say that given the recent trends and developments, I am now on the fence WRT joining the camp that says that NAT is unavoidable for v6 so we might as well make it work. I have not made my mind yet but if things continue the way they are now you will likely find me developing a NATv6 box this time next year. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 02:04:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17026 for ; Tue, 23 Sep 2003 02:04:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gHW-0003QW-TV for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:04:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N64Ew5013171 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gHW-0003QB-7b for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 02:04:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16468 for ; Tue, 23 Sep 2003 02:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1gHT-0006do-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:04:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1gHS-0006dl-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:04:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gHL-0003LT-LM; Tue, 23 Sep 2003 02:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gGR-0003DN-7a for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 02:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15318 for ; Tue, 23 Sep 2003 02:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1gGN-0006X4-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:03:03 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1gGN-0006U5-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:03:03 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8N62Vk08378; Tue, 23 Sep 2003 09:02:31 +0300 Date: Tue, 23 Sep 2003 09:02:31 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: ipv6@ietf.org Subject: Re: comments on deprecate-site-local-00 In-Reply-To: <3F6ECB6F.1F536826@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, 22 Sep 2003, Brian E Carpenter wrote: > > 2 Adverse effects of site local addresses > > > > ==> I showed this draft to a believer of site-local addressing, who had had > > very little experience with IPv6. He was not convinced of the arguments. > > This may be for one of the many reasons. One fix is to also refer to some > > documents which include more verbiage than this document, e.g. Margaret > > Wasserman's SL impact document -- note that such would necessarily have to > > be a normative reference then, requiring the publication of it as an > > Informational doc. > > People who don't understand the down side of RFC 1918 are hard to convince > by more verbiage, in my experience. So I don't think this would be a > good use of our collective effort. True, but if we wish to remain relevant, something has to be written somewhere. I fully agree that doing so in *this* document may not be worth it; it might be worth it in some other doc, e.g. sl-impact. > Are there any specific weak points? Trying to summarize: - 2.1: trying your own local addresses while visiting another site is a problem, but no news compared to RFC1918 - 2.2: the "leaking" of addresses may not be clear enough. The reader interpreted that as source/destination addresses (trivial!) and DNS. The *difficult* problems are elsewhere.. - 2.3: the reader didn't notice that the difficulty of routing lies with overlapping or adjacent sites. I'll send the exact wording off-list.. > > 5 Security Considerations > > > > The link-local unicast prefix allows for some blocking action in > > firewall rules and address selection rules, which are commonly > > viewed as a security feature since they prevent packets crossing > > administrative boundaries. However, such blocking rules can be > > configured for any prefix, including the expected future replacement > > for the site-local prefix. Thus the deprecation of the site-local > > prefix does not endanger security. > > > > ==> s/link/site/, obviously. > > > > ==> I think the security considerations considers only one, but important > > aspect of the site-locals. One should also discuss the effect of stability > > to the availability (which is part of security), and the effect of explicit > > scope to the address selection -- e.g., the case with intra-domain > > VPN's which route some traffic directly to the Internet but some to through > > the VPN to the infrastructure: how to ensure that the traffic destined to > > internal hosts over the VPN doesn't end up in the Internet by accident > > (e.g. if the VPN is down). > > I'm not disagreeing with your points, but does this document really need an > extended security analysis? That belongs in the specification for the > replacement (if any) of site locals, surely? Well, I'm not sure if the document does need it; maybe not. However, the security considerations as it is is a bit one-sided. It should be either tailed down a bit or extended. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 02:05:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18034 for ; Tue, 23 Sep 2003 02:05:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gIM-0003p8-Jj for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:05:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N656kl014689 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gIL-0003m4-62 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 02:05:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17354 for ; Tue, 23 Sep 2003 02:04:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1gIH-0006if-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:05:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1gIH-0006ic-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:05:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gII-0003fV-JO; Tue, 23 Sep 2003 02:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1gHR-0003NB-MX for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 02:04:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16392 for ; Tue, 23 Sep 2003 02:04:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1gHO-0006dN-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:04:06 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A1gHN-0006cU-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:04:05 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8N5tVed031509; Tue, 23 Sep 2003 07:55:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 23 Sep 2003 07:55:21 +0200 Subject: Re: why market picked up NATs [Re: Write-ups on why RFC1918 is bad?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: "Michel Py" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <84BE9DEA-ED8A-11D7-9C77-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On dinsdag, sep 23, 2003, at 07:03 Europe/Amsterdam, Michel Py wrote: > I don't think that the ability to have multiple servers on the same > port > is significant enough to trigger a migration; there would need to be a > more significant change. Bottom line is that on my single IP at home, I > host all the services I want, use H.323, peer-to-peer apps, and > whatever > else I please and yes it does work. But only because application and NAT box builders are bending over backwards to support it. > I have to say that given the recent trends and developments, I am now > on > the fence WRT joining the camp that says that NAT is unavoidable for v6 Where is this camp hiding? > so we might as well make it work. I have not made my mind yet but if > things continue the way they are now you will likely find me developing > a NATv6 box this time next year. When I sent you http://www.bgpexpert.com/darkside.mp3 a while ago that was a joke, you know. I think adding NAT to the mix in IPv6 makes no sense at all, as NAT in itself doesn't provide any useful functionality, it's only a crutch to get around lack of address space (which isn't an issue in IPv6) or renumbering (which is less of an issue in IPv6). It would certainly be possible to rearrange the IP architecture in such a way that NAT fits in. (There are numerous technologies where address-like fields change in transit.) However, this means a significant number of changes in many places, not unlike the changes necessary to support IPv6... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 02:53:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26510 for ; Tue, 23 Sep 2003 02:53:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h2K-00033C-IS for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:52:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N6qaDP011699 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:52:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h2H-0002yj-LK for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 02:52:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26470 for ; Tue, 23 Sep 2003 02:52:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1h2E-000373-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:52:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1h2D-00036z-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:52:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h1m-0002mj-3T; Tue, 23 Sep 2003 02:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h10-0002hD-9K for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 02:51:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26456 for ; Tue, 23 Sep 2003 02:51:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1h0w-00030Z-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:51:10 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by ietf-mx with esmtp (Exim 4.12) id 1A1h0w-00030N-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:51:10 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h8N6pGZS001793; Tue, 23 Sep 2003 08:51:16 +0200 (CEST) Date: Tue, 23 Sep 2003 08:51:13 +0200 Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pekka Savola , ipv6@ietf.org To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <52409BC6-ED92-11D7-8F55-000A95880ECC@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On tisdag, sep 23, 2003, at 02:32 Europe/Stockholm, Erik Nordmark wrote: > I think there is an overarching issue about deployment/transition > that relates to the NAT thing; > providing a new service/feature/capability by only adding one box to > the network is a lot easier sell than for instance > - requring a box in the peer's network > - requring all the routers in the path to do something new > - requring the ISP to do something new > To be honest I think there is a much simpler reason as to why NAT picked up. The concept of "if the outside world can't see what I have in my network - it must be secure" is much easier to accept by most people than "NAT does not really give you increased security" and "you break the end-to-end model". - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com iQA/AwUBP2/tY6arNKXTPFCVEQJPpQCff8Z9cR5i9/Nit4X1hCMNSffUinMAnjgr FcNTE3AgNrKz32ww+rJCPy6M =LMBq -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 02:58:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26780 for ; Tue, 23 Sep 2003 02:58:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h7g-000411-M9 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:58:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N6w8u3015430 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 02:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h7f-00040i-Q3 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 02:58:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26735 for ; Tue, 23 Sep 2003 02:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1h7b-0003cD-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:58:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1h7b-0003cA-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 02:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h7a-0003wg-VR; Tue, 23 Sep 2003 02:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1h73-0003r4-ES for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 02:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26705 for ; Tue, 23 Sep 2003 02:57:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1h6z-0003Yq-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:57:25 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by ietf-mx with esmtp (Exim 4.12) id 1A1h6z-0003Yh-00 for ipv6@ietf.org; Tue, 23 Sep 2003 02:57:25 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h8N6vSZS001800; Tue, 23 Sep 2003 08:57:33 +0200 (CEST) Date: Tue, 23 Sep 2003 08:57:26 +0200 Subject: Re: comments on deprecate-site-local-00 Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , ipv6@ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <30D55E52-ED93-11D7-8F55-000A95880ECC@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> 2 Adverse effects of site local addresses >>> >>> ==> I showed this draft to a believer of site-local addressing, who >>> had had >>> very little experience with IPv6. He was not convinced of the >>> arguments. >>> This may be for one of the many reasons. One fix is to also refer >>> to some >>> documents which include more verbiage than this document, e.g. >>> Margaret >>> Wasserman's SL impact document -- note that such would necessarily >>> have to >>> be a normative reference then, requiring the publication of it as an >>> Informational doc. >> >> People who don't understand the down side of RFC 1918 are hard to >> convince >> by more verbiage, in my experience. So I don't think this would be a >> good use of our collective effort. > > True, but if we wish to remain relevant, something has to be written > somewhere. I fully agree that doing so in *this* document may not be > worth it; it might be worth it in some other doc, e.g. sl-impact. I agree with Pekka. HAving this in writing somewhere is important. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com iQA/AwUBP2/u2KarNKXTPFCVEQL+PACg5HhPDOK6MMEMG433odlKWl43NpUAnjBN zKZ+AS//5H++SrR2uv4H+8KA =hvTJ -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 03:06:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27124 for ; Tue, 23 Sep 2003 03:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1hFX-0005NT-UX for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 03:06:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N76Fq9020664 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 03:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1hFW-0005N1-63 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 03:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27062 for ; Tue, 23 Sep 2003 03:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1hFS-0004LO-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 03:06:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1hFS-0004LK-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 03:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1hFL-0005GS-Iu; Tue, 23 Sep 2003 03:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1hFB-0005F1-GN for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 03:05:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27046 for ; Tue, 23 Sep 2003 03:05:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1hF7-0004JQ-00 for ipv6@ietf.org; Tue, 23 Sep 2003 03:05:49 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by ietf-mx with esmtp (Exim 4.12) id 1A1hF6-0004JI-00 for ipv6@ietf.org; Tue, 23 Sep 2003 03:05:49 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h8N6u1ZS001797; Tue, 23 Sep 2003 08:56:01 +0200 (CEST) Date: Tue, 23 Sep 2003 08:55:57 +0200 Subject: Re: why market picked up NATs [Re: Write-ups on why RFC1918 is bad?] Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Erik Nordmark" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On tisdag, sep 23, 2003, at 07:03 Europe/Stockholm, Michel Py wrote: > I have to say that given the recent trends and developments, I am now > on > the fence WRT joining the camp that says that NAT is unavoidable for v6 > so we might as well make it work. I have not made my mind yet but if > things continue the way they are now you will likely find me developing > a NATv6 box this time next year. Just out of curiosity, then why bother migrating to IPv6 at all? What have you gained? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com iQA/AwUBP2/ugKarNKXTPFCVEQI7wgCfQEqAxjzcoGbVar1Ui5CJ1znc8vMAn2Ok rudJ/ET82MwFml0yyIUsB80k =1Y1u -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 05:26:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01960 for ; Tue, 23 Sep 2003 05:26:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jRH-0005y6-SL for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 05:26:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N9QVcN022941 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 05:26:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jRH-0005xt-Ki for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 05:26:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01939 for ; Tue, 23 Sep 2003 05:26:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jRE-00011o-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 05:26:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1jRD-00011k-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 05:26:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jQn-0005pT-U7; Tue, 23 Sep 2003 05:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jQY-0005ns-9f for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 05:25:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01910 for ; Tue, 23 Sep 2003 05:25:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jQV-0000xk-00 for ipv6@ietf.org; Tue, 23 Sep 2003 05:25:43 -0400 Received: from smithers.nildram.co.uk ([195.112.4.34]) by ietf-mx with esmtp (Exim 4.12) id 1A1jQU-0000xe-00 for ipv6@ietf.org; Tue, 23 Sep 2003 05:25:42 -0400 Received: from hourglass (unknown [81.6.214.202]) by smithers.nildram.co.uk (Postfix) with ESMTP id 6DB8124EF06; Tue, 23 Sep 2003 10:20:43 +0100 (BST) From: "Christian de Larrinaga" To: "'Keith Moore'" Cc: , Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Date: Tue, 23 Sep 2003 10:23:08 +0100 Message-ID: <000901c381b4$4dad1130$cad60651@hourglass> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030922235511.1a00af27.moore@cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > Is it really true that most of the market chose to use NAT > rather than > > tunneling or dual-stack for IPv6 transition mechanism? > > there is zero truth to that. if you're going to use NAT > there is (almost) > no point in using IPv6. > well use v6 through the NAT :-) so you keep on friendly terms with the folks who think NAT is a security "must have" and still get to give all real users an individual IP address. Christian de Larrinaga -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 09:31:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11917 for ; Tue, 23 Sep 2003 09:31:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nFf-0003BY-Gq for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 09:30:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NDUlrZ012238 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 09:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nFf-0003BJ-6r for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 09:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11871 for ; Tue, 23 Sep 2003 09:30:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nFd-0007Nc-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 09:30:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1nFd-0007NY-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 09:30:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nDy-0002zr-Kz; Tue, 23 Sep 2003 09:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nDk-0002z5-MP for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 09:28:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11793 for ; Tue, 23 Sep 2003 09:28:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nDi-0007Lz-00 for ipv6@ietf.org; Tue, 23 Sep 2003 09:28:47 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A1nDi-0007Lw-00 for ipv6@ietf.org; Tue, 23 Sep 2003 09:28:46 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 434D8140FF; Tue, 23 Sep 2003 09:28:46 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20523-15; Tue, 23 Sep 2003 09:28:45 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 13ED3140A0; Tue, 23 Sep 2003 09:28:45 -0400 (EDT) Date: Tue, 23 Sep 2003 09:25:00 -0400 From: Keith Moore To: "Christian de Larrinaga" Cc: moore@cs.utk.edu, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030923092500.3e9dca26.moore@cs.utk.edu> In-Reply-To: <000901c381b4$4dad1130$cad60651@hourglass> References: <20030922235511.1a00af27.moore@cs.utk.edu> <000901c381b4$4dad1130$cad60651@hourglass> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > well use v6 through the NAT :-) so you keep on friendly terms with the folks > who think NAT is a security "must have" and still get to give all real users > an individual IP address. sort of seems like a contradiction - either you have the NAT to provide security or you use the same address for a host everywhere so that applications can (modulo access control) talk to hosts using the same address no matter where they are. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 09:45:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12933 for ; Tue, 23 Sep 2003 09:45:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nTE-0004TI-Ko for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 09:44:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NDimfx017182 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 09:44:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nTE-0004T3-Fq for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 09:44:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12882 for ; Tue, 23 Sep 2003 09:44:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nTC-0007jU-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 09:44:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1nTC-0007jQ-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 09:44:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nST-00045L-Hu; Tue, 23 Sep 2003 09:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nS1-00040f-Ey for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 09:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12775 for ; Tue, 23 Sep 2003 09:43:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nRz-0007gz-00 for ipv6@ietf.org; Tue, 23 Sep 2003 09:43:31 -0400 Received: from mr200a.caspiannetworks.com ([63.108.173.139] helo=cmail.caspian.com) by ietf-mx with esmtp (Exim 4.12) id 1A1nRy-0007gJ-00 for ipv6@ietf.org; Tue, 23 Sep 2003 09:43:31 -0400 Received: from innovationslab.net ([172.17.55.3]) by cmail.caspian.com (Mirapoint Messaging Server MOS 3.2.4-GA) with ESMTP id AIQ25439; Tue, 23 Sep 2003 06:42:56 -0700 (PDT) Message-ID: <3F704DDF.3050800@innovationslab.net> Date: Tue, 23 Sep 2003 09:42:55 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Note on id/loc separation discussion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, The chairs have noted the level of interest garnered by the discussion of separating the Identifier and Locator aspects of IP addresses. There is apparently a high level of interest in exploring possible ways of separating these functionalities and gauging the benefits and downsides. However, the chairs wish to point out that this topic is not in charter for the ipv6 mailing list and it touches on the domains of several other working groups (e.g. multi6). So, even though we would to request that discussion not continue on the ipv6 mailing list, the chairs do not want to put a stop to anyone who wishes to continue the investigation. Therefore, we suggest that interested parties create a separate mailing list to discuss the topic of identifier and locator separation. If needed, the chairs can help arrange for the creation of an exploratory mailing list. Regards, Bob Hinden / Brian Haberman IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 10:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16319 for ; Tue, 23 Sep 2003 10:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oGw-0007gR-Us for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 10:36:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NEaA5Q029533 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 10:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oGw-0007gG-M1 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 10:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16283 for ; Tue, 23 Sep 2003 10:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oGu-0000dE-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 10:36:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1oGt-0000d9-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 10:36:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oFq-0007SV-FS; Tue, 23 Sep 2003 10:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oFd-0007S4-Ri for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 10:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16209 for ; Tue, 23 Sep 2003 10:34:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oFb-0000cI-00 for ipv6@ietf.org; Tue, 23 Sep 2003 10:34:47 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by ietf-mx with esmtp (Exim 4.12) id 1A1oFa-0000cF-00 for ipv6@ietf.org; Tue, 23 Sep 2003 10:34:46 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h8NEYhOS000563; Tue, 23 Sep 2003 16:34:43 +0200 (CEST) Date: Tue, 23 Sep 2003 16:34:40 +0200 Subject: Re: Note on id/loc separation discussion Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Brian Haberman From: Kurt Erik Lindqvist In-Reply-To: <3F704DDF.3050800@innovationslab.net> Message-Id: <107AF341-EDD3-11D7-82FF-000A95880ECC@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Therefore, we suggest that interested parties create a > separate mailing list to discuss the topic of identifier and > locator separation. If needed, the chairs can help arrange > for the creation of an exploratory mailing list. This _does_ touch upon some of the proposals made in multi6 and several people have asked if it is ok to discuss there. I have said yes before to these requests. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP3BaAqarNKXTPFCVEQKRrgCePX7X7De3CLSm8R7yv27VFgGsuSkAoIU5 K7Oc021rsDHndC3bhIhWxGkd =G42Q -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 10:43:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17222 for ; Tue, 23 Sep 2003 10:43:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oNJ-0000Rr-GG for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 10:42:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NEgjxr001717 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 10:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oNJ-0000Rc-AT for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 10:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17146 for ; Tue, 23 Sep 2003 10:42:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oNG-0000pv-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 10:42:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1oNG-0000ps-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 10:42:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oMb-0008Vj-1n; Tue, 23 Sep 2003 10:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oM4-0008NG-3G for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 10:41:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17023 for ; Tue, 23 Sep 2003 10:41:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oM1-0000nJ-00 for ipv6@ietf.org; Tue, 23 Sep 2003 10:41:25 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A1oM1-0000ls-00 for ipv6@ietf.org; Tue, 23 Sep 2003 10:41:25 -0400 Subject: RE: why market picked up NATs [Re: Write-ups on why RFC1918 is bad?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Sep 2003 07:40:53 -0700 Content-class: urn:content-classes:message Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: why market picked up NATs [Re: Write-ups on why RFC1918 is bad?] Thread-Index: AcOBzDk+RlNO3xODTMWcwBEAPrWlHQAFFAfQ From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: "Erik Nordmark" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Kurt Erik Lindqvist wrote: > Just out of curiosity, then why bother migrating to IPv6 > at all? What have you gained? Early presence on the market. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 13:09:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24807 for ; Tue, 23 Sep 2003 13:09:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qeq-0008GT-Nl for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 13:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NH90Sg031763 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 13:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qeq-0008GC-8h for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 13:09:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24747 for ; Tue, 23 Sep 2003 13:08:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qeo-0003Ga-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 13:08:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1qeo-0003GX-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 13:08:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qdu-00080O-Nl; Tue, 23 Sep 2003 13:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qdN-0007rR-Cm for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 13:07:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24658 for ; Tue, 23 Sep 2003 13:07:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qdL-0003F4-00 for ipv6@ietf.org; Tue, 23 Sep 2003 13:07:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1qdJ-0003EU-00 for ipv6@ietf.org; Tue, 23 Sep 2003 13:07:27 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2003 10:09:09 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8NH6kJu019808; Tue, 23 Sep 2003 10:06:52 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIJ73136; Tue, 23 Sep 2003 10:06:44 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA17486; Tue, 23 Sep 2003 10:06:44 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16240.32164.181705.470876@thomasm-u1.cisco.com> Date: Tue, 23 Sep 2003 10:06:44 -0700 (PDT) To: Keith Moore Cc: Michael Thomas , Erik.Nordmark@sun.com, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] In-Reply-To: <20030922223812.7b62d08c.moore@cs.utk.edu> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith Moore writes: > > From my SF-centric Nexus-of-the-web-trendiod > > standpoint: for residential use (especially with > > broadband) it is simply impossible to have an > > argument about the evils of NAT. > > that's the stupidest thing that's been said here in a long time. > > NATs are at least as harmful in a residential environment as in any other > environment. It's just that residential customers are slower to realize > the problems with NAT and they have less ability to get blocks of addresses > routed to them at reasonable prices than other customers. I have no idea what it is that you think you're arguing with because it is simply my observation having tried to get people to understand why their innocent cuddly NAT boxen are really wolves in sheep's clothing. How you derive "stupid" from that is beyond me as it's a complete non-sequitur unless a mere observation can now be assessed for its intelligence quotient. Mike -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 13:23:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25811 for ; Tue, 23 Sep 2003 13:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qsb-00012s-9q for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 13:23:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NHNDxf004017 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 13:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qsa-00012i-8B for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 13:23:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25756 for ; Tue, 23 Sep 2003 13:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qsY-0003aY-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 13:23:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1qsX-0003aV-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 13:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qsR-0000vA-9R; Tue, 23 Sep 2003 13:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dHy-0003jp-7T for ipv6@optimus.ietf.org; Mon, 22 Sep 2003 22:52:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04693 for ; Mon, 22 Sep 2003 22:52:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dHu-00042P-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:52:26 -0400 Received: from 198.cust3.nsw.dsl.ozemail.com.au ([203.103.158.198] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1A1dHt-0003yL-00 for ipv6@ietf.org; Mon, 22 Sep 2003 22:52:26 -0400 Received: from Dupy2.nosense.org (198.cust3.nsw.dsl.ozemail.com.au [203.103.158.198]) by nosense.org (Postfix) with SMTP id 075B23F024; Tue, 23 Sep 2003 12:22:29 +0930 (CST) Date: Tue, 23 Sep 2003 12:22:28 +0930 From: Mark Smith To: Keith Moore Cc: mat@cisco.com, moore@cs.utk.edu, Erik.Nordmark@sun.com, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030923122228.1f782a7d.mark@nosense.org> In-Reply-To: <20030922223812.7b62d08c.moore@cs.utk.edu> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-SCO-IP-Status: None detected, but FUD campaign will continue. X-message-flag: Microsoft Exchange V6.0.5762.3 status message #3885.86 - Delivery of this email was delayed, possibly due to static from nylon underware. Reply-By: Tue, 24 Jul 2000 19:02:00 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As a datapoint, it might be worth reading the comments posted to slashdot relating to this story End Of the Line for SpeakFreely: NATed to Death http://slashdot.org/article.pl?sid=03/09/20/1556253&mode=thread&tid=126&tid=185&tid=95 (And yes, I got sucked into it, and ended up looking like I'd just stepped out of my spaceship) On Mon, 22 Sep 2003 22:38:12 -0400 Keith Moore wrote: > > From my SF-centric Nexus-of-the-web-trendiod > > standpoint: for residential use (especially with > > broadband) it is simply impossible to have an > > argument about the evils of NAT. > > that's the stupidest thing that's been said here in a long time. > > NATs are at least as harmful in a residential environment as in any other > environment. It's just that residential customers are slower to realize > the problems with NAT and they have less ability to get blocks of addresses > routed to them at reasonable prices than other customers. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 16:04:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04280 for ; Tue, 23 Sep 2003 16:04:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tO9-0002Jd-38 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 16:03:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NK3vUF008895 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 16:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tO8-0002JO-Tc for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 16:03:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04245 for ; Tue, 23 Sep 2003 16:03:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1tO7-0005zC-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 16:03:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1tO6-0005z9-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 16:03:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tMJ-0001zh-2h; Tue, 23 Sep 2003 16:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tM1-0001z9-Ky for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 16:01:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04154 for ; Tue, 23 Sep 2003 16:01:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1tLz-0005x4-00 for ipv6@ietf.org; Tue, 23 Sep 2003 16:01:43 -0400 Received: from mr200a.caspiannetworks.com ([63.108.173.139] helo=cmail.caspian.com) by ietf-mx with esmtp (Exim 4.12) id 1A1tLz-0005wi-00 for ipv6@ietf.org; Tue, 23 Sep 2003 16:01:43 -0400 Received: from innovationslab.net ([172.17.55.3]) by cmail.caspian.com (Mirapoint Messaging Server MOS 3.2.4-GA) with ESMTP id AIQ28317; Tue, 23 Sep 2003 13:01:07 -0700 (PDT) Message-ID: <3F70A682.9060908@innovationslab.net> Date: Tue, 23 Sep 2003 16:01:06 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Updates to Neighbor Discovery and Stateless Autoconfiguration Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, One of our charter items is to produce updates of RFC 2461 and 2462 in order to progress them to Draft Standard. As a part of that effort, I would like to bring to the Work Group's attention, some work that has been done in SEND. http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-03.txt outlines several security issues that exist in NDP and in Stateless Autonconfiguration. So as a part of the effort to revise 2461 and 2462, I am soliciting the WG's thoughts on how to incorporate the work done in the SEND document into the base specifications. My primary goal is to come to a balance of existing functionality vs. enhanced security capability. So, I encourage people to read the document and comment on their applicability to the pending updates. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 16:46:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06121 for ; Tue, 23 Sep 2003 16:46:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1u2e-0005Gh-4n for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 16:45:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NKjmYA020245 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 16:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1u2d-0005GS-S6 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 16:45:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06061 for ; Tue, 23 Sep 2003 16:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1u2b-0006bp-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 16:45:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1u2b-0006bm-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 16:45:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1u1v-0004sr-3E; Tue, 23 Sep 2003 16:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1u19-0004iE-Nu for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 16:44:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06029 for ; Tue, 23 Sep 2003 16:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1u17-0006ar-00 for ipv6@ietf.org; Tue, 23 Sep 2003 16:44:13 -0400 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 1A1u17-0006aU-00 for ipv6@ietf.org; Tue, 23 Sep 2003 16:44:13 -0400 Received: from ala-mrwtemp.windriver.com ([147.11.233.26]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA22996; Tue, 23 Sep 2003 13:43:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20030923163942.040171f8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Sep 2003 16:41:16 -0400 To: Kurt Erik Lindqvist From: Margaret Wasserman Subject: Re: comments on deprecate-site-local-00 Cc: Pekka Savola , Brian E Carpenter , ipv6@ietf.org In-Reply-To: <30D55E52-ED93-11D7-8F55-000A95880ECC@kurtis.pp.se> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 08:57 AM 9/23/2003 +0200, Kurt Erik Lindqvist wrote: > > True, but if we wish to remain relevant, something has to be written > > somewhere. I fully agree that doing so in *this* document may not be > > worth it; it might be worth it in some other doc, e.g. sl-impact. > >I agree with Pekka. HAving this in writing somewhere is important. I'd be happy to dust off my sl-impact draft, and update it based on the feedback I've received so far, if folks think that would be useful... Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 19:06:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12386 for ; Tue, 23 Sep 2003 19:06:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wEU-0004gc-7v for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 19:06:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NN6A3c018013 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 19:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wEU-0004gS-35 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 19:06:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12341 for ; Tue, 23 Sep 2003 19:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1wEQ-0000Xw-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 19:06:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1wEQ-0000Xt-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 19:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wDP-0004Sh-6K; Tue, 23 Sep 2003 19:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wCz-0004Rz-FA for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 19:04:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12307 for ; Tue, 23 Sep 2003 19:04:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1wCv-0000X9-00 for ipv6@ietf.org; Tue, 23 Sep 2003 19:04:34 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A1wCv-0000X6-00 for ipv6@ietf.org; Tue, 23 Sep 2003 19:04:33 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 85893140B6; Tue, 23 Sep 2003 19:04:31 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02300-05; Tue, 23 Sep 2003 19:04:31 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id F05D813FED; Tue, 23 Sep 2003 19:04:30 -0400 (EDT) Date: Tue, 23 Sep 2003 19:04:25 -0400 From: Keith Moore To: Michael Thomas Cc: moore@cs.utk.edu, mat@cisco.com, Erik.Nordmark@sun.com, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030923190425.14581579.moore@cs.utk.edu> In-Reply-To: <16240.32164.181705.470876@thomasm-u1.cisco.com> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Keith Moore writes: > > > From my SF-centric Nexus-of-the-web-trendiod > > > standpoint: for residential use (especially with > > > broadband) it is simply impossible to have an > > > argument about the evils of NAT. > > > > that's the stupidest thing that's been said here in a long time. > > > > NATs are at least as harmful in a residential environment as in any > > other environment. It's just that residential customers are slower > > to realize the problems with NAT and they have less ability to get > > blocks of addresses routed to them at reasonable prices than other > > customers. > > I have no idea what it is that you think you're > arguing with because it is simply my observation > having tried to get people to understand why their > innocent cuddly NAT boxen are really wolves in > sheep's clothing. How you derive "stupid" from > that is beyond me as it's a complete non-sequitur > unless a mere observation can now be assessed for > its intelligence quotient. Sorry, I must have taken that statement in a different way than was intended. I have also seen that it's difficult to convince people that their NATs cause problems. The people I've talked to fall into two categories: 1. Those who are technically savvy enough to be aware of the limitations of NAT. These people are usually also savvy enough to work around those limitations for small-scale use, but they might have to deal with some annoying restriction or another - e.g. having to run certain apps on one particular machine. They don't see NAT as the problem - they see NAT as an imperfect workaround for the inability to get multiple addresses routed to their home net at a reasonable price. (some of these people think that NAT has a security benefit, so a bit of education would still help.) 2. Those who aren't technically savvy enough to be aware of NAT's limitations. To those people, NAT is how you hook up multiple computers to the net - they are probably not even aware that there is such a thing as address translation going on. And if any apps don't work in that environment, it must be the app vendor's fault - after all, everyone else's network works just like theirs, right? Most of the people in group 1 can be convinced, with some effort, that the workarounds they use for NAT's limitations don't scale well to ordinary users, and that the widespread deployment of NAT limits the ability to deploy certain kinds of applications. The people in group 2 (i.e. the vast majority) are hopeless, because they don't realize that the Internet has the potential to provide any more services than email, the web, and IM. (anything that AOL doesn't provide doesn't exist) So I'd say that it certainly is possible to have an informed argument about the evils of NAT for residential use, what is difficult is to have a useful discussion about NAT with the typical residential user. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 21:35:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17263 for ; Tue, 23 Sep 2003 21:35:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yYP-0003fI-2G for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 21:34:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O1YrRt014087 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 21:34:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yYO-0003f8-TJ for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 21:34:52 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17237 for ; Tue, 23 Sep 2003 21:34:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yWc-0003Bw-6o; Tue, 23 Sep 2003 21:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yVj-0003A9-OP for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 21:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17092 for ; Tue, 23 Sep 2003 21:31:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yVg-0002AX-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:32:04 -0400 Received: from x1-6-00-0c-e5-0a-3e-77.k33.webspeed.dk ([195.41.29.4] helo=ursa.amorsen.dk) by ietf-mx with esmtp (Exim 4.12) id 1A1yVg-00029n-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:32:04 -0400 Received: from vega.amorsen.dk (vega.amorsen.dk [172.31.4.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id D434A1C160; Wed, 24 Sep 2003 03:31:25 +0200 (CEST) Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] From: Benny Amorsen To: Keith Moore Cc: Michael Thomas , Erik.Nordmark@sun.com, pekkas@netcore.fi, ipv6@ietf.org In-Reply-To: <20030923190425.14581579.moore@cs.utk.edu> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> Content-Type: text/plain Message-Id: <1064367082.27238.15.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-7) Date: Wed, 24 Sep 2003 03:31:23 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One thing that has not been mentioned so far in the discussion is that NAT is empowering many users. It allows them to share connectivity, working around draconian policies imposed on them by outside entities such as ISP's. With NAT, any single address can now give access to a whole network, and it can even happen recursively. No need to ask anyone for extra addresses, no need to play with routing tables or proxy arp... Of course there are a few applications that do not work in this setup, but those applications are by far in the minority - and therefore those applications are blamed for any problems. Most applications either just work or have implemented workarounds for NAT. With IPv6 you get some of that flexibility, but not all of it. Sure, each user hopefully gets a /48 assigned by their ISP, but if they want to partition a bit of it out to their neighbour, they need to learn about routing... An IPv4 NAT box just grabs an address with DHCP and in turn serves out addresses to others. In order to reach the same ease of configuration, it would be necessary to make a routing protocol where a router could ask its upstream to be assigned a /64. The upstream would pass the request on, until the request is granted by the router which was given a /48. Is anything like that possible today? /Benny -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 21:45:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17844 for ; Tue, 23 Sep 2003 21:45:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yhu-0004oN-HV for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 21:44:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O1igiT018491 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 21:44:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yhu-0004oA-Bw for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 21:44:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17803 for ; Tue, 23 Sep 2003 21:44:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yhr-0002Nv-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 21:44:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1yhr-0002Ns-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 21:44:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yhG-0004Rf-3a; Tue, 23 Sep 2003 21:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yh6-0004RN-R7 for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 21:43:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17772 for ; Tue, 23 Sep 2003 21:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yh3-0002Mr-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:43:49 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A1yh3-0002Mo-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:43:49 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3637E14039; Tue, 23 Sep 2003 21:43:50 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17863-01; Tue, 23 Sep 2003 21:43:49 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id BB00F14014; Tue, 23 Sep 2003 21:43:48 -0400 (EDT) Date: Tue, 23 Sep 2003 21:40:02 -0400 From: Keith Moore To: Benny Amorsen Cc: moore@cs.utk.edu, mat@cisco.com, Erik.Nordmark@sun.com, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030923214002.1ca0fdec.moore@cs.utk.edu> In-Reply-To: <1064367082.27238.15.camel@vega.amorsen.dk> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> <1064367082.27238.15.camel@vega.amorsen.dk> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 24 Sep 2003 03:31:23 +0200 Benny Amorsen wrote: > One thing that has not been mentioned so far in the discussion is that > NAT is empowering many users. It allows them to share connectivity, > working around draconian policies imposed on them by outside entities > such as ISP's. With NAT, any single address can now give access to a > whole network, and it can even happen recursively. No need to ask anyone > for extra addresses, no need to play with routing tables or proxy arp... > > Of course there are a few applications that do not work in this setup, > but those applications are by far in the minority - and therefore those > applications are blamed for any problems. Most applications either just > work or have implemented workarounds for NAT. the problem with that statement is that the set of "most" applications is different in the presence of NAT than it would have been in the absence of NAT. your statement is true for "most" applications partially because the applications that would have worked without NAT have been denied a significant portion of the market. but I strongly agree that autoconfiguration of routers (including the ability of a router to ask its upstream routers for a /64 prefix) is a significant missing piece for IPv6. IMHO we need to compile a list of these pieces and start working on them. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 21:52:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18110 for ; Tue, 23 Sep 2003 21:52:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yow-0005Js-Q1 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 21:52:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O1pwOK020442 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 21:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yow-0005Jd-Ks for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 21:51:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18067 for ; Tue, 23 Sep 2003 21:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yot-0002TW-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 21:51:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1yot-0002TR-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 21:51:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yo1-0004zp-HD; Tue, 23 Sep 2003 21:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ynZ-0004zQ-IW for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 21:50:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18028 for ; Tue, 23 Sep 2003 21:50:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1ynW-0002SG-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:50:30 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1ynW-0002S5-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:50:30 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2003 18:47:53 -0700 Received: from cisco.com (sjc-vpn3-113.cisco.com [10.21.64.113]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8O1nwxW012658; Tue, 23 Sep 2003 18:49:59 -0700 (PDT) Message-ID: <3F70F845.3010005@cisco.com> Date: Tue, 23 Sep 2003 18:49:57 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> <1064367082.27238.15.camel@vega.amorsen.dk> <20030923214002.1ca0fdec.moore@cs.utk.edu> In-Reply-To: <20030923214002.1ca0fdec.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith Moore wrote: > but I strongly agree that autoconfiguration of routers (including the > ability of a router to ask its upstream routers for a /64 prefix) is > a significant missing piece for IPv6. Why is this "missing"? Isn't this what prefix-delegation does? Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 22:18:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18896 for ; Tue, 23 Sep 2003 22:18:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zDw-0006iv-QR for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:17:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O2Hm9T025839 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:17:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zDw-0006ig-E5 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 22:17:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18861 for ; Tue, 23 Sep 2003 22:17:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zDt-0002kn-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:17:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1zDs-0002kk-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:17:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zDB-0006OS-W1; Tue, 23 Sep 2003 22:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zCh-0006Ns-3u for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 22:16:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18836 for ; Tue, 23 Sep 2003 22:16:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zCd-0002k9-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:16:27 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A1zCd-0002k6-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:16:27 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8B73914088; Tue, 23 Sep 2003 22:16:28 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21022-07; Tue, 23 Sep 2003 22:16:28 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 80F0013FFD; Tue, 23 Sep 2003 22:16:27 -0400 (EDT) Date: Tue, 23 Sep 2003 22:12:41 -0400 From: Keith Moore To: Eliot Lear Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030923221241.3a2581c3.moore@cs.utk.edu> In-Reply-To: <3F70F845.3010005@cisco.com> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> <1064367082.27238.15.camel@vega.amorsen.dk> <20030923214002.1ca0fdec.moore@cs.utk.edu> <3F70F845.3010005@cisco.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > but I strongly agree that autoconfiguration of routers (including the > > ability of a router to ask its upstream routers for a /64 prefix) is > > a significant missing piece for IPv6. > > Why is this "missing"? Isn't this what prefix-delegation does? maybe I'm the one missing something. where is the protocol for this defined? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 22:33:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19600 for ; Tue, 23 Sep 2003 22:33:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zSU-0007qz-UK for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:32:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O2Wowu030183 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zSU-0007qV-P7 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 22:32:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19537 for ; Tue, 23 Sep 2003 22:32:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zSR-0002zF-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:32:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1zSQ-0002z8-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:32:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zRh-0007Pa-Hu; Tue, 23 Sep 2003 22:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zQp-0007OV-KO for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 22:31:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19428 for ; Tue, 23 Sep 2003 22:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zQm-0002xN-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:31:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1zQl-0002wv-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:31:03 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2003 19:32:59 -0700 Received: from cisco.com (sjc-vpn3-113.cisco.com [10.21.64.113]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8O2UWYb013016; Tue, 23 Sep 2003 19:30:32 -0700 (PDT) Message-ID: <3F7101C8.2090601@cisco.com> Date: Tue, 23 Sep 2003 19:30:32 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> <1064367082.27238.15.camel@vega.amorsen.dk> <20030923214002.1ca0fdec.moore@cs.utk.edu> <3F70F845.3010005@cisco.com> <20030923221241.3a2581c3.moore@cs.utk.edu> In-Reply-To: <20030923221241.3a2581c3.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith Moore wrote: > maybe I'm the one missing something. where is the protocol for this defined? draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 22:33:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19599 for ; Tue, 23 Sep 2003 22:33:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zSU-0007qf-RC for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:32:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O2Woh0030168 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zSU-0007qU-M1 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 22:32:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19535 for ; Tue, 23 Sep 2003 22:32:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zSR-0002zC-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:32:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1zSQ-0002z7-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:32:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zRj-0007QC-3L; Tue, 23 Sep 2003 22:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zQp-0007Oa-Vg for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 22:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19431 for ; Tue, 23 Sep 2003 22:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zQm-0002xQ-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:31:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1zQm-0002wv-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:31:04 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2003 19:33:02 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8O2UZxW000438; Tue, 23 Sep 2003 19:30:35 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-40.cisco.com [10.82.240.40]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACQ06439; Tue, 23 Sep 2003 22:30:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20030923222954.044e3b30@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Sep 2003 22:30:31 -0400 To: Keith Moore From: Ralph Droms Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Cc: Eliot Lear , moore@cs.utk.edu, ipv6@ietf.org In-Reply-To: <20030923221241.3a2581c3.moore@cs.utk.edu> References: <3F70F845.3010005@cisco.com> <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> <1064367082.27238.15.camel@vega.amorsen.dk> <20030923214002.1ca0fdec.moore@cs.utk.edu> <3F70F845.3010005@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt The doc has been sent to the IESG for publication. - Ralph At 10:12 PM 9/23/2003 -0400, Keith Moore wrote: > > > but I strongly agree that autoconfiguration of routers (including the > > > ability of a router to ask its upstream routers for a /64 prefix) is > > > a significant missing piece for IPv6. > > > > Why is this "missing"? Isn't this what prefix-delegation does? > >maybe I'm the one missing something. where is the protocol for this defined? > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 23 22:43:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20054 for ; Tue, 23 Sep 2003 22:43:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zbx-0000Pi-Fr for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:42:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O2gb2r001591 for ipv6-archive@odin.ietf.org; Tue, 23 Sep 2003 22:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zbx-0000Pa-9W for ipv6-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 22:42:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20027 for ; Tue, 23 Sep 2003 22:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zbt-000387-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:42:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1zbt-000384-00 for ipv6-web-archive@ietf.org; Tue, 23 Sep 2003 22:42:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zaP-000094-R4; Tue, 23 Sep 2003 22:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zaG-00008j-Q6 for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 22:40:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19911 for ; Tue, 23 Sep 2003 22:40:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zaD-00035Z-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:40:49 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1zaC-00035P-00 for ipv6@ietf.org; Tue, 23 Sep 2003 22:40:49 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2003 19:38:12 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8O2eGYb017697; Tue, 23 Sep 2003 19:40:17 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-40.cisco.com [10.82.240.40]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACQ06724; Tue, 23 Sep 2003 22:40:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20030923223117.0453b0b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Sep 2003 22:40:11 -0400 To: Benny Amorsen From: Ralph Droms Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Cc: Keith Moore , Michael Thomas , Erik.Nordmark@sun.com, pekkas@netcore.fi, ipv6@ietf.org In-Reply-To: <1064367082.27238.15.camel@vega.amorsen.dk> References: <20030923190425.14581579.moore@cs.utk.edu> <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , DHCPv6 prefix delegation, draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt, provides this capability. Interoperability among several implementations has been demonstrated at TAHI and Connectathon. - Ralph At 03:31 AM 9/24/2003 +0200, Benny Amorsen wrote: >In order to reach the same ease of configuration, it would be necessary >to make a routing protocol where a router could ask its upstream to be >assigned a /64. The upstream would pass the request on, until the >request is granted by the router which was given a /48. Is anything like >that possible today? > > >/Benny > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 00:07:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23849 for ; Wed, 24 Sep 2003 00:07:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A20w9-00055P-7M for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 00:07:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O47W4Z019537 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 00:07:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A20w8-00054u-42 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 00:07:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23807 for ; Wed, 24 Sep 2003 00:07:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A20w5-0004H6-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 00:07:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A20w5-0004H3-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 00:07:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A20vf-0004pz-3X; Wed, 24 Sep 2003 00:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A20un-0004pA-5f for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 00:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23774 for ; Wed, 24 Sep 2003 00:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A20uk-0004GY-00 for ipv6@ietf.org; Wed, 24 Sep 2003 00:06:06 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A20uh-0004GN-00 for ipv6@ietf.org; Wed, 24 Sep 2003 00:06:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8O44G605459; Wed, 24 Sep 2003 07:04:16 +0300 Date: Wed, 24 Sep 2003 07:04:15 +0300 (EEST) From: Pekka Savola To: Keith Moore cc: Benny Amorsen , , , Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] In-Reply-To: <20030923214002.1ca0fdec.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 23 Sep 2003, Keith Moore wrote: > Benny Amorsen wrote: > > One thing that has not been mentioned so far in the discussion is that > > NAT is empowering many users. It allows them to share connectivity, > > working around draconian policies imposed on them by outside entities > > such as ISP's. With NAT, any single address can now give access to a > > whole network, and it can even happen recursively. No need to ask anyone > > for extra addresses, no need to play with routing tables or proxy arp... [...] > but I strongly agree that autoconfiguration of routers (including the > ability of a router to ask its upstream routers for a /64 prefix) is > a significant missing piece for IPv6. .. IMHO, that may be too "technological" way to solve the problem (of course, we still need it, but I'm arguing that we may very well need something else too!). Very likely this calls for the limited form of Bridge-like ND-proxies, or something. That's how you can extend your network like magic (provided the ISP gives you at least /64), without having to configure anything. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 01:50:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28199 for ; Wed, 24 Sep 2003 01:50:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22Ww-0001EJ-Ck for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 01:49:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O5ncOY004721 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 01:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22Ww-0001E4-5i for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 01:49:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28160 for ; Wed, 24 Sep 2003 01:49:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A22Ws-0005aU-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 01:49:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A22Ws-0005aR-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 01:49:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22WM-00017t-0C; Wed, 24 Sep 2003 01:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22Vp-00017U-4P for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 01:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28131 for ; Wed, 24 Sep 2003 01:48:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A22Vl-0005Zu-00 for ipv6@ietf.org; Wed, 24 Sep 2003 01:48:25 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A22Vl-0005Zb-00 for ipv6@ietf.org; Wed, 24 Sep 2003 01:48:25 -0400 Subject: RE: Note on id/loc separation discussion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Sep 2003 22:47:54 -0700 Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: Note on id/loc separation discussion Thread-Index: AcOB55PBFPAviDjmQUerC71a2pIL1gAc1whg From: "Michel Py" To: "Brian Haberman" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Brian, > Brian Haberman wrote: > [separating the Identifier and Locator aspects of IP addresses.] > even though we would to request that discussion not continue on > the ipv6 mailing list, the chairs do not want to put a stop to > anyone who wishes to continue the investigation. IMHO this is a purely academic exercise. Very interesting, but unlikely to produce concrete results, as the opinions and arguments WRT the issue are heavily tied to the proposed solution. For example, I am completely with Pekka Nikander when recommending id/loc separation as applied to HIP (I would do the same); however, in the case of MHAP we are currently discussing the opposite side which is that the identifier could be one of the locators. This is not all black or white. > Therefore, we suggest that interested parties create a > separate mailing list to discuss the topic of identifier > and locator separation. I have moved this thread to the MHAP list; although I do not expect changes to MHAP WRT the issue it is on-topic there. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 01:58:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28785 for ; Wed, 24 Sep 2003 01:58:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22fB-0001l5-1O for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 01:58:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O5w8YP006756 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 01:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22fA-0001kt-NT for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 01:58:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28746 for ; Wed, 24 Sep 2003 01:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A22f7-0005mX-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 01:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A22f6-0005mU-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 01:58:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22f3-0001db-SW; Wed, 24 Sep 2003 01:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A22eo-0001d7-Sv for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 01:57:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28735 for ; Wed, 24 Sep 2003 01:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A22el-0005mB-00 for ipv6@ietf.org; Wed, 24 Sep 2003 01:57:43 -0400 Received: from 198.cust3.nsw.dsl.ozemail.com.au ([203.103.158.198] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1A22ek-0005le-00 for ipv6@ietf.org; Wed, 24 Sep 2003 01:57:42 -0400 Received: from Dupy2.nosense.org (198.cust3.nsw.dsl.ozemail.com.au [203.103.158.198]) by nosense.org (Postfix) with SMTP id 5796B3F024; Wed, 24 Sep 2003 15:27:54 +0930 (CST) Date: Wed, 24 Sep 2003 15:27:53 +0930 From: Mark Smith To: Pekka Savola Cc: moore@cs.utk.edu, benny+nospam@amorsen.dk, mat@cisco.com, Erik.Nordmark@sun.com, ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030924152753.6ef8ce0b.ipv6@nosense.org> In-Reply-To: References: <20030923214002.1ca0fdec.moore@cs.utk.edu> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't think it has been mentioned as a reason why NAT took off, but the other thing that may need to be provided is the "default "security" with no configuration" that these end users believe these NATting (or NATting + firewall) products provide. Of course, tight default security policies also provide similar limitations that NAT does when it comes to new killer apps becoming available and popular on the Internet - the non-technological user doesn't know how to turn off security for that application (ie. open up a port), or doesn't know how to turn it off safely. Mark. On Wed, 24 Sep 2003 07:04:15 +0300 (EEST) Pekka Savola wrote: > On Tue, 23 Sep 2003, Keith Moore wrote: > > Benny Amorsen wrote: > > > One thing that has not been mentioned so far in the discussion is that > > > NAT is empowering many users. It allows them to share connectivity, > > > working around draconian policies imposed on them by outside entities > > > such as ISP's. With NAT, any single address can now give access to a > > > whole network, and it can even happen recursively. No need to ask anyone > > > for extra addresses, no need to play with routing tables or proxy arp... > [...] > > but I strongly agree that autoconfiguration of routers (including the > > ability of a router to ask its upstream routers for a /64 prefix) is > > a significant missing piece for IPv6. > > .. IMHO, that may be too "technological" way to solve the problem (of > course, we still need it, but I'm arguing that we may very well need > something else too!). Very likely this calls for the limited form of > Bridge-like ND-proxies, or something. That's how you can extend your > network like magic (provided the ISP gives you at least /64), without > having to configure anything. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 03:22:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28430 for ; Wed, 24 Sep 2003 03:22:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23yE-000195-Ck for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 03:21:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7Lsuj004397 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 03:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23yD-00018p-Kp for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 03:21:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28397 for ; Wed, 24 Sep 2003 03:21:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A23yB-0006ty-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 03:21:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A23yA-0006tt-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 03:21:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23xP-0000pN-Vc; Wed, 24 Sep 2003 03:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23wR-0000o3-R5 for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 03:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28341 for ; Wed, 24 Sep 2003 03:19:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A23wP-0006sf-00 for ipv6@ietf.org; Wed, 24 Sep 2003 03:20:01 -0400 Received: from n2.nomadiclab.com ([131.160.193.2]) by ietf-mx with esmtp (Exim 4.12) id 1A23wO-0006sL-00 for ipv6@ietf.org; Wed, 24 Sep 2003 03:20:00 -0400 Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 3CC9ECBA54; Wed, 24 Sep 2003 10:19:25 +0300 (EEST) Received: from nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id B0260113E2E; Wed, 24 Sep 2003 10:19:24 +0300 (EEST) Message-ID: <3F707F7A.3000702@nomadiclab.com> Date: Tue, 23 Sep 2003 19:14:34 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: IPV6 WG , hipsec@honor.trusecure.com Subject: Re: What end-point identifiers are needed for? References: <3F66A227.6050809@nomadiclab.com> <20030916100222.44a7fa95.moore@cs.utk.edu> In-Reply-To: <20030916100222.44a7fa95.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, [Sorry for late reply.] >> 2) Referral >> For referral to succeed, the transferred information must give >> the receiving end-point >> >> - a means to identify the second end-point (1b) >> - a means to reach the second end-point >> >> Note that in this case the "means to reach" does not need >> to be a locator. It can be a name that the rendezvous (3b) >> service is able to convert to a locator. > > right. it's just like what you were calling 3b except with the added > constraint that the identifiers need to have the same meaning and be > resolvable to locators from any point in the network. Thanks for this clarification. It made my thinking more crystal. >> 1a) To me, identification for mobility and multi-homing seems to >> be the easiest one. There we are only interested in gaining >> assurance that the peer remains the same. That is, for the >> sole purpose of mobility or multi-homing, we do not really >> care with whom we are communicating with, but only that the >> peer end-point is not changed in mid-communication due to >> mobility, multi-homing, or attacks based on mobility or >> multi-homing mechanisms. >> >> For the purposes of 1a) it seems to be sufficient to create >> an ephemeral identifier, only known to the participating end-points >> (and a sufficiently limited class of potential attackers). >> There is no need for long-lasting stable identifiers. > > disagree. the problem is that you don't always know how many participating > end points there will be. and an application - especially one that encompasses > large numbers of hosts - can run indefinitely, meaning that the identifiers > may need to last indefinitely. Well, I think that you are slightly mixing things here. While I agree with you than in most real life situations you most probably would not be done with ephemeral identifiers, the reason for that is that such situations involve other needs but pure mobility or multi-homing (multi-addressing in Dave Croker's terminology). ' If your application encompasses more than two hosts, either they talk pairwise (in which case my statement holds), or they make referrals (in which case the reason for identification is not pure mobility or multi-homing any more). If your application encompasses only two hosts, but lasts "indefinitely", then the "ephemeral" identifier can last "indefinitely". If picked from a large enough space, the chance of collisions is still neglible enough. (We have to remember that "indefinitely" in our field appears to be around 50 years, at most 200 I guess.) Besides, if you application runs that long, then you most probably also need occasional rendezvous, again imposing other reasons (and other requirements) for identification but pure mobility and multi-homing. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 03:37:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29037 for ; Wed, 24 Sep 2003 03:37:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24D5-0001pI-Dy for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 03:37:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7bF3K007014 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 03:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24D2-0001p3-C9 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 03:37:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29009 for ; Wed, 24 Sep 2003 03:37:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24Cz-00075f-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 03:37:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A24Cz-00075c-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 03:37:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24Ct-0001iB-3s; Wed, 24 Sep 2003 03:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24CQ-0001hL-Uw for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 03:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28997 for ; Wed, 24 Sep 2003 03:36:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24CC-00075I-00 for ipv6@ietf.org; Wed, 24 Sep 2003 03:36:20 -0400 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A24CB-00074x-00 for ipv6@ietf.org; Wed, 24 Sep 2003 03:36:19 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h8O7Zmo0094112; Wed, 24 Sep 2003 09:35:48 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8O7ZlZ7089600; Wed, 24 Sep 2003 09:35:47 +0200 Received: from zurich.ibm.com (gsine10.us.sine.ibm.com [9.14.6.40]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id JAA51064; Wed, 24 Sep 2003 09:35:44 +0200 Message-ID: <3F71493C.D287FB6@zurich.ibm.com> Date: Wed, 24 Sep 2003 09:35:24 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Margaret Wasserman CC: Kurt Erik Lindqvist , Pekka Savola , ipv6@ietf.org Subject: Re: comments on deprecate-site-local-00 References: <5.1.0.14.2.20030923163942.040171f8@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I definitely think so. I think it's better if the deprecation document, which is a standards action, stays mean and lean so that it can be read in 5 minutes, with the full details of the issues being Informational. Brian Margaret Wasserman wrote: > > At 08:57 AM 9/23/2003 +0200, Kurt Erik Lindqvist wrote: > > > True, but if we wish to remain relevant, something has to be written > > > somewhere. I fully agree that doing so in *this* document may not be > > > worth it; it might be worth it in some other doc, e.g. sl-impact. > > > >I agree with Pekka. HAving this in writing somewhere is important. > > I'd be happy to dust off my sl-impact draft, and update it based > on the feedback I've received so far, if folks think that would be > useful... > > Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 05:16:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03463 for ; Wed, 24 Sep 2003 05:16:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25kV-0008Q0-Hc for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 05:15:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O9FptQ032356 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 05:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25kV-0008Pn-CZ for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 05:15:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03423 for ; Wed, 24 Sep 2003 05:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A25kR-0000fs-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 05:15:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A25kR-0000fp-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 05:15:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25jj-0008Bp-VC; Wed, 24 Sep 2003 05:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25jF-0008Av-Em for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 05:14:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03366 for ; Wed, 24 Sep 2003 05:14:25 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A25jB-0000eP-00 for ipv6@ietf.org; Wed, 24 Sep 2003 05:14:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A25jB-0000eI-00 for ipv6@ietf.org; Wed, 24 Sep 2003 05:14:29 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8O9EE623429 for ; Wed, 24 Sep 2003 12:14:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 12:14:14 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 12:14:13 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 12:14:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Mobility text in node reqts (Was: AD review of draft-ietf-ipv6-node-requirements-05.txt) Date: Wed, 24 Sep 2003 12:14:12 +0300 Message-ID: Thread-Topic: Mobility text in node reqts (Was: AD review of draft-ietf-ipv6-node-requirements-05.txt) Thread-Index: AcNyDbzpPCbHLV2EQAKgL7swtVgA4gQblWRQ To: Cc: , X-OriginalArrivalTime: 24 Sep 2003 09:14:12.0822 (UTC) FILETIME=[3846B760:01C3827C] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I think Jari's text looks right, I have added it to the issues list as Issue17: Mobility text changes. I am going to make the changes, as long as noone objects. br, John > > And include a normative reference to the document. > >=20 > >=20 > >>7.2 Securing Signaling between Mobile Nodes and Home Agents > >> > >> The security mechanisms described in [MIPv6-HASEC] MUST=20 > be supported > >> by nodes implementing mobile node or home agent functionality > >> specified in Mobile IP [MIPv6]. > >=20 > >=20 > > So would presumably the applicable parts of Section 8 of the mipv6 > > spec. Better to cite them explicitely. > >=20 > >=20 > >> Generic Packet Tunneling [RFC-2473] MUST be supported for nodes > >> implementing mobile node functionality or Home Agent=20 > functionality of > >> Mobile IP [MIPv6]. > >=20 > >=20 > > This may not need mentioning, as it may already be covered=20 > in Section > > 8 of the mipv6 spec. >=20 > Hmm... is node requirements a list of all specs needed for IPv6, or > a list of specs which together with their normative refs are needed? > This hasn't been very clear. >=20 > My take is that we should list all IPv6 specifications, but=20 > we can leave > out some generic normative references, 2119 et al. >=20 > > Actually, this entire section may warrant rethinking given the > > existance of Section 8 in the MIPv6 spec. >=20 > The [MIPv6-HASEC] reference is in Section 8 (though indirectly). > But per above, I'd rather keep all clearly IPv6-specific documents > listed in the node requirements document. >=20 > Here's a suggested reformulation. Keep in mind that while the > Mobile IPv6 specification says what is required for a mobile > node, it does not have a keyword which states when such > functionality is needed. This is why the keywords > in the below text are important. >=20 > 7. Mobile IP >=20 > The Mobile IPv6 [MIPv6] specification defines requirements for the > following types of nodes: >=20 > - mobile nodes > - correspondent nodes with support for route optimization > - home agents > - all IPv6 routers >=20 > Hosts MAY support mobile node functionality described in > Section 8.5 of [MIPv6], including support of generic packet > tunneling [RFC-2473] and secure home agent communications > [MIPv6-HASEC]. >=20 > Hosts SHOULD support route optimization requirements for > correspondent nodes described in Section 8.2 of [MIPv6]. >=20 > Routers SHOULD support the generic mobility-related > requirements for all IPv6 routers described in Section 8.3 > of [MIPv6]. Routers MAY support the home agent functionality > described in Section 8.4 of [MIPv6], including support of > [RFC-2473] and [MIPv6-HASEC]. >=20 > --Jari >=20 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 05:42:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04114 for ; Wed, 24 Sep 2003 05:42:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26A5-0001aV-5e for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 05:42:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O9gHWJ006097 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 05:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26A4-0001aG-Vz for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 05:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04088 for ; Wed, 24 Sep 2003 05:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A26A1-0000uN-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 05:42:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A26A0-0000uK-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 05:42:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A269q-0001UR-4d; Wed, 24 Sep 2003 05:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A268u-0001Tc-7l for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 05:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04063 for ; Wed, 24 Sep 2003 05:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A268q-0000tq-00 for ipv6@ietf.org; Wed, 24 Sep 2003 05:41:00 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1A268p-0000tm-00 for ipv6@ietf.org; Wed, 24 Sep 2003 05:40:59 -0400 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA15642 for ; Wed, 24 Sep 2003 10:40:59 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA20617 for ; Wed, 24 Sep 2003 10:40:59 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h8O9exx26425 for ipv6@ietf.org; Wed, 24 Sep 2003 10:40:59 +0100 Date: Wed, 24 Sep 2003 10:40:59 +0100 From: Tim Chown To: ipv6@ietf.org Subject: Re: comments on deprecate-site-local-00 Message-ID: <20030924094059.GP25709@login.ecs.soton.ac.uk> References: <5.1.0.14.2.20030923163942.040171f8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030923163942.040171f8@mail.windriver.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Sep 23, 2003 at 04:41:16PM -0400, Margaret Wasserman wrote: > > I'd be happy to dust off my sl-impact draft, and update it based > on the feedback I've received so far, if folks think that would be > useful... Please. It's excellent to have the issues in one place (other than embdedded in a few hundred mails in the list archive :). Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 06:00:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04813 for ; Wed, 24 Sep 2003 06:00:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26RU-0002Lp-9X for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 06:00:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OA0GeW009033 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 06:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26RT-0002LV-IF for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 06:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04763 for ; Wed, 24 Sep 2003 06:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A26RP-000192-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 06:00:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A26RP-00018w-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 06:00:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26RH-0002Fk-Qw; Wed, 24 Sep 2003 06:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26Qi-0002D9-TO for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 05:59:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04724 for ; Wed, 24 Sep 2003 05:59:20 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A26Qf-00018M-00 for ipv6@ietf.org; Wed, 24 Sep 2003 05:59:25 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A26Qe-00018J-00 for ipv6@ietf.org; Wed, 24 Sep 2003 05:59:24 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8O9xO619641 for ; Wed, 24 Sep 2003 12:59:25 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 12:59:24 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 12:59:24 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 12:59:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node requirement nits (was: AD review of draft-ietf-ipv6-node-requirements-05.txt) Date: Wed, 24 Sep 2003 12:59:23 +0300 Message-ID: Thread-Topic: Node requirement nits (was: AD review of draft-ietf-ipv6-node-requirements-05.txt) Thread-Index: AcNwcNzlV/LpggAjS2OvLr/k56QJrwSDFo+Q To: Cc: , X-OriginalArrivalTime: 24 Sep 2003 09:59:24.0326 (UTC) FILETIME=[88756460:01C38282] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, Assigned as issue 18, comments in line. > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Thomas Narten wrote: >=20 > >> Routers do not need to support route optimization or home agent > >> functionality. > >> > >> Routers SHOULD support the generic mobile IP requirements. > >=20 > >=20 > > I think it would be better to replace the above with something like: > >=20 > > Routers SHOULD support the router-specific extensions defined in > > Section 8.3 of MIPv6 >=20 > Yes. Updated as per Jari's update on Mobile IP. =20 > >> The goal of this document is to define the set of functionality > >> required for an IPv6 node; the functionality common to=20 > both hosts and > >> routers. Many IPv6 nodes will implement optional or additional > >=20 > >=20 > > Sentence with semi-colon doesn't parse. :-( >=20 > Yes. "The goal of this document is to define the common functionality > required from both IPv6 hosts and routers." Updated. > >>3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 > >> > >> Transmission of IPv6 Packets over Ethernet Networks=20 > [RFC-2464] MUST > >> be supported for nodes supporting Ethernet interfaces. > >=20 > >=20 > > I don't quite like the way this (and subsequent) sentences is > > worded. We don't want to imply that nodes that support IPv4 over > > Ethernet must also support this... > >=20 > > How about: > >=20 > > Nodes supporting IPv6 over Ethernet interfaces MUST implement > > Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. > > =20 > > same applies to remaining LL sub-sections. >=20 > Sounds better. OK. =20 > >> IPv6 over ATM Networks [RFC2492] MUST be supported for nodes > >> supporting ATM interfaces. Additionally, the=20 > specification states: > >=20 > >=20 > > what does "the specification" refer to? How about saying > >=20 > > Additionally, RFC 2492 states: >=20 > Right. OK > >> option of disabling this function. The ability to=20 > understand specific > >> Router Advertisement optionss is dependent on supporting the > >=20 > > s/optionss/options/ >=20 > Yes. OK > >> Redirect functionionality SHOULD be supported. If the node is a > >=20 > > spelling >=20 > Speling is bad inteed. Fixed. =20 > >> Nodes that are routers MUST be able to generate link=20 > local addresses > >> as described in this specification. > >=20 > >=20 > > "this specification" is ambiguious. Do you mean 2460? >=20 > Yes. s/this specification/RFC 2460 [RFC-2460]/ OK > >> If an application is going join any-source multicast, it SHOULD > >> support MLDv1. If it is going to support=20 > Source-Specific Multicast, > >=20 > >=20 > > s/join any-source multicast/to join any-source multicast=20 > group addresses/ >=20 > Ok. Got it. > >> This document is currently being updated. > >=20 > >=20 > > s/this document/RFC2893/ >=20 > Ok. Got it > >=20 > >> 7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473 > >=20 > >=20 > > nit: indention is wrong on this heading. >=20 > Yes. got it. =20 > >=20 > >> 3DES-CBC does not suffer from the issues related to=20 > DES-CBC. 3DES-CBC > >> and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be=20 > supported. AES- > >> 128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is=20 > expected to > >> be a widely available, secure algorithm that is required for > >> interoperability. It is not required by the current IPsec RFCs, > >> however. > >=20 > >=20 > > Perhaps add to last sentence, "but is expected to become required in > > the future" ??? >=20 > Ok. Got it. =20 > > act as routers. Currently, this section does not discuss routin- > > specific requirements. > >=20 > > s/routin/routing/ >=20 > Yes. Got it. =20 > >> At least the following two MIBs SHOULD be supported MIBs=20 > SHOULD be > >> supported by nodes that support an SNMP agent. > >=20 > >=20 > > duplicate words. >=20 > Yes. s/MIBs SHOULD be supported MIBs SHOULD be supported/MIBs=20 > SHOULD be supported/ Yes =20 > >>10.1.1 IP Forwarding Table MIB > >> > >> Support for this MIB does not imply that IPv4 or IPv4 specific > >> portions of this MIB be supported. > >=20 > >=20 > > Which MIB is this? (No reference provided...) >=20 > Yes. Its [RFC-2096-BIS], I think. Got it. > >>10.1.2 Management Information Base for the Internet Protocol (IP) > >=20 > >=20 > > Ditto. >=20 > Yes. [RFC-2011-BIS] Got it. > >>12.1 Normative > >> > >> [DHCPv6-SL] R. Droms, "A Guide to Implementing=20 > Stateless DHCPv6 > >> Service", Work in Progress. > >=20 > >=20 > > For all the references, please include the ID name, so folk can > > actually figure out which ID it refers to. Also the RFC editor will > > want to know this too, so they can put in the right references, in > > case any are already RFCs. Got all of these. >=20 > Agree. This one is draft-ietf-dhc-dhcpv6-stateless-00.txt >=20 > The rest are: >=20 > [MIPv6] D. Johnson and C. Perkins, "Mobility=20 > Support in IPv6", > Work in progress. >=20 > draft-ietf-mobileip-ipv6-24.txt. one author missing, too.... ;-) >=20 > [MIPv6-HASEC] J. Arkko, V. Devarapalli, F. Dupont,=20 > "Using IPsec to > Protect Mobile IPv6 Signaling between=20 > Mobile Nodes and > Home Agents", Work in Progress. >=20 > draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. an "and" between the last > two authors? >=20 > [MLDv2] Vida, R. et al., "Multicast Listener=20 > Discovery Version > 2 (MLDv2) for IPv6", Work in Progress. >=20 > draft-vida-mld-v2-07.txt >=20 > [RFC-1886-BIS] Thomson, S., et al., "DNS Extensions to support IP > version 6", Work In Progress. >=20 > draft-ietf-dnsext-rfc1886bis-03.txt >=20 > [RFC-2096-BIS] Wasserman, M. (ed), "IP Forwarding Table=20 > MIB", Work in > Progress. >=20 > draft-ietf-ipv6-rfc2096-update-05.txt. the authors should be=20 > "Haberman, B. > and Wasserman, M.". No "(ed)", I think, because it doesn't say in the > I-D boilerplate. >=20 > [RFC-2011-BIS] Routhier, S (ed), "Management Information=20 > Base for the > Internet Protocol (IP)", Work in progress. >=20 > draft-ietf-ipv6-rfc2011-update-03.txt >=20 > [ANYCAST] Hagino, J and Ettikan K., "An Analysis of=20 > IPv6 Anycast" > Work in Progress. >=20 > draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt >=20 > [SOI] C. Madson, "Son-of-IKE Requirements", Work=20 > in Progress. >=20 > Expired, I think. Better replace this reference with > draft-ietf-ipsec-ikev2-10.txt. >=20 > [IPv6-RH] P. Savola, "Security of IPv6 Routing=20 > Header and Home > Address Options", Work in Progress, March 2002. >=20 > draft-savola-ipv6-rh-ha-security-03.txt >=20 > [SSM-ARCH] H. Holbrook, B. Cain, "SSM Architecture",=20 > Work in Pro- > gress. >=20 > I think this is draft-ietf-ssm-arch-03.txt, but then the title > is wrong: Source-Specific Multicast for IP >=20 > --Jari >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 06:20:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05341 for ; Wed, 24 Sep 2003 06:20:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26l3-0003mN-Ms for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 06:20:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OAKTwl014524 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 06:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26l3-0003mB-IT for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 06:20:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05303 for ; Wed, 24 Sep 2003 06:20:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A26kz-0001JL-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 06:20:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A26kz-0001JI-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 06:20:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26ke-0003gD-TF; Wed, 24 Sep 2003 06:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26k8-0003fJ-RP for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 06:19:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05267 for ; Wed, 24 Sep 2003 06:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A26k4-0001J2-00 for ipv6@ietf.org; Wed, 24 Sep 2003 06:19:28 -0400 Received: from mr200a.caspiannetworks.com ([63.108.173.139] helo=cmail.caspian.com) by ietf-mx with esmtp (Exim 4.12) id 1A26k4-0001Iq-00 for ipv6@ietf.org; Wed, 24 Sep 2003 06:19:28 -0400 Received: from innovationslab.net ([172.17.55.3]) by cmail.caspian.com (Mirapoint Messaging Server MOS 3.2.4-GA) with ESMTP id AIR01381; Wed, 24 Sep 2003 03:18:55 -0700 (PDT) Message-ID: <3F716F8E.5080400@innovationslab.net> Date: Wed, 24 Sep 2003 06:18:54 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Note on id/loc separation discussion References: <3F704DDF.3050800@innovationslab.net> In-Reply-To: <3F704DDF.3050800@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As a follow-up, the IAB is looking into creating a list for this type of discussion based on the comments made at the open plenary in Vienna. They will announce this list when it is active. Regards, Brian Brian Haberman wrote: > All, > The chairs have noted the level of interest garnered > by the discussion of separating the Identifier and Locator > aspects of IP addresses. There is apparently a high level > of interest in exploring possible ways of separating these > functionalities and gauging the benefits and downsides. > > However, the chairs wish to point out that this topic > is not in charter for the ipv6 mailing list and it touches > on the domains of several other working groups (e.g. multi6). > So, even though we would to request that discussion not > continue on the ipv6 mailing list, the chairs do not want > to put a stop to anyone who wishes to continue the investigation. > > Therefore, we suggest that interested parties create a > separate mailing list to discuss the topic of identifier and > locator separation. If needed, the chairs can help arrange > for the creation of an exploratory mailing list. > > Regards, > Bob Hinden / Brian Haberman > IPv6 WG co-chairs > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:18:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07129 for ; Wed, 24 Sep 2003 07:18:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27ez-0007ZM-8t for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:18:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBIHnx029090 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27ez-0007Z7-2p for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:18:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07095 for ; Wed, 24 Sep 2003 07:18:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27ey-0001uq-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:18:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27ey-0001un-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:18:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27ek-0007TL-6b; Wed, 24 Sep 2003 07:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27e3-0007Sg-FH for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:17:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07082 for ; Wed, 24 Sep 2003 07:17:13 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27e2-0001uM-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:17:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A27e2-0001uI-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:17:18 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBH1t23380 for ; Wed, 24 Sep 2003 14:17:02 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:17:01 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:17:00 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:17:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Issue 19: AD review of draft-ietf-ipv6-node-requirements-05.txt Date: Wed, 24 Sep 2003 14:17:00 +0300 Message-ID: Thread-Topic: AD review of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcNs4uGBXOd7Jo9vRW+qaP2lqxY+zQVqXwpg To: , X-OriginalArrivalTime: 24 Sep 2003 11:17:00.0774 (UTC) FILETIME=[5FEAF860:01C3828D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Nodes MUST always be able to receive fragment headers. However, = if it > > does not implement path MTU discovery it may not need to send > > fragment headers. However, nodes that do not implement = transmission > > of fragment headers need to impose a limitation to the payload = size > > of layer 4 protocols. > =20 > This would seem inconsistent with the following wording in RFC 2460: >=20 > In response to an IPv6 packet that is sent to an IPv4 destination > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280. In that case, the IPv6 = node > is not required to reduce the size of subsequent packets to less = than > 1280, but must include a Fragment header in those packets so that = the > IPv6-to-IPv4 translating router can obtain a suitable = Identification > value to use in resulting IPv4 fragments. Note that this means = the > payload may have to be reduced to 1232 octets (1280 minus 40 for = the > IPv6 header and 8 for the Fragment header), and smaller still if > additional extension headers are used. So, this should be changed to: Nodes MUST always be able to send and receive fragment headers. (rest = of the text deleted) John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:23:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07305 for ; Wed, 24 Sep 2003 07:23:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27jq-0007xA-SH for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:23:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBNIGH030566 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27jq-0007wv-Na for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07265 for ; Wed, 24 Sep 2003 07:23:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27jq-0001yM-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:23:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27jp-0001yJ-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:23:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27ja-0007sq-AQ; Wed, 24 Sep 2003 07:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27ig-0007rq-PH for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:22:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07235 for ; Wed, 24 Sep 2003 07:21:59 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27ie-0001xf-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:22:04 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A27id-0001xc-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:22:04 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBM2t29489 for ; Wed, 24 Sep 2003 14:22:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:21:59 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:21:58 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:21:58 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:21:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Issue20: Sect. 4.2 disabling Router Discovery Date: Wed, 24 Sep 2003 14:21:57 +0300 Message-ID: Thread-Topic: AD review of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcNs4uGBXOd7Jo9vRW+qaP2lqxY+zQVqXwpgAABk2bA= To: , X-OriginalArrivalTime: 24 Sep 2003 11:21:57.0652 (UTC) FILETIME=[10DEF540:01C3828E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Router Discovery is how hosts locate routers that reside on an > > attached link. Router Discovery MUST be supported for > > implementations. However, an implementation MAY support disabling > > this function. >=20 > Why the MAY above? If there are reasons to allow this, it would be > good to give some examples of the WG's thinking for calling out such > an exception. Also, this is a change to 2461 I assume? Suggested resolution: delete last sentence. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:27:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07566 for ; Wed, 24 Sep 2003 07:27:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27nX-0008SA-9Y for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:27:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBR74p032488 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27nX-0008Rv-4A for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:27:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07491 for ; Wed, 24 Sep 2003 07:27:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27nW-000244-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27nW-000241-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:27:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27nR-0008Ib-ME; Wed, 24 Sep 2003 07:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27mz-0008HE-Qz for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:26:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07411 for ; Wed, 24 Sep 2003 07:26:27 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27mz-00022I-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:26:33 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A27mx-00022F-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:26:32 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBQU603732 for ; Wed, 24 Sep 2003 14:26:30 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:26:30 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:26:30 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:26:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Issue21: Section 4.2: Prefix discovery & DAD Date: Wed, 24 Sep 2003 14:26:29 +0300 Message-ID: Thread-Topic: AD review of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcNs4uGBXOd7Jo9vRW+qaP2lqxY+zQVqXwpgAABk2bAAACdowA== To: , X-OriginalArrivalTime: 24 Sep 2003 11:26:29.0956 (UTC) FILETIME=[B32D4040:01C3828E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable New issue: 21, see below: > > Prefix Discovery is how hosts discover the set of address = prefixes > > that define which destinations are on-link for an attached link. > > Prefix discovery MUST be supported for implementations. However, = the > > implementation MAY support the option of disabling this function. >=20 > same comment with regards to MAY. And also, am I right to assume that > disabling this function would need to be done on a per-interface basis > (in which case the current text isn't explicit enough)? I.e, is this > related to some 3G type deployment? The text isn't related to any 3G deployments, that I know of. Suggested resolution, delete last sentence. > > Duplicate Address Detection MUST be supported (RFC2462 section = 5.4 > > specifies DAD MUST take place on all unicast addresses). >=20 > This reference to 2462 section 5.4 is a tad misleading. The relevant > paragraph in 2462 says: >=20 > > 5.4. Duplicate Address Detection > >=20 > > Duplicate Address Detection is performed on unicast addresses = prior > > to assigning them to an interface whose DupAddrDetectTransmits > > variable is greater than zero. Duplicate Address Detection MUST = take > > place on all unicast addresses, regardless of whether they are > > obtained through stateful, stateless or manual configuration, = with > > the exception of the following cases: >=20 > Note that one of the exception cases is stateless addr conf when > configuring multiple addresses using the same IID. Is node-requirments > trying to override this exception? If so, it should be explicit about > it. Otherwise, I'm not sure why the above sentence is included in > node-requirements. The Node Req. should not override any RFC, so the suggested resolution:=20 delete text in parenthesis. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:35:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08018 for ; Wed, 24 Sep 2003 07:35:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27vN-0000vb-Lt for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:35:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBZD6J003561 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27vN-0000vM-Ew for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07971 for ; Wed, 24 Sep 2003 07:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27vM-0002D1-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:35:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27vM-0002Cy-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:35:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27vD-0000mr-El; Wed, 24 Sep 2003 07:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27ut-0000kj-PL for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:34:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07947 for ; Wed, 24 Sep 2003 07:34:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27ut-0002Cc-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:34:43 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1A27us-0002Bg-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:34:42 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8OBYBPK364418; Wed, 24 Sep 2003 07:34:11 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-215-231.mts.ibm.com [9.65.215.231]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8OBYAiY067934; Wed, 24 Sep 2003 05:34:10 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h8OBV3Z07609; Wed, 24 Sep 2003 07:31:20 -0400 Message-Id: <200309241131.h8OBV3Z07609@cichlid.adsl.duke.edu> To: Michael Thomas cc: Erik Nordmark , Pekka Savola , ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] In-Reply-To: Message from mat@cisco.com of "Mon, 22 Sep 2003 17:53:54 PDT." <16239.39330.308606.237915@thomasm-u1.cisco.com> Date: Wed, 24 Sep 2003 07:31:03 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Michael Thomas writes: > From my SF-centric Nexus-of-the-web-trendiod > standpoint: for residential use (especially with > broadband) it is simply impossible to have an > argument about the evils of NAT. It's even worse than that. If you are residential user, try finding a home router that is actually a Real Router. I've come to the unfortunate conclusion that they no longer exist. The market landscape has shifted dramatically. All home routers come with NAT builtin and the functionality can simply _NOT_ be disabled. I was forced not too long ago to switch DSL providers. I had been living in bliss: my DSL modem was a bridge to an ISP that gave me as many public addresses as I wanted using DHCP. It worked well and I was happy. My current provider is more typical. It is willing to give me extra addresses (for a monthly charge), so I naively thought I would do this with a home router. The two home routers I've looked at most closely (D-Link and Linksys) do not allow one to disable the NAT functionality. My ISP (after having supposedly done research) says this is the case for all home routers. To get a real router would seem to cost a lot more (i.e, low hundreds of $$). It has been suggested that if I want a cheap router, I should go to eBay and by a used low-end Cisco. Kind of shows how bad the situation actually is. If one looks at the price point/functionality of home routers, the situation is not very encouaraging. They typically come with a 4 port ethernet switch, all for something like $40. They heavily market security as important, i.e., none of the internal machines are visible to outside hackers by default. Given the current feature/functionaliy/price point reality of home routers, getting them to implement reasonable functionality as an IPv6 router seems like it will be a rather hard sell. :-( Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08262 for ; Wed, 24 Sep 2003 07:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2813-0001zg-Tc for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:41:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBf51s007658 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2813-0001zR-Oo for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:41:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08214 for ; Wed, 24 Sep 2003 07:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2813-0002IN-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:41:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2812-0002IK-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2810-0001to-1F; Wed, 24 Sep 2003 07:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A280f-0001tN-1q for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:40:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08202 for ; Wed, 24 Sep 2003 07:40:34 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A280e-0002IA-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:40:40 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A280d-0002I7-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:40:39 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBeb620562 for ; Wed, 24 Sep 2003 14:40:37 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:40:37 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:40:37 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:40:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue22: 4.5.4 Default Address Selection for IPv6 - RFC3484 text Date: Wed, 24 Sep 2003 14:40:36 +0300 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCkBXAGp5Li7UKSGWRmJf2o1FKYwAAHwTg To: , X-OriginalArrivalTime: 24 Sep 2003 11:40:37.0064 (UTC) FILETIME=[AC17AC80:01C38290] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 4.5.4 Default Address Selection for IPv6 - RFC3484 > >=20 > > Default Address Selection for IPv6 [RFC-3484] SHOULD be supported, = if > > a node has more than one IPv6 address per interface or a node has > > more that one IPv6 interface (physical or logical) configured. > >=20 > > If supported, the rules specified in the document MUST be > > implemented. A node needs to belong to one site, however there is = no > > requirement that a node be able to belong to more than one site. >=20 > This is really weasle worded. Is 3484 mandatory to _implement_ or not? > You can't make its implementation dependent on whether there are > multiple addresses, since the number of addresses a node will have is > not something an implementor will know, as it's an operational issue. Why do you say its weasley-worded? I take this as a strong SHOULD. I imagine that a single purpose IPv6, like a sensor may, in fact, have a single IP address. Some text clarification may be OK, though, how about adding to the first paragraph the following text: It is expected that most implementations will indeed support this, = as=20 since the number of addresses a node will have is more of an=20 operational issue. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:49:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08547 for ; Wed, 24 Sep 2003 07:49:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2894-0002c6-1A for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:49:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBnLJ6010040 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:49:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2893-0002br-SH for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:49:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08488 for ; Wed, 24 Sep 2003 07:49:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2893-0002Nd-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:49:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2892-0002NZ-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:49:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A288j-0002SM-Az; Wed, 24 Sep 2003 07:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A287p-0002RU-FB for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08447 for ; Wed, 24 Sep 2003 07:47:58 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A287o-0002Mo-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:48:04 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A287n-0002Ml-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:48:03 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBm1628250 for ; Wed, 24 Sep 2003 14:48:01 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:48:01 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:48:00 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:45:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue23: DNS issues Date: Wed, 24 Sep 2003 14:45:46 +0300 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCkBXAGp5Li7UKSGWRmJf2o1FKYwAAHwTgAAAw5yA= To: , X-OriginalArrivalTime: 24 Sep 2003 11:45:49.0784 (UTC) FILETIME=[667CF580:01C38291] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152] > > and [RFC-3363] MAY be supported. Not all nodes will need to = resolve > > names. Note that RFC 1886 is currently being updated = [RFC-1886-BIS]. >=20 > 1886-bis has been approved by the IESG I believe... When it gets and RFC number, I will update. > Also, I suspect this section really needs to talk about resolvers and > resolver behavior, rather than just say DNS. Most of the server issues > do not apply to generic IPv6 nodes.=20 Servers are nodes, are they not? Nodes can be both a host and/or = server. =20 > But almost every node will have some sort of resolver... There had been some discussion about this, and some folks made some comments that indicated that certain devices may not have any resolvers, so I don't want to assume that almost every node will have some sort of resolver. My suggested resolution is to leave the text unchanged. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:50:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08615 for ; Wed, 24 Sep 2003 07:50:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A289l-0002qc-Cc for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:50:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBo5v0010946 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A289k-0002oZ-Ol for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08566 for ; Wed, 24 Sep 2003 07:49:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A289j-0002PD-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:50:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A289j-0002PA-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A289j-0002hU-CQ; Wed, 24 Sep 2003 07:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A289S-0002gm-PQ for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:49:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08524 for ; Wed, 24 Sep 2003 07:49:40 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A289R-0002Oh-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:49:46 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A289R-0002Oe-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:49:45 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBnit01030 for ; Wed, 24 Sep 2003 14:49:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:49:43 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:49:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:49:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue24: 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 Date: Wed, 24 Sep 2003 14:49:42 +0300 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCkBXAGp5Li7UKSGWRmJf2o1FKYwAAHwTgAABUWmA= To: , X-OriginalArrivalTime: 24 Sep 2003 11:49:42.0933 (UTC) FILETIME=[F174AC50:01C38291] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 5.3.1 Managed Address Configuration >=20 > IMO, it doesn't make sense to talk about "implementing DHC" without > being more specific. I suspect that all of this section is about the > client part of DHC, not the server. It would be good to make this > clear. Ditto for 5.3.2. Suggested reslution: Modify the first sentence to: An IPv6 node that does not include an implementation of the client=20 part of DHCP .. > Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be used to > obtain configuration information. A node that uses stateless DHCP > must have obtained its IPv6 addresses through some other mechanism, > typically stateless address autoconfiguration. >=20 > Does this even need mentioning? I.e, what are the real implications > for clients? Do they need to implement full blown dhc (the client > part)? Or do they implement some subset? (Hmm... reading the related > draft, clients implement a subset... And this document has a normative > reference to the other ID, so either this document needs to be more > explicit about what stateless DHCPv6 is, or will have to wait on the > other document.) Suggest resolution: strike the paragraph. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 07:55:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08906 for ; Wed, 24 Sep 2003 07:55:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Ei-0003c1-An for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:55:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBtCaK013879 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 07:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Ei-0003bm-63 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08872 for ; Wed, 24 Sep 2003 07:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28Eh-0002Vc-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:55:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A28Eg-0002VY-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 07:55:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28EZ-0003Ub-D4; Wed, 24 Sep 2003 07:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28EL-0003Tr-8H for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 07:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08857 for ; Wed, 24 Sep 2003 07:54:42 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28EK-0002VD-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:54:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A28EJ-0002VA-00 for ipv6@ietf.org; Wed, 24 Sep 2003 07:54:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBskt06674 for ; Wed, 24 Sep 2003 14:54:46 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:54:46 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:54:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:54:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue25: 6.1 Transition Mechanisms Date: Wed, 24 Sep 2003 14:54:38 +0300 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCkBXAGp5Li7UKSGWRmJf2o1FKYwAAHwTgAABUWmAAACx9wA== To: , X-OriginalArrivalTime: 24 Sep 2003 11:54:39.0428 (UTC) FILETIME=[A22E3840:01C38292] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 6.1 Transition Mechanisms > >=20 > > IPv6 nodes SHOULD use native addressing instead of = transition-based > > addressing (according to the algorithms defined in RFC 3484). >=20 > Is this a statement about what needs to be implemented? Or is this an > operational statement? (This document seems to be mostly about the > former, and this statement seems odd without more context...) This was a suggestion early on in the draft history, it is about operational issues than anything. Suggestion resolution: strike the = text. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 08:09:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09693 for ; Wed, 24 Sep 2003 08:09:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28SR-0005HO-3W for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 08:09:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OC9ND8020288 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 08:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28SQ-0005H9-UL for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 08:09:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09655 for ; Wed, 24 Sep 2003 08:09:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28SP-0002nd-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 08:09:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A28SP-0002na-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 08:09:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28S6-00056a-GZ; Wed, 24 Sep 2003 08:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Rd-00054l-Po for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 08:08:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09617 for ; Wed, 24 Sep 2003 08:08:27 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28Rc-0002n0-00 for ipv6@ietf.org; Wed, 24 Sep 2003 08:08:32 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A28Rb-0002mw-00 for ipv6@ietf.org; Wed, 24 Sep 2003 08:08:32 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OC8T622568 for ; Wed, 24 Sep 2003 15:08:30 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 15:08:13 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 15:08:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 15:08:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711 Date: Wed, 24 Sep 2003 15:08:11 +0300 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCkBXAGp5Li7UKSGWRmJf2o1FKYwAAHwTgAABUWmAAACx9wAAAeWLQ To: , X-OriginalArrivalTime: 24 Sep 2003 12:08:11.0932 (UTC) FILETIME=[86787DC0:01C38294] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Section 9 begins by saying: >=20 > > 9. Router-Specific Functionality > >=20 > > This section defines general host considerations for IPv6 nodes = that > > act as routers. Currently, this section does not discuss routin- > > specific requirements. >=20 > an then immediately says >=20 > > 9.1.1 IPv6 Router Alert Option - RFC2711 > >=20 > > The Router Alert Option [RFC-2711] MUST be supported by nodes = that > > perform packet forwarding at the IP layer (i.e. - the node is a > > router). >=20 > But this seems like a "forwarding-related" requirement. When do > routers send router alerts? They need to process them when they are > received, e.g., as part of MLD stuff. When else are they used? Reading 2711, there are some host / server specific issues about 2711.=20 Suggested text: IPv6 Router Alert Option specific [RFC-2711] defines a new option in = the IPv6 Hop-by-Hop Header. Hosts MAY support the router alert option=20 defined. Nodes that generate RSVP message MUST implement the router alert option. The Router Alert Option [RFC-2711] MUST be supported by=20 nodes that perform packet forwarding at the IP layer (i.e. - the node = is a router). John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 08:14:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09951 for ; Wed, 24 Sep 2003 08:14:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28X4-0005fH-CY for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 08:14:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OCEAmi021768 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 08:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28X4-0005f1-21 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 08:14:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09895 for ; Wed, 24 Sep 2003 08:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28X3-0002sq-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 08:14:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A28X2-0002sn-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 08:14:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Ww-0005Xo-0n; Wed, 24 Sep 2003 08:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28WO-0005Wj-0t for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 08:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09855 for ; Wed, 24 Sep 2003 08:13:21 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28WM-0002rU-00 for ipv6@ietf.org; Wed, 24 Sep 2003 08:13:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A28WM-0002rP-00 for ipv6@ietf.org; Wed, 24 Sep 2003 08:13:26 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OCDPt29209 for ; Wed, 24 Sep 2003 15:13:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 15:13:24 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 15:13:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 15:13:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue27: 11. Security Considerations Date: Wed, 24 Sep 2003 15:13:22 +0300 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCkBXAGp5Li7UKSGWRmJf2o1FKYwAAHwTgAABUWmAAACx9wAAAph7A To: , Cc: X-OriginalArrivalTime: 24 Sep 2003 12:13:23.0175 (UTC) FILETIME=[3FFC6770:01C38295] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 11. Security Considerations >=20 > This section seems both too detailed and not detailed enough. Too > detailed in that it talks about security issues related to some > (arbitrary?) protocols like ICMPv6, but not detailed enough in that it > is anywhere complete and doesn't mention many other protocols that > could also be included if one were to include ICMPv6. My suggestion > would be to up-level here and not talk about detailed security issues > of individual protocols. If you want to do that, point to the security > sections in other documents. But if you do this, you'll have a hard > time deciding whether to mention every document or just some. >=20 > Does _this_ document itself introduce or raise any security issues not > covered elsewhere? That is the question this document should focus > on. The answer may be mostly no. I am not a security expert, perhaps Jari could comment on this section.=20 This document does not introduce any new security vulnerabilites on the Internet. However, in creating this document some of the contributors felt that there are security issues that are not covered in existing = RFCs and this is what we have tried to document. Perhaps you should be more specific on what should be removed, for example. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 08:17:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10165 for ; Wed, 24 Sep 2003 08:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Zu-00061u-PS for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 08:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OCH6pK023172 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 08:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Zu-00061f-KR for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 08:17:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10104 for ; Wed, 24 Sep 2003 08:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28Zt-0002xa-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 08:17:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A28Zs-0002xX-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 08:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Zq-0005w4-66; Wed, 24 Sep 2003 08:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28ZX-0005vd-Dd for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 08:16:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10064 for ; Wed, 24 Sep 2003 08:16:36 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28ZW-0002wm-00 for ipv6@ietf.org; Wed, 24 Sep 2003 08:16:42 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A28ZV-0002wi-00 for ipv6@ietf.org; Wed, 24 Sep 2003 08:16:41 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OCGet03550 for ; Wed, 24 Sep 2003 15:16:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 15:16:40 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 15:16:39 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 15:16:39 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 15:16:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Updating the Node Requirements document Date: Wed, 24 Sep 2003 15:16:38 +0300 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCkBXAGp5Li7UKSGWRmJf2o1FKYwAAHwTgAABUWmAAACx9wAAAeWLQAAA7lqA= To: , X-OriginalArrivalTime: 24 Sep 2003 12:16:38.0777 (UTC) FILETIME=[B492E690:01C38295] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I have gone through Thomas' AD review comments of this document, and = filed a number of issues. Most all of them have proposed resolutions. I have = sent the individual issues to the list. The issues can be found from: http://danforsberg.info:8080/draft-ietf-ipv6-node-requirements/index As long as the proposed resolutions are acceptable, I propose to update = the document and submit it early next week. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 10:11:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16442 for ; Wed, 24 Sep 2003 10:11:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AMQ-0005vm-F6 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 10:11:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OEBIvO022794 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 10:11:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AMQ-0005vZ-BX for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 10:11:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16376 for ; Wed, 24 Sep 2003 10:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2AMO-0004YJ-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 10:11:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2AMN-0004YE-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 10:11:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ALD-0005eT-Ey; Wed, 24 Sep 2003 10:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AKW-0005d3-Tp for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 10:09:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15966; Wed, 24 Sep 2003 10:09:11 -0400 (EDT) Message-Id: <200309241409.KAA15966@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-01.txt Date: Wed, 24 Sep 2003 10:09:11 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-addr-01.txt Pages : 15 Date : 2003-9-24 This document defines an unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet given current routing technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-unique-local-addr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-24092356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unique-local-addr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-24092356.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 11:43:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22810 for ; Wed, 24 Sep 2003 11:43:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BnW-0003xx-A0 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 11:43:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OFhMQl015239 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 11:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BnW-0003xi-5g for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 11:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22766 for ; Wed, 24 Sep 2003 11:43:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BnV-0006Rv-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 11:43:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2BnU-0006Rs-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 11:43:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BmD-0003hF-El; Wed, 24 Sep 2003 11:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BmA-0003gu-Jo for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 11:41:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22656 for ; Wed, 24 Sep 2003 11:41:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Bm9-0006Oo-00 for ipv6@ietf.org; Wed, 24 Sep 2003 11:41:57 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A2Bm2-0006Oe-00 for ipv6@ietf.org; Wed, 24 Sep 2003 11:41:50 -0400 Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Sep 2003 08:41:14 -0700 Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCj+qkO1aUdGh+RMyot+E3AMfq2gAHSx0w From: "Michel Py" To: "Thomas Narten" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thomas, > Thomas Narten wrote: > If you are residential user, try finding a home router > that is actually a Real Router. I've come to the > unfortunate conclusion that they no longer exist. The $40 router never existed. Get real, there is no way to support Joe Blow configuring a router if it sells for $40. There are dual-ethernet products such as the Netopia R910 ($170) that do what you are looking for. There also are several sub-$100 boxes, none of them I could recommend because the manufacturer will likely tank before the end of the year. And if you want a real firewall you still have to spend a mighty $350 for a SonicWall. > I had been living in bliss A too common problem within the IETF. Maybe it would be useful for some people here to actually get out in the real world. > Given the current feature/functionaliy/price point reality > of home routers, getting them to implement reasonable > functionality as an IPv6 router seems like it will be a > rather hard sell. :-( It's impossible to deliver because of supportability issues. Technically, the code could be embedded in a $40 box, nobody wants to do that though because it will take $300 to cover support calls. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 12:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23836 for ; Wed, 24 Sep 2003 12:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C3g-0005A6-DV for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 12:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OG02VP019832 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 12:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C3d-00059P-LN for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 12:00:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23783 for ; Wed, 24 Sep 2003 11:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2C3Z-0006gU-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 11:59:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2C3Z-0006gR-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 11:59:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C2g-0004xK-2S; Wed, 24 Sep 2003 11:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2C29-0004wU-1V for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 11:58:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23737 for ; Wed, 24 Sep 2003 11:58:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2C27-0006fG-00 for ipv6@ietf.org; Wed, 24 Sep 2003 11:58:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2C27-0006eS-00 for ipv6@ietf.org; Wed, 24 Sep 2003 11:58:27 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2003 09:00:34 -0700 Received: from cisco.com (sjc-vpn2-875.cisco.com [10.21.115.107]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8OFvrYb018293; Wed, 24 Sep 2003 08:57:54 -0700 (PDT) Message-ID: <3F71BF00.9040000@cisco.com> Date: Wed, 24 Sep 2003 08:57:52 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: Thomas Narten , ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit DING DING.... IPv4-0-Meter just went off. Why is this an issue in v6-land, assuming you can get a v6 consumer networking device? Eliot Michel Py wrote: > Thomas, > > >>Thomas Narten wrote: >>If you are residential user, try finding a home router >>that is actually a Real Router. I've come to the >>unfortunate conclusion that they no longer exist. > > > The $40 router never existed. Get real, there is no way to support Joe > Blow configuring a router if it sells for $40. > > There are dual-ethernet products such as the Netopia R910 ($170) that do > what you are looking for. There also are several sub-$100 boxes, none of > them I could recommend because the manufacturer will likely tank before > the end of the year. And if you want a real firewall you still have to > spend a mighty $350 for a SonicWall. > > > >>I had been living in bliss > > > A too common problem within the IETF. Maybe it would be useful for some > people here to actually get out in the real world. > > > >>Given the current feature/functionaliy/price point reality >>of home routers, getting them to implement reasonable >>functionality as an IPv6 router seems like it will be a >>rather hard sell. :-( > > > It's impossible to deliver because of supportability issues. > Technically, the code could be embedded in a $40 box, nobody wants to do > that though because it will take $300 to cover support calls. > > Michel. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 12:32:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25140 for ; Wed, 24 Sep 2003 12:32:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CYm-0007XE-Ds for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 12:32:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OGWCAF028961 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 12:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CYl-0007X2-K1 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 12:32:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25113 for ; Wed, 24 Sep 2003 12:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2CYk-00072L-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 12:32:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2CYj-00072I-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 12:32:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CXf-0007BH-DG; Wed, 24 Sep 2003 12:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ywT-0005Wb-Nv for ipv6@optimus.ietf.org; Tue, 23 Sep 2003 21:59:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18346 for ; Tue, 23 Sep 2003 21:59:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1ywQ-0002ZF-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:59:42 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1A1ywQ-0002ZC-00 for ipv6@ietf.org; Tue, 23 Sep 2003 21:59:42 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h8O1xftD019104 for ; Tue, 23 Sep 2003 18:59:42 -0700 (MST) Received: from motorola.com (mvp-10-238-2-125.corp.mot.com [10.238.2.125]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h8O1xZVo023985 for ; Tue, 23 Sep 2003 20:59:39 -0500 Message-ID: <3F70FA85.2BD7E8F7@motorola.com> Date: Wed, 24 Sep 2003 11:59:33 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: why market picked up NATs References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> <1064367082.27238.15.camel@vega.amorsen.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Benny, In general, I agree with your analysis. Benny Amorsen writes: > > In order to reach the same ease of configuration, it would be necessary > to make a routing protocol where a router could ask its upstream to be > assigned a /64. The upstream would pass the request on, until the > request is granted by the router which was given a /48. Is anything like > that possible today? I think it's a little more complex. Let's leave aside the daisy-chained NATs for a moment (which is a nightmare waiting to happen) and look at the home deployment scenario. Using 6to4, it is reasonably easy to build an all-in-one IPv6 home gateway right now. Currently, it's advantageous if the gateway does both IPv4 and IPv6, since DNS support virtually requires v4. At this point, you have end-to-end connectivity from any host (something you don't get with NAT), less whatever your firewall chooses to filter out. The real issue is application support. In the consumer market, OS X has IPv6, but it's hidden from most users. Win XP also has IPv6, but it requires a bunch of chicanery to get it working. The real killer is that few developers are building IPv4/6 agnostic stacks into their software, even though the overhead is minimal. I follow several games mailing lists, and it is quite common to see lots of issues with peer-peer games being blocked by home "routers". I suspect if these devs could be convinced to go IPv6 then the IPv6 home market could grow quite rapidly. The other issue is cascading these setups. Currently, I am unaware of a deployed solution for automatically telling a gateway home router what it's IPv6 network is (Haberman has written a draft, however, and there may be others). A second issue occurs with cascading. I have built a zeroconf system for doing peer-peer routing, but that's different from hierarchical delegation. These issues are very soluble, but it's a matter of how the market wishes to deploy the solutions. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 13:06:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26700 for ; Wed, 24 Sep 2003 13:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2D5g-0001kC-Hg for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 13:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OH6Cek006704 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 13:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2D5g-0001k3-Cj for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 13:06:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26659 for ; Wed, 24 Sep 2003 13:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2D5e-0007Vh-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 13:06:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2D5d-0007Ve-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 13:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2D4Z-0001Sb-9u; Wed, 24 Sep 2003 13:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2D4F-0001PH-B4 for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 13:04:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26598 for ; Wed, 24 Sep 2003 13:04:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2D4D-0007U5-00 for ipv6@ietf.org; Wed, 24 Sep 2003 13:04:41 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2D4C-0007Tk-00 for ipv6@ietf.org; Wed, 24 Sep 2003 13:04:40 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8OH49F29138 for ; Wed, 24 Sep 2003 10:04:09 -0700 X-mProtect: <200309241704> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIzZEWe; Wed, 24 Sep 2003 10:04:07 PDT Message-Id: <4.3.2.7.2.20030924094919.0394f9e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Sep 2003 09:54:47 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: Fwd: Last Call: 'Multicast Listener Discovery Version 2 (MLDv2) for IPv6' to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , FYI >To: IETF-Announce :; >Cc: magma@ietf.org >From: The IESG >Subject: Last Call: 'Multicast Listener Discovery Version 2 (MLDv2) for > IPv6' to Proposed Standard >Reply-to: iesg@ietf.org >Date: Wed, 24 Sep 2003 09:55:28 -0400 >Sender: owner-ietf-announce@ietf.org >X-pstn-levels: (C:80.2266 M:99.5542 P:95.9108 R:95.9108 S: 2.7045 ) >X-pstn-settings: 3 (1.0000:1.0000) pmCr >X-pstn-addresses: from > >The IESG has received a request from the Multicast & Anycast Group >Membership WG to consider the following document: > >- 'Multicast Listener Discovery Version 2 (MLDv2) for IPv6' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-08. > > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-vida-mld-v2-07.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 13:34:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27814 for ; Wed, 24 Sep 2003 13:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2DWZ-0003be-JN for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 13:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OHXxO7013856 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 13:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2DWZ-0003bP-B8 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 13:33:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27772 for ; Wed, 24 Sep 2003 13:33:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2DWX-00003O-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 13:33:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2DWW-00003L-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 13:33:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2DVe-0003CM-6C; Wed, 24 Sep 2003 13:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2DVX-0003Bf-I6 for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 13:32:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27733 for ; Wed, 24 Sep 2003 13:32:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2DVV-00002g-00 for ipv6@ietf.org; Wed, 24 Sep 2003 13:32:53 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1A2DVU-00002d-00 for ipv6@ietf.org; Wed, 24 Sep 2003 13:32:52 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h8OHWixK008624; Wed, 24 Sep 2003 11:32:44 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8OHWfQ05102; Wed, 24 Sep 2003 19:32:41 +0200 (MEST) Date: Wed, 24 Sep 2003 19:27:46 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] To: Thomas Narten Cc: Michael Thomas , Erik Nordmark , Pekka Savola , ipv6@ietf.org In-Reply-To: "Your message with ID" <200309241131.h8OBV3Z07609@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > It's even worse than that. If you are residential user, try finding a > home router that is actually a Real Router. I've come to the > unfortunate conclusion that they no longer exist. The market > landscape has shifted dramatically. All home routers come with NAT > builtin and the functionality can simply _NOT_ be disabled. Hmm - must be the $50 routers and the cheapest service. The box I got installed last week as part of a DSL install (which is "SOHO class" i.e. not the cheapest on the market) is not only a real router, but when you disable NAT it has a default firewall policy (outbound only connections). To get this setup by the ISP all I had to do is tell them that I need public IPv4 address space by filling in a form, and then they spent 10 seconds to put that address space range in the router. > My ISP (after having supposedly done research) says > this is the case for all home routers. To get a real router would seem > to cost a lot more (i.e, low hundreds of $$). My cost $149 with a $149 mailin rebate = zero. Cheap enough for me. But different regions and countries are likely to have different competitive pressure; my attempts at getting non-NATed service in France failed and UDP tunneling came to my rescue. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 15:01:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01395 for ; Wed, 24 Sep 2003 15:01:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Et8-0001B8-E5 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 15:01:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OJ1MQV004529 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 15:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Et8-0001Ay-8C for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 15:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01367 for ; Wed, 24 Sep 2003 15:01:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Et5-00010F-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 15:01:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Et5-00010C-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 15:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Eqs-0000ni-7j; Wed, 24 Sep 2003 14:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Eqp-0000nT-4J for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 14:58:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01277 for ; Wed, 24 Sep 2003 14:58:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Eqk-0000yk-00 for ipv6@ietf.org; Wed, 24 Sep 2003 14:58:54 -0400 Received: from fep20-0.kolumbus.fi ([193.229.0.47] helo=fep20-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1A2Eqj-0000yh-00 for ipv6@ietf.org; Wed, 24 Sep 2003 14:58:54 -0400 Received: from kolumbus.fi ([62.248.153.78]) by fep20-app.kolumbus.fi with ESMTP id <20030924185851.VEEG2909.fep20-app.kolumbus.fi@kolumbus.fi>; Wed, 24 Sep 2003 21:58:51 +0300 Message-ID: <3F71E898.6060006@kolumbus.fi> Date: Wed, 24 Sep 2003 21:55:20 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-node-requirements-05.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>Pekka had raised the comment that a reference to the MLDv1 >>Source Address Selection >>document should be added to the Node Reqirements document: >> >> >>>> 1) some comments never made it to the draft, were they >> >>missed or rejected >> >>>>for some purpose? (Example: MLDv1 Source Address >> >>Selection document which >> >>>>has been approved by the IESG.) >>> >>>As people bothered to write the document to fix a bootstrap >> >>problem in >> >>>MLDv1, I believe it should be included. >> >>Does anyone have a problem with this? Works for me. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 17:17:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08321 for ; Wed, 24 Sep 2003 17:17:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2H0c-0002Zn-UO for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 17:17:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OLHE00009899 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 17:17:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2H0c-0002Za-NP for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 17:17:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08272 for ; Wed, 24 Sep 2003 17:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2H0a-0002m4-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 17:17:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2H0a-0002m1-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 17:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2GzS-0002OM-IT; Wed, 24 Sep 2003 17:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2GyS-0002N6-D1 for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 17:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08178 for ; Wed, 24 Sep 2003 17:14:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2GyQ-0002jc-00 for ipv6@ietf.org; Wed, 24 Sep 2003 17:14:58 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2GyO-0002j5-00 for ipv6@ietf.org; Wed, 24 Sep 2003 17:14:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8OLDnb16923; Wed, 24 Sep 2003 14:13:49 -0700 X-mProtect: <200309242113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdahObVD; Wed, 24 Sep 2003 14:13:48 PDT Message-ID: <3F720992.70303@iprg.nokia.com> Date: Wed, 24 Sep 2003 14:16:02 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: Michael Thomas , Erik Nordmark , Pekka Savola , ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] References: <200309241131.h8OBV3Z07609@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas Narten wrote: >To get a real router would seem >to cost a lot more (i.e, low hundreds of $$). It has been suggested >that if I want a cheap router, I should go to eBay and by a used >low-end Cisco. Kind of shows how bad the situation actually is. > Maybe salvage a low-end PC with multiple NICs and and run Linux on it? Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 17:33:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08969 for ; Wed, 24 Sep 2003 17:33:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2HFq-0003w4-3I for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 17:33:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OLWw9N015111 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 17:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2HFo-0003qm-TR for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 17:32:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08929 for ; Wed, 24 Sep 2003 17:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2HFm-00030f-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 17:32:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2HFd-00030X-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 17:32:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2HEw-0003h2-2T; Wed, 24 Sep 2003 17:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2HED-0003fl-OC for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 17:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08838 for ; Wed, 24 Sep 2003 17:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2HE9-0002yo-00 for ipv6@ietf.org; Wed, 24 Sep 2003 17:31:13 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1A2HE9-0002yg-00 for ipv6@ietf.org; Wed, 24 Sep 2003 17:31:13 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8OLVAed057432; Wed, 24 Sep 2003 23:31:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 24 Sep 2003 23:31:01 +0200 Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipv6@ietf.org To: Thomas Narten From: Iljitsch van Beijnum In-Reply-To: <200309241131.h8OBV3Z07609@cichlid.adsl.duke.edu> Message-Id: <64B93BD2-EED6-11D7-84AE-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On woensdag, sep 24, 2003, at 13:31 Europe/Amsterdam, Thomas Narten wrote: > It's even worse than that. If you are residential user, try finding a > home router that is actually a Real Router. I've come to the > unfortunate conclusion that they no longer exist. The market > landscape has shifted dramatically. All home routers come with NAT > builtin and the functionality can simply _NOT_ be disabled. Is this surprising if you only want to pay $40? I don't think the landscape has shifted, because people never used to have routers of any kind in their homes. I spent 500 euros on a Cisco 826 ADSL router (yes, original meaning of the word although I must admit I have it do NAT) and an Apple base station, and it's well worth the additional money to have a router that actually does what I want (which includes forwarding IP unmolested) and a base station that sits transparently between the wired and wireless LANs. And this combo supports IPv6 the way it was intended. (But the router terminates a tunnel, I didn't want to spend more money on DSL service that supports native v6 although that's of course much cooler.) > Given the current feature/functionaliy/price point reality of home > routers, getting them to implement reasonable functionality as an IPv6 > router seems like it will be a rather hard sell. :-( For stuff like this all costs except shipping and support eventually approach zero when the numbers get bit enough. Putting in an IPv6 stack that takes an automatically configured IPv4 address and sets up 6to4 would take some development, but that's well worth it if you can sell a few million additional boxes because these boxes allow more than a single computer in a household to do peer to peer file sharing. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 18:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13472 for ; Wed, 24 Sep 2003 18:43:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ILg-0008NV-Qq for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 18:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OMh4FI032199 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 18:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ILg-0008NG-M8 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 18:43:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13437 for ; Wed, 24 Sep 2003 18:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ILd-000473-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 18:43:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2ILd-000470-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 18:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2IKg-000899-H2; Wed, 24 Sep 2003 18:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2IK3-00088P-4M for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 18:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13400 for ; Wed, 24 Sep 2003 18:41:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2IK0-00045y-00 for ipv6@ietf.org; Wed, 24 Sep 2003 18:41:20 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2IJz-00045r-00 for ipv6@ietf.org; Wed, 24 Sep 2003 18:41:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8OMem831916; Wed, 24 Sep 2003 15:40:48 -0700 X-mProtect: <200309242240> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd62lYUg; Wed, 24 Sep 2003 15:40:45 PDT Message-Id: <4.3.2.7.2.20030924152820.0325b830@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Sep 2003 15:38:17 -0700 To: awhite@arc.corp.mot.com From: Bob Hinden Subject: Prefix Delegation and Cascading [was why market picked up NATs] Cc: ipv6@ietf.org In-Reply-To: <3F70FA85.2BD7E8F7@motorola.com> References: <16239.39330.308606.237915@thomasm-u1.cisco.com> <20030922223812.7b62d08c.moore@cs.utk.edu> <16240.32164.181705.470876@thomasm-u1.cisco.com> <20030923190425.14581579.moore@cs.utk.edu> <1064367082.27238.15.camel@vega.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Andrew, >The other issue is cascading these setups. Currently, I am unaware of a >deployed solution for automatically telling a gateway home router what it's >IPv6 network is (Haberman has written a draft, however, and there may be >others). A second issue occurs with cascading. I have built a zeroconf >system for doing peer-peer routing, but that's different from hierarchical >delegation. These issues are very soluble, but it's a matter of how the >market wishes to deploy the solutions. As has been pointed out for prefix delegation there is the requirements document: and the DHCPv6 prefix delegation option: Both of these are now in the IESG. One cut at the cascading problem is: It would be good to get some discussion on this draft. It was intended to meet the ND proxy part of prefix delegation, but there hasn't been very much discussion to date. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 19:04:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14262 for ; Wed, 24 Sep 2003 19:04:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ifm-0001JW-2X for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 19:03:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ON3oQT005044 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 19:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ifl-0001JH-UR for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 19:03:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14229 for ; Wed, 24 Sep 2003 19:03:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ifi-0004Mz-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 19:03:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Ifi-0004Mu-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 19:03:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2If0-00014F-6X; Wed, 24 Sep 2003 19:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2IeO-00013e-5v for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 19:02:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14167 for ; Wed, 24 Sep 2003 19:02:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2IeK-0004M4-00 for ipv6@ietf.org; Wed, 24 Sep 2003 19:02:20 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2IeK-0004Lb-00 for ipv6@ietf.org; Wed, 24 Sep 2003 19:02:20 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8ON1fA16254; Wed, 24 Sep 2003 16:01:41 -0700 X-mProtect: <200309242301> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbrvZh1; Wed, 24 Sep 2003 16:01:38 PDT Message-Id: <4.3.2.7.2.20030924154155.030ed790@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Sep 2003 15:59:13 -0700 To: Thomas Narten From: Bob Hinden Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Cc: ipv6@ietf.org In-Reply-To: <200309241131.h8OBV3Z07609@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Thomas, >It's even worse than that. If you are residential user, try finding a >home router that is actually a Real Router. I've come to the >unfortunate conclusion that they no longer exist. The market >landscape has shifted dramatically. All home routers come with NAT >builtin and the functionality can simply _NOT_ be disabled. They do exist, but I agree with you not at the very low end. When I switched DSL providers (actually my old one decided it could no longer support my area), my new one supplied me with a small router (not one of brand names one can buy in places like Fry's). This box was a real router (e.g., it even supported RIPv2) and had NAT that could be enabled/disabled. Note that I did pay extra for a higher grade of DSL and a block of public IPv4 addresses. I figured it would be hypocritical for me to run NAT at home and work on IPv6 in the IETF, so I was willing to pay a bit more money. Everyone has to make their own decision. It's a version of "think globally, act locally". >Given the current feature/functionaliy/price point reality of home >routers, getting them to implement reasonable functionality as an IPv6 >router seems like it will be a rather hard sell. :-( I think it will be driven by vendors shipping products with applications that make good of IPv6 and that people want to run. This will give the home router vendors some real incentive to add IPv6 support. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Sep 24 23:49:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22307 for ; Wed, 24 Sep 2003 23:49:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2N86-0006ub-Go for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 23:49:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8P3nMBY026563 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 23:49:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2N86-0006uM-BH for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 23:49:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22274 for ; Wed, 24 Sep 2003 23:49:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2N84-0007Cu-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 23:49:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2N83-0007Cq-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 23:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2N6n-0006gc-VB; Wed, 24 Sep 2003 23:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2N6c-0006gN-Ab for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 23:47:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22253 for ; Wed, 24 Sep 2003 23:47:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2N6a-0007CV-00 for ipv6@ietf.org; Wed, 24 Sep 2003 23:47:48 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A2N6Z-0007CM-00 for ipv6@ietf.org; Wed, 24 Sep 2003 23:47:47 -0400 Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Sep 2003 20:47:17 -0700 Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOC+g1oWVEhlcthSr2J/Js5WAsgUwAGf5DQ From: "Michel Py" To: "Bob Hinden" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Bob, > Bob Hinden wrote: > I figured it would be hypocritical for me to run NAT at home > and work on IPv6 in the IETF I don't think so. I am not ashamed of running IPv4 NAT at home and working on IPv6; it's a matter of money. > so I was willing to pay a bit more money. If not indiscrete, how many IPv4 addresses and how much $$$ are we talking about? Given the number of hosts I have on my home setup (I need a /27) the only realistic option I have to run NAT-free is to bring in a T1 (as no reliable residential broadband provider is willing to give me a /27), which still is $500/mo (local loop + transit) instead of the $49/mo I am paying for my aDSL. I'm sorry, but this is a car payment for a Mercedes-Benz, and unless someone on the list is willing to fork out $450/mo I will stick with NAT. The number of addresses will not be an issue with IPv6, but this not why people would use IPv6 NAT if given a working box. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 25 00:06:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22940 for ; Thu, 25 Sep 2003 00:06:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NO4-0007yf-4A for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 00:05:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8P45qG4030659 for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 00:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NO3-0007yQ-UI for ipv6-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 00:05:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22901 for ; Thu, 25 Sep 2003 00:05:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2NO1-0007Qu-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 00:05:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2NO1-0007Qp-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 00:05:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NNH-0007l5-Jn; Thu, 25 Sep 2003 00:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NMz-0007kd-Mh for ipv6@optimus.ietf.org; Thu, 25 Sep 2003 00:04:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22868 for ; Thu, 25 Sep 2003 00:04:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2NMx-0007Pw-00 for ipv6@ietf.org; Thu, 25 Sep 2003 00:04:43 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A2NMw-0007Pb-00 for ipv6@ietf.org; Thu, 25 Sep 2003 00:04:43 -0400 Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Sep 2003 21:04:13 -0700 Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Thread-Index: AcOCtJ9q+zAWFhdJR96U1wHUugym8wAZOVyQ From: "Michel Py" To: "Eliot Lear" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Eliot, > Eliot Lear wrote: > DING DING.... IPv4-0-Meter just went off. > Why is this an issue in v6-land, assuming you can get a v6 > consumer networking device? My point exactly. Can Cisco/Linksys deliver a $40 IPv6 consumer device? :-D Hey, I'd fork out the $40 just to see it if it comes with TAC support. Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 25 00:28:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23618 for ; Thu, 25 Sep 2003 00:28:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NjQ-0000qi-KM for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 00:27:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8P4RuPx003265 for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 00:27:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NjQ-0000qZ-AT for ipv6-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 00:27:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23588 for ; Thu, 25 Sep 2003 00:27:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2NjN-0007dH-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 00:27:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2NjN-0007dE-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 00:27:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NiX-0000d6-Ne; Thu, 25 Sep 2003 00:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2NiH-0000cL-8q for ipv6@optimus.ietf.org; Thu, 25 Sep 2003 00:26:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23556 for ; Thu, 25 Sep 2003 00:26:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2NiE-0007cE-00 for ipv6@ietf.org; Thu, 25 Sep 2003 00:26:42 -0400 Received: from 113.cust12.nsw.dsl.ozemail.com.au ([203.103.155.113] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1A2NiD-0007bl-00 for ipv6@ietf.org; Thu, 25 Sep 2003 00:26:41 -0400 Received: from Dupy2.nosense.org (113.cust12.nsw.dsl.ozemail.com.au [203.103.155.113]) by nosense.org (Postfix) with SMTP id E68C23F024 for ; Thu, 25 Sep 2003 13:56:48 +0930 (CST) Date: Thu, 25 Sep 2003 13:56:47 +0930 From: Mark Smith To: ipv6@ietf.org Subject: Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-Id: <20030925135647.423fae33.ipv6@nosense.org> In-Reply-To: <4.3.2.7.2.20030924154155.030ed790@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030924154155.030ed790@mailhost.iprg.nokia.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, On Wed, 24 Sep 2003 15:59:13 -0700 Bob Hinden wrote: > > I think it will be driven by vendors shipping products with applications > that make good of IPv6 and that people want to run. This will give the > home router vendors some real incentive to add IPv6 support. > John Walker has an interesting point of view on NAT, in his Q&A on why he is EOLing his Speak Freely software (http://www.fourmilab.ch/speakfree/eol/), under the question "What do you mean--isn't the Internet still in its infancy?" " A user behind a NAT box is no longer a peer to other sites on the Internet. Since the user no longer has an externally visible Internet Protocol (IP) address (fixed or variable), there is no way (in the general case--there may be "workarounds" for specific NAT boxes, but they're basically exploiting bugs which will probably eventually be fixed) for sites to open connections or address packets to his machine. The user is demoted to acting exclusively as a client. While the user can contact and freely exchange packets with sites not behind NAT boxes, he cannot be reached by connections which originate at other sites. In economic terms, the NATted user has become a consumer of services provided by a higher-ranking class of sites, producers or publishers, not subject to NAT. There are powerful forces, including government, large media organisations, and music publishers who think this situation is just fine. In essence, every time a user--they love the word "consumer"--goes behind a NAT box, a site which was formerly a peer to their own sites goes dark, no longer accessible to others on the Internet, while their privileged sites remain. The lights are going out all over the Internet. My paper, The Digital Imprimatur, discusses the technical background, economic motivations, and social consequences of this in much more (some will say tedious) detail. Suffice it to say that, as the current migration of individual Internet users to broadband connections with NAT proceeds, the population of users who can use a peer to peer telephony product like Speak Freely will shrink apace. It is irresponsible to encourage people to buy into a technology which will soon cease to work." It was technically obvious that NAT turns end-users into consumers rather than peers, but it hadn't occured to me that there would be non-networking and other market forces that would be quite happy for that trend to continue. As much as the uses of it commonly tend to be illegal, it seems that the only killer app that has emerged for which IPv6 would be a real benefit is peer to peer file sharing eg., Kazaa. Maybe we should suggest to them that they work on simple methods to move their end-users from IPv4 to IPv6, rather than spending time developing NAT work arounds. I wonder if Micrsoft's IPv6 stack license terms would permit it to be distributed as "adware" :-) Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 25 01:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25864 for ; Thu, 25 Sep 2003 01:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Oy3-000534-SN for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 01:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8P5l7Zk019400 for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 01:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Oy3-00052p-MB for ipv6-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 01:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25834 for ; Thu, 25 Sep 2003 01:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Oy0-0000gc-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 01:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Oy0-0000gZ-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 01:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ox0-0004op-46; Thu, 25 Sep 2003 01:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ow5-0004nP-GQ for ipv6@optimus.ietf.org; Thu, 25 Sep 2003 01:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25756 for ; Thu, 25 Sep 2003 01:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ow2-0000fI-00 for ipv6@ietf.org; Thu, 25 Sep 2003 01:45:02 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ow1-0000ev-00 for ipv6@ietf.org; Thu, 25 Sep 2003 01:45:01 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8P5iPK30563; Thu, 25 Sep 2003 08:44:25 +0300 Date: Thu, 25 Sep 2003 08:44:24 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: awhite@arc.corp.mot.com, Subject: Re: Prefix Delegation and Cascading [was why market picked up NATs] In-Reply-To: <4.3.2.7.2.20030924152820.0325b830@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 24 Sep 2003, Bob Hinden wrote: [...] > One cut at the cascading problem is: > > > > It would be good to get some discussion on this draft. It was intended to > meet the ND proxy part of prefix delegation, but there hasn't been very > much discussion to date. I think there was some discussion after Vienna. I think there was something looking like consensus that the document's applicability should be cleared up and some the mechanisms simplified. I don't think much is likely to happen prior to an updated document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 25 14:14:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11425 for ; Thu, 25 Sep 2003 14:14:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2acc-0003RM-0Z for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 14:13:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PIDj0Q013218 for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 14:13:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2acb-0003R7-O9 for ipv6-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 14:13:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11361 for ; Thu, 25 Sep 2003 14:13:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2acY-0003JV-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 14:13:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2acY-0003JF-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 14:13:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2aaw-0002wo-LR; Thu, 25 Sep 2003 14:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2aaf-0002vr-Tj for ipv6@optimus.ietf.org; Thu, 25 Sep 2003 14:11:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11145 for ; Thu, 25 Sep 2003 14:11:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2aad-0003FO-00 for ipv6@ietf.org; Thu, 25 Sep 2003 14:11:43 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2aac-0003F8-00 for ipv6@ietf.org; Thu, 25 Sep 2003 14:11:42 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8PI5l205638; Thu, 25 Sep 2003 11:05:47 -0700 X-mProtect: <200309251805> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmiZSBH; Thu, 25 Sep 2003 11:05:45 PDT Message-Id: <4.3.2.7.2.20030925103742.02205a10@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Sep 2003 11:03:15 -0700 To: "Michel Py" From: Bob Hinden Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Michel, >If not indiscrete, how many IPv4 addresses and how much $$$ are we >talking about? Given the number of hosts I have on my home setup (I need >a /27) the only realistic option I have to run NAT-free is to bring in a >T1 (as no reliable residential broadband provider is willing to give me >a /27), which still is $500/mo (local loop + transit) instead of the >$49/mo I am paying for my aDSL. I'm sorry, but this is a car payment for >a Mercedes-Benz, and unless someone on the list is willing to fork out >$450/mo I will stick with NAT. I pay about $80. a month and have a /28 and a /30. I will provide the details and the name of the ISP off list. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Sep 25 19:12:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26905 for ; Thu, 25 Sep 2003 19:12:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fHU-0002WT-6D for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 19:12:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PNCG47009691 for ipv6-archive@odin.ietf.org; Thu, 25 Sep 2003 19:12:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fHU-0002WE-16 for ipv6-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 19:12:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26862 for ; Thu, 25 Sep 2003 19:12:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2fHS-0007fO-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 19:12:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2fHR-0007fI-00 for ipv6-web-archive@ietf.org; Thu, 25 Sep 2003 19:12:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fGI-0002Hj-3a; Thu, 25 Sep 2003 19:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fGD-0002HN-EE for ipv6@optimus.ietf.org; Thu, 25 Sep 2003 19:10:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26803 for ; Thu, 25 Sep 2003 19:10:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2fGA-0007dm-00 for ipv6@ietf.org; Thu, 25 Sep 2003 19:10:54 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2fG9-0007dX-00 for ipv6@ietf.org; Thu, 25 Sep 2003 19:10:53 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8PNAE825606; Thu, 25 Sep 2003 16:10:14 -0700 X-mProtect: <200309252310> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwwsSee; Thu, 25 Sep 2003 16:10:11 PDT Message-Id: <4.3.2.7.2.20030925160504.03283e98@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Sep 2003 16:07:44 -0700 To: ipv6@ietf.org From: Bob Hinden Subject: [I-D ACTION:draft-ietf-ipv6-unique-local-addr-01.txt] In-Reply-To: <200309241409.KAA15966@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 07:09 AM 9/24/2003, 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 IP Version 6 Working Group Working Group >of the IETF. > > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-unique-local-addr-01.txt > Pages : 15 > Date : 2003-9-24 > The changes in this draft based on discussion on the mailing list are: o Removed example of PIR as an example of an allocation authority and clarified the text that the IANA should delegate the centrally assigned prefix to an allocation authority. o Changed sample code for generating pseudo random Global IDs to not require any human input. Changes from using birthday to unique token (e.g., EUI-64, serial number, etc.) available on machine running the algorithm. o Added a new section analyzing the uniqueness properties of the pseudo random number algorithm. o Added text to recommend that centrally assigned local addresses be used for site planning extensive inter-site communication. o Clarified that domain border routers should follow site border router recommendations. o Clarified that AAAA DNS records should not be installed in the global DNS. o Several editorial changes. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 01:27:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08595 for ; Fri, 26 Sep 2003 01:27:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2l7l-0005ih-CP for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 01:26:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q5Qblp021981 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 01:26:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2l7l-0005iS-7h for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 01:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08560 for ; Fri, 26 Sep 2003 01:26:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2l7i-0003j4-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 01:26:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2l7h-0003j1-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 01:26:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2l7C-0005cI-76; Fri, 26 Sep 2003 01:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2l6o-0005bl-A1 for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 01:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08523 for ; Fri, 26 Sep 2003 01:25:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2l6l-0003i1-00 for ipv6@ietf.org; Fri, 26 Sep 2003 01:25:35 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2l6k-0003hm-00 for ipv6@ietf.org; Fri, 26 Sep 2003 01:25:34 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8Q5Osh21144; Fri, 26 Sep 2003 08:24:55 +0300 Date: Fri, 26 Sep 2003 08:24:54 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: ipv6@ietf.org Subject: Re: Updates to Neighbor Discovery and Stateless Autoconfiguration In-Reply-To: <3F70A682.9060908@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 23 Sep 2003, Brian Haberman wrote: > One of our charter items is to produce updates of > RFC 2461 and 2462 in order to progress them to Draft Standard. > As a part of that effort, I would like to bring to the Work > Group's attention, some work that has been done in SEND. > > http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-03.txt > outlines several security issues that exist in NDP and in > Stateless Autonconfiguration. So as a part of the effort to > revise 2461 and 2462, I am soliciting the WG's thoughts on how > to incorporate the work done in the SEND document into the > base specifications. My primary goal is to come to a balance > of existing functionality vs. enhanced security capability. The SEND work is not the only thing which has proposed (or uncovered a potential need for) modifications ini RFC2461/2462. Some requests have surfaced already in the Mobile IP space as well. I'd encourage you to go through the archives. There has been a significant amount of discussion on many ambiguous pieces of the spec (e.g. dead code in RFC2462 section 5.5.3 e, ambiguities about decrementing the Lifetime counters, etc.). I'd hope that someone (e.g. one of the original authors) would have archived the relevant threads for later perusal. In addition, draft-roy-v6ops-v6onbydefault-01.txt (will be updated soon to v6ops WG document) has identified a set of serious problems with the "on-link by default" rule. Expect a companion document describing the tradeoffs of changing RFC2461/2 in this regard shortly. Hope this helps to get into the swing.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 01:37:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08916 for ; Fri, 26 Sep 2003 01:37:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2lID-0006P9-1h for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 01:37:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q5bORl024610 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 01:37:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2lIC-0006Om-8D for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 01:37:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08865 for ; Fri, 26 Sep 2003 01:37:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2lI9-0003qB-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 01:37:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2lI8-0003q8-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 01:37:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2lHr-0006Di-0z; Fri, 26 Sep 2003 01:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2lHc-0006Cr-8S for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 01:36:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08852 for ; Fri, 26 Sep 2003 01:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2lHY-0003ph-00 for ipv6@ietf.org; Fri, 26 Sep 2003 01:36:44 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1A2lHY-0003pY-00 for ipv6@ietf.org; Fri, 26 Sep 2003 01:36:44 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 26 Sep 2003 01:36:08 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D64@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Brian Haberman Cc: ipv6@ietf.org Subject: RE: Updates to Neighbor Discovery and Stateless Autoconfiguration Date: Fri, 26 Sep 2003 01:35:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Also you might want to consider the discussions on: - Address resolution on p2p links - Clarifying the meaning of the M and O bits - Other MIP related discussions Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, September 26, 2003 1:25 AM > To: Brian Haberman > Cc: ipv6@ietf.org > Subject: Re: Updates to Neighbor Discovery and Stateless > Autoconfiguration > > > On Tue, 23 Sep 2003, Brian Haberman wrote: > > One of our charter items is to produce updates of > > RFC 2461 and 2462 in order to progress them to Draft Standard. > > As a part of that effort, I would like to bring to the Work > > Group's attention, some work that has been done in SEND. > > > > http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-03.txt > > outlines several security issues that exist in NDP and in > > Stateless Autonconfiguration. So as a part of the effort to > > revise 2461 and 2462, I am soliciting the WG's thoughts on how > > to incorporate the work done in the SEND document into the > > base specifications. My primary goal is to come to a balance > > of existing functionality vs. enhanced security capability. > > The SEND work is not the only thing which has proposed (or > uncovered a > potential need for) modifications ini RFC2461/2462. Some > requests have > surfaced already in the Mobile IP space as well. > > I'd encourage you to go through the archives. There has been a > significant amount of discussion on many ambiguous pieces of the spec > (e.g. dead code in RFC2462 section 5.5.3 e, ambiguities > about decrementing > the Lifetime counters, etc.). I'd hope that someone (e.g. > one of the > original authors) would have archived the relevant threads for later > perusal. > > In addition, draft-roy-v6ops-v6onbydefault-01.txt (will be > updated soon to > v6ops WG document) has identified a set of serious problems with the > "on-link by default" rule. Expect a companion document > describing the > tradeoffs of changing RFC2461/2 in this regard shortly. > > Hope this helps to get into the swing.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 07:19:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00638 for ; Fri, 26 Sep 2003 07:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qch-0005P7-4f for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 07:18:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QBItET020767 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 07:18:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qcg-0005Os-VS for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 07:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00597 for ; Fri, 26 Sep 2003 07:18:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2qcg-0007Ic-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 07:18:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2qcg-0007IZ-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 07:18:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qbq-0005IZ-IB; Fri, 26 Sep 2003 07:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qbg-0005Hy-EE for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 07:17:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00558 for ; Fri, 26 Sep 2003 07:17:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2qbf-0007HX-00 for ipv6@ietf.org; Fri, 26 Sep 2003 07:17:51 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A2qbf-0007HS-00 for ipv6@ietf.org; Fri, 26 Sep 2003 07:17:51 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h8QBHJV17581; Fri, 26 Sep 2003 04:17:19 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6d-51.chvlva.adelphia.net [67.21.61.51]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h8QBHYtX026906 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 26 Sep 2003 04:17:38 -0700 Message-ID: <3F742038.2050505@innovationslab.net> Date: Fri, 26 Sep 2003 07:17:12 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: Updates to Neighbor Discovery and Stateless Autoconfiguration References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Tue, 23 Sep 2003, Brian Haberman wrote: > >> One of our charter items is to produce updates of >>RFC 2461 and 2462 in order to progress them to Draft Standard. >>As a part of that effort, I would like to bring to the Work >>Group's attention, some work that has been done in SEND. >> >>http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-03.txt >>outlines several security issues that exist in NDP and in >>Stateless Autonconfiguration. So as a part of the effort to >>revise 2461 and 2462, I am soliciting the WG's thoughts on how >>to incorporate the work done in the SEND document into the >>base specifications. My primary goal is to come to a balance >>of existing functionality vs. enhanced security capability. > > > The SEND work is not the only thing which has proposed (or uncovered a > potential need for) modifications ini RFC2461/2462. Some requests have > surfaced already in the Mobile IP space as well. Agreed. My point was more to make the WG aware of the issues raised in the SEND document. The issues raised in other places (e.g. MIPv6) are just as important. > > I'd encourage you to go through the archives. There has been a > significant amount of discussion on many ambiguous pieces of the spec > (e.g. dead code in RFC2462 section 5.5.3 e, ambiguities about decrementing > the Lifetime counters, etc.). I'd hope that someone (e.g. one of the > original authors) would have archived the relevant threads for later > perusal. > > In addition, draft-roy-v6ops-v6onbydefault-01.txt (will be updated soon to > v6ops WG document) has identified a set of serious problems with the > "on-link by default" rule. Expect a companion document describing the > tradeoffs of changing RFC2461/2 in this regard shortly. Great. I will look for its publication. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 07:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00693 for ; Fri, 26 Sep 2003 07:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qcq-0005Vy-0E for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 07:19:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QBJ3pI021192 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 07:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qcp-0005Vj-KW for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 07:19:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00601 for ; Fri, 26 Sep 2003 07:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2qcp-0007Ik-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 07:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2qco-0007Ih-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 07:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qco-0005Q6-Dj; Fri, 26 Sep 2003 07:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2qcQ-0005Lr-TN for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 07:18:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00581 for ; Fri, 26 Sep 2003 07:18:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2qcQ-0007IG-00 for ipv6@ietf.org; Fri, 26 Sep 2003 07:18:38 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A2qcP-0007Hn-00 for ipv6@ietf.org; Fri, 26 Sep 2003 07:18:37 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h8QBI4V17587; Fri, 26 Sep 2003 04:18:04 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6d-51.chvlva.adelphia.net [67.21.61.51]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h8QBIJtX026909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 26 Sep 2003 04:18:23 -0700 Message-ID: <3F742065.5090203@innovationslab.net> Date: Fri, 26 Sep 2003 07:17:57 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'Pekka Savola'" , ipv6@ietf.org Subject: Re: Updates to Neighbor Discovery and Stateless Autoconfiguration References: <748C6D0A58C0F94CA63C198B6674697A01922D64@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D64@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes. Thanks for the data points, Hesham. Regards, Brian Soliman Hesham wrote: > Also you might want to consider the discussions on: > > - Address resolution on p2p links > - Clarifying the meaning of the M and O bits > - Other MIP related discussions > > Hesham > > > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Friday, September 26, 2003 1:25 AM > > To: Brian Haberman > > Cc: ipv6@ietf.org > > Subject: Re: Updates to Neighbor Discovery and Stateless > > Autoconfiguration > > > > > > On Tue, 23 Sep 2003, Brian Haberman wrote: > > > One of our charter items is to produce updates of > > > RFC 2461 and 2462 in order to progress them to Draft Standard. > > > As a part of that effort, I would like to bring to the Work > > > Group's attention, some work that has been done in SEND. > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-03.txt > > > outlines several security issues that exist in NDP and in > > > Stateless Autonconfiguration. So as a part of the effort to > > > revise 2461 and 2462, I am soliciting the WG's thoughts on how > > > to incorporate the work done in the SEND document into the > > > base specifications. My primary goal is to come to a balance > > > of existing functionality vs. enhanced security capability. > > > > The SEND work is not the only thing which has proposed (or > > uncovered a > > potential need for) modifications ini RFC2461/2462. Some > > requests have > > surfaced already in the Mobile IP space as well. > > > > I'd encourage you to go through the archives. There has been a > > significant amount of discussion on many ambiguous pieces of the spec > > (e.g. dead code in RFC2462 section 5.5.3 e, ambiguities > > about decrementing > > the Lifetime counters, etc.). I'd hope that someone (e.g. > > one of the > > original authors) would have archived the relevant threads for later > > perusal. > > > > In addition, draft-roy-v6ops-v6onbydefault-01.txt (will be > > updated soon to > > v6ops WG document) has identified a set of serious problems with the > > "on-link by default" rule. Expect a companion document > > describing the > > tradeoffs of changing RFC2461/2 in this regard shortly. > > > > Hope this helps to get into the swing.. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 12:14:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12217 for ; Fri, 26 Sep 2003 12:14:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vEf-0003qS-9W for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 12:14:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QGEPhC014774 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 12:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vEf-0003qD-4B for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 12:14:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12197 for ; Fri, 26 Sep 2003 12:14:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vEd-0002hg-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 12:14:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2vEd-0002hd-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 12:14:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vBP-0003U8-BD; Fri, 26 Sep 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vAV-0003T1-D6 for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 12:10:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12106 for ; Fri, 26 Sep 2003 12:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vAT-0002f5-00 for ipv6@ietf.org; Fri, 26 Sep 2003 12:10:06 -0400 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 1A2vAT-0002ez-00 for ipv6@ietf.org; Fri, 26 Sep 2003 12:10:05 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h8QG9eT72316; Fri, 26 Sep 2003 12:09:40 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h8QG9ev56763; Fri, 26 Sep 2003 12:09:40 -0400 (EDT) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id MAA26271; Fri, 26 Sep 2003 12:09:39 -0400 (EDT) Subject: Re: [I-D ACTION:draft-ietf-ipv6-unique-local-addr-01.txt] From: Steven Blake Reply-To: slblake@torrentnet.com To: Bob Hinden Cc: ipv6@ietf.org In-Reply-To: <4.3.2.7.2.20030925160504.03283e98@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030925160504.03283e98@mailhost.iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Sep 2003 12:09:39 -0400 Message-Id: <1064592579.342.477.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have some comments about Section 3.2.1 (Centrally Assigned Global IDs) 1. I don't understand the necessity for the requirement to generate IDs consistent with [RANDOM]. The IDs need to be unique and sufficiently "randomized" (one could argue how important this need really is) so that there is no plausible way to aggregate them. I don't think it is necessary to be unable to guess the date or relative order in which a particular ID was allocated, however. 2. I don't find the argument for a single allocation authority compelling. It is still possible for a single authority (i.e., IANA) to delegate blocks of the global ID space to multiple registries. The naive way would be to delegate lists of random numbers generated by IANA. A more elegant way would be to delegate ranges in the sequence space of a non-repeating PRNG (e.g., maximal period 40-bit LFSR). Note that the requirement (1) above precludes this latter method. 3. I don't believe it is essential to have alternative registration methods besides web and e-mail. Anyone can establish a new network using only PA addresses (and locally assigned local IDs if necessary) before acquiring a "centrally assigned" local ID. One could also ask a friend with connectivity, or go to a local library. Requiring non-automated means of registration significantly drives up the allocation cost. 4. I don't believe that it is necessary for the allocation registry to escrow each allocation; I think it is sufficient for the allocation recipient to do so. In a dispute one can prove that he or she owns an allocation by producing a non-repudiatable (e.g., signed) message from a registry. The registries would only have to escrow their public keys. 5. I don't believe that the 10 euro fee is appropriate. I suspect that the cost to collect the money is substantially higher than the cost to manage the registry infrastructure, especially if the requirements are relaxed sufficiently such that the process can be fully automated. Although I'm not volunteering to foot the costs of a registry myself, I suspect sponsors could be found to operate them. 6. I believe a centralized registry is more susceptible to a DoS attack. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 12:19:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12377 for ; Fri, 26 Sep 2003 12:19:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vIp-0004ED-Rp for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 12:18:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QGIhLV016247 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 12:18:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vIp-0004Dy-Lq for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 12:18:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12348 for ; Fri, 26 Sep 2003 12:18:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vIo-0002l7-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 12:18:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2vIn-0002l4-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 12:18:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vGE-0003rb-Dl; Fri, 26 Sep 2003 12:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vGA-0003r9-1S for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 12:15:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12244 for ; Fri, 26 Sep 2003 12:15:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vG8-0002hz-00 for ipv6@ietf.org; Fri, 26 Sep 2003 12:15:56 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1A2vG7-0002hw-00 for ipv6@ietf.org; Fri, 26 Sep 2003 12:15:56 -0400 Message-ID: <011901c38449$8132b950$956015ac@dclkempt40> From: "James Kempf" To: "Brian Haberman" , "Pekka Savola" Cc: References: <3F742038.2050505@innovationslab.net> Subject: Re: Updates to Neighbor Discovery and Stateless Autoconfiguration Date: Fri, 26 Sep 2003 09:16:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Agreed. My point was more to make the WG aware of the issues raised > in the SEND document. The issues raised in other places (e.g. MIPv6) > are just as important. > Perhaps it would be helpful if the MIP WG would come up with a draft that collected the issues in one place. I know some of them were discussed in the DNA BOF, but were they specifically related to RFC 2461/2 rather than being generic for IP movement detection? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 12:50:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13478 for ; Fri, 26 Sep 2003 12:50:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vn2-0006D0-Vu for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 12:49:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QGnuqb023860 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 12:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vn2-0006Cl-GQ for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 12:49:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13446 for ; Fri, 26 Sep 2003 12:49:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vn0-00039Q-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 12:49:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2vn0-00039N-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 12:49:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vkE-0005s5-Iw; Fri, 26 Sep 2003 12:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vjL-0005pd-Dd for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 12:46:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13358 for ; Fri, 26 Sep 2003 12:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vjJ-00037w-00 for ipv6@ietf.org; Fri, 26 Sep 2003 12:46:05 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2vjI-00037F-00 for ipv6@ietf.org; Fri, 26 Sep 2003 12:46:05 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8QGjIC01331; Fri, 26 Sep 2003 09:45:18 -0700 X-mProtect: <200309261645> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrtUS9b; Fri, 26 Sep 2003 09:45:17 PDT Message-ID: <3F746DAD.1000509@iprg.nokia.com> Date: Fri, 26 Sep 2003 09:47:41 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'Pekka Savola'" , Brian Haberman , ipv6@ietf.org Subject: Re: Updates to Neighbor Discovery and Stateless Autoconfiguration References: <748C6D0A58C0F94CA63C198B6674697A01922D64@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Also clarify the processing of prefix options in Router Advertisements with the L bit not set. Fred ftemplin@iprg.nokia.com Soliman Hesham wrote: >Also you might want to consider the discussions on: > >- Address resolution on p2p links >- Clarifying the meaning of the M and O bits >- Other MIP related discussions > >Hesham > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 16:13:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22047 for ; Fri, 26 Sep 2003 16:13:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2yxC-0007hH-O3 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 16:12:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QKCcDx029583 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 16:12:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2yxC-0007h4-JV for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 16:12:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22018 for ; Fri, 26 Sep 2003 16:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2yxA-0005GV-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 16:12:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2yxA-0005GR-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 16:12:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ywc-0007bC-Ct; Fri, 26 Sep 2003 16:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2yw5-0007ag-SF for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 16:11:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21998 for ; Fri, 26 Sep 2003 16:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2yw4-0005GA-00 for ipv6@ietf.org; Fri, 26 Sep 2003 16:11:28 -0400 Received: from creativedynamo.com ([64.65.66.163] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 1A2yw3-0005Ff-00 for ipv6@ietf.org; Fri, 26 Sep 2003 16:11:27 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h8QKDOZt003133; Fri, 26 Sep 2003 10:13:24 -1000 Received: from localhost (tony@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) with ESMTP id h8QKDNJk003130; Fri, 26 Sep 2003 10:13:24 -1000 X-Authentication-Warning: localhost.localdomain: tony owned process doing -bs Date: Fri, 26 Sep 2003 10:13:23 -1000 (HST) From: Antonio Querubin X-X-Sender: tony@localhost.localdomain To: awhite@arc.corp.mot.com cc: ipv6@ietf.org Subject: Re: why market picked up NATs In-Reply-To: <3F70FA85.2BD7E8F7@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 24 Sep 2003, Andrew White wrote: > I think it's a little more complex. > > Let's leave aside the daisy-chained NATs for a moment (which is a nightmare > waiting to happen) and look at the home deployment scenario. > > Using 6to4, it is reasonably easy to build an all-in-one IPv6 home gateway > right now. Currently, it's advantageous if the gateway does both IPv4 and > IPv6, since DNS support virtually requires v4. At this point, you have > end-to-end connectivity from any host (something you don't get with NAT), > less whatever your firewall chooses to filter out. > > The real issue is application support. In the consumer market, OS X has > IPv6, but it's hidden from most users. Win XP also has IPv6, but it > requires a bunch of chicanery to get it working. The real killer is that Actually, the Windows XP implementation is pretty much plug and play. Run 'ipv6 install' and it's ready to do 6to4 automatically. If it's already attached to a network that has an IPv6 router it'll favor the advertised local router over the tunnel and obtain it's prefix from the local router. One of the 6to4 gateway addresses it automatically uses is the RFC 3068 anycast 6to4 relay. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 22:25:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03180 for ; Fri, 26 Sep 2003 22:25:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A34lI-00068O-G2 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 22:24:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8R2OiMU023574 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 22:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A34lI-000689-B5 for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 22:24:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03150 for ; Fri, 26 Sep 2003 22:24:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A34lF-0000fi-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 22:24:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A34lE-0000ff-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 22:24:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A34kc-000621-Eb; Fri, 26 Sep 2003 22:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A34kH-000614-Ow for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 22:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03118 for ; Fri, 26 Sep 2003 22:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A34kE-0000en-00 for ipv6@ietf.org; Fri, 26 Sep 2003 22:23:38 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1A34kD-0000ee-00 for ipv6@ietf.org; Fri, 26 Sep 2003 22:23:37 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HLU00501PAC74@mailout1.samsung.com> for ipv6@ietf.org; Sat, 27 Sep 2003 11:23:00 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLU000MEPACTL@mailout1.samsung.com> for ipv6@ietf.org; Sat, 27 Sep 2003 11:23:00 +0900 (KST) Received: from LocalHost ([165.213.91.136]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HLU00MAIPAATL@mmp1.samsung.com> for ipv6@ietf.org; Sat, 27 Sep 2003 11:23:00 +0900 (KST) Date: Sat, 27 Sep 2003 11:23:05 +0900 From: Ron Lee Subject: IPv6 to IPv4 translator To: ipv6@ietf.org Message-id: <000001c3849e$498ef270$885bd5a5@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello, I am wondering if there are commercially availble IPv6 to IPv4 translators with high throughput. I am also curious if the testbeds or commercial IPv6 access services are allowing IPv6-only subscribers to communicate with IPv4-only hosts. Any tip of information is welcome. Please let me know. Thanks in advance. PS: If this kind of question is irrelevant or unwelcome here, say so please. ========================================================== Ron Lee, Ph.D. Senior Engineer Telecommunication Division, Samsung Electronics Co., Ltd Suwon, South Korea Office: +82-31-279-3615 Mobile: +82-505-717-7217 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Sep 26 23:11:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04483 for ; Fri, 26 Sep 2003 23:11:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A35UM-0000Jc-1v for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 23:11:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8R3BH5A001210 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 23:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A35UL-0000JR-IY for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 23:11:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04453 for ; Fri, 26 Sep 2003 23:11:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A35UG-00019D-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 23:11:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A35UE-00019A-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 23:11:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A35U7-0000DS-DM; Fri, 26 Sep 2003 23:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A35U3-0000D3-57 for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 23:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04445 for ; Fri, 26 Sep 2003 23:10:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A35Tx-000194-00 for ipv6@ietf.org; Fri, 26 Sep 2003 23:10:53 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1A35Tw-00018v-00 for ipv6@ietf.org; Fri, 26 Sep 2003 23:10:52 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HLU00501RH9FI@mailout2.samsung.com> for ipv6@ietf.org; Sat, 27 Sep 2003 12:10:21 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLU00NEGRH92W@mailout2.samsung.com> for ipv6@ietf.org; Sat, 27 Sep 2003 12:10:21 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HLU00CNERH93Z@mmp2.samsung.com> for ipv6@ietf.org; Sat, 27 Sep 2003 12:10:21 +0900 (KST) Date: Sat, 27 Sep 2003 12:10:30 +0900 From: Soohong Daniel Park Subject: RE: Updates to Neighbor Discovery and Stateless Autoconfiguration In-reply-to: <011901c38449$8132b950$956015ac@dclkempt40> To: "'James Kempf'" , "'Brian Haberman'" , "'Pekka Savola'" Cc: ipv6@ietf.org Message-id: <002a01c384a4$e8551960$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT IPv6 DAD Optimization is being discussed in DNA. IPv6 DAD Optimization Goals and Requirements http://home.megapass.co.kr/~natpp00/dad-optimization.txt Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of James Kempf > Sent: Saturday, September 27, 2003 1:16 AM > To: Brian Haberman; Pekka Savola > Cc: ipv6@ietf.org > Subject: Re: Updates to Neighbor Discovery and Stateless > Autoconfiguration > > > > Agreed. My point was more to make the WG aware of the issues raised > > in the SEND document. The issues raised in other places > (e.g. MIPv6) > > are just as important. > > > > Perhaps it would be helpful if the MIP WG would come up with > a draft that > collected the issues in one place. I know some of them were > discussed in the > DNA BOF, but were they specifically related to RFC 2461/2 > rather than being > generic for IP movement detection? > > jak > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 28 00:03:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23858 for ; Sun, 28 Sep 2003 00:03:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Slh-0001Kz-SE for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 00:02:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8S42jog005137 for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 00:02:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Slh-0001Km-Oa for ipv6-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 00:02:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23807 for ; Sun, 28 Sep 2003 00:02:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Slf-0004wL-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 00:02:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3Slf-0004wH-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 00:02:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Sk4-0001C6-HR; Sun, 28 Sep 2003 00:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Sk0-00019g-0K for ipv6@optimus.ietf.org; Sun, 28 Sep 2003 00:01:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23737 for ; Sun, 28 Sep 2003 00:00:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Sjx-0004rl-00 for ipv6@ietf.org; Sun, 28 Sep 2003 00:00:57 -0400 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1A3Sjx-0004rU-00 for ipv6@ietf.org; Sun, 28 Sep 2003 00:00:57 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 533C641B for ; Sun, 28 Sep 2003 00:00:27 -0400 (EDT) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 28 Sep 2003 00:00:27 -0400 Message-Id: <20030928040027.533C641B@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.66% | 13 | 17.77% | 68527 | john.loughney@nokia.com 7.23% | 6 | 6.91% | 26644 | moore@cs.utk.edu 7.23% | 6 | 5.75% | 22182 | michel@arneill-py.sacramento.ca.us 6.02% | 5 | 6.07% | 23390 | brian@innovationslab.net 4.82% | 4 | 6.64% | 25584 | brc@zurich.ibm.com 6.02% | 5 | 5.42% | 20910 | hinden@iprg.nokia.com 4.82% | 4 | 4.66% | 17974 | pekkas@netcore.fi 4.82% | 4 | 4.06% | 15635 | kurtis@kurtis.pp.se 3.61% | 3 | 4.10% | 15812 | ipv6@nosense.org 3.61% | 3 | 3.20% | 12331 | lear@cisco.com 2.41% | 2 | 3.23% | 12455 | ron.lee@samsung.com 2.41% | 2 | 2.38% | 9169 | iljitsch@muada.com 2.41% | 2 | 2.38% | 9161 | mat@cisco.com 2.41% | 2 | 2.32% | 8958 | rdroms@cisco.com 2.41% | 2 | 2.20% | 8491 | erik.nordmark@sun.com 2.41% | 2 | 1.83% | 7045 | ftemplin@iprg.nokia.com 1.20% | 1 | 1.55% | 5989 | pekka.nikander@nomadiclab.com 1.20% | 1 | 1.50% | 5799 | slblake@torrentnet.com 1.20% | 1 | 1.40% | 5389 | andrew.e.white@motorola.com 1.20% | 1 | 1.38% | 5319 | h.soliman@flarion.com 1.20% | 1 | 1.30% | 5017 | narten@us.ibm.com 1.20% | 1 | 1.26% | 4848 | soohong.park@samsung.com 1.20% | 1 | 1.25% | 4805 | internet-drafts@ietf.org 1.20% | 1 | 1.23% | 4736 | zefram@fysh.org 1.20% | 1 | 1.22% | 4714 | mark@nosense.org 1.20% | 1 | 1.20% | 4612 | benny+nospam@amorsen.dk 1.20% | 1 | 1.20% | 4610 | sra+ipng@hactrn.net 1.20% | 1 | 1.09% | 4221 | tony@lava.net 1.20% | 1 | 1.03% | 3983 | a.gyasi-agyei@cqu.edu.au 1.20% | 1 | 0.94% | 3631 | jari.arkko@kolumbus.fi 1.20% | 1 | 0.92% | 3564 | tjc@ecs.soton.ac.uk 1.20% | 1 | 0.90% | 3477 | mrw@windriver.com 1.20% | 1 | 0.88% | 3385 | cdel@firsthand.net 1.20% | 1 | 0.82% | 3164 | kempf@docomolabs-usa.com --------+------+--------+----------+------------------------ 100.00% | 83 |100.00% | 385531 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 28 05:26:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12448 for ; Sun, 28 Sep 2003 05:26:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3XoA-0007gb-6V for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 05:25:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8S9PctJ029546 for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 05:25:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Xo9-0007gT-VX for ipv6-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 05:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12424 for ; Sun, 28 Sep 2003 05:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Xo6-00079r-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 05:25:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3Xo6-00079o-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 05:25:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Xna-0007aY-Iu; Sun, 28 Sep 2003 05:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Xn4-0007a9-71 for ipv6@optimus.ietf.org; Sun, 28 Sep 2003 05:24:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12397 for ; Sun, 28 Sep 2003 05:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Xn0-00079R-00 for ipv6@ietf.org; Sun, 28 Sep 2003 05:24:26 -0400 Received: from mail.sernet.de ([193.159.217.66]) by ietf-mx with esmtp (Exim 4.12) id 1A3Xn0-00079O-00 for ipv6@ietf.org; Sun, 28 Sep 2003 05:24:26 -0400 Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 2.12 #2) id 1A3Xn0-0003ac-00; Sun, 28 Sep 2003 11:24:26 +0200 Received: by intern.SerNet.DE id 1A3Xn0-0007XV-00; Sun, 28 Sep 2003 11:24:26 +0200 Received: by intern.SerNet.DE id 1A3Xn0-0007XR-00; Sun, 28 Sep 2003 11:24:26 +0200 Date: Sun, 28 Sep 2003 11:24:26 +0200 (CEST) From: Lutz Pressler To: Antonio Querubin cc: , Subject: Re: why market picked up NATs In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: Organization: Service Network GmbH, Goettingen, Germany Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, 26 Sep 2003, Antonio Querubin wrote: > On Wed, 24 Sep 2003, Andrew White wrote: > > > > The real issue is application support. In the consumer market, OS X has > > IPv6, but it's hidden from most users. Win XP also has IPv6, but it > > requires a bunch of chicanery to get it working. The real killer is that > > Actually, the Windows XP implementation is pretty much plug and play. > Run 'ipv6 install' and it's ready to do 6to4 automatically. One (the?) major problem is, that the DNS resolver cannot use IPv6 as transport. That makes IPv6-only setups impossible. Application problems are still there, too, of course. For example, it is possible to let IE use a proxy via IPv6, but only with the trick of putting a hostname IPv6-address into the hosts file (and using that name in the IE configuration, not the literal address). Lutz -- _ | Lutz Pressler | Tel: ++49-551-3700002 |_ |\ | | Service Network GmbH | FAX: ++49-551-3700009 ._|ER | \|ET | Bahnhofsallee 1b | mailto:lp@SerNet.DE Service Network | D-37081 Goettingen | http://www.SerNet.DE/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 28 06:17:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13389 for ; Sun, 28 Sep 2003 06:17:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Yc8-0001AK-Jr for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 06:17:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8SAHGQ5004474 for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 06:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Yc8-0001A5-DV for ipv6-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 06:17:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13357 for ; Sun, 28 Sep 2003 06:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Yc4-0007Wg-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 06:17:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3Yc4-0007Wa-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 06:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Ybu-00014S-L6; Sun, 28 Sep 2003 06:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3YbR-00011D-35 for ipv6@optimus.ietf.org; Sun, 28 Sep 2003 06:16:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13342 for ; Sun, 28 Sep 2003 06:16:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3YbN-0007WE-00 for ipv6@ietf.org; Sun, 28 Sep 2003 06:16:29 -0400 Received: from [213.221.138.98] (helo=kurtis-lindqvists-computer.local) by ietf-mx with esmtp (Exim 4.12) id 1A3YbM-0007WB-00 for ipv6@ietf.org; Sun, 28 Sep 2003 06:16:28 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by kurtis-lindqvists-computer.local (8.12.9/8.10.2) with ESMTP id h8SAGNdV000801; Sun, 28 Sep 2003 12:16:23 +0200 (CEST) Date: Thu, 25 Sep 2003 16:16:59 +0200 Subject: Re: comments on deprecate-site-local-00 Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pekka Savola , Brian E Carpenter , ipv6@ietf.org To: Margaret Wasserman From: Kurt Erik Lindqvist In-Reply-To: <5.1.0.14.2.20030923163942.040171f8@mail.windriver.com> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> > True, but if we wish to remain relevant, something has to be written >> > somewhere. I fully agree that doing so in *this* document may not >> be >> > worth it; it might be worth it in some other doc, e.g. sl-impact. >> >> I agree with Pekka. HAving this in writing somewhere is important. > > I'd be happy to dust off my sl-impact draft, and update it based > on the feedback I've received so far, if folks think that would be > useful... That could be a good base, but I think that what Pekka asked for and at least what I would hope for, would be broader. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP3L43aarNKXTPFCVEQITtgCeOniEyb2YUJBE7zxgG3xMiYd5pFMAnjSC RVLJ8cEoU1dxYG/X7vHSNFWV =SMwP -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 28 07:58:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15930 for ; Sun, 28 Sep 2003 07:58:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3aBN-0004j6-JZ for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 07:57:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8SBvj6J018164 for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 07:57:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3aBN-0004it-EF for ipv6-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 07:57:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15903 for ; Sun, 28 Sep 2003 07:57:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3aBM-0000da-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 07:57:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3aBM-0000dX-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 07:57:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3aAg-0004W5-3e; Sun, 28 Sep 2003 07:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3a9o-0004Vk-N6 for ipv6@optimus.ietf.org; Sun, 28 Sep 2003 07:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15881 for ; Sun, 28 Sep 2003 07:56:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3a9n-0000d2-00 for ipv6@ietf.org; Sun, 28 Sep 2003 07:56:07 -0400 Received: from slimsixten.pilsnet.sunet.se ([192.36.125.115] helo=slimsixten.besserwisser.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A3a9n-0000cz-00 for ipv6@ietf.org; Sun, 28 Sep 2003 07:56:07 -0400 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h8SBu2Ht027068; Sun, 28 Sep 2003 13:56:07 +0200 (CEST) Date: Sat, 27 Sep 2003 14:22:29 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: ipv6@ietf.org cc: Margaret Wasserman Subject: Re: comments on deprecate-site-local-00 Message-ID: <743720000.1064665349@localhost> In-Reply-To: <5.1.0.14.2.20030923163942.040171f8@mail.windriver.com> References: <5.1.0.14.2.20030923163942.040171f8@mail.windriver.com> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2471046430==========" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==========2471046430========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Tuesday, September 23, 2003 16:41:16 -0400 Margaret Wasserman wrote: > I'd be happy to dust off my sl-impact draft, and update it based > on the feedback I've received so far, if folks think that would be > useful... Yes, please do.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2471046430========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE/dYEF02/pMZDM1cURAiaWAJ0RYHaiWdWWwi8jtpHX18ZCTU4qvgCdG4AE tqurh0cjq/n8Ce7x3CDQLxE= =KLWf -----END PGP SIGNATURE----- --==========2471046430==========-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 28 08:05:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16127 for ; Sun, 28 Sep 2003 08:05:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3aIe-00056r-9r for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 08:05:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8SC5Gq0019634 for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 08:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3aIe-00056b-3t for ipv6-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 08:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16087 for ; Sun, 28 Sep 2003 08:05:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3aId-0000hF-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 08:05:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3aIc-0000hB-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 08:05:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3aIR-0004xL-BV; Sun, 28 Sep 2003 08:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3aI8-0004x1-EW for ipv6@optimus.ietf.org; Sun, 28 Sep 2003 08:04:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16080 for ; Sun, 28 Sep 2003 08:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3aI7-0000h0-00 for ipv6@ietf.org; Sun, 28 Sep 2003 08:04:43 -0400 Received: from slimsixten.pilsnet.sunet.se ([192.36.125.115] helo=slimsixten.besserwisser.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A3aI6-0000gx-00 for ipv6@ietf.org; Sun, 28 Sep 2003 08:04:43 -0400 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h8SBu2Hv027068; Sun, 28 Sep 2003 13:56:08 +0200 (CEST) Date: Sat, 27 Sep 2003 14:38:24 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Michel Py , Thomas Narten cc: ipv6@ietf.org Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-ID: <757610000.1064666304@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1094185783==========" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==========1094185783========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Wednesday, September 24, 2003 08:41:14 -0700 Michel Py wrote: >> I had been living in bliss >=20 > A too common problem within the IETF. Maybe it would be useful for some > people here to actually get out in the real world. We more typically escape to bliss, at a cost, because we've seen what the Consumer-grade "Internet" is, and want none of it.=20 I have a small-business-grade DSL at home, costing around 5 times as much as consumer (and that is with the discaount!), but I get a /27 and RFC2317 style delegation. It is bliss, but it should not be exceptional, it should be the norm -- because it is immensely empowering. I want my fellow humans to feel that, too, which is why I'm fighting for it.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1094185783========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE/dYTA02/pMZDM1cURAn0XAJ0W0ZFmEUWN9Es3SffQibcwE+KHUQCgjOj+ EtThV3C+pSiE/6d2X8o0qRM= =6TG1 -----END PGP SIGNATURE----- --==========1094185783==========-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 28 19:34:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05339 for ; Sun, 28 Sep 2003 19:34:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3l3j-0000Nf-0E for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 19:34:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8SNYY2I001457 for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 19:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3l3i-0000NQ-R4 for ipv6-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 19:34:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05313 for ; Sun, 28 Sep 2003 19:34:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3l3h-0005xn-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 19:34:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3l3g-0005xk-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 19:34:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3l3B-0000JT-V7; Sun, 28 Sep 2003 19:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3l2z-0000J8-5c for ipv6@optimus.ietf.org; Sun, 28 Sep 2003 19:33:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05285 for ; Sun, 28 Sep 2003 19:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3l2x-0005xB-00 for ipv6@ietf.org; Sun, 28 Sep 2003 19:33:47 -0400 Received: from creativedynamo.com ([64.65.66.163] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 1A3l2w-0005wv-00 for ipv6@ietf.org; Sun, 28 Sep 2003 19:33:46 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h8SNafZt026525; Sun, 28 Sep 2003 13:36:41 -1000 Received: from localhost (tony@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) with ESMTP id h8SNaeM2026522; Sun, 28 Sep 2003 13:36:41 -1000 X-Authentication-Warning: localhost.localdomain: tony owned process doing -bs Date: Sun, 28 Sep 2003 13:36:40 -1000 (HST) From: Antonio Querubin X-X-Sender: tony@localhost.localdomain To: Lutz Pressler cc: awhite@arc.corp.mot.com, Subject: Re: why market picked up NATs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sun, 28 Sep 2003, Lutz Pressler wrote: > On Fri, 26 Sep 2003, Antonio Querubin wrote: > > On Wed, 24 Sep 2003, Andrew White wrote: > > > > > > The real issue is application support. In the consumer market, OS X has > > > IPv6, but it's hidden from most users. Win XP also has IPv6, but it > > > requires a bunch of chicanery to get it working. The real killer is that > > > > Actually, the Windows XP implementation is pretty much plug and play. > > Run 'ipv6 install' and it's ready to do 6to4 automatically. > One (the?) major problem is, that the DNS resolver cannot use IPv6 > as transport. That makes IPv6-only setups impossible. > Application problems are still there, too, of course. > For example, it is possible to let IE use a proxy via IPv6, > but only with the trick of putting a hostname IPv6-address into > the hosts file (and using that name in the IE configuration, > not the literal address). True there are a few missing features but I wouldn't call them major nor would I characterize the stack as requiring quite a lot of extra steps to get it to 'work'. Setting up an IPv6-only configuration isn't practical or useful to the majority of end-users. Considering what you get from running a single command I'd say it's fairly functional for the majority of things that most Windows users would require. Some content sites may want to do IPv6-only networks but at least Windows users will still have easy access. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Sep 28 22:18:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08961 for ; Sun, 28 Sep 2003 22:18:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ncL-0005lF-Sh for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 22:18:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8T2IT0x022139 for ipv6-archive@odin.ietf.org; Sun, 28 Sep 2003 22:18:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ncL-0005l0-N9 for ipv6-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 22:18:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08943 for ; Sun, 28 Sep 2003 22:18:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3ncI-0007Dc-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 22:18:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3ncI-0007DZ-00 for ipv6-web-archive@ietf.org; Sun, 28 Sep 2003 22:18:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3nbt-0005e5-O3; Sun, 28 Sep 2003 22:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3nbp-0005dq-Fo for ipv6@optimus.ietf.org; Sun, 28 Sep 2003 22:17:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08939 for ; Sun, 28 Sep 2003 22:17:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3nbm-0007DW-00 for ipv6@ietf.org; Sun, 28 Sep 2003 22:17:54 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A3nbl-0007DH-00 for ipv6@ietf.org; Sun, 28 Sep 2003 22:17:53 -0400 Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Date: Sun, 28 Sep 2003 19:17:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] thread-index: AcOFyTkqtmdiuReIRti1A10mgp6PcgAZihHw From: "Michel Py" To: =?iso-8859-1?Q?M=E5ns_Nilsson?= Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable M=E5ns, > M=E5ns Nilsson wrote: > I have a small-business-grade DSL at home, costing around > 5 times as much as consumer (and that is with the discaount!), Sounds about right with a discount. > but I get a /27 and RFC2317 style delegation. It is bliss, > but it should not be exceptional, it should be the norm -- > because it is immensely empowering. Would you care giving concrete examples of what it empowers you to do, = which is, what can't I do with my residential setup and you can because = you have been empowered? Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 09:37:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14374 for ; Mon, 29 Sep 2003 09:37:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yD8-000233-Dz for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 09:37:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TDbAnt007867 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 09:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yD8-00022n-1S for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 09:37:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14345 for ; Mon, 29 Sep 2003 09:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yD6-0005ql-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 09:37:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3yD5-0005qh-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 09:37:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yC2-0001u4-NO; Mon, 29 Sep 2003 09:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yBD-0001rt-7Y for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 09:35:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14286 for ; Mon, 29 Sep 2003 09:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yBB-0005pP-00 for ipv6@ietf.org; Mon, 29 Sep 2003 09:35:09 -0400 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by ietf-mx with esmtp (Exim 4.12) id 1A3yBA-0005ox-00 for ipv6@ietf.org; Mon, 29 Sep 2003 09:35:08 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h8TDYYfw046174; Mon, 29 Sep 2003 15:34:34 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8TDYXWo185462; Mon, 29 Sep 2003 15:34:33 +0200 Received: from zurich.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id PAA34646; Mon, 29 Sep 2003 15:34:30 +0200 Message-ID: <3F7834CC.128C39E3@zurich.ibm.com> Date: Mon, 29 Sep 2003 15:34:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: slblake@torrentnet.com CC: Bob Hinden , ipv6@ietf.org Subject: Re: [I-D ACTION:draft-ietf-ipv6-unique-local-addr-01.txt] References: <4.3.2.7.2.20030925160504.03283e98@mailhost.iprg.nokia.com> <1064592579.342.477.camel@newcastle.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steven Blake wrote: > > I have some comments about Section 3.2.1 (Centrally Assigned Global IDs) > > 1. I don't understand the necessity for the requirement to generate IDs > consistent with [RANDOM]. The IDs need to be unique and > sufficiently "randomized" (one could argue how important this need > really is) so that there is no plausible way to aggregate them. I > don't think it is necessary to be unable to guess the date or > relative order in which a particular ID was allocated, however. Strictly, that's true, but isn't it easier to simply refer to an existing method? > > 2. I don't find the argument for a single allocation authority > compelling. It is still possible for a single authority (i.e., > IANA) to delegate blocks of the global ID space to multiple > registries. The naive way would be to delegate lists of random > numbers generated by IANA. A more elegant way would be to delegate > ranges in the sequence space of a non-repeating PRNG (e.g., maximal > period 40-bit LFSR). Note that the requirement (1) above precludes > this latter method. Yes but why bother ? There is no geographical aspect here, so why set up more than one registry? > > 3. I don't believe it is essential to have alternative registration > methods besides web and e-mail. Anyone can establish a new network > using only PA addresses (and locally assigned local IDs if > necessary) before acquiring a "centrally assigned" local ID. One > could also ask a friend with connectivity, or go to a local library. > Requiring non-automated means of registration significantly drives > up the allocation cost. I would agree, but how does someone in the middle of a developing country with no connected friends and no such thing as a library do it? > > 4. I don't believe that it is necessary for the allocation registry to > escrow each allocation; I think it is sufficient for the allocation > recipient to do so. In a dispute one can prove that he or she owns > an allocation by producing a non-repudiatable (e.g., signed) message > from a registry. The registries would only have to escrow their > public keys. Yes, I think that is better. > > 5. I don't believe that the 10 euro fee is appropriate. I suspect that > the cost to collect the money is substantially higher than the > cost to manage the registry infrastructure, especially if the > requirements are relaxed sufficiently such that the process can be > fully automated. Although I'm not volunteering to foot the costs > of a registry myself, I suspect sponsors could be found to operate > them. The fee is the abuse-prevention mechanism. We know from other examples that automated registries can and do operate at that level of fee. And in the conditions of the early 21st century, no, I don't think it's trivial to find sponsorship. > > 6. I believe a centralized registry is more susceptible to a DoS > attack. That's true. But if each probe of the attack takes 10 Euros out of the attackers credit card, who cares? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 11:12:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20325 for ; Mon, 29 Sep 2003 11:12:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zgc-0007uR-Eg for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 11:11:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TFBgel030398 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 11:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zgc-0007uC-8B for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 11:11:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20300 for ; Mon, 29 Sep 2003 11:11:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zgZ-00078M-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 11:11:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3zgZ-00078J-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 11:11:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zfy-0007kD-RW; Mon, 29 Sep 2003 11:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zfi-0007jo-Gy for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 11:10:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20244 for ; Mon, 29 Sep 2003 11:10:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zff-00077K-00 for ipv6@ietf.org; Mon, 29 Sep 2003 11:10:43 -0400 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 1A3zff-00077F-00 for ipv6@ietf.org; Mon, 29 Sep 2003 11:10:43 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h8TFAc910943; Mon, 29 Sep 2003 11:10:38 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h8TFAbY43650; Mon, 29 Sep 2003 11:10:37 -0400 (EDT) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id LAA25794; Mon, 29 Sep 2003 11:10:36 -0400 (EDT) Subject: Re: [I-D ACTION:draft-ietf-ipv6-unique-local-addr-01.txt] From: Steven Blake Reply-To: slblake@torrentnet.com To: Brian E Carpenter Cc: ipv6@ietf.org In-Reply-To: <3F7834CC.128C39E3@zurich.ibm.com> References: <4.3.2.7.2.20030925160504.03283e98@mailhost.iprg.nokia.com> <1064592579.342.477.camel@newcastle.torrentnet.com> <3F7834CC.128C39E3@zurich.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 29 Sep 2003 11:10:36 -0400 Message-Id: <1064848236.342.505.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2003-09-29 at 09:34, Brian E Carpenter wrote: > Steven Blake wrote: > > 2. I don't find the argument for a single allocation authority > > compelling. It is still possible for a single authority (i.e., > > IANA) to delegate blocks of the global ID space to multiple > > registries. The naive way would be to delegate lists of random > > numbers generated by IANA. A more elegant way would be to delegate > > ranges in the sequence space of a non-repeating PRNG (e.g., maximal > > period 40-bit LFSR). Note that the requirement (1) above precludes > > this latter method. > > Yes but why bother ? There is no geographical aspect here, so why set up > more than one registry? Well, the main reason is to prevent one registry from ripping people off at 10 euros a piece. > > 3. I don't believe it is essential to have alternative registration > > methods besides web and e-mail. Anyone can establish a new network > > using only PA addresses (and locally assigned local IDs if > > necessary) before acquiring a "centrally assigned" local ID. One > > could also ask a friend with connectivity, or go to a local library. > > Requiring non-automated means of registration significantly drives > > up the allocation cost. > > I would agree, but how does someone in the middle of a developing country > with no connected friends and no such thing as a library do it? How do they come up with 10 euros to spend on a random number? The simplest thing to do is use a locally assigned local ID until they get a PA allocation, and then go get their "centrally assigned" local ID. > > 4. I don't believe that it is necessary for the allocation registry to > > escrow each allocation; I think it is sufficient for the allocation > > recipient to do so. In a dispute one can prove that he or she owns > > an allocation by producing a non-repudiatable (e.g., signed) message > > from a registry. The registries would only have to escrow their > > public keys. > > Yes, I think that is better. > > > > > 5. I don't believe that the 10 euro fee is appropriate. I suspect that > > the cost to collect the money is substantially higher than the > > cost to manage the registry infrastructure, especially if the > > requirements are relaxed sufficiently such that the process can be > > fully automated. Although I'm not volunteering to foot the costs > > of a registry myself, I suspect sponsors could be found to operate > > them. > > The fee is the abuse-prevention mechanism. We know from other examples that > automated registries can and do operate at that level of fee. And in the > conditions of the early 21st century, no, I don't think it's trivial to > find sponsorship. If the registration page requires some manual action by the registree then that should be effective to prevent widespread abuse. The typical approach is to imbed a string in some graphic and require the user to type in the string. > > 6. I believe a centralized registry is more susceptible to a DoS > > attack. > > That's true. But if each probe of the attack takes 10 Euros out of the > attackers credit card, who cares? Attackers would be more clever than that. Anyway, I think the 10 euro fee is arbitrary and absurdly high. I hope IANA puts this out to competitive bid. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 13:08:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29050 for ; Mon, 29 Sep 2003 13:08:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41Ut-0005pV-0X for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 13:07:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TH7gCs022395 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 13:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41Ur-0005os-Ra for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 13:07:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29002 for ; Mon, 29 Sep 2003 13:07:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A41Uq-0001vl-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 13:07:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A41Uq-0001vi-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 13:07:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41UE-0005TT-TX; Mon, 29 Sep 2003 13:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41TN-0005GE-8p for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 13:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28941 for ; Mon, 29 Sep 2003 13:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A41TL-0001uR-00 for ipv6@ietf.org; Mon, 29 Sep 2003 13:06:07 -0400 Received: from radiosixten.pilsnet.sunet.se ([192.36.125.116] helo=slimsixten.besserwisser.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A41TL-0001uO-00 for ipv6@ietf.org; Mon, 29 Sep 2003 13:06:07 -0400 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.6) with ESMTP id h8TGuwlO027072; Mon, 29 Sep 2003 18:56:59 +0200 (CEST) Date: Mon, 29 Sep 2003 18:56:58 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Michel Py cc: "ipv6@ietf.org" Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?] Message-ID: <1585500000.1064854618@localhost.besserwisser.org> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2950820541==========" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --==========2950820541========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Sunday, September 28, 2003 19:17:23 -0700 Michel Py wrote: > Would you care giving concrete examples of what it empowers you to do, > which is, what can't I do with my residential setup and you can because > you have been empowered? * I can run servers without firewall redirects.=20 * I can connect directly to any node on my home network from any place=20 in the world -- barring administrative rules.=20 * My two IP telephones work. I could have one with a redirect, but I want two.=20 * All nodes get distinctive reverse DNS.=20 * Kerberos works as intended, with address-tied tickets.=20 * My AFS server setup works.=20 * If I chose to employ firewall rules, I can put them on the nodes=20 that need them, not having to think about impact on other nodes.=20 * I can have one view on DNS -- no need for ugly split hacks.=20 * My friends who come over for coffee and packets can get the same=20 service as I get, without special hacks from me -- they just get=20 a real, routable address from my DHCP pool. Whatever they chose to run is possible.=20 In short, IP works as designed, as opposed to "barely works through a=20 series of ugly e2e violations". The reduction in mental stress is=20 impressive and relieving. =20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2950820541========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE/eGRa02/pMZDM1cURAvWKAKCfwqVCn/PSR9/d7R+Y0IRhfIVHwACfTldy LKpHTNzDwfu5RdOQQXY5R8A= =yiSH -----END PGP SIGNATURE----- --==========2950820541==========-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 13:57:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00932 for ; Mon, 29 Sep 2003 13:57:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42Go-00083q-3S for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 13:57:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8THvEdf030980 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 13:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42Gn-00083b-UK for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 13:57:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00909 for ; Mon, 29 Sep 2003 13:57:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42Gm-0002UK-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 13:57:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A42Gl-0002UH-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 13:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42Gb-0007xs-MX; Mon, 29 Sep 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42G8-0007xS-B3 for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 13:56:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00896 for ; Mon, 29 Sep 2003 13:56:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42G4-0002U0-00 for ipv6@ietf.org; Mon, 29 Sep 2003 13:56:29 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1A42G4-0002Tq-00 for ipv6@ietf.org; Mon, 29 Sep 2003 13:56:28 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8THtuPK355124; Mon, 29 Sep 2003 13:55:56 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8THttdm209020; Mon, 29 Sep 2003 11:55:56 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h8THqCGB008909; Mon, 29 Sep 2003 13:52:13 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id h8THqC0j008904; Mon, 29 Sep 2003 13:52:12 -0400 Message-Id: <200309291752.h8THqC0j008904@rotala.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipv6@ietf.org Subject: Re: Node Req: Issue22: 4.5.4 Default Address Selection for IPv6 - RFC3484 text In-Reply-To: Message from john.loughney@nokia.com of "Wed, 24 Sep 2003 14:40:36 +0300." Date: Mon, 29 Sep 2003 13:52:12 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > > 4.5.4 Default Address Selection for IPv6 - RFC3484 > > > > > > Default Address Selection for IPv6 [RFC-3484] SHOULD be supported, if > > > a node has more than one IPv6 address per interface or a node has > > > more that one IPv6 interface (physical or logical) configured. > > > > > > If supported, the rules specified in the document MUST be > > > implemented. A node needs to belong to one site, however there is no > > > requirement that a node be able to belong to more than one site. > > > > This is really weasle worded. Is 3484 mandatory to _implement_ or not? > > You can't make its implementation dependent on whether there are > > multiple addresses, since the number of addresses a node will have is > > not something an implementor will know, as it's an operational issue. > Why do you say its weasley-worded? I take this as a strong SHOULD. I > imagine that a single purpose IPv6, like a sensor may, in fact, have a > single IP address. The current wording suggests that there are classes of devices that don't need to handle multiple addresses (i.e., they will only have a single address assigned to them). This (IMO) violates a core assumption of IPv6, that all nodes need to deal with multiple addresses. I'd like to see a better justification to allow this. So, I'm not objecting to the SHOULD, I'm objecting to the suggestion that some nodes won't need to support multiple addresses. Note: whether a site uses one or some small number of addressesd is an operational issue, and can't really be a device implementation decision. > Some text clarification may be OK, though, how about > adding to the first paragraph the following text: > It is expected that most implementations will indeed support this, as > since the number of addresses a node will have is more of an > operational issue. IMO, I'd like to see removal of all wording suggesting that it might be OK for devices to support only a single address. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 14:01:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01258 for ; Mon, 29 Sep 2003 14:01:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42KY-00009y-3R for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TI16uh000608 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42KX-00009j-VM for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 14:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01159 for ; Mon, 29 Sep 2003 14:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42KW-0002XK-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A42KV-0002XH-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42KU-0008S5-RV; Mon, 29 Sep 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42KL-0008RM-VT for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 14:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01150 for ; Mon, 29 Sep 2003 14:00:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42KJ-0002X7-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:00:52 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1A42KJ-0002Wv-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:00:51 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8TI0LPK390020; Mon, 29 Sep 2003 14:00:21 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8TI0Kdm137264; Mon, 29 Sep 2003 12:00:20 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h8THubGB008940; Mon, 29 Sep 2003 13:56:37 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id h8THubib008935; Mon, 29 Sep 2003 13:56:37 -0400 Message-Id: <200309291756.h8THubib008935@rotala.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipv6@ietf.org Subject: Re: Node Req: Issue23: DNS issues In-Reply-To: Message from john.loughney@nokia.com of "Wed, 24 Sep 2003 14:45:46 +0300." Date: Mon, 29 Sep 2003 13:56:37 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , My point on this issue is that this section doesn't really provide much useful information, or provide any useful guidance to an implementor. This document surely isn't going to recommend that nodes need to support DNS servers. At best, this is a MAY. So, not much needs to be said about server stuff. But what is of interest to generic nodes is what resolver functionality they should implement. I would expect this document to recommend something like "nodes SHOULD implement DNS IPv6 resolver functionality" and then provide some pointers to the IPv6 specific parts (e.g., supporting queries for AAAA records). The current wording just doesn't seem to say anything to me. Thomas john.loughney@nokia.com writes: > > > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152] > > > and [RFC-3363] MAY be supported. Not all nodes will need to resolve > > > names. Note that RFC 1886 is currently being updated [RFC-1886-BIS]. > > > > 1886-bis has been approved by the IESG I believe... > When it gets and RFC number, I will update. > > Also, I suspect this section really needs to talk about resolvers and > > resolver behavior, rather than just say DNS. Most of the server issues > > do not apply to generic IPv6 nodes. > Servers are nodes, are they not? Nodes can be both a host and/or server. > > But almost every node will have some sort of resolver... > There had been some discussion about this, and some folks made some > comments that indicated that certain devices may not have any resolvers, > so I don't want to assume that almost every node will have some sort of > resolver. > My suggested resolution is to leave the text unchanged. > John > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 14:21:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01960 for ; Mon, 29 Sep 2003 14:21:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42eI-00022c-Va for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:21:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TILUve007845 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42eI-00022S-7a for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 14:21:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01906 for ; Mon, 29 Sep 2003 14:21:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42eG-0002jr-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:21:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A42eF-0002jn-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:21:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42cu-0001TY-5I; Mon, 29 Sep 2003 14:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42cg-0001Sf-BF for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 14:19:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01860 for ; Mon, 29 Sep 2003 14:19:42 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42ce-0002iw-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:19:48 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A42cd-0002ip-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:19:47 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TIJlt26691 for ; Mon, 29 Sep 2003 21:19:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Sep 2003 21:19:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 21:19:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 21:19:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue23: DNS issues Date: Mon, 29 Sep 2003 21:19:46 +0300 Message-ID: Thread-Topic: Node Req: Issue23: DNS issues Thread-Index: AcOGs6Hbjp5VhWvLTDmC9F0XL/MJVQAAnqmg To: Cc: X-OriginalArrivalTime: 29 Sep 2003 18:19:46.0546 (UTC) FILETIME=[43295D20:01C386B6] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thomas, > My point on this issue is that this section doesn't really provide > much useful information, or provide any useful guidance to an > implementor. >=20 > This document surely isn't going to recommend that nodes need to > support DNS servers. At best, this is a MAY. So, not much needs to be > said about server stuff. >=20 > But what is of interest to generic nodes is what resolver > functionality they should implement. I would expect this document to > recommend something like "nodes SHOULD implement DNS IPv6 resolver > functionality" and then provide some pointers to the IPv6 specific > parts (e.g., supporting queries for AAAA records). The current > wording just doesn't seem to say anything to me. I will look at reving the text, but some suggestions would be helpful. What RFCs quality for IPv6 Resolver functionality. =20 thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 14:22:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01993 for ; Mon, 29 Sep 2003 14:22:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42eS-00025k-Bi for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:21:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TILeGB008034 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42eS-00025V-7C for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 14:21:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01920 for ; Mon, 29 Sep 2003 14:21:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42eQ-0002kD-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:21:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A42eP-0002kA-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:21:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42dr-0001lA-IS; Mon, 29 Sep 2003 14:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42cz-0001Us-V1 for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 14:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01878 for ; Mon, 29 Sep 2003 14:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42cx-0002j1-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:20:07 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1A42cx-0002ig-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:20:07 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8TIJZm2266094; Mon, 29 Sep 2003 14:19:35 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8TIJYdm175980; Mon, 29 Sep 2003 12:19:34 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h8TIFpGB008991; Mon, 29 Sep 2003 14:15:51 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id h8TIFlaO008986; Mon, 29 Sep 2003 14:15:51 -0400 Message-Id: <200309291815.h8TIFlaO008986@rotala.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipv6@ietf.org Subject: Re: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711 In-Reply-To: Message from john.loughney@nokia.com of "Wed, 24 Sep 2003 15:08:11 +0300." Date: Mon, 29 Sep 2003 14:15:47 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , john.loughney@nokia.com writes: > Reading 2711, there are some host / server specific issues about 2711. > Suggested text: > IPv6 Router Alert Option specific [RFC-2711] defines a new option in the s/specific/specifically/? > IPv6 Hop-by-Hop Header. Hosts MAY support the router alert option > defined. Nodes that generate RSVP message MUST implement the router > alert option. The Router Alert Option [RFC-2711] MUST be supported by > nodes that perform packet forwarding at the IP layer (i.e. - the node is > a router). Router alerts are also required with MLD messages. So wording that reflects this would be good. Indeed, I don't think the RSVP usage is so important to mention, given that RSVP isn't mentioned elsewhere in the document. How about something like the following instead: The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-Hop Header that is used in conjunction with some protocols (e.g., RSVP [RFC XXX], or MLD [RFC XXX]). The Router Alert option will need to be implemented whenever protocols that mandate its usage are implemented. See Section XXX-MLD. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 14:38:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02883 for ; Mon, 29 Sep 2003 14:38:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42u7-0003Cf-Dk for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:37:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TIbofu012299 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42u6-0003CI-Ft for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 14:37:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02831 for ; Mon, 29 Sep 2003 14:37:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42u4-0002wi-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:37:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A42u3-0002wf-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:37:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42tJ-0002jN-Te; Mon, 29 Sep 2003 14:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42sP-0002iM-Ir for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 14:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02760 for ; Mon, 29 Sep 2003 14:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42sN-0002vZ-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:36:03 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A42sM-0002ur-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:36:02 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h8TIZQV14184; Mon, 29 Sep 2003 11:35:26 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6d-51.chvlva.adelphia.net [67.21.61.51]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h8TIZvtX013986 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 Sep 2003 11:36:01 -0700 Message-ID: <3F787B69.6010101@innovationslab.net> Date: Mon, 29 Sep 2003 14:35:21 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: john.loughney@nokia.com, ipv6@ietf.org Subject: Re: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711 References: <200309291815.h8TIFlaO008986@rotala.raleigh.ibm.com> In-Reply-To: <200309291815.h8TIFlaO008986@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas Narten wrote: > john.loughney@nokia.com writes: > > >>Reading 2711, there are some host / server specific issues about 2711. >>Suggested text: > > >> IPv6 Router Alert Option specific [RFC-2711] defines a new option in the > > > s/specific/specifically/? > >> IPv6 Hop-by-Hop Header. Hosts MAY support the router alert option >> defined. Nodes that generate RSVP message MUST implement the router >> alert option. The Router Alert Option [RFC-2711] MUST be supported by >> nodes that perform packet forwarding at the IP layer (i.e. - the node is >> a router). > > > Router alerts are also required with MLD messages. So wording that > reflects this would be good. Indeed, I don't think the RSVP usage is > so important to mention, given that RSVP isn't mentioned elsewhere in > the document. How about something like the following instead: > > The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 > Hop-by-Hop Header that is used in conjunction with some protocols > (e.g., RSVP [RFC XXX], or MLD [RFC XXX]). The Router Alert option > will need to be implemented whenever protocols that mandate its > usage are implemented. See Section XXX-MLD. I like Thomas' suggested text. Only mentioning RSVP with respect to the router alert option is the wrong approach. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Sep 29 14:42:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03077 for ; Mon, 29 Sep 2003 14:42:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42xq-0003mg-VO for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:41:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TIfgrD014547 for ipv6-archive@odin.ietf.org; Mon, 29 Sep 2003 14:41:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42xq-0003mY-Nf for ipv6-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 14:41:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03042 for ; Mon, 29 Sep 2003 14:41:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42xo-000308-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:41:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A42xn-000305-00 for ipv6-web-archive@ietf.org; Mon, 29 Sep 2003 14:41:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42xC-0003Qp-Qe; Mon, 29 Sep 2003 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42wC-0003P8-F8 for ipv6@optimus.ietf.org; Mon, 29 Sep 2003 14:40:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02945 for ; Mon, 29 Sep 2003 14:39:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42wA-0002yW-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:39:58 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1A42w9-0002yK-00 for ipv6@ietf.org; Mon, 29 Sep 2003 14:39:57 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8TIdRm2368736; Mon, 29 Sep 2003 14:39:27 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8TIdQ2W128268; Mon, 29 Sep 2003 12:39:26 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h8TIZgGB009144; Mon, 29 Sep 2003 14:35:42 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id h8TIZgdY009139; Mon, 29 Sep 2003 14:35:42 -0400 Message-Id: <200309291835.h8TIZgdY009139@rotala.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipv6@ietf.org, jari.arkko@kolumbus.fi Subject: Re: Node Req: Issue27: 11. Security Considerations In-Reply-To: Message from john.loughney@nokia.com of "Wed, 24 Sep 2003 15:13:22 +0300." Date: Mon, 29 Sep 2003 14:35:42 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I am not a security expert, perhaps Jari could comment on this section. > This document does not introduce any new security vulnerabilites on the > Internet. However, in creating this document some of the contributors > felt that there are security issues that are not covered in existing RFCs > and this is what we have tried to document. Note: I thought we were on the path that updates to the original documents should go in those documents. So maybe at least some of the comments could go in an appropriate revised document? And given that at least some of them are expected to be revised, this may be reasonable. We'd need a breakdown of which parts would go in what document to see how this might work. > Perhaps you should be more specific on what should be removed, for > example. the following: The use of ICMPv6 without IPsec can expose the nodes in question to various kind of attacks including Denial-of-Service, Impersonation, Man-in-the-Middle, and others. Note that only manually keyed IPsec can protect some of the ICMPv6 messages that are related to establishing communications. This is due to chicken-and-egg problems on running automated key management protocols on top of IP. However, manually keyed IPsec may require a large number of SAs in order to run on a large network due to the use of many addresses during ICMPv6 Neighbor Discovery. The use of wide-area multicast communications has an increased risk from specific security threats, compared with the same threats in unicast [MC-THREAT]. An implementer should also consider the analysis of anycast [ANYCAST]. Note: to the reader who may not understand the history here, this section just seems to have included some random things. That raises the question of what was included and why not. At the very least, it would make sense to include some context saying that the above is not complete but includes some items that are discussed insufficiently in the relevant documents. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 00:27:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25106 for ; Tue, 30 Sep 2003 00:27:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C6a-0005ju-EB for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 00:27:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U4RKF4022056 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 00:27:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C6a-0005jf-7X for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 00:27:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25065 for ; Tue, 30 Sep 2003 00:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4C6X-0001du-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 00:27:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4C6X-0001dr-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 00:27:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C5L-0005Zi-5Y; Tue, 30 Sep 2003 00:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C4v-0005ZG-J0 for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 00:25:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24995 for ; Tue, 30 Sep 2003 00:25:28 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4C4t-0001cp-00 for ipv6@ietf.org; Tue, 30 Sep 2003 00:25:35 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A4C4s-0001cl-00 for ipv6@ietf.org; Tue, 30 Sep 2003 00:25:34 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8U4PX607214 for ; Tue, 30 Sep 2003 07:25:33 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Sep 2003 07:25:33 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 07:25:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 07:25:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711 Date: Tue, 30 Sep 2003 07:25:30 +0300 Message-ID: Thread-Topic: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711 Thread-Index: AcOGuJiFSBFPgL+fR8Cg0lyCTu8ggAAUjrLg To: , Cc: X-OriginalArrivalTime: 30 Sep 2003 04:25:33.0004 (UTC) FILETIME=[E356B8C0:01C3870A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, I will update the doc according to the text Thomas proposed. John > -----Original Message----- > From: ext Brian Haberman [mailto:brian@innovationslab.net] > Sent: 29 September, 2003 21:35 > To: Thomas Narten > Cc: Loughney John (NRC/Helsinki); ipv6@ietf.org > Subject: Re: Node Req: Issue26: 9.1.1 IPv6 Router Alert=20 > Option - RFC2711 >=20 >=20 >=20 >=20 > Thomas Narten wrote: >=20 > > john.loughney@nokia.com writes: > >=20 > >=20 > >>Reading 2711, there are some host / server specific issues=20 > about 2711.=20 > >>Suggested text: > >=20 > >=20 > >> IPv6 Router Alert Option specific [RFC-2711] defines a=20 > new option in the > >=20 > >=20 > > s/specific/specifically/? > >=20 > >> IPv6 Hop-by-Hop Header. Hosts MAY support the router alert option=20 > >> defined. Nodes that generate RSVP message MUST implement=20 > the router > >> alert option. The Router Alert Option [RFC-2711] MUST be=20 > supported by=20 > >> nodes that perform packet forwarding at the IP layer=20 > (i.e. - the node is > >> a router). > >=20 > >=20 > > Router alerts are also required with MLD messages. So wording that > > reflects this would be good. Indeed, I don't think the RSVP usage is > > so important to mention, given that RSVP isn't mentioned=20 > elsewhere in > > the document. How about something like the following instead: > >=20 > > The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 > > Hop-by-Hop Header that is used in conjunction with some protocols > > (e.g., RSVP [RFC XXX], or MLD [RFC XXX]). The Router Alert option > > will need to be implemented whenever protocols that mandate its > > usage are implemented. See Section XXX-MLD. >=20 > I like Thomas' suggested text. Only mentioning RSVP with respect > to the router alert option is the wrong approach. >=20 > Regards, > Brian >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 00:28:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25179 for ; Tue, 30 Sep 2003 00:28:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C7p-0005zq-Fb for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 00:28:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U4Sbnp023044 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 00:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C7p-0005za-9t for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 00:28:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25139 for ; Tue, 30 Sep 2003 00:28:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4C7m-0001f4-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 00:28:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4C7m-0001f1-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 00:28:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C7G-0005nx-9f; Tue, 30 Sep 2003 00:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4C6f-0005nK-6r for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 00:27:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25071 for ; Tue, 30 Sep 2003 00:27:16 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4C6c-0001e2-00 for ipv6@ietf.org; Tue, 30 Sep 2003 00:27:22 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A4C6c-0001dz-00 for ipv6@ietf.org; Tue, 30 Sep 2003 00:27:22 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8U4RM608355 for ; Tue, 30 Sep 2003 07:27:22 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Sep 2003 07:27:22 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 07:27:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 07:27:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue27: 11. Security Considerations Date: Tue, 30 Sep 2003 07:27:21 +0300 Message-ID: Thread-Topic: Node Req: Issue27: 11. Security Considerations Thread-Index: AcOGuR04EnT1/yoiRxOYJsV+3JsyOwAUc/0A To: Cc: , X-OriginalArrivalTime: 30 Sep 2003 04:27:21.0645 (UTC) FILETIME=[241805D0:01C3870B] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thomas, Your comments at the end of this mail confused me. Do you want the text removed or do you want clarifying text? The more I think about it, the more I think it would be OK to remove much of the text from the security consideration, as they really don't help the reader do anything extra. Some of the original documents need updating, so perhaps it is best left to that. thanks John > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: 29 September, 2003 21:36 > To: Loughney John (NRC/Helsinki) > Cc: ipv6@ietf.org; jari.arkko@kolumbus.fi > Subject: Re: Node Req: Issue27: 11. Security Considerations=20 >=20 >=20 > > I am not a security expert, perhaps Jari could comment on=20 > this section.=20 > > This document does not introduce any new security=20 > vulnerabilites on the > > Internet. However, in creating this document some of the=20 > contributors > > felt that there are security issues that are not covered in=20 > existing RFCs > > and this is what we have tried to document. >=20 > Note: I thought we were on the path that updates to the original > documents should go in those documents. So maybe at least some of the > comments could go in an appropriate revised document? And given that > at least some of them are expected to be revised, this may be > reasonable. We'd need a breakdown of which parts would go in what > document to see how this might work. >=20 > > Perhaps you should be more specific on what should be removed, for > > example. >=20 > the following: >=20 > The use of ICMPv6 without IPsec can expose the nodes in question to > various kind of attacks including Denial-of-Service, Impersonation, > Man-in-the-Middle, and others. Note that only manually keyed IPsec > can protect some of the ICMPv6 messages that are related to > establishing communications. This is due to=20 > chicken-and-egg problems > on running automated key management protocols on top of=20 > IP. However, > manually keyed IPsec may require a large number of SAs in order to > run on a large network due to the use of many addresses=20 > during ICMPv6 > Neighbor Discovery. >=20 > The use of wide-area multicast communications has an increased risk > from specific security threats, compared with the same threats in > unicast [MC-THREAT]. >=20 > An implementer should also consider the analysis of anycast > [ANYCAST]. >=20 >=20 > Note: to the reader who may not understand the history here, this > section just seems to have included some random things. That raises > the question of what was included and why not. At the very least, it > would make sense to include some context saying that the above is not > complete but includes some items that are discussed insufficiently in > the relevant documents. >=20 > Thomas >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 06:55:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15944 for ; Tue, 30 Sep 2003 06:55:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4I9R-0007NB-IY for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 06:54:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UAsfVQ028335 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 06:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4I9R-0007Mw-99 for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 06:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15904 for ; Tue, 30 Sep 2003 06:54:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4I9N-00053w-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 06:54:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4I9M-00053t-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 06:54:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4I8n-0007DS-EP; Tue, 30 Sep 2003 06:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4I7r-0007C8-AS for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 06:53:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15877 for ; Tue, 30 Sep 2003 06:52:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4I7m-00053I-00 for ipv6@ietf.org; Tue, 30 Sep 2003 06:52:59 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1A4I7m-00052s-00 for ipv6@ietf.org; Tue, 30 Sep 2003 06:52:58 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8UAqT67167316; Tue, 30 Sep 2003 06:52:29 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-232-192.mts.ibm.com [9.65.232.192]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8UAqS1R063552; Tue, 30 Sep 2003 04:52:28 -0600 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id h8UAnWb08247; Tue, 30 Sep 2003 06:49:32 -0400 Message-Id: <200309301049.h8UAnWb08247@cichlid.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipv6@ietf.org, jari.arkko@kolumbus.fi Subject: Re: Node Req: Issue27: 11. Security Considerations In-Reply-To: Message from john.loughney@nokia.com of "Tue, 30 Sep 2003 07:27:21 +0300." Date: Tue, 30 Sep 2003 06:49:32 -0400 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Your comments at the end of this mail confused me. Do you want the text > removed or do you want clarifying text? I'm fine with removing it. My last point was more about if it's felt the text needs to stay. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 07:09:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16299 for ; Tue, 30 Sep 2003 07:09:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4INT-0008U8-85 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 07:09:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UB9B8l032610 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 07:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4INS-0008Tt-U2 for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 07:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16271 for ; Tue, 30 Sep 2003 07:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4INO-0005Bp-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 07:09:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4INN-0005Bm-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 07:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4INJ-0008OK-GH; Tue, 30 Sep 2003 07:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ING-0008O0-KN for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 07:08:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16263 for ; Tue, 30 Sep 2003 07:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4INC-0005Bc-00 for ipv6@ietf.org; Tue, 30 Sep 2003 07:08:54 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A4INB-0005BH-00 for ipv6@ietf.org; Tue, 30 Sep 2003 07:08:53 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h8UB8KV19611; Tue, 30 Sep 2003 04:08:20 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6d-51.chvlva.adelphia.net [67.21.61.51]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h8UB8stX016695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 30 Sep 2003 04:08:58 -0700 Message-ID: <3F79641F.4060407@innovationslab.net> Date: Tue, 30 Sep 2003 07:08:15 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: narten@us.ibm.com, ipv6@ietf.org, jari.arkko@kolumbus.fi Subject: Re: Node Req: Issue27: 11. Security Considerations References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would support the removal of the text. These security issues really belong in the base specifications and not in an Info doc. Regards, Brian john.loughney@nokia.com wrote: > Thomas, > > Your comments at the end of this mail confused me. Do you want the text > removed or do you want clarifying text? The more I think about it, the > more I think it would be OK to remove much of the text from the security > consideration, as they really don't help the reader do anything extra. > Some of the original documents need updating, so perhaps it is best left > to that. > > thanks > John > > >>-----Original Message----- >>From: ext Thomas Narten [mailto:narten@us.ibm.com] >>Sent: 29 September, 2003 21:36 >>To: Loughney John (NRC/Helsinki) >>Cc: ipv6@ietf.org; jari.arkko@kolumbus.fi >>Subject: Re: Node Req: Issue27: 11. Security Considerations >> >> >> >>>I am not a security expert, perhaps Jari could comment on >> >>this section. >> >>>This document does not introduce any new security >> >>vulnerabilites on the >> >>>Internet. However, in creating this document some of the >> >>contributors >> >>>felt that there are security issues that are not covered in >> >>existing RFCs >> >>>and this is what we have tried to document. >> >>Note: I thought we were on the path that updates to the original >>documents should go in those documents. So maybe at least some of the >>comments could go in an appropriate revised document? And given that >>at least some of them are expected to be revised, this may be >>reasonable. We'd need a breakdown of which parts would go in what >>document to see how this might work. >> >> >>>Perhaps you should be more specific on what should be removed, for >>>example. >> >>the following: >> >> The use of ICMPv6 without IPsec can expose the nodes in question to >> various kind of attacks including Denial-of-Service, Impersonation, >> Man-in-the-Middle, and others. Note that only manually keyed IPsec >> can protect some of the ICMPv6 messages that are related to >> establishing communications. This is due to >>chicken-and-egg problems >> on running automated key management protocols on top of >>IP. However, >> manually keyed IPsec may require a large number of SAs in order to >> run on a large network due to the use of many addresses >>during ICMPv6 >> Neighbor Discovery. >> >> The use of wide-area multicast communications has an increased risk >> from specific security threats, compared with the same threats in >> unicast [MC-THREAT]. >> >> An implementer should also consider the analysis of anycast >> [ANYCAST]. >> >> >>Note: to the reader who may not understand the history here, this >>section just seems to have included some random things. That raises >>the question of what was included and why not. At the very least, it >>would make sense to include some context saying that the above is not >>complete but includes some items that are discussed insufficiently in >>the relevant documents. >> >>Thomas >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 10:05:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21947 for ; Tue, 30 Sep 2003 10:05:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L7O-0007jl-4y for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 10:04:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UE4k29029735 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 10:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L7N-0007jW-UM for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 10:04:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21852 for ; Tue, 30 Sep 2003 10:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L7L-00070h-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 10:04:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4L7L-00070d-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 10:04:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L6g-0007cC-Dz; Tue, 30 Sep 2003 10:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L67-0007bt-DQ for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 10:03:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21809 for ; Tue, 30 Sep 2003 10:03:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L65-00070C-00 for ipv6@ietf.org; Tue, 30 Sep 2003 10:03:25 -0400 Received: from ns.digi-data.com ([209.94.197.193] helo=digi-data.com) by ietf-mx with esmtp (Exim 4.12) id 1A4L64-000707-00 for ipv6@ietf.org; Tue, 30 Sep 2003 10:03:24 -0400 Received: from exchsvr.digi-data.com ([10.1.1.11]) by odin.digi-data.com with ESMTP id <119043>; Tue, 30 Sep 2003 10:02:20 -0400 Received: from digi-data.com ([10.1.1.31]) by exchsvr.digi-data.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Sep 2003 10:03:34 -0400 Message-ID: <3F798D8F.1040001@digi-data.com> Date: Tue, 30 Sep 2003 10:05:03 -0400 From: Robert Honore User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Test Mesg. Pls Ignore Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2003 14:03:34.0982 (UTC) FILETIME=[A3689660:01C3875B] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mesg sent 2003 Sept 30 10:04 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 10:57:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25046 for ; Tue, 30 Sep 2003 10:57:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LwN-000304-7X for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 10:57:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UEvR9g011526 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 10:57:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LwM-0002zk-DV for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 10:57:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25020 for ; Tue, 30 Sep 2003 10:57:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4LwI-0007be-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 10:57:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4LwH-0007bb-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 10:57:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Lvy-0002u8-6b; Tue, 30 Sep 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Lvw-0002tq-Cs for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 10:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25009 for ; Tue, 30 Sep 2003 10:56:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Lvt-0007bQ-00 for ipv6@ietf.org; Tue, 30 Sep 2003 10:56:57 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A4Lvs-0007b8-00 for ipv6@ietf.org; Tue, 30 Sep 2003 10:56:57 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h8UEuQV20759 for ; Tue, 30 Sep 2003 07:56:26 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6d-51.chvlva.adelphia.net [67.21.61.51]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h8UEv0tX017244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 30 Sep 2003 07:57:04 -0700 Message-ID: <3F799994.8070400@innovationslab.net> Date: Tue, 30 Sep 2003 10:56:20 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <3F730183.6090504@caspiannetworks.com> In-Reply-To: <3F730183.6090504@caspiannetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [WG chair hat off] Below are my comments on the Hain/Templin draft. Globally, I think that these goals are worthwhile for the entire IPv6 protocol suite. This type of functionality is needed in order for people to feel comfortable migrating from v4 to v6. > Goals for an Addressing Scheme to Support Local Communications within > Sites The title still implies that these goals will be satisfied by an addressing scheme rather than some other mechanism. As it has been noted in the past, some of these goals are not specific or require a local addressing scheme. In fact, some of the "goals" are really operational rather than addressing issues. If we can separate out the operational issues from the local addressing goals, the title may fit better. > 1. Introduction > > The IPv6 addressing architecture [RFC3513] specifies global and > local-use unicast addresses. Global addresses are understood to have > unlimited range and may be used as the source and destination > addresses in packets that originate from any point on the connected > global IPv6 Internet. Local-use addresses are intended for use only > within the range of a single link/site, but their specification does > not address operational considerations and does not account for the > esoteric nature of terms such as "site". I cannot determine what the last sentence is trying to say. Further along in the document, it expressly talks about operation considerations. In fact, the whole document assumes that these considerations should all be fixed by a local addressing scheme. Perhaps what needs to be discussed here is why only having global addresses would not suffice. Describe the operational problems that will be caused without local addressing. > > There is a perceived need for an addressing scheme that supports > local communications within sites. Of special interest are "active > sites", e.g., sites that are intermittently-connected or disconnected > from the global Internet, sites that frequently change provider > points of attachment, sites that temporarily or permanently merge > with other sites, multi-homed sites, etc. This memo will discuss > goals for an addressing scheme to support local communications within > sites in the context of real world deployment scenarios. I find the use of the word "perceived" in the first sentence of this paragraph and in other places in this document. If it is just a perceived need, can't these goals be solved with other tools? Or put in other terms, will operators use different tools if they are provided/defined/developed? Also, multi-homing is a different issue altogether. I can't see where it needs to be discussed other than as a subset of a possible renumbering scenario. Like my comments on the introduction, I would firm up the issues caused without local addressing. I also suggest that multi-homing be taken out of this document. > 3.1 Easy to Acquire > > Some portion of the address space should be made available that > requires no public registration, payment, customer/provider > relationship, or approval. These addresses should be architecturally > supported and end-user-controlled. A few issues with this section. First, why is no payment a goal as far as ease of acquisition is concerned? Second, how can conflict resolution occur without some form of public registration? No registry is fine if we are talking about a strictly disconnected network, but for connected networks a conflict resolution capability is a good thing to have. Third, I would suggest some text be added to discuss the tradeoffs of the global routability of these addresses. > > 3.2 Stable > > Applications that enable local communications should use addresses > that support session stability (i.e., connection survivability) > during intermittent connectivity, site mergers, change to a new > provider, etc. In particular, session stability should not be > affected by renumbering events [BAKER]. How often do you expect renumbering events to occur? How does renumbering differ from a planned outage? When those occur, applications either restart or are restarted once the change is made. In addition, just because a subnetwork disconnects, it doesn't terminate the use of prefixes within the subnetwork. So, the apps can keep using those addresses until the nodes are told of new ones. The requirement seems to be for a stable address for a long period of time (months, years, decades, etc). If that is the requirement, then state it as such. > > 3.3 Multiple Link Support > > Addresses for local communications within sites should support > operation over multiple links, e.g., via L3 routing, L2 bridging or > some combination thereof. As such, subnetting consistent with the > recommendations in ([RFC3177], section 3) should be supported. > > Link-local addresses in IPv6: "are designed to be used for addressing > on a single link for purposes such as automatic address > configuration, neighbor discovery, or when no routers are present" > ([RFC3513], section 2.5.6). By definition, link-local addresses have > a single link range of operation and will not meet this goal. I don't think this section even belongs here. We have link-locals defined already, so someone will not re-define them. I suggest taking it out altogether. > > 3.4 Well-known Prefix I think this section is an excellent example of trying to solve an operational issue with an addressing scheme. Several people have suggested this before, but a "well-known" prefix can just as easily be carved out of one's global prefix. In addition, how exactly does an app figure out "the hint"? It has no way of knowing which side of the site boundary it currently resides. The well-known prefix works for filtering at boundaries, not for special handling by an app. > 3.5 Globally Unique > > Addresses used by sites should be globally unique such that site > mergers will not result in collisions. Global uniqueness is based on > the statistical properties of address allocations, therefore > proposals should specify a suitable means for random prefix > generation. Addressing scheme proposals should also provide a > suitable means for conflict resolution, e.g., certification through a > central registry, distributed database, etc. Doesn't this directly conflict with the requirement in 3.1 for no public registry? > > Sufficient global uniqueness is needed to support, e.g.: > > o VPNs between enterprises > > o dynamically created VPNs in support of temporary virtual > organizations > > o service provider co-location of hosts that reside in the address > space of multiple customers > > o formation of virtual organizations (Grids) among enterprises > > o mergers and acquisitions of enterprises such that address spaces > do not collide I am confused by this list. One could argue that all of the above put together requires globally routed addresses. Perhaps the better way to approach this is to discuss the tradeoffs of centrally-allocated addresses and locally-allocated addresses in supporting tools such as VPNs. > 3.6 Usable in the Absence of a Provider > > Active sites need addresses that can be used when there is no active > link to a provider. In the case of intermittently-connected sites, > provider access may be unavailable for long periods but this should > not disrupt local communications within the site. In the case of > sites moving to new provider points of attachment, frequent > renumbering events may occur but, again, local communications should > not be disrupted. > The current scheme for renumbering allows for overlapping of the old and new prefixes for a period of time. This would apply to the intermittently-connected sites as well. Apps can continue to use the old prefixes for internal sessions until the pre-planned, hard cutover. Once that cutover occurs, the apps will disconnect from the old prefix and re-establish through the new prefix. > > PI addresses provide one solution alternative genre that also > appliies to cases where network managers want global access. The > issue is that PI addresses with no designed aggregation properties > may lead to global routing table explosion (if advertised outside the > site) given current routing technologies. For this reason, PI > addressing scheme proposals should either provide reasonable > aggregation properties or a detailed analysis of their interactions > with global routing technologies. PA and other non-PI proposals > should explain how the proposed addressing schemes will support local > communications in the presence of intermittent and/or disconnected > provider access. What is the purpose of having this short discussion of PI addresses in this document? > 3.8 Compatible with Site Naming System > Since the document assumes that addressing will be the solution, why have this section on naming? > 3.9 Compatible with VPN > See my comments on section 3.5. This is a prime example for the use of global addresses. > 4.1 Border Filtering > > Network managers limit specific applications to internal use, so they > configure them to only work with a filtered address range. This > simplifies the border filter to an address prefix, rather than > needing to employ deep packet inspection to track a potentially > dynamic range of ports. > Again, if they are connected to the Internet, they can carve out a portion of the global prefix IF you want to rely on this type of filtering for "application protection". I have the same concern about this section as raised with section 3.4 In discussing the issue of filtering, I would like to see the tradeoffs, e.g. real cost, of using a portion of your global space vs. local addresses. > 4.2 Maintaining Confidentiality of the Address Space > > Private space may be used to avoid exposing to competitors what > internal networks they are deploying and which office is coordinating > that effort. Network managers also don't have to expose business > plans to a registrar for evaluation for networks that are not > attached to the global Internet. Some have stated that if they are > required to register for public space for every internal use network, > they are more likely to pick random numbers than tip off the > competition. Can you give an example of how this works? Knowing what someone's prefix is doesn't reveal what internal networks are being deployed. > > 4.3 Test Networks > > Another significant use of private address space is test networks. > Frequently these are large, elaborate networks with a mix of public > and private address space. Use of random unallocated space runs the > risk of collision with legitimate addresses on remote networks. But you can mitigate that risk if you sub-divide your public space and filter the chunk you want private. > 4.5 Mobile Router with Personal Area Network > 4.6.2 Groups of Nodes that Travel Together I made this comment earlier, but it applies to these two sections as well. Just because a network is dis-connected, does not mean it can't keep using the prefix it was assigned when it was connected. I suggest that this section spell out the issues of long-term use of an ISP-assigned prefix after the dis-connection. And that this take into account whether the customer has negotiated the rights to "keep" the prefix during the intermittently connected time. > Research ships at sea intermittently connect via INMARSAT, or when in > port, the shipboard network is connected to shore via Ethernet. Of > utmost importance is that the systems on board the ship all function, > providing data collection and analysis without interruption. Static > addressing is used on most intra-ship network components and servers. > It's quite expensive to operate a research ship, so eliminating > points of failure is important. Scientists on board collaborate with > colleagues back home by sharing of data and email. Currently private > address space is employed for several reasons: 1) it provides the > ability to allocate significant address space to each ship without > needing to worry about how many computers will be on a given cruise. > 2) it provides separate address space for each ship. 3) it simplifies > filtering to ensure shipboard traffic is not permitted to transmit > out or bring up expensive satellite links. Point 1 is a no-op, it can be accomplished with almost any addressing mechanism. Point 2 screams for the use of global addresses. And 3 can, once again, be accomplished through many other means besides a special address range. > 5. Perceived Advantages of Limited Range Addressing Solutions > > Limited range addressing solutions allow filtering, and filtering > creates addressing boundaries no matter where the bits come from. The > point is that some addresses are only valid within the range defined > by the local network manager. I agree with this sentence. Some addresses are only valid in an area defined by the manager. And that can be accomplished in several ways. > > In the simple case, hosts that are allowed external access have a > policy that allows them to configure both global and limited range > prefixes, while those that are not allowed global access have a > policy that only allows limited range. Address selection policy > tables might need modifications to enable the selection of limited > range address space over global addresses. Given such modifications, > address selection rules will prefer the smallest range so internal > communications are forced to stay internal by the hard filter at the > border. > > If an application chooses to assert a policy that is different from > the network manager's filtering rules, it will fail. Having a well > defined limited range address space that is known to have filtering > applied allows applications to have a hint about potential range > restrictions. We can choose to leave the network managers to figure > out their own adhoc mechanisms, or we can put them in a structured > limited range address space so that applications will have a chance > to react appropriately. This paragraph raises the point that the proposals by Zill and Bellovin or other similar approaches to advertise "special" prefixes via an RA may be useful tools for us to provide. And I am sure others will see the same. Perhaps there needs to be some wrap-up on the operational issues between using such an approach and using a local addressing scheme. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 12:51:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01597 for ; Tue, 30 Sep 2003 12:51:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Nir-0002gD-Gn for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 12:51:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UGpb9f010295 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 12:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Nir-0002fy-Ce for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 12:51:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01558 for ; Tue, 30 Sep 2003 12:51:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Nip-0001aY-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 12:51:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Nip-0001aU-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 12:51:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4NiH-0002Ws-W1; Tue, 30 Sep 2003 12:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Nhp-0002W1-Ie for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 12:50:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01546 for ; Tue, 30 Sep 2003 12:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Nhn-0001aJ-00 for ipv6@ietf.org; Tue, 30 Sep 2003 12:50:31 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Nhn-0001Zs-00 for ipv6@ietf.org; Tue, 30 Sep 2003 12:50:31 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2003 09:54:51 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8UGnwXg017808 for ; Tue, 30 Sep 2003 09:49:59 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.247]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACU01001; Tue, 30 Sep 2003 12:49:57 -0400 (EDT) Message-Id: <4.3.2.7.2.20030930124555.01fd8b00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Sep 2003 12:49:54 -0400 To: ipv6@ietf.org From: Ralph Droms Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt In-Reply-To: <3F799994.8070400@innovationslab.net> References: <3F730183.6090504@caspiannetworks.com> <3F730183.6090504@caspiannetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Here are my comments on draft-hain-templin-ipv6-limitedrange-02.txt... Global organization - as I read the doc (others' reactions may differ), I feel like I'm reading a document that is based on some assumptions about the solution before describing the problem. In particular, the first sentence in the second paragraph of the Introduction: There is a perceived need for an addressing scheme that supports local communications within sites. seems to me to conclude, without explicit support for the conclusion, that something like site-local addresses is required. Even the title, "Goals for an Addressing Scheme to Support Local Communications within Sites" suggests the outcome. I suggest renaming the doc to "Goals for Local Communication within Sites". It turns out that you do have support for the "perceived need" in section 4. So my suggestion would be to swap sections 3 and 4, and add a sentence in the introduction: There is a perceived need for an addressing scheme that supports local communications within sites. The next section gives several scenarios in which local communications within a site are required. Then, the goals can be justified by reference to the scenarios. Comments about scenarios: 4.2 Why would an organization ever have to expose the internal networks being deployed and what office is coordinating the effort? 4.3 Is this test network connected to the Internet? 4.4 I think this scenario would be clearer if it were labelled "Static Configuration with Addresses" or some such. The problem is really static configuration of an address rather than caching an address learned through some other process. 4.6 What about a completely disconnected ad-hoc network (not necessarily mobile)? I'm thinking of 5 guys in a bar using an ad hoc network with no Internet connection... 4.8 I'm afraid I couldn't understand this scenario at all. When the two sites connect, do they essentially merge into a single, multi-homed site? Is the "local traffic" between hosts within the merged A/B site? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 14:50:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07325 for ; Tue, 30 Sep 2003 14:50:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PZK-0003Dj-Bf for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 14:49:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UInsJg012373 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 14:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PZK-0003DU-78 for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:49:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07271 for ; Tue, 30 Sep 2003 14:49:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PZH-00035R-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 14:49:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PZG-00035M-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 14:49:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PYU-0002wB-62; Tue, 30 Sep 2003 14:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PYJ-0002vZ-3N for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 14:48:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07194 for ; Tue, 30 Sep 2003 14:48:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PYG-00034G-00 for ipv6@ietf.org; Tue, 30 Sep 2003 14:48:48 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1A4PYF-00033j-00 for ipv6@ietf.org; Tue, 30 Sep 2003 14:48:47 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h8UImHV22034 for ; Tue, 30 Sep 2003 11:48:17 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6d-51.chvlva.adelphia.net [67.21.61.51]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h8UImqtX017932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 30 Sep 2003 11:48:56 -0700 Message-ID: <3F79CFEC.8010809@innovationslab.net> Date: Tue, 30 Sep 2003 14:48:12 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Agenda Requests for Minneapolis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, The chairs are currently formulating the agenda for the Minneapolis meeting. If you have items you wish included, please send the request to the chairs. Regards, Brian & Bob IPv6 WG Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 15:16:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09911 for ; Tue, 30 Sep 2003 15:16:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pyo-00060r-2M for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 15:16:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJGE6Z023101 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 15:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pyn-00060V-QS for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 15:16:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09815 for ; Tue, 30 Sep 2003 15:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Pym-0003Xf-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 15:16:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Pyl-0003Xa-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 15:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pyc-0005p2-1A; Tue, 30 Sep 2003 15:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P3t-00005P-63 for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 14:17:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05618 for ; Tue, 30 Sep 2003 14:17:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P3q-0002dl-00 for ipv6@ietf.org; Tue, 30 Sep 2003 14:17:22 -0400 Received: from web12905.mail.yahoo.com ([216.136.174.72]) by ietf-mx with smtp (Exim 4.12) id 1A4P3q-0002di-00 for ipv6@ietf.org; Tue, 30 Sep 2003 14:17:22 -0400 Message-ID: <20030930181721.56060.qmail@web12905.mail.yahoo.com> Received: from [193.251.135.123] by web12905.mail.yahoo.com via HTTP; Tue, 30 Sep 2003 11:17:21 PDT Date: Tue, 30 Sep 2003 11:17:21 -0700 (PDT) From: Abdul-Hafeez Jamali Subject: help To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-646260366-1064945841=:56007" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-646260366-1064945841=:56007 Content-Type: text/plain; charset=us-ascii Hi all I m new to IPv6. Can anybody answer the following question, so that I could better understand IPv6 : Is fragmentaion is possible in IPv6 Packet/datagram ?? if Yes then how ??? if No. then why not ??? Thanx ahj --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-646260366-1064945841=:56007 Content-Type: text/html; charset=us-ascii
Hi all
I m new to IPv6. Can anybody answer the following question, so that I could better understand IPv6 :
 
Is fragmentaion is possible in IPv6 Packet/datagram ?? if Yes then how ??? if No. then why not ???
 
Thanx
 
ahj

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-646260366-1064945841=:56007-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 15:16:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09928 for ; Tue, 30 Sep 2003 15:16:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pyo-000610-4A for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 15:16:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJGE9s023115 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 15:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pyn-00060W-UA for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 15:16:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09817 for ; Tue, 30 Sep 2003 15:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Pym-0003Xh-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 15:16:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Pyl-0003Xb-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 15:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pyd-0005pF-FJ; Tue, 30 Sep 2003 15:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PUH-0002E3-8Y for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 14:44:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06854; Tue, 30 Sep 2003 14:44:30 -0400 (EDT) Message-Id: <200309301844.OAA06854@ietf.org> From: The IESG To: Tony Hain Cc: ipv6@ietf.org, IETF-Announce: ; Subject: Response to appeal by Tony Hain on site-local issue Date: Tue, 30 Sep 2003 14:44:30 -0400 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The IESG has reviewed the appeal by Tony Hain of the IPv6 Working Group chairs' declaration of consensus on the issue of site local addresses in the IPv6 address architecture. Tony's appeal requests that the declaration of consensus be overturned due to the ambiguity of the question asked. As is to be expected of a technical discussion where there are many opinions, the discussion of the site-local issue at the San Francisco IETF meeting went all over the map, with many unanswered questions. However, the question asked by the chairs, with clarification from the AD, was clear. "Does the group want to go away from site-local addressing, deprecate it, work out how to get it out, [or] does the group want to keep it and figure out what the right usage model is for it?" The clarifying statement was "Deprecate [...] means somewhere to the left of the 'limited use' model?" The spectrum of choices, including the 'limited use' model, had been presented during that same meeting. Although the group had decided to rule out the 'limited use' model (and presumably anything to the left of it as well) in Atlanta, nothing precludes new information from prompting a review of old decisions. The question posed on the list was more concise, simply "Should we deprecate IPv6 site-local unicast addressing?" This question is not ambiguous. The deprecation of site-local addresses in their current form has served a useful role in forcing the working group to recognize the problems that the original definition had and work to address them. The IESG finds nothing unusual about how the question was asked or how the working group has proceeded. There is strong consensus in the IESG that deprecation is the correct technical decision, but we have done our best to separate our technical preferences from the process issue in considering this appeal. In summary, the IESG upholds the chairs' and INT ADs' decisions. The IESG -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 15:40:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11454 for ; Tue, 30 Sep 2003 15:40:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QME-0000FG-I5 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 15:40:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJeQ0c000936 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 15:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QME-0000F0-BI for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 15:40:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11418 for ; Tue, 30 Sep 2003 15:40:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QMC-0003sg-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 15:40:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4QMC-0003sd-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 15:40:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QLs-00008E-16; Tue, 30 Sep 2003 15:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QL2-0008SC-51 for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 15:39:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11312 for ; Tue, 30 Sep 2003 15:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QL0-0003rG-00 for ipv6@ietf.org; Tue, 30 Sep 2003 15:39:10 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A4QKz-0003qX-00 for ipv6@ietf.org; Tue, 30 Sep 2003 15:39:10 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8UJcXe27195; Tue, 30 Sep 2003 12:38:33 -0700 X-mProtect: <200309301938> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTebPqN; Tue, 30 Sep 2003 12:38:31 PDT Message-ID: <3F79DC5E.3080307@iprg.nokia.com> Date: Tue, 30 Sep 2003 12:41:18 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman CC: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <3F730183.6090504@caspiannetworks.com> <3F799994.8070400@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, Thanks for sending the detailed comments. Will give a first-pass at them below, but may require a couple of iterations. Fred ftemplin@iprg.nokia.com Brian Haberman wrote: > > [WG chair hat off] > > Below are my comments on the Hain/Templin draft. Globally, > I think that these goals are worthwhile for the entire IPv6 > protocol suite. This type of functionality is needed in order > for people to feel comfortable migrating from v4 to v6. > > >> Goals for an Addressing Scheme to Support Local Communications within >> Sites > > > The title still implies that these goals will be satisfied > by an addressing scheme rather than some other mechanism. As > it has been noted in the past, some of these goals are not > specific or require a local addressing scheme. In fact, some > of the "goals" are really operational rather than addressing > issues. Actually, Ralph Droms had a similar comment (see his post on this thread) and suggested the following title: "Goals for Local Communications Within Sites" > If we can separate out the operational issues from the local > addressing goals, the title may fit better. I like Ralph's title suggestion; any others? > >> 1. Introduction >> >> The IPv6 addressing architecture [RFC3513] specifies global and >> local-use unicast addresses. Global addresses are understood to have >> unlimited range and may be used as the source and destination >> addresses in packets that originate from any point on the connected >> global IPv6 Internet. Local-use addresses are intended for use only >> within the range of a single link/site, but their specification does >> not address operational considerations and does not account for the >> esoteric nature of terms such as "site". > > > I cannot determine what the last sentence is trying to say. How about: "...but their specification does not address operational considerations for real-world deployments." > Further along in the document, it expressly talks about operation > considerations. In fact, the whole document assumes that these > considerations should all be fixed by a local addressing scheme. Not the intention, and will work to fix this. We want to support local communications within sites, but this need not be through a *local addressing* scheme. > Perhaps what needs to be discussed here is why only having global > addresses would not suffice. Describe the operational problems > that will be caused without local addressing. Any specific text suggestions would be welcome. >> >> There is a perceived need for an addressing scheme that supports >> local communications within sites. Of special interest are "active >> sites", e.g., sites that are intermittently-connected or disconnected >> from the global Internet, sites that frequently change provider >> points of attachment, sites that temporarily or permanently merge >> with other sites, multi-homed sites, etc. This memo will discuss >> goals for an addressing scheme to support local communications within >> sites in the context of real world deployment scenarios. > > > I find the use of the word "perceived" in the first sentence of this > paragraph and in other places in this document. If it is just a > perceived need, can't these goals be solved with other tools? Or > put in other terms, will operators use different tools if they are > provided/defined/developed? Well, there is an actual need for local communications within sites and any form of communications requires addressing. Would your concerns be satisfied if we struck the word "perceived" wherever it occurs? > Also, multi-homing is a different issue altogether. I can't see > where it needs to be discussed other than as a subset of a possible > renumbering scenario. > > Like my comments on the introduction, I would firm up the issues > caused without local addressing. Again, specific text suggestions would be welcome. > I also suggest that multi-homing be taken out of this document. Agree; we already have RFC 3582 and don't want to re-create it here. > >> 3.1 Easy to Acquire >> >> Some portion of the address space should be made available that >> requires no public registration, payment, customer/provider >> relationship, or approval. These addresses should be architecturally >> supported and end-user-controlled. > > > A few issues with this section. > > First, why is no payment a goal as far as ease of acquisition is > concerned? Not intending the non-payment aspect for the entire address space, as indicated by: "*Some portion* of the address space..". What we are intending to say is that some scenarios may require autonomous address configuration with no interactions with a registry, and those scenarios should be supported. > Second, how can conflict resolution occur without some form of > public registration? No registry is fine if we are talking > about a strictly disconnected network, but for connected networks > a conflict resolution capability is a good thing to have. Not what we're intending to say; clearly, some scenarios will require conflict resolution such as can only be enforced through public registration. We touch on this in section 3.5. > Third, I would suggest some text be added to discuss the tradeoffs > of the global routability of these addresses. Suggestions? >> >> 3.2 Stable >> >> Applications that enable local communications should use addresses >> that support session stability (i.e., connection survivability) >> during intermittent connectivity, site mergers, change to a new >> provider, etc. In particular, session stability should not be >> affected by renumbering events [BAKER]. > > > How often do you expect renumbering events to occur? In fixed environments, perhaps quite rarely; in mobile environments, perhaps quite often. This seems like a question for [BAKER]. > How does renumbering differ from a planned outage? When those > occur, applications either restart or are restarted once the > change is made. We don't want applications to have to restart; we want them to continue through to completion. > In addition, just because a subnetwork disconnects, it doesn't > terminate the use of prefixes within the subnetwork. So, the > apps can keep using those addresses until the nodes are told > of new ones. > > The requirement seems to be for a stable address for a long period > of time (months, years, decades, etc). If that is the requirement, > then state it as such. Long period of time, perhaps, but how long is difficult to quantify. Again, perhaps this is a question for the [BAKER] renumbering draft. > >> >> 3.3 Multiple Link Support >> >> Addresses for local communications within sites should support >> operation over multiple links, e.g., via L3 routing, L2 bridging or >> some combination thereof. As such, subnetting consistent with the >> recommendations in ([RFC3177], section 3) should be supported. >> >> Link-local addresses in IPv6: "are designed to be used for addressing >> on a single link for purposes such as automatic address >> configuration, neighbor discovery, or when no routers are present" >> ([RFC3513], section 2.5.6). By definition, link-local addresses have >> a single link range of operation and will not meet this goal. > > > I don't think this section even belongs here. We have link-locals > defined already, so someone will not re-define them. I suggest taking > it out altogether. Remove all of section 3.3, or just the second paragraph? (The first paragraph is the only text in the document that speaks to the possibility of subnetting within the site.) >> >> 3.4 Well-known Prefix > > > I think this section is an excellent example of trying to solve > an operational issue with an addressing scheme. Several people > have suggested this before, but a "well-known" prefix can just as > easily be carved out of one's global prefix. > > In addition, how exactly does an app figure out "the hint"? It > has no way of knowing which side of the site boundary it currently > resides. The well-known prefix works for filtering at boundaries, > not for special handling by an app. I have no opinion on this question; do you have anything to add on this subject, Tony? >> 3.5 Globally Unique >> >> Addresses used by sites should be globally unique such that site >> mergers will not result in collisions. Global uniqueness is based on >> the statistical properties of address allocations, therefore >> proposals should specify a suitable means for random prefix >> generation. Addressing scheme proposals should also provide a >> suitable means for conflict resolution, e.g., certification through a >> central registry, distributed database, etc. > > > Doesn't this directly conflict with the requirement in 3.1 for > no public registry? As I mentioned in response to the section 3.1 comments, we want to support both those scenarions that require autonomous address configuration with no registration in which statistical uniqueness is sufficient, and those that require conflict resolution and true global uniqueness as provided through a registration authority. Can you suggest a way for us to clarify? >> >> Sufficient global uniqueness is needed to support, e.g.: >> >> o VPNs between enterprises >> >> o dynamically created VPNs in support of temporary virtual >> organizations >> >> o service provider co-location of hosts that reside in the address >> space of multiple customers >> >> o formation of virtual organizations (Grids) among enterprises >> >> o mergers and acquisitions of enterprises such that address spaces >> do not collide > > > I am confused by this list. One could argue that all of the above > put together requires globally routed addresses. The objective of this document is to present the goals for local communications within sites; not to argue for one solution alternative over another. If others use this document as a talking point for arguing the solution alternatives, then the document will have served its purpose. > Perhaps the better way to approach this is to discuss the tradeoffs > of centrally-allocated addresses and locally-allocated addresses in > supporting tools such as VPNs. OK, if f we can do so without departing from the goals focus and getting too close to the realm of solutions. Any suggetions would be welcome. >> 3.6 Usable in the Absence of a Provider >> >> Active sites need addresses that can be used when there is no active >> link to a provider. In the case of intermittently-connected sites, >> provider access may be unavailable for long periods but this should >> not disrupt local communications within the site. In the case of >> sites moving to new provider points of attachment, frequent >> renumbering events may occur but, again, local communications should >> not be disrupted. >> > > The current scheme for renumbering allows for overlapping of the > old and new prefixes for a period of time. This would apply to > the intermittently-connected sites as well. Apps can continue to > use the old prefixes for internal sessions until the pre-planned, > hard cutover. Once that cutover occurs, the apps will disconnect > from the old prefix and re-establish through the new prefix. OK. > >> PI addresses provide one solution alternative genre that also >> appliies to cases where network managers want global access. The >> issue is that PI addresses with no designed aggregation properties >> may lead to global routing table explosion (if advertised outside the >> site) given current routing technologies. For this reason, PI >> addressing scheme proposals should either provide reasonable >> aggregation properties or a detailed analysis of their interactions >> with global routing technologies. PA and other non-PI proposals >> should explain how the proposed addressing schemes will support local >> communications in the presence of intermittent and/or disconnected >> provider access. > > > What is the purpose of having this short discussion of PI addresses > in this document? Well, your point could be made that this is getting away from goals and touching too closely on solution space. I could live with dropping this text, if that is what you are suggesting. Tony? > >> 3.8 Compatible with Site Naming System >> > > Since the document assumes that addressing will be the solution, > why have this section on naming? Didn't quite understand this comment; can you clarify? >> 3.9 Compatible with VPN >> > > See my comments on section 3.5. This is a prime example for > the use of global addresses. If you think this is getting away from goals and coming too close to solutions, please explain; the section seems to be describing a goal to me. >> 4.1 Border Filtering >> >> Network managers limit specific applications to internal use, so they >> configure them to only work with a filtered address range. This >> simplifies the border filter to an address prefix, rather than >> needing to employ deep packet inspection to track a potentially >> dynamic range of ports. >> > > Again, if they are connected to the Internet, they can carve out a > portion of the global prefix IF you want to rely on this type of > filtering for "application protection". I have the same concern > about this section as raised with section 3.4 In discussing the > issue of filtering, I would like to see the tradeoffs, e.g. real > cost, of using a portion of your global space vs. local addresses. Again, I'll have to ask that Tony comment on this one. >> 4.2 Maintaining Confidentiality of the Address Space >> >> Private space may be used to avoid exposing to competitors what >> internal networks they are deploying and which office is coordinating >> that effort. Network managers also don't have to expose business >> plans to a registrar for evaluation for networks that are not >> attached to the global Internet. Some have stated that if they are >> required to register for public space for every internal use network, >> they are more likely to pick random numbers than tip off the >> competition. > > > Can you give an example of how this works? Knowing what someone's > prefix is doesn't reveal what internal networks are being deployed. This one also for Tony. >> >> 4.3 Test Networks >> >> Another significant use of private address space is test networks. >> Frequently these are large, elaborate networks with a mix of public >> and private address space. Use of random unallocated space runs the >> risk of collision with legitimate addresses on remote networks. > > > But you can mitigate that risk if you sub-divide your public space > and filter the chunk you want private. > > >> 4.5 Mobile Router with Personal Area Network > > >> 4.6.2 Groups of Nodes that Travel Together > > > I made this comment earlier, but it applies to these two sections > as well. Just because a network is dis-connected, does not mean > it can't keep using the prefix it was assigned when it was connected. Well, again we are talking about goals here - not solutions. The goal is to support local communications within groups of nodes that travel together with possible long periods of intermittent/disconnected access. The solution is out of scope for this document. > I suggest that this section spell out the issues of long-term use > of an ISP-assigned prefix after the dis-connection. And that this > take into account whether the customer has negotiated the rights > to "keep" the prefix during the intermittently connected time. But, would this take us back into solution space again? >> Research ships at sea intermittently connect via INMARSAT, or when in >> port, the shipboard network is connected to shore via Ethernet. Of >> utmost importance is that the systems on board the ship all function, >> providing data collection and analysis without interruption. Static >> addressing is used on most intra-ship network components and servers. >> It's quite expensive to operate a research ship, so eliminating >> points of failure is important. Scientists on board collaborate with >> colleagues back home by sharing of data and email. Currently private >> address space is employed for several reasons: 1) it provides the >> ability to allocate significant address space to each ship without >> needing to worry about how many computers will be on a given cruise. >> 2) it provides separate address space for each ship. 3) it simplifies >> filtering to ensure shipboard traffic is not permitted to transmit >> out or bring up expensive satellite links. > > > Point 1 is a no-op, it can be accomplished with almost any addressing > mechanism. Point 2 screams for the use of global addresses. And 3 > can, once again, be accomplished through many other means besides a > special address range. Are you suggesting any changes for the document in this comment? >> 5. Perceived Advantages of Limited Range Addressing Solutions >> >> Limited range addressing solutions allow filtering, and filtering >> creates addressing boundaries no matter where the bits come from. The >> point is that some addresses are only valid within the range defined >> by the local network manager. > > > I agree with this sentence. Some addresses are only valid in an area > defined by the manager. And that can be accomplished in several ways. OK. >> In the simple case, hosts that are allowed external access have a >> policy that allows them to configure both global and limited range >> prefixes, while those that are not allowed global access have a >> policy that only allows limited range. Address selection policy >> tables might need modifications to enable the selection of limited >> range address space over global addresses. Given such modifications, >> address selection rules will prefer the smallest range so internal >> communications are forced to stay internal by the hard filter at the >> border. >> >> If an application chooses to assert a policy that is different from >> the network manager's filtering rules, it will fail. Having a well >> defined limited range address space that is known to have filtering >> applied allows applications to have a hint about potential range >> restrictions. We can choose to leave the network managers to figure >> out their own adhoc mechanisms, or we can put them in a structured >> limited range address space so that applications will have a chance >> to react appropriately. > > > This paragraph raises the point that the proposals by Zill and > Bellovin or other similar approaches to advertise "special" prefixes > via an RA may be useful tools for us to provide. And I am sure others > will see the same. Perhaps there needs to be some wrap-up on the > operational issues between using such an approach and using a local > addressing scheme. OK; we can investigate this further. > Regards, > Brian > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 16:01:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13365 for ; Tue, 30 Sep 2003 16:01:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qg6-0002Qy-9c for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 16:00:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UK0wEs009357 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 16:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qg3-0002Qp-TT for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 16:00:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13307 for ; Tue, 30 Sep 2003 16:00:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Qg2-0004WH-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 16:00:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Qg1-0004WE-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 16:00:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QfF-00028V-49; Tue, 30 Sep 2003 16:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qem-00027V-Mv for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 15:59:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13140 for ; Tue, 30 Sep 2003 15:59:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Qel-0004TO-00 for ipv6@ietf.org; Tue, 30 Sep 2003 15:59:35 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A4Qek-0004SW-00 for ipv6@ietf.org; Tue, 30 Sep 2003 15:59:34 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8UJwtF11225; Tue, 30 Sep 2003 12:58:55 -0700 X-mProtect: <200309301958> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt2uRbW; Tue, 30 Sep 2003 12:58:53 PDT Message-ID: <3F79E125.8040504@iprg.nokia.com> Date: Tue, 30 Sep 2003 13:01:41 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms CC: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <3F730183.6090504@caspiannetworks.com> <3F730183.6090504@caspiannetworks.com> <4.3.2.7.2.20030930124555.01fd8b00@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Ralph, Thanks for the comments; please see my responses below: Fred ftemplin@iprg.nokia.com Ralph Droms wrote: > Here are my comments on draft-hain-templin-ipv6-limitedrange-02.txt... > > Global organization - as I read the doc (others' reactions may differ), I > feel like I'm reading a document that is based on some assumptions > about the > solution before describing the problem. In particular, the first > sentence > in the second paragraph of the Introduction: > > There is a perceived need for an addressing scheme that supports > local communications within sites. > > seems to me to conclude, without explicit support for the conclusion, > that > something like site-local addresses is required. Even the title, > "Goals for > an Addressing Scheme to Support Local Communications within Sites" > suggests > the outcome. I suggest renaming the doc to "Goals for Local > Communication > within Sites". As I also responded to Brian Haberman, a title change seems appropriate and your suggestion looks good. Any other suggestions for a new title? > It turns out that you do have support for the "perceived need" in > section 4. > So my suggestion would be to swap sections 3 and 4, and add a sentence in > the introduction: > > There is a perceived need for an addressing scheme that supports > local communications within sites. The next section gives > several scenarios in which local communications within a site > are required. > > Then, the goals can be justified by reference to the scenarios. The section-swap sounds like a very reasonable suggestion for the next draft version. > Comments about scenarios: > > 4.2 Why would an organization ever have to expose the internal networks > being deployed and what office is coordinating the effort? > > 4.3 Is this test network connected to the Internet? I believe these are best for Tony to answer. > 4.4 I think this scenario would be clearer if it were labelled "Static > Configuration with Addresses" or some such. The problem is really static > configuration of an address rather than caching an address learned > through > some other process. Agree with the comment as a reasonable suggestion for the next draft version. > 4.6 What about a completely disconnected ad-hoc network (not necessarily > mobile)? I'm thinking of 5 guys in a bar using an ad hoc network with no > Internet connection... This scenario seems to be covered already in section 4.6.1, but please let us know if you think text changes are needed. > 4.8 I'm afraid I couldn't understand this scenario at all. When the two > sites connect, do they essentially merge into a single, multi-homed site? I believe the answer to this is yes, and I believe Brian Haberman also expressed concerns about such scenarios since they touch on site multi-homing. (My answer to Brian is that we are not trying to re-create RFC 3582 in this document.) What you would suggest in terms of this block of text? > Is the "local traffic" between hosts within the merged A/B site? Essentially, yes. Again, the disposition of this block of text probably warrants further discussion. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 19:51:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21448 for ; Tue, 30 Sep 2003 19:51:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4UHG-0005hH-PD for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 19:51:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UNpYMR021893 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 19:51:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4UHG-0005h2-Jm for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 19:51:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21429 for ; Tue, 30 Sep 2003 19:51:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4UHE-0006u3-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 19:51:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4UHE-0006u0-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 19:51:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4UGl-0005b6-2j; Tue, 30 Sep 2003 19:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4UG4-0005Yu-AW for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 19:50:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21409 for ; Tue, 30 Sep 2003 19:50:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4UG2-0006tZ-00 for ipv6@ietf.org; Tue, 30 Sep 2003 19:50:18 -0400 Received: from c211-29-163-60.carlnfd2.nsw.optusnet.com.au ([211.29.163.60] helo=bsdi.dv.isc.org) by ietf-mx with esmtp (Exim 4.12) id 1A4UG1-0006tW-00 for ipv6@ietf.org; Tue, 30 Sep 2003 19:50:17 -0400 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h8UNoE0o084744; Wed, 1 Oct 2003 09:50:15 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309302350.h8UNoE0o084744@bsdi.dv.isc.org> To: Abdul-Hafeez Jamali Cc: ipv6@ietf.org From: Mark.Andrews@isc.org Subject: Re: help In-reply-to: Your message of "Tue, 30 Sep 2003 11:17:21 MST." <20030930181721.56060.qmail@web12905.mail.yahoo.com> Date: Wed, 01 Oct 2003 09:50:14 +1000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Hi all > I m new to IPv6. Can anybody answer the following question, so that I could b > etter understand IPv6 : > > Is fragmentaion is possible in IPv6 Packet/datagram ?? if Yes then how ??? if > No. then why not ??? See RFC 2460. http://www.ietf.org/html.charters/ipv6-charter.html Also please do not send HTML to the list. > Thanx > > ahj -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 21:02:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23488 for ; Tue, 30 Sep 2003 21:02:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VN4-0001Ra-2t for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 21:01:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9111ctx005544 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 21:01:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VN3-0001RL-UT for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 21:01:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23437 for ; Tue, 30 Sep 2003 21:01:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4VN1-0007cQ-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 21:01:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4VN1-0007cN-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 21:01:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VMW-0001HC-Dq; Tue, 30 Sep 2003 21:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VMI-0001GB-1k for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 21:00:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23391 for ; Tue, 30 Sep 2003 21:00:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4VMF-0007bs-00 for ipv6@ietf.org; Tue, 30 Sep 2003 21:00:47 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1A4VME-0007bp-00 for ipv6@ietf.org; Tue, 30 Sep 2003 21:00:46 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h9110j1d027548 for ; Tue, 30 Sep 2003 18:00:45 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h9110fSt015228 for ; Tue, 30 Sep 2003 20:00:43 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.10/8.12.10) with ESMTP id h9110eEK016823 for ; Wed, 1 Oct 2003 11:00:40 +1000 (EST) Message-ID: <3F7A2736.75566C22@motorola.com> Date: Wed, 01 Oct 2003 11:00:38 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt References: <3F730183.6090504@caspiannetworks.com> <3F730183.6090504@caspiannetworks.com> <4.3.2.7.2.20030930124555.01fd8b00@flask.cisco.com> <3F79E125.8040504@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As the originator of section 4.8, I'll speak to this one... Fred Templin wrote: > > > 4.8 I'm afraid I couldn't understand this scenario at all. When the > > two sites connect, do they essentially merge into a single, > > multi-homed site? > > I believe the answer to this is yes, and I believe Brian Haberman > also expressed concerns about such scenarios since they touch on > site multi-homing. (My answer to Brian is that we are not trying > to re-create RFC 3582 in this document.) What you would suggest > in terms of this block of text? I don't think it's possible to completely divorce local addressing from multi-homing, unless we want to go down the NAT path (any takers? No, I thought not). One local addressing model that both Tony and I have been envisioning (and IMO the most compelling) is that of disjoint, overlapping addressing spaces. The local network uses an internal addressing scheme for all internal operations. When and if 'external' connectivity is applied (which may be another 'local' network) the external space is also made available to all nodes within the network that want external operation. Local nodes are configured to prefer the internal addresses for internal use and the global addresses for destinations that don't have a matching internal address. Note that the 'internal' addresses could be global unicast addresses or 'local' addresses. Likewise the 'external' addresses, although these will probably be global. The key issue is that the 'internal' addresses are provider independent. The core address space of the network is independent of the presence or absence of an ISP. For the 'zeroconf home' scenario, registration-free local addresses become very attractive for the internal address space. They don't need to care about ISPs or any external stuff, and unique address spaces can be easily configured. And a RFC3484 implementation will favour them over global addresses. Connecting two of these networks together is interesting. The assumption is that the connection is via a 'local' channel - one that is (virtually) 'inside' whatever mechanisms define the borders between the local address spaces and the global space. However, what sort of 'merging' occurs is harder to determine. Some scenarios: (1) Minimal merging: The two 'local' networks talk via a pair of gateways, and all traffic for the other network's address space/s is directed to that network's gateway. DNS and like services are similarly redirected. (2) Routing table merging: Full routing information is passed across the two networks. Addresses are allocated independently by each network. (3) Full merging: The two networks become one network, sharing prefixes originally owned by one or the other network across all nodes. Option 1 is probably easiest. Local addresses provide an advantage here again, in that if both networks are using local addresses RFC3484 will cause inter-network communications to favour the local addresses. The most interesting case in network merging occurs when the local addresses are allocated by the routers, using the strategy described in 'draft-white-auto-subnet-00' (). From an address allocation perspective, only 'external' prefixes are propagated - the internal addressing scheme is built into the routers. Under this model, there is no need to propagate the internal prefixes - the address spaces are already compatible. All that is required is to connect the routes and propagate service information (such as DNS). External prefixes still need to be propagated. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 30 23:58:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28078 for ; Tue, 30 Sep 2003 23:58:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Y8H-0001fG-LN for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 23:58:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h913wXsM006392 for ipv6-archive@odin.ietf.org; Tue, 30 Sep 2003 23:58:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Y8H-0001f1-D4 for ipv6-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 23:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28024 for ; Tue, 30 Sep 2003 23:58:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Y8F-0001No-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 23:58:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Y8E-0001Nl-00 for ipv6-web-archive@ietf.org; Tue, 30 Sep 2003 23:58:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Y7m-0001Y8-Hf; Tue, 30 Sep 2003 23:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Y7h-0001XS-6e for ipv6@optimus.ietf.org; Tue, 30 Sep 2003 23:57:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28002 for ; Tue, 30 Sep 2003 23:57:48 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Y7e-0001NF-00 for ipv6@ietf.org; Tue, 30 Sep 2003 23:57:54 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A4Y7d-0001NB-00 for ipv6@ietf.org; Tue, 30 Sep 2003 23:57:54 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h913vr625220 for ; Wed, 1 Oct 2003 06:57:53 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 1 Oct 2003 06:57:53 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 06:57:53 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 06:57:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 1 Oct 2003 06:57:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue27: 11. Security Considerations Date: Wed, 1 Oct 2003 06:57:50 +0300 Message-ID: Thread-Topic: Node Req: Issue27: 11. Security Considerations Thread-Index: AcOHQQk2K8nMJ6iGTT6G0jcxzIRnOwAjx70A To: Cc: , X-OriginalArrivalTime: 01 Oct 2003 03:57:52.0561 (UTC) FILETIME=[300CFA10:01C387D0] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Thomas, I'll remove the text. John > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: 30 September, 2003 13:50 > To: Loughney John (NRC/Helsinki) > Cc: ipv6@ietf.org; jari.arkko@kolumbus.fi > Subject: Re: Node Req: Issue27: 11. Security Considerations=20 >=20 >=20 > > Your comments at the end of this mail confused me. Do you=20 > want the text > > removed or do you want clarifying text? >=20 > I'm fine with removing it. My last point was more about if it's felt > the text needs to stay. >=20 > Thomas >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------