From int-area-bounces@lists.ietf.org Fri Nov 04 22:51:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYF5q-0004du-T3; Fri, 04 Nov 2005 22:51:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYF5n-0004dm-GD for int-area@megatron.ietf.org; Fri, 04 Nov 2005 22:51:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05747 for ; Fri, 4 Nov 2005 22:51:23 -0500 (EST) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYFKs-00055l-0O for int-area@ietf.org; Fri, 04 Nov 2005 23:07:25 -0500 Received: from [66.30.121.250] (account margaret HELO ceili) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 574956 for int-area@ietf.org; Fri, 04 Nov 2005 22:51:44 -0500 From: "Margaret Wasserman" To: Date: Fri, 4 Nov 2005 22:51:32 -0500 Message-ID: <004f01c5e1bc$360a8ed0$0302a8c0@instant802.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXhvDWc4R1uT1Q3Qk+ZdwGnH95R+g== X-Spam-Score: 0.1 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: Subject: [Int-area] INT AD Office Hours X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1284768274==" Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1284768274== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C5E192.4D3486D0" This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C5E192.4D3486D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Just FYI - As usual, we will have INT AD open office hours from approximately 1pm-5pm on Sunday afternoon at a location TBD. Mark just had a baby and probably won't be able to join us this time around, but I would be happy to meet with anyone who would like to discuss anything with me. You can arrange an appointment ahead of time, or just stop by. I'll send room information when it is available. Margaret ------=_NextPart_000_0050_01C5E192.4D3486D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Just FYI –

 

As usual, we will have INT AD open office hours from approximately 1pm-5pm on Sunday afternoon at a location TBD.  Mark = just had a baby and probably won’t be able to join us this time around, = but I would be happy to meet with anyone who would like to discuss anything = with me.  You can arrange an appointment ahead of time, or just stop = by.  I’ll send room information when it is = available.

 

Margaret

 

 

------=_NextPart_000_0050_01C5E192.4D3486D0-- --===============1284768274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============1284768274==-- From int-area-bounces@lists.ietf.org Sat Nov 05 06:59:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYMiE-0006tn-Eb; Sat, 05 Nov 2005 06:59:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYMiD-0006tf-Ad; Sat, 05 Nov 2005 06:59:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26992; Sat, 5 Nov 2005 06:59:32 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYMxO-00082o-EN; Sat, 05 Nov 2005 07:15:39 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 05 Nov 2005 03:59:47 -0800 X-IronPort-AV: i="3.97,293,1125903600"; d="scan'208"; a="672136868:sNHT29441294" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA5BxgNl005647; Sat, 5 Nov 2005 03:59:43 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Nov 2005 06:59:42 -0500 Received: from [10.83.1.102] ([10.83.1.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Nov 2005 06:59:41 -0500 Message-ID: <436C9E8D.3000305@cisco.com> Date: Sat, 05 Nov 2005 12:59:09 +0100 From: Mark Townsley User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IAB , IESG , int-chairs@cisco.com, Internet Area Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 05 Nov 2005 11:59:42.0116 (UTC) FILETIME=[67E97E40:01C5E200] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA26992 Cc: Subject: [Int-area] Coming to Vancouver! X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org All, I had previously announced that I would not be physically present at the=20 Vancouver IETF due to the pending birth of my child who was due to=20 arrive on Oct 28. Little L=E9na arrived a bit early, on Oct 20, and both=20 her and her Mother are doing well now. I've lined up family (in Paris=20 and traveling from the US) to help out, and believe I can responsibly=20 get on a plane and travel 5000 miles from home. Assuming flights are on=20 time, I arrive at YVR 13:50 on Sunday. I intend to stay the full week,=20 but will catch the next flight back in case there are any problems at=20 home. So, assuming all goes well, see you tomorrow! - Mark Disclaimer: I am stepping from one sleep-deprived state (as any of you=20 who have taken care of a newborn know), though a 9 hour time change, and=20 directly into the IETF without consulting much email at all for more=20 than 2 weeks. My cache is completely wiped. Apologies in advance for the=20 extra effort which may be required to reload it. PS. Here's the link from a proud new Father! http://www.townsley.net/lena _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sun Nov 06 13:56:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpgc-0007s4-G3; Sun, 06 Nov 2005 13:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpgb-0007rx-Gg for int-area@megatron.ietf.org; Sun, 06 Nov 2005 13:56:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14468; Sun, 6 Nov 2005 13:55:45 -0500 (EST) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYpw0-0001q5-FN; Sun, 06 Nov 2005 14:12:10 -0500 Received: from [209.52.109.222] (account margaret HELO ceili) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 575635; Sun, 06 Nov 2005 13:56:01 -0500 From: "Margaret Wasserman" To: , Date: Sun, 6 Nov 2005 13:55:50 -0500 Message-ID: <001101c5e303$b5c809c0$de6d34d1@instant802.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcXjA7QyoQyVI/pxSKqqBYOZrj9zUg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: Subject: [Int-area] INT AD Office Hours X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1357148526==" Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1357148526== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C5E2D9.CCF201C0" This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C5E2D9.CCF201C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, The INT AD office hours will be held in the Capilano Room from 2pm - 5pm PST this afternoon (Sunday). The IESG meeting is scheduled to end at 2pm, and I will be there as soon as possible thereafter. Mark is coming to Vancouver after all, but I don't know if he will be here in time for office hours. So, come visit, because otherwise I'll be there all alone. :-( Margaret ------=_NextPart_000_0012_01C5E2D9.CCF201C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The INT AD office hours will be held in the Capilano = Room from 2pm – 5pm PST this afternoon (Sunday).  The IESG meeting is scheduled to end at 2pm, and I will be there as soon as possible = thereafter.

 

Mark is coming to Vancouver after all, but I don’t know if he will be here in time for office hours.  So, come visit, because otherwise I’ll be there all alone.  L

 

Margaret

 

 

------=_NextPart_000_0012_01C5E2D9.CCF201C0-- --===============1357148526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============1357148526==-- From int-area-bounces@lists.ietf.org Wed Nov 09 13:49:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv0r-0007nG-Gl; Wed, 09 Nov 2005 13:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv0p-0007me-SN; Wed, 09 Nov 2005 13:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29607; Wed, 9 Nov 2005 13:49:08 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvGs-0005du-RO; Wed, 09 Nov 2005 14:06:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8799B212C2D; Wed, 9 Nov 2005 20:49:14 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 9 Nov 2005 10:49:10 -0800 To: Internet Area X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: HIP , ipv6@ietf.org Subject: [Int-area] KHIs and SHA-256 X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Internet Area , Pekka Nikander List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org [Cross-posted to HIP WG and IPv6 WG; replies _only_ to INT area please.] I'd like to direct people's attention to draft-laganier-ipv6- khi-00.txt at http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-00.txt Here is the abstract: This document introduces Keyed Hash Identifiers (KHI) as a new, experimental class of IPv6-address-lookalike identifiers. They are constructed to be statistically globally unique. They are intended to be used as identifiers only, and not as locators. They should not appear in actual IPv6 headers. Consequently, they are considered as non-routable addresses from the IPv6 point of view. These identifiers are expected to be used at the existing IPv6 API and application protocols between consenting hosts. They may be defined and used in different contexts, suitable for different protocols. Examples of these include Host Identity Tags (HIT) in the Host Identity Protocol (HIP) and Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Keyed Hash Identifiers. The basic question is whether we should go forward with it, and if so, where? Could we last call it at the Internet Area, as the IPv6 chairs indicate that they consider it a larger issue and not just IPv6 specific? I would also get people's opinion whether SHA-1 is OK for the document, as currently the proposed experiment is to end by 2009. According to the discussion at security directorate yesterday, SHA-1 is expected to be at the end of life by 2010. Consequently, for most security protocols there will be two transitions in the foreseeable future, first to SHA-256, and then to something that NIST may be getting to within the next five years or so. Hence, are we happy with going with (patched) SHA-1 with the expectation that the experiment will end by 2009, and will also become unsecure around the same time, or should we adopt SHA-256 from the beginning? See also the previous discussion at the IPv6 WG, starting at http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html --Pekka Nikander _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 10 11:43:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFVs-0008QJ-9k; Thu, 10 Nov 2005 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFVq-0008Ny-Th; Thu, 10 Nov 2005 11:42:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15500; Thu, 10 Nov 2005 11:42:30 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFm5-0007f6-Ak; Thu, 10 Nov 2005 11:59:46 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAAGeAtK016536; Thu, 10 Nov 2005 18:40:12 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Nov 2005 18:42:54 +0200 Received: from [209.52.107.220] ([10.241.58.93]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Nov 2005 18:42:54 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Thu, 10 Nov 2005 08:42:52 -0800 To: Internet Area , Pekka Nikander X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 10 Nov 2005 16:42:54.0272 (UTC) FILETIME=[CC177C00:01C5E615] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: HIP , ipv6@ietf.org Subject: [Int-area] Re: KHIs and SHA-256 X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka, On Nov 9, 2005, at 10:49 AM, ext Pekka Nikander wrote: > > The basic question is whether we should go forward with it, and if > so, where? > Could we last call it at the Internet Area, as the IPv6 chairs > indicate that they consider it a larger issue and not just IPv6 > specific? While I do think there are larger issues here, since this proposes an allocation of IPv6 addresses I think it is important that the IPv6 working group review it. It would be good to talk to the Internet ADs to figure out the best way forward (e.g., where to last call it, etc.). Thanks, Bob > I would also get people's opinion whether SHA-1 is OK for the > document, as currently the proposed experiment is to end by 2009. > According to the discussion at security directorate yesterday, > SHA-1 is expected to be at the end of life by 2010. Consequently, > for most security protocols there will be two transitions in the > foreseeable future, first to SHA-256, and then to something that > NIST may be getting to within the next five years or so. Hence, > are we happy with going with (patched) SHA-1 with the expectation > that the experiment will end by 2009, and will also become unsecure > around the same time, or should we adopt SHA-256 from the beginning? > > See also the previous discussion at the IPv6 WG, starting at > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html > > --Pekka Nikander > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 10 16:06:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJcy-0006M3-8b; Thu, 10 Nov 2005 16:06:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJcv-00069d-9i; Thu, 10 Nov 2005 16:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08788; Thu, 10 Nov 2005 16:06:04 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaJtC-0001iA-1L; Thu, 10 Nov 2005 16:23:23 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.7558121; Thu, 10 Nov 2005 16:05:56 -0500 In-Reply-To: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> References: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Date: Thu, 10 Nov 2005 16:05:55 -0500 To: Bob Hinden X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ipv6@ietf.org, Internet Area , HIP Subject: [Int-area] Re: KHIs and SHA-256 X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0781937377==" Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org --===============0781937377== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-878217170; protocol="application/pkcs7-signature" --Apple-Mail-7-878217170 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit My understanding is that these are not routable addresses. That is, they won't appear in routing protocol exchanges or routing tables. If that is the case, then we are talking about the allocation of something different than IPv6 addresses. Regards, Brian On Nov 10, 2005, at 11:42, Bob Hinden wrote: > Pekka, > > On Nov 9, 2005, at 10:49 AM, ext Pekka Nikander wrote: >> >> The basic question is whether we should go forward with it, and if >> so, where? >> Could we last call it at the Internet Area, as the IPv6 chairs >> indicate that they consider it a larger issue and not just IPv6 >> specific? > > While I do think there are larger issues here, since this proposes an > allocation of IPv6 addresses I think it is important that the IPv6 > working group review it. It would be good to talk to the Internet ADs > to figure out the best way forward (e.g., where to last call it, > etc.). > > Thanks, > Bob > > >> I would also get people's opinion whether SHA-1 is OK for the >> document, as currently the proposed experiment is to end by 2009. >> According to the discussion at security directorate yesterday, SHA-1 >> is expected to be at the end of life by 2010. Consequently, for most >> security protocols there will be two transitions in the foreseeable >> future, first to SHA-256, and then to something that NIST may be >> getting to within the next five years or so. Hence, are we happy >> with going with (patched) SHA-1 with the expectation that the >> experiment will end by 2009, and will also become unsecure around the >> same time, or should we adopt SHA-256 from the beginning? >> >> See also the previous discussion at the IPv6 WG, starting at >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html >> >> --Pekka Nikander >> >> >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- --Apple-Mail-7-878217170 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTEwMjEwNTU2WjAjBgkqhkiG9w0B CQQxFgQU64E3f6sPtiKyzdr9SzOb0YNbPBUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAt7ac5zXNeEQQazfrYQzxzzm2HL9NwYSvK2bi0g3Sc+eZ3nYSY584tW5FGpXPF8+C1uR7 vqPxOc7+m2UrIiDI5wGHJxCR0JfgBghApMnIsBbJ7ymOpzjKxTXwASxAY306QE84RpDkuyPIfqWB JEi1Wyli3ydw/aBV0yXERmHhJSfnjKKuLX6RPTS1TL19ApcN14ojp+dE+mPd9HVAR4nBPn2Z74U1 XQ1yPUdRY5M2PFDmZJesUhNhenYFPAuGQh4PwoNRBUFY8UdgQFPZL/kCT92mCkmZZjg7y3ZGp6tU O/6EG/evYx3loLF86qt0wQIlQlLCunK3n11bGyiDS1B5agAAAAAAAA== --Apple-Mail-7-878217170-- --===============0781937377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============0781937377==-- From int-area-bounces@lists.ietf.org Thu Nov 10 17:28:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKtr-0000uU-QW; Thu, 10 Nov 2005 17:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKto-0000tr-Mb; Thu, 10 Nov 2005 17:28:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20771; Thu, 10 Nov 2005 17:27:35 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLA6-0006ZK-0u; Thu, 10 Nov 2005 17:44:55 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAAMRhR17814; Thu, 10 Nov 2005 23:27:43 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAAMRi6V015702; Thu, 10 Nov 2005 23:27:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman Subject: Re: [Int-area] Re: KHIs and SHA-256 In-reply-to: Your message of Thu, 10 Nov 2005 16:05:55 EST. Date: Thu, 10 Nov 2005 23:27:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org, Internet Area , HIP X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org In your previous mail you wrote: My understanding is that these are not routable addresses. That is, they won't appear in routing protocol exchanges or routing tables. If that is the case, then we are talking about the allocation of something different than IPv6 addresses. => you are right: not only they are not routable but they should be easy to be recognized as not routable. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 10 17:47:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLCY-0000LP-SH; Thu, 10 Nov 2005 17:47:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLCX-0000Jc-I9; Thu, 10 Nov 2005 17:47:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22253; Thu, 10 Nov 2005 17:46:56 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLSp-0007DW-Cz; Thu, 10 Nov 2005 18:04:16 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2F5E0212C2D; Fri, 11 Nov 2005 00:47:04 +0200 (EET) In-Reply-To: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Thu, 10 Nov 2005 14:47:01 -0800 To: Brian Haberman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org [Dropping HIP WG from CC; still including IPv6 though...] >> My understanding is that these are not routable addresses. That >> is, they won't appear in routing protocol exchanges or routing >> tables. If that is the case, then we are talking about the >> allocation of something different than IPv6 addresses. > > you are right: not only they are not routable but they should be > easy to be recognized as not routable. To clarify: if we decide to define this prefix, it will mean that the particular prefix will be generally unavailable for routing, as there will be hosts that will use the prefix at the API level. Consequently, if you want to talk to those hosts, you cannot use the prefix in the network. Hence, even though the prefix is not assumed to appear in the wire, defining this does effect on what bits can(not) be used in the wire. --Pekka Nikander _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Nov 11 14:05:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeDD-0002dH-3I; Fri, 11 Nov 2005 14:05:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeDA-0002cB-Ka; Fri, 11 Nov 2005 14:05:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28166; Fri, 11 Nov 2005 14:04:50 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaeTd-0001J3-JP; Fri, 11 Nov 2005 14:22:22 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jABJ0obe028958; Fri, 11 Nov 2005 21:00:51 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 21:05:16 +0200 Received: from [209.52.107.220] ([10.241.58.144]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Nov 2005 21:05:15 +0200 In-Reply-To: References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Fri, 11 Nov 2005 11:05:11 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 11 Nov 2005 19:05:16.0204 (UTC) FILETIME=[D9E49EC0:01C5E6F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Hi, > [Dropping HIP WG from CC; still including IPv6 though...] > >>> My understanding is that these are not routable addresses. That >>> is, they won't appear in routing protocol exchanges or routing >>> tables. If that is the case, then we are talking about the >>> allocation of something different than IPv6 addresses. >> >> you are right: not only they are not routable but they should be >> easy to be recognized as not routable. > > To clarify: if we decide to define this prefix, it will mean that > the particular prefix will be generally unavailable for routing, as > there will be hosts that will use the prefix at the API level. > Consequently, if you want to talk to those hosts, you cannot use > the prefix in the network. > > Hence, even though the prefix is not assumed to appear in the wire, > defining this does effect on what bits can(not) be used in the wire. Right, the draft proposes to get an allocation from IPv6 unicast space to allow the addresses to be distinguished from the rest of the address space. I see two issues. The first is to make sure there are enough cautionary words in the draft to insure no one thinks these are intended to be put into packets and routed. The general topic of allocating addresses that are not CIDR routable has caused a lot of controversy in the past (e.g., ULA discussions). The second is that while it is may be OK to allocate a block of IPv6 addresses for this experiment, I don't think we would want to have multiple experiments all wanting a separate allocation. I was thinking we could allocate a block of IPv6 non-routable addresses for experimental purposes and this proposal could then use that block. This would allow other experiments to use the addresses at the same time. Bob _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Nov 12 22:35:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eO-000550-Cx; Sat, 12 Nov 2005 22:35:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eM-00054Y-Pm; Sat, 12 Nov 2005 22:35:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09123; Sat, 12 Nov 2005 22:34:57 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb8v5-00021l-Rl; Sat, 12 Nov 2005 22:52:45 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAD3YSXv003925; Sun, 13 Nov 2005 14:34:34 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112224120.02e47008@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 22:45:08 +1100 To: Pekka Nikander , Brian Haberman From: Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 In-Reply-To: References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org At 09:47 AM 11/11/2005, Pekka Nikander wrote: >[Dropping HIP WG from CC; still including IPv6 though...] > >>> My understanding is that these are not routable addresses. That >>>is, they won't appear in routing protocol exchanges or routing >>>tables. If that is the case, then we are talking about the >>>allocation of something different than IPv6 addresses. >> >>you are right: not only they are not routable but they should be >>easy to be recognized as not routable. > >To clarify: if we decide to define this prefix, it will mean that the >particular prefix will be generally unavailable for routing, as there >will be hosts that will use the prefix at the API level. >Consequently, if you want to talk to those hosts, you cannot use the >prefix in the network. > >Hence, even though the prefix is not assumed to appear in the wire, >defining this does effect on what bits can(not) be used in the wire. But _nothing_ in what you have posted so far justifies and _address allocation_ From HIP's perspective _they are just numbers_ as they are identities, not locators. Geoff (The IAB had a draft for a while about identities, and then the IAB decided to drop it on the floor. Seems like it could sure come in useful here in terms of outlining to some IAB folk the difference between locators and identifiers!) _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Nov 12 22:35:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eP-00056p-N5; Sat, 12 Nov 2005 22:35:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eM-00054X-OZ; Sat, 12 Nov 2005 22:35:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09122; Sat, 12 Nov 2005 22:34:57 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb8v5-00021m-Rx; Sat, 12 Nov 2005 22:52:45 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAD3YSXt003925; Sun, 13 Nov 2005 14:34:30 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112224023.02d80718@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 22:41:07 +1100 To: Francis Dupont , Brian Haberman From: Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 In-Reply-To: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Internet Area , ipv6@ietf.org, HIP X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org At 09:27 AM 11/11/2005, Francis Dupont wrote: > In your previous mail you wrote: > > My understanding is that these are not routable addresses. That is, > they won't appear in routing protocol exchanges or routing tables. > If that is the case, then we are talking about the allocation of > something different than IPv6 addresses. > >=> you are right: not only they are not routable but they should >be easy to be recognized as not routable. +1 Geoff _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 06:19:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcMu-0000fM-20; Mon, 14 Nov 2005 06:19:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcMs-0000ej-NQ; Mon, 14 Nov 2005 06:19:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12843; Mon, 14 Nov 2005 06:18:51 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebcdr-0008LG-FM; Mon, 14 Nov 2005 06:36:58 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAEBIoH32583; Mon, 14 Nov 2005 12:18:50 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAEBIn4b033459; Mon, 14 Nov 2005 12:18:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141118.jAEBIn4b033459@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden Subject: Re: [Int-area] Re: KHIs and SHA-256 In-reply-to: Your message of Fri, 11 Nov 2005 11:05:11 PST. Date: Mon, 14 Nov 2005 12:18:49 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org In your previous mail you wrote: I see two issues. The first is to make sure there are enough cautionary words in the draft to insure no one thinks these are intended to be put into packets and routed. The general topic of allocating addresses that are not CIDR routable has caused a lot of controversy in the past (e.g., ULA discussions). The second is that while it is may be OK to allocate a block of IPv6 addresses for this experiment, I don't think we would want to have multiple experiments all wanting a separate allocation. I was thinking we could allocate a block of IPv6 non-routable addresses for experimental purposes and this proposal could then use that block. This would allow other experiments to use the addresses at the same time. => the draft is supposed to address both issues. For the first one we can add more cautionary words if one believes there are not yet enough. For the second one we already merged two very different experiments into one request. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 06:53:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebctq-0006xF-RF; Mon, 14 Nov 2005 06:53:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebcto-0006x3-JK; Mon, 14 Nov 2005 06:53:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14665; Mon, 14 Nov 2005 06:52:53 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbdAo-0000vU-Tk; Mon, 14 Nov 2005 07:11:00 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 95609212C3F; Mon, 14 Nov 2005 13:53:08 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051112224120.02e47008@localhost> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 12:53:07 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Geoff, >>>> My understanding is that these are not routable addresses. >>> >>> you are right: not only they are not routable but they should be >>> easy to be recognized as not routable. >> >> To clarify: if we decide to define this prefix, it will mean that the >> particular prefix will be generally unavailable for routing, as there >> will be hosts that will use the prefix at the API level. >> Consequently, if you want to talk to those hosts, you cannot use the >> prefix in the network. >> >> Hence, even though the prefix is not assumed to appear in the wire, >> defining this does effect on what bits can(not) be used in the wire. > > > But _nothing_ in what you have posted so far justifies and _address > allocation_ > > From HIP's perspective _they are just numbers_ as they are > identities, not locators. We have tried to address this in the draft. Succinctly: If we want legacy IPv6 applications to work without changes with protocols that use non-routable identifiers as upper layer identifiers, it would be desirable to have identifiers that a) are syntactically similar to current IPv6 addresses, but b) are understood to be semantically different. The draft attempts to address that by allocating a separate prefix for such identifiers, and at the same time also provide a secure means for associating any identifier in the given identifier space with other properties, in a fashion similar to HBA/CGA. Looking at these identifiers from a HBA/CGA point of view, what we propose are similar to HBAs/CGAs with two differences: - the hash length is much longer and therefore more secure (about 120 bits vs. about 56 bits) - they are non-routable If you feel that argumentation like the above should be in the document, I can expand the above and we can add it as an appendix to the draft. > (The IAB had a draft for a while about identities, and then the IAB > decided to drop it on the floor. Seems like it could sure come in > useful here in terms of outlining to some IAB folk the difference > between locators and identifiers!) I agree a document explaining the various types of identifiers would be useful. OTOH, my own IETF-related work queue is currently more-or- less full till March or so. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 15:11:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkfZ-0005Yj-RF; Mon, 14 Nov 2005 15:11:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkfU-0005RW-TE; Mon, 14 Nov 2005 15:11:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19819; Mon, 14 Nov 2005 15:10:35 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbkwW-0002DQ-I0; Mon, 14 Nov 2005 15:28:47 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAEKAcXt088851; Tue, 15 Nov 2005 07:10:40 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 07:10:30 +1100 To: Pekka Nikander From: Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 In-Reply-To: References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org But nothing in what you have said is inconsistent with the proposition that there is _no_ requirement to allocate IPv6 unicast address space for this form of use of 128 numbers. As you yourself point out "they are non-routeable" and theya re understood to be "semantically different". i.e. what you are going with the number in this context is really interesting, and a Good Thing in terms of furthering our understanding of the implications of the identifier / locator split. But I have yet to see a justification as to why these numbers should also entail a reservation in the IPv6 unicast number space. Indeed, I can think of some tolerable arguments as to why they should deliberately clash with unicast address values. regards, Geoff _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 17:56:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnFf-0006qk-9x; Mon, 14 Nov 2005 17:56:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnFc-0006q9-95; Mon, 14 Nov 2005 17:56:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08181; Mon, 14 Nov 2005 17:56:03 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbnWi-0002He-3u; Mon, 14 Nov 2005 18:14:17 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAEMtgXv093282; Tue, 15 Nov 2005 09:55:44 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115095113.02cd2788@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 09:53:40 +1100 To: "Manfredi, Albert E" From: Geoff Huston Subject: RE: [Int-area] Re: KHIs and SHA-256 In-Reply-To: <620321DC01C5E54BB37FF662E0C314B501F98008@xch-ne-05p.ne.nos .boeing.com> References: <620321DC01C5E54BB37FF662E0C314B501F98008@xch-ne-05p.ne.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Don't present such packets to the router. i.e. if you are working in an identifier space that has no locator overtones (I have already seen the assertion that these identifiers are "non-routeable"), then how exactly will these identity values show up in a packet on the wire and be presented to routers are a destination or source locator? Geoff At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: >Geoff, > >How would a router know not to forward such packets, in the event the >top 64 bits clash with a real IPv6 address? > >Bert > > > > -----Original Message----- > > From: Geoff Huston [mailto:gih@apnic.net] > > Sent: Monday, November 14, 2005 3:11 PM > > To: Pekka Nikander > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > But nothing in what you have said is inconsistent with the > > proposition that > > there is _no_ requirement to allocate IPv6 unicast address > > space for this > > form of use of 128 numbers. > > > > As you yourself point out "they are non-routeable" and theya > > re understood > > to be "semantically different". > > > > i.e. what you are going with the number in this context is really > > interesting, and a Good Thing in terms of furthering our > > understanding of > > the implications of the identifier / locator split. But I > > have yet to see a > > justification as to why these numbers should also entail a > > reservation in > > the IPv6 unicast number space. Indeed, I can think of some tolerable > > arguments as to why they should deliberately clash with > > unicast address values. > > > > regards, > > > > Geoff > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 18:42:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyL-00068x-75; Mon, 14 Nov 2005 18:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyI-000688-Fo; Mon, 14 Nov 2005 18:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11051; Mon, 14 Nov 2005 18:42:15 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EboFP-0003pY-QS; Mon, 14 Nov 2005 19:00:28 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAENgVXt094007; Tue, 15 Nov 2005 10:42:32 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115103856.02b4ced0@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 10:39:32 +1100 To: "Manfredi, Albert E" From: Geoff Huston Subject: RE: [Int-area] Re: KHIs and SHA-256 In-Reply-To: <620321DC01C5E54BB37FF662E0C314B501F98009@xch-ne-05p.ne.nos .boeing.com> References: <620321DC01C5E54BB37FF662E0C314B501F98009@xch-ne-05p.ne.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org I heard "non-routeable" with respect to these identifiers. Is this _really_ the case? Geoff At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: >I didn't assume that the identifier space with no locator overtones must >be non-intersecting with a routable network space. > >Are you saying that use of these identifiers must only apply to isolated >nets? > >Bert > > > > -----Original Message----- > > From: Geoff Huston [mailto:gih@apnic.net] > > Sent: Monday, November 14, 2005 5:54 PM > > To: Manfredi, Albert E > > Cc: Internet Area; ipv6@ietf.org > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > Don't present such packets to the router. > > > > i.e. if you are working in an identifier space that has no locator > > overtones (I have already seen the assertion that these > > identifiers are > > "non-routeable"), then how exactly will these identity values > > show up in a > > packet on the wire and be presented to routers are a > > destination or source > > locator? > > > > Geoff > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > >Geoff, > > > > > >How would a router know not to forward such packets, in the event the > > >top 64 bits clash with a real IPv6 address? > > > > > >Bert > > > > > > > > > > -----Original Message----- > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > To: Pekka Nikander > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > But nothing in what you have said is inconsistent with the > > > > proposition that > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > space for this > > > > form of use of 128 numbers. > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > re understood > > > > to be "semantically different". > > > > > > > > i.e. what you are going with the number in this context is really > > > > interesting, and a Good Thing in terms of furthering our > > > > understanding of > > > > the implications of the identifier / locator split. But I > > > > have yet to see a > > > > justification as to why these numbers should also entail a > > > > reservation in > > > > the IPv6 unicast number space. Indeed, I can think of > > some tolerable > > > > arguments as to why they should deliberately clash with > > > > unicast address values. > > > > > > > > regards, > > > > > > > > Geoff > > > > > > > > >-------------------------------------------------------------------- > > >IETF IPv6 working group mailing list > > >ipv6@ietf.org > > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > >-------------------------------------------------------------------- > > > > > > > > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 18:42:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyS-0006CH-Ix; Mon, 14 Nov 2005 18:42:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyM-00069Q-B4; Mon, 14 Nov 2005 18:42:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11054; Mon, 14 Nov 2005 18:42:19 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EboFT-0003pj-Kz; Mon, 14 Nov 2005 19:00:32 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAENgVXv094007; Tue, 15 Nov 2005 10:42:33 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115103954.02cd0388@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 10:42:33 +1100 To: "Durand, Alain" , From: Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C73C2F14C@PACDCEXCMB01.cable. comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C73C2F14C@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipv6@ietf.org, int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Alain, I'm not sure that 'leak" is really an issue here, nor do I see "risk of incompetence of implementation" as really being an adequate justification of an address allocation. Let me put it in a relatively stark fashion: If they are truly non-routeable identifiers then define an identity token space from the start and use it - don't attempt to steal locators! Geoff At 10:12 AM 15/11/2005, Durand, Alain wrote: >Geoff, > >The question is: can those identifier leak from an application and then be >used as locators? > >If there is a risk of leak, there is a need for a separate prefix. If we >are 100% sure there is no way that any application would ever leak, then I >would agree we do not need to use a dedicated prefix. > > - Alain. > > >-----Original Message----- >From: ipv6-bounces@ietf.org >To: Manfredi, Albert E >CC: ipv6@ietf.org; Internet Area >Sent: Mon Nov 14 17:53:40 2005 >Subject: RE: [Int-area] Re: KHIs and SHA-256 > >Don't present such packets to the router. > >i.e. if you are working in an identifier space that has no locator >overtones (I have already seen the assertion that these identifiers are >"non-routeable"), then how exactly will these identity values show up in a >packet on the wire and be presented to routers are a destination or source >locator? > > Geoff > > > > > > >At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > >Geoff, > > > >How would a router know not to forward such packets, in the event the > >top 64 bits clash with a real IPv6 address? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 3:11 PM > > > To: Pekka Nikander > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > But nothing in what you have said is inconsistent with the > > > proposition that > > > there is _no_ requirement to allocate IPv6 unicast address > > > space for this > > > form of use of 128 numbers. > > > > > > As you yourself point out "they are non-routeable" and theya > > > re understood > > > to be "semantically different". > > > > > > i.e. what you are going with the number in this context is really > > > interesting, and a Good Thing in terms of furthering our > > > understanding of > > > the implications of the identifier / locator split. But I > > > have yet to see a > > > justification as to why these numbers should also entail a > > > reservation in > > > the IPv6 unicast number space. Indeed, I can think of some tolerable > > > arguments as to why they should deliberately clash with > > > unicast address values. > > > > > > regards, > > > > > > Geoff > > > > > >-------------------------------------------------------------------- > >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 >-------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 19:05:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboJt-0004S6-7U; Mon, 14 Nov 2005 19:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboJp-0004Po-KF for int-area@megatron.ietf.org; Mon, 14 Nov 2005 19:05:03 -0500 Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12417 for ; Mon, 14 Nov 2005 19:04:20 -0500 (EST) Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 262724CAFA for ; Tue, 15 Nov 2005 09:04:16 +0900 (JST) Date: Tue, 15 Nov 2005 09:04:21 +0900 From: Thierry Ernst To: int-area@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 Message-Id: <20051115090421.3b35bbf6.ernst@sfc.wide.ad.jp> In-Reply-To: <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org I've heard about people who want to allocate IPv6 address to cars instead of registration plates (not to a CPU in embedded in a car), and other to national I-D cards ;-) I fear that many other folks who have a very vague understanding of what an IPv6 address is for gets even more confused that they currently are. The fact that a number is 128 bits long doesn't entail it to be called an IPv6 address when it's not routable. Thierry On Tue, 15 Nov 2005 07:10:30 +1100 Geoff Huston wrote: > But nothing in what you have said is inconsistent with the proposition > that there is _no_ requirement to allocate IPv6 unicast address space > for this form of use of 128 numbers. > > As you yourself point out "they are non-routeable" and theya re > understood to be "semantically different". > > i.e. what you are going with the number in this context is really > interesting, and a Good Thing in terms of furthering our understanding > of the implications of the identifier / locator split. But I have yet > to see a justification as to why these numbers should also entail a > reservation in the IPv6 unicast number space. Indeed, I can think of > some tolerable arguments as to why they should deliberately clash with > unicast address values. > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 14 19:16:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboUa-0008E7-U0; Mon, 14 Nov 2005 19:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboUW-0008Do-VM; Mon, 14 Nov 2005 19:16:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12879; Mon, 14 Nov 2005 19:15:33 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebolc-0004to-7U; Mon, 14 Nov 2005 19:33:47 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAF0F9Xt094518; Tue, 15 Nov 2005 11:15:09 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115111333.02c7bd88@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 11:14:40 +1100 To: "Christian Huitema" , "Manfredi, Albert E" From: Geoff Huston Subject: RE: [Int-area] Re: KHIs and SHA-256 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org At 11:02 AM 15/11/2005, Christian Huitema wrote: >IMHO, every identifier ends up being routed, at least in some context. Does your statement here specifically encompass the DNS? If not, then what is the difference between such DNS identifiers and the ones under consideration in this context? regards, Geoff >For example, there is a good case that on a disconnected ad hoc network, >it makes more sense to use the identifiers you have than to create some >new addresses. Indeed, if one is willing to have individual host entries >in a routing table, then one can use any identifier. > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >Geoff Huston >Sent: Monday, November 14, 2005 3:40 PM >To: Manfredi, Albert E >Cc: ipv6@ietf.org; Internet Area >Subject: RE: [Int-area] Re: KHIs and SHA-256 > >I heard "non-routeable" with respect to these identifiers. > >Is this _really_ the case? > > Geoff > > >At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: > >I didn't assume that the identifier space with no locator overtones >must > >be non-intersecting with a routable network space. > > > >Are you saying that use of these identifiers must only apply to >isolated > >nets? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 5:54 PM > > > To: Manfredi, Albert E > > > Cc: Internet Area; ipv6@ietf.org > > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > > > Don't present such packets to the router. > > > > > > i.e. if you are working in an identifier space that has no locator > > > overtones (I have already seen the assertion that these > > > identifiers are > > > "non-routeable"), then how exactly will these identity values > > > show up in a > > > packet on the wire and be presented to routers are a > > > destination or source > > > locator? > > > > > > Geoff > > > > > > > > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > > >Geoff, > > > > > > > >How would a router know not to forward such packets, in the event >the > > > >top 64 bits clash with a real IPv6 address? > > > > > > > >Bert > > > > > > > > > > > > > -----Original Message----- > > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > > To: Pekka Nikander > > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > > > But nothing in what you have said is inconsistent with the > > > > > proposition that > > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > > space for this > > > > > form of use of 128 numbers. > > > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > > re understood > > > > > to be "semantically different". > > > > > > > > > > i.e. what you are going with the number in this context is >really > > > > > interesting, and a Good Thing in terms of furthering our > > > > > understanding of > > > > > the implications of the identifier / locator split. But I > > > > > have yet to see a > > > > > justification as to why these numbers should also entail a > > > > > reservation in > > > > > the IPv6 unicast number space. Indeed, I can think of > > > some tolerable > > > > > arguments as to why they should deliberately clash with > > > > > unicast address values. > > > > > > > > > > regards, > > > > > > > > > > Geoff > > > > > > > > > > > > >-------------------------------------------------------------------- > > > >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 >-------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 03:47:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwTI-0006Cz-Jz; Tue, 15 Nov 2005 03:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwTF-0006Cj-Am; Tue, 15 Nov 2005 03:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10194; Tue, 15 Nov 2005 03:46:44 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbwkP-0004Jg-BQ; Tue, 15 Nov 2005 04:05:03 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BFECB212C3F; Tue, 15 Nov 2005 10:46:55 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 09:46:53 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Geoff, I fully agree with you that a new identifier name space should not be mixed with any existing locator space. In other words, from an ideal architectural point of view, the goals of having non-routable identifiers that have different semantics from IPv6 addresses definitely do not warrant allocation from the IPv6 address space. There we fully agree, and and that is exactly how I would like to see the architecture to be in the longer run: an identifier space fully separate from the locator space, the locator space consisting mainly of IPv6 addresses. (The IPv4 story is also there, but it is more messy; I'll skip it here for the sake of clarity.) But we need a transition strategy! Requiring a change that mandates that you 1) change your stack, 2) introduce a new piece of infrastructure, and 3) change your applications is a no-starter. Such changes won't happen, or if they do, it takes at least 10 years. Haven't we learned anything from the pain we are feeling with IPv6? Hence, we need a transition strategy that allows us to move from the current situation into full blown identifier / locator split along a path where each step is easy enough and brings benefits by itself. My current view is that we will be progressing along two (or perhaps three) parallel paths, the steps being roughly as follows: 1a. Implement SHIM6 - changes stack - does not change applications - implements identifier / locator split, but - keeps identifier and locator semantics and syntax identical - does not require any additional infrastructure - works only with IPv6 1b. Implement "invisible" HIP that uses IP addresses as identifiers - changes stack - does not change applications - implements identifier / locator split, but - keeps identifier and locator semantics and syntax identical - does not require any additional infrastructure - works with both IPv4 and IPv6 - is more heavyweight than SHIM6 2a. Implement KHIs on the top of SHIM6 - changes stack but minimally from 1a, perhaps not at all - does not change applications - continues identifier / locator split by - requires additional infrastructure to KHI->locator mapping - works only with IPv6 2b. Implement HIP with KHIs in the legacy API - does not change stack from 1b - does not change applications - continues identifier / locator split by - making a minimal difference in identifier and locator syntax and semantics - requires additional infrastructure to KHI->locator mapping - works with both IPv4 and IPv6 - is more heavyweight than SHIM6 3. Implement full HIP, with a new HIP-aware API - does not change stack from 2b - does change applications - continues identifier / locator split by - making identifiers and locators fully separate - does not work any additional infrastructure compared to 2 - works with both IPv4 and IPv6 - is more heavyweight than SHIM6 Note that "HIP" above does not necessarily mean HIP as currently defined, but something that combines host-layer mobility, multi- homing, and security in a HIP-like way. It may grow from the current HIP, it may grow from SHIM6, it may grow from IPsec+IKEv2+MOBIKE +BTNS, or it may grow from MIP+MONAMI6, or from some combination of those. Or we may end up having three or four different ways of implementing it. What is important here is the semantics; if we end up with multiple protocols to implement the semantics, well then we do. To summarise my idea of the transition path, we progress step-by-step: 1. Change the stack 2. Introduce KHIs and supporting infrastructure 3. Change the API and applications Trying to do any combination of the steps at once would decrease the chances of success proportionally. Trying to do all three at once is bound to fail. So, the one and only reason why KHIs need to be *temporarily* allocated from the IPv6 address space is to allow smooth transition without requiring any changes to existing applications. In theory we could live without such allocation, creating syntactically similar overlapping spaces, but that would not be prudent engineering. During the transition some identifiers are bound to leak to the locator space, as Alan pointed out. It is just prudent engineering to minimise the effects of such leaks, both in the implementation (within the stack) and in the operational environment (in live networks). Even if there was no implementation errors, some upper layer protocols would still send these identifiers to non-consenting hosts, causing indirect leaks. Finally, note that we have very carefully proposed to use KHIs as an *experiment* until 2009. By that time we will know much better if the transition strategy is working, and if it is, how long longer we will need the allocation. If the transition is not taking place at all, which is of course possible, the allocation will be defaulted back to IANA. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 03:51:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwXT-0006sW-Gf; Tue, 15 Nov 2005 03:51:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwXS-0006sI-6o; Tue, 15 Nov 2005 03:51:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10557; Tue, 15 Nov 2005 03:51:05 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebwoe-0004YR-LS; Tue, 15 Nov 2005 04:09:25 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 89235212C3F; Tue, 15 Nov 2005 10:51:28 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47D8BF28-7846-49F2-AC8C-A43FA234CF0A@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 09:51:26 +0100 To: Christian Huitema X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "Manfredi, Albert E" , ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Christian, > IMHO, every identifier ends up being routed, at least in some context. I think I fully agree with you, but IMHO we need to be very careful about the terminology here. For example, I can easily imagine an overlay network, running on the top of the current IP network, using DHTs to "route" flat identifiers. If we want to call that kind of "application-layer" forwarding routing, then I fully agree. > For example, there is a good case that on a disconnected ad hoc > network, > it makes more sense to use the identifiers you have than to create > some > new addresses. Indeed, if one is willing to have individual host > entries > in a routing table, then one can use any identifier. I concur. But as you well know, that does not scale. Once your ad hoc network grows to a size where clustering becomes a necessity, you can no longer use fixed flat identifiers for routing purposes. [Note that I am not saying that you need hierarchically organised addresses; more desirable would probably be dynamically assigned locators that encode clustering information in some better-than- hierarchically-assigned way.] --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 03:58:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbweI-0001Tl-QG; Tue, 15 Nov 2005 03:58:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbweG-0001Ta-W0; Tue, 15 Nov 2005 03:58:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11169; Tue, 15 Nov 2005 03:58:08 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbwvS-0004qi-Ae; Tue, 15 Nov 2005 04:16:27 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5A754212C3F; Tue, 15 Nov 2005 10:58:30 +0200 (EET) In-Reply-To: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 09:58:28 +0100 To: David Conrad X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org David, >> IMHO, every identifier ends up being routed, at least in some >> context. > > If they are routed, they are not identifiers. They are locators. > > An identifier simply names the object. It might enable > connectivity on a non-routed infrastructure, e.g., a local LAN, and > if you want to call this 'being routed', then your comment could be > considered accurate, but in a rather pointless sense. I think Christian's point here is that one man's identifiers are other man's locators. All depends on your point of view, or layer what you are looking at. However, as I noted in my previous message, while having some value, such usage of terms it is likely to cause confusion, requiring care with terminology. Ad hoc (and other sufficiently small) networks are a kind of a special case since you can mix identifiers and locators there, simplifying the architecture. I also happen to believe that this confounding of roles in current IP addresses is one of the reasons why the Internet has been so successful as it is. However, to me it is also clear that it is high time to move on, and to split these two roles. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 03:59:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwfA-0001lf-R3; Tue, 15 Nov 2005 03:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwf9-0001lP-RO for int-area@megatron.ietf.org; Tue, 15 Nov 2005 03:59:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11257 for ; Tue, 15 Nov 2005 03:59:03 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbwwL-0004sI-H5 for int-area@ietf.org; Tue, 15 Nov 2005 04:17:22 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A6D59212C3F; Tue, 15 Nov 2005 10:59:24 +0200 (EET) In-Reply-To: <20051115090421.3b35bbf6.ernst@sfc.wide.ad.jp> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> <20051115090421.3b35bbf6.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 09:59:22 +0100 To: Thierry Ernst X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Thierry, > The fact that a number is 128 bits long doesn't entail it to be called > an IPv6 address when it's not routable. While I agree with you, I think KHIs are a valuable means as a transition mechanism; see my other message on the list. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 04:04:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwk9-0003zt-Oe; Tue, 15 Nov 2005 04:04:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwk8-0003ye-2u; Tue, 15 Nov 2005 04:04:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11672; Tue, 15 Nov 2005 04:04:11 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebx1J-00055S-GW; Tue, 15 Nov 2005 04:22:31 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 199F1212C3F; Tue, 15 Nov 2005 11:04:33 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 10:04:31 +0100 To: Christian Huitema X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Christian, >> => the draft is supposed to address both issues. For the first one >> we can add more cautionary words if one believes there are not yet >> enough. For the second one we already merged two very different >> experiments into one request. > > Well, if that is what we want, then we can write a much simpler draft, > "reserving a prefix for non routable identifiers". It will have > essentially one or two paragraph of text, plus the usual ten pages of > boiler text. I would almost agree with you. However, as we do discuss in the draft, we also want to use a hash function to securely bind information into the identifier. Consequently, there is the tension of having as many bits as possible in the hash, and spending as few bits as possible in the prefix. Consequently, if we want to share the prefix with multiple experiments, we either a) need to define some bits to define which experiment is going on, or b) define a means of encoding this information in the hash We have chosen b), with the motivation of thereby getting a longer hash. No explicit bits needed to differentiate the experiments, resulting in a slightly longer hash. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 05:49:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbyN3-0008Qg-HV; Tue, 15 Nov 2005 05:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbyN2-0008Pa-J5 for int-area@megatron.ietf.org; Tue, 15 Nov 2005 05:49:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16815 for ; Tue, 15 Nov 2005 05:48:27 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbyeE-0008Dn-U3 for int-area@ietf.org; Tue, 15 Nov 2005 06:06:48 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1E5464C703; Tue, 15 Nov 2005 19:48:30 +0900 (JST) Date: Tue, 15 Nov 2005 19:48:35 +0900 From: Thierry Ernst To: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Message-Id: <20051115194835.6ac3d555.ernst@sfc.wide.ad.jp> In-Reply-To: References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> <20051115090421.3b35bbf6.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org > > The fact that a number is 128 bits long doesn't entail it to be > > called an IPv6 address when it's not routable. > > While I agree with you, I think KHIs are a valuable means as a > transition mechanism; see my other message on the list. May be, but let's be careful about the terminology. You and peolple on this list definitely know what an IPv6 address is but I can tell you that many people really don't, so whatever we do we must clarify the boundaries of the "IPv6 address" term. I don't know where this confusion started in people's mind, but it's here. The people who wants to use the IPv6 address as an identifier (they still call it an IP address even when to identify a person) are generally unaware of the locator/id split discussion, so I think it might be helpful to educate people about longer-term plans of the IETF. Thierry _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 12:08:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4Ht-0004rf-M6; Tue, 15 Nov 2005 12:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4Hs-0004rX-52 for int-area@megatron.ietf.org; Tue, 15 Nov 2005 12:08:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09470 for ; Tue, 15 Nov 2005 12:07:30 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec4Z7-0003NP-NJ for int-area@ietf.org; Tue, 15 Nov 2005 12:25:55 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAFH7XXt038272; Wed, 16 Nov 2005 04:07:35 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051116040505.02d1cdf8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 16 Nov 2005 04:07:28 +1100 To: Thierry Ernst , Pekka Nikander From: Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 In-Reply-To: <20051115194835.6ac3d555.ernst@sfc.wide.ad.jp> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> <20051115090421.3b35bbf6.ernst@sfc.wide.ad.jp> <20051115194835.6ac3d555.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org At 09:48 PM 15/11/2005, Thierry Ernst wrote: >The people who wants to use the IPv6 address as an >identifier (they still call it an IP address even when to identify a >person) are generally unaware of the locator/id split discussion, so I >think it might be helpful to educate people about longer-term plans of >the IETF. s/the longer term plans of the IETF/the aspirations of some folk as to the IETF's direction/ There is a critical distinction here, of course. Geoff _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 13:38:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5ho-0004W2-3T; Tue, 15 Nov 2005 13:38:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5hm-0004Vu-Sv; Tue, 15 Nov 2005 13:38:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16590; Tue, 15 Nov 2005 13:38:23 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5z3-0006pY-6h; Tue, 15 Nov 2005 13:56:46 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAFIb9Xu088323; Wed, 16 Nov 2005 05:38:41 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 16 Nov 2005 05:37:09 +1100 To: Pekka Nikander , David Conrad From: Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 In-Reply-To: <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Christian Huitema , Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org At 07:58 PM 15/11/2005, Pekka Nikander wrote: >David, > >>>IMHO, every identifier ends up being routed, at least in some >>>context. >> >>If they are routed, they are not identifiers. They are locators. >> >>An identifier simply names the object. It might enable >>connectivity on a non-routed infrastructure, e.g., a local LAN, and >>if you want to call this 'being routed', then your comment could be >>considered accurate, but in a rather pointless sense. > >I think Christian's point here is that one man's identifiers are >other man's locators. All depends on your point of view, or layer >what you are looking at. My apologies, but this is getting a little spaced out in terms of being able to understand where you are heading here. My point of view is, i thought, pretty simple. I am looking at routers that forward packets according to a precisely defined matching algorithm between the contents of the packet's destination address field and the forwarding table in the router. What we used to call "addresses". Where exactly are you looking? regards, Geoff _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 13:42:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5lM-0005Qi-FG; Tue, 15 Nov 2005 13:42:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5lJ-0005Q8-VK; Tue, 15 Nov 2005 13:42:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16808; Tue, 15 Nov 2005 13:42:02 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec62a-0006xQ-An; Tue, 15 Nov 2005 14:00:26 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAFIepXu088400; Wed, 16 Nov 2005 05:42:22 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 16 Nov 2005 05:40:51 +1100 To: Pekka Nikander , Christian Huitema From: Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 In-Reply-To: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org At 08:04 PM 15/11/2005, Pekka Nikander wrote: >Christian, > >>>=> the draft is supposed to address both issues. For the first one >>>we can add more cautionary words if one believes there are not yet >>>enough. For the second one we already merged two very different >>>experiments into one request. >> >>Well, if that is what we want, then we can write a much simpler draft, >>"reserving a prefix for non routable identifiers". It will have >>essentially one or two paragraph of text, plus the usual ten pages of >>boiler text. > Its a simple draft, but it still makes absolutely no sense to me to me in terms of relating to to an address allocation. If these token values are in fact "non routable identifiers" , which is what I read above, then you have no semantic intersection with the conventional address space and you can set up a "non-routeable identifier" register and allocate unique identifier tokens according to any distribution criteria that makes sense according to the intended use. Geoff _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 14:21:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6Mw-0002lR-3x; Tue, 15 Nov 2005 14:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6Ms-0002kU-2B; Tue, 15 Nov 2005 14:21:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19194; Tue, 15 Nov 2005 14:20:50 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec6e9-0008H9-0P; Tue, 15 Nov 2005 14:39:14 -0500 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.18972780; Tue, 15 Nov 2005 14:20:42 -0500 In-Reply-To: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 14:20:43 -0500 To: Geoff Huston X-Mailer: Apple Mail (2.623) X-esp: ESP<-11>=RBL:<0> RDNS:<0> SHA:<0> UHA:<0> SLS:<0> BAYES:<-11> SenderID:<0> URL Substring Dictionary (TRU8):<0> Spam Dictionary (TRU8):<0> APL-8-TRU-Words:<0> Porn Dictionary (TRU8):<0> NigeriaScam Dictionary (TRU8):<0> HTML Dictionary (TRU8):<0> APL-8-TRU-Substrings:<0> Embed HTML Dictionary (TRU8):<0> Obscenities Dictionary (TRU8):<0> URL Dictionary (TRU8):<0> CAN-SPAM Compliance Dictionary (TRU8):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Christian Huitema , Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800851834==" Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org --===============1800851834== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--843578763; protocol="application/pkcs7-signature" --Apple-Mail-4--843578763 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 15, 2005, at 13:40, Geoff Huston wrote: > At 08:04 PM 15/11/2005, Pekka Nikander wrote: >> Christian, >> >>>> => the draft is supposed to address both issues. For the first one >>>> we can add more cautionary words if one believes there are not yet >>>> enough. For the second one we already merged two very different >>>> experiments into one request. >>> >>> Well, if that is what we want, then we can write a much simpler >>> draft, >>> "reserving a prefix for non routable identifiers". It will have >>> essentially one or two paragraph of text, plus the usual ten pages of >>> boiler text. >> > > > Its a simple draft, but it still makes absolutely no sense to me to me > in terms of relating to to an address allocation. If these token > values are in fact "non routable identifiers" , which is what I read > above, then you have no semantic intersection with the conventional > address space and you can set up a "non-routeable identifier" register > and allocate unique identifier tokens according to any distribution > criteria that makes sense according to the intended use. Another benefit of a separate registry for IDs is the removal of the size concern (mentioned as a reason for the request of a /3). As completely separate from addresses, these identifiers could be even larger than 128 bits. And this would increase their strength as cryptographic entities. Regards, Brian --Apple-Mail-4--843578763 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE1MTkyMDQ0WjAjBgkqhkiG9w0B CQQxFgQUsA3RvSuKXoyLXl8EgESpZvxdJQwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAIvOWjFtBVfbuvYF7W8DDB9X8w755PPcbYiYv9+j6wpmmkHY21Jw6rG6/go+TGVrrqLpV 5s86MWCQr2LSqau0HVPCICbKwHlPfCubzPfuMvk0NAJaSxKAg5U7HCp+DEWNqimMr8M96bSpavo2 N5tlmtHGbIuFiIgcOMAaKjO+Mq6DtSKoXYrTY41Rxf6bS68ufbf6DIwuI1Rm0uHDVf0yiAhmhgdO jbFS1WKJQO3OqYqMChgZecbpnSQP7jPJajc2m5l3iJExYUNendyz3vGYORPQMp51U7MlcDGgXdgC wGWTF3zUUflQb5eDZMwRn4p6B9Zy8QJ8lC+pJlSBGv4V6QAAAAAAAA== --Apple-Mail-4--843578763-- --===============1800851834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============1800851834==-- From int-area-bounces@lists.ietf.org Tue Nov 15 15:47:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7i1-0001Ng-1l; Tue, 15 Nov 2005 15:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7hx-0001NF-DK; Tue, 15 Nov 2005 15:47:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140; Tue, 15 Nov 2005 15:46:40 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7zC-0002tv-L6; Tue, 15 Nov 2005 16:05:05 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 66986212C3F; Tue, 15 Nov 2005 22:46:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 21:46:51 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , ipv6@ietf.org, David Conrad X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Dear Geoff, > My apologies, but this is getting a little spaced out in terms of > being able to understand where you are heading here. > > [...] > > Where exactly are you looking? Sorry for trying to interpret Christian's intentions, thereby confusing the things. I merely tried to understand what Christian meant, nothing more. What I really have wanted to say so far was the transition plan message, http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 15:55:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7pX-0003eu-R3; Tue, 15 Nov 2005 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7pX-0003ec-9M; Tue, 15 Nov 2005 15:55:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25623; Tue, 15 Nov 2005 15:54:30 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec86p-00039D-WF; Tue, 15 Nov 2005 16:12:56 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B33D2212C3F; Tue, 15 Nov 2005 22:54:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 21:54:51 +0100 To: Geoff Huston , Brian Haberman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Dear Geoff and Brian, > Its a simple draft, but it still makes absolutely no sense to me to > me in terms of relating to to an address allocation. If these token > values are in fact "non routable identifiers" , which is what I > read above, then you have no semantic intersection with the > conventional address space and you can set up a "non-routeable > identifier" register and allocate unique identifier tokens > according to any distribution criteria that makes sense according > to the intended use. Geoff, to quote my longer message http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html, "I fully agree with you that a new identifier name space should not be mixed with any existing locator space." Hence, from what I called "an ideal architectural point of view", I agree with what you write above, with the difference that I don't see need for any registries. Statistical uniqueness seems to be enough. The difference is that I try to be practical here, and pave way to such fully fledged, non-routable identifiers, which in fact are much larger than 128 bits, like Brian pointed out: > Another benefit of a separate registry for IDs is the removal of > the size > concern (mentioned as a reason for the request of a /3). As > completely > separate from addresses, these identifiers could be even larger than > 128 bits. And this would increase their strength as cryptographic > entities. As I wrote, I can't see how we could convince the world from going from where we are now to a world that requires people to change their network stack, add a new piece of infrastructure, and to change applications at the same time. That won't happen, any more. Even a "killer application" that requires a stack change and a piece of new infrastructure would be highly unlikely to succeed. Hence, try to minimise the amount of change required at each step. Doesn't that transition strategy make any sense to you? What is wrong with it? If you are worried that once established such hook for an identifier space within the address space is likely to last for a long time, please say so. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 16:21:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec8FU-00065H-Sl; Tue, 15 Nov 2005 16:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec8FU-000656-33; Tue, 15 Nov 2005 16:21:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27182; Tue, 15 Nov 2005 16:21:19 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec8Wm-0003xF-42; Tue, 15 Nov 2005 16:39:45 -0500 Received: from [192.168.0.2] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <200511152121170110023rmke>; Tue, 15 Nov 2005 21:21:23 +0000 In-Reply-To: <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 13:21:12 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org > As I wrote, I can't see how we could convince the world from going > from where we are now to a world that requires people to change > their network stack, add a new piece of infrastructure, and to > change applications at the same time. That won't happen, any > more. Even a "killer application" that requires a stack change and > a piece of new infrastructure would be highly unlikely to succeed. > Hence, try to minimise the amount of change required at each step. If we follow that logic, how do we ever deploy any change? Any kind of locator/identifier semantics is necessarily a change, just because it is not the status quo. It will have impact somewhere in the stack and run into the brick wall of actual deployability. I submit, rather, that we have the ability to deploy change, but that we only have one shot and we'd best do it right. IPv6, while distributed, is not actually deployed in the sense of it being enabled and pervasive yet. If we, as a body, reached consensus on a change, it would be tractable to deploy new stacks. Obviously, it needs to be a worthwhile change. Tony _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 16:57:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec8oH-0000yi-Fc; Tue, 15 Nov 2005 16:57:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec8oE-0000w3-NE; Tue, 15 Nov 2005 16:57:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29257; Tue, 15 Nov 2005 16:57:13 -0500 (EST) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec95Q-0004zq-DH; Tue, 15 Nov 2005 17:15:40 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 15 Nov 2005 21:57:29 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Tue, 15 Nov 2005 11:57:48 +0000 Received: (private information removed) Received: from mail pickup service by NAEANRFKEB05.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Tue, 15 Nov 2005 16:56:31 -0500 Received: from NAWEPRLHEG03.nadsuswe.nads.navy.mil ([10.32.118.47]) by naweprlheb02.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 10:54:52 -1000 Received: from naweprlhfw02.nmci.navy.mil ([10.32.0.42]) by NAWEPRLHEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 10:54:51 -1000 Received: from [138.163.129.6] by naweprlhfw02.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.32.118.47]) with SMTP; Tue, 15 Nov 2005 20:54:51 +0000 Received: from mx2.spawar.navy.mil (128.49.251.7) by navyprlhio01.nmci.navy.mil with ESMTP; 15 Nov 2005 11:02:55 -1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx2.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id jAFKrhHc031795; Tue, 15 Nov 2005 12:53:43 -0800 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7i2-0001O5-In; Tue, 15 Nov 2005 15:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7hx-0001NF-DK; Tue, 15 Nov 2005 15:47:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140; Tue, 15 Nov 2005 15:46:40 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7zC-0002tv-L6; Tue, 15 Nov 2005 16:05:05 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 66986212C3F; Tue, 15 Nov 2005 22:46:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 21:46:51 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 3.3, BAYES_00 -2.60) Subject: Re: [Int-area] Re: KHIs and SHA-256 X-OriginalArrivalTime: 15 Nov 2005 20:54:51.0852 (UTC) FILETIME=[D2EFE0C0:01C5EA26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Dear Geoff, > My apologies, but this is getting a little spaced out in terms of > being able to understand where you are heading here. > > [...] > > Where exactly are you looking? Sorry for trying to interpret Christian's intentions, thereby confusing the things. I merely tried to understand what Christian meant, nothing more. What I really have wanted to say so far was the transition plan message, http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 17:01:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec8rN-0001Vy-0u; Tue, 15 Nov 2005 17:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec8rK-0001TR-Ix; Tue, 15 Nov 2005 17:00:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29388; Tue, 15 Nov 2005 17:00:25 -0500 (EST) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec98c-00054c-KZ; Tue, 15 Nov 2005 17:18:52 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 15 Nov 2005 22:00:56 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw11c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Tue, 15 Nov 2005 22:00:47 +0000 Received: (private information removed) Received: from mail pickup service by NAEANRFKEB05.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Tue, 15 Nov 2005 17:00:10 -0500 Received: from NAWEPRLHEG04.nadsuswe.nads.navy.mil ([10.32.118.48]) by naweprlheb02.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 09:25:36 -1000 Received: from naweprlhfw03.nmci.navy.mil ([10.32.0.43]) by NAWEPRLHEG04.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 09:25:36 -1000 Received: from [138.163.129.6] by naweprlhfw03.nmci.navy.mil via smtpd (for insidesmtp.navy.mil [10.32.118.48]) with SMTP; Tue, 15 Nov 2005 20:22:28 +0000 Received: from mx2.spawar.navy.mil (128.49.251.7) by navyprlhio01.nmci.navy.mil with ESMTP; 15 Nov 2005 09:34:24 -1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+o= Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx2.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id jAFJOdiT009449; Tue, 15 Nov 2005 11:24:39 -0800 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6Mv-0002kr-Uu; Tue, 15 Nov 2005 14:21:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6Ms-0002kU-2B; Tue, 15 Nov 2005 14:21:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19194; Tue, 15 Nov 2005 14:20:50 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec6e9-0008H9-0P; Tue, 15 Nov 2005 14:39:14 -0500 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.18972780; Tue, 15 Nov 2005 14:20:42 -0500 In-Reply-To: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Date: Tue, 15 Nov 2005 14:20:43 -0500 To: Geoff Huston X-Mailer: Apple Mail (2.623) X-esp: ESP<-11>=RBL:<0> RDNS:<0> SHA:<0> UHA:<0> SLS:<0> BAYES:<-11> SenderID:<0> URL Substring Dictionary (TRU8):<0> Spam Dictionary (TRU8):<0> APL-8-TRU-Words:<0> Porn Dictionary (TRU8):<0> NigeriaScam Dictionary (TRU8):<0> HTML Dictionary (TRU8):<0> APL-8-TRU-Substrings:<0> Embed HTML Dictionary (TRU8):<0> Obscenities Dictionary (TRU8):<0> URL Dictionary (TRU8):<0> CAN-SPAM Compliance Dictionary (TRU8):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Content-Type: multipart/mixed; boundary="===============0840698949==" X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 3.3, BAYES_00 -2.60) Subject: Re: [Int-area] Re: KHIs and SHA-256 X-OriginalArrivalTime: 15 Nov 2005 19:25:36.0529 (UTC) FILETIME=[5AEA7010:01C5EA1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Christian Huitema , Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org --===============0840698949== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--843578763; protocol="application/pkcs7-signature" --Apple-Mail-4--843578763 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 15, 2005, at 13:40, Geoff Huston wrote: > At 08:04 PM 15/11/2005, Pekka Nikander wrote: >> Christian, >> >>>> => the draft is supposed to address both issues. For the first one >>>> we can add more cautionary words if one believes there are not yet >>>> enough. For the second one we already merged two very different >>>> experiments into one request. >>> >>> Well, if that is what we want, then we can write a much simpler >>> draft, >>> "reserving a prefix for non routable identifiers". It will have >>> essentially one or two paragraph of text, plus the usual ten pages of >>> boiler text. >> > > > Its a simple draft, but it still makes absolutely no sense to me to me > in terms of relating to to an address allocation. If these token > values are in fact "non routable identifiers" , which is what I read > above, then you have no semantic intersection with the conventional > address space and you can set up a "non-routeable identifier" register > and allocate unique identifier tokens according to any distribution > criteria that makes sense according to the intended use. Another benefit of a separate registry for IDs is the removal of the size concern (mentioned as a reason for the request of a /3). As completely separate from addresses, these identifiers could be even larger than 128 bits. And this would increase their strength as cryptographic entities. Regards, Brian --Apple-Mail-4--843578763 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE1MTkyMDQ0WjAjBgkqhkiG9w0B CQQxFgQUsA3RvSuKXoyLXl8EgESpZvxdJQwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAIvOWjFtBVfbuvYF7W8DDB9X8w755PPcbYiYv9+j6wpmmkHY21Jw6rG6/go+TGVrrqLpV 5s86MWCQr2LSqau0HVPCICbKwHlPfCubzPfuMvk0NAJaSxKAg5U7HCp+DEWNqimMr8M96bSpavo2 N5tlmtHGbIuFiIgcOMAaKjO+Mq6DtSKoXYrTY41Rxf6bS68ufbf6DIwuI1Rm0uHDVf0yiAhmhgdO jbFS1WKJQO3OqYqMChgZecbpnSQP7jPJajc2m5l3iJExYUNendyz3vGYORPQMp51U7MlcDGgXdgC wGWTF3zUUflQb5eDZMwRn4p6B9Zy8QJ8lC+pJlSBGv4V6QAAAAAAAA== --Apple-Mail-4--843578763-- --===============0840698949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0840698949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============0840698949==-- From int-area-bounces@lists.ietf.org Tue Nov 15 18:24:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAAQ-0004V7-JW; Tue, 15 Nov 2005 18:24:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAAN-0004Tk-0B; Tue, 15 Nov 2005 18:24:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05084; Tue, 15 Nov 2005 18:24:09 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcARc-0007mR-NN; Tue, 15 Nov 2005 18:42:37 -0500 Received: from jurassic.eng.sun.com ([129.146.224.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jAFNOY3F023353; Tue, 15 Nov 2005 16:24:34 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAFNOXUc846873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Nov 2005 15:24:33 -0800 (PST) Message-ID: <437A643A.2070509@sun.com> Date: Tue, 15 Nov 2005 14:42:02 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka Nikander wrote: > > My current view is that we will be progressing along two (or perhaps > three) parallel paths, the steps being roughly as follows: > > 1a. Implement SHIM6 > - changes stack > - does not change applications > - implements identifier / locator split, but > - keeps identifier and locator semantics and syntax identical > - does not require any additional infrastructure > - works only with IPv6 > > 1b. Implement "invisible" HIP that uses IP addresses as identifiers > - changes stack > - does not change applications > - implements identifier / locator split, but > - keeps identifier and locator semantics and syntax identical > - does not require any additional infrastructure > - works with both IPv4 and IPv6 > - is more heavyweight than SHIM6 > > 2a. Implement KHIs on the top of SHIM6 > - changes stack but minimally from 1a, perhaps not at all > - does not change applications I don't understand the last point. A KHI couldn't be used in referrals unless we have a ubiquitous and scalable KHI->locator lookup system, and I don't think we know how to build such a thing (yet). > - continues identifier / locator split by > - requires additional infrastructure to KHI->locator mapping > - works only with IPv6 > > 2b. Implement HIP with KHIs in the legacy API > - does not change stack from 1b > - does not change applications > - continues identifier / locator split by > - making a minimal difference in identifier and locator syntax and > semantics > - requires additional infrastructure to KHI->locator mapping > - works with both IPv4 and IPv6 > - is more heavyweight than SHIM6 I think there is also a 2c to explore, which hasn't been talked about much. Instead of doing KHI, define Hierarchically allocated 128-bit identifiers (hereby named HAI). If we have those we can use existing scalable infrastructure for lookups (defining some new DNS RR, or perhaps just use PTR and AAAA). This would still be more heavyweight than SHIM6, since the lookup of the locators is needed before communication can start. But it would run on top shim6 for the locator agility part. Erik _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 18:31:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAHL-0006wp-Hp; Tue, 15 Nov 2005 18:31:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAHK-0006vt-1P; Tue, 15 Nov 2005 18:31:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06330; Tue, 15 Nov 2005 18:31:20 -0500 (EST) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcAYd-0008Gd-0B; Tue, 15 Nov 2005 18:49:48 -0500 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 15 Nov 2005 23:31:43 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Tue, 15 Nov 2005 23:31:34 +0000 Received: (private information removed) Received: from mail pickup service by NAEANRFKEB08.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Tue, 15 Nov 2005 18:31:12 -0500 Received: from naweprlheb02.nadsuswe.nads.navy.mil ([10.32.118.41]) by NAEANRFKEB30.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 15:58:04 -0500 Received: from NAWEPRLHEG04.nadsuswe.nads.navy.mil ([10.32.118.48]) by naweprlheb02.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 10:57:17 -1000 Received: from naweprlhfw04.nmci.navy.mil ([10.32.0.44]) by NAWEPRLHEG04.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 10:57:17 -1000 Received: from [138.163.129.6] by naweprlhfw04.nmci.navy.mil via smtpd (for insidesmtp.navy.mil [10.32.118.48]) with SMTP; Tue, 15 Nov 2005 21:55:04 +0000 Received: from megatron.ietf.org (132.151.6.71) by navyprlhio01.nmci.navy.mil with ESMTP; 15 Nov 2005 11:06:09 -1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7pb-0003g3-75; Tue, 15 Nov 2005 15:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7pX-0003ec-9M; Tue, 15 Nov 2005 15:55:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25623; Tue, 15 Nov 2005 15:54:30 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec86p-00039D-WF; Tue, 15 Nov 2005 16:12:56 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B33D2212C3F; Tue, 15 Nov 2005 22:54:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 21:54:51 +0100 To: Geoff Huston , Brian Haberman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 15 Nov 2005 20:57:17.0033 (UTC) FILETIME=[2978BD90:01C5EA27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Dear Geoff and Brian, > Its a simple draft, but it still makes absolutely no sense to me to > me in terms of relating to to an address allocation. If these token > values are in fact "non routable identifiers" , which is what I > read above, then you have no semantic intersection with the > conventional address space and you can set up a "non-routeable > identifier" register and allocate unique identifier tokens > according to any distribution criteria that makes sense according > to the intended use. Geoff, to quote my longer message http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html, "I fully agree with you that a new identifier name space should not be mixed with any existing locator space." Hence, from what I called "an ideal architectural point of view", I agree with what you write above, with the difference that I don't see need for any registries. Statistical uniqueness seems to be enough. The difference is that I try to be practical here, and pave way to such fully fledged, non-routable identifiers, which in fact are much larger than 128 bits, like Brian pointed out: > Another benefit of a separate registry for IDs is the removal of > the size > concern (mentioned as a reason for the request of a /3). As > completely > separate from addresses, these identifiers could be even larger than > 128 bits. And this would increase their strength as cryptographic > entities. As I wrote, I can't see how we could convince the world from going from where we are now to a world that requires people to change their network stack, add a new piece of infrastructure, and to change applications at the same time. That won't happen, any more. Even a "killer application" that requires a stack change and a piece of new infrastructure would be highly unlikely to succeed. Hence, try to minimise the amount of change required at each step. Doesn't that transition strategy make any sense to you? What is wrong with it? If you are worried that once established such hook for an identifier space within the address space is likely to last for a long time, please say so. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 19:45:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBQw-0005zH-1L; Tue, 15 Nov 2005 19:45:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBQu-0005yl-OC; Tue, 15 Nov 2005 19:45:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15358; Tue, 15 Nov 2005 19:45:17 -0500 (EST) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcBiC-0003nU-SU; Tue, 15 Nov 2005 20:03:46 -0500 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 16 Nov 2005 00:45:39 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw13c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 16 Nov 2005 00:45:30 +0000 Received: (private information removed) Received: from mail pickup service by NAEANRFKEB08.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Tue, 15 Nov 2005 19:44:42 -0500 Received: from NAEANRFKEG02.nadsusea.nads.navy.mil ([10.16.20.70]) by NAEANRFKEB30.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 15:54:46 -0500 Received: from naeanrfkfw12.nmci.navy.mil ([10.16.41.10]) by NAEANRFKEG02.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 15:54:01 -0500 Received: from naeanrfkms01.nadsusea.nads.navy.mil by naeanrfkfw12.nmci.navy.mil via smtpd (for insidesmtp.navy.mil [10.16.20.70]) with ESMTP; Tue, 15 Nov 2005 20:54:01 +0000 Received: from naeanrfkfw11c.nmci.navy.mil (naeanrfkfw11c.nmci.navy.mil [10.16.0.163]) by naeanrfkms01.nadsusea.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAFKdGe01596; Tue, 15 Nov 2005 20:39:16 GMT Received: from [138.162.5.21] by naeanrfkfw11c.nmci.navy.mil via smtpd (for [10.16.0.173]) with ESMTP; Tue, 15 Nov 2005 20:54:01 +0000 Received: from megatron.ietf.org (132.151.6.71) by navynrfkio01.nmci.navy.mil with ESMTP; 15 Nov 2005 15:54:39 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7i2-0001O5-In; Tue, 15 Nov 2005 15:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7hx-0001NF-DK; Tue, 15 Nov 2005 15:47:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140; Tue, 15 Nov 2005 15:46:40 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7zC-0002tv-L6; Tue, 15 Nov 2005 16:05:05 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 66986212C3F; Tue, 15 Nov 2005 22:46:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 21:46:51 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-OriginalArrivalTime: 15 Nov 2005 20:54:02.0271 (UTC) FILETIME=[B5626AF0:01C5EA26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Dear Geoff, > My apologies, but this is getting a little spaced out in terms of > being able to understand where you are heading here. > > [...] > > Where exactly are you looking? Sorry for trying to interpret Christian's intentions, thereby confusing the things. I merely tried to understand what Christian meant, nothing more. What I really have wanted to say so far was the transition plan message, http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Tue Nov 15 19:54:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBZE-0000KP-6O; Tue, 15 Nov 2005 19:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBZB-0000KH-Nb; Tue, 15 Nov 2005 19:54:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15858; Tue, 15 Nov 2005 19:53:53 -0500 (EST) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcBqV-00043F-Ar; Tue, 15 Nov 2005 20:12:20 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 16 Nov 2005 00:54:23 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw09c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 16 Nov 2005 00:54:14 +0000 Received: (private information removed) Received: from mail pickup service by NAEANRFKEB08.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Tue, 15 Nov 2005 19:54:11 -0500 Received: from NAEANRFKEG02.nadsusea.nads.navy.mil ([10.16.20.70]) by NAEANRFKEB30.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 15:54:46 -0500 Received: from naeanrfkfw12.nmci.navy.mil ([10.16.41.10]) by NAEANRFKEG02.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Nov 2005 15:54:01 -0500 Received: from naeanrfkms01.nadsusea.nads.navy.mil by naeanrfkfw12.nmci.navy.mil via smtpd (for insidesmtp.navy.mil [10.16.20.70]) with ESMTP; Tue, 15 Nov 2005 20:54:01 +0000 Received: from naeanrfkfw11c.nmci.navy.mil (naeanrfkfw11c.nmci.navy.mil [10.16.0.163]) by naeanrfkms01.nadsusea.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id jAFKdGe01596; Tue, 15 Nov 2005 20:39:16 GMT Received: from [138.162.5.21] by naeanrfkfw11c.nmci.navy.mil via smtpd (for [10.16.0.173]) with ESMTP; Tue, 15 Nov 2005 20:54:01 +0000 Received: from megatron.ietf.org (132.151.6.71) by navynrfkio01.nmci.navy.mil with ESMTP; 15 Nov 2005 15:54:39 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7i2-0001O5-In; Tue, 15 Nov 2005 15:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7hx-0001NF-DK; Tue, 15 Nov 2005 15:47:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140; Tue, 15 Nov 2005 15:46:40 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7zC-0002tv-L6; Tue, 15 Nov 2005 16:05:05 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 66986212C3F; Tue, 15 Nov 2005 22:46:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 21:46:51 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-OriginalArrivalTime: 15 Nov 2005 20:54:02.0271 (UTC) FILETIME=[B5626AF0:01C5EA26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Dear Geoff, > My apologies, but this is getting a little spaced out in terms of > being able to understand where you are heading here. > > [...] > > Where exactly are you looking? Sorry for trying to interpret Christian's intentions, thereby confusing the things. I merely tried to understand what Christian meant, nothing more. What I really have wanted to say so far was the transition plan message, http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 09:03:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNsT-0001HM-HM; Wed, 16 Nov 2005 09:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNsP-0001GA-3f; Wed, 16 Nov 2005 09:03:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27427; Wed, 16 Nov 2005 09:02:32 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcO9l-0000gb-Jt; Wed, 16 Nov 2005 09:21:07 -0500 Received: from [192.168.1.121] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42DE178C0463F145; Wed, 16 Nov 2005 15:02:45 +0100 From: Julien Laganier To: ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 User-Agent: KMail/1.8 References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <437A643A.2070509@sun.com> In-Reply-To: <437A643A.2070509@sun.com> MIME-Version: 1.0 Content-Disposition: inline Date: Wed, 16 Nov 2005 15:04:52 +0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200511161504.52318.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org On Tuesday 15 November 2005 23:42, Erik Nordmark wrote: > Pekka Nikander wrote: (...) > > 2a. Implement KHIs on the top of SHIM6 > > - changes stack but minimally from 1a, perhaps not at all > > - does not change applications > > I don't understand the last point. A KHI couldn't be used in > referrals unless we have a ubiquitous and scalable KHI->locator > lookup system, and I don't think we know how to build such a thing > (yet). Yes and no. We do not know yet how to build a scalable KHI->locator lookup system. But OTOH, a KHI can be used in FTP referrals, we had it working. Then, for the rest of applications using referrals that break with KHIs, one can argue that they probably break in presence of NATs too. But nobody's perfect ;) Perhaps it's acceptable for a _transition_ and _experimental_ tool. I used to run HIP on the laptop with which I am writing this message. It had vanilla IP and IPsec stacks plus a HIP userland daemon, and still I was able to use both HIP and IP at the same time. That was possible because we could make the distinction between an IPv6 address (starting with binary 00 or 11) and a HIT (starting with binary 10 or 01.) When this distinction was lost I was not any longer able to use the _vanilla_ IPsec SPD to specify that packets send from any HIT to any HIT should be encrypted and integrity protected by ESP (hence causing HIP exchange). Yes that was hacky and overloaded, but again it was just working (as a transition and experimental tool.) > > - continues identifier / locator split by > > - requires additional infrastructure to KHI->locator mapping > > - works only with IPv6 > > > > 2b. Implement HIP with KHIs in the legacy API > > - does not change stack from 1b > > - does not change applications > > - continues identifier / locator split by > > - making a minimal difference in identifier and locator > > syntax and semantics > > - requires additional infrastructure to KHI->locator mapping > > - works with both IPv4 and IPv6 > > - is more heavyweight than SHIM6 > > I think there is also a 2c to explore, which hasn't been talked > about much. Instead of doing KHI, define Hierarchically allocated > 128-bit identifiers (hereby named HAI). If we have those we can use > existing scalable infrastructure for lookups (defining some new DNS > RR, or perhaps just use PTR and AAAA). > This would still be more heavyweight than SHIM6, since the lookup > of the locators is needed before communication can start. > But it would run on top shim6 for the locator agility part. The 2c you are referring to used to exist as 'Type 2' HITs (64 bits hierarchical prefix for lookup + 64 bits of public key hash). They were removed lately by the working group because the HIT diversity was problematic and there was no consensus to keep them alive. --julien -- julien _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 09:15:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO41-00063G-H5; Wed, 16 Nov 2005 09:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO3x-0005zd-RS; Wed, 16 Nov 2005 09:15:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28745; Wed, 16 Nov 2005 09:14:29 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOLO-0001JQ-Q6; Wed, 16 Nov 2005 09:33:04 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAGEEY516371; Wed, 16 Nov 2005 15:14:34 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAGEEYgR051446; Wed, 16 Nov 2005 15:14:34 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Julien Laganier Subject: Re: [Int-area] Re: KHIs and SHA-256 In-reply-to: Your message of Wed, 16 Nov 2005 15:04:52 +0100. <200511161504.52318.julien.IETF@laposte.net> Date: Wed, 16 Nov 2005 15:14:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Please note KHIs have other usages than HIP... Regards Francis.Dupont@enst-bretagne.fr PS: one of the strong points of the KHI drafts is it should cover more than one usage (if possible all usages) for crypto generated identifiers which look like addresses (so called "not routable addresses") for the API. _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 09:28:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH8-00010X-Gl; Wed, 16 Nov 2005 09:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH5-0000yY-0A; Wed, 16 Nov 2005 09:28:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00063; Wed, 16 Nov 2005 09:28:01 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOYO-0001s9-FT; Wed, 16 Nov 2005 09:46:36 -0500 Received: from [192.168.10.148] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 433BC54A02DEAAE0; Wed, 16 Nov 2005 15:27:23 +0100 From: Julien Laganier To: Francis Dupont Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Wed, 16 Nov 2005 15:30:02 +0100 User-Agent: KMail/1.8 References: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> In-Reply-To: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511161530.02491.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org On Wednesday 16 November 2005 15:14, Francis Dupont wrote: > Please note KHIs have other usages than HIP... Off course! That was just an usefulness example of having identifiers allocated out of the locator space as a transition tool: it makes possible to use at the same time identifiers and locators in an unmodified protocol layer (IPsec, TCP/UDP and APIs in my case). --julien _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 11:40:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQKi-0007q1-Gd; Wed, 16 Nov 2005 11:40:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQKh-0007ps-6l; Wed, 16 Nov 2005 11:40:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08661; Wed, 16 Nov 2005 11:39:53 -0500 (EST) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQc9-0007y7-3N; Wed, 16 Nov 2005 11:58:30 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 16 Nov 2005 16:40:19 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw09c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 16 Nov 2005 16:40:10 +0000 Received: (private information removed) Received: from mail pickup service by NAEANRFKEB05.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Wed, 16 Nov 2005 11:39:09 -0500 Received: from naweprlheb01.nadsuswe.nads.navy.mil ([10.32.118.40]) by NAEANRFKEB30.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Nov 2005 09:56:54 -0500 Received: from NAWEPRLHEG04.nadsuswe.nads.navy.mil ([10.32.118.48]) by naweprlheb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Nov 2005 04:31:42 -1000 Received: from naweprlhfw03.nmci.navy.mil ([10.32.0.43]) by NAWEPRLHEG04.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Nov 2005 04:31:43 -1000 Received: from [138.163.129.6] by naweprlhfw03.nmci.navy.mil via smtpd (for insidesmtp.navy.mil [10.32.118.48]) with SMTP; Wed, 16 Nov 2005 15:28:40 +0000 Received: from megatron.ietf.org (132.151.6.71) by navyprlhio01.nmci.navy.mil with ESMTP; 16 Nov 2005 04:41:00 -1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH8-0000zp-D4; Wed, 16 Nov 2005 09:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH5-0000yY-0A; Wed, 16 Nov 2005 09:28:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00063; Wed, 16 Nov 2005 09:28:01 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOYO-0001s9-FT; Wed, 16 Nov 2005 09:46:36 -0500 Received: from [192.168.10.148] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 433BC54A02DEAAE0; Wed, 16 Nov 2005 15:27:23 +0100 From: Julien Laganier To: Francis Dupont Date: Wed, 16 Nov 2005 15:30:02 +0100 User-Agent: KMail/1.8 References: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> In-Reply-To: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511161530.02491.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 16 Nov 2005 14:31:43.0252 (UTC) FILETIME=[7713A540:01C5EABA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org On Wednesday 16 November 2005 15:14, Francis Dupont wrote: > Please note KHIs have other usages than HIP... Off course! That was just an usefulness example of having identifiers allocated out of the locator space as a transition tool: it makes possible to use at the same time identifiers and locators in an unmodified protocol layer (IPsec, TCP/UDP and APIs in my case). --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 11:41:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQLi-0007vA-4N; Wed, 16 Nov 2005 11:41:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQLg-0007uy-JB; Wed, 16 Nov 2005 11:41:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08735; Wed, 16 Nov 2005 11:40:55 -0500 (EST) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQd4-000802-Qu; Wed, 16 Nov 2005 11:59:32 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 16 Nov 2005 16:41:22 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw09c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 16 Nov 2005 16:41:13 +0000 Received: (private information removed) Received: from mail pickup service by NAEANRFKEB05.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Wed, 16 Nov 2005 11:40:14 -0500 Received: from naweprlheb01.nadsuswe.nads.navy.mil ([10.32.118.40]) by NAEANRFKEB30.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Nov 2005 09:56:38 -0500 Received: from NAWEPRLHEG03.nadsuswe.nads.navy.mil ([10.32.118.47]) by naweprlheb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Nov 2005 04:32:33 -1000 Received: from naweprlhfw01.nmci.navy.mil ([10.32.0.41]) by NAWEPRLHEG03.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Nov 2005 04:32:33 -1000 Received: from [138.163.129.8] by naweprlhfw01.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.32.118.47]) with SMTP; Wed, 16 Nov 2005 15:29:02 +0000 Received: from mx2.spawar.navy.mil (128.49.251.7) by navyprlhio02.nmci.navy.mil with ESMTP; 16 Nov 2005 04:31:28 -1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx2.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id jAGEVHqU027558; Wed, 16 Nov 2005 06:31:18 -0800 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH8-0000zp-D4; Wed, 16 Nov 2005 09:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH5-0000yY-0A; Wed, 16 Nov 2005 09:28:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00063; Wed, 16 Nov 2005 09:28:01 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOYO-0001s9-FT; Wed, 16 Nov 2005 09:46:36 -0500 Received: from [192.168.10.148] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 433BC54A02DEAAE0; Wed, 16 Nov 2005 15:27:23 +0100 From: Julien Laganier To: Francis Dupont Date: Wed, 16 Nov 2005 15:30:02 +0100 User-Agent: KMail/1.8 References: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> In-Reply-To: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511161530.02491.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.878, required 3.3, BAYES_00 -2.60, SARE_FREE_WEBM_LAPOSTE 0.72) X-OriginalArrivalTime: 16 Nov 2005 14:32:33.0740 (UTC) FILETIME=[952B80C0:01C5EABA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org On Wednesday 16 November 2005 15:14, Francis Dupont wrote: > Please note KHIs have other usages than HIP... Off course! That was just an usefulness example of having identifiers allocated out of the locator space as a transition tool: it makes possible to use at the same time identifiers and locators in an unmodified protocol layer (IPsec, TCP/UDP and APIs in my case). --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 14:40:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcT8i-0002sN-TS; Wed, 16 Nov 2005 14:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcT8i-0002sI-2h for int-area@megatron.ietf.org; Wed, 16 Nov 2005 14:40:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19499 for ; Wed, 16 Nov 2005 14:39:41 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTQC-0005wg-0W for int-area@ietf.org; Wed, 16 Nov 2005 14:58:21 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 657A389863; Wed, 16 Nov 2005 21:40:05 +0200 (EET) Message-ID: <437B8AA3.8010107@piuha.net> Date: Wed, 16 Nov 2005 21:38:11 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman Subject: Re: [Int-area] Re: KHIs and SHA-256 References: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Brian Haberman wrote: > My understanding is that these are not routable addresses. That is, > they won't appear in routing protocol exchanges or routing tables. > If that is the case, then we are talking about the allocation of > something > different than IPv6 addresses. Well, "not appear in routing table" != "is not an address". Link local addresses, for instance, do not appear in routing protocols or tables but we still consider them IPv6 addresses. Anyway, the point is moot because these folks ARE requesting an allocation from the IPv6 address space, no matter what we call the values. Also, it would appear to me that application-layer referrals would probably cause some of these numbers to leak outside host processing and onto packets during the experiment. --Jari _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 14:45:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTDZ-00044c-SC; Wed, 16 Nov 2005 14:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTDY-00044X-4e for int-area@megatron.ietf.org; Wed, 16 Nov 2005 14:45:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19797 for ; Wed, 16 Nov 2005 14:44:41 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTV2-000683-0F for int-area@ietf.org; Wed, 16 Nov 2005 15:03:21 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C5AED89863; Wed, 16 Nov 2005 21:45:04 +0200 (EET) Message-ID: <437B8BCE.7010806@piuha.net> Date: Wed, 16 Nov 2005 21:43:10 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka Nikander wrote: > But we need a transition strategy! FWIW, I agree with the above. --Jari _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 17:31:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVoL-0000Ea-Nm; Wed, 16 Nov 2005 17:31:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVoH-00006O-Pw; Wed, 16 Nov 2005 17:31:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04278; Wed, 16 Nov 2005 17:30:48 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcW5l-0005Ck-1C; Wed, 16 Nov 2005 17:49:28 -0500 Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jAGMVEdK004142; Wed, 16 Nov 2005 14:31:14 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAGMVDdS019164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2005 14:31:14 -0800 (PST) Message-ID: <437BB32D.1070400@sun.com> Date: Wed, 16 Nov 2005 14:31:09 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> In-Reply-To: <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka Nikander wrote: > Geoff, to quote my longer message > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html, > "I fully agree with you that a new identifier name space should not be > mixed with any existing locator space." Hence, from what I called "an > ideal architectural point of view", I agree with what you write above, > with the difference that I don't see need for any registries. > Statistical uniqueness seems to be enough. I think it would be wise to reserve from space for identifiers in the 128-bit IPv6 space, whether they are statistically unique or whether they have internal hierarchy. The KHI draft seems to assume that we would only ever need 128 identifiers that have no internal hierarchy, which seems short-sighted as best, given how little we know about the feasibility of doing lookups in flat very large spaces. One thing I didn't understand from the KHI draft is how we can remove the use of these identifiers if they are successful. If folks use them (meaning that they appear in the appropriate places in the DNS, and that stacks know what is an identifier vs. a locator based on the prefix), how would they disappear from use? Is the assumption that the applications would switch to some other API which explicitly passes HIs or HITs? I don't see much benefits to move the applications to use the existing APIs (e.g., connect()) with a KHI, to some other API which passes a 128-bit HIT without a KHI prefix. So I must be missing something. Erik _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Nov 16 17:48:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcW4X-00051I-43; Wed, 16 Nov 2005 17:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcW4V-000511-2R; Wed, 16 Nov 2005 17:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05089; Wed, 16 Nov 2005 17:47:28 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcWLv-0005jW-8r; Wed, 16 Nov 2005 18:06:08 -0500 Message-ID: <00d101c5eaff$c175cc90$396015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Erik Nordmark" , "Pekka Nikander" References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net><5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <437BB32D.1070400@sun.com> Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Wed, 16 Nov 2005 14:47:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org I agree. I think any allocation should be considered experimental, particularly since there is a possibility that the identifiers might become longer in the future. However, it is also possible that 128 bit identifiers might become standard practice. At this point, we don't really know. jak ----- Original Message ----- From: "Erik Nordmark" To: "Pekka Nikander" Cc: "Christian Huitema" ; "Internet Area" ; Sent: Wednesday, November 16, 2005 2:31 PM Subject: Re: [Int-area] Re: KHIs and SHA-256 > Pekka Nikander wrote: > >> Geoff, to quote my longer message >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html, >> "I fully agree with you that a new identifier name space should not be >> mixed with any existing locator space." Hence, from what I called "an >> ideal architectural point of view", I agree with what you write above, >> with the difference that I don't see need for any registries. >> Statistical uniqueness seems to be enough. > > I think it would be wise to reserve from space for identifiers in the > 128-bit IPv6 space, whether they are statistically unique or whether they > have internal hierarchy. > The KHI draft seems to assume that we would only ever need 128 identifiers > that have no internal hierarchy, which seems short-sighted as best, given > how little we know about the feasibility of doing lookups in flat very > large spaces. > > > One thing I didn't understand from the KHI draft is how we can remove the > use of these identifiers if they are successful. > If folks use them (meaning that they appear in the appropriate places in > the DNS, and that stacks know what is an identifier vs. a locator based on > the prefix), how would they disappear from use? > Is the assumption that the applications would switch to some other API > which explicitly passes HIs or HITs? > I don't see much benefits to move the applications to use the existing > APIs (e.g., connect()) with a KHI, to some other API which passes a > 128-bit HIT without a KHI prefix. > So I must be missing something. > > Erik > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 09:31:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcknJ-0002ZW-7z; Thu, 17 Nov 2005 09:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcknI-0002ZM-35; Thu, 17 Nov 2005 09:31:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27073; Thu, 17 Nov 2005 09:30:44 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecl4v-0003zq-IR; Thu, 17 Nov 2005 09:49:35 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 75A97212C3F; Thu, 17 Nov 2005 16:31:09 +0200 (EET) In-Reply-To: <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Thu, 17 Nov 2005 15:31:07 +0100 To: Tony Li , Erik Nordmark X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Tony and Erik, >> As I wrote, I can't see how we could convince the world from going >> from where we are now to a world that requires people to change >> their network stack, add a new piece of infrastructure, and to >> change applications at the same time. That won't happen, any >> more. Even a "killer application" that requires a stack change >> and a piece of new infrastructure would be highly unlikely to >> succeed. Hence, try to minimise the amount of change required at >> each step. > > > If we follow that logic, how do we ever deploy any change? Any > kind of locator/identifier semantics is necessarily a change, just > because it is not the status quo. It will have impact somewhere in > the stack and run into the brick wall of actual deployability. > > I submit, rather, that we have the ability to deploy change, but > that we only have one shot and we'd best do it right. IPv6, while > distributed, is not actually deployed in the sense of it being > enabled and pervasive yet. If we, as a body, reached consensus on > a change, it would be tractable to deploy new stacks. Obviously, > it needs to be a worthwhile change. I would find it very nice if we could change the IP layer, install infrastructure, and change the applications in one shot. I just don't believe that we any more can do it -- we almost failed with IPv6, and IMHO would have failed without the _severe_ address scarcity outside of NA and EU. People are replacing their computer and operating systems all the time. Hence, a change to the stack *can* be fairly generally implemented in 5-7 years, which is the time of most hosts get replaced or at least undergo a software update. Given a new stack is there, people *may* start to use a piece of new infrastructure. Getting a new piece of DNS-like infra out there is relatively easy. What is hard is to get people to generally use it and to provide to running the infrastructure by sharing part of the operational load. I wasn't there when DNS was initially deployed, but as far as I have understood, it wasn't exactly painless. If there is new functionality in the stack and new piece of infrastructure, it *may* be possible to provide sufficient incentives for upgrading the applications. I would imagine that security might be such a feature in the long run. > One thing I didn't understand from the KHI draft is how we can > remove the use of these identifiers if they are successful. If > folks use them (meaning that they appear in the appropriate places > in the DNS, and that stacks know what is an identifier vs. a > locator based on the prefix), how would they disappear from use? > Is the assumption that the applications would switch to some other > API which explicitly passes HIs or HITs? Yes, that is what I hope to eventually happen. > I don't see much benefits to move the applications to use the > existing APIs (e.g., connect()) with a KHI, to some other API which > passes a 128-bit HIT without a KHI prefix. > So I must be missing something. I don't see much incentive for for doing a KHI -> pure HIT transition, but I could imagine some incentive for KHI -> HI transition, where HI can assumedly be much longer and even variable size than a KHI or HIT. But I do agree with you that we are missing some thinking here, i.e., we are missing a convincing set of incentives. Maybe we should go and try to create them artificially, by reducing the KHI hash size so that they will become insecure sooner that with the current design, and by not allowing the experiment to be continued, say, beyond 2015 even with IETF consensus. _Sort_ of similar to what we did with 6bone, making it very clear from the beginning that people have to eventually move forward. If the currently secure hash size is about 96 bits, 120 bits can be expected to become insecure in about 24 years.... Maybe that is too much; OTOH, given the recent advances in breaking SHA-1, we should have *some* marginal.... --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 09:40:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckwO-0005mE-PJ; Thu, 17 Nov 2005 09:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckwM-0005ja-Ti; Thu, 17 Nov 2005 09:40:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27788; Thu, 17 Nov 2005 09:40:07 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EclE0-0004Nh-Jv; Thu, 17 Nov 2005 09:58:58 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3B4CD212C3F; Thu, 17 Nov 2005 16:40:32 +0200 (EET) In-Reply-To: <437A643A.2070509@sun.com> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> <437A643A.2070509@sun.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Thu, 17 Nov 2005 15:40:31 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Erik, > I don't understand the last point. A KHI couldn't be used in > referrals unless we have a ubiquitous and scalable KHI->locator > lookup system, and I don't think we know how to build such a thing > (yet). I think we know, at least for some value of "know". We can use DHTs. What we don't apparently know are how to secure them against freeloading in the case of multi-operator DHTs and how fast/slow they will be in widespread use. But there are experiments and lots of research going on in those areas. http://www.opendht.org/ http://www.cs.cornell.edu/people/egs/beehive/codons.php Some of the existing HIP implementations already support HIT->IP address lookups from OpenDHT. > I think there is also a 2c to explore, which hasn't been talked > about much. > Instead of doing KHI, define Hierarchically allocated 128-bit > identifiers (hereby named HAI). If we have those we can use > existing scalable infrastructure for lookups (defining some new DNS > RR, or perhaps just use PTR and AAAA). > This would still be more heavyweight than SHIM6, since the lookup > of the locators is needed before communication can start. > But it would run on top shim6 for the locator agility part. Yes, that would be an interesting area to explore. But that would also create yet another hierarchy, and in my current "slash all hierarchies from the Internet" attitude I would rather not go there. :-) More seriously, I would rather see the Internet to develop towards fewer contention points (like the current DNS and IP address assignments) rather than towards more of them. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 17:54:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcseG-00083N-5V; Thu, 17 Nov 2005 17:54:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcseD-00082A-GC; Thu, 17 Nov 2005 17:54:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02182; Thu, 17 Nov 2005 17:53:55 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecsvs-0006Ea-7W; Thu, 17 Nov 2005 18:12:48 -0500 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jAHMsLD7020692; Thu, 17 Nov 2005 15:54:21 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAHMsKtA015552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2005 14:54:21 -0800 (PST) Message-ID: <437D0A16.1070700@sun.com> Date: Thu, 17 Nov 2005 14:54:14 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> <437A643A.2070509@sun.com> <02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> In-Reply-To: <02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka Nikander wrote: > I think we know, at least for some value of "know". We can use DHTs. > What we don't apparently know are how to secure them against > freeloading in the case of multi-operator DHTs and how fast/slow they > will be in widespread use. But there are experiments and lots of > research going on in those areas. Yes, but IMHO the hardest problem is scale. If we want the architecture to move towards a flat identifier space (whether fixed length or crammed into 128 bits) we need a way to do lookups that scale to when every host on the planet has such an identifier. RFC 1726 talks about at least 10^12 hosts. I don't know of any DHT research that is pushing towards such scale, but I'd would be interested in finding out if there is. > More seriously, I would rather see the Internet to develop towards > fewer contention points (like the current DNS and IP address > assignments) rather than towards more of them. But if we don't have any indication that we can scale flat spaces, then we need hierarchy. Hierarchy doesn't necessarily imply administratively controlled root of the name/number space; one can in theory construct a hierarchy based on multiple hashes that give statistical uniqueness at the top level. I think it would be wise to expand the KHI draft to allow for hierarchical identifiers, so that we have flexibility as we learn more about a 128-bit identifier space. For instance, allocating binary 0001/4 for IP identifiers, and then 000100/6 for flat Keyed Hash Identifiers might make sense, leaving room for other work in 0001/4. Erik _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 18:13:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcswS-0000p1-0E; Thu, 17 Nov 2005 18:13:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcswQ-0000ot-6i; Thu, 17 Nov 2005 18:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03406; Thu, 17 Nov 2005 18:12:43 -0500 (EST) Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EctE8-0006su-Dn; Thu, 17 Nov 2005 18:31:37 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Ecsvv-0000A6-00; Thu, 17 Nov 2005 18:12:47 -0500 From: Tim Shepard To: Erik Nordmark Subject: Re: [Int-area] Re: KHIs and SHA-256 In-reply-to: Your message of Thu, 17 Nov 2005 14:54:14 -0800. <437D0A16.1070700@sun.com> Date: Thu, 17 Nov 2005 18:12:47 -0500 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org > If we want the architecture to move towards a flat identifier space > (whether fixed length or crammed into 128 bits) we need a way to do > lookups that scale to when every host on the planet has such an > identifier. We do not necessarily need such "a way to do lookups" that scales. Indeed for some architectures for how these identifiers might be used, we would need such a mechanism. But other architectures might have other ways of doing things (like referals might carry something other than just one of these flat identifiers). I think it might be helpful to understand all the different ways referals might be passed, and then in each case, what lookupability properties the various names, and locators would need to have. -Tim Shepard shep@alum.mit.edu _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 18:22:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ect5X-0005mi-Jn; Thu, 17 Nov 2005 18:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ect5U-0005m9-LD; Thu, 17 Nov 2005 18:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03871; Thu, 17 Nov 2005 18:22:06 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EctNB-0007Ag-UV; Thu, 17 Nov 2005 18:41:00 -0500 Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jAHNMZD7010619; Thu, 17 Nov 2005 16:22:35 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAHNMYF0026335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2005 15:22:34 -0800 (PST) Message-ID: <437D10B4.2020602@sun.com> Date: Thu, 17 Nov 2005 15:22:28 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Int-area] Re: KHIs and SHA-256 References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka Nikander wrote: > I would find it very nice if we could change the IP layer, install > infrastructure, and change the applications in one shot. I just don't > believe that we any more can do it -- we almost failed with IPv6, and > IMHO would have failed without the _severe_ address scarcity outside of > NA and EU. Pekka, I hope you didn't interpret my comments that we need to replace everything at once. For instance, I don't think we should change the applications and the APIs at all - the applications should continue to function using getaddrinfo() + connect()/sendto() using 128 bit names for their peers. [We might want to introduce an optional connect_by_name() call to make it easier/faster to handle the multiplicity of locators.) Thus I see a need to evolve the stack (towards shim6 and hip like capabilities) as well as a way to handle ID->locator lookup when/if we have identifiers that are not also usable as locators. But I don't see a need to change anything else. > If there is new functionality in the stack and new piece of > infrastructure, it *may* be possible to provide sufficient incentives > for upgrading the applications. I would imagine that security might > be such a feature in the long run. But security of what? See below. > But I do agree with you that we are missing some thinking here, i.e., > we are missing a convincing set of incentives. Maybe we should go and > try to create them artificially, by reducing the KHI hash size so that > they will become insecure sooner that with the current design, and by > not allowing the experiment to be continued, say, beyond 2015 even with > IETF consensus. _Sort_ of similar to what we did with 6bone, making it > very clear from the beginning that people have to eventually move forward. But for the 6bone there was a place to move to which had the same characteristics hence the cost to move is relatively low; the needed forcing function doesn't have to be that strong. If the goal is to cause all the applications on the planet to be rewritten there is no forcing function strong enough; you'd need significant benefits to even get a small fraction of the applications to be ported to something new. > If the currently secure hash size is about 96 bits, 120 bits can be > expected to become insecure in about 24 years.... Maybe that is too > much; OTOH, given the recent advances in breaking SHA-1, we should have > *some* marginal.... My assumption is that anybody that cares about security of the content being communicated applies some security to that content; IPsec, TLS, whatever. And if folks care about www.example.com really mapping to an IP address and the routes pointing in that direction, we need DNSsec and some routing security. AFAICT we need this even if HIP is used (even though HIP helps to get IPsec end-to-end). I think this implies that the length of the hash is only there to protect against redirection attacks for off-path attackers; on path attackers e.g. somebody that can cut the wire or control the software/firmware in a router or switch can always redirect packets. Thus in terms of the mobility and multihoming control protocol, the attacks for the important traffic would be limited to redirecting the encrypted payload to somewhere else. If the e2e encryption is good enough, this would be the same as redirecting it to a black hole i.e., a, possibly selective, DoS attack on some traffic. How much effort would an attacker like to spend on such an attack? And what are the different ways the attack could be performed? The attacker could look for input that hashes to the same identifier, which will be feasible in the future, but will require significant compute cycles. The attacker could also gain physical access to the path (break in, bribe somebody with access, etc). Comparing the cost/effort of a protocol attack vs. a physical attack is like comparing apples and oranges. But I still think we need to consider this so that we don't overengineer the protection against redirection attacks. An attacker can use bribes to get physical access - take $10,000 to $100,000 as numbers out of a hat. An attacker can attack the hash function for a single host - how many CPU hours are required to do this today? With what hash length would this be less than 10,000 to 100,000 CPU hours today? I realize that HIP is a bit harder to analyze in this was than shim6, because HIP also uses the HIT/HI to secure the payload with ESP. But the above arguments would apply to shim6 and "ESP-less HIP". Erik _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 19:13:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctsT-0001Mx-NK; Thu, 17 Nov 2005 19:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctsS-0001Mk-2J; Thu, 17 Nov 2005 19:13:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06850; Thu, 17 Nov 2005 19:12:41 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcuA8-0000TW-HY; Thu, 17 Nov 2005 19:31:36 -0500 Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jAI0D43F021462; Thu, 17 Nov 2005 17:13:04 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAI0D3Ct011750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2005 16:13:03 -0800 (PST) Message-ID: <437D1C89.50505@sun.com> Date: Thu, 17 Nov 2005 16:12:57 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard Subject: Re: [Int-area] Re: KHIs and SHA-256 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Tim Shepard wrote: > We do not necessarily need such "a way to do lookups" that scales. > > Indeed for some architectures for how these identifiers might be used, > we would need such a mechanism. > > But other architectures might have other ways of doing things (like > referals might carry something other than just one of these flat > identifiers). > > I think it might be helpful to understand all the different ways > referals might be passed, and then in each case, what lookupability > properties the various names, and locators would need to have. Yes, one can contemplate such an approach. What is hard to determine is how large set of the applications would need to be modified to handle this. (Referrals, callbacks, and long-lived application associations are all problematic - see draft-ietf-shim6-app-refer.) Note that it isn't just the applications; in some cases the application *protocols* would need to be modified (to be able to carry the new "referral handle" in addition to a 128-bit IPv6 referral handle). This means that the application needs to negotiate with the peer to determine whether or not it supports the new type of referral handles (whatever they might be). These are all reasons why I'm personally trying to figure out what we can do under the existing 128-bit API where the 128-bit quantities passed over that API can be used as referral handles. Erik 'don't break the app' Nordmark _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 23:25:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecxoe-0006er-Go; Thu, 17 Nov 2005 23:25:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecxoc-0006ej-0f; Thu, 17 Nov 2005 23:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19766; Thu, 17 Nov 2005 23:24:55 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecy6G-0007zE-NV; Thu, 17 Nov 2005 23:43:52 -0500 Message-ID: <023d01c5ebf8$12eac640$396015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Erik Nordmark" , "Pekka Nikander" References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr><6.2.0.14.2.20051112224120.02e47008@localhost><6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net><437A643A.2070509@sun.com><02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> <437D0A16.1070700@sun.com> Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Thu, 17 Nov 2005 20:25:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org The other alternative to hierarchy for scalability is separate addressing domains. But let's not go there. jak ----- Original Message ----- From: "Erik Nordmark" To: "Pekka Nikander" Cc: "Internet Area" ; Sent: Thursday, November 17, 2005 2:54 PM Subject: Re: [Int-area] Re: KHIs and SHA-256 > Pekka Nikander wrote: > >> I think we know, at least for some value of "know". We can use DHTs. >> What we don't apparently know are how to secure them against freeloading >> in the case of multi-operator DHTs and how fast/slow they will be in >> widespread use. But there are experiments and lots of research going on >> in those areas. > > Yes, but IMHO the hardest problem is scale. > > If we want the architecture to move towards a flat identifier space > (whether fixed length or crammed into 128 bits) we need a way to do > lookups that scale to when every host on the planet has such an > identifier. RFC 1726 talks about at least 10^12 hosts. > I don't know of any DHT research that is pushing towards such scale, but > I'd would be interested in finding out if there is. > >> More seriously, I would rather see the Internet to develop towards fewer >> contention points (like the current DNS and IP address assignments) >> rather than towards more of them. > > But if we don't have any indication that we can scale flat spaces, then we > need hierarchy. Hierarchy doesn't necessarily imply administratively > controlled root of the name/number space; one can in theory construct a > hierarchy based on multiple hashes that give statistical uniqueness at the > top level. > > I think it would be wise to expand the KHI draft to allow for hierarchical > identifiers, so that we have flexibility as we learn more about a 128-bit > identifier space. > > For instance, allocating binary 0001/4 for IP identifiers, and then > 000100/6 for flat Keyed Hash Identifiers might make sense, leaving room > for other work in 0001/4. > > Erik > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Nov 17 23:27:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecxqh-0007Ue-3B; Thu, 17 Nov 2005 23:27:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecxqf-0007Tq-Hp; Thu, 17 Nov 2005 23:27:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19890; Thu, 17 Nov 2005 23:27:07 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecy8P-00083n-Bf; Thu, 17 Nov 2005 23:46:03 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A909C89863; Fri, 18 Nov 2005 06:27:16 +0200 (EET) Message-ID: <437D57AE.2030601@piuha.net> Date: Fri, 18 Nov 2005 06:25:18 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [Int-area] Re: KHIs and SHA-256 References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> <437D10B4.2020602@sun.com> In-Reply-To: <437D10B4.2020602@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Erik Nordmark wrote: >> If there is new functionality in the stack and new piece of >> infrastructure, it *may* be possible to provide sufficient >> incentives for upgrading the applications. I would imagine that >> security might be such a feature in the long run. > > > But security of what? See below. > > ... > My assumption is that anybody that cares about security of the content > being communicated applies some security to that content; IPsec, TLS, > whatever. And if folks care about www.example.com really mapping to an > IP address and the routes pointing in that direction, we need DNSsec > and some routing security. > > AFAICT we need this even if HIP is used (even though HIP helps to get > IPsec end-to-end). Yes. One of the reasons why this is needed is that the specific issues in applications typically need specific security support that is easier to provide in application or transport layer. Secondly, historically, we have struggled in providing meaningful and universal information from IP layer security mechanisms to applications. I do not see any reason why the world would change in this regard, particularly given the already developed and deployed mechanisms. > I think this implies that the length of the hash is only there to > protect against redirection attacks for off-path attackers; on path > attackers e.g. somebody that can cut the wire or control the > software/firmware in a router or switch can always redirect packets. Agreed. --Jari _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Nov 18 12:59:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAWX-00039o-7m; Fri, 18 Nov 2005 12:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAWV-00034n-M0 for int-area@megatron.ietf.org; Fri, 18 Nov 2005 12:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01923 for ; Fri, 18 Nov 2005 12:59:08 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdAoO-0007nx-DS for int-area@ietf.org; Fri, 18 Nov 2005 13:18:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 892FC212C45; Fri, 18 Nov 2005 19:59:22 +0200 (EET) In-Reply-To: <437D57AE.2030601@piuha.net> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> <437D10B4.2020602@sun.com> <437D57AE.2030601@piuha.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <975447ED-A0C8-4EC7-BFA4-FF56AE0AC3CE@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [Int-area] Security of identifiers (was Re: KHIs and SHA-256) Date: Fri, 18 Nov 2005 13:02:05 +0100 To: Jari Arkko , Erik Nordmark X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.7 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org [Dropping IPv6 as this has nothing to do with IPv6 any more] Jari and Erik, >>> If there is new functionality in the stack and new piece of >>> infrastructure, it *may* be possible to provide sufficient >>> incentives for upgrading the applications. I would imagine >>> that security might be such a feature in the long run. >> >> >> But security of what? See below. >> >> My assumption is that anybody that cares about security of the >> content being communicated applies some security to that content; >> IPsec, TLS, whatever. And if folks care about www.example.com >> really mapping to an IP address and the routes pointing in that >> direction, we need DNSsec and some routing security. >> >> AFAICT we need this even if HIP is used (even though HIP helps to >> get IPsec end-to-end). > > Yes. One of the reasons why this is needed is that > the specific issues in applications typically need specific > security support that is easier to provide in application > or transport layer. Secondly, historically, we have struggled > in providing meaningful and universal information from IP > layer security mechanisms to applications. I do not > see any reason why the world would change in this regard, > particularly given the already developed and deployed > mechanisms. I think you may be missing one aspect of CGAs/KHIs/HITs/whatever, which is implicit channel bindings and the ability to continue identifiers for security purposes. We have a long tradition of using IP addresses for security. In the original architecture IP addresses used to act as very good approximations of host or end-point identifiers, making it natural to use IP addresses to make a difference between more and less trusted hosts. The same design was adopted into IPsec, and is still used in many firewalls, configuration files, proxies, etc. Using something which looks and tastes like an IP addresses to an application (while not being it in the network) is able to build upon that tradition. When we add strong security semantics to this, basically providing a much higher level of assurance that any packet sent to that identifier is not delivered to anyone else but the identified recipient, we just strengthen the semantics that we used to have and that many applications and practises still assume. CGAs and KHIs can be seen as handles to public keys. While CGAs are currently used only in SeND, both CGAs and KHIs could be used to provide, implicitly, the strong security semantics. That is what HIP does with its HITs. If you send a packet to a HIT, the underlying HIP layer will create an IPsec ESP association with the named host (authenticated with the public key bound to the HIT), and delivers the packet ESP protected, if at all. Hence, the security I was referring to is the strength of the cryptographic binding from the IPv6-look-alike identifier to the public key. If the hash is short, the binding is weak. Even the currently-proposed 120-bits hash will become vulnerable during the lifetime of many of us, and using 128 bits doesn't help much there. Consequently, in the long run, I think there is some incentive to move using full public keys (or something similar) as host or end- point identifiers. --Pekka _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Nov 18 13:56:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBPG-0006UT-Fq; Fri, 18 Nov 2005 13:56:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBPE-0006UO-Gh for int-area@megatron.ietf.org; Fri, 18 Nov 2005 13:56:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04351 for ; Fri, 18 Nov 2005 13:55:41 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBh5-0000be-NS for int-area@ietf.org; Fri, 18 Nov 2005 14:14:46 -0500 Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jAIIuA4u002037; Fri, 18 Nov 2005 10:56:10 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAIIu9Nv028089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Nov 2005 10:56:10 -0800 (PST) Message-ID: <437E23C2.6030303@sun.com> Date: Fri, 18 Nov 2005 10:56:02 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Int-area] Security of identifiers (was Re: KHIs and SHA-256) References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> <437D10B4.2020602@sun.com> <437D57AE.2030601@piuha.net> <975447ED-A0C8-4EC7-BFA4-FF56AE0AC3CE@nomadiclab.com> In-Reply-To: <975447ED-A0C8-4EC7-BFA4-FF56AE0AC3CE@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka Nikander wrote: > [Dropping IPv6 as this has nothing to do with IPv6 any more] > > Jari and Erik, >>> My assumption is that anybody that cares about security of the >>> content being communicated applies some security to that content; >>> IPsec, TLS, whatever. And if folks care about www.example.com really >>> mapping to an IP address and the routes pointing in that direction, >>> we need DNSsec and some routing security. >>> >>> AFAICT we need this even if HIP is used (even though HIP helps to >>> get IPsec end-to-end). >> >> >> Yes. One of the reasons why this is needed is that >> the specific issues in applications typically need specific >> security support that is easier to provide in application >> or transport layer. Secondly, historically, we have struggled >> in providing meaningful and universal information from IP >> layer security mechanisms to applications. I do not >> see any reason why the world would change in this regard, >> particularly given the already developed and deployed >> mechanisms. > > > I think you may be missing one aspect of CGAs/KHIs/HITs/whatever, which > is implicit channel bindings and the ability to continue identifiers > for security purposes. I suspect neither Jari or I have missed that. I guess I don't understand what you are responding to; this particular part was about the need for DNSsec and routing security. I don't think you are arguing that we don't need those if we have HIP, thus I don't understand what point you are making relative to what I and Jari said. > Hence, the security I was referring to is the strength of the > cryptographic binding from the IPv6-look-alike identifier to the public > key. If the hash is short, the binding is weak. Even the > currently-proposed 120-bits hash will become vulnerable during the > lifetime of many of us, and using 128 bits doesn't help much there. > Consequently, in the long run, I think there is some incentive to move > using full public keys (or something similar) as host or end- point > identifiers. The impact of the above was what I explicitly disclaimed in my email yesterday. But to understand the security of the system, one would presumably need to start with a FQDN and take into account DNSsec and routing security, and see what the different threats are. For instance, how would HIP (with its binding by having the hash in the HIT) compare with getting both AAAA and IPSECKEY RRs from (the secured) DNS? I certainly don't understand all the tradeoffs to make such a comparison. Erik _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Nov 18 15:14:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdCd4-0003KY-9r; Fri, 18 Nov 2005 15:14:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdCd3-0003KS-2I for int-area@megatron.ietf.org; Fri, 18 Nov 2005 15:14:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07582 for ; Fri, 18 Nov 2005 15:14:01 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdCuw-0002Ks-5A for int-area@ietf.org; Fri, 18 Nov 2005 15:33:07 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EC94E212C40; Fri, 18 Nov 2005 22:14:16 +0200 (EET) In-Reply-To: <437E23C2.6030303@sun.com> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> <437D10B4.2020602@sun.com> <437D57AE.2030601@piuha.net> <975447ED-A0C8-4EC7-BFA4-FF56AE0AC3CE@nomadiclab.com> <437E23C2.6030303@sun.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Int-area] Security of identifiers (was Re: KHIs and SHA-256) Date: Fri, 18 Nov 2005 21:14:13 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Erik, I must have been reading your and Jari's yesterday's messages carelessly. My apologies. I'll try to find time to read them again. I agree that as we are in general dependent on DNS names, we need to worry about DNS security, too. Where KHIs and the like may help there is the possibility of using leap-of-faith kind of methods, in a way similar to what SSH does today. --Pekka I wrote: >> I think you may be missing one aspect of CGAs/KHIs/HITs/whatever, >> which is implicit channel bindings and the ability to continue >> identifiers for security purposes. You wrote: > I suspect neither Jari or I have missed that. > I guess I don't understand what you are responding to; this > particular part was about the need for DNSsec and routing security. _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88W-00086i-5l; Mon, 21 Nov 2005 04:38:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESluv-0006Rk-7f for int-area@megatron.ietf.org; Thu, 20 Oct 2005 21:41:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16054 for ; Thu, 20 Oct 2005 21:41:46 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESm6y-0002tn-3C for int-area@ietf.org; Thu, 20 Oct 2005 21:54:24 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Oct 2005 18:41:38 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 18:41:38 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 18:41:37 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 18:41:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt Date: Thu, 20 Oct 2005 18:41:31 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC11404B2C6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt Thread-Index: AcW6R4HcSSObDm6RQwCaFP5WIFferQbmMjDw From: "Dave Thaler" To: "James Kempf" , , "Thomas Narten" , "Bob Hinden" X-OriginalArrivalTime: 21 Oct 2005 01:41:37.0850 (UTC) FILETIME=[93C551A0:01C5D5E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:53 -0500 Cc: X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org > -----Original Message----- > From: int-area-bounces@lists.ietf.org [mailto:int-area- > bounces@lists.ietf.org] On Behalf Of James Kempf > Sent: Thursday, September 15, 2005 3:47 PM > To: int-area@ietf.org; Thomas Narten > Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt >=20 > Thomas, >=20 > I share your concerns about this draft. At a minimum, pulling the IPv4 > specification out of the draft seems appropriate. This was Issue #10 on the old NDProxy Issues list: http://www.icir.org/dthaler/NDProxyOldIssues.htm#Issue%2010 The resolution of that issue was previously: > [IETF 59 minutes]: > Options include:=20 > 1) leave IPv4 in with caveat;=20 > 2) remove all mention of IPv4; and=20 > 3) put IPv4 support in an appendix. =20 > After some discussion, the chairs polled the room. Approximately 8 people=20 > felt we should remove IPv4 support, and approximately 4 people felt we > should keep it in. Thomas Narten observed that it was disappointing that=20 > there were so few opinions in the room. The chairs noted that since the > working group didn't have a strong opinion, we should defer to the author. > > [DT comment]: > So far the authors have chosen the path of least author work (i.e.,=20 > no change). Since there seems to still be vocal support for removing IPv4, and no vocal support for keeping it, and the poll at IETF59 also had more in favor of removing, I have removed the IPv4 portions from draft-04 as suggested. > My particular concern, though, is with the lack of support for security. > When SEND was finalized, we had some very vague ideas about how to do > proxy > ND security which didn't seem ready for standardization. Now, after about > a > year and a half of discussion in IRTF/MOBOPTS, I think we are beginning to > have some firmer ideas about how SEND could be extended to proxy ND. If > the > WG decides that it would like to continue working on this and decides that > security is important, we could bring some of the IRTF/MOBOPTS work into > IETF. Jari Arkko submitted proposed replacement text for the security=20 considerations section which summarizes the above, and the text=20 has been incorporated. > jak >=20 > ----- Original Message ----- > From: "Thomas Narten" > To: > Sent: Thursday, September 15, 2005 8:44 AM > Subject: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt >=20 > > I'm sending this to the int-area because the concerns I have are > > broader than the just the ipv6 WG. This document is really about > > bridging/proxy arp in general, and it does not restrict itself to > > IPv6; it also covers IPv4. > > > > I've read this document a couple of times (it is on the IESG's plate > > to review), but have general concerns. I wonder if others in the > > community share my concern. > > > > The bottom line is that I think the IPv6 portion of document/protocol > > is both under-specified and too broad in scope and I worry that there > > are a lot of potential gotchas lurking. I also worry that it will > > break some of our standards track protocols. And if it gets widely > > implemented, we'll have to deal with the resultant mess. We have > > plenty of experience in IPv4 with proxy arp, and some of it has been > > unpleasant. > > > > I have the following meta concerns: > > > > 1) I do not believe the material on IPv4 ARP proxy should be > > included. It is not in-scope for the IPv6 WG to be developing it, and > > any document on proxy ARP in IPv4 really requires review from the > > broader community. AFAIK, that review has not taken place. > > > > Recommendation: remove the IPv4 material and place in a separate > > document Removed as recommended. > > 2) This document breaks SEND (but does not say this clearly). I have > > doubts that we should be publishing documents that break our standards > > track protocols (especially ones that we believe are important). Or at > > the very least, if it is published, very strong wording is needed to > > point out that it is incompatable with SEND, e.g., an IESG note. Updated security considerations section with text from Jari Arkko. > > 3) this document may have implications for DHC. In particular, > > document says: > > > > One limitation of this rule is that if the authentication > > protocol for DHCPv4 described in [DHCPAUTH] is used, only > > clients that set the BROADCAST flag themselves will be able to > > use DHCPv4 through the proxy. > > > > If this document breaks some forms of DHC, that needs to be noted up > > front and more visibly. I also think more discussion would be > > appropriat here, to be sure we fully understand the issue here. > > Again, I'm also not sure we should be promoting documents that cause > > problems for existing standards track protocols. Removed IPv4 material, so this point goes away. > > 4) The history of this document is troubling, and I believe it does > > not have strong support from the WG. Rather, I'd characterize this as > > an effort that has gotten this far mostly because the vast majority of > > the WG has tuned out and no longer is following the work. > > > > The history of this effort (though I may be biased) is that the IPv6 > > WG desired a simple proxy mechanism for the following case. Suppose > > one has an access router connecting to an upstream ISP, and that link > > is assigned a prefix (say X). It would be nice if the access router > > could readvertise that prefix (say for a home network), acting as a > > simple bridge. That way the end site wouldn't need a separate prefix > > (say if the ISP as stingy and didn't want to give it out). I had > > always assumed this configuration was a simple star topology with the > > access router at the center. Indeed, the current IPv6 charter says: > > > >> - Develop Proxy Neighbor Discovery solution for prefix delegation > >> and publish. This enables a simple site border router to > >> re-advertise downstream a prefix it hears on its upstream link. > > > > The WG had such an item in its charter for a long time (years), but > > from what I can tell, there was limited interest in terms of actually > > doing the work, so it languished. What "the WG" finally produced was > > the above document. But it's scope is quite a lot broader than what > > the charter called for. And, I think its fair to say that the work > > reflects a small number of contributers (with good intentions) but > > apathy and almost no help from the rest of the WG (e.g., the last WG > > LC received no comments). So, this document is going through the > > process by default, rather than being a strongly reviewed piece of > > work. > > > > Margaret (as AD) raised a similar point about the scope of this work > > in the WG a few months back. For details, review the discussion > > during the WG last call in May: (sorry, I can't find a a good URL to > > point to -- sigh). There was hardly strong support for the document, > > and in fact, the reviews were negative and the document was taken off > > standards track and put on experimental in response to that thread. > > > > In summary, I believe there are good reasons why the document in its > > current form should not be published with an IETF blessing. > > > > Some possible options: > > > > 1) Drop the work completely. This may not be as silly as it seems. A > > basic premise of this work is that its somehow not possible (or too > > hard) to get a proper prefix delegated from an ISP. However, there > > is little evidence that this will be a real issue in IPv6. Current > > RIR address allocation polcies and existing ISP practices is to > > give out chunks of address space (rather than /64s), or a single > > address. > > > > 2) Move all the IPv4 material to a separate document (this should be > > done in any case if work on this continues). Also, the IPv4 > > material would need serious review from the IPv4 community. Removed IPv4 material from this document. > > 3) Pull out all the more general bridging stuff for the IPv6 case and > > just solve the narrow problem described earlier, namely a single > > router acting as a star/hub for proxying. > > > > 4) Add an IESG note with a warning that this has potential issues and > > the IETF doesn't recommend widespread adoption/use. (Indeed, the > > current applicability statement is really weak and gives > > insufficient guidance in terms of where this technology can safely > > be used) > > > > And what I'd _really_ like to see, more than anything else, is strong > > support from the community both for scope of this document and the > > details of what are contained in the document. In the absence of that, > > if the document is published, I'd like to see a strong note adequately > > characterizing the issues above. > > > > Thomas Proposed updated draft is at http://www.icir.org/dthaler/draft-ietf-ipv6-ndproxy-04.txt Thanks, -Dave _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88W-00087B-Hf; Mon, 21 Nov 2005 04:38:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebi4Y-0000EM-5H; Mon, 14 Nov 2005 12:24:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06641; Mon, 14 Nov 2005 12:24:19 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbiLb-000476-FW; Mon, 14 Nov 2005 12:42:28 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 09:24:39 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 09:24:38 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 09:24:38 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 09:24:38 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 09:24:37 -0800 Message-ID: Thread-Topic: [Int-area] Re: KHIs and SHA-256 thread-index: AcXpDY/vZQxwFypyQ5aPvyEEVkbcfwAMQmNA From: "Christian Huitema" To: "Francis Dupont" , "Bob Hinden" X-OriginalArrivalTime: 14 Nov 2005 17:24:38.0255 (UTC) FILETIME=[4A3BF7F0:01C5E940] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:53 -0500 Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org > =3D> the draft is supposed to address both issues. For the first one > we can add more cautionary words if one believes there are not yet > enough. For the second one we already merged two very different > experiments into one request. Well, if that is what we want, then we can write a much simpler draft, "reserving a prefix for non routable identifiers". It will have essentially one or two paragraph of text, plus the usual ten pages of boiler text: "Various experiments require encoding a non routable identifier in the format of an IPv6 address. To avoid confusion with regular use of IPv6 address, we instruct the IANA to reserve the prefix xxxx:yyyy::/n for that purpose. (TBD IANA: specific value of xxxx:yyyy; TBD working group: specific value of n). The addresses will have the following format: +---------------+---------------------------------------------+ | n bits prefix | (128-n) bits identifier | +---------------+---------------------------------------------+ Different experiments are expected to construct the identifier in different ways. Each experiment is expect to specify how the identifier is constructed and verified, e.g. using experiment-specific cryptographic procedures. Each experiment MUST specify an identifier verification method that will validate properly allocated identifiers according to this experiment, and invalidate incompatible identifiers allocated according to different experiments." -- Christian Huitema _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88W-00087e-RH; Mon, 21 Nov 2005 04:38:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblUK-0002fn-8b; Mon, 14 Nov 2005 16:03:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25465; Mon, 14 Nov 2005 16:03:08 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbllN-0004yc-Co; Mon, 14 Nov 2005 16:21:20 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA10177; Mon, 14 Nov 2005 13:03:13 -0800 (PST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAEL3DH18491; Mon, 14 Nov 2005 13:03:13 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.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: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 16:03:12 -0500 Message-ID: <620321DC01C5E54BB37FF662E0C314B501F98008@xch-ne-05p.ne.nos.boeing.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXpWPrsC8MUxgd3RAqWvYYVqjQEbwABUMrw From: "Manfredi, Albert E" To: "Geoff Huston" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:54 -0500 Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Geoff, How would a router know not to forward such packets, in the event the top 64 bits clash with a real IPv6 address? Bert > -----Original Message----- > From: Geoff Huston [mailto:gih@apnic.net]=20 > Sent: Monday, November 14, 2005 3:11 PM > To: Pekka Nikander > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > Subject: Re: [Int-area] Re: KHIs and SHA-256=20 >=20 > But nothing in what you have said is inconsistent with the=20 > proposition that=20 > there is _no_ requirement to allocate IPv6 unicast address=20 > space for this=20 > form of use of 128 numbers. >=20 > As you yourself point out "they are non-routeable" and theya=20 > re understood=20 > to be "semantically different". >=20 > i.e. what you are going with the number in this context is really=20 > interesting, and a Good Thing in terms of furthering our=20 > understanding of=20 > the implications of the identifier / locator split. But I=20 > have yet to see a=20 > justification as to why these numbers should also entail a=20 > reservation in=20 > the IPv6 unicast number space. Indeed, I can think of some tolerable=20 > arguments as to why they should deliberately clash with=20 > unicast address values. >=20 > regards, >=20 > Geoff _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88X-00088D-4p; Mon, 21 Nov 2005 04:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnMO-00020U-47; Mon, 14 Nov 2005 18:03:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08622; Mon, 14 Nov 2005 18:03:03 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbndV-0002Zu-CQ; Mon, 14 Nov 2005 18:21:17 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA27245; Mon, 14 Nov 2005 15:03:13 -0800 (PST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAEN3CH24345; Mon, 14 Nov 2005 15:03:12 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.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: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 18:03:02 -0500 Message-ID: <620321DC01C5E54BB37FF662E0C314B501F98009@xch-ne-05p.ne.nos.boeing.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXpbo3/cESkOfeAQKa9BnHgwqeCowAAE9ng From: "Manfredi, Albert E" To: "Geoff Huston" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:54 -0500 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org I didn't assume that the identifier space with no locator overtones must be non-intersecting with a routable network space. Are you saying that use of these identifiers must only apply to isolated nets? Bert > -----Original Message----- > From: Geoff Huston [mailto:gih@apnic.net]=20 > Sent: Monday, November 14, 2005 5:54 PM > To: Manfredi, Albert E > Cc: Internet Area; ipv6@ietf.org > Subject: RE: [Int-area] Re: KHIs and SHA-256=20 >=20 > Don't present such packets to the router. >=20 > i.e. if you are working in an identifier space that has no locator=20 > overtones (I have already seen the assertion that these=20 > identifiers are=20 > "non-routeable"), then how exactly will these identity values=20 > show up in a=20 > packet on the wire and be presented to routers are a=20 > destination or source=20 > locator? >=20 > Geoff >=20 >=20 >=20 >=20 >=20 >=20 > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > >Geoff, > > > >How would a router know not to forward such packets, in the event the > >top 64 bits clash with a real IPv6 address? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 3:11 PM > > > To: Pekka Nikander > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > But nothing in what you have said is inconsistent with the > > > proposition that > > > there is _no_ requirement to allocate IPv6 unicast address > > > space for this > > > form of use of 128 numbers. > > > > > > As you yourself point out "they are non-routeable" and theya > > > re understood > > > to be "semantically different". > > > > > > i.e. what you are going with the number in this context is really > > > interesting, and a Good Thing in terms of furthering our > > > understanding of > > > the implications of the identifier / locator split. But I > > > have yet to see a > > > justification as to why these numbers should also entail a > > > reservation in > > > the IPv6 unicast number space. Indeed, I can think of=20 > some tolerable > > > arguments as to why they should deliberately clash with > > > unicast address values. > > > > > > regards, > > > > > > Geoff > > > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- >=20 >=20 >=20 >=20 _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88X-00088w-Ff; Mon, 21 Nov 2005 04:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnVU-00059P-4d; Mon, 14 Nov 2005 18:13:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09224; Mon, 14 Nov 2005 18:12:27 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebnmb-0002tf-4d; Mon, 14 Nov 2005 18:30:41 -0500 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.14902366; Mon, 14 Nov 2005 18:12:22 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 18:12:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 18:12:21 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73C2F14C@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXpbxPO/dKTvceeTBSFs7BHIxHmvQAAcme6 From: "Durand, Alain" To: , X-OriginalArrivalTime: 14 Nov 2005 23:12:22.0443 (UTC) FILETIME=[DE4267B0:01C5E970] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:53 -0500 Cc: int-area@ietf.org, ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2052261211==" Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org --===============2052261211== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R2VvZmYsDQoNClRoZSBxdWVzdGlvbiBpczogY2FuIHRob3NlIGlkZW50aWZpZXIgbGVhayBmcm9t IGFuIGFwcGxpY2F0aW9uIGFuZCB0aGVuIGJlIHVzZWQgYXMgbG9jYXRvcnM/DQoNCklmIHRoZXJl IGlzIGEgcmlzayBvZiBsZWFrLCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgc2VwYXJhdGUgcHJlZml4 LiBJZiB3ZSBhcmUgMTAwJSBzdXJlIHRoZXJlIGlzIG5vIHdheSB0aGF0IGFueSBhcHBsaWNhdGlv biB3b3VsZCBldmVyIGxlYWssIHRoZW4gSSB3b3VsZCBhZ3JlZSB3ZSBkbyBub3QgbmVlZCB0byB1 c2UgYSBkZWRpY2F0ZWQgcHJlZml4Lg0KDQogICAgIC0gQWxhaW4uDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9yZw0KVG86IE1hbmZyZWRp LCBBbGJlcnQgRQ0KQ0M6IGlwdjZAaWV0Zi5vcmc7IEludGVybmV0IEFyZWENClNlbnQ6IE1vbiBO b3YgMTQgMTc6NTM6NDAgMjAwNQ0KU3ViamVjdDogUkU6IFtJbnQtYXJlYV0gUmU6IEtISXMgYW5k IFNIQS0yNTYgDQoNCkRvbid0IHByZXNlbnQgc3VjaCBwYWNrZXRzIHRvIHRoZSByb3V0ZXIuDQoN CmkuZS4gaWYgeW91IGFyZSB3b3JraW5nIGluIGFuIGlkZW50aWZpZXIgc3BhY2UgdGhhdCBoYXMg bm8gbG9jYXRvciANCm92ZXJ0b25lcyAoSSBoYXZlIGFscmVhZHkgc2VlbiB0aGUgYXNzZXJ0aW9u IHRoYXQgdGhlc2UgaWRlbnRpZmllcnMgYXJlIA0KIm5vbi1yb3V0ZWFibGUiKSwgdGhlbiBob3cg ZXhhY3RseSB3aWxsIHRoZXNlIGlkZW50aXR5IHZhbHVlcyBzaG93IHVwIGluIGEgDQpwYWNrZXQg b24gdGhlIHdpcmUgYW5kIGJlIHByZXNlbnRlZCB0byByb3V0ZXJzIGFyZSBhIGRlc3RpbmF0aW9u IG9yIHNvdXJjZSANCmxvY2F0b3I/DQoNCiAgIEdlb2ZmDQoNCg0KDQoNCg0KDQpBdCAwODowMyBB TSAxNS8xMS8yMDA1LCBNYW5mcmVkaSwgQWxiZXJ0IEUgd3JvdGU6DQo+R2VvZmYsDQo+DQo+SG93 IHdvdWxkIGEgcm91dGVyIGtub3cgbm90IHRvIGZvcndhcmQgc3VjaCBwYWNrZXRzLCBpbiB0aGUg ZXZlbnQgdGhlDQo+dG9wIDY0IGJpdHMgY2xhc2ggd2l0aCBhIHJlYWwgSVB2NiBhZGRyZXNzPw0K Pg0KPkJlcnQNCj4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IEdlb2ZmIEh1c3RvbiBbbWFpbHRvOmdpaEBhcG5pYy5uZXRdDQo+ID4gU2VudDogTW9uZGF5LCBO b3ZlbWJlciAxNCwgMjAwNSAzOjExIFBNDQo+ID4gVG86IFBla2thIE5pa2FuZGVyDQo+ID4gQ2M6 IGlwdjZAaWV0Zi5vcmc7IEJyaWFuIEhhYmVybWFuOyBJbnRlcm5ldCBBcmVhDQo+ID4gU3ViamVj dDogUmU6IFtJbnQtYXJlYV0gUmU6IEtISXMgYW5kIFNIQS0yNTYNCj4gPg0KPiA+IEJ1dCBub3Ro aW5nIGluIHdoYXQgeW91IGhhdmUgc2FpZCBpcyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUNCj4gPiBw cm9wb3NpdGlvbiB0aGF0DQo+ID4gdGhlcmUgaXMgX25vXyByZXF1aXJlbWVudCB0byBhbGxvY2F0 ZSBJUHY2IHVuaWNhc3QgYWRkcmVzcw0KPiA+IHNwYWNlIGZvciB0aGlzDQo+ID4gZm9ybSBvZiB1 c2Ugb2YgMTI4IG51bWJlcnMuDQo+ID4NCj4gPiBBcyB5b3UgeW91cnNlbGYgcG9pbnQgb3V0ICJ0 aGV5IGFyZSBub24tcm91dGVhYmxlIiBhbmQgdGhleWENCj4gPiByZSB1bmRlcnN0b29kDQo+ID4g dG8gYmUgInNlbWFudGljYWxseSBkaWZmZXJlbnQiLg0KPiA+DQo+ID4gaS5lLiB3aGF0IHlvdSBh cmUgZ29pbmcgd2l0aCB0aGUgbnVtYmVyIGluIHRoaXMgY29udGV4dCBpcyByZWFsbHkNCj4gPiBp bnRlcmVzdGluZywgYW5kIGEgR29vZCBUaGluZyBpbiB0ZXJtcyBvZiBmdXJ0aGVyaW5nIG91cg0K PiA+IHVuZGVyc3RhbmRpbmcgb2YNCj4gPiB0aGUgaW1wbGljYXRpb25zIG9mIHRoZSBpZGVudGlm aWVyIC8gbG9jYXRvciBzcGxpdC4gQnV0IEkNCj4gPiBoYXZlIHlldCB0byBzZWUgYQ0KPiA+IGp1 c3RpZmljYXRpb24gYXMgdG8gd2h5IHRoZXNlIG51bWJlcnMgc2hvdWxkIGFsc28gZW50YWlsIGEN Cj4gPiByZXNlcnZhdGlvbiBpbg0KPiA+IHRoZSBJUHY2IHVuaWNhc3QgbnVtYmVyIHNwYWNlLiBJ bmRlZWQsIEkgY2FuIHRoaW5rIG9mIHNvbWUgdG9sZXJhYmxlDQo+ID4gYXJndW1lbnRzIGFzIHRv IHdoeSB0aGV5IHNob3VsZCBkZWxpYmVyYXRlbHkgY2xhc2ggd2l0aA0KPiA+IHVuaWNhc3QgYWRk cmVzcyB2YWx1ZXMuDQo+ID4NCj4gPiByZWdhcmRzLA0KPiA+DQo+ID4gICAgICAgR2VvZmYNCj4N Cj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0K PmlwdjZAaWV0Zi5vcmcNCj5BZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3Jn DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --===============2052261211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============2052261211==-- From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88X-00089S-Ql; Mon, 21 Nov 2005 04:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboHL-0003gT-Ev; Mon, 14 Nov 2005 19:02:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12230; Mon, 14 Nov 2005 19:01:56 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EboYT-0004U9-7o; Mon, 14 Nov 2005 19:20:09 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 16:02:16 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:02:16 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:02:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:02:16 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 16:02:13 -0800 Message-ID: Thread-Topic: [Int-area] Re: KHIs and SHA-256 thread-index: AcXpdlqC23AOOpVaRTa6Vb4ivk9XDAAASx3A From: "Christian Huitema" To: "Geoff Huston" , "Manfredi, Albert E" X-OriginalArrivalTime: 15 Nov 2005 00:02:16.0150 (UTC) FILETIME=[D6A5D760:01C5E977] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:53 -0500 Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org IMHO, every identifier ends up being routed, at least in some context. For example, there is a good case that on a disconnected ad hoc network, it makes more sense to use the identifiers you have than to create some new addresses. Indeed, if one is willing to have individual host entries in a routing table, then one can use any identifier. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Geoff Huston Sent: Monday, November 14, 2005 3:40 PM To: Manfredi, Albert E Cc: ipv6@ietf.org; Internet Area Subject: RE: [Int-area] Re: KHIs and SHA-256=20 I heard "non-routeable" with respect to these identifiers. Is this _really_ the case? Geoff At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: >I didn't assume that the identifier space with no locator overtones must >be non-intersecting with a routable network space. > >Are you saying that use of these identifiers must only apply to isolated >nets? > >Bert > > > > -----Original Message----- > > From: Geoff Huston [mailto:gih@apnic.net] > > Sent: Monday, November 14, 2005 5:54 PM > > To: Manfredi, Albert E > > Cc: Internet Area; ipv6@ietf.org > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > Don't present such packets to the router. > > > > i.e. if you are working in an identifier space that has no locator > > overtones (I have already seen the assertion that these > > identifiers are > > "non-routeable"), then how exactly will these identity values > > show up in a > > packet on the wire and be presented to routers are a > > destination or source > > locator? > > > > Geoff > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > >Geoff, > > > > > >How would a router know not to forward such packets, in the event the > > >top 64 bits clash with a real IPv6 address? > > > > > >Bert > > > > > > > > > > -----Original Message----- > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > To: Pekka Nikander > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > But nothing in what you have said is inconsistent with the > > > > proposition that > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > space for this > > > > form of use of 128 numbers. > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > re understood > > > > to be "semantically different". > > > > > > > > i.e. what you are going with the number in this context is really > > > > interesting, and a Good Thing in terms of furthering our > > > > understanding of > > > > the implications of the identifier / locator split. But I > > > > have yet to see a > > > > justification as to why these numbers should also entail a > > > > reservation in > > > > the IPv6 unicast number space. Indeed, I can think of > > some tolerable > > > > arguments as to why they should deliberately clash with > > > > unicast address values. > > > > > > > > regards, > > > > > > > > Geoff > > > > > > > > >-------------------------------------------------------------------- > > >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 -------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88Y-00089r-5X; Mon, 21 Nov 2005 04:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebodp-0002l7-Rh; Mon, 14 Nov 2005 19:25:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13379; Mon, 14 Nov 2005 19:25:10 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eboux-0005CP-KO; Mon, 14 Nov 2005 19:43:24 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 16:25:31 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:25:31 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:25:31 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:25:30 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 16:25:29 -0800 Message-ID: Thread-Topic: [Int-area] Re: KHIs and SHA-256 thread-index: AcXpecl1S8UudH10RySoJ5pkyQb+mwAAOz7g From: "Christian Huitema" To: "Geoff Huston" , "Manfredi, Albert E" X-OriginalArrivalTime: 15 Nov 2005 00:25:30.0878 (UTC) FILETIME=[15F871E0:01C5E97B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:53 -0500 Cc: ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org The purpose of the request identifiers is to be "network like", in the sense that they are used by applications in place of addresses. They share many of the attributes of addresses, e.g. size, binary format, uniqueness. There is a natural trend that such "overlay identifiers" end up being used directly for routing purpose. Hey, IPv4 addresses started life as overlay identifiers... -----Original Message----- From: Geoff Huston [mailto:gih@apnic.net]=20 Sent: Monday, November 14, 2005 4:15 PM To: Christian Huitema; Manfredi, Albert E Cc: Internet Area; ipv6@ietf.org Subject: RE: [Int-area] Re: KHIs and SHA-256=20 At 11:02 AM 15/11/2005, Christian Huitema wrote: >IMHO, every identifier ends up being routed, at least in some context. Does your statement here specifically encompass the DNS? If not, then what=20 is the difference between such DNS identifiers and the ones under=20 consideration in this context? regards, Geoff >For example, there is a good case that on a disconnected ad hoc network, >it makes more sense to use the identifiers you have than to create some >new addresses. Indeed, if one is willing to have individual host entries >in a routing table, then one can use any identifier. > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >Geoff Huston >Sent: Monday, November 14, 2005 3:40 PM >To: Manfredi, Albert E >Cc: ipv6@ietf.org; Internet Area >Subject: RE: [Int-area] Re: KHIs and SHA-256 > >I heard "non-routeable" with respect to these identifiers. > >Is this _really_ the case? > > Geoff > > >At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: > >I didn't assume that the identifier space with no locator overtones >must > >be non-intersecting with a routable network space. > > > >Are you saying that use of these identifiers must only apply to >isolated > >nets? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 5:54 PM > > > To: Manfredi, Albert E > > > Cc: Internet Area; ipv6@ietf.org > > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > > > Don't present such packets to the router. > > > > > > i.e. if you are working in an identifier space that has no locator > > > overtones (I have already seen the assertion that these > > > identifiers are > > > "non-routeable"), then how exactly will these identity values > > > show up in a > > > packet on the wire and be presented to routers are a > > > destination or source > > > locator? > > > > > > Geoff > > > > > > > > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > > >Geoff, > > > > > > > >How would a router know not to forward such packets, in the event >the > > > >top 64 bits clash with a real IPv6 address? > > > > > > > >Bert > > > > > > > > > > > > > -----Original Message----- > > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > > To: Pekka Nikander > > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > > > But nothing in what you have said is inconsistent with the > > > > > proposition that > > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > > space for this > > > > > form of use of 128 numbers. > > > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > > re understood > > > > > to be "semantically different". > > > > > > > > > > i.e. what you are going with the number in this context is >really > > > > > interesting, and a Good Thing in terms of furthering our > > > > > understanding of > > > > > the implications of the identifier / locator split. But I > > > > > have yet to see a > > > > > justification as to why these numbers should also entail a > > > > > reservation in > > > > > the IPv6 unicast number space. Indeed, I can think of > > > some tolerable > > > > > arguments as to why they should deliberately clash with > > > > > unicast address values. > > > > > > > > > > regards, > > > > > > > > > > Geoff > > > > > > > > > > > > >-------------------------------------------------------------------- > > > >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 >-------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88Y-0008Ap-Rl; Mon, 21 Nov 2005 04:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpCp-0005vG-BU; Mon, 14 Nov 2005 20:01:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15366; Mon, 14 Nov 2005 20:01:19 -0500 (EST) Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbpTw-0006Ns-En; Mon, 14 Nov 2005 20:19:33 -0500 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id jAENuOt8062952; Mon, 14 Nov 2005 15:56:24 -0800 (PST) (envelope-from drc@virtualized.org) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [Int-area] Re: KHIs and SHA-256 Date: Mon, 14 Nov 2005 17:01:38 -0800 To: Christian Huitema X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:54 -0500 Cc: "Manfredi, Albert E" , ipv6@ietf.org, Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Christian, On Nov 14, 2005, at 4:02 PM, Christian Huitema wrote: > IMHO, every identifier ends up being routed, at least in some context. If they are routed, they are not identifiers. They are locators. An identifier simply names the object. It might enable connectivity on a non-routed infrastructure, e.g., a local LAN, and if you want to call this 'being routed', then your comment could be considered accurate, but in a rather pointless sense. > For example, there is a good case that on a disconnected ad hoc > network, > it makes more sense to use the identifiers you have than to create > some > new addresses. Indeed, if one is willing to have individual host > entries > in a routing table, then one can use any identifier. Then the locator and the identifier have the same value, but they are semantically different. I don't quite understand why this is so difficult for folks to understand. IMHO, the failure to differentiate the two is probably the biggest failing in the IP protocol. Rgds, -drc Speaking only for myself _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Nov 21 04:38:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee88Z-0008Bq-85; Mon, 21 Nov 2005 04:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7yP-0000BN-Pj; Tue, 15 Nov 2005 16:04:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26272; Tue, 15 Nov 2005 16:03:41 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec8Ff-0003Tb-LM; Tue, 15 Nov 2005 16:22:07 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA09292; Tue, 15 Nov 2005 15:03:53 -0600 (CST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAFL3qH09398; Tue, 15 Nov 2005 13:03:52 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.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: [Int-area] Re: KHIs and SHA-256 Date: Tue, 15 Nov 2005 16:03:51 -0500 Message-ID: <620321DC01C5E54BB37FF662E0C314B501F98012@xch-ne-05p.ne.nos.boeing.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXqJxV4f5LcI6urSCqJ1hFwbjd/RgAAH8NQ From: "Manfredi, Albert E" To: "Pekka Nikander" , "Brian Haberman" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Nov 2005 04:38:54 -0500 Cc: Internet Area , ipv6@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: int-area-bounces@lists.ietf.org Errors-To: int-area-bounces@lists.ietf.org Pekka Nikander wrote: > As I wrote, I can't see how we could convince the world from going =20 > from where we are now to a world that requires people to=20 > change their =20 > network stack, add a new piece of infrastructure, and to change =20 > applications at the same time. That won't happen, any more. This is also my confusion in the thread. I thought the I-D wanted to retain the 128-bit structure, but change the semantics, specifically so as not to require changes in the IP stack. > Doesn't that transition strategy make any sense to you? What is =20 > wrong with it? >=20 > If you are worried that once established such hook for an identifier =20 > space within the address space is likely to last for a long time, =20 > please say so. >=20 > --Pekka Bert _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area