From architecture-discuss-bounces@ietf.org Tue May 01 04:57: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 1HioAv-0001p4-6O; Tue, 01 May 2007 04:57:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HioAt-0001oy-TC for architecture-discuss@ietf.org; Tue, 01 May 2007 04:57:31 -0400 Received: from mtagate8.uk.ibm.com ([195.212.29.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HioAt-0003sL-Ez for architecture-discuss@ietf.org; Tue, 01 May 2007 04:57:31 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l418vSkV297752 for ; Tue, 1 May 2007 08:57:28 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l418vSXO2666722 for ; Tue, 1 May 2007 09:57:28 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l418vSHG001680 for ; Tue, 1 May 2007 09:57:28 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l418vSSp001669; Tue, 1 May 2007 09:57:28 +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 KAA356834; Tue, 1 May 2007 10:57:27 +0200 Message-ID: <46370102.1050402@zurich.ibm.com> Date: Tue, 01 May 2007 10:57:38 +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: <4635ABFF.2090005@zurich.ibm.com> <20070430125326.GG5237@sun.com> <20070430142532.GA26684@kebe.East.Sun.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: 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 On 2007-05-01 01:31, Andrew McGregor wrote: > > 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). I'm no expert, but RFC 4301 says: >> 3.2. How IPsec Works >> >> IPsec uses two protocols to provide traffic security services -- >> Authentication Header (AH) and Encapsulating Security Payload (ESP). >> Both protocols are described in detail in their respective RFCs >> [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY >> support AH. (Support for AH has been downgraded to MAY because >> experience has shown that there are very few contexts in which ESP >> cannot provide the requisite security services. Note that ESP can be >> used to provide only integrity, without confidentiality, making it >> comparable to AH in most contexts.) However, I feel we are a little ahead of ourselves here. If we end up with an identifier in every packet, plus potentially variable locators, I'm sure that the fine details of which fields are covered by both AH and ESP will need to be adapted. I don't see how that can be defined in advance. There will surely be code changes in IPSEC. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri May 04 13:45:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1qf-0002Q9-Fe; Fri, 04 May 2007 13:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1qe-0002Q1-1W; Fri, 04 May 2007 13:45:40 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk1qc-0003dl-P1; Fri, 04 May 2007 13:45:40 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l44Hjbjq024999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 May 2007 12:45:38 -0500 (CDT) 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 l44Hjbvg011801; Fri, 4 May 2007 10:45:37 -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 l44HjOtK011391; Fri, 4 May 2007 10:45:24 -0700 (PDT) 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); Fri, 4 May 2007 10:45:22 -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 Date: Fri, 4 May 2007 10:45:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED782@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <05cf01c788e8$7972b7e0$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPvLX and companion documents updated Thread-Index: AceI8VXM6/H2RMVzRBOQagzpJYI51QFgKgHg References: <72707A4A-8FA9-4AF4-858C-76E64F42273F@multicasttech.com> <05cf01c788e8$7972b7e0$0601a8c0@pc6> From: "Templin, Fred L" To: , "rrg" , X-OriginalArrivalTime: 04 May 2007 17:45:22.0709 (UTC) FILETIME=[FD669450:01C78E73] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Templin, Fred L" Subject: [arch-d] IPvLX and companion documents updated 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 IPvLX and its companion documents have been updated and are available for comment; all can be found at: http://ipvlx.org. Major changes are given below; please send comments either to the list or to the author. Fred fred.l.templin@boeing.com 1) IPvLX (draft-templin-ipvlx-07.txt): - Simplified and clarified text by introducing ITR/ETR/EBR/SBR terminology - Replaced RS/RA mapping mechanism with NI Query/Reply - introduced identifier/locator split terminology - numerous other clarifications/updates 2) Link Adaptation for IPv6-in-(foo)-in-IPv4 Tunnels (draft-templin-linkadapt-05.txt): - removed setting of IPv4 "Reserved Fragmentation", since ITE/ETE capabilities can be discovered during the initial tunnel negotiation. - Clarified that mechanisms cover IPv6-in-(foo)-in-IPv4; not just IPv6-in-IPv4. - New terminology for ITE/ETE - Clarifications to layering model - Replaced RA with NI Reply as probe response - Reduced SEGID to 6 bits and increased ULPID to 8 bits 3) RFC4214(bis) (draft-templin-rfc4214bis-03.txt): - noted that ISATAP nodes are not required to validate that interface identifiers with the 'u' bit set to universal are unique. - clarifications on Potential Router List initialization. - clarifications in neighbor unreachability detection. - updated domain of applicability. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon May 07 15:05:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl8Vw-0003EM-MR; Mon, 07 May 2007 15:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl8Vv-00039m-KE; Mon, 07 May 2007 15:04:51 -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 1Hl8Vu-00037W-8C; Mon, 07 May 2007 15:04:51 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l47J4m0s005458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 May 2007 12:04:49 -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 l47J4mlJ019181; Mon, 7 May 2007 14:04:48 -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 l47J4axb018713; Mon, 7 May 2007 14:04:46 -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, 7 May 2007 12:04:45 -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 Date: Mon, 7 May 2007 12:04:44 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED78E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <463F31CD.8070503@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tunnel MTU link adaptation and the Reserved Fragmentation (RF) bit Thread-Index: AceQsVTOXmbtriDaSceFov7J5A4mIwAIq51Q References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com><20070507091257.GA28839@nic.fr> <463F31CD.8070503@sri.com> From: "Templin, Fred L" To: , X-OriginalArrivalTime: 07 May 2007 19:04:45.0063 (UTC) FILETIME=[93396170:01C790DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [arch-d] Tunnel MTU link adaptation and the Reserved Fragmentation (RF) bit 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 IPv6-in-(foo)-in-IPv4 tunneling mechanisms (e.g., LISP, IPvLX, ISATAP, Teredo, 6to4, etc.) are currently limited to sending packets only slightly larger than the IPv6 minMTU of 1280 bytes due to operational aspects of the IPv4 Internet. A solution to this limitation is given in 'draft-templin-linkadapt', which specifies a Sub-IP layer mechanism that supports larger MTUs (up to 9KB or larger) through link adaptation at a layer below IPv6 fragmentation but above IPv4 fragmentation. A key requirement of the spec is that both the ITR and ETR be made aware that the link adaptation scheme is being used, and previous versions of the spec did this by requiring the ITR to set the "Reserved Fragmentation (RF)" bit in the IPv4 headers of tunneled packets. The current document version (-05) has gone away from this approach and now requires a prior negotiation between the ITR and ETR. This decision has some important ramifications; first, it sets the use or non-use of the link adaptation on a per- tunnel basis rather than on a per-flow or per-packet basis. This means that all flows and all packets that traverse the tunnel would either use the scheme or not. Secondly, it requires that there be an explicit prior negotiation between the ITR and ETR as to whether the scheme is enabled. Finally, it does not allow for an adpative "revert to classical IPv4 fragmentation" option after the tunnel is established. Use of the RF bit has some associated uncertainties, however. For example, it is not clear as to whether the state of the RF bit would be preserved across all paths since RFC791 says that it is "reserved, must be zero" but does not say what network middleboxes should do with a packet that has RF=3D1. The other consideration is that there are other proposals that would like to make use of this bit. So, can we have some discussion on the use or non-use of the RF bit for link adaptation over IPv6-in-(foo)-in-IPv4 tunnels? 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 Tue May 08 15:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVJo-0004FS-Dm; Tue, 08 May 2007 15:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVJl-0004FL-NX for architecture-discuss@ietf.org; Tue, 08 May 2007 15:25:49 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVJk-0005CC-Tm for architecture-discuss@ietf.org; Tue, 08 May 2007 15:25:49 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 11F64208FC; Tue, 8 May 2007 21:25:48 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-be-4640cebb0ffa Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3DBF20605; Tue, 8 May 2007 21:25:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 21:25:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 21:25:47 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 45D2B24BA; Tue, 8 May 2007 22:25:47 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D017C4DC05; Tue, 8 May 2007 22:25:46 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 719B24DC04; Tue, 8 May 2007 22:25:46 +0300 (EEST) Message-ID: <4640CEBA.1000206@nomadiclab.com> Date: Tue, 08 May 2007 22:25:46 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.10 (X11/20070403) 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 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 08 May 2007 19:25:47.0525 (UTC) FILETIME=[AE1F8B50:01C791A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Hello Noel, I think you came up with a very good capture of immediate benefits that an ID/locator split would have today. One may add that the split provides a new means for access networks to choose an ISP for outgoing packets without conflicts with ingress filtering. And possibly anycast might benefit as well. Yet, the main point I would like to make is not to extend your benefits list, but to emphasize that the effect and the benefits of an ID/locator split strongly depend on /where/ the split is implemented: directly in the hosts, or somewhere in the network. HIP is usually associated with a host-based ID/locator split [1], whereas LISP, eFIT, et al. place the split on the border between an access network and its ISP(s). I prefer to use the term "locator/locator split" when referring to approaches such as LISP or eFIT. [1] As a matter of fact, network-based HIP implementations are likewise conceivable, especially during a transition phase, as Pekka Nikander described in [draft-nikander-ram-generix-proxying]. If the ID/locator split is inside a host, the host still needs to have multiple IP addresses, each with a prefix that topologically corresponds to the respective upstream path. In other words, a host-based split still does not do away with access networks' desire for PI addressing space. This has two disadvantages: (i) The operators continue to face the same limitations with respect to traffic engineering: Hosts still choose the IP source addresses in outgoing packets and thereby determine the ISP that the packets must be forwarded through. (ii) Network reconfiguration is expensive when an access network switches ISPs since existing prefixes must be replaced. On the other hand, as you say, a host-based ID/locator split helps a lot for host mobility, locally within an access network as well as across access networks. And it also helps for host multi-homing, where -- in contrast to access network (or "site") multi-homing -- the host has multiple interfaces to possibly different access networks (see also Thomas Henderson's email earlier in this thread). A host-based split would also make multicast (and perhaps anycast) conceptually cleaner. With a locator/locator split inside the network -- say, at the border between an access network and its ISPs --, traffic engineering becomes more facile, and only border routers need to be reconfigured when the access network changes ISPs. On the other hand, a locator/locator split does not support host multi-homing, neither does it facilitate host mobility except when local within a single access network. It also has no benefits WRT multicast and anycast. In the above, I have considered mobility only in the sense of "session continuity", and I have disregarded the aspect of host reachability. However, when it comes to host reachability, a network-based locator/locator split actually has an advantage because it makes a (stationary) home agent's or other rendez-vous server's IP address stable even when the access network changes ISPs. So in summary, I would argue that both types of splits are necessary to satisfy all objectives that we have today: An ID/locator split on the host for session continuity despite mobility, host multi-homing, multicast, and anycast. And in addition a locator/locator split further upstream in the network, easing ISP changes, access network multi-homing, traffic engineering, and reachability for mobile hosts. The two kinds of splits are truly orthogonal and complementary. Kind regards, - Christian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue May 08 16:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlW2k-0002Ds-39; Tue, 08 May 2007 16:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlW2j-0002Dc-6W for architecture-discuss@ietf.org; Tue, 08 May 2007 16:12:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlW2g-0005we-SV for architecture-discuss@ietf.org; Tue, 08 May 2007 16:12:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 08 May 2007 13:12:15 -0700 X-IronPort-AV: i="4.14,506,1170662400"; d="scan'208"; a="373813849:sNHT44901596" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l48KCEX4025208; Tue, 8 May 2007 13:12:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l48KBnZX008549; Tue, 8 May 2007 20:12:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:12:06 -0700 Received: from [192.168.0.100] ([10.21.153.30]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:12:06 -0700 In-Reply-To: <4640CEBA.1000206@nomadiclab.com> References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <4640CEBA.1000206@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31BF097C-77FA-4B3E-95E4-BDEE1272F4E1@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Benefits of identity/location separation? Date: Tue, 8 May 2007 13:12:04 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 20:12:06.0142 (UTC) FILETIME=[264ED9E0:01C791AD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1065; t=1178655134; x=1179519134; c=relaxed/simple; s=sjdkim1004; 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=aDL5JlkCYsq7L91YC9Dc8qropLAEqslRYuGH84tAsxY=; b=WCpvjFyeclx0dtA6a9aoN9tcYzeWhlM9YKKRvMjf8U7mYAW3qfEaxxc7B5haCxjmH2nYUD1e SsJvQFuWjck3dcHBqptcsrXfuU1bJAx9nt8JundbivZN1wEVYVffqguZ3mIK3VApJL6+Nfcgcc NhgsKpX6GurRZEMpeAVoVAuPc=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 May 8, 2007, at 12:25 PM, Christian Vogt wrote: > If the ID/locator split is inside a host, the host still needs to have > multiple IP addresses, each with a prefix that topologically > corresponds > to the respective upstream path. In other words, a host-based split > still does not do away with access networks' desire for PI addressing > space. This has two disadvantages: (i) The operators continue to > face > the same limitations with respect to traffic engineering: Hosts still > choose the IP source addresses in outgoing packets and thereby > determine > the ISP that the packets must be forwarded through. (ii) Network > reconfiguration is expensive when an access network switches ISPs > since > existing prefixes must be replaced. Christian, I'm not following you at all here. If the ID/locator split is at the edge of the network, the host needs multiple locators, but there need only be a single identifier. This is also true if the ID/locator split is at the host. Could you clarify? Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 09 03:39:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlglm-0002L9-Am; Wed, 09 May 2007 03:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlglk-0002L3-Bf for architecture-discuss@ietf.org; Wed, 09 May 2007 03:39:28 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlglj-0000Qz-LH for architecture-discuss@ietf.org; Wed, 09 May 2007 03:39:28 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 02CF020850; Wed, 9 May 2007 09:39:27 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-42-46417aae4150 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D8BA1209DD; Wed, 9 May 2007 09:39:26 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 09:39:26 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 09:39:26 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1734C232F; Wed, 9 May 2007 10:39:26 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CE9E34DC04; Wed, 9 May 2007 10:39:25 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 80A2B4DBEF; Wed, 9 May 2007 10:39:25 +0300 (EEST) Message-ID: <46417AAE.7010308@nomadiclab.com> Date: Wed, 09 May 2007 10:39:26 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Li Subject: Re: [arch-d] Benefits of identity/location separation? References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <4640CEBA.1000206@nomadiclab.com> <31BF097C-77FA-4B3E-95E4-BDEE1272F4E1@cisco.com> In-Reply-To: <31BF097C-77FA-4B3E-95E4-BDEE1272F4E1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 May 2007 07:39:26.0248 (UTC) FILETIME=[2B53A280:01C7920D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Hi Tony, just up front: By "edge of the network", you mean the "border between the access network and an ISP", right? This is what I was describing as the locator/locator split in the network. What the recent proposals for a network-side locator/locator split pursue is to allow for PI addressing space inside an access network, while still using aggragatable PA addressing space for packet forwarding across ISPs. The way they do this is, at a high level, by translating IP addresses from PI addressing space to IP addresses from PA addressing space. Multiple PA IP addresses thereby map onto the same PI IP address iff the access network is multi-homed -- because each ISP maps its own PA IP address onto the same PI IP address of a host. This is why you end up with only a single locator in the access network. This locator is independent of the ISPs, which is exactly what many access network operators desire for traffic engineering and ISP changes. ISPs don't care so much if there are multiple locators for the same host because they deal with only one of those locators anyway. The recent proposals tend to call the single locator used in the access network an "endpoint identifier", a term that I am not very happy with, as explained in my previous email. Does this make things clearer? - Christian Tony Li wrote: >> If the ID/locator split is inside a host, the host still needs to >> have multiple IP addresses, each with a prefix that topologically >> corresponds to the respective upstream path. In other words, a >> host-based split still does not do away with access networks' >> desire for PI addressing space. This has two disadvantages: (i) >> The operators continue to face the same limitations with respect to >> traffic engineering: Hosts still choose the IP source addresses in >> outgoing packets and thereby determine the ISP that the packets >> must be forwarded through. (ii) Network reconfiguration is >> expensive when an access network switches ISPs since existing >> prefixes must be replaced. > > > Christian, > > I'm not following you at all here. If the ID/locator split is at the > edge of the network, the host needs multiple locators, but there > need only be a single identifier. This is also true if the > ID/locator split is at the host. > > Could you clarify? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 09 12:24: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 1HloxH-00036O-9L; Wed, 09 May 2007 12:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HloxE-00036E-Nn for architecture-discuss@ietf.org; Wed, 09 May 2007 12:23:52 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HloxD-0007kb-3X for architecture-discuss@ietf.org; Wed, 09 May 2007 12:23:52 -0400 Received: from PortatilALV by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002500548.msg for ; Wed, 09 May 2007 18:20:32 +0200 From: "Alvaro Vives Martinez" To: References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <462DA425.70705@zurich.ibm.com> In-Reply-To: <462DA425.70705@zurich.ibm.com> Subject: RE: [arch-d] Benefits of identity/location separation? Date: Wed, 9 May 2007 18:23:07 +0200 Message-ID: <40C3B3D0E0CF4EBB99E1E8E417307A93@PortatilALV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16386 Thread-Index: AceGTxB1V7XaaebcQ4q2SsV++jdpEgMBjJbQ X-Authenticated-Sender: alvaro.vives@consulintel.es X-HashCash: 1:20:070509:architecture-discuss@ietf.org::srOUxDCdTHHGnvuz:0000000000000000000000000000000001xz X-MDRemoteIP: 88.11.63.73 X-Return-Path: alvaro.vives@consulintel.es X-MDaemon-Deliver-To: architecture-discuss@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Wed, 09 May 2007 18:20:34 +0200 X-MDAV-Processed: consulintel.es, Wed, 09 May 2007 18:20:52 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alvaro.vives@consulintel.es 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 Hello Brian, > 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? IMHO in a layered model, where locator applies to one layer (lets say internetwork layer) and identifiers to other layer (over the interntwork layer), the introduction of the "split" requires a mapping mechanism. Although quite obvious, the mapping mechanism is part of the described architecture. It could be more or less complex but never null, IMHO. Best regards, Alvaro > > 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 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 09 12:28: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 1Hlp1s-00061v-Jp; Wed, 09 May 2007 12:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlp1p-00061q-UF for architecture-discuss@ietf.org; Wed, 09 May 2007 12:28:37 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlp1p-0008Qq-CM for architecture-discuss@ietf.org; Wed, 09 May 2007 12:28:37 -0400 Received: from PortatilALV by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002500557.msg for ; Wed, 09 May 2007 18:25:37 +0200 From: "Alvaro Vives Martinez" To: References: <20070425160122.12CF6872DE@mercury.lcs.mit.edu> <4631B004.3080209@zurich.ibm.com> In-Reply-To: <4631B004.3080209@zurich.ibm.com> Subject: RE: [arch-d] Benefits of identity/location separation? Date: Wed, 9 May 2007 18:28:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16386 Thread-Index: AceIozAEPeUjA9iqQK69A12iVriwnQJsz2Ow X-Authenticated-Sender: alvaro.vives@consulintel.es X-HashCash: 1:20:070509:architecture-discuss@ietf.org::AChEmsoA2OZZXtMU:00000000000000000000000000000000Et1L X-MDRemoteIP: 88.11.63.73 X-Return-Path: alvaro.vives@consulintel.es X-MDaemon-Deliver-To: architecture-discuss@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Wed, 09 May 2007 18:25:40 +0200 X-MDAV-Processed: consulintel.es, Wed, 09 May 2007 18:25:43 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alvaro.vives@consulintel.es 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 Hello Brian, > > > 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. IMHO this is a bad thing. For example in the case of a mobile node that have already established a connection using the identifier (== locator) on its side. When moves to another network locator can change, no problem, but having an ID equal to another network locator doesn't seem a good thing. Best regards, Alvaro > > 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 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 09 12:33:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlp69-0008JQ-KN; Wed, 09 May 2007 12:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlp68-0008JL-D9 for architecture-discuss@ietf.org; Wed, 09 May 2007 12:33:04 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlp67-0000vb-RB for architecture-discuss@ietf.org; Wed, 09 May 2007 12:33:04 -0400 Received: from PortatilALV by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002500563.msg for ; Wed, 09 May 2007 18:30:04 +0200 From: "Alvaro Vives Martinez" To: References: <20070422150125.B85BA8731C@mercury.lcs.mit.edu> <462DFD6B.8090000@dcrocker.net> In-Reply-To: <462DFD6B.8090000@dcrocker.net> Subject: RE: [arch-d] Benefits of identity/location separation? Date: Wed, 9 May 2007 18:32:24 +0200 Message-ID: <20A8DC7619084E27BFAFA9834B901F9C@PortatilALV> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16386 Thread-Index: AceGb5o0RReZ1e9tRRC0BlZF3qcEgAL54ITw X-Authenticated-Sender: alvaro.vives@consulintel.es X-HashCash: 1:20:070509:architecture-discuss@ietf.org::upu2A4ZQroUTwLDk:000000000000000000000000000000002Y3G X-MDRemoteIP: 88.11.63.73 X-Return-Path: alvaro.vives@consulintel.es X-MDaemon-Deliver-To: architecture-discuss@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Wed, 09 May 2007 18:30:10 +0200 X-MDAV-Processed: consulintel.es, Wed, 09 May 2007 18:30:13 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alvaro.vives@consulintel.es 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 Hello Dave, > 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. The difference, IMO, is that DNS/IP mapping is used within the same layer, the application layer, and for the same thing. It only makes things easier for human beings. The loc/id split being discussed, IMHO, provides its benefits from the use of locs and ids in different "layers" and for different things (roughly said). Best regards, Alvaro > > 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 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss