From architecture-discuss-bounces@ietf.org Sun Apr 22 11:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfdZA-00038I-Ak; Sun, 22 Apr 2007 11:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfdZ9-000347-D0 for architecture-discuss@ietf.org; Sun, 22 Apr 2007 11:01:27 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfdZ8-0004qi-59 for architecture-discuss@ietf.org; Sun, 22 Apr 2007 11:01:27 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B85BA8731C; Sun, 22 Apr 2007 11:01:25 -0400 (EDT) To: architecture-discuss@ietf.org Message-Id: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Date: Sun, 22 Apr 2007 11:01:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: jnc@mercury.lcs.mit.edu Subject: [arch-d] Benefits of identity/location separation? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I was recently talking with someone of the recent discussion, and they made the point that they hadn't seen a clear enumeration of the benefits of separation of location and identity. This is something I tend not to think about in detail, because I am always mindful of the Great Architecture dictum ("the hallmark of great architecture is not how well it does the things you knew it needed to do, and it was therefore designed to do, but how well it does things nobody had thought of at the time it was designed"). E.g. nobody who did TCP/IP had any real idea of the Web (the closest we came was something like the world of John Brunner's "Shockwave Rider"). Not surprising; new things tend not to get thought up until the architecture enables them. So, I tend to think in a very different way (asking things like "does this structure express some fundamental truth about the way things ought to be organized"). However, it would probably be a useful exercise if we can enumerate, and to some degreee evaluate, all the *immediate* benefits which separation of location and identity will give us. Here are the ones I can come up with: - Multihoming: A number of aspects of multihoming are easier with separation. Specifically: - Avoiding having to give hosts multiple "addresses". With anything vaguely like the current routing architecture, we cannot support widespread multihoming purely within the routing (i.e. PI addresses). The only other technically feasible approach that years of work have identified is for such hosts have to have multiple addresses. Howeever, this seems to be an operation non-starter, and is the big objection to designs like SHIM6. - Keeping connections open if one address becomes unreachable (this applies to hosts with multiple interfaces too). - Provider independence for small organizations: It's much easier to switch providers if the low-level naming of hosts doesn't change when this happens. Currently, the only other ways to provide this are PI-addresses (which don't scale to support many small sites), and NAT. - Mobility: Mobility (especially as distinct from portability - the former term is taken to include keeping connections open) is basically impossible without separation of location and identity. Mobile6 basically does this now, albeit with both namespaces being IPv6 addresses. - Multicast: Right now, the notion of the membership of a multicast group, and the distribution tree thereto, are inherently entangled. My feeling is that until we can separate the two, widespread multicast (especially lots of small groups) will be technically infeasible. Alas, I have a feeling I am missing a great deal, but I don't think well at this level. Can others expand on this list? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Apr 22 22:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfoOJ-0006Co-35; Sun, 22 Apr 2007 22:34:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfoOI-0006Cj-Iw for architecture-discuss@ietf.org; Sun, 22 Apr 2007 22:34:58 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfoOH-00063n-5G for architecture-discuss@ietf.org; Sun, 22 Apr 2007 22:34:58 -0400 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 438DE17BDE; Mon, 23 Apr 2007 04:34:56 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Apr 2007 01:09:17 +0200 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: JFC Morfin Subject: Re: [arch-d] Benefits of identity/location separation? In-Reply-To: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070423023456.438DE17BDE@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Noel, I do not see any advantage myself, except that by chance it can support better some of the needs of the three addressing (fixity, mobility, and virtuality) layers, than the default current fixty only layer violation. jfc At 17:01 22/04/2007, Noel Chiappa wrote: >I was recently talking with someone of the recent discussion, and they made >the point that they hadn't seen a clear enumeration of the benefits of >separation of location and identity. > >This is something I tend not to think about in detail, because I am always >mindful of the Great Architecture dictum ("the hallmark of great architecture >is not how well it does the things you knew it needed to do, and it was >therefore designed to do, but how well it does things nobody had thought of >at the time it was designed"). E.g. nobody who did TCP/IP had any real idea >of the Web (the closest we came was something like the world of John >Brunner's "Shockwave Rider"). Not surprising; new things tend not to get >thought up until the architecture enables them. So, I tend to think in a very >different way (asking things like "does this structure express some >fundamental truth about the way things ought to be organized"). > >However, it would probably be a useful exercise if we can enumerate, and to >some degreee evaluate, all the *immediate* benefits which separation of >location and identity will give us. Here are the ones I can come up with: > >- Multihoming: A number of aspects of multihoming are easier with separation. > Specifically: > - Avoiding having to give hosts multiple "addresses". With anything vaguely > like the current routing architecture, we cannot support widespread > multihoming purely within the routing (i.e. PI addresses). The only other > technically feasible approach that years of work have identified is for > such hosts have to have multiple addresses. Howeever, this seems to be > an operation non-starter, and is the big objection to designs like SHIM6. > - Keeping connections open if one address becomes unreachable (this applies > to hosts with multiple interfaces too). > >- Provider independence for small organizations: It's much easier to switch > providers if the low-level naming of hosts doesn't change when this > happens. Currently, the only other ways to provide this are PI-addresses > (which don't scale to support many small sites), and NAT. > >- Mobility: Mobility (especially as distinct from portability - the former > term is taken to include keeping connections open) is basically > impossible without separation of location and identity. Mobile6 basically > does this now, albeit with both namespaces being IPv6 addresses. > >- Multicast: Right now, the notion of the membership of a multicast group, > and the distribution tree thereto, are inherently entangled. My feeling > is that until we can separate the two, widespread multicast (especially > lots of small groups) will be technically infeasible. > >Alas, I have a feeling I am missing a great deal, but I don't think well at >this level. Can others expand on this list? > > Noel > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 23 10:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzpe-0005W5-Gc; Mon, 23 Apr 2007 10:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzpd-0005Tr-4L for architecture-discuss@ietf.org; Mon, 23 Apr 2007 10:47:57 -0400 Received: from web58708.mail.re1.yahoo.com ([66.196.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfzpa-0005ie-Kd for architecture-discuss@ietf.org; Mon, 23 Apr 2007 10:47:57 -0400 Received: (qmail 10976 invoked by uid 60001); 23 Apr 2007 14:47:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=w31y+RWs7RTP4QGYxCMhzLWA2sAyEe7qMjsSDubHJz4p5DsMCxU57QtnNj1ZWiws/dE+ZyNYtO6OLNubvrxiNcHi/3RUfBUeiRqGImAfvwrFgADs3BNBtGkARNoawUNcZ3fsjPf3Ii7PG4VBvX3DLR6tNSdnBqZhwmoHtcTdyXA=; X-YMail-OSG: amPLCI4VM1l4tDQGBLDa0fiz6H2lL9bT9Bcim.j0 Received: from [207.107.50.100] by web58708.mail.re1.yahoo.com via HTTP; Mon, 23 Apr 2007 07:47:40 PDT Date: Mon, 23 Apr 2007 07:47:40 -0700 (PDT) From: Peter Sherbin Subject: Re: [arch-d] Benefits of identity/location separation? To: Noel Chiappa , architecture-discuss@ietf.org In-Reply-To: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <223014.5229.qm@web58708.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Could we look at Mobility as a general case where separation is required. Static sites are treated as mobile only not in motion. Peter --- Noel Chiappa wrote: > I was recently talking with someone of the recent discussion, and they made > the point that they hadn't seen a clear enumeration of the benefits of > separation of location and identity. > > This is something I tend not to think about in detail, because I am always > mindful of the Great Architecture dictum ("the hallmark of great architecture > is not how well it does the things you knew it needed to do, and it was > therefore designed to do, but how well it does things nobody had thought of > at the time it was designed"). E.g. nobody who did TCP/IP had any real idea > of the Web (the closest we came was something like the world of John > Brunner's "Shockwave Rider"). Not surprising; new things tend not to get > thought up until the architecture enables them. So, I tend to think in a very > different way (asking things like "does this structure express some > fundamental truth about the way things ought to be organized"). > > However, it would probably be a useful exercise if we can enumerate, and to > some degreee evaluate, all the *immediate* benefits which separation of > location and identity will give us. Here are the ones I can come up with: > > - Multihoming: A number of aspects of multihoming are easier with separation. > Specifically: > - Avoiding having to give hosts multiple "addresses". With anything vaguely > like the current routing architecture, we cannot support widespread > multihoming purely within the routing (i.e. PI addresses). The only other > technically feasible approach that years of work have identified is for > such hosts have to have multiple addresses. Howeever, this seems to be > an operation non-starter, and is the big objection to designs like SHIM6. > - Keeping connections open if one address becomes unreachable (this applies > to hosts with multiple interfaces too). > > - Provider independence for small organizations: It's much easier to switch > providers if the low-level naming of hosts doesn't change when this > happens. Currently, the only other ways to provide this are PI-addresses > (which don't scale to support many small sites), and NAT. > > - Mobility: Mobility (especially as distinct from portability - the former > term is taken to include keeping connections open) is basically > impossible without separation of location and identity. Mobile6 basically > does this now, albeit with both namespaces being IPv6 addresses. > > - Multicast: Right now, the notion of the membership of a multicast group, > and the distribution tree thereto, are inherently entangled. My feeling > is that until we can separate the two, widespread multicast (especially > lots of small groups) will be technically infeasible. > > Alas, I have a feeling I am missing a great deal, but I don't think well at > this level. Can others expand on this list? > > Noel > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 24 05:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGvl-0007Jj-Nj; Tue, 24 Apr 2007 05:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGvj-0007JS-Rn for architecture-discuss@ietf.org; Tue, 24 Apr 2007 05:03:23 -0400 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgGvj-0001OW-Ap for architecture-discuss@ietf.org; Tue, 24 Apr 2007 05:03:23 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l3O93MW8078706 for ; Tue, 24 Apr 2007 09:03:22 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3O93MGP2846908 for ; Tue, 24 Apr 2007 10:03:22 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3O93MSV031225 for ; Tue, 24 Apr 2007 10:03:22 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3O93Lbr031214; Tue, 24 Apr 2007 10:03:21 +0100 Received: from [9.4.210.19] ([9.4.210.19]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA453522; Tue, 24 Apr 2007 11:03:15 +0200 Message-ID: <462DA425.70705@zurich.ibm.com> Date: Tue, 24 Apr 2007 08:31:01 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] Benefits of identity/location separation? References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> In-Reply-To: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org There's a sense in which Noel's question was in my mind when I wrote draft-carpenter-idloc-map-cons-00.txt. Noel has told me he's going to comment on that on the RAM list, but here would work too... Just to complete the picture, we should probably also document the disadvantages of identity/location separation. Quoting my own draft: As implied by the previous section, there are cases where a split would increase rather than decrease confusion. Enterprise network operations would be turned upside down. Firewalls would have to deal with fundamental change, since identifiers rather than locators would be the focus of many attacks. The way the DNS and the socket API are related to each other might change. Any upper layer implementation that believes that an IP Address is both a Locator and an Identifier would be in even greater trouble than today. And of course the fragile superstructure built on NATs and ALGs would be severely challenged. These are all practical, operational disadvantages. Are there any architectural disadvantages? Brian On 2007-04-22 17:01, Noel Chiappa wrote: > I was recently talking with someone of the recent discussion, and they made > the point that they hadn't seen a clear enumeration of the benefits of > separation of location and identity. > > This is something I tend not to think about in detail, because I am always > mindful of the Great Architecture dictum ("the hallmark of great architecture > is not how well it does the things you knew it needed to do, and it was > therefore designed to do, but how well it does things nobody had thought of > at the time it was designed"). E.g. nobody who did TCP/IP had any real idea > of the Web (the closest we came was something like the world of John > Brunner's "Shockwave Rider"). Not surprising; new things tend not to get > thought up until the architecture enables them. So, I tend to think in a very > different way (asking things like "does this structure express some > fundamental truth about the way things ought to be organized"). > > However, it would probably be a useful exercise if we can enumerate, and to > some degreee evaluate, all the *immediate* benefits which separation of > location and identity will give us. Here are the ones I can come up with: > > - Multihoming: A number of aspects of multihoming are easier with separation. > Specifically: > - Avoiding having to give hosts multiple "addresses". With anything vaguely > like the current routing architecture, we cannot support widespread > multihoming purely within the routing (i.e. PI addresses). The only other > technically feasible approach that years of work have identified is for > such hosts have to have multiple addresses. Howeever, this seems to be > an operation non-starter, and is the big objection to designs like SHIM6. > - Keeping connections open if one address becomes unreachable (this applies > to hosts with multiple interfaces too). > > - Provider independence for small organizations: It's much easier to switch > providers if the low-level naming of hosts doesn't change when this > happens. Currently, the only other ways to provide this are PI-addresses > (which don't scale to support many small sites), and NAT. > > - Mobility: Mobility (especially as distinct from portability - the former > term is taken to include keeping connections open) is basically > impossible without separation of location and identity. Mobile6 basically > does this now, albeit with both namespaces being IPv6 addresses. > > - Multicast: Right now, the notion of the membership of a multicast group, > and the distribution tree thereto, are inherently entangled. My feeling > is that until we can separate the two, widespread multicast (especially > lots of small groups) will be technically infeasible. > > Alas, I have a feeling I am missing a great deal, but I don't think well at > this level. Can others expand on this list? > > Noel > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 24 08:52:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKVg-0004kK-0M; Tue, 24 Apr 2007 08:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKVe-0004k8-FF for architecture-discuss@ietf.org; Tue, 24 Apr 2007 08:52:42 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKVd-0007Qd-3x for architecture-discuss@ietf.org; Tue, 24 Apr 2007 08:52:42 -0400 Received: from [192.168.0.4] (adsl-67-127-54-128.dsl.pltn13.pacbell.net [67.127.54.128]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l3OCqPqi014000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 05:52:25 -0700 Message-ID: <462DFD6B.8090000@dcrocker.net> Date: Tue, 24 Apr 2007 05:51:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] Benefits of identity/location separation? References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> In-Reply-To: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel Chiappa wrote: > However, it would probably be a useful exercise if we can enumerate, and to > some degreee evaluate, all the *immediate* benefits which separation of > location and identity will give us. Here are the ones I can come up with: This is an important exercise, but it is equally important that it be done with sufficient scope. For example, as Brian suggests, the negatives also have to be considered. I also suggest that the characteristics of the split can have a massive impact on the characteristics of the result. An obvious example is the level at which the constructs are provided. Since locator must remain with IP, the question is where the identifier is used and whether it is globally unique, persistent and/or public. So, for example, it can be observed that we already have one kind of loc/id split, between IP Address and Domain Name. That has some strengths and it has some weaknesses. Any other choice for creating a new identifier venue will equally have trade-offs. Further, the granularity of the benefits (goals?) makes a difference. The need to have the IP layer support identifier is based on some critical assumptions. For example, there is a continuing assumption that two flows with different locator-pairs must be handled in the aggregate, by the IP infrastructure, if they are part of the same upper-level transmission, such as a TCP connection. While this sounds completely reasonable, it well might not be necessary or even appropriate. For example, just as a route tends to be relatively stable for the life of a given TCP connection, the amount of locator-pair changeability during a connection might actually be quite small. If it is, then there is no real need for the IP infrastructure to know that the different locator-pairs are related. This, in turn, means that the identifier might well be appropriate to provide at a higher layer, rather than a lower one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 24 11:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNJS-0003FW-Dv; Tue, 24 Apr 2007 11:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNJQ-00033s-Ai for architecture-discuss@ietf.org; Tue, 24 Apr 2007 11:52:16 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNJO-0003R8-Sh for architecture-discuss@ietf.org; Tue, 24 Apr 2007 11:52:16 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3OFq878029392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Apr 2007 08:52:08 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3OFq7VW004402; Tue, 24 Apr 2007 08:52:07 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3OFphvw003576; Tue, 24 Apr 2007 08:51:46 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 08:51:44 -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: [arch-d] Benefits of identity/location separation? Date: Tue, 24 Apr 2007 08:50:47 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0404929F@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Benefits of identity/location separation? Thread-Index: AceE7yNtIhA3JPV9RTy/Zo14suc1TAA0VnwA From: "Henderson, Thomas R" To: "Noel Chiappa" , X-OriginalArrivalTime: 24 Apr 2007 15:51:44.0254 (UTC) FILETIME=[752769E0:01C78688] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel,=20 I'm glad you raised this thread, since answering the question in the Subject: field of this email is what the HIP research group is chartered to explore (in the context of the HIP proposal specifically).=20 First, I think that the answers depend on the nature of the identifiers. Specifically, are they routable or usable as locators in some context, and do they have any inherent security properties? Second, the answers will also depend on how much one assumes that DNS or another service is available to facilitate the bindings. >=20 > - Multihoming: A number of aspects of multihoming are easier=20 > with separation. > Specifically: > - Avoiding having to give hosts multiple "addresses". With=20 > anything vaguely > like the current routing architecture, we cannot support=20 > widespread > multihoming purely within the routing (i.e. PI=20 > addresses).=20 Do you refer above to a border-router address rewriting approach? > The only other > technically feasible approach that years of work have=20 > identified is for > such hosts have to have multiple addresses. Howeever,=20 > this seems to be > an operation non-starter, and is the big objection to=20 > designs like SHIM6. I think that the above needs to be qualified. It may be that, in a large enterprise-managed situation, this is operationally problematic. However, if you have multiple interfaces, especially through multiple technologies or providers, then you may have to have multiple addresses at the host. Maybe multihoming category should be split into "site" and "host" multihoming variants. =20 > - Keeping connections open if one address becomes=20 > unreachable (this applies > to hosts with multiple interfaces too). agree >=20 > - Provider independence for small organizations: It's much=20 > easier to switch > providers if the low-level naming of hosts doesn't change=20 > when this > happens. Currently, the only other ways to provide this=20 > are PI-addresses > (which don't scale to support many small sites), and NAT. >=20 > - Mobility: Mobility (especially as distinct from portability=20 > - the former > term is taken to include keeping connections open) is basically > impossible without separation of location and identity.=20 > Mobile6 basically > does this now, albeit with both namespaces being IPv6 addresses. I agree that this seems impossible to have L3 mobility without some form of split. HIP and mobile IP have similar solutions (both early- and late-binding approaches) using different identifier spaces. I think an open question, however, is how much it helps operationally. Network-level ID/locator splits seem to help most when roaming across different layer-3 networks (different ASes). However, it seems that users most often are moving within a single provider's network and not hopping across providers (the so-called vertical handoff). I wonder whether there will be enough incentives for providers to support the vertical handoff modes of mobility. The intended seamless experience of roaming across layer-3 networks, perhaps with disconnection, may be defeated by things like ssh session timeouts and http capture agents. =20 >=20 > - Multicast: Right now, the notion of the membership of a=20 > multicast group, > and the distribution tree thereto, are inherently=20 > entangled. My feeling > is that until we can separate the two, widespread=20 > multicast (especially > lots of small groups) will be technically infeasible. Can you expand on this point? >=20 > Alas, I have a feeling I am missing a great deal, but I don't=20 > think well at > this level. Can others expand on this list? Architecturally, a split allows for late-binding approaches to resolution (e.g., the DTN or i3 architectures, mobile IP home agent) which may allow novel solutions to rendezvous, privacy, and delegation. Security (including privacy) is another issue that could be weakened or strengthened by a split, depending on the nature of the split. Tom _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 24 21:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgVxQ-00009o-K6; Tue, 24 Apr 2007 21:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgVxP-00009Y-32 for architecture-discuss@ietf.org; Tue, 24 Apr 2007 21:06:07 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgVxN-0006mm-Og for architecture-discuss@ietf.org; Tue, 24 Apr 2007 21:06:07 -0400 Received: from [10.0.1.48] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc11) with ESMTP id <20070425010601b1100kd01ee>; Wed, 25 Apr 2007 01:06:05 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Date: Tue, 24 Apr 2007 21:02:16 -0400 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Benefits of identity/location separation? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I think "patch" would be a better characterization of the benefits to the so-called loc/id split problem. As we both know solving the loc/id split is not the whole problem. I have not seen a solution to the loc/id split that scales. As far as things like the web: As Alan Kay pointed out not long ago, the developers of the web would have done well to look at NLS first. While NLS was single-site at the time, that wasn't a limitation of the design, only the times. It was much closer to what we should have had. However, I am more concerned by the responses that don't see that there is a problem that needs to be solved. This is one of several fundamental problems we have known about for 35 years that remain unresolved. It begins to look more and more like the IETF/Internet has acquired a mind set more like the phone companies in 1970s than networking of the 1970s. But you are right, the mark of a good architecture is one that solves problems that were not designed in. Take care, John At 11:01 -0400 2007/04/22, Noel Chiappa wrote: >I was recently talking with someone of the recent discussion, and they made >the point that they hadn't seen a clear enumeration of the benefits of >separation of location and identity. > >This is something I tend not to think about in detail, because I am always >mindful of the Great Architecture dictum ("the hallmark of great architecture >is not how well it does the things you knew it needed to do, and it was >therefore designed to do, but how well it does things nobody had thought of >at the time it was designed"). E.g. nobody who did TCP/IP had any real idea >of the Web (the closest we came was something like the world of John >Brunner's "Shockwave Rider"). Not surprising; new things tend not to get >thought up until the architecture enables them. So, I tend to think in a very >different way (asking things like "does this structure express some >fundamental truth about the way things ought to be organized"). > >However, it would probably be a useful exercise if we can enumerate, and to >some degreee evaluate, all the *immediate* benefits which separation of >location and identity will give us. Here are the ones I can come up with: > >- Multihoming: A number of aspects of multihoming are easier with separation. > Specifically: > - Avoiding having to give hosts multiple "addresses". With anything vaguely > like the current routing architecture, we cannot support widespread > multihoming purely within the routing (i.e. PI addresses). The only other > technically feasible approach that years of work have identified is for > such hosts have to have multiple addresses. Howeever, this seems to be > an operation non-starter, and is the big objection to designs like SHIM6. > - Keeping connections open if one address becomes unreachable (this applies > to hosts with multiple interfaces too). > >- Provider independence for small organizations: It's much easier to switch > providers if the low-level naming of hosts doesn't change when this > happens. Currently, the only other ways to provide this are PI-addresses > (which don't scale to support many small sites), and NAT. > >- Mobility: Mobility (especially as distinct from portability - the former > term is taken to include keeping connections open) is basically > impossible without separation of location and identity. Mobile6 basically > does this now, albeit with both namespaces being IPv6 addresses. > >- Multicast: Right now, the notion of the membership of a multicast group, > and the distribution tree thereto, are inherently entangled. My feeling > is that until we can separate the two, widespread multicast (especially > lots of small groups) will be technically infeasible. > >Alas, I have a feeling I am missing a great deal, but I don't think well at >this level. Can others expand on this list? > > Noel > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 24 22:03:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWqp-000455-Op; Tue, 24 Apr 2007 22:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWqo-00044x-B1 for architecture-discuss@ietf.org; Tue, 24 Apr 2007 22:03:22 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWqn-00012i-Jm for architecture-discuss@ietf.org; Tue, 24 Apr 2007 22:03:22 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 3C19E1CC20; Tue, 24 Apr 2007 22:03:21 -0400 (EDT) Date: Tue, 24 Apr 2007 22:03:21 -0400 From: John Leslie To: Noel Chiappa Subject: Re: [arch-d] Benefits of identity/location separation? Message-ID: <20070425020321.GD97539@verdi> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel Chiappa wrote: > > ... (asking things like "does this structure express some fundamental > truth about the way things ought to be organized"). (For example, the difference between a host and an interface? ;^) > However, it would probably be a useful exercise if we can enumerate, > and to some degreee evaluate, all the *immediate* benefits which > separation of location and identity will give us. I usually refuse to list any "immediate" benefits... > Here are the ones I can come up with: > > - Multihoming: A number of aspects of multihoming are easier with separation. > Specifically: > - Avoiding having to give hosts multiple "addresses". It's more a matter of avoiding the pitfalls of multiple "addresses" for a host. We're going to end up with multiple "locators" for an interface anyway, which isn't the same problem at all... > With anything vaguely like the current routing architecture, we > cannot support widespread multihoming purely within the routing > (i.e. PI addresses). That's not actually the problem: we can assign PI addresses to several orders of magnitude more hosts; what we can't do is have routing do anything "reasonable" about them. Folks who pay thousands of dollars per month for redundant connectivity _really want it to _do_ something. They will insist on fiddling the knobs until they believe it _is_ doing something. Routing, OTOH, _really_ needs to avoid routing loops. In most cases, there's nothing routing can do to effectively use redundant connectivity without creating a danger of routing loops. Actually, it's even worse: routing can't even tell the difference between a congested link and a failed link. We have to settle for a generic timeout to declare a link to have failed, which leads to _both_ mistaking congestion for failure and failure to switch to an alternate path quickly enough. That decision, IMHO, doesn't belong in routing... Loc/ID split would give us the tools to recognize multiple paths of a single "connection", enabling load-sharing and "instant" switching upon path failure or sudden increase in congestion. (That would require _some_ changes in TCP stacks -- perhaps only to the congestion control if we hide the locator manipulation from the TCP stack itself...) > The only other technically feasible approach that years of work > have identified is for such hosts have to have multiple addresses. Do you mean the likes of SCTP? > However, this seems to be an operation non-starter, and is the > big objection to designs like SHIM6. Actually, I think there are other "big" objections to SHIM6... > - Keeping connections open if one address becomes unreachable (this > applies to hosts with multiple interfaces too). I think you should have stopped after "open". For years I was saying that the Internet was designed to survive World War III -- by patiently waiting for civilization to rebuild, and then resuming where it was interrupted. We should be able to keep connections open, period. If somebody unplugs his laptop from his office ethernet, it should be able to continue downloading over the office wireless, stall intermittently while he drives home, and pick up speed again when he gets home to his cable "broadband" connection. Applications shouldn't have to deal with this: it should come "for free" in the operating system. This would require exactly the same changes to TCP stacks. > - Provider independence for small organizations: It's much easier to > switch providers if the low-level naming of hosts doesn't change > when this happens. "Renumbering" is a horror, because synchronizing any access at all to hundreds of hosts is practically impossible. (Not to even mention work necessarily interrupted.) > Currently, the only other ways to provide this are PI-addresses > (which don't scale to support many small sites), and NAT. (NAT should be our friend. NAT _could_ be our friend, IMHO. NAT _could_ handle most of what we need if we could migrate congestion control to it...) > - Mobility: Mobility (especially as distinct from portability - the > former term is taken to include keeping connections open) is > basically impossible without separation of location and identity. While literally true, I'd avoid saying it that way. Most folks don't take "mobility" to imply keeping connections open. It's something we could do with a proper loc/ID split, yes, but most folks think it's OK so long as their browser window works and checking their email remains automatic. I think we need to talk of "seamless mobility", where applications no longer need to pay any heed to whether the host is mobile. > Mobile6 basically does this now, albeit with both namespaces being > IPv6 addresses. Assuming you mean Mobile IPv6, I don't agree it does any sort of namespace split. In effect it merely maintains a tunnel from a "home" locator to the mobile locator, which remains invisible to the other end of any connection. BTW, I see no reason something looking exactly like an "IPv6 address" can't be an "identifier", rather than a "locator". It just isn't what Mobile IPv6 does. > - Multicast: Right now, the notion of the membership of a multicast > group, and the distribution tree thereto, are inherently entangled. > My feeling is that until we can separate the two, widespread > multicast (especially lots of small groups) will be technically > infeasible. I wouldn't go that far: multicast _is_ technically feasible: it just depends upon non-scalable mechanisms for its operation. Loc/ID could give us some opportunities for alternative multicast routing paradigms; but I'm not sure that's where multicast stalls. > Alas, I have a feeling I am missing a great deal, but I don't think > well at this level. Can others expand on this list? I don't think you're missing all that much -- within today's paradigms of what the Internet does... Nonetheless, there is certainly a need to list "protection from routing meltdown". Once we have a way -- outside routing -- to find alternate paths to a host, we can escape the feature-creep that's increasing the danger of routing meltdown. We also could explore entirely different routing paradigms if we were freed from the expectation of "quickly" finding alternate routes. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 24 22:37:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXNh-0007yO-Dz; Tue, 24 Apr 2007 22:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXNf-0007yG-M3 for architecture-discuss@ietf.org; Tue, 24 Apr 2007 22:37:19 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgXNf-0001Ja-ES for architecture-discuss@ietf.org; Tue, 24 Apr 2007 22:37:19 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 5FA9D1CC27; Tue, 24 Apr 2007 22:37:19 -0400 (EDT) Date: Tue, 24 Apr 2007 22:37:19 -0400 From: John Leslie To: Brian E Carpenter Subject: Re: [arch-d] Benefits of identity/location separation? Message-ID: <20070425023719.GE97539@verdi> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <462DA425.70705@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462DA425.70705@zurich.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian E Carpenter wrote: > > There's a sense in which Noel's question was in my mind when I wrote > draft-carpenter-idloc-map-cons-00.txt. Noel has told me he's going > to comment on that on the RAM list, but here would work too... I'd be happy to discuss it here... > Just to complete the picture, we should probably also document the > disadvantages of identity/location separation. > > Quoting my own draft: > As implied by the previous section, there are cases where a split > would increase rather than decrease confusion. Enterprise network > operations would be turned upside down. That overstates the case, IMHO. If a host ("stack") has multiple locators, they're still all under the control of the enterprise. The enterprise would have _more_ freedom to enforce traffic-shaping. The enterprise would have the _same_ ability to control assignment of locators that it now has for assignment of IP addresses. The enterprise _would_ have to deal with assignment and tracking of multiple locators. > Firewalls would have to deal with fundamental change, since > identifiers rather than locators would be the focus of many attacks. Their are some schemes being proposed that would tunnel IDs past firewalls. Hopefully saner heads will prevail: otherwise switches will have to be designed to enforce "source IP" filtering. This problem is not generic to loc/ID splitting: it results from implementation details. > The way the DNS and the socket API are related to each other might > change. Indeed... There are many ways to publish ID/loc mappings... > Any upper layer implementation that believes that an IP Address is > both a Locator and an Identifier would be in even greater trouble > than today. We might do well to try to compile a list of these: nothing jumps out at me as an example which assumes _both_... > And of course the fragile superstructure built on NATs and ALGs > would be severely challenged. It already _is_ severely challenged. For most purposes, we can assume that any migration to loc/ID which takes a year or more will be a slower cycle than the evolution of the threats NATs claim to ameliorate. Nonetheless, listing a few weak areas would be good. > These are all practical, operational disadvantages. Are there any > architectural disadvantages? I can't think of anything I'd call an "architectural disadvantage" of splitting loc and ID. (There certainly are architectural disadvantages of some specific proposals...) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 24 23:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXqV-0007jv-KC; Tue, 24 Apr 2007 23:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXqU-0007jo-O3 for architecture-discuss@ietf.org; Tue, 24 Apr 2007 23:07:06 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgXqU-0007bq-ET for architecture-discuss@ietf.org; Tue, 24 Apr 2007 23:07:06 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 8F6D11CC27; Tue, 24 Apr 2007 23:06:58 -0400 (EDT) Date: Tue, 24 Apr 2007 23:06:58 -0400 From: John Leslie To: dcrocker@bbiw.net Subject: Re: [arch-d] Benefits of identity/location separation? Message-ID: <20070425030658.GF97539@verdi> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <462DFD6B.8090000@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462DFD6B.8090000@dcrocker.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dave Crocker wrote: > > This is an important exercise, but it is equally important that it be > done with sufficient scope. For example, as Brian suggests, the > negatives also have to be considered. Agreed. > I also suggest that the characteristics of the split can have a massive > impact on the characteristics of the result. The devil, as always, is in the details; but a clean split need not break things not already "broken". > An obvious example is the level at which the constructs are provided. > Since locator must remain with IP, the question is where the identifier > is used and whether it is globally unique, persistent and/or public. Out of scope, IMHO. Or to say it differently: Identifiers should be used above the internetworking layer, they may or may not be globally unique, they should persist long enough to satisfy the needs of the layer using them, and some will be public while others are not. (I will stipulate that some proposals propose making identifiers visible to lower layers; however much I dislike this, it doesn't change the statement above.) (I further stipulate that some proposals try to be more restrictive than the statement above: they are simply wrong, and will be defeated in the marketplace if necessary.) > So, for example, it can be observed that we already have one kind of > loc/id split, between IP Address and Domain Name. That has some > strengths and it has some weaknesses. Any other choice for creating a > new identifier venue will equally have trade-offs. Its weaknesses are mostly historic (but we will have to live with them). We should note that DNS _could_ serve almost any imaginable loc/ID mapping, but the current usage maps mostly services, not stacks. > Further, the granularity of the benefits (goals?) makes a difference. > The need to have the IP layer support identifier is based on some > critical assumptions. ... all wrong-headed, IMHO. Besides, I don't consider that "granularity". It's simply a misunderstanding of what an identifier _is_. > For example, there is a continuing assumption that two flows with > different locator-pairs must be handled in the aggregate, by the IP > infrastructure, if they are part of the same upper-level transmission, > such as a TCP connection. While this sounds completely reasonable, it > well might not be necessary or even appropriate. It doesn't sound the least bit "reasonable" to me. The IP infrastructure should forward packets, period. It should not worry about "aggregates"; it should be blissfully unware whether there _is_ any such thing as an "upper-level transmission". TCP should have no difficulty "routing around" problems this might introduce, except that congestion control has gotten so intertwined with details of the current IP infrastructure that we cringe at any thought of changing it. > For example, just as a route tends to be relatively stable for the life > of a given TCP connection, (often false) > the amount of locator-pair changeability during a connection might > actually be quite small. Might... or might not... > If it is, then there is no real need for the IP infrastructure to > know that the different locator-pairs are related. There should be no such need in either case. > This, in turn, means that the identifier might well be appropriate > to provide at a higher layer, rather than a lower one. Agreed! -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 01:48:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgaMy-0003pj-IA; Wed, 25 Apr 2007 01:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgaMy-0003oM-3z for architecture-discuss@ietf.org; Wed, 25 Apr 2007 01:48:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgaMw-00030n-Lp for architecture-discuss@ietf.org; Wed, 25 Apr 2007 01:48:48 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 22:48:46 -0700 X-IronPort-AV: i="4.14,449,1170662400"; d="scan'208"; a="415322509:sNHT47764464" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3P5mkcd025249; Tue, 24 Apr 2007 22:48:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3P5mjwn023355; Wed, 25 Apr 2007 05:48:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 22:48:45 -0700 Received: from [192.168.0.100] ([10.21.99.173]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 22:48:44 -0700 In-Reply-To: References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Benefits of identity/location separation? Date: Wed, 25 Apr 2007 01:40:06 -0400 To: John Day X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Apr 2007 05:48:44.0235 (UTC) FILETIME=[629861B0:01C786FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=834; t=1177480126; x=1178344126; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[arch-d]=20Benefits=20of=20identity/location=20separa tion? |Sender:=20; bh=bplJdWVDxtcUmJ9jxjplD7ywRHikak1hTVDtxg0ZYMU=; b=e2CNIYfi9dUUhpIerDtmswFpqYmazpYe9eHnXxZPKEiN3T05ZgjqUHbBHunhnGQ1FUrDITFN h0WfANwhSaVmHSvdr3HXLZQvENaT/7iQ/pgq3ViqjrOp/i+jAJcHU7a8; Authentication-Results: sj-dkim-8; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Apr 24, 2007, at 9:02 PM, John Day wrote: > As we both know solving the loc/id split is not the whole problem. John, What would you say is "the whole problem"? > However, I am more concerned by the responses that don't see that > there is a problem that needs to be solved. This is one of several > fundamental problems we have known about for 35 years that remain > unresolved. It begins to look more and more like the IETF/Internet > has acquired a mind set more like the phone companies in 1970s than > networking of the 1970s. I think it's unfair to paint the entire IETF this way. There are those that are still unconvinced. I find it telling that those that are unconvinced are not those who will be called upon to fix things when we get to a full-fledged 'crisis'. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 02:41:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgbBa-00066k-69; Wed, 25 Apr 2007 02:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgbBY-00066f-2A for architecture-discuss@ietf.org; Wed, 25 Apr 2007 02:41:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgbBW-0004gn-P3 for architecture-discuss@ietf.org; Wed, 25 Apr 2007 02:41:04 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 23:41:03 -0700 X-IronPort-AV: i="4.14,449,1170662400"; d="scan'208"; a="415329648:sNHT46254924" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3P6f2Wx032243; Tue, 24 Apr 2007 23:41:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3P6eqAA028923; Wed, 25 Apr 2007 06:40:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 23:40:56 -0700 Received: from [192.168.0.100] ([10.21.99.173]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 23:40:55 -0700 In-Reply-To: <20070425030658.GF97539@verdi> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <462DFD6B.8090000@dcrocker.net> <20070425030658.GF97539@verdi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Benefits of identity/location separation? Date: Wed, 25 Apr 2007 02:40:54 -0400 To: John Leslie X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Apr 2007 06:40:56.0003 (UTC) FILETIME=[AD464130:01C78704] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=605; t=1177483262; x=1178347262; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[arch-d]=20Benefits=20of=20identity/location=20separa tion? |Sender:=20; bh=AvAmTWBj0QxF0l88161fFfG2M6s8Jzu4WMV7YJHUAJo=; b=UOfWczWg9gUpni+7tNKqJ9wMrtymOOg2Drnb+HZGK2Gwc8Ourulc3ZFgcxUKZD/dL6begD2A p7YwylhFx4zNf5XVyrdzsIHFHZFpaSWNFZtgy1BFflmIx+U6WrKHHXzv; Authentication-Results: sj-dkim-6; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dcrocker@bbiw.net, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Apr 24, 2007, at 11:06 PM, John Leslie wrote: > We should note that DNS _could_ serve almost any imaginable loc/ID > mapping, but the current usage maps mostly services, not stacks. More generally, I think that we should note that DNS can, with sufficiently clever encoding, provide almost any arbitrary mapping function that we can think of. Hacks like in-addr.arpa already give us a mapping from integers to strings, so we clearly have considerable flexibility. It's not just a distributed relational database, it's also a floor wax and desert topping! ;-) Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 07:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgfYf-0001zK-8P; Wed, 25 Apr 2007 07:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgfYd-0001zB-E0 for architecture-discuss@ietf.org; Wed, 25 Apr 2007 07:21:11 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgfYb-0004wZ-WA for architecture-discuss@ietf.org; Wed, 25 Apr 2007 07:21:11 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 50E0A19868C; Wed, 25 Apr 2007 14:21:08 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0FE1219866A; Wed, 25 Apr 2007 14:21:08 +0300 (EEST) Message-ID: <462F39A4.7030304@piuha.net> Date: Wed, 25 Apr 2007 14:21:08 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: John Day Subject: Re: [arch-d] Benefits of identity/location separation? References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, > I think "patch" would be a better characterization of the benefits to > the so-called loc/id split problem. As we both know solving the > loc/id split is not the whole problem. I have not seen a solution to > the loc/id split that scales. Not sure I understand what you mean with "the whole problem". Loc/id split is not a problem to begin with, its a solution designed to address a particular set of problems. I do agree that there are challenging aspects in this solution, and we need to see how scalable the mapping table distribution mechanisms are going to be, for instance. Or Brian's list of operational issues. The verdict is still open, but I think the approach is promising. > However, I am more concerned by the responses that don't see that > there is a problem that needs to be solved. I would suggest moving past this argument. It is true that there are differing opinions with regards to how urgent this issue is or how well we can create hardware to deal with it. But at the end of the day we know we have a situation where local events and state are visible on a global scale. There is no disagreement about that. As far as I know, there is also no disagreement about whether we should work towards a more scalable architecture. Bottom line: arguing about the level of urgency isn't going to move us forward. Having a design that can actually solve some of our problems does take us forward, however. Lets work to get to that design! And yes, we do need to understand the impacts of the design, both positive and negative. Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 07:50:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgg0y-0003Nk-Le; Wed, 25 Apr 2007 07:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgg0w-0003HD-M8 for architecture-discuss@ietf.org; Wed, 25 Apr 2007 07:50:26 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgg0u-0001th-Bk for architecture-discuss@ietf.org; Wed, 25 Apr 2007 07:50:26 -0400 Received: from [10.0.1.48] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20070425115006m1200cgkt7e>; Wed, 25 Apr 2007 11:50:21 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> Date: Wed, 25 Apr 2007 07:48:34 -0400 To: Tony Li , John Day From: John Day Subject: Re: [arch-d] Benefits of identity/location separation? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 1:40 -0400 2007/04/25, Tony Li wrote: >On Apr 24, 2007, at 9:02 PM, John Day wrote: > >>As we both know solving the loc/id split is not the whole problem. > > >John, > >What would you say is "the whole problem"? RFC 1498. You need another identifier. Just having points of attachments and application names isn't enough. The loc/id split characterization points at a solution space that won't scale. But this is well understood. One could even say it is basic to CS. ;-) > >>However, I am more concerned by the responses that don't see that >>there is a problem that needs to be solved. This is one of several >>fundamental problems we have known about for 35 years that remain >>unresolved. It begins to look more and more like the IETF/Internet >>has acquired a mind set more like the phone companies in 1970s than >>networking of the 1970s. > > >I think it's unfair to paint the entire IETF this way. There are >those that are still unconvinced. I find it telling that those that >are unconvinced are not those who will be called upon to fix things >when we get to a full-fledged 'crisis'. I agree. We have known about this problem since 1972. We had a chance to fix it 15 years ago and refused. It is long past time to do it. We need to be more proactive. When you build a house, you don't wait until it looks like rain to think about what a roof should look like. If you do, then you just throw something up that takes care of this shower, but may be completely inadequate for the next storm. I am concerned that we have become more like the phone companies of the 1970s than the networking of the 1970s. While I empathize with your comment about DNS being a dessert topping and a floor wax ;-), I am also concerned that we need to work on reducing the "parts count" rather than increasing it. This thing is getting more and more unwieldy. It is starting to feel like all of those add-ons to DOS years ago, rather than new things that just nicely fit in. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 10:08:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiAx-0000RO-Vz; Wed, 25 Apr 2007 10:08:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiAw-0000RE-Su for architecture-discuss@ietf.org; Wed, 25 Apr 2007 10:08:54 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiAv-0000z6-LN for architecture-discuss@ietf.org; Wed, 25 Apr 2007 10:08:54 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5B9E4872CC; Wed, 25 Apr 2007 10:08:53 -0400 (EDT) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Benefits of identity/location separation? Message-Id: <20070425140853.5B9E4872CC@mercury.lcs.mit.edu> Date: Wed, 25 Apr 2007 10:08:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day >>> As we both know solving the loc/id split is not the whole problem. >> What would you say is "the whole problem"? > RFC 1498. You need another identifier. Just having points of > attachments and application names isn't enough. You've got me thorougly confused - and I suspect others as well! I thought a significant ancillary point of the location/identity split was the the two different names would not only have different semantics (location versus identity), but would also name *two different classes of objects* - to wit, interfaces and "stacks". (I'm going to totally skip the whole debate on whether or not, with a blank-sheet design, you'd even want to name stacks - we don't have a blank sheet.) Were you assuming the two kinds of names would name the same class of objects (and if so, what)? What is the advantage (if any) in doing that? If not, what classes of objects did you think they named, and what additional class of objects would be like to see explicitly recognized and named? > The loc/id split characterization points at a solution space that won't > scale. This also I don't understand. Could you give us some more detail? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 10:37:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgid0-00059r-QD; Wed, 25 Apr 2007 10:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgicy-00059l-7e for architecture-discuss@ietf.org; Wed, 25 Apr 2007 10:37:52 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgicw-0006KX-UO for architecture-discuss@ietf.org; Wed, 25 Apr 2007 10:37:52 -0400 Received: from [10.0.1.48] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20070425143748b12008n8l7e>; Wed, 25 Apr 2007 14:37:50 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070425140853.5B9E4872CC@mercury.lcs.mit.edu> References: <20070425140853.5B9E4872CC@mercury.lcs.mit.edu> Date: Wed, 25 Apr 2007 10:37:44 -0400 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Benefits of identity/location separation? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org ;-) My understanding of loc/id split given the proposals that purport to address it and the discussions here and elsewhere is that when interpreted in terms of RFC 1498; The loc is a point of attachment address and the id is seems to be an application name since it is always location-independent Strictly speaking it is probably more an "application-protocol-instance-name" rather than an application name since it seems to identify a single flow/connection/communication to an application. Although in some proposals the id seems to be a "transport address" (whatever that could be) but is still location-independent. If what you mean by "stack name" is what I think you mean by stack name, ;-) then I think they need to be location-dependent in some way without being route dependent. This being what 1498 calls node *address.* Not a node name. Then I guess if you think "stack name" is node address, then I think it has the wrong properties! ;-) And we are in for scaling problems. That clearer? ;-) John At 10:08 -0400 2007/04/25, Noel Chiappa wrote: > > From: John Day > > >>> As we both know solving the loc/id split is not the whole problem. > > >> What would you say is "the whole problem"? > > > RFC 1498. You need another identifier. Just having points of > > attachments and application names isn't enough. > >You've got me thorougly confused - and I suspect others as well! I thought a >significant ancillary point of the location/identity split was the the two >different names would not only have different semantics (location versus >identity), but would also name *two different classes of objects* - to wit, >interfaces and "stacks". > >(I'm going to totally skip the whole debate on whether or not, with a >blank-sheet design, you'd even want to name stacks - we don't have a blank >sheet.) > >Were you assuming the two kinds of names would name the same class of objects >(and if so, what)? What is the advantage (if any) in doing that? >If not, what classes of objects did you think they named, and what additional >class of objects would be like to see explicitly recognized and named? > > > The loc/id split characterization points at a solution space that won't > > scale. > >This also I don't understand. Could you give us some more detail? > > Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 12:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgjvs-0004KH-OH; Wed, 25 Apr 2007 12:01:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgjvs-0004Jp-1M for architecture-discuss@ietf.org; Wed, 25 Apr 2007 12:01:28 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hgjvo-000620-JH for architecture-discuss@ietf.org; Wed, 25 Apr 2007 12:01:25 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 12CF6872DE; Wed, 25 Apr 2007 12:01:22 -0400 (EDT) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Benefits of identity/location separation? Message-Id: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> Date: Wed, 25 Apr 2007 12:01:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day > The loc is a point of attachment address Yes; it's also commonly called the interface "address". (And BTW I don't like to use the term "address", because to too many people it means "IPvN address", i..e. something with very complex/mixed semantics.) > the id is seems to be an application name .. Strictly speaking it is > probably more an "application-protocol-instance-name" rather than an > application name since it seems to identify a single > flow/connection/communication to an application. Although in some > proposals the id seems to be a "transport address" (whatever that > could be) No, as far as I know, most people think it names a host/stack, i.e. an instance of a group of transports (TCP, UDP, etc), and all the connections of that group instance. As John Leslie pointed out, this is yet *another* axis of confusion with IPvN addresses - not only location/identity (semantics of name), but also interface/host (what is named). > If what you mean by "stack name" is what I think you mean by stack > name, ;-) then I think they need to be location-dependent in some way > without being route dependent. First, I disagree that stack-names need to be location-dependent. Why would you want that, iff interface-name (PoA-names) are also location-dependent? Second, location-names in general (other than source routes) try to be location-dependent without being route dependent. To give a simple example of this, you can use them to say what the destination is, but from any location in the network. Also, in a classical ideal routing architecture, no place in the network would have more than one location-name. (This is equivalent to saying that, at any given layer of abstraction naming, abstraction boundaries constructed around portions of the graph do, or do not, overlap. If they do overlap, any location in that overlap can have more than one location-name.) And even if a location did have more than one location-name, those location-names would be route-independent (i.e. traffic from one location to another would take the same path no matter which location-name(s) were used). In real networks (especially ones that are much, much bigger than the ones Jerry had to look at when he did 1498), *neither* of these is true any longer. So the concept of "location-dependent ... without being route dependent" is no longer applicable - *anything* which is location-name-dependent is inherently no longer route-independent. > This being what 1498 calls node *address.* Not a node name. I haven't read 1498 recently, but it's rather old (the original dates to 1982, and it's possible that our understanding has become more subtle since then. As one example, I long ago decided that at the level above interfaces (PoA's) we should be naming stacks, not physical machines. So I don't agree that giving stacks/hosts names which include their location is a good idea - in fact, I would extremely strenuously disagree. > Then I guess if you think "stack name" is node address, then I think > it has the wrong properties! ;-) And we are in for scaling problems. And I still have no clue whatsoever that these scaling problems might be. Please expand your allusion. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 19:07:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgqaW-0005UN-Qe; Wed, 25 Apr 2007 19:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgqaV-0005Tp-5w for architecture-discuss@ietf.org; Wed, 25 Apr 2007 19:07:51 -0400 Received: from ndjsbar01.ndc.nasa.gov ([198.120.25.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgqYx-0000GK-JG for architecture-discuss@ietf.org; Wed, 25 Apr 2007 19:06:18 -0400 Received: from ndjsxgw02.ndc.nasa.gov (ndjsxgw02.ndc.nasa.gov [129.166.32.112]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id F33F92D1F8B; Wed, 25 Apr 2007 18:06:13 -0500 (CDT) Received: from NDJSEVS15.ndc.nasa.gov ([129.166.32.125]) by ndjsxgw02.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 18:06:13 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Apr 2007 18:05:30 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NASA Exploration Program - Netcentric Operations - Request for Information Thread-Index: AceHZwLMttIvx6olR/aYmTgdsPwHqQ== From: "Ivancic, William D. (GRC-RCN0)" To: , , X-OriginalArrivalTime: 25 Apr 2007 23:06:13.0787 (UTC) FILETIME=[523836B0:01C7878E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [arch-d] NASA Exploration Program - Netcentric Operations - Request for Information X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org NASA's Constellation Program has decided to implement a space-based network centric operations architecture. This is good. However, the requirements are not always well founded. It would greatly benefit NASA if experts in networking and security could comment - particularly on the Command, Control, Communication and Information (C3I) Interoperability Specification (Volume 1) and the Data Exchange Protocol (Volume 5). Whatever decisions are made today will affect space-communications for the next 50 to 75 years. Note, we are still using 1970's technology on Shuttle and Station. Thus, any constructive criticism will be appreciated. Some areas that would be good to get feedback on include: * Starting with IPv4 rather than IPv6. NASA has, for all practical purposes, no IPv4 flying today, to a move to IPv6 today would mean no transition whereas implementing IPv4 would result in a period of transition. * The proposed IPv4 addressing scheme.=20 * The call for Protocol Enhancing Proxies (PEPs). The going in thought is that most communication would be via UDP and even Delay/Disruption Tolerant Network (DTN) protocols, so PEPs will not really help. * IPsec is the baseline security mechanism. There are requirements for IKE or IKEv2 for space-base systems. IKE and IKEv2 system will not operate over unidirectional links and use a decent amount of bandwidth to negotiate security associations. This is problematic over unidirectional links and for extremely low bandwidth links such as 24 kbps, 72 kbps. * Baseline is static routing rather than dynamic routing. Many within NASA believe that static routes are easier to manage than dynamic routes. =20 * Comments on protocols that may not be wise to deploy and alternative architectures or protocols. Of particular interest is what will or will not operate in off-nominal situations (unidirectional links, low bandwidth links, high delay links). =20 =3D=3D=3D=3D=3D=3D NASA has issued a Request for Information (RFI) regarding the Exploration Initiative's Constellation Program's Communications, Command, Control and Information (C3I) activities, including=20 1. Request for comments on the C3I Interoperability Specification Volumes 1 and 5 2. Request for information on available communications concepts and capabilities 3. Request for information on available commercial products for space vehicle command and control The RFI was released this week and can be found at the following URL. Note that, per NASA/JSC policy, you will be prompted to request a user-id and password so that NASA has a record of who has accessed the documents. This is meant to be a simple process. http://prod.nais.nasa.gov/cgi-bin/eps/synopsis.cgi?acqid=3D124099 Please note, comments should be sent to the point of contact identified in the RFI. ****************************** Will Ivancic _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 25 20:50:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgsBl-00008D-AH; Wed, 25 Apr 2007 20:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgsBj-000088-J7 for architecture-discuss@ietf.org; Wed, 25 Apr 2007 20:50:23 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgsBh-00010n-Vc for architecture-discuss@ietf.org; Wed, 25 Apr 2007 20:50:23 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id MAA28099; Thu, 26 Apr 2007 12:50:16 +1200 In-Reply-To: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] Benefits of identity/location separation? Date: Thu, 26 Apr 2007 12:51:22 +1200 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 26/04/2007, at 4:01 AM, Noel Chiappa wrote: >> From: John Day > >> the id is seems to be an application name .. Strictly speaking it is >> probably more an "application-protocol-instance-name" rather than an >> application name since it seems to identify a single >> flow/connection/communication to an application. Although in some >> proposals the id seems to be a "transport address" (whatever that >> could be) > > No, as far as I know, most people think it names a host/stack, i.e. an > instance of a group of transports (TCP, UDP, etc), and all the > connections > of that group instance. > > As John Leslie pointed out, this is yet *another* axis of confusion > with > IPvN addresses - not only location/identity (semantics of name), > but also > interface/host (what is named). I think the HIP implementers are quite clear on what we think is identified: whatever the administrator wants. It could be the endpoint of anything from the entire host's connection bundle, to an application's connections, to a single connection. In practice, by default it ends up being the first, but that is not necessary either in theory, or in practice. I recall a hallway discussion about parallel OSes where process migration is possible, and how that would interact with HIP, and we concluded that if an identity were bound to an application, it is entirely reasonable for that identity to follow the process around... and having HIP there makes that somewhat easier. Andrew _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Apr 26 02:50:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgxoU-0003r5-02; Thu, 26 Apr 2007 02:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgxoS-0003qZ-LN for architecture-discuss@ietf.org; Thu, 26 Apr 2007 02:50:44 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgxoR-0008F0-5M for architecture-discuss@ietf.org; Thu, 26 Apr 2007 02:50:44 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3Q6ofrD144416 for ; Thu, 26 Apr 2007 06:50:41 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3Q6oflj3965090 for ; Thu, 26 Apr 2007 08:50:41 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3Q6oe5b028452 for ; Thu, 26 Apr 2007 08:50:41 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3Q6oep4028443; Thu, 26 Apr 2007 08:50:40 +0200 Received: from [9.4.210.19] ([9.4.210.19]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA388804; Thu, 26 Apr 2007 08:50:39 +0200 Message-ID: <46304BC9.2080008@zurich.ibm.com> Date: Thu, 26 Apr 2007 08:50:49 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew McGregor Subject: Re: [arch-d] Benefits of identity/location separation? References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer Internet Standards and Technology IBM On 2007-04-26 02:51, Andrew McGregor wrote: > > On 26/04/2007, at 4:01 AM, Noel Chiappa wrote: > >>> From: John Day >> >>> the id is seems to be an application name .. Strictly speaking it is >>> probably more an "application-protocol-instance-name" rather than an >>> application name since it seems to identify a single >>> flow/connection/communication to an application. Although in some >>> proposals the id seems to be a "transport address" (whatever that >>> could be) >> >> No, as far as I know, most people think it names a host/stack, i.e. an >> instance of a group of transports (TCP, UDP, etc), and all the >> connections >> of that group instance. >> >> As John Leslie pointed out, this is yet *another* axis of confusion with >> IPvN addresses - not only location/identity (semantics of name), but also >> interface/host (what is named). > > I think the HIP implementers are quite clear on what we think is > identified: whatever the administrator wants. It could be the endpoint > of anything from the entire host's connection bundle, to an > application's connections, to a single connection. In practice, by > default it ends up being the first, but that is not necessary either in > theory, or in practice. > > I recall a hallway discussion about parallel OSes where process > migration is possible, and how that would interact with HIP, and we > concluded that if an identity were bound to an application, it is > entirely reasonable for that identity to follow the process around... > and having HIP there makes that somewhat easier. I think this is pretty much standard practice in some of today's Virtual IP(v4) Address solutions. And imagine a large server farm of the future, with a pool of physical network interfaces shared by a larger pool of (multicore) CPUs in a big rack. With a plethora of IPv6 addresses or HITs available, you can easily imagine that the correspondence between an identifier and an interface or CPU becomes completely fluid. An instance of IP might well be dedicated to as little as a single application session in such a system. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Apr 26 06:58:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1gE-0005my-B3; Thu, 26 Apr 2007 06:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1gD-0005mh-5P for architecture-discuss@ietf.org; Thu, 26 Apr 2007 06:58:29 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh1gB-00034p-TH for architecture-discuss@ietf.org; Thu, 26 Apr 2007 06:58:29 -0400 Received: from [10.0.1.48] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <200704261058270120034cs9e>; Thu, 26 Apr 2007 10:58:27 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> Date: Thu, 26 Apr 2007 06:52:48 -0400 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Benefits of identity/location separation? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I am a bit pressed for time, but I hope this helps. If I have time later I will try to comment on what you said above. > > This being what 1498 calls node *address.* Not a node name. > >I haven't read 1498 recently, but it's rather old (the original dates to >1982, and it's possible that our understanding has become more subtle since >then. As one example, I long ago decided that at the level above interfaces >(PoA's) we should be naming stacks, not physical machines. So I don't agree >that giving stacks/hosts names which include their location is a good idea >- in fact, I would extremely strenuously disagree. Give 1498 a careful re-read. It is just as correct today as when it was written. There is one minor case that probably didn't exist when Saltzer wrote it that he missed (understandably). But if you include it, it turns out to be a very telling indicator of the general structure. As you re-read 1498, construct a logical model of the resulting architecture based on what it says not on what we think we have today. Then compare it to what we have today. One thing you should find is that based on what Saltzer writes, the minimum necessary scope of a point of attachment address is that it be unambiguous only between nearest neighbors. The scope of node addresses is greater, usually "global," but strictly speaking doesn't have to be. Take care, John > > > > Then I guess if you think "stack name" is node address, then I think > > it has the wrong properties! ;-) And we are in for scaling problems. > >And I still have no clue whatsoever that these scaling problems might be. >Please expand your allusion. > > Noel > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Apr 27 04:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLXM-0006ul-JJ; Fri, 27 Apr 2007 04:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLXL-0006uc-Ba for architecture-discuss@ietf.org; Fri, 27 Apr 2007 04:10:39 -0400 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhLXK-0004ql-TO for architecture-discuss@ietf.org; Fri, 27 Apr 2007 04:10:39 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l3R8Acto020470 for ; Fri, 27 Apr 2007 08:10:38 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3R8Acu02789550 for ; Fri, 27 Apr 2007 09:10:38 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3R8AbGF005575 for ; Fri, 27 Apr 2007 09:10:37 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3R8AbjH005567; Fri, 27 Apr 2007 09:10:37 +0100 Received: from [9.4.210.177] ([9.4.210.177]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA53414; Fri, 27 Apr 2007 10:10:34 +0200 Message-ID: <4631B004.3080209@zurich.ibm.com> Date: Fri, 27 Apr 2007 10:10:44 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: John Day Subject: Re: [arch-d] Benefits of identity/location separation? References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, > One thing you should find is that based on what Saltzer writes, the > minimum necessary scope of a point of attachment address is that it be > unambiguous only between nearest neighbors. I can readily believe that as a mathematical theorem. But the question is whether it's an operationally useful observation. > > The scope of node addresses is greater, usually "global," I don't think that's true, given the number of NATs deployed. I think usually "site-local" is the usual scope today. I think the interesting question, where Noel and I likely disagree, is whether having identifier == locator within site-local scope is a Good Thing or a Bad Thing. Brian > but strictly > speaking doesn't have to be. > > Take care, > John > >> >> >> > Then I guess if you think "stack name" is node address, then I >> think >> > it has the wrong properties! ;-) And we are in for scaling >> problems. >> >> And I still have no clue whatsoever that these scaling problems might be. >> Please expand your allusion. >> >> Noel >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Apr 27 04:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLuA-00039h-N7; Fri, 27 Apr 2007 04:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLu8-00038B-4W for architecture-discuss@ietf.org; Fri, 27 Apr 2007 04:34:12 -0400 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhLu6-0000mG-Mp for architecture-discuss@ietf.org; Fri, 27 Apr 2007 04:34:12 -0400 Received: from webmail16.lax.untd.com (webmail16.lax.untd.com [10.131.27.156]) by smtpout05.lax.untd.com with SMTP id AABDDDN9NATC68J2 for (sender ); Fri, 27 Apr 2007 01:27:24 -0700 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPcINWq1SZzwVj5ey63dR+d4KblggXwYCnA== Received: (from fergdawg@netzero.net) by webmail16.lax.untd.com (jqueuemail) id MLBRGNQT; Fri, 27 Apr 2007 01:27:12 PDT Received: from [76.103.55.43] by webmail16.lax.untd.com with HTTP: Fri, 27 Apr 2007 08:26:31 GMT X-Originating-IP: [76.103.55.43] Mime-Version: 1.0 From: "Fergie" Date: Fri, 27 Apr 2007 08:26:31 GMT To: brc@zurich.ibm.com Subject: Re: [arch-d] Benefits of identity/location separation? X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070427.012712.751.1189192@webmail16.lax.untd.com> X-ContentStamp: 6:3:3391603937 X-MAIL-INFO: 10955c28a8185c1895f895d9c9386d4c4c8549414c7ce1c9a5cd7558119d9d5c693dad28 X-UNTD-Peer-Info: 10.131.27.156|webmail16.lax.untd.com|webmail16.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu, jeanjour@comcast.net X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -- Brian E Carpenter wrote: >> The scope of node addresses is greater, usually "global," = > >I don't think that's true, given the number of NATs deployed. >I think usually "site-local" is the usual scope today. I'm not actually sure that is even really an issue, really. >I think the interesting question, where Noel and I likely disagree, >is whether having identifier =3D=3D locator within site-local scope >is a Good Thing or a Bad Thing. Probably both. It would "be nice" if there were some sort of sliding window to encompass "variableness" of the loc/id-ness. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Apr 27 07:03:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOE9-0002Tx-3K; Fri, 27 Apr 2007 07:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOE7-0002Tr-P7 for architecture-discuss@ietf.org; Fri, 27 Apr 2007 07:02:59 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOE6-0004Z2-IQ for architecture-discuss@ietf.org; Fri, 27 Apr 2007 07:02:59 -0400 Received: from [10.0.1.29] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc13) with ESMTP id <20070427110252013003et35e>; Fri, 27 Apr 2007 11:02:58 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <4631B004.3080209@zurich.ibm.com> References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> <4631B004.3080209@zurich.ibm.com> Date: Fri, 27 Apr 2007 06:54:51 -0400 To: Brian E Carpenter , John Day From: John Day Subject: Re: [arch-d] Benefits of identity/location separation? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:10 +0200 2007/04/27, Brian E Carpenter wrote: >John, > >>One thing you should find is that based on what Saltzer writes, the >>minimum necessary scope of a point of attachment address is that >>it be unambiguous only between nearest neighbors. > >I can readily believe that as a mathematical theorem. But the question >is whether it's an operationally useful observation. It can be. Depends on what the lower layer is. The point was that Saltzer's paper is outlining fundamental principles. It is only by understanding the fundamental principles that we gain insight into what is really going on here, which then further indicates the nature of the solution. >> >>The scope of node addresses is greater, usually "global," > >I don't think that's true, given the number of NATs deployed. >I think usually "site-local" is the usual scope today. Precisely. Which is why I said "usually." If the node address space is not global, then one must relay based on the application name which is global. >I think the interesting question, where Noel and I likely disagree, >is whether having identifier == locator within site-local scope >is a Good Thing or a Bad Thing. The problem with the Internet is that it has half an addressing architecture. But then we have known that for 35 years. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Apr 27 12:12:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT3e-0005ss-Nr; Fri, 27 Apr 2007 12:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT3c-0005oD-Uj for architecture-discuss@ietf.org; Fri, 27 Apr 2007 12:12:28 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhT3c-0006L2-Fo for architecture-discuss@ietf.org; Fri, 27 Apr 2007 12:12:28 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 5E32C1CC1F; Fri, 27 Apr 2007 12:12:28 -0400 (EDT) Date: Fri, 27 Apr 2007 12:12:28 -0400 From: John Leslie To: Brian E Carpenter Subject: Re: [arch-d] Benefits of identity/location separation? Message-ID: <20070427161228.GB83989@verdi> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <462DA425.70705@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462DA425.70705@zurich.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian E Carpenter wrote: > > draft-carpenter-idloc-map-cons-00.txt Brian deserves some serious discussion of this. (It has taken a while to digest it all...) First, he states some good definitions: ] ] A stack is defined as one participant or the process on one side of ] an end-to-end communication. (quoted from NSRG) ]... ] Locator: A binary quantity (not necessarily an IP Address) that can ] be used by a routing or forwarding device to decide where to send a ] packet. ] ] Identifier: A binary quantity (not necessarily an IP Address) that ] can be used by a Stack "A" to uniquely identify another Stack "B" ] both for bilateral communication and for informing a third Stack "C" ] that it should communicate with stack "B". We need to keep these firmly in mind. It's still a somewhat open issue exactly _what_ we mean an "identifier" to identify; but I'll proceed as if we had agreed to ID a "stack". IMHO, the major purpose of a stack ID is to give assurance to the other end of a communication that it's talking to the right entity. There are various cases in current-day TCP/IP where the IP Address is used for that, on the theory that we know the packets we send are being directed there; we should be looking for something stronger. Brian quotes RFC2101: ] ] Due to dynamic address allocation and increasingly frequent ] network renumbering, temporal uniqueness of IPv4 addresses is no ] longer globally guaranteed, which puts their use as identifiers ] into severe question. Due to the proliferation of Intranets, ] spatial uniqueness is also no longer guaranteed across routing ] realms... Clearly, IPv4 addresses are becoming less useful as Identifiers. ] The IAB feels that... the transition to IPv6 would be an ideal ] occasion to provide upper layer end-to-end protocols with temporally ] unique identifiers. How close we've come in the intervening ten years is in question. Brian observes: ] ] ... we can loosely divide upper layer implementations (transport layer ] and above) into two classes: ] 1. Those that use a socket API, or the equivalent, on the ] traditional assumption that an IP Address is simultaneously a ] unique Locator and a unique Identifier... ] 2. Those that avoid this assumption, for example by creating their ] own namespace or relying completely on the DNS. Brian predicts confusion within traditional socket-API implementations when Locator and ID are no longer the same. Avoiding this confusion weighs heavily on the remainder of his draft. But we're discussing architecture: we don't need to retreat at the first hint of confusion. There's no reason a (suitably evolved) socket API couldn't distinguish Locator from ID, defining the socket by the IDs while constructing packets with the locators. Brian continues: ] ] The predominant assumption is that the IP Address of a network element ] (router, switch, bridge, server or user device) both identifies and ] locates it. This is pretty much true by definition for Layer 3 (which should remain blissfully unaware of all the higher-layer gadgets which break the assumption). ] The assumption generally made by operations staff is that there is ] a single namespace; the notion of an identifier-locator split is ] unknown. True, but irrelevant. Brian goes on to contend: ] ] that no solution which removes the ability of upper layers and ] management systems to treat the Identifier and Locator Namespaces as ] identical within some well defined context is deployable in practice. (His wordsmithing makes this unassailable as written...) ] ... at the level of packet transmission, and the network elements and ] Stacks that handle them, we need unified Namespaces within certain ] Namespace Contexts. I've already stipulated this for Layer 3; but that doesn't mean we need unified Namespaces within everything that interfaces to Layer 3. ] In practice this means that network elements and Stacks need to be ] able to treat things that look like an IP Address as they do today, ] but with a clear definition of the context within which Identifiers ] and Locators are the same thing, and of the contexts in which they ] are not. Un-evolved Stacks _will_ treat IP Addresses that way; that's not our concern when discussing architecture. ] Within its site, A must have an Identifier and Locator that match ] 1:1... Here, Brian and I part ways. He wants to split by physical position; I want to split by Layer. ] When communicating with B, A must provide an Identifier that B can ] rely on, and conversely. Agreed. ] A must also be able to communicate with C on the same basis, and ] furthermore tell C that it may communicate with B as part of the same ] application. Agreed, but we must be careful not to read too much into this. By communicating an ID to C, A does _not_ undertake to tell C _how_ to reach B -- only how to tell _whether_ C has reached B. Finding a locator is out-of-band, and should be subject to B's security policies. Brian concludes: ] ] o On-site, Identifiers and Locators should not be split. His opinion; not mine. ] o To go off-site, it is necessary to know which Locator leads ] towards a given Identifier. Either the sending Stack or its ] router could know this. Ideally, the interface to Layer 3 would find _a_ locator. There are many possibilities during transition to a new architecture. ] o The Identifier of the sending Stack must be delivered unchanged to ] the receiving Stack. I agree (and would further suggest that IDs be tamper-resistant). ] o It must be possible to refer third party Stacks to a remote ] Stack's Identifier. Agreed. Brian goes on to discuss mapping locators to and from IDs. In this email, I'll limit myself to stating that if _every_ ID must publicly map to a locator, and vice-versa, we're not talking about a loc/ID "split". Thus I'd rather not go into detail about concerns with Brian's mapping proposals (yet). -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Apr 27 14:49:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVVZ-0006JT-4m; Fri, 27 Apr 2007 14:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVVX-0006IY-Nt for architecture-discuss@ietf.org; Fri, 27 Apr 2007 14:49:27 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVVW-00044u-D6 for architecture-discuss@ietf.org; Fri, 27 Apr 2007 14:49:27 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3RInNIE006951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 11:49:24 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3RInL6P020273; Fri, 27 Apr 2007 11:49:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4631B004.3080209@zurich.ibm.com> References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> <4631B004.3080209@zurich.ibm.com> Date: Fri, 27 Apr 2007 11:49:21 -0700 To: Brian E Carpenter , John Day From: Ted Hardie Subject: Re: [arch-d] Benefits of identity/location separation? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:10 AM +0200 4/27/07, Brian E Carpenter wrote: >>The scope of node addresses is greater, usually "global," > >I don't think that's true, given the number of NATs deployed. >I think usually "site-local" is the usual scope today. > >I think the interesting question, where Noel and I likely disagree, >is whether having identifier == locator within site-local scope >is a Good Thing or a Bad Thing. I think "site-local" has been defined in terms of administrative boundaries rather than the routing system. During the discussion of what became RFC 4193, there was a fairly heated exchange over the value of nailing down what a "site" is. The unwillingness to do that in terms of the routing system was pretty telling. As it stands, I believe there are lots of things that are definable as "sites" in 4193 or RFC 1918 terms that are not routing scopes at all. They are crunchy-on-the-outside/soft-in-the-middle policy scopes in firewalls, NATs, and the minds of admins. Having our addressing system and our routing system additionally strained by this disjuncture has been no help in the past, and I hope is not a design goal of our future. regards, Ted Hardie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 04:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRTC-0005cf-8r; Mon, 30 Apr 2007 04:42:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRTA-0005a5-SO for architecture-discuss@ietf.org; Mon, 30 Apr 2007 04:42:52 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiRTA-0008CV-DT for architecture-discuss@ietf.org; Mon, 30 Apr 2007 04:42:52 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3U8gptd180232 for ; Mon, 30 Apr 2007 08:42:51 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3U8gpcl3985590 for ; Mon, 30 Apr 2007 10:42:51 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3U8gemu005670 for ; Mon, 30 Apr 2007 10:42:41 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3U8genE005534; Mon, 30 Apr 2007 10:42:40 +0200 Received: from [9.146.222.171] (chvb1001.de.ibm.com [9.146.222.171]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA163808; Mon, 30 Apr 2007 10:42:28 +0200 Message-ID: <4635ABFF.2090005@zurich.ibm.com> Date: Mon, 30 Apr 2007 10:42:39 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [arch-d] Benefits of identity/location separation? References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> <4631B004.3080209@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: architecture-discuss@ietf.org, Noel Chiappa , John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 2007-04-27 20:49, Ted Hardie wrote: > At 10:10 AM +0200 4/27/07, Brian E Carpenter wrote: >>> The scope of node addresses is greater, usually "global," >> I don't think that's true, given the number of NATs deployed. >> I think usually "site-local" is the usual scope today. >> >> I think the interesting question, where Noel and I likely disagree, >> is whether having identifier == locator within site-local scope >> is a Good Thing or a Bad Thing. > > I think "site-local" has been defined in terms of administrative boundaries > rather than the routing system. During the discussion of what became RFC > 4193, there was a fairly heated exchange over the value of nailing down > what a "site" is. The unwillingness to do that in terms of the routing system > was pretty telling. As it stands, I believe there are lots of things that are definable > as "sites" in 4193 or RFC 1918 terms that are not routing scopes at all. They > are crunchy-on-the-outside/soft-in-the-middle policy scopes in firewalls, NATs, > and the minds of admins. Having our addressing system and our routing > system additionally strained by this disjuncture has been no help in the past, > and I hope is not a design goal of our future. > regards, > Ted Hardie I think that is completely correct, and at the heart of where John Leslie has quarrels with my draft. Firstly let me say that when I update the draft, I will try to bring the points that John raised to the fore, and restructure the draft to show that there is a fork in the road to be chosen. Then, I have to say that I believe that design for the future is strongly constrained by the past. As the RRG draft says: Since solutions that are not deployable are simply academic exercises, solutions are required to be deployable. Furthermore, given the extensive deployed base of today's Internet, a solution is required to be incrementally deployable. I see no possible way round this. I have to say that strongly affects my view of which fork in the road we should take. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 07:49:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUNL-0006gB-2W; Mon, 30 Apr 2007 07:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUNJ-0006Yl-9y for architecture-discuss@ietf.org; Mon, 30 Apr 2007 07:49:01 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiUNI-0006Xg-1U for architecture-discuss@ietf.org; Mon, 30 Apr 2007 07:49:01 -0400 Received: from [10.0.1.5] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20070430114858m130033u7he>; Mon, 30 Apr 2007 11:48:59 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <4635ABFF.2090005@zurich.ibm.com> References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> <4631B004.3080209@zurich.ibm.com> <4635ABFF.2090005@zurich.ibm.com> Date: Mon, 30 Apr 2007 07:46:24 -0400 To: Brian E Carpenter , Ted Hardie From: John Day Subject: Re: [arch-d] Benefits of identity/location separation? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org, Noel Chiappa , John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >Then, I have to say that I believe that design for the future is strongly >constrained by the past. As the RRG draft says: I would disagree. I would say that only the next step is strongly constrained by the past. Much of the problem here is that there is no clear idea of the goal. As long as that is the case, all of this is nothing more than wandering lost in the woods. There does not even seem to be a clear idea of what North is let alone how to get out of the woods. > > Since solutions that are not deployable are simply academic > exercises, solutions are required to be deployable. Furthermore, > given the extensive deployed base of today's Internet, a solution is > required to be incrementally deployable. Yes, indeed everything must be ultimately deployable. However, some things may take more than one step. But I do find this characterization that the Internet is "too big" to be changed to be bothersome. We have been hearing this since the early 1980s. Of course, by comparison changes then would have been trivial compared to now. The only for which this rationalization can apply is that the Internet is near the end of its growth, rather than still having considerable growth to go. I tend to be in the later camp. We aren't even close to the end of its growth, which makes the idea that we can build and maintain something that the world economy is now dependent upon without a clear picture of where it needs to be evolving to but can only react to crises of its limitations discovered 35 years after the fact is both frightening and irresponsible. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 07:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUU8-0004df-DO; Mon, 30 Apr 2007 07:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUU7-0004Sa-Cc for architecture-discuss@ietf.org; Mon, 30 Apr 2007 07:56:03 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiUU6-0008IF-0a for architecture-discuss@ietf.org; Mon, 30 Apr 2007 07:56:03 -0400 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 0B9C617F1D; Mon, 30 Apr 2007 13:56:00 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Apr 2007 13:55:59 +0200 To: Brian E Carpenter ,Ted Hardie From: JFC Morfin Subject: Re: [arch-d] Benefits of identity/location separation? In-Reply-To: <4635ABFF.2090005@zurich.ibm.com> References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> <4631B004.3080209@zurich.ibm.com> <4635ABFF.2090005@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070430115600.0B9C617F1D@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: John Day , architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:42 30/04/2007, Brian E Carpenter wrote: I see no possible way round this. I have to say that strongly affects my >view of which fork in the road we should take. This means that you think we go from a legacy monolith to another monolith by way of evolution? Not from a situation A to a situation B by way of adaptating whatever is necessary, even if one has to adapt from a single monolith architectural understanding and acknowledge the multilith nature of the need? "The principle of constant change is perhaps the only principle of the Internet that should survive indefinitely." (RFC 1958). This does not only affect issues within the Internet current approach (as defined in RFC 3935 core values), but may lead to change these very core values. At least one is to be changed (from "decentralised" to "distributed"). You say "fork in the road", why not to free us once for goo and "take-off". Switching from "inter-choice" to "multi-possibility". I am afraid that all this identity/location debate forgets many options. There is some kind of interactive unity between understanding your need, identifying who can address is, where that who is located, reaching it, staying connected, and keeping your need answered. This is a constant mix of fixity (the hardware/bandwidth layer), mobility (the software/logic layer), virtuality (the rendered service) and continuity (of the pertinent service being obtained), the whole thing being dependent upon the constraints/advantages of the followed access path (s) and resulting costs. For example (the reason why I am adamant on language issues), what is the need for a user to access a host he cannot understand because it uses another language. Or if he has no login/password on it. Or the proper services is not offered there (ex. difference between IN and MX). Or if his type of traffic is being filtered out or downgraded to a lesser quality transport service. At least identity/location/accessibility should be covered. But accessibility can include a very large number of issues interacting with identity and location. For example why do Web.2.0 applications use zero second TTL to constantly adapt the address of the source of web elements? Is the identity or the localtion which is changing in that rotational resulting addresses jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 08:39:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVAU-00084w-HG; Mon, 30 Apr 2007 08:39:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVAS-00084r-Sn for architecture-discuss@ietf.org; Mon, 30 Apr 2007 08:39:48 -0400 Received: from ndjsbar01.ndc.nasa.gov ([198.120.25.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiVAR-0002za-3i for architecture-discuss@ietf.org; Mon, 30 Apr 2007 08:39:48 -0400 Received: from ndjsxgw02.ndc.nasa.gov (ndjsxgw02.ndc.nasa.gov [129.166.32.112]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id E1A1F3044A0; Mon, 30 Apr 2007 07:39:45 -0500 (CDT) Received: from NDJSEVS15.ndc.nasa.gov ([129.166.32.125]) by ndjsxgw02.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 07:39:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Benefits of identity/location separation? Date: Mon, 30 Apr 2007 07:38:57 -0500 Message-ID: In-Reply-To: <4635ABFF.2090005@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Benefits of identity/location separation? Thread-Index: AceLA5oO8FYS1YqeRi23P/FPtZ/Y/gAIE17w From: "Ivancic, William D. (GRC-RCN0)" To: "Brian E Carpenter" , "Ted Hardie" X-OriginalArrivalTime: 30 Apr 2007 12:39:45.0750 (UTC) FILETIME=[A211AF60:01C78B24] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: John Day , architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I have been seeing more and more solutions (or at least proposed solutions) regarding identity/location separation (i.e. shim6, hip, etc...). I believe it is extremely important that the identity/location separator solution work in concert with security solutions such as IPsec or whatever IPsec may become of that for identity/location separation. Obviously for mobile and multi-homed systems, the address and the identity are no longer one in the same. Running IPsec in such environments is problematic at best. Will Ivancic _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 08:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVNr-0007YT-0W; Mon, 30 Apr 2007 08:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVNp-0007YO-Ea for architecture-discuss@ietf.org; Mon, 30 Apr 2007 08:53:37 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiVNn-0006zd-St for architecture-discuss@ietf.org; Mon, 30 Apr 2007 08:53:37 -0400 Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3UCrWZ2029016 for ; Mon, 30 Apr 2007 12:53:33 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UCrWNO005682 for ; Mon, 30 Apr 2007 08:53:32 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3UCrR9e006469; Mon, 30 Apr 2007 08:53:28 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l3UCrQqN006468; Mon, 30 Apr 2007 08:53:26 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 30 Apr 2007 08:53:26 -0400 From: Dan McDonald To: "Ivancic, William D. (GRC-RCN0)" Subject: Re: [arch-d] Benefits of identity/location separation? Message-ID: <20070430125326.GG5237@sun.com> References: <4635ABFF.2090005@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: Sun Microsystems, Inc. - Solaris Networking & Security X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, Apr 30, 2007 at 07:38:57AM -0500, Ivancic, William D. (GRC-RCN0) wrote: > I believe it is extremely important that the identity/location > separator solution work in concert with security solutions such as IPsec > or whatever IPsec may become of that for identity/location separation. Agreed. I *believe* most-if-not-all of the folks here in the audience understand that one can't blow off security anymore. I also believe IPsec, even as specified in RFC 430x, would be able to handle a ID/locator split. > Obviously for mobile and multi-homed systems, the address and the > identity are no longer one in the same. True... > Running IPsec in such environments is problematic at best. ...not true. Read the definition of a Security Association in RFC 4301: For an SA used to carry unicast traffic, the Security Parameters Index (SPI) by itself suffices to specify an SA. That certainly is agile in the face of an ID/locator split. I think I'd need to pull out too much disparate text, but IKEv2 (4306) calls out the traffic selectors explicitly, so two ends who don't specify locator selectors can communicate regardless. Thinking about it, an ID/locator split MAY lead to more flexibile security policy... "Ooooh, if I go over cloud X I have to worry about more snooping than I do if I go over cloud Y." Though in practice, I doubt clouds X or Y would be that much different. Dan _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 10:20:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWjE-0006gU-UX; Mon, 30 Apr 2007 10:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWjD-0006gP-5s for architecture-discuss@ietf.org; Mon, 30 Apr 2007 10:19:47 -0400 Received: from m6f095e42.tmodns.net ([66.94.9.111] helo=svcstsnq07.hotspot.t-mobile.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiWjA-0005ln-O7 for architecture-discuss@ietf.org; Mon, 30 Apr 2007 10:19:47 -0400 Received: from [10.240.72.79] (79.72.240.10.in-addr.arpa [10.240.72.79]) by svcstsnq07.hotspot.t-mobile.com (8.13.7+Sun/8.13.7) with ESMTP id l3UEIqXg026539; Mon, 30 Apr 2007 07:18:53 -0700 (PDT) In-Reply-To: <20070430125326.GG5237@sun.com> References: <4635ABFF.2090005@zurich.ibm.com> <20070430125326.GG5237@sun.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Merike Kaeo Subject: Re: [arch-d] Benefits of identity/location separation? Date: Mon, 30 Apr 2007 07:22:03 -0700 To: Dan McDonald X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: architecture-discuss@ietf.org, "Ivancic, William D. \(GRC-RCN0\)" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org IKEv2 and/or Mobike should be able to handle an ID/locator split [although I want to check the details to make sure that is absolutely the case] but can IPsec AH handle the ID/locator split? While there are camps that believe AH is deprecated, and of course you cannot use it with IPv4 NATs, there was a long discussion in IPv6 mailing lists (non-IETF) regarding requiring AH for specific use cases. There was some talk of requiring a 'new AH' to handle a future ID/locator split.... - merike On Apr 30, 2007, at 5:53 AM, Dan McDonald wrote: > On Mon, Apr 30, 2007 at 07:38:57AM -0500, Ivancic, William D. (GRC- > RCN0) wrote: >> I believe it is extremely important that the identity/location >> separator solution work in concert with security solutions such as >> IPsec >> or whatever IPsec may become of that for identity/location >> separation. > > Agreed. I *believe* most-if-not-all of the folks here in the audience > understand that one can't blow off security anymore. I also > believe IPsec, > even as specified in RFC 430x, would be able to handle a ID/locator > split. > >> Obviously for mobile and multi-homed systems, the address and the >> identity are no longer one in the same. > > True... > >> Running IPsec in such environments is problematic at best. > > ...not true. > > Read the definition of a Security Association in RFC 4301: > > For an SA used to carry unicast traffic, the Security Parameters > Index (SPI) by itself suffices to specify an SA. > > That certainly is agile in the face of an ID/locator split. I > think I'd need > to pull out too much disparate text, but IKEv2 (4306) calls out the > traffic > selectors explicitly, so two ends who don't specify locator > selectors can > communicate regardless. > > Thinking about it, an ID/locator split MAY lead to more flexibile > security > policy... "Ooooh, if I go over cloud X I have to worry about more > snooping > than I do if I go over cloud Y." Though in practice, I doubt > clouds X or Y > would be that much different. > > Dan > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 10:25:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWos-0000gI-Ss; Mon, 30 Apr 2007 10:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWor-0000g3-P9 for architecture-discuss@ietf.org; Mon, 30 Apr 2007 10:25:37 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiWoq-0006Xh-EI for architecture-discuss@ietf.org; Mon, 30 Apr 2007 10:25:37 -0400 Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3UEPZ3x028586 for ; Mon, 30 Apr 2007 14:25:35 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3UEPZ2p019774 for ; Mon, 30 Apr 2007 10:25:35 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3UEPWfa026705; Mon, 30 Apr 2007 10:25:32 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l3UEPWeL026704; Mon, 30 Apr 2007 10:25:32 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 30 Apr 2007 10:25:32 -0400 From: Dan McDonald To: Merike Kaeo Subject: Re: [arch-d] Benefits of identity/location separation? Message-ID: <20070430142532.GA26684@kebe.East.Sun.COM> References: <4635ABFF.2090005@zurich.ibm.com> <20070430125326.GG5237@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: Sun Microsystems, Inc. - Solaris Networking & Security X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, Apr 30, 2007 at 07:22:03AM -0700, Merike Kaeo wrote: > IKEv2 and/or Mobike should be able to handle an ID/locator split > [although I want to check the details to make sure that is absolutely > the case] but can IPsec AH handle the ID/locator split? Ahhh, now THAT's an interesting question. > While there are camps that believe AH is deprecated, and of course you > cannot use it with IPv4 NATs, there was a long discussion in IPv6 mailing > lists (non-IETF) regarding requiring AH for specific use cases. There was > some talk of requiring a 'new AH' to handle a future ID/locator split.... I'm not sure if a "new AH" would be needed, but rather a "new AH rules for new IP protocol". Assuming the ID/locator split is technically a new IP header (v9?), all one would need is a processing rule for AH that says "don't include the locator in the AH computation". If the split is a change to IPv6, then I suppose there could be an SA attribute (negotiated by IKE, or say an SADB_X_SAFLAG_ value for PF_KEY) that says "don't include locator part of IPv6 header". It shouldn't be that hard to make AH work in a post-split world. Protocol designers in the audience - please take note that AH still matters to some people. Dan _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 11:29:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXoy-0003yz-JE; Mon, 30 Apr 2007 11:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXox-0003ys-E4 for architecture-discuss@ietf.org; Mon, 30 Apr 2007 11:29:47 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXow-0000qE-2h for architecture-discuss@ietf.org; Mon, 30 Apr 2007 11:29:47 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3UFTTwI006113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Apr 2007 08:29:29 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3UFTSVe007311; Mon, 30 Apr 2007 10:29:28 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3UFTCHe006519; Mon, 30 Apr 2007 10:29:21 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 08:29:18 -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: [arch-d] Benefits of identity/location separation? Date: Mon, 30 Apr 2007 08:29:17 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED769@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Benefits of identity/location separation? Thread-Index: AceLA5oO8FYS1YqeRi23P/FPtZ/Y/gAIE17wAAX/4NA= References: <4635ABFF.2090005@zurich.ibm.com> From: "Templin, Fred L" To: "Ivancic, William D. \(GRC-RCN0\)" , "Brian E Carpenter" , "Ted Hardie" X-OriginalArrivalTime: 30 Apr 2007 15:29:18.0377 (UTC) FILETIME=[516D6190:01C78B3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Noel Chiappa , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > etc...). I believe it is extremely important that the identity/location > separator solution work in concert with security solutions such as IPsec > or whatever IPsec may become of that for identity/location separation. IPvLX has designed-in provisions for securing mechanisms. A new version of the draft is now available at: http://www.ietf.org/internet-drafts/draft-templin-ipvlx-07.txt Fred fred.l.templin@boeing.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 30 19:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HifKN-0001iF-T0; Mon, 30 Apr 2007 19:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HifKL-0001i5-70 for architecture-discuss@ietf.org; Mon, 30 Apr 2007 19:30:41 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HifKJ-0002bH-I4 for architecture-discuss@ietf.org; Mon, 30 Apr 2007 19:30:41 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id LAA04358; Tue, 1 May 2007 11:30:26 +1200 In-Reply-To: <20070430142532.GA26684@kebe.East.Sun.COM> References: <4635ABFF.2090005@zurich.ibm.com> <20070430125326.GG5237@sun.com> <20070430142532.GA26684@kebe.East.Sun.COM> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] Benefits of identity/location separation? Date: Tue, 1 May 2007 11:31:47 +1200 To: Dan McDonald X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 01/05/2007, at 2:25 AM, Dan McDonald wrote: > On Mon, Apr 30, 2007 at 07:22:03AM -0700, Merike Kaeo wrote: >> IKEv2 and/or Mobike should be able to handle an ID/locator split >> [although I want to check the details to make sure that is absolutely >> the case] but can IPsec AH handle the ID/locator split? > > Ahhh, now THAT's an interesting question. > >> While there are camps that believe AH is deprecated, and of course >> you >> cannot use it with IPv4 NATs, there was a long discussion in IPv6 >> mailing >> lists (non-IETF) regarding requiring AH for specific use cases. >> There was >> some talk of requiring a 'new AH' to handle a future ID/locator >> split.... > > I'm not sure if a "new AH" would be needed, but rather a "new AH > rules for > new IP protocol". > > Assuming the ID/locator split is technically a new IP header (v9?), > all one > would need is a processing rule for AH that says "don't include the > locator > in the AH computation". If the split is a change to IPv6, then I > suppose > there could be an SA attribute (negotiated by IKE, or say an > SADB_X_SAFLAG_ > value for PF_KEY) that says "don't include locator part of IPv6 > header". > > It shouldn't be that hard to make AH work in a post-split world. > Protocol > designers in the audience - please take note that AH still matters > to some > people. > > Dan The same trick as is used by HIP's BEET mode for ESP would work; require that the locators in the header be rewritten to identifiers (or hashes thereof) before doing crypto or checksums. Or, use ESP with null encryption and authentication enabled (yes, I know this is regarded as a bad idea... but it does work). Andrew _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss