From ram-bounces@iab.org Wed Aug 01 09:15: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 1IGE2U-00014Z-R6; Wed, 01 Aug 2007 09:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGE2T-00014R-Fw for ram@iab.org; Wed, 01 Aug 2007 09:14:57 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGE2R-0005nW-UJ for ram@iab.org; Wed, 01 Aug 2007 09:14:57 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l71DEq3j019437 for ; Wed, 1 Aug 2007 09:14:52 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l71DEpNE175684 for ; Wed, 1 Aug 2007 07:14:52 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l71DEpUg028824 for ; Wed, 1 Aug 2007 07:14:51 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-185-171.wecm.ibm.com [9.67.185.171]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l71DEnDZ028757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 07:14:51 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l71DEdQC016773; Wed, 1 Aug 2007 09:14:39 -0400 Message-Id: <200708011314.l71DEdQC016773@cichlid.raleigh.ibm.com> To: JFC Morfin Subject: Re: [RAM] First cut at routing & addressing problem statement In-reply-to: <20070801010335.4FE331831E@smtp7-g19.free.fr> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46AB47AB.9060304@firstpr.com.au> <46AC78FC.4050701@firstpr.com.au> <200707312024.l6VKOBfb029716@cichlid.raleigh.ibm.com> <20070801010335.4FE331831E@smtp7-g19.free.fr> Comments: In-reply-to JFC Morfin message dated "Wed, 01 Aug 2007 02:52:41 +0200." Date: Wed, 01 Aug 2007 09:14:39 -0400 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org JFC Morfin writes: > At 22:24 31/07/2007, Thomas Narten wrote: > >We intended the term "site" to be a fairly general term, one that > >includes pretty much any topologically distinct thing that connects to > >the internet. This includes home users. It is also NOT restricted to > >just larger enterprises or ASes. We'll add a clarifying definition to > >the document. > Dear Thomas, > I am sorry but "5. Provides meaningful benefits to the parties who > bear the costs of deploying and maintaining the technology." is an > error. What we want is to provide meaningful benefits to the users. Sure. But if you provide benefits to users, but the cost of providing those benefits is carried by others (who do not themselves see the benefits), by what means does one actually force the cost on those others? There is no free lunch. We can't make parties do things they don't want to. One thing we should have learned by now is that forcing others to bear unfunded mandates (to benefit another party) all to often results in technology that simply never gets deployed. So, if we actually want something to be deployed, it would be advisable to have the technology be of a type that those who have to pay the costs also see the benefit, so that they have incentive to pay the cost. Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 01 13:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGI9P-00038z-Lj; Wed, 01 Aug 2007 13:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGI9O-00038u-99 for ram@iab.org; Wed, 01 Aug 2007 13:38:22 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGI9M-0004lG-TE for ram@iab.org; Wed, 01 Aug 2007 13:38:22 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 396621A386 for ; Wed, 1 Aug 2007 19:38:20 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 0A9F91A334 for ; Wed, 1 Aug 2007 19:38:19 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2007 19:38:26 +0200 To: ram@iab.org From: JFC Morfin Subject: Re: [RAM] First cut at routing & addressing problem statement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070801173819.0A9F91A334@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 05:54 01/08/2007, Robin Whittle said: >Hi JFC Morphin, >The missing point 3 is just a typo. Thank you. > The other points you mention >seem to involve long-term new architectural goals involving host >changes. Not that much. It is more a paradigm change that, I think, today TCP/IP can support - but not necessarily all its possible evolutions. >I have approached the RADIR Problem Statement assuming it concerns >a problem which requires a solution which is incrementally >deployable and automatically enables existing hosts, without >changes, to remain connected, but achieves important benefits such >as multihoming, portability, TE etc. for many more end-users >without adding to the growth in the global routing table. IMHO there are several ways to achieve that. However, the real problem is that whatever the one being chosen it will have to co-exist with the current approach (designed along the old paradigm). In so doing it will live demonstrate that the Internet can support architectural multiplicity. This means that the ROAP leads to the necessity of an IETF change of paradigm. And that its solution will be expressed under this new paradigm. Trying to express and solve it under the paradigm wich created it may turn being very complex, may be impossible? jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Aug 02 21:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGlg9-0002Sd-14; Thu, 02 Aug 2007 21:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGlg8-0002SP-6W for ram@iab.org; Thu, 02 Aug 2007 21:10:08 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGlg6-0007XP-2l for ram@iab.org; Thu, 02 Aug 2007 21:10:08 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B7FA059DA2; Fri, 3 Aug 2007 11:09:57 +1000 (EST) Message-ID: <46B28059.9010701@firstpr.com.au> Date: Fri, 03 Aug 2007 11:09:45 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org References: <150457.89497.qm@web58707.mail.re1.yahoo.com> In-Reply-To: <150457.89497.qm@web58707.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [RAM] Re: [RRG] Routers in DFZ X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org The iPlane project: http://iplane.cs.washington.edu/data.html has a file "Lists of alias clusters", where each line is a router, with the IP addresses of its one or more interfaces. I wrote to them earlier this week about trying to use this data to infer the number of single-homed routers and multihomed/transit routers. My analysis of the current file didn't match their statement in November last year: This clustering algorithm, when executed on a typical traceroute output, clusters 762,701 interfaces into 54,530 clusters. 653,455 interfaces are in 10,713 clusters of size greater than 10, while 21,217 interfaces are in singleton clusters. When I looked the other day, there were very few single IP address lines. They said they would get back to me soon with proper information on the number of singlehomed and multihomed/border routers, because at present their data doesn't enable this to be determined. I will post whatever I find out to this list and to the RAM list. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Aug 02 22:37: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 1IGn2f-00032E-FC; Thu, 02 Aug 2007 22:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGn2e-000328-JP for ram@iab.org; Thu, 02 Aug 2007 22:37:28 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGn2c-00013B-FJ for ram@iab.org; Thu, 02 Aug 2007 22:37:28 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id D3E9F59DA2; Fri, 3 Aug 2007 12:37:22 +1000 (EST) Message-ID: <46B294D6.7070700@firstpr.com.au> Date: Fri, 03 Aug 2007 12:37:10 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is something further to the discussion in the "First cut at routing & addressing problem statement" thread on whether or not it will ever be possible to have a completely automated method of renumbering a network, here more arguments that it will never be possible. In that thread I argue that the RADIR Problem Statement should not be written as if there was even a slight possibility that new technologies could make today's networks reliably renumbered by some automated means. Even with arbitrary architectural refinements in the networks of tomorrow, as long as we are still working with IPv4 or IPv6 as we know them today, reliable automated renumbering is not going to be possible. Even if end-users didn't care about portability, many of them need multihoming. As far as I know, the only way to cope with SSL certificates and IP addresses of nameservers programmed into other nameservers is to implement multihoming with genuine portability so the servers and the entire multihomed netork keeps operating on the same addresss. Not all the occurrences of actual IP addresses occur in the network itself. If a server as an SSL certificate, that is specific to its physical IP address. No amount of automation can help with that, or the cost and time-delay of getting another certificate. Likewise, if the network contains nameservers, the IP addresses of those will be written into other nameservers. This takes time and effort to change, and could result in disruption if the actual change of address doesn't closely match the change in the next highest DNS level. For a substantial network to be able to move to another ISP without near-certain disruption and without excessive costs, I believe it simply has to take its address space with it. Portability is the only solution. As far as I know, this notion of IPv6 end-users supposedly being happy with PA space and automated renumbering has been going on for ten years or so. Hadn't anyone thought of all the config files (named, httpd, imapd, firewall etc.), SSL certs, DNS delegation etc.? - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Aug 03 15:12: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 1IH2Ze-00051l-Ij; Fri, 03 Aug 2007 15:12:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH2Zc-00051g-LX for ram@iab.org; Fri, 03 Aug 2007 15:12:32 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH2Zc-0004qn-BN for ram@iab.org; Fri, 03 Aug 2007 15:12:32 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 17D421A34E for ; Fri, 3 Aug 2007 21:11:08 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id D718D1A351 for ; Fri, 3 Aug 2007 21:11:07 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Aug 2007 21:11:16 +0200 To: ram@iab.org From: JFC Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070803191107.D718D1A351@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [RAM] Why TE must be at individual user level X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org May be this will help understanding why the need is for routing to be decided (not just suggested) at individual user level. http://www.washingtonpost.com/wp-dyn/content/article/2007/08/02/AR2007080202619.html?hpid=topnews Or for national DFZ's? As noted in a previous mail, the Internet has no presentation layer which might help. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Aug 03 15:47:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH37q-00048G-JE; Fri, 03 Aug 2007 15:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH37p-00048A-Vx for ram@iab.org; Fri, 03 Aug 2007 15:47:53 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH37p-0000NY-Ku for ram@iab.org; Fri, 03 Aug 2007 15:47:53 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l73Jlp46016357 for ; Fri, 3 Aug 2007 15:47:51 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l73JloAm475302 for ; Fri, 3 Aug 2007 15:47:50 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l73Jlofm013381 for ; Fri, 3 Aug 2007 15:47:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l73JlnOP013345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2007 15:47:50 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l73JljZ3027893; Fri, 3 Aug 2007 15:47:49 -0400 Message-Id: <200708031947.l73JljZ3027893@rotala.raleigh.ibm.com> To: Robin Whittle Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. In-reply-to: <46B294D6.7070700@firstpr.com.au> References: <46B294D6.7070700@firstpr.com.au> Comments: In-reply-to Robin Whittle message dated "Fri, 03 Aug 2007 12:37:10 +1000." Date: Fri, 03 Aug 2007 15:47:45 -0400 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin Whittle writes: > Here is something further to the discussion in the "First cut at > routing & addressing problem statement" thread on whether or not it > will ever be possible to have a completely automated method of > renumbering a network, here more arguments that it will never be > possible. > In that thread I argue that the RADIR Problem Statement should not > be written as if there was even a slight possibility that new > technologies could make today's networks reliably renumbered by some > automated means. Why is it important to do this? If it is feasible to do this, we shold. If it is not, we won't. Trying to rule it out as a possibility from the problem statement point of view makes no sense (IMO). The purpose of the problem statement is to define the problem, and not rule out _any_ solution, so long as it addresses the problem. (And no, I'm not about to argue that getting automatic/painless renumbering is about to happen. But let any proposed solution in that direction be evaluated on its merits please!). It's much more productive to focus on solution aproaches that folk think might be viable, than spending cycles trying to rule out approaches that aren't being pushed very heavily... > As far as I know, this notion of IPv6 end-users supposedly being > happy with PA space and automated renumbering has been going on for > ten years or so. Um, AFAIK, people have NOT been making this argument. Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Aug 03 16:51:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH475-0004J4-Vi; Fri, 03 Aug 2007 16:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH474-0004Iy-T6 for ram@iab.org; Fri, 03 Aug 2007 16:51:10 -0400 Received: from fk-out-0910.google.com ([209.85.128.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH474-00022U-F0 for ram@iab.org; Fri, 03 Aug 2007 16:51:10 -0400 Received: by fk-out-0910.google.com with SMTP id 19so1434698fkr for ; Fri, 03 Aug 2007 13:51:09 -0700 (PDT) Received: by 10.82.112.16 with SMTP id k16mr3809419buc.1186143942768; Fri, 03 Aug 2007 05:25:42 -0700 (PDT) Received: from ?10.10.50.8? ( [213.3.13.1]) by mx.google.com with ESMTPS id k10sm3096968nfh.2007.08.03.05.25.40 (version=SSLv3 cipher=RC4-MD5); Fri, 03 Aug 2007 05:25:40 -0700 (PDT) Message-ID: <46B31EC7.7040904@gmail.com> Date: Fri, 03 Aug 2007 14:25:43 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [RAM] First cut at routing & addressing problem statement References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> In-Reply-To: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > We would welcome comments on the document. In particular: > > - Do folk agree with the problem statement as written, or are we > missing something fairly fundamental? Yes. I think it's correct to keep it down to the bare bones. > - Are there other pressures on the routing system that we have not > listed or described completely? Not that I noticed. > - We intentionally did not include improving mobility as a core > "problem", as explained in the document. (That doesn't mean we > don't recognize that some of the solutions under discussion may > also be applicable to mobility scenarios. Rather, we tend to see > improved mobility as a possible benefit of certain classes of > solutions.) I think this is correct. In many ways mobility is an overlay on a routing system assumed to be stable and scaleable. > - Are there other views of what folk perceive the core routing and > addressing problem to be? Not here. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Aug 03 16:57: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 1IH4DQ-00077k-PD; Fri, 03 Aug 2007 16:57:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH4DP-00077M-Ho for ram@iab.org; Fri, 03 Aug 2007 16:57:43 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IH4DO-0002H1-0I for ram@iab.org; Fri, 03 Aug 2007 16:57:43 -0400 Received: (qmail 55590 invoked by uid 1007); 3 Aug 2007 09:51:00 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=XEM1PKCC8GJhOsLVRBKLtRI8kJx3CO1t60AHmbJkmZP0VA+GApx8fSUyEiBZIsca ; Date: Fri, 3 Aug 2007 11:51:00 +0200 From: Gert Doering To: Robin Whittle Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. Message-ID: <20070803095100.GF69215@Space.Net> References: <46B294D6.7070700@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46B294D6.7070700@firstpr.com.au> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 1.9 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, On Fri, Aug 03, 2007 at 12:37:10PM +1000, Robin Whittle wrote: > If a server as an SSL certificate, that is specific to its physical > IP address. No amount of automation can help with that, or the cost > and time-delay of getting another certificate. Doing so in the first place could be considered a mistake. The nice thing about *names* is that you can (and should!) tie the SSL certificate to the domain name that you want to secure, not to the IP address. [..] > As far as I know, this notion of IPv6 end-users supposedly being > happy with PA space and automated renumbering has been going on for > ten years or so. Hadn't anyone thought of all the config files > (named, httpd, imapd, firewall etc.), SSL certs, DNS delegation etc.? Most end user networks neither run name servers nor SSL certs, etc., in their network range - they delegate that task to their service providers. "all the config files" should contain host names, not IP addresses (that's what DNS has been invented for, half a century ago). Of course there are larger "end users" (corporate networks) that have local servers in their network - but even then, with proper planning in the setup phase (and that means "not putting IP addresses in places that should have server names"), renumbering is not painless, but also not impossible. It mostly boils down to firewall rules, and changing glue for a few name servers (again, the "proper planning" thing). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Aug 03 16:57: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 1IH4Df-0007Ia-4R; Fri, 03 Aug 2007 16:57:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH4De-0007Gj-0y for ram@iab.org; Fri, 03 Aug 2007 16:57:58 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH4Da-0002HJ-Nc for ram@iab.org; Fri, 03 Aug 2007 16:57:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id B930EB5A6E; Fri, 3 Aug 2007 10:58:16 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17510-01-97; Fri, 3 Aug 2007 10:58:13 +0200 (CEST) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id C4BF2B5A69; Fri, 3 Aug 2007 10:58:13 +0200 (CEST) Message-ID: <46B2EE25.30405@uninett.no> Date: Fri, 03 Aug 2007 10:58:13 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.5 (X11/20070731) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. References: <46B294D6.7070700@firstpr.com.au> In-Reply-To: <46B294D6.7070700@firstpr.com.au> Content-Type: multipart/mixed; boundary="------------030004030806000107010106" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -1.4 (-) X-Scan-Signature: 153beb8acb7d067344ce5c1c46ff3fbc Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --------------030004030806000107010106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Robin Whittle wrote: [...] > As far as I know, this notion of IPv6 end-users supposedly being > happy with PA space and automated renumbering has been going on for > ten years or so. Hadn't anyone thought of all the config files > (named, httpd, imapd, firewall etc.), SSL certs, DNS delegation etc.? Many of these issues (including config files, applications, DNS etc.) were studied in the expired draft draft-chown-v6ops-renumber-thinkabout-05.txt I've attached the draft for those that may be interested. Unfortunately it did not consider certificates. Most people I know use FQDNs in certificates though. Stig > > > - Robin --------------030004030806000107010106 Content-Type: text/plain; name="draft-chown-v6ops-renumber-thinkabout-05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="draft-chown-v6ops-renumber-thinkabout-05.txt" Network Working Group T. Chown Internet-Draft M. Thompson Expires: March 22, 2007 A. Ford S. Venaas University of Southampton, UK September 18, 2006 Things to think about when Renumbering an IPv6 network draft-chown-v6ops-renumber-thinkabout-05 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo presents a summary of scenarios, issues for consideration and protocol features for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. Its focus lies not in the procedure for renumbering, but as a set of "things to think about" when undertaking such a renumbering exercise. Chown, et al. Expires March 22, 2007 [Page 1] =0C Internet-Draft Renumbering an IPv6 network September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Structure of Document . . . . . . . . . . . . . . . . . . 4 1.2. Past IPv4 Renumbering studies in the PIER WG . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Renumbering Event Triggers . . . . . . . . . . . . . . . . . . 5 3.1. Change of uplink prefix . . . . . . . . . . . . . . . . . 6 3.1.1. Migration to new provider . . . . . . . . . . . . . . 6 3.1.2. Dial on Demand . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Provider migration and upstream renumbering . . . . . 7 3.1.4. IPv6 transition . . . . . . . . . . . . . . . . . . . 7 3.2. Change of internal topology . . . . . . . . . . . . . . . 8 3.3. Acquisition or merger . . . . . . . . . . . . . . . . . . 8 3.4. Network growth . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Network mobility . . . . . . . . . . . . . . . . . . . . . 8 4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 9 4.1. Minimal disruption . . . . . . . . . . . . . . . . . . . . 9 4.2. Session survivability . . . . . . . . . . . . . . . . . . 9 4.2.1. Short-term session survivability . . . . . . . . . . . 10 4.2.2. Medium-term session survivability . . . . . . . . . . 10 4.2.3. Long-term session survivability . . . . . . . . . . . 10 4.2.4. "Sessions" in non-session based transports . . . . . . 11 5. IPv6 Protocol Features and their Effects on Renumbering . . . 11 5.1. Multi-addressing . . . . . . . . . . . . . . . . . . . . . 11 5.2. Multi-homing techniques . . . . . . . . . . . . . . . . . 12 5.2.1. Relevance of multi-homing to renumbering . . . . . . . 12 5.2.2. Current situation with IPv6 multi-homing . . . . . . . 13 5.3. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Visited site renumbers when mobile . . . . . . . . . . 14 5.3.2. Home site renumbers when mobile . . . . . . . . . . . 14 5.3.3. Home site renumbers when disconnected . . . . . . . . 14 5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Unique Local Addressing . . . . . . . . . . . . . . . . . 16 5.5.1. ULAs, Multicast and Address Selection . . . . . . . . 17 5.5.2. ULAs with application-layer gateways . . . . . . . . . 18 5.6. Anycast addressing . . . . . . . . . . . . . . . . . . . . 18 6. Node Configuration Issues . . . . . . . . . . . . . . . . . . 19 6.1. Stateless Address Autoconfiguration . . . . . . . . . . . 19 6.1.1. Router Advertisement Lifetimes . . . . . . . . . . . . 20 6.1.2. Stateless Configuration with DHCPv6 . . . . . . . . . 20 6.1.3. Tokenised Interface Identifiers . . . . . . . . . . . 20 6.2. Stateful Configuration with DHCPv6 . . . . . . . . . . . . 21 6.2.1. Prefix Delegation . . . . . . . . . . . . . . . . . . 22 6.2.2. Source Address Selection Policy distribution . . . . . 22 6.3. Router Renumbering . . . . . . . . . . . . . . . . . . . . 22 7. Administrative Considerations for Renumbering . . . . . . . . 23 7.1. Router Advertisement Lifetimes . . . . . . . . . . . . . . 23 Chown, et al. Expires March 22, 2007 [Page 2] =0C Internet-Draft Renumbering an IPv6 network September 2006 7.2. Border filtering . . . . . . . . . . . . . . . . . . . . . 24 7.3. Frequency of renumbering episodes . . . . . . . . . . . . 24 7.4. Delay-related Considerations . . . . . . . . . . . . . . . 25 7.4.1. With or without a flag day . . . . . . . . . . . . . . 25 7.4.2. Freshness of service data . . . . . . . . . . . . . . 25 7.4.3. Availability of old prefix . . . . . . . . . . . . . . 26 7.4.4. Duration of overlap . . . . . . . . . . . . . . . . . 27 7.5. Scalability issues . . . . . . . . . . . . . . . . . . . . 27 7.5.1. Packet filters, Firewalls and ACLs . . . . . . . . . . 28 7.5.2. Monitoring tools . . . . . . . . . . . . . . . . . . . 30 7.6. Considerations with a Dual-Stack Network . . . . . . . . . 30 7.7. Equipment administrative ownership . . . . . . . . . . . . 31 8. Impact of Topology Design on Renumbering . . . . . . . . . . . 31 8.1. Merging networks . . . . . . . . . . . . . . . . . . . . . 31 8.2. Fixed length subnets . . . . . . . . . . . . . . . . . . . 32 8.3. Use 112-bit prefixes for point-to-point links . . . . . . 32 8.4. Plan for growth where possible . . . . . . . . . . . . . . 33 8.5. IPv6 NAT Avoidance . . . . . . . . . . . . . . . . . . . . 33 9. Application and service-oriented Issues . . . . . . . . . . . 34 9.1. Shims and sockets . . . . . . . . . . . . . . . . . . . . 34 9.2. Explicitly named IP addresses . . . . . . . . . . . . . . 35 9.3. API dilemma . . . . . . . . . . . . . . . . . . . . . . . 36 9.4. Server Sockets . . . . . . . . . . . . . . . . . . . . . . 37 9.5. Sockets surviving invalidity . . . . . . . . . . . . . . . 37 9.6. DNS Authority . . . . . . . . . . . . . . . . . . . . . . 38 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.1. IETF Call to Arms . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.1. Normative References . . . . . . . . . . . . . . . . . . . 40 14.2. Informative References . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 44 Chown, et al. Expires March 22, 2007 [Page 3] =0C Internet-Draft Renumbering an IPv6 network September 2006 1. Introduction This memo presents a summary of scenarios, issues for consideration and protocol features for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. This document does not relate the procedures for IPv6 renumbering; for such a procedure the reader is referred to [1]. The authors plan to use this document, together with ongoing operational experience, to refine [1] where necessary, to promote that guide from Informational to BCP. The focus is on renumbering site networks, though many of the principles apply to renumbering other (ISP) networks. 1.1. Structure of Document This document is split into a number of sections that discuss various aspects of network renumbering that should be considered when undertaking such an event. This document begins with a discussion of the various reasons behind renumbering events, and the requirements to ensure the event goes smoothly. The following sections then discuss a selection of factors that can both help and hinder the renumbering procedure, and as such should be taken into account when planning the event. Finally, this document summarises issues with applications and services, and attempts to identify places where IP addresses may be hard-coded and thus require reconfiguration during a renumbering event. 1.2. Past IPv4 Renumbering studies in the PIER WG A number of years ago (1996-1997), the Procedures for Internet/ Enterprise Renumbering (PIER) WG spent time considering the issues for IPv4 renumbering. The WG produced three RFC documents. In RFC1916 [2], a "call to arms" for input on renumbering techniques was made. RFC2071 [3] documents why IPv4 renumbering is required. Interestingly, many, but not all, of the drivers have changed with respect to IPv6. In RFC2072 [4], a Router Renumbering Guide, some operational procedures are given, much as they are in Baker [1] for IPv6. Reflection on RFC2071 is interesting, witness the quote: "It is also envisioned that Network Address Translation (NAT) devices will be developed to assist in the IPv4 to IPv6 transition, or perhaps supplant the need to renumber the majority of interior networks altogether, but that is beyond the scope of this document." That need however is still very strong, particularly given the lack of Provider Independent (PI) address space in IPv6 (in IPv4, PI address space exists mainly for historical, pre-CIDR reasons). Chown, et al. Expires March 22, 2007 [Page 4] =0C Internet-Draft Renumbering an IPv6 network September 2006 RFC2072 is more interesting in the context of this document. Some is certainly relevant, though much is not, due to the inherent changes in IPv6. For example, there is no CIDR and address aggregation is given as mandate. Also, IPv6 subnets are in effect fixed length (/64), so local administrators do not need to resize subnets to maximise efficient use of address space as they do in IPv4. One core message from RFC2072 that holds true today is that of section 4 where the observation is made that renumbering networks whilst remaining the same hierarchy of subnets (i.e. the cardinality of the set of prefixes to renumber remains constant) is the 'easiest' scenario to renumber; when each "old" prefix can be mapped to a single "new" prefix. A distinction of this work is that, where the PIER working group consider the transition from IPv4 to IPv6 addressing as a renumbering scenario, we strictly consider only the renumbering from IPv6 prefixes to other IPv6 prefixes and leave transition to well documented techniques such as those from the PIER working group. 2. Terminology The following terminology is used in this document (to be expanded in future revisions): o Site: An organisationally distinct network, ranging from SOHO through to enterprise. o Flag day: A planned service outage. o Node: A device on the network that is being renumbered, or that is involved in communication with the network being renumbered. 3. Renumbering Event Triggers This section details typical actions that result in the need for a renumbering event, and thus define the scenarios for renumbering. In many instances, in particular those where no "flag day" is involved, the process of renumbering will inevitably lead to a scenario where hosts are multi-addressed or multi-homed as one phase of the renumbering procedure. The relationship between renumbering and multi-homing is discussed later in this document. In other instances, e.g. a change in the IPv4 address offered by a provider to a site using 6to4 [9], the change offers no overlap in Chown, et al. Expires March 22, 2007 [Page 5] =0C Internet-Draft Renumbering an IPv6 network September 2006 external connectivity or addressing, and thus there is no multi- homing overlap. Triggers may be provider-initiated or customer-initiated. Triggers and scenarios for IPv4 renumbering are discussed in RFC2071, but many of these are no longer relevant, and in IPv6 some new triggers exist, e.g. those related to network mobility or IPv6 transition tools. 3.1. Change of uplink prefix One of the most common causes for renumbering will be a change in the site's upstream provider. As per RFC3177 [10], the typical allocation for an IPv6 site is a /48 size prefix taken from the globally aggregated address space of the site's provider. With IPv6, sites are highly unlikely to be able to obtain provider independent (PI) address space, as have in some cases been obtained in the past with IPv4. Rather, sites use provider assigned (PA) addressing. As a result, if a site changes provider, it must also change its IPv6 PA prefix. 3.1.1. Migration to new provider In the simplest case, the customer is triggering the renumbering by choosing to change the site's upstream provider to a new ISP and thus a new PA IPv6 prefix range. This may simply be in the form of selecting a new commercial provider, although there are several other possible scenarios, such as changing from a dial-up to a broadband connection, or moving from a community wireless connection to a fixed broadband connection. A similar scenario exists when a customer migrates to a different service from the same provider. For example, if a customer changes from a dialup to a broadband connection, they will likely be connecting to a different part of the provider's topology, and therefore receive a different address allocation. 3.1.2. Dial on Demand A site may connect intermittently to its upstream provider. In such cases the prefix allocated by the provider may change with each connection, as it often does in the case of single IPv4 address allocations to SOHO customers today. Thus the site may receive a prefix still in its provider PA range, but the prefix may vary with each connection, causing a renumbering event. Dynamically assigned IP addresses are common today with dial-up and Chown, et al. Expires March 22, 2007 [Page 6] =0C Internet-Draft Renumbering an IPv6 network September 2006 ISDN Internet connections, and to a lesser extent some broadband products, particularly cable modems. Usually with dynamically assigned IP addresses on broadband products, the address is only likely to change when the customer reconnects, which could be very infrequently. This case can be mitigated by encouraging ISPs to offer static IPv6 prefixes to customers. Where /48 prefixes are provided, a large ISP may be forced to require significantly more than the "default" /32 allocation from an RIR to an ISP to be able to service its present and future customer base. With always-on more common in new deployments, provider re-allocation should be less common; however the practice of reallocating IPv4 addresses in SOHO broadband networks is not uncommon in current broadband ISPs. 3.1.3. Provider migration and upstream renumbering A site's upstream provider may need to renumber, due for example to a change in its network topology or the need to migrate to a different or additional prefix from its Regional Internet Registry (RIR). This will in turn trigger the renumbering of the end site. Such renumbering events would be expected to be rare, but it should be noted that RIR-assigned IPv6 address space is not owned by an ISP. 3.1.4. IPv6 transition During transition to IPv6, there are several scenarios where a site may have to renumber. For example, if the site uses 6to4 for access and its IPv4 address is dynamically assigned, an IPv6 renumbering event will be triggered when the site's IPv4 address changes. Another likely renumbering event would be the change of transition mechanism, such as from 6to4 to a static IPv6-in-IPv4 tunnel, or from any one of those mechanisms to a native IPv6 link. When changing from 6to4 (2002::/16) addresses to native global aggregatable unicast addresses, renumbering would be unavoidable. When migrating from a tunnelled to a native connection, renumbering may not be necessary if the same prefix can be routed natively, however this would be provider-dependent. In addition, there are likely to be many cases of network renumbering occurring when the old 6bone prefix (3FFE::/16) is phased out as per RFC3701 [11], and networks still using it will have to renumber. Finally, there is at least one transition mechanism, ISATAP [12], that uses specially crafted host EUI-64 format addresses. Should a site migrate from ISATAP to use either conventional EUI-64 addressing Chown, et al. Expires March 22, 2007 [Page 7] =0C Internet-Draft Renumbering an IPv6 network September 2006 (via stateless address autoconfiguration or perhaps DHCPv6), then renumbering would be required at least in the host part of addresses. It is also worth noting that nodes that use IPv6 Privacy Extensions [13] will in effect renumber the host part of their address on a frequent basis, in the case of one popular implementation on a daily basis if the node remains on-link on the same network. 3.2. Change of internal topology A site may need to renumber all or part of its internal network due to a change of topology, such as creating more or less specific subnets, or acquiring a larger IPv6 address allocation. Motivations for splitting a link into separate subnets may be to meet security demands on a particular link (policy for link-based access control rules), or for link load management by shuffling popular services to more appropriate locations in the local topology. Link-merging may be due to department restructuring within the hosting organisation, for example. 3.3. Acquisition or merger Two networks may need to merge to one due to the acquisition or merger of two organisations or companies. Such a reorganisation may require one or more parts of the new network to renumber to the primary PA IPv6 prefix. 3.4. Network growth A site that is allocated a /48 prefix may grow to a size where it needs to use a larger prefix for internal networking. Sites in the early stages of IPv6 deployment may only request a /48, even if they are likely to outgrow such a prefix in time. In such a case site- wide renumbering may be required to utilise the new prefix if organisational restructuring also happens due to the growth. 3.5. Network mobility This covers various cases of network mobility, where a static or nomadic network may obtain different uplink connectivity over time, and thus be assigned different IPv6 PA prefixes as the topology changes. One example is the "traditional" NEMO network [14], another may be a community wireless network where different sets of nodes gain uplink connectivity - typically to the same provider - at different times. Chown, et al. Expires March 22, 2007 [Page 8] =0C Internet-Draft Renumbering an IPv6 network September 2006 4. Renumbering Requirements In this section we enumerate potential specific goals or requirements for sites or users undergoing an IPv6 renumbering event. 4.1. Minimal disruption The renumbering event should cause minimal disruption to the routine operation of the network being renumbered, and the users of that network. Disruption is a difficult term to quantify in a generic way, but it can be expressed by factors such as: o Application sessions being terminated o Security controls (e.g. ACLs) blocking access to legitimate resources o Unreachability of nodes or networks o Name resolution, directory and configuration services providing invalid (out-of-date) address data o Limitation of network management visibility These disruptive elements will be covered in situ as we discuss protocol features and other renumbering considerations later in this memo. 4.2. Session survivability The concept of session survivability is catered for by [1] in that new sessions adopt either old or new prefix based on the state of the renumbering process, as discussed in Section 5.1. However, other approaches to renumbering networks may be appropriate in certain deployments, such as where "flag days" are unavoidable, such as where two live prefixes are being "swapped". In these cases, further consideration for existing sessions (their longevity, frequency, independence across interactions, etc.) is required. Some protocols are specifically geared to aid session survivability, e.g. the Stream Control Transmission Protocol (SCTP) [15], and may prove valuable in mission-critical renumbering scenarios, in particular the extension that enables the dynamic addition and removal of IP addresses from an SCTP endpoint association [16]. Sessions may be administratively maintained, such as NFS mounts for Chown, et al. Expires March 22, 2007 [Page 9] =0C Internet-Draft Renumbering an IPv6 network September 2006 user filestore, or they may be user-driven, e.g. long-running ssh sessions. In general, it is important to consider how TCP and the applications above it handle the connection failures that may result from a change in address. There are different classes of session duration, as described in the following sections. 4.2.1. Short-term session survivability A typical short-term session would involve a request-response protocol, such as HTTP, where a new network connection is initiated per transaction, or at worst for a small transaction set. In such cases the migration to a new network prefix is transparent: the client can use the new prefix in new transactions without consequence. Some applications, however, may be skewed by such a shift in connection source for the same entity 'user', for example applications that use recent connection history as a cue to identity (e.g. POP-before-SMTP as used by many dial-on-demand ISP customers ), or for applications that care about connection statistics (the same user web-browsing "session" may be split into two where a renumbering event occurs in-between client transactions). 4.2.2. Medium-term session survivability A medium-term session is typified by an application or service that may persist for perhaps a period of a few minutes up to a period of a day or so. This might involve a TCP-based application that is left running during a working day, such as an interactive shell (SSH) or a large file download. 4.2.3. Long-term session survivability Long term sessions may typically run for several days, if not weeks or months. These might typically include TCP-based NFS mounts, or long-running TCP applications. Sessions in this context may also include those applications that, once started, do not re-resolve names and so repeatedly open new connections or send new datagrams to the same (as bound at time of initialisation) address throughout their execution lifetime. Even if at API-level applications do attempt to re-resolve the symbol to which they desire to connect, the behaviour of the resolvers is unclear as to whether mappings are refreshed from the naming service, and as such even if the renumbering site does update its DNS (or NIS, LDAP database etc.), the local result may indeed be cached without any indication passed Chown, et al. Expires March 22, 2007 [Page 10] =0C Internet-Draft Renumbering an IPv6 network September 2006 back up to the application as to how 'old' said binding information is. 4.2.4. "Sessions" in non-session based transports UDP transport protocols, such as UDP-based NFS mounts, maintain the status of a 'session' by keeping state at one or both ends of the communication, but without a persistent open socket connection at the network layer. If, due to node renumbering, one endpoint changes address then that state becomes invalid and the 'session' interrupted. Note that some stack implementations do not correctly flag an error to applications that attempt to send packets with an invalidated source address, see section Section 9.5 IP addresses are also seen carried in higher-layer protocols, e.g. application sessions, such as with FTP. Any application that makes use of layer-3 address data as a unique end-point identifying token may be disrupted by the address of the node changing to which that token relates. This may not be an issue in cases where the token is treated as abstract (i.e. literally just a token), however where locator semantics are inferred, subsequent attempts to 'resolve' the token to an address endpoint for communication, for example, will fail. 5. IPv6 Protocol Features and their Effects on Renumbering IPv6 includes a number of notable features that can help or hinder - and sometimes both - renumbering episodes. This section discusses these features and their associated effects for consideration when undertaking network renumbering, both in terms of how they can be used to ease the process, as well as potential pitfalls that should be considered. 5.1. Multi-addressing As per RFC3513 [17], IPv6 hosts may be multi-addressed. This means that multiple unicast addresses can be assigned and active on the same interface. These addresses can have different reachabilities ('scopes' such as link-local or global), different statuses including 'preferred' and 'deprecated', and may be ephemeral in nature (such as care-of addresses when attached to a foreign network [18] or IPv6 Privacy addresses [13]). RFC3484 address selection semantics [5] determine which of the "MxN" address pairs to use for communication in the general case. Chown, et al. Expires March 22, 2007 [Page 11] =0C Internet-Draft Renumbering an IPv6 network September 2006 During a renumbering episode, the addition of an extra address for an endpoint increases the number of possible source-destination address pairs for communications between nodes to use. The address selection mechanisms specified by RFC3484 are currently at varying stages of implementation in operating systems. RFC3484 also specifies policy hooks to allow administrative override of the default address selection behaviour, for example to specifically prefer a source prefix for use with a set of particular destinations. It is thought that this policy-based address selection may be of benefit in renumbering events, or used in the development of bespoke renumbering tools. Multi-addressing also creates various issues with border filtering, discussed in detail in Section 7.2. 5.2. Multi-homing techniques A multi-homed site is a site which has multiple upstream providers. A site may be multi-homed for various reasons, however the most common are to provide redundancy in case of failure, to increase bandwidth, and to provide more varied, optimal routes for certain destinations. In renumbering, multi-homing will either be a temporary state, during the transition, or be a permanent feature of the network configuration, which may be being altered during the renumbering. 5.2.1. Relevance of multi-homing to renumbering As discussed in section 2, and in particular section 2.5, of [1], during the 'without a flag day' renumbering procedure there will be a period where both the old and the new prefixes are stable and valid for the network. During such a period, the network may be multi- homed, and as such many of the issues relating to multi-homing in IPv6 are also relevant, albeit in a small capacity, to the renumbering procedure. A stable multi-homed situation must therefore be a requirement for renumbering without a 'flag day'. In such a situation, however, the multi-homed state will not be permanent, and will only exist for the duration for which it is required, i.e. for the period during the renumbering procedure when both prefixes should be valid. Renumbering can also occur, however, in a network that is already multi-homed, for example with redundant links to multiple providers. Such a site may wish to renumber for any of the situations given in the earlier section, as well as renumbering because of changes in the Chown, et al. Expires March 22, 2007 [Page 12] =0C Internet-Draft Renumbering an IPv6 network September 2006 number of upstream providers. If at least one of the upstream links remains unchanged during the renumbering, however, then these links could be used exclusively for that period, alleviating some of the issues with prefix changes. The stable link(s) could therefore be the only prefixes advertised as valid for the 'stable state', with the removal of the old prefix and introduction of the new prefix being separate events. Until the best practice for the multi-homing situation is defined, however, its effect on renumbering is not a focus of this document. 5.2.2. Current situation with IPv6 multi-homing Unlike IPv4 multi-homing, where PI address space is relatively easy to obtain and thus a site can broadcast its own routing information, most IPv6 addresses will be PA addresses and thus the site will have no control over routing information. Multi-homing in IPv6 therefore does not necessarily exist in the same way as in IPv4 and the multi6 [38] working group was chartered to try to find a solution. Most IPv6 multi-homing solutions fall into the categories of either being host-centric, where it is the hosts that are multi-addressed, and choose which addresses to use, or site-based, where it is the site exit routers that decide which connections to use. The simplest solutions are extensions of the current multi-addressing techniques, but these suffer from the problem that, at some point, connections using the old addresses will be broken. The more advanced solutions [19], and in particular the solution taken forward into the shim6 [39] working group, examine the potential for splitting the 'identity' and 'location' features of IP, currently both represented by the IP address, and connecting to a host's identity, rather than its address, so that connections can continue unhindered across renumbering events. Such solutions are, however, very much in their infancy and as yet do not provide a stable solution to this problem. Support for the level of multi-homing required during a renumbering exercise is, however, mostly provided by multi-addressing (Section 5.1), since all that is primarily required is stable use of either prefix for a given period. The core issue remains, however, that at some point the connections using the old address will be broken when the addresses are removed. The impact of this can be limited as best as possible during the renumbering procedure. 5.3. Mobile IPv6 Mobile IPv6 (MIPv6) [18] specifies routing support to permit an IPv6 Chown, et al. Expires March 22, 2007 [Page 13] =0C Internet-Draft Renumbering an IPv6 network September 2006 host to continue using its "permanent" home address as it moves around the Internet. Mobile IPv6 supports transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. There are a number of issues to take into account when renumbering episodes occur where Mobile IPv6 is deployed: Renumbering a network which has mobile IPv6 active is a potentially complex issue to think about. In particular, can changed router advertisements correctly reach the mobile nodes, and can they be correctly renumbered, like a node on the local network? In addition, an even more complex issue is what happens when the home agent renumbers? Is it possible for the mobile nodes to be informed and correctly renumber and continue, or will the link be irretrievably broken? 5.3.1. Visited site renumbers when mobile When a node is mobile and attached to a foreign network it, like any other node on the link, is subject to prefix renumbering at that site. Detecting a new prefix through the receipt of router advertisements, the mobile node can then re-bind with its home agent informing it of its care-of address - just as if it had detached from the foreign network and migrated elsewhere. Where the node receives forewarning of the renumbering episode, the Mobility specification suggests that the node explicitly solicits an update of the prefix information on its home network 5.3.2. Home site renumbers when mobile When mobile, a host can still be contacted at its original (home) address. Should the home network renumber whilst the node is away but active (i.e. having bound to the home agent and registered a live care-of address), then it can be informed of the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages (sections 6.7 and 6.8 of RFC3775 [18] respectively). 5.3.3. Home site renumbers when disconnected Finally, if a mobile node is detached (i.e. no binding with the home agent exists with the node present on a foreign network) and the home network renumbers, the recommended procedure - documented as an appendix to the mobility specification and therefore not necessarily proven - is to fall back to alternative methods of 'rediscovering' its home network, using the DNS to find the new global routing prefix for the home network and therefore the Home Agent's subnet anycast address, 'guessing' at what the node's new home address would be on the basis of a 64 bit prefix and 64 bit interface identifier, and Chown, et al. Expires March 22, 2007 [Page 14] =0C Internet-Draft Renumbering an IPv6 network September 2006 then attempting to perform registration to bind its new location. 5.4. Multicast IPv6 supports an enriched model of multicast compared to IPv4 in that there are well-defined scopes for multicast communication that are readily expressed in the protocol's addressing architecture. Multicast features much more prominently in the core specification, for example it is the enabling technology for the Neighbour Discovery protocol (a much more efficient approach to layer 2 address discovery than compared to ARP with IPv4). Where multicast is used to discover the availability of core services (e.g. all DHCPv6 servers in a site will join FF05::1:3), the effect of renumbering the unicast address of those services will mean that the services are still readily discoverable without resorting to a (bespoke or otherwise) service location protocol to continue to function - particularly if (unicast) ULAs are not deployed locally as per Section 5.5. One issue related to IPv6 multicast and renumbering is the embedding of unicast addresses into multicast addresses specified in RFC3306 [20] and the embedded-RP (Rendezvous Point) in RFC3956 [21]. The former is purely a way of assigning addresses that helps with multicast address assignment, avoiding different sites from using the same multicast addresses. If a site's unicast prefix changes, then one will also need to change the multicast addresses. By way of example, a site renumbering away from prefix 2001:DB8:BEEF::/48" might have globally-scoped multicast addresses in use under the prefix "FF3E:30:2001:DB8:BEEF::/96". One may continue using the old addresses for a while, but this should be avoided since another site may inherit the prefix and they may end up using the same multicast addresses. The issue with embedded-RP is that, by definition, the RP address is embedded. So if the RP address changes, then the group addresses must also be changed. This may happen not only when a site is renumbered, but also if a site is restructured or the RP is moved within the site. The embedded address is used by routers to determine the RP address. Applications must use new group addresses once the RP is not available on the old address. Another interesting topic is multicast source renumbering. With traditional multicast a source should be able to start streaming from a new address, and nodes belonging to the multicast group will immediately start receiving. There might be some application issues though. If sources are identified by the source address only, then Chown, et al. Expires March 22, 2007 [Page 15] =0C Internet-Draft Renumbering an IPv6 network September 2006 this might appear as a new source to the receivers (as they would where IPv6 Privacy addresses are used). Using RTP a receiver may determine it's the same source. With Source Specific Multicast (SSM), source renumbering is more complicated since receivers must specify exactly which sources they want to to receive from. This means that receivers must somehow be told to join the new source addresses, and must be able to discover those addresses. 5.5. Unique Local Addressing Section 5 of [22] suggests that the use of Local IPv6 addresses in a site results in making communication using these addresses independent of renumbering a site's provider based global addresses. It also points out that a renumbering episode is not triggered when merging multiple sites that have deployed centrally assigned unique local addresses[23] because the FC00::/7 ULA prefix assures global uniqueness. The use of ULAs internally should ideally mitigate against global address renumbering of nodes, particularly as intra- site communication can continue unhindered by the change in global address prefixes due to provider migration or re-assignment of prefix from an upstream. ULAs appear to lend themselves particularly well for long-lived sessions (from the categorisation Section 4.2.3) whose nature is intra-site, for example local filestore mounts over TCP-mounted NFS: With clients using ULA source addresses to mount filestore using the ULA of an NFS server, both client and server can have their global routing prefix renumbered without consequence to ongoing local connections. When merging two sites that have both deployed FC00::/7 locally- assigned ULA prefixes, the chance of collision is inherently small given the pseudo-random global-ID determination algorithm of [22]. Consideration of possible collisions may be prudent however unlikely the occurrence may be. With reference to section 2 of [1], the adoption of ULA to assist in network renumbering can be considered a 'seasoning' of Baker's renumbering procedure: where interaction between local nodes and their services cannot suffer the inherent issues observed when migrating to a new aggregatable global unicast prefix, the use of FC00::/7 unique local addresses may offer an appropriately stable and reliable solution. Whilst on the surface, the use of ULAs in networks that also have global connectivity appears straightforward and of immediate benefit as regards provider migration, they currently suffer significant operational issues including address Chown, et al. Expires March 22, 2007 [Page 16] =0C Internet-Draft Renumbering an IPv6 network September 2006 selection, border filtering, name service provision and routing. If addresses under a global routing prefix are deployed alongside ULAs, then nodes will need to cater for being multi-addressed with multiple addresses of the same (global) syntactic scope, e.g. follow the principles laid out in RFC3484 [5]. The administrator should ideally be able to set local policy such that nodes use ULAs for intranet communications and global addresses for global Internet communications. Note in particular that address selection policy different from the defaults of RFC3484 are required for sites that have deployed ULAs whilst making use of multicast in scopes greater than link-scope (i.e. FFx3 and higher). 5.5.1. ULAs, Multicast and Address Selection For ordinary unicast traffic, the address selection rules of RFC3484 will function correctly. Assuming no higher-precedence rules are matched, a multi-addressed host will choose its source address through finding the address with the longest matching prefix compared with the destination address. This will pick global unicast addresses (i.e. within 2000::/3) for communication with other such addresses, and pick ULAs for other ULAs. This correct behaviour is dependent on sites running two-face DNS, however, and therefore ensuring remote sites do not know of non-routable ULAs. The key problem with ULAs and source address selection occurs, however, when sending to multicast addresses. When it falls to the longest matching prefix tests, a ULA will always come out as preferable to a global unicast address for matching a multicast (FF00::/8) address. This does not affect link-local multicast, however, as the preference for the appropriate scope will choose the unicast link-local address before looking at the longest prefix match (see Section 3.1 of RFC3484). For scopes wider than link-local, however, the ULA will by default always be chosen. Local policy needs to be implemented such that, e.g., global-scope multicast addresses have the same `label' as global aggregatable unicast addresses in RFC3484 parlance. Additional rules could also be added such that site- and organisational-scope multicast addresses prefer ULAs as source addresses, again by defining an appropriate label. Whilst no standard policy distribution mechanism exists for overriding default RFC3484 preference rules, [24] proposes the use of a DHCPv6 option in sites where stateful configuration is available. Chown, et al. Expires March 22, 2007 [Page 17] =0C Internet-Draft Renumbering an IPv6 network September 2006 5.5.2. ULAs with application-layer gateways The use of ULAs may not necessarily be accompanied by provider- assigned (PA) addresses in connected networks. If addresses under a PA global routing prefix are not used, application layer gateway deployment will be required for ULA-only nodes internal to the network to communicate with external nodes that are not part of the same ULA topology. Destination nodes that are addressed under FC00::/7 which are not part of the same administrative domain from which the ULA allocation of the local node is made, nor part of a predetermined routing agreement between two organisations utilising different ULAs for nodes within their own sites, would be filtered at the site border as usual. Typical deployments utilising this technique would include those networks where an administrative policy decision has been made to restrict those services available to the users, or where connectivity is sufficeintly intermittent that as few nodes as possible are exposed to the issues of ephemeral connectivity. 5.6. Anycast addressing Syntactically indistinguishable from unicast addresses, 'anycast' offers nodes a mean to route traffic toward the topologically nearest instance of a service (as represented by an IP address), relying on the routing infrastructure to deliver appropriately. RFC2526 [25] defines a set of reserved subnet anycast addresses within the highest 128 values of the 64 bit IID space. Of that space, currently only three are used, of which one is actively used and is for discovery of Mobile IPv6 Home-Agents. At the current time there are no 'global' well-known anycast addresses assigned by IANA. In order to participate using anycast, nodes need to be configured as routers (to comply with RFC3513 [17]) and exchange routing information about the reachability of the specific anycast address. This extra level of administration requirement is negligible in the context of services as the services themselves would need configuration anyway. There have been proposals to define globally well-known anycast addresses for core services, such as the DNS [26]. Anycast scales with regard subnet-anycast in the sense that the global routing prefix used to direct packets to an anycast node within a site is no different from any other host, and therefore nothing 'special' in the global routing architecture is required - only locally within the site does the multi-node nature of anycast need to be considered. Chown, et al. Expires March 22, 2007 [Page 18] =0C Internet-Draft Renumbering an IPv6 network September 2006 However, for global well-known anycast addresses to be defined, host- specific routes will need to be advertised and distributed throughout the entire Internet. As acknowledged by section 2.6 of [17], this presents a severe scaling limit and it is expected that support for global anycast sets may be unavailable or very restricted. A good discussion of best current practice for service provision using anycast addressing can be found in [27]. The use of well-known anycast addresses would assist the renumbering exercise by removing the requirement to change the addresses in the configuration of such services. The use of anycast DNS would alleviate concerns with ensuring node reconfiguration, for example when using Stateless DHCPv6 (Section 6.1.2). While anycasting datagram-based services such as DNS pose little problems, anycast does not maintain state, and so it would not be guaranteed that sequential TCP packets were to go to the same host. As discussed in [28], responses from TCP sessions begun to an anycast address should be sent from the unicast address, and future communication should continue with this address. While this means that communication will continue with the same unicast address, that address is subject to the standard address deprecation and validity. Note that anycasting of this form can be an alternative to site or organisational scope multicast service discovery as described in Section 5.4. 6. Node Configuration Issues This section discusses how IPv6 node configuration protocols (both stateless and stateful, including DHCPv6, as well as ICMP router renumbering messages) can be used to facilitate a renumbering event, plus any complications caused by these processes, to which consideration should be given. 6.1. Stateless Address Autoconfiguration Many IPv6 networks are likely to be configured using Stateless Address AutoConfiguration [6] (SLAAC), and in order to work through the multi-staged process as documented by Baker [1], the new prefix is introduced via router advertisements, and then the old prefix is deprecated, and finally removed. Initially the router advertisements will contain only the prefix of the old network, then for a time they will contain both the old and the new, but with a shorter (zero) lifetime on the old prefix to indicate that it is deprecated. Finally the router advertisements will contain only the new prefix. Chown, et al. Expires March 22, 2007 [Page 19] =0C Internet-Draft Renumbering an IPv6 network September 2006 6.1.1. Router Advertisement Lifetimes RFC2462 (IPv6 Stateless Autoconfiguration) [6] specifies the technique for expiring assigned prefixes and then invalidating them, such that a network has opportunity to gracefully withdraw a prefix from service whilst not terminally disrupting on-going applications that use addresses under it. Section 5.5.4 of RFC2462 in particular details the procedure for deprecation and subsequent invalidation. By mandating as a node requirement the ability to phase out addresses assigned to an interface, network renumbering is readily facilitated: subnet routers update the pre-existing prefix and mark them as 'deprecated' with a scheduled time for expiration and then advertise (when appropriate) the new prefix that should be chosen for all outgoing communications. 6.1.2. Stateless Configuration with DHCPv6 Sometimes, DHCPv6 will be used alongside SLAAC. SLAAC will provide the address assignment, and DHCPv6 will provide additional host configuration options, such as DNS servers. If any of the DHCPv6 options are directly related to the IPv6 addresses being renumbered, then the configuration must be changed at the appropriate time during the renumbering event, even though it itself does not handle the address assignments. Since the configuration is stateless, the DHCPv6 server will not know which clients to contact to inform them to refresh. Clients of the configuration protocol should poll the service to obtain potentially updated ancillary data, such as suggested by [29]. It is proposed that a new DHCPv6 service option is added to inform clients of an upper bound for how long they should wait before re-requesting service information. 6.1.3. Tokenised Interface Identifiers IPv6 Stateless Address Auto-configuration (SLAAC) enables network administrators to deploy devices in a network and have those devices automatically generate global addresses without any administrative intervention, and without the need for any stateful configuration service such as DHCPv6. However, certain services - such as HTTP, SMTP and IMAP - may better benefit from having 'well known' identifiers that do not depend on the physical hardware address of the server's network interface card, e.g. ::53 for name servers. Tokenised addresses offer a facility for administrators to specify Chown, et al. Expires March 22, 2007 [Page 20] =0C Internet-Draft Renumbering an IPv6 network September 2006 the bottom 64 bits of an IPv6 address for a node whilst allowing the top 64 bits (the network prefix) to be automatically configured from router advertisements. Currently, only more recent versions of Sun Microsytems' Solaris operating system features ioctl-configured support for tokenised interface identifiers, although recent work at Southampton has demonstrated that the configuration technique can be introduced trivially through simple kernel extensions in Linux. As regards renumbering, automatically configured tokenised addresses, where the network prefix component is learnt through router advertisements, ease the renumbering process where administrators have elected to use well known interface identifiers. Rather than having to manually reconfigure the nodes with the new addresses, the nodes can rely on automatic configuration techniques to pick up the new prefix. 6.2. Stateful Configuration with DHCPv6 As opposed to stateless autoconfiguration, IPv6 stateful or managed configuration can be achieved through the deployment of DHCPv6. Section 18.1.8 of [30] details how a node should respond to the receipt of stateful configuration data from a DHCPv6 server where the lifetime indicated has expired (is zero). Section 19.4.1 details how clients should respond to being instructed by DHCPv6 servers to reconfigure (potentially forceful renumbering). Section 22.6 details how prefix validity time is conveyed (c.f. the equivalent data in SLAAC's Router Advertisement). In order to renumber such a network, the DHCPv6 server should send reconfigure messages to inform the clients that the configuration has changed, and the clients should re-request configuration details from the DHCPv6 server. This, of course, relies on the clients correctly responding to such messages. Where DHCPv6 has been employed, careful consideration about the configuration of the service is required such that administrators can be confident that clients will re-contact the service to refresh their configuration data. As alluded to in sections 22.4 and 22.5 of [30], the configurable timers that offer servers the ability to control when clients re-contacts the server about its configuration can be set such that clients rarely (if ever) connect to validate their configuration set. The approach described in [29] allows the lifetime of other configuration information supplied by DHCPv6 to be ramped down in preparation for a planned renumbering event. Chown, et al. Expires March 22, 2007 [Page 21] =0C Internet-Draft Renumbering an IPv6 network September 2006 6.2.1. Prefix Delegation Where stateless autoconfiguration enables hosts to request prefixes from link-attached routers, prefix delegation enables routers to request a prefix for advertising from superior routers, i.e. routers closer to the top of the prefix hierarchy - typically topologically closer, therefore, to the provider. Once the router has been delegated prefix(es), it can begin advertising it to the connected subnet (perhaps even multi-link) with indicators for hosts to use stateful (DHCPv6) or stateless address autoconfiguration as per RFC2461. There have been two principal approaches to prefix delegation proposed: HPD (Hierarchical Prefix Delegation for IPv6), which proposed the use of bespoke ICMPv6 messages for prefix delegation, and IPv6 Prefix Options for Dynamic Host Configuration Protocol [31], which defines a DHCPv6 option type. Of the two approaches, the DHCPv6-based approach has received wide support and is on the standards track. 6.2.2. Source Address Selection Policy distribution It has been proposed that DHCPv6 could also be used to distribute source address selection policy to nodes [24]. The model proposes that consumer edge router receives policies (e.g. from multiple ISPs in the case of multi-homed networks) and re-distributes them to end nodes. The end nodes then put them into their local policy table, which leads to appropriate source address selection. Where the design goal was a distribution mechanism in light of multi-homed networks, the adoption of the technique for the multi-prefix states of [1] during renumbering appears appropriate. 6.3. Router Renumbering RFC2894 [7] defines a mechanism for renumbering IPv6 routers throughout a network using a bespoke ICMP message type for manipulating the set of prefixes deployed throughout subnets. Through the use of prefix matching and a rudimentary algebra for bit- wise manipulation of prefix data bound to router interfaces, the mechanism enables administrators to affect every router within a scope from a single administration workstation. One drawback of RFC2894 is that it requires an enterprise-wide IPsec infrastructure to be deployed to secure the ICMP messages in order to be compliant. The approach utilises multicast communication to the all-routers address, FF05::2, scoped to the entire 'site' as determined by router filter policy to distribute configuration updates to all (compliant) routers. The mechanism also works with more specific addressing Chown, et al. Expires March 22, 2007 [Page 22] =0C Internet-Draft Renumbering an IPv6 network September 2006 modalities, such as link-local multicast (FF02::2) to reach all routers on a specific link, or directed unicast to affect a specific router instance. When surveying current implementations very few IPv6 implementations bound their interfaces to the Site-wide All- Routers multicast address (FF05::2), and fewer still have implementations of RFC2894. Example use cases cited in RFC2894 are for deploying global routing prefixes across a hierarchical network where site-locals already exist (presumably updated now to Unique Local Addresses), and for renumbering from an existing prefix to another in a similar manner to that proposed by Baker (i.e. the deployment of a new prefix alongside the existing one, which is deprecated and subsequently expired and removed - using the same mechanism described). The specification was developed before the shift in recommendation away from the Top-, Next- at Site-Level Aggregation Identifier address allocation hierarchy of RFC3513, although the techniques documented for renumbering the global routing prefix and subnet ID components in the updated address allocation recommendations [17] are not affected by the architectural change. As with other prefix assignment techniques, it is the responsibility of the node to correctly deprecate and then expire the use of a previously assigned prefix as defined by the IPv6 Neighbour Discovery protocol, RFC2461 [8], section 4.6.2 describing the Prefix Information option in particular. 7. Administrative Considerations for Renumbering This section is concerned with factors that affect the renumbering procedure, from a network administration viewpoint. In particular, this section discusses areas that a network administrator should consider before undertaking a renumbering event, to ensure that it proceeds smoothly. This includes considerations of event frequency, scalability, and those relating to delays in information propagation. 7.1. Router Advertisement Lifetimes As discussed in Section 6.1.1, IPv6 Stateless Autoconfiguration allows the expiration of assigned prefixes. This process permits existing sessions to continue while preferring a new prefix. It should be noted, however, that there are some limitations in the specification that have an impact in renumbering. In particular, it is not possible to reduce a prefix's lifetime to below two hours if it has previously been available at a longer validity. This therefore emphasises the need to plan renumbering events in advance Chown, et al. Expires March 22, 2007 [Page 23] =0C Internet-Draft Renumbering an IPv6 network September 2006 if at all possible, to reduce the lifetime as required, within these limitations. 7.2. Border filtering Multi-addressing (Section 5.1) allows multiple globally reachable addresses to be assigned to node interfaces, but one administrative caveat that arises is that of site border filtering. Not only is it the norm for sites to filter at their border router traffic that is not destined to local subnets, but it is also increasingly common for sites to undertake egress filtering. This is often used to prevent administratively local addresses (such as the, now deprecated, site- local prefix) 'leaking' traffic, or for mis-configured hosts (e.g. visitors with manually configured stacks without Mobile IPv6) from sourcing traffic that cannot be routed back (cases of which may include deliberate IP spoofing or DDoS attempts). Providers often use ingress filtering so that the provider only accepts packets from customers that have source addresses inside the address space the provider has delegated to the customer. With multi-addressing, hosts in the site may send packets with source addresses from either provider's address space. If the providers do ingress filtering, a packet must then be forwarded out on the correct uplink, based on which source address the packet has. If the site has a common exit router for the two uplinks, that router will need to route the packets based on the source address. If the site has two different exit routers, the entire site backbone may need to route based on source addresses in order to forward the packets to the correct exit router. 7.3. Frequency of renumbering episodes The many different renumbering scenarios, discussed in Section 3, can have vastly different frequencies of renumbering events. In the case of a provider offering only dynamically assigned IP addresses, it could be very frequent, for example as frequent as 'per-connection' for dial-on-demand services, or weekly for some broadband services. Such renumbering events usually only occur when a customer reconnects to such services or are explicitly cited in a subscription agreement and as such are often pre-determined. The renumbering of a site due to upstream renumbering is relevant to all connections from a small dial-up link to a large enterprise. It is of particular interest since the end user has no control over the timing or frequency of the renumbering events. It is expected, however, that such events are likely to be very infrequent. The other irregular renumbering events are those that occur due to Chown, et al. Expires March 22, 2007 [Page 24] =0C Internet-Draft Renumbering an IPv6 network September 2006 end user migrating, either to a new provider, or to a new address allocation of their choosing. The timing of such an event is therefore often within the control of the end user (within reason), and are also likely to be one-off events, or at the very least, highly infrequent. 7.4. Delay-related Considerations When considering a renumbering event, both the planning of, and responses to the event are affected by temporal factors. The amount of time available in which to undertake the operation can change the administrative actions required, and this section aims to discuss some of these issues. 7.4.1. With or without a flag day A network may be renumbered with or without a flag day. In the context of this document we are focusing on without a flag day, although many of the issues will still apply when renumbering is effected with a flag day. Despite the similarities, because there is an outage of services when renumbering with a flag day, it is not necessary to ensure continuity of network connections, and almost all reconfiguration can be done during the outage, thus greatly simplifying the task of renumbering. 7.4.2. Freshness of service data One of the largest issues when renumbering a network will be the effect on applications that are already running. In particular, applications that periodically contact a particular host may do an initial hostname lookup, and cache the result for use throughout the lifetime of the program. In such a situation, there is no way for the application to find out that the host in question has been renumbered, and it should stop using its already cached address. It is therefore recommended that applications should regularly request hostname lookups for the desired hosts, leaving the caching to the resolver. It is then up to the resolver to ensure that resource record TTLs are observed, and its cached response is updated as necessary. Despite this, there is still a serious issue in that there is no method of caching resolvers knowing when a renumbering event is going to take place. If a typical RR's TTL is one day, then that should be reduced not less than a day before the renumbering event, so that resolvers will more frequently check for changed records. This will work successfully for a pre-planned renumbering event, but problems of stale, cached records will exist if the renumbering event is Chown, et al. Expires March 22, 2007 [Page 25] =0C Internet-Draft Renumbering an IPv6 network September 2006 unplanned (e.g. by receiving a new router advertisement from upstream). There are also cases where the use of a resolver is not practical, such as with packet filter rules. If a packet filter has been configured with explicit hostnames, these are translated to IP addresses for fast packet matching. The per-packet resolver function is highly undesirable from a pure performance perspective. Such a packet filter is likely to need to be reloaded for the DNS changes to be recognised. A similar problem exists when a nameserver is renumbered. If the operating system's resolver has cached the nameserver address, it will at some point find it unavailable. To mitigate this problem, it is suggested that at least one off-site nameserver is included in the configuration. In addition, well-known anycast addresses (see Section 5.6) could be used, so that the client's DNS configuration does not need to be changed at all during the renumbering event. The basic process of renumbering, involving the introduction of a new prefix and the deprecation and eventual removal of the old prefix, could be hypothetically handled by a special tool, with no manual intervention. Such a tool would have to become significantly more complex in order to handle all the cases where IP addresses are explicitly specified (a comprehensive list is given in Section 9.2). Other particularly notable cases that could be changed with a tool, were it to be developed, include DNS zone files and DHCPv6 configuration. Deployment of such a tool, even if possible, would be made complex through the requirement to authenticate the updates to each instance of the deployed literals. 7.4.3. Availability of old prefix The duration of the period where the old prefix remains available affects the length of time that can be allowed for the renumbering procedure, and the maximum time for which existing sessions could continue. If end users have control over the renumbering procedure (such as when changing provider), then they can continue providing the old prefix for as long as required, within reason (such as cost aspects). This heavily mitigates the issues of session survivability, and relaxes the speed at which hosts must be reconfigured. If the end users do not have such control, such as when the upstream provider forces the renumbering, the availability of the old prefix is determined entirely by the upstream provider's willingness to continue providing it, which is likely to be based on the technicalities of their own renumbering situation. The end user Chown, et al. Expires March 22, 2007 [Page 26] =0C Internet-Draft Renumbering an IPv6 network September 2006 should therefore not rely on retaining the old prefix for a relatively long period of time. In addition, many situations, such as dial-on-demand with dynamic IP addresses, and nomadic networks, will lose their old prefix quickly, if not almost instantaneously. It would be possible to continue using the old prefix internally, even when the external connectivity for that prefix is no longer active, for example to keep access to core services such as DNS servers while the transition is taking place. This should, however, be considered bad practice in case of route leaking and application confusion, as well as preventing access to the addresses if they have been reassigned, and as such this should only be used as a last resort to ensure internal continuity of service, if the availability of the old prefix is too short to allow a full transition to take place. 7.4.4. Duration of overlap A key operational decision when renumbering is enforced due to a change in connectivity provider is how long to sustain the overlap of two live prefixes. The trade-off to be made is the cost of maintaining two contracts with separate providers against the 'smoothness' of the transition to the new prefix as regards local administration overheads, service migration, etc. Where larger corporations can likely suffer the increased financial costs, SMEs and SOHOs might consider as little as one month's overlap too expensive, and so Baker's State 5 (Stable use of either prefix) [1] is unattainable in such scenarios. In some cases, there may be technical reasons for the overlap to not be feasible, such as with xDSL provision where the new service is a drop-in replacement for the old and the two cannot co-exist (for example, because the provision of the service requires the whole circuit resource from exchange to customer). 7.5. Scalability issues During the renumbering transition, there will be a time when two prefixes are valid for use. At this point, there will be a considerable amount of configuration that will have to be (temporarily) duplicated. In particular, routing entries on the hosts will be doubled, and there will, for a short period, be two forward DNS records for every hostname. Security is another key scalability issue. All access control lists, packet filters, etc, will need to be updated to cope with the multiple addresses that each host will have. This could have a noticeable impact on packet filter performance, especially if it lead to, for example, the doubling of several hundred firewall rules. Chown, et al. Expires March 22, 2007 [Page 27] =0C Internet-Draft Renumbering an IPv6 network September 2006 The scalability issues created by the increase in configuration to cope with the temporary existence of multiple addresses per host adds a complexity in management, but how much so is up to the end-users themselves. A user may choose to do direct transitions of some services (such as web servers) from one IP address to another, without going through a stage where the service is available on all addresses. While that is not strictly providing a fully seamless transition, it could significantly reduce the management complexity, without a significant impact on service, especially if the DNS updates are rapid. It should also be noted that during a renumbering event, since the DNS resource record TTLs are significantly shorter, the primary DNS servers for the domains will receive significantly more queries, as resolvers should not cache the responses for so long, and will regularly check back with the master. The likelihood of this having any significant impact is, however, fairly minimal, at least in a typical small to medium site. Section 3.1 of Baker [1] is aptly titled "Find all the places", and serves as a gentle reminder to application developers that embedding addresses is bad at best. Where common UNIX tools such as "grep" allow administrators to crawl the file systems of servers for places where address information is hard-coded, the proliferation of technologies such as NetInfo and other directory- or hive-based configuration schemes makes the job of finding all the places that addresses are hard-coded intractable. Beyond the call to arms for application and services developers made by Baker et al. [1], and specific to the challenges of renumbering, the following security and policy-related services that initial research has flagged as particularly troublesome: 7.5.1. Packet filters, Firewalls and ACLs Throughout the transition from the old address set to the new, all packet filters and firewalls will need to adapt to map policy to both prefixes (sets of addresses) - perhaps even selectively as the old addresses become deprecated. Whilst technologies such as Router Renumbering and Neighbour Discovery automate to a large extent the transition of router and node configurations, and dynamic DNS update for the re-mapping of resource records to reflect the new addresses [32], no such mechanism exists at present for mechanising the adaption of security policy. Particularly troublesome policies to administer include egress filtering, where packet filters discard outbound packets that have source addresses that should not exist within the site, and filtering Chown, et al. Expires March 22, 2007 [Page 28] =0C Internet-Draft Renumbering an IPv6 network September 2006 inbound site-local addresses in cases where two organisations are renumbering as a step toward merging their networks together (although the use of site-local addressing is now deprecated). Where renumbering is due to a 'clean break' from previous connectivity provider, another consideration is for the ingress filtering performed by the provider. For instance, the new provider may refuse to receive into their routing topology those packets whose source address is under the old prefix, and likewise for the old provider and new prefix. Whilst it is not the business of the IETF to mandate business practice, it is likely that the provision of out- of-allocation prefix routing as part of a multi-homing service contract would be a chargeable service and not one that an enterprise trying to make a clean break away would likely be willing to pay just for the duration of transition to their new prefix. Beyond the immediate up-stream provider, there are other policy-based considerations to take into account when renumbering. Some rudimentary authenticated access mechanisms rely on access queries coming from a particular IP network, for example, and so those application service providers will need to update their access control lists. Likewise all the internal applications (possibly meant for 'internal' eyes only) will have to have their access controls updated to reflect the change. The use of symbolic access controls (i.e. DNS domain names) rather than embedded addresses may serve to mitigate much of the distributed administrative load here, at least if such symbols are re-resolved, especially during the mid- renumbering states where both sets of addresses are still live and valid. 7.5.1.1. Policy rule replication where both prefixes valid One key caveat with policy application during a renumbering prefix concerns rules that are 'tied down' at both ends to (sets of) addresses under the prefix to be renumbered, i.e. those that detail specific nodes or subnets in both source and destination elements of the policy rule as opposed to source 'any' or destination 'any'. Examples of where this approach apply include specific holes punched through a packet filter between a DMZ and the internal network, e.g. for staged access to compute servers from off-site. A dilemma here is that the otherwise 'ideal practice' use of symbolic names to identify elements in the network may not be appropriate in policy rules. This is particularly the case where resolver libraries do not return all bound resource data for symbols (i.e. old and new AAAA records for www.example.com), or where policy applications do not iterate across all returned resource record data in resolvers Chown, et al. Expires March 22, 2007 [Page 29] =0C Internet-Draft Renumbering an IPv6 network September 2006 that are well behaved. It also assumes that name service data is updated ahead of policy application, which is ill-advised given that the instant name servers start serving data regarding new, yet to be configured, addresses for nodes. 7.5.2. Monitoring tools Network monitoring and supervisory utilities such as RMON probes, etc., are often deployed to monitor network status based on IP traffic. During a renumbering episode, the addresses for which the probes should monitoring and the addresses of logging services to which the probes report (e.g. in the case of remote SNMP logging) need to be tracked. "Helpdesk ops" service liveness monitoring software also poses a particular problem where liveness is determined, for example, by a null transaction (e.g. for POP3 mail server, authenticating and performing a NOOP) made against a named service instance, if the name is by IP then two instances of the liveness test will be required: one on the old address to cater for those remote parties that are not yet aware of the new address, and one test against the new. As part of the renumbering process, it may be advantageous to deploy flow analysis tools that can be scripted to alert administrators on observation of particular traffic patterns, e.g. flows to a service under a deprecated prefix during transitions where both old and new prefixes are live and routed to the site concurrently. This can highlight, for example, mis-cached DNS resource records, sources of manually configured service location data, etc. When relying on DNS labels for identifying nodes to administer, care must be taken to ensure that the complete set of nodes administered are caught. For instance, a set of application servers may share the same DNS label and rely on DNS round-robin for rudimentary load balancing (a modality at odds with the notion of maintaining resource records for both old and new prefixes during renumbering episodes). A network monitoring tool that was configured to monitor just that service that was resolved by address lookup might only capture one of that set of nodes. 7.6. Considerations with a Dual-Stack Network There are several issues to consider when renumbering a dual-stacked network. In the simplest case, the IPv4 addresses will be remaining the same while the IPv6 addresses are renumbered. This could, for example, be due to an upstream renumbering, a change of IPv6 transition method (such as a tunnel), or a topology change. In such a case, the IPv4 connectivity remains unchanged, and as such can be Chown, et al. Expires March 22, 2007 [Page 30] =0C Internet-Draft Renumbering an IPv6 network September 2006 used as a fallback during the renumbering to assist with session continuity, DNS services, etc. The other case is when the IPv4 network is being renumbered along with the IPv6 network. Again this could be due to an upstream change, a network reconfiguration, or because the two are inter- linked - such as with the 6to4 transition mechanism. In this case, it is unlikely that the existence of IPv4 on the network can be used for any advantage, and instead many of the same issues are likely to be found when renumbering the IPv4 network as for the IPv6 network, except for the fact that more of the renumbering must be manually configured, for example by reconfiguring the stateful IPv4 DHCP configuration, or even manually configuring IPv4 addresses. A hybrid case is also possible, where IPv4 NAT is used on the internal network, but with globally routable IPv6 addresses. In this case, if both networks' external connectivity is being renumbered, the internal network will only see the effect of the IPv6 renumbering, while keeping the IPv4 addresses the same. The renumbering procedure will still have an impact on the IPv4 connectivity and its session survivability, however. It may also be possible that the site uses both global and ULA IPv6 prefixes, the ULA prefix being deployed to avoid impact to long-running IPv6 sessions. 7.7. Equipment administrative ownership The question of who owns and administers (also, who is authorised to administer) the site's access router is an issue in some renumbering situations. In the enterprise scenarios, the liaison between the end users and remote administrators is likely to be relatively easy; this is less likely to be the case for a SOHO scenario. This is not likely to be a major issue, however, since SOHO renumbering is likely to only be required if the remote administrators deem it necessary, or if the end user is sufficiently technically competent and decides to renumber their own network. 8. Impact of Topology Design on Renumbering This section looks at considerations regarding network design, such as network merging, and design-time recommendations that can help avoid the need for a network renumbering event. 8.1. Merging networks Renumbering of all or part of a network due to merging two or more smaller networks has many of the concerns already discussed, but it Chown, et al. Expires March 22, 2007 [Page 31] =0C Internet-Draft Renumbering an IPv6 network September 2006 may not affect the whole network. For example, multiple disparate networks may be merged together as one entirely new subnet, and thus all hosts must be renumbered; but it is also possible that one of the networks in the merger retains its prefix, and the other network(s) merge with it. When the networks merge, the router advertises itself, and the new prefix if appropriate, to the new hosts, and Duplicate Address Detection (DAD, see Section 5.4 of [6]) must be applied by the new hosts to ensure they are not taking addresses already assigned to the existing hosts. It is implementation-dependent, however, as to whether the DAD algorithm will be re-run on link-local addresses if the network configuration is changed, so there is the possibility of an address conflict. However, as is noted in RFC2462, DAD is not completely reliable, and as such it cannot be assumed that initially after a network merge all link-local addresses will be unique. 8.2. Fixed length subnets The IAB/IESG recommendations for IPv6 address allocations [10] details some of the motivations behind the change in the addressing architecture of IPv6 since its inception, and asserts the current state of a 64-bit 'network' part (the prefix) and a 64-bit 'host' part (the interface identifier). Fixing the lower 64 bits to be exclusive of routing topology significantly reduces the administrative load associated with renumbering and re-subnetting as experienced with IPv4 networks previously, for example, to get better address utilisation efficiency as networks evolve and provider address allocations changed. The recommendations also discuss what length of network prefix should be allocated to sites, typically provisioning for 16-bits of subnet space in which sites can build their topology. Having such a large address space for sites to divide up at their discretion alleviates many of the drivers for renumbering discussed during the PIER working group's lifetime [3]. 8.3. Use 112-bit prefixes for point-to-point links It is recommended that point-to-point links, such as tunnel endpoints or router-router links, are allocated /112 subnets from a single /64 within the site's allocation. This simplifies policy-based filtering and is less wasteful of address space than using /64s everywhere, improving the address utilisation ratio for the site that would in extreme cases lead to a larger prefix becoming required. The 112-bit prefix length is preferred to 127-bit on the advice of RFC3627[33], which suggests that such allocations can lead to end- Chown, et al. Expires March 22, 2007 [Page 32] =0C Internet-Draft Renumbering an IPv6 network September 2006 point address starvation where one router elects to take both the zeroth address in the /127 as a subnet router anycast address and the first address for its endpoint, leaving no address for the remote end of the link. 8.4. Plan for growth where possible When designing address topology - particularly in ISP and larger- scale Enterprise sites - it is recommended that network designers plan for growth of lower hierarchies under their provision (e.g. a /60 satellite site becoming big enough for a /56; a /48 customer getting sufficiently large as to warrant a shorter prefix). Techniques for such allocations include centre-most bitset growth as described in Section 3.3 of RFC3531 [17], which leave the bits nearer upstream and downstream bit-boundaries until much later in the allocation selection set, meaning that a boundary shift has minimal impact on existing deployed allocations. However the overheads and non-contiguous nature of successive allocations may not suit Enterprise sites, meaning that other allocation strategies are required, contextually sensitive to the demands of the site in which the prefixes are being deployed. In enterprise networks where satellite sites participate, it is recommended that single-subnet blocks are skipped in the allocation such that remote satellites can grow (double) without requiring those `nearby' in the address block to renumber. For example, the strategy taken in an enterprise with 56-bit prefixes allocated to satellites is to leave subsequent /56s for future expansion of each sub-tier to a /55. Note that strictly adopting RFC3531 may be insufficient in enterprises where, for example, there is a mix of subnet provision (e.g. for satellite sites) and end-user subnets. 8.5. IPv6 NAT Avoidance RFC2072 stated: "Network address translation (NAT) is a valuable technique for renumbering, or even for avoiding the need to renumber significant parts of an enterprise." That is, by 'hiding' the subnet topology and making independent of any connectivity provider the addressing model used within a site, NATs enable renumbering of entire networks because the only device that is renumbered when global addressing changes is the outside edge of the NAT devices. However, NAT is strongly discouraged in IPv6, not least because it breaks end-to-end transparency (as described in [34]) and obscures Chown, et al. Expires March 22, 2007 [Page 33] =0C Internet-Draft Renumbering an IPv6 network September 2006 identity - including the basis for permission, authorisation, verification and validation - and thus should not be considered as being available as a solution. A significant reason to deploy IPv6 is to simplify network and application operation by (IPv4) NAT removal, for example to provide true end-to-end connectivity, to make simple the gateway between site and Internet, to encourage 'considered' policy for secure access rather than rely on the (relatively) dangerous defence of 'hiding' behind a NAT. A more detailed discussion of the motivations for 'protecting' the network architecture from NATs can be found in [35]. 9. Application and service-oriented Issues In this section we highlight issues and common approaches to software development that 'disrupt' protocol layering to the extent that applications become aware of renumbering episodes, even if catastrophic and without knowing how to recover without failing. NOTE: This section, like the discussion sections before it, will evolve as experience grows researching the various renumbering strategies in controlled experiments - particularly in light of Section 10.1. 9.1. Shims and sockets As discussed in Section 7.5, Baker's draft calls for application developers to consider the effects of renumbering whilst applications are 'live', particularly as regards caching the results of symbol resolution. Where applications maintain open connections to services over a sustained period of time (as opposed to the ephemeral nature of protocol interactions such as with HTTP), any change in either end's addressing may intrude on the application's execution - particularly if the change is abrupt or the session longer than the expiry and withdrawal time of the old addresses. Various options may be available to minimise the risk of application disruption in this instance. A HIP-like 'shim' [36], as is being developed as a candidate solution to the general multi-homing problem, removes the tight coupling between a connection and a service's topological location: as the renumbering event takes place, the locator is updated to reflect the new address topology, and the application remains blissfully unaware - a form of layer 3.5 mobility. Alternatively, should the old address space be available such that a single (or subnet of) Mobile IPv6 Home Agents be deployed in the routing path of the to-be-otherwise-interrupted connection, then the Chown, et al. Expires March 22, 2007 [Page 34] =0C Internet-Draft Renumbering an IPv6 network September 2006 endpoint being renumbered could utilise layer 3 mobility once the old prefix is removed from its link, i.e. register with the Home Agent in the old prefix topology - presumably in the provider's network, formerly upstream from the site - and rely on Mobile IPv6 route optimisation to make good the additional overhead imposed by the reverse tunnelling to the new prefix. Applications that employ SCTP as opposed to TCP or UDP for communication avoid all of the issues highlighted in this sub-section due to the provision of dynamic endpoint reconfiguration in the protocol (see Section 4.2). 9.2. Explicitly named IP addresses There are many places in the network where IP addresses are embedded as opposed to symbolic names, and finding them all to be updated during a renumbering episode is not a trivial task. This section details an evolving list of such places as surveyed as common. Addresses may be hard-coded in software configuration files or services, in software source-code itself (which is particularly cumbersome if no source is available, e.g. a bespoke utility built to order), in firmware (for example, an access-controlling hardware dongle), or even in hardware, e.g. fixed by DIP switches. A non-exhaustive list of instances of such addresses includes: o Provider based prefix(es) o Names resolved to IP addresses in firewall at startup time o IP addresses in remote firewalls allowing access to remote services o IP-based authentication in remote systems allowing access to online bibliographic resources o IP address of both tunnel end points for IPv6 in IPv4 tunnel o Hard-coded IP subnet configuration information o IP addresses for static route targets o Blocked SMTP server IP list (spam sources) o Web .htaccess and remote access controls Chown, et al. Expires March 22, 2007 [Page 35] =0C Internet-Draft Renumbering an IPv6 network September 2006 o Apache .Listen. directive on given IP address o Configured multicast rendezvous point o TCP wrapper files o Samba configuration files o DNS resolv.conf on Unix o Any network traffic monitoring tool o NIS/ypbind via the hosts file o Some interface configurations o Unix portmap security masks o NIS security masks o PIM-SM Rendezvous Point address on multicast routers Some hard-coded IP address information will be held in remote locations, e.g. remote firewalls, DNS glue, etc. adding to the complexity of the search for all instances of the old prefix. Should symbols be used rather than addresses, administrative ownership of DNS - with due consideration for the TTL of resource records - and other naming services ease this particularly problematic issue of data ownership and validity. There are also cases when IP addresses are embedded into payload data, such as with UDP-based NFS mounts and FTP sessions. These cases were discussed in more detail in Section 4.2.4. 9.3. API dilemma In light of Section 7.4.2, there is an open question as to whether we need an extension to the sockets API that would allow applications resolving addresses to be able to determine the freshness of the resolved data. A straw poll of networking applications demonstrated that common programming practise is to 'resolve once, bind many' during the lifetime of an application, caching the initial lookup result and assuming that it is still valid throughout. Whilst this is a perfectly valid approach for short-lived applications, where the chance of renumbering - site or the single node - increases with regards the longevity of the application, the likelihood of the resolved data being intrusively inaccurate also increases. Chown, et al. Expires March 22, 2007 [Page 36] =0C Internet-Draft Renumbering an IPv6 network September 2006 Application programmers should therefore consider the possibility of network renumbering when writing socket software. The best behaviour is probably to freshly resolve for any socket binding, and let the resolver handle the caching, based on the DNS TTL. Only when there are a significant number of connections within a short timeframe should application-level caching be considered. 9.4. Server Sockets Certain applications create a server socket and bind the socket so that they only receive connections or datagrams at one specific address. These services typically keep the socket bound to that address until they are shut-down or restarted. This means that if the host is configured with a new address, these applications would not respond to that address. If the applications were listening to the wildcard address, they would also accept connections and datagrams on new addresses as they become configured on a node. An example would be a webserver, which may in fact bind to multiple different IP addresses to serve content for different domains where the particular business case is for customers to be allocated their 'own' IP address (e.g. for reverse DNS to reflect their branded domain name). A typical work-around would be to schedule a restart of all such services having first identified whether they can operate on both address prefixes (to satisfy the middle states of Baker [1]), or at least to schedule their migration to the new address configuration in light of the DNS name bindings (considering caches and TTL), and the nature of existing clients that may still be bound to the old service (consider graceful migration). One possible solution, not implemented in existing socket APIs, would be to allow servers to bind to just the lowest 64 bits of an address, allowing the network identifier to change without the server knowing. This is a purely hypothetical solution, however, and has numerous issues, not least regarding requirements of some server software to know its current globally routable IP address. 9.5. Sockets surviving invalidity When an address expires (validity lifetime falls to zero), addresses are to be removed from interfaces, and the expired address is not to be used as a source address for further packets (see RFC2462 section 5.5.4 and RFC2215 secion 10). Chown, et al. Expires March 22, 2007 [Page 37] =0C Internet-Draft Renumbering an IPv6 network September 2006 However, it appears that for an established TCP session or for UDP where the application has bound to a specific address, many stack implementations keep using the same source address blindly putting packets onto the wire, even if the address is removed from the interface. It appears that these stack implementations make sure the address is valid when the TCP session is created or when an application binds to an address on a datagram socket, but once the socket is bound to that address there are no more checks. Whilst this is not a serious issue - certainly, no reply packets could be received as the interface will not listen for them, and it is likely that the prefix would no longer be routable at the next-hop router beyond the point of invalidation - it does mean that application data will be lost up until that point where the transport layer determines that the packets are not being received (e.g. TCP ACKs). 9.6. DNS Authority It is often the case in enterprises that host web servers and application servers on behalf of collaborators and customers that DNS zones out of the administrative control of the host maintain resource records concerning addresses for nodes out of their control. The upshot here is that when the service host renumbers, they do not have sufficient authority to change the AAAA records, etc., that refer to newly renumbered addresses. It is recommended that remote DNSes maintain CNAME records to labels in a zone that is under the authoritative control of the enterprise whose addresses are referenced. 10. Summary This memo has further motivated the issue of network renumbering, highlighted important requirements to ensure that episodes can pass smoothly with a minimum of disruption to users, and indicated a number of protocol features and technologies that assist network designers and operators in the smooth transition from one prefix to another, all in the context of [1]. 10.1. IETF Call to Arms Validation surveys of address selection implementations per RFC3484, of address expiry per RFC2462 and RFC3315, and operational experience Chown, et al. Expires March 22, 2007 [Page 38] =0C Internet-Draft Renumbering an IPv6 network September 2006 validating the Baker et al. procedure have been carried out and reported on in other fora (e.g. in D3.6.1 of the 6NET project). However, in the above considerations, a number of actions would be most helpful in advancing the understanding of the practical implications and robustness of IPv6 renumbering. These include: o Survey of the pervasiveness of address literals and steps to avoid their use o Validation of address selection at source and destination during various stages of Baker's renumbering procedure in implementations other than Cisco IOS, FreeBSD 5.9, Linux 2.6, Macintosh OS/X 10.4, Sun Solaris 8-10, Microsoft Windows XP SP2 o Validation of RA lifetime expiry and confirmation of prefix removal and effects on existing sessions in other implementations o Validation of IPv6 Prefix Delegation by DHCP, and of IPv6 Router Renumbering o Better understanding of the commonalities and differences between renumbering and multi-homing o Anecdotal experience of IETF members that have undertaken an IPv6 renumbering exercise, e.g. in the transition from 3FFE::/16 6Bone addresses to production GAU Given that this memo is dressed as a set of "things to think about", there is no conclusion other than a call for input from the IETF community. There may be a case to be made to reopen the PIER WG in the new context of IPv6, although that group has not been active since 1997. 11. IANA Considerations This document makes no request of IANA. 12. Security Considerations The security considerations as outlined in [1] still hold, with the following supporting comments... (tbd) 13. Acknowledgements Chown, et al. Expires March 22, 2007 [Page 39] =0C Internet-Draft Renumbering an IPv6 network September 2006 The authors gratefully acknowledge the many helpful discussions and suggestions of their colleagues from the 6NET consortium, particularly Fred Baker, Graca Carvalho, Ralph Droms, David Mills, Thorsten Kuefer, Eliot Lear, Christian Schild, Andre Stolze, Tina Strauf, Bernard Tuy, and Gunter Van de Velde. 14. References 14.1. Normative References [1] Baker, F., "Procedures for Renumbering an IPv6 Network without a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in progress), March 2005. [2] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser, "Enterprise Renumbering: Experience and Information Solicitation", RFC 1916, February 1996. [3] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997. [4] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. [5] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [6] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 14.2. Informative References [9] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [10] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [11] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004. Chown, et al. Expires March 22, 2007 [Page 40] =0C Internet-Draft Renumbering an IPv6 network September 2006 [12] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-24 (work in progress), January 2005. [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [14] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-05 (work in progress), March 2006. [15] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [16] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp-15 (work in progress), June 2006. [17] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [18] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [19] Huston, G., "Architectural Approaches to Multi-Homing for IPv6", draft-ietf-multi6-architecture-04 (work in progress), February 2005. [20] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [21] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [22] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in progress), January 2005. [23] Hinden, R. and B. Haberman, "Centrally Assigned Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-01 (work in progress), February 2005. [24] Matsumoto, A., "Source Address Selection Policy Distribution for Multihoming", draft-arifumi-multi6-sas-policy-dist-00 (work in progress), October 2004. Chown, et al. Expires March 22, 2007 [Page 41] =0C Internet-Draft Renumbering an IPv6 network September 2006 [25] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. [26] Jeong, J., "IPv6 Host Configuration of DNS Server Information Approaches", draft-ietf-dnsop-ipv6-dns-configuration-06 (work in progress), May 2005. [27] Abley, J. and K. Lindqvist, "Operation of Anycast Services", draft-ietf-grow-anycast-04 (work in progress), July 2006. [28] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [29] Venaas, S. and T. Chown, "Information Refresh Time Option for DHCPv6", draft-ietf-dhc-lifetime-03 (work in progress), January 2005. [30] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [31] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [32] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [33] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003. [34] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [35] Velde, G., "IPv6 Network Architecture Protection", draft-ietf-v6ops-nap-03 (work in progress), July 2006. [36] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", draft-ietf-hip-arch-03 (work in progress), August 2005. URIs [38] [39] Chown, et al. Expires March 22, 2007 [Page 42] =0C Internet-Draft Renumbering an IPv6 network September 2006 Authors' Addresses Tim J. Chown University of Southampton, UK Electronics and Computer Science University of Southampton Southampton SO17 1BJ UK Phone: +44 23 8059 5415 Fax: +44 23 8059 2865 Email: tjc@ecs.soton.ac.uk Mark K. Thompson University of Southampton, UK Email: mkt@ecs.soton.ac.uk Alan Ford University of Southampton, UK Email: ajf101@ecs.soton.ac.uk Stig Venaas University of Southampton, UK Email: sv@ecs.soton.ac.uk Chown, et al. Expires March 22, 2007 [Page 43] =0C Internet-Draft Renumbering an IPv6 network September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chown, et al. Expires March 22, 2007 [Page 44] =0C --------------030004030806000107010106 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --------------030004030806000107010106-- From ram-bounces@iab.org Sat Aug 04 06:41:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHH4P-0005mZ-6W; Sat, 04 Aug 2007 06:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHH4O-0005mT-Gg for ram@iab.org; Sat, 04 Aug 2007 06:41:16 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHH4M-00079h-Vs for ram@iab.org; Sat, 04 Aug 2007 06:41:16 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 5516C1A34A; Sat, 4 Aug 2007 12:41:14 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id B6B1F1A322; Sat, 4 Aug 2007 12:41:13 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Aug 2007 12:41:23 +0200 To: Brian E Carpenter , Thomas Narten From: JFC Morfin Subject: Re: [RAM] First cut at routing & addressing problem statement In-Reply-To: <46B31EC7.7040904@gmail.com> References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> <46B31EC7.7040904@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070804104113.B6B1F1A322@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 14:25 03/08/2007, Brian E Carpenter wrote: >Content-Transfer-Encoding: 7bit > >>We would welcome comments on the document. In particular: >> - Do folk agree with the problem statement as written, or are we >> missing something fairly fundamental? > >Yes. I think it's correct to keep it down to the bare bones. Fairly fundamental: yes. - What an address is? - UP as the User Protected address area. Any ROAP network centric solution will only meet the same problem which is user centric reality. - all the discussed figures are based upon the source of the problem: number limited by constraints. The solution must support billions of AS (real and virtual), routing planes. Every host must be PI-able. >> - Are there other pressures on the routing system that we have not >> listed or described completely? > >Not that I noticed. Just introduced a big one. TE must be possible by individual users. >> - We intentionally did not include improving mobility as a core >> "problem", as explained in the document. (That doesn't mean we >> don't recognize that some of the solutions under discussion may >> also be applicable to mobility scenarios. Rather, we tend to see >> improved mobility as a possible benefit of certain classes of >> solutions.) > >I think this is correct. In many ways mobility is an overlay >on a routing system assumed to be stable and scaleable. I am afraid this is incorrect. Addresses must be defined first: as possibly made of a stable, mobile, and virtual part (parts in case of multilevel). If every host is considered for what it is: a virtual system hosted by a mobile machine plugged into a stable plug, the solution should be unique. You can also phrase: address = PA + PI + UP. The problem is much clearer if these three spaces are made orthogonal. >> - Are there other views of what folk perceive the core routing and >> addressing problem to be? > >Not here. Addressing and routing are not ex-nihilo. They happen in a real network context. The other missing point in the statement is the Plan (as in NIMROD but probably with an adjancy focus). To understand this, let assume that a complete multi-level solution has been found, and there is no more problem. I will therefore have access to a certain level of TE, as a user, an ISP, a Government, of the IGF. I will then be able build the plan of my own virtual network infrastructure, and develop an higher level ROAP (routing addressing planning system) atop of it. This solution may in turn scale into higher virtuality levels. In doing this I would create a fractality break in traffic support: at some point [entering your solution from mine] the architectural vision changes. I accept to bet it can work and that the whole thing can support the semantic networking layers I am interested in. But I doubt it will be optimal. So, it means that under the upper layers needs, the Internet layers solution will have to be adapted, leading to three simultaneous approaches (the current one, the solution to the current problem statement, the new approach needed by semantic network development). This is why I suggested that one first considers the problems resulting from the current IETF paradigm, as summarized by the community two years ago in RFC 3935. Then consider which paradigm improvements (like for example switching from decentralization to distribution) could simplify or generalize the problem at hand. jfc PS. Some will probably disregard this post in claiming that it is a troll. Others will try to understand where I come from. I consider four general communication layers: telecoms between devices, datacoms between agents, metacoms between brains, syllocoms within comprehension systems. I currently focus on metacoms as a support to syllocoms exploration. Network System theories seem to apply to them all as in any four successive network layers (along fractality and subsidiarity rules). Semantic networking is currently supported at the Internet layer (data) and at the metacoms layer (metadata) but in most of the cases as a layer violation (ex. RFC 4646) because metacoms have not been identified as such by the IAB. Inconsistency between these layers seems to translate, as for every other layers, by layer violations and rigidities. At its datacoms engineering level IETF should benefit from the IAB guidance to correctly position its work in such a generalized communication model. The problem ROAP translates is that the IAB does not build requirements from reality, but from consistency with the initial prototype. IAB/IETF tunes the network (RFC 3935: "make it work better") rather than build it. I fully understand the need to keep the existing past solutions in tune with present needs. But not to the point to conflict with our future. I only make the capacity of the investigated solution to _also_ support the past as a validation criteria. In the Multilingual Internet case, the problem was the confusion introduced by the RFC 4646 initial proposition (because it would go through due to its sponsors). It was therefore vital that its text and context be clarified and constrained. This was done (but unfortunately not respected). So far, in this case I see no other bigger danger than delays for all. Two years ago I considered that IPv6 "UP" (see above) could be directly related to semantic addresses, giving them a universal common reference and an IPv6 killing application. ISO 3166-1:2006 shown the simplicity and power of polynymy (concept name/address invariance across languages). This uncouples digital and semantic addressing (including its DNS part: I gave an example with cctags). _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 06 05:10: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 1IHybF-0008FO-0i; Mon, 06 Aug 2007 05:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHybE-0008FJ-E1 for ram@iab.org; Mon, 06 Aug 2007 05:10:04 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHybD-0000uh-0R for ram@iab.org; Mon, 06 Aug 2007 05:10:04 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id B36341C008F; Mon, 6 Aug 2007 11:10:01 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id AEA681C007E; Mon, 6 Aug 2007 11:10:01 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A0E7158ECC9; Mon, 6 Aug 2007 11:10:01 +0200 (CEST) Date: Mon, 6 Aug 2007 11:10:01 +0200 From: Stephane Bortzmeyer To: Gert Doering Message-ID: <20070806091001.GA27102@nic.fr> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070803095100.GF69215@Space.Net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Robin Whittle , ram@iab.org Subject: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, Aug 03, 2007 at 11:51:00AM +0200, Gert Doering wrote a message of 44 lines which said: > with proper planning in the setup phase (and that means "not putting > IP addresses in places that should have server names"), renumbering > is not painless, And if programmers were doing their jobs properly (abstraction, encapsulation, use of well-defined APIs, etc), moving applications to IPv6 (or any sort of IP/loc separation) would be trivial. But the problem statement we refer to is about the real world :-( _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 06 05:57:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHzL9-0004Ue-VZ; Mon, 06 Aug 2007 05:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHzL6-0004UN-K9 for ram@iab.org; Mon, 06 Aug 2007 05:57:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHzL6-00020H-79 for ram@iab.org; Mon, 06 Aug 2007 05:57:28 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2007 11:57:24 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIaNtkaQ/uCLh2dsb2JhbACBUoxCAQEBCAon X-IronPort-AV: i="4.19,224,1183327200"; d="scan'208"; a="149865822:sNHT2335239114" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l769vOUl032095; Mon, 6 Aug 2007 11:57:24 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp305.cisco.com [10.61.65.49]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l769vKx0009516; Mon, 6 Aug 2007 09:57:22 GMT Message-ID: <46B6F070.8040709@cisco.com> Date: Mon, 06 Aug 2007 11:57:04 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [RAM] First cut at routing & addressing problem statement References: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> In-Reply-To: <200707270020.l6R0KbZs014836@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1471; t=1186394244; x=1187258244; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20First=20cut=20at=20routing=20&=20addressing=2 0problem=20=20statement |Sender:=20; bh=Ru6gRbYibSaACtImJnxltoDiw7Gdc93rPfC02Q3QNVo=; b=Vfc6AHqJ7t0HFFvJBIvh3Xp8YR+5K/i5Tw9fH9rzEGSxN8N1I7g92cIxzCrnETUPbdr8MGDQ BEuQJlHjPUrA6rewf+qe9E/INorIU2MeX6WCbpGm6Hy9Ofpzn7LI9ysw; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, I have not had time to review the full document yet, but I do have some immediate comments. In Section 3, 4th para, we *do* build routers to meet today's requirements and so it is unnecessary to ask a question that has already been clearly answered in the affirmative. In Section 3.1, first para, the wording here leaves out the most important "must", which is that routers must process changes to the network topology. Moreover, it leaves as quite murky as to whether the problem is in the forwarding path, the update path, or both, or whether this is dependent on design architecture. I would personally like to see some performance numbers here. In Section 4.3 first para, last sentence, given current discussions on RAM, I would make the following change for clarity: OLD: > However, each individual PI > prefix must be propagated throughout the DFZ and adds to the DFZ > routing load. NEW: > However, with the current BGP-based routing system, each individual PI > prefix must be propagated throughout the DFZ and adds to the DFZ > routing load. Section 4.4 should reference (informationally) RFC 1627, where we first raised this concern 13 years ago. Finally, in Section 6, I think we should add that it is desirable that those who multihome or make use of traffic engineering incur whatever associated costs. This follows in part from your earlier business alignment discussion. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 07 12:01:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIRUL-00075f-Cd; Tue, 07 Aug 2007 12:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIRUK-00075L-09 for ram@iab.org; Tue, 07 Aug 2007 12:00:52 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIRUH-00008C-FH for ram@iab.org; Tue, 07 Aug 2007 12:00:51 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B932959E54; Wed, 8 Aug 2007 02:00:46 +1000 (EST) Message-ID: <46B8971C.3020008@firstpr.com.au> Date: Wed, 08 Aug 2007 02:00:28 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> In-Reply-To: <20070803095100.GF69215@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I was wrong to assume that TLS/SSL certificates necessarily involved IP addresses. I understand they can bind hostnames too. I made this mistake because I knew TLS/SSL required a different IP address for each logical website. Gert Doering clarified this for me. The restriction is not in the TLS/SSL certificate, but in the way the server has to use a single certificate at the moment a TCP connection is established, which means only one certificate can be used for any IP address. Gert wrote: >> As far as I know, this notion of IPv6 end-users supposedly being >> happy with PA space and automated renumbering has been going on for >> ten years or so. Hadn't anyone thought of all the config files >> (named, httpd, imapd, firewall etc.), SSL certs, DNS delegation etc.? > > Most end user networks neither run name servers nor SSL certs, etc., in > their network range - they delegate that task to their service providers. I can't cite counter examples, but I would have thought that many networks would be running their own mailserver, with integrated IMAP and probably web-based email software, which should run via TLS/SSL. Also, they would be running links to other offices, which would all need to be broken and re-established on new IP addresses if multihoming meant getting new addresses. What about SSHing from outside into a server in the network? It would be not such a good thing to find the server suddenly on another IP address from last time, due to a multihoming service restoration operation. I assume SSH would be fussy about that, but perhaps I am wrong about that too. This wouldn't prevent a connection, its just that there would be warnings etc. - which should ideally only occur something really is wrong. If the network suddenly winds up on a different set of addresses, I don't see how it would be possible to automatically update the DNS records for all relevant hostnames. The master nameserver could be in the current network, or anywhere in the world. That and the slaves have caching times to reduce their load, so this will leave some hosts with the old IP address for an hour or whatever after the MH service restoration event. I like running my own master nameserver at home, and having a slave in a server on the other side of the world. Having the whole network suddenly adopt new addresses due to some multihoming service restoration event sounds like 100% trouble and 0% convenience and elegance. It would be far better to have portable IP addresses which remained the same no matter what happened with multihoming. > "all the config files" should contain host names, not IP addresses > (that's what DNS has been invented for, half a century ago). I agree. But how could an automated system update the zone files, restart the nameservers, and then wait for an appropriate time (maybe restarting local caching nameservers to clear their cache) before somehow automatically reloading configurations, re-running start-up scripts or whatever - in an order which is not going to cause some troubles? > Of course there are larger "end users" (corporate networks) that have > local servers in their network - but even then, with proper planning > in the setup phase (and that means "not putting IP addresses in places > that should have server names"), renumbering is not painless, but also > not impossible. It mostly boils down to firewall rules, and changing > glue for a few name servers (again, the "proper planning" thing). Every one of these administrators would surely prefer to have portability and to keep the same addresses during multihoming service restoration. There are various arguments about why something might be possible, or why it would be feasible if only programmers did the right thing, and why it would be best to do this thing for the Greater Good. But the argument is against a network keeping its own IP addresses no matter what, people might nod in general agreement - but they would be nuts to say that there is no cost, no risk etc. making their network suddenly switch to a new set of addresses just because one multihomed link went down, or because they want another ISP. I am adamant that end-users need portability and portability based multihoming, not some supposedly easy renumbering process and multihoming which automagically renumbers their network. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 07 12:28: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 1IIRuR-0002II-Ay; Tue, 07 Aug 2007 12:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIRuQ-0002IA-CJ for ram@iab.org; Tue, 07 Aug 2007 12:27:50 -0400 Received: from smtpout.sgsi.ucl.ac.be ([130.104.5.77] helo=smtp4.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIRuO-0001Ss-TJ for ram@iab.org; Tue, 07 Aug 2007 12:27:50 -0400 Received: from smtp4.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTP id 464EAEF7AE; Tue, 7 Aug 2007 18:27:48 +0200 (CEST) Received: from [192.168.1.101] (ip-83-134-208-80.dsl.scarlet.be [83.134.208.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 7 Aug 2007 18:27:48 +0200 (CEST) Message-ID: <46B89D78.8090407@uclouvain.be> Date: Tue, 07 Aug 2007 18:27:36 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> In-Reply-To: <46B8971C.3020008@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-SGSI-Watermark: 1187108868.45029@bKV7xqhLljC3MjYvS2Z1zQ X-Sgsi-Spamcheck: Authenticated, X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin, > > I am adamant that end-users need portability and portability based > multihoming, not some supposedly easy renumbering process and > multihoming which automagically renumbers their network. I think that we strongly need to distinguish between addresses used as locators and addresses used as identifiers. Users will probably want to keep the same identifier, but they don't care about the locators. Today, most end users received their IP address (which serves as both locator and identifier) through DHCP. They don't need to keep the same IP address always and some ISPs that are charging premium for 'static' IP addresses make sure that DHCP assigned addresses change every few days. End users who are willing to have stable "identifiers" today rely on the DNS, either by coupling the DNS server with the DHCP server or by using services such as dyndns. Endusers don't care about portability of addresses, most of the time, they don't see the IP addresses. Olivier -- http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 07 13:28: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 1IISrD-0000t8-Px; Tue, 07 Aug 2007 13:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISrC-0000nx-BX for ram@iab.org; Tue, 07 Aug 2007 13:28:34 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISrA-0004kY-7j for ram@iab.org; Tue, 07 Aug 2007 13:28:34 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 81B2159E54; Wed, 8 Aug 2007 03:28:28 +1000 (EST) Message-ID: <46B8ABA9.3090209@firstpr.com.au> Date: Wed, 08 Aug 2007 03:28:09 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> In-Reply-To: <46B89D78.8090407@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Olivier.Bonaventure@uclouvain.be X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Olivier, By "end-users" I meant those "end-users" who run networks and which need multihoming, or the ability to choose another ISP without a renumbering effort which in their view is excessively costly or likely to cause more disruption than their organisation can handle. I wasn't referring to people at home with NAT firewalls in ADSL modems who have never heard of an IP address or a configuration file. > I think that we strongly need to distinguish between addresses used as > locators and addresses used as identifiers. Users will probably want to > keep the same identifier, but they don't care about the locators. The addresses which matter to these end-users are those of the packets which are in their network. How the routing system, LISP etc. gets them to the network is not something they care about - unless those methods cause inefficiencies, difficulties with fragmentation, or break Path MTU Discovery by the hosts which are sending them packets. Unfortunately, I think LISP, eFIT-APT and Ivip will cause these difficulties. But something like this will probably be built of those difficulties are not as bad as what would otherwise happen with the number of advertised prefixes growing without constraint. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 07 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 1IIU7K-0002al-Br; Tue, 07 Aug 2007 14:49:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIU7J-0002XS-S2 for ram@iab.org; Tue, 07 Aug 2007 14:49:17 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIU7I-0006ut-9X for ram@iab.org; Tue, 07 Aug 2007 14:49:17 -0400 Received: (qmail 26602 invoked by uid 1007); 7 Aug 2007 18:49:14 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=bhUX9eoqGGE4dOnBnNlWWukmGi+HlKFyR2a39S81tGlA2PXPfZlhpxIpWwyZ7EtP ; Date: Tue, 7 Aug 2007 20:49:14 +0200 From: Gert Doering To: Robin Whittle Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. Message-ID: <20070807184914.GG69215@Space.Net> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46B8ABA9.3090209@firstpr.com.au> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Olivier.Bonaventure@uclouvain.be, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hoi, On Wed, Aug 08, 2007 at 03:28:09AM +1000, Robin Whittle wrote: > I wasn't referring to people at home with NAT firewalls in ADSL > modems who have never heard of an IP address or a configuration file. Those are the *large majority* of "end users". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 07 15:37: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 1IIUsA-0003KX-CA; Tue, 07 Aug 2007 15:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUs9-0003KL-7p for ram@iab.org; Tue, 07 Aug 2007 15:37:41 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIUs4-0000Am-TC for ram@iab.org; Tue, 07 Aug 2007 15:37:41 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 3088D5A662; Wed, 8 Aug 2007 05:37:30 +1000 (EST) Message-ID: <46B8C9E6.7070909@firstpr.com.au> Date: Wed, 08 Aug 2007 05:37:10 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> In-Reply-To: <20070807184914.GG69215@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Olivier.Bonaventure@uclouvain.be Subject: [RAM] "End-users" & things I think warrant more attention X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org In the thread "Renumbering impossibility: TSL/SSL certs, DNS delegation etc.", Gert Doering wrote: > Hoi, > > On Wed, Aug 08, 2007 at 03:28:09AM +1000, Robin Whittle wrote: >> I wasn't referring to people at home with NAT firewalls in ADSL >> modems who have never heard of an IP address or a configuration file. > > Those are the *large majority* of "end users". Sure . . . This whole discussion is about end-users who want or need multihoming, traffic engineering and portability. Rather than writing: "end-users who want or need multihoming, traffic engineering and portability" all through my messages I try to keep them a little shorter by sometimes writing: "end-users" and then there are two messages to the list about me not being specific enough, plus my two replies. There are many more important things I have put on this list and the RRG list in recent weeks which I would really appreciate more attention being given to: ITR complexity & security (ICMP) in LISP-NERD/CONS & eFIT-APT http://www1.ietf.org/mail-archive/web/ram/current/msg01766.html Constructive critique and suggestions for RADIR Problem Statement http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html Likewise for the RRG Design Goals http://psg.com/lists/rrg/2007/msg00199.html Also, if someone would write a critique of the Ivip I-D, that would be great. It has been available for 3 weeks: http://tools.ietf.org/html/draft-whittle-ivip-arch-00 http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html It is long, but not as long as keeping up with these lists - and it is hopefully easier to understand! - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 07 18:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIXma-00055j-RV; Tue, 07 Aug 2007 18:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIXmY-00055e-NC for ram@iab.org; Tue, 07 Aug 2007 18:44:06 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIXmX-0005FV-89 for ram@iab.org; Tue, 07 Aug 2007 18:44:06 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 6F570187D6; Wed, 8 Aug 2007 00:44:04 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 04ACB1A33C; Wed, 8 Aug 2007 00:44:00 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Aug 2007 00:44:01 +0200 To: Olivier.Bonaventure@uclouvain.be,Robin Whittle From: JFC Morfin Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. In-Reply-To: <46B89D78.8090407@uclouvain.be> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070807224400.04ACB1A33C@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org +1 as I explained many times addresses should be three orthogonal folds : fixed, mobile, and virtual. I recently explained that "UP - user protected addressing area" was missing in Thomas' review, and that an address had to be "AP + IP + UP", each being separately managed. I explained many times that an IPv6 addressing /3 block could be organised that way, with three different registries and very small tables if AP is E.164 related. Also, that as long as there is no "plug and play" like standardised possibility protected in the user addressing area, users will not be interested in IPv6. Multilevel addressing obviously offers more possibilities that my IPv6 respectful proposition. This includes virtual addressing (and multilingual naming) over the solution that will be eventually worked out to solve ROAP or the grassroots IPatch that could deploy. The bonus would be that such a virtual presentation layer could deploy on other technologies as well and permit migrations. jfc At 18:27 07/08/2007, Olivier Bonaventure wrote: >Robin, >>I am adamant that end-users need portability and portability based >>multihoming, not some supposedly easy renumbering process and >>multihoming which automagically renumbers their network. > >I think that we strongly need to distinguish between addresses used >as locators and addresses used as identifiers. Users will probably >want to keep the same identifier, but they don't care about the locators. > >Today, most end users received their IP address (which serves as >both locator and identifier) through DHCP. They don't need to keep >the same IP address always and some ISPs that are charging premium >for 'static' IP addresses make sure that DHCP assigned addresses >change every few days. End users who are willing to have stable >"identifiers" today rely on the DNS, either by coupling the DNS >server with the DHCP server or by using services such as dyndns. >Endusers don't care about portability of addresses, most of the >time, they don't see the IP addresses. > > >Olivier > > >-- >http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 05: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 1IIhaP-0007lb-B1; Wed, 08 Aug 2007 05:12:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhaN-0007lU-F9 for ram@iab.org; Wed, 08 Aug 2007 05:12:11 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIhaM-0002li-1Z for ram@iab.org; Wed, 08 Aug 2007 05:12:11 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 1457C1C00E0; Wed, 8 Aug 2007 11:12:09 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0F5571C00DF; Wed, 8 Aug 2007 11:12:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0C0E958ECC0; Wed, 8 Aug 2007 11:12:09 +0200 (CEST) Date: Wed, 8 Aug 2007 11:12:09 +0200 From: Stephane Bortzmeyer To: Olivier Bonaventure Message-ID: <20070808091209.GB11514@nic.fr> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46B89D78.8090407@uclouvain.be> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Robin Whittle , ram@iab.org Subject: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, Aug 07, 2007 at 06:27:36PM +0200, Olivier Bonaventure wrote a message of 31 lines which said: > They don't need to keep the same IP address always and some ISPs > that are charging premium for 'static' IP addresses make sure that > DHCP assigned addresses change every few days. [...] Endusers don't > care about portability of addresses, most of the time, they don't > see the IP addresses. So what? Most end users, today, do not even need IP, an ALG with HTTP would be sufficient for them (I am old enough to remember Compuserve and AOL 1.0). Do we want to maintain the crippled Internet that so many unfortunate users experience today or do we want a better solution (RFC 4924)? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 05:14: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 1IIhd2-0003D8-BJ; Wed, 08 Aug 2007 05:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhd0-0003D0-Kx for ram@iab.org; Wed, 08 Aug 2007 05:14:54 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIhcz-0002oh-E0 for ram@iab.org; Wed, 08 Aug 2007 05:14:54 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 172C91C00E5; Wed, 8 Aug 2007 11:14:53 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 11ADB1C00DF; Wed, 8 Aug 2007 11:14:53 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 03F9258ECC0; Wed, 8 Aug 2007 11:14:53 +0200 (CEST) Date: Wed, 8 Aug 2007 11:14:53 +0200 From: Stephane Bortzmeyer To: Gert Doering Message-ID: <20070808091452.GA12605@nic.fr> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070807184914.GG69215@Space.Net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Olivier.Bonaventure@uclouvain.be, Robin Whittle , ram@iab.org Subject: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, Aug 07, 2007 at 08:49:14PM +0200, Gert Doering wrote a message of 22 lines which said: > Those are the *large majority* of "end users". We have no work to do for "the large majority of TODAY's end users", "it works for them". We work for the power users of today, who do what the end users of tomorrow will do daily (P2P file sharing being a typical example). _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 05:22:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhk9-0007kn-5Z; Wed, 08 Aug 2007 05:22:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhk8-0007kh-Be for ram@iab.org; Wed, 08 Aug 2007 05:22:16 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIhk6-0002xy-Qq for ram@iab.org; Wed, 08 Aug 2007 05:22:16 -0400 Received: (qmail 14594 invoked by uid 1007); 8 Aug 2007 09:22:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=kOSE4AraBcy+JXDQhI+jtg93M9MxRzrIyFi9NWIN+ikRiJQ/4GPQLPQCZ+f1qFSD ; Date: Wed, 8 Aug 2007 11:22:13 +0200 From: Gert Doering To: Stephane Bortzmeyer Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. Message-ID: <20070808092213.GS69215@Space.Net> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <20070808091209.GB11514@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070808091209.GB11514@nic.fr> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Olivier Bonaventure , Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, On Wed, Aug 08, 2007 at 11:12:09AM +0200, Stephane Bortzmeyer wrote: > So what? Most end users, today, do not even need IP, an ALG with HTTP > would be sufficient for them (I am old enough to remember Compuserve > and AOL 1.0). Do we want to maintain the crippled Internet that so > many unfortunate users experience today or do we want a better > solution (RFC 4924)? My point was: people claiming that "all end-users need (!) instant IP address portability!!" are just ignoring the majority of end-users, that just do *not* need that, because: - they do not run servers that require a fixed IP address (DNS servers) - if they run servers at all (e.g. peer2peer stuff), they can happily use directory services that get updated whenever their IP address changes - renumbering is a nearly no-cost issue, because they don't have anything tied to fixed IP addresses This is not advocating NAT, or dynamic IPs, but trying to get a more balanced view into this discussion. I *do* acknowledge that "corporate end-users" have different needs, and as such, changing IP addresses can be difficult to impossible, depending on the size and structure of the corporate network. (Some, smaller, corporate networks fall into the same category as "home end-users" - no servers inside their network, external access is through a proxy only, renumbering is less pain than signing a new contract with a new ISP and turning up the new line). I just can't see a way to truthfully claim "all end users need full IP independence, multihoming, instant ISP changing". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 05:23: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 1IIhlc-0008S5-K6; Wed, 08 Aug 2007 05:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhlb-0008OJ-Uw for ram@iab.org; Wed, 08 Aug 2007 05:23:47 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIhla-00030f-Ka for ram@iab.org; Wed, 08 Aug 2007 05:23:47 -0400 Received: (qmail 14694 invoked by uid 1007); 8 Aug 2007 09:23:46 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=MNef1iiq2W/d0aGI3JD7TdE4tyIQv/Awp2HcJGlzEvFhN+Uc0jtQJb4vuI4VDF8c ; Date: Wed, 8 Aug 2007 11:23:46 +0200 From: Gert Doering To: Stephane Bortzmeyer Message-ID: <20070808092346.GT69215@Space.Net> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> Mime-Version: 1.0 In-Reply-To: <20070808091452.GA12605@nic.fr> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ram@iab.org, Olivier.Bonaventure@uclouvain.be, Robin Whittle Subject: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453709251==" Errors-To: ram-bounces@iab.org --===============1453709251== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xugTQucUrPU/y3dQ" Content-Disposition: inline --xugTQucUrPU/y3dQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Aug 08, 2007 at 11:14:53AM +0200, Stephane Bortzmeyer wrote: > > Those are the *large majority* of "end users". >=20 > We have no work to do for "the large majority of TODAY's end users", > "it works for them".=20 >=20 > We work for the power users of today, who do what the end users of > tomorrow will do daily (P2P file sharing being a typical example). P2P file sharing is happy if you give it a global IP address that doesn't change too often and has no NAT in its way. They have understood= =20 the concept of "using lookup services". Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --xugTQucUrPU/y3dQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBRrmLoqkuBuNlUUl1AQLT/AP8D4zGCRY7QjCPZsOxhnQ6RE5Sf4jUL5Jv Cpm/Y3DPu1hrXfzr+nRcM/HtjtRUs6prnahzkhzUFlm/hSoJMxco6wsA9bu0WU4v GL7m/Y8H4vu/ito4BCxwV3JD/Uu4Vmhd9VU6MWVQWo+bRT9nbLmfGrEa3/PrcCZM gvPS969aKrw= =QCS0 -----END PGP SIGNATURE----- --xugTQucUrPU/y3dQ-- --===============1453709251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1453709251==-- From ram-bounces@iab.org Wed Aug 08 08:09: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 1IIkLq-00038i-95; Wed, 08 Aug 2007 08:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIkLp-00038d-2d for ram@iab.org; Wed, 08 Aug 2007 08:09:21 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIkLn-0006Ca-Jr for ram@iab.org; Wed, 08 Aug 2007 08:09:21 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id DDDE01A339; Wed, 8 Aug 2007 14:09:18 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 3EF841A359; Wed, 8 Aug 2007 14:09:15 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Aug 2007 14:02:51 +0200 To: Gert Doering ,Stephane Bortzmeyer , Thomas Narten From: JFC Morfin Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. In-Reply-To: <20070808092346.GT69215@Space.Net> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070808120915.3EF841A359@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Olivier.Bonaventure@uclouvain.be, Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org 1) Sounds to me like a 1920 AT&T director explaining that people did not need a dedicated telephone number. This might have been true. Like ICANN saying in August 2000 that mobiles did not need IP addresses and could be accessed via Telcos' own Gateways as virtual hosts. Or experts of the 90s saying that everyone could accept Windows with large users working on IBM main frames. Who knows? However, who wants to bet on that? 2) Thomas, I think there is something missing in your summary: a calendar. Time to get a solution, and how long it is expected to stay. This will say if what is looked for at this stage has to be a patch or can be an architecture. We need to see that clarified first. jfc At 11:23 08/08/2007, Gert Doering wrote: >Hi, > >On Wed, Aug 08, 2007 at 11:14:53AM +0200, Stephane Bortzmeyer wrote: > > > Those are the *large majority* of "end users". > > > > We have no work to do for "the large majority of TODAY's end users", > > "it works for them". > > > > We work for the power users of today, who do what the end users of > > tomorrow will do daily (P2P file sharing being a typical example). > >P2P file sharing is happy if you give it a global IP address that >doesn't change too often and has no NAT in its way. They have understood >the concept of "using lookup services". > >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 113403 > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 10:37:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImez-0002aU-6O; Wed, 08 Aug 2007 10:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImew-0002a7-C4 for ram@iab.org; Wed, 08 Aug 2007 10:37:14 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IImeu-0001tx-Fb for ram@iab.org; Wed, 08 Aug 2007 10:37:14 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l78EbAEX025368 for ; Wed, 8 Aug 2007 10:37:10 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l78Eb9Um259802 for ; Wed, 8 Aug 2007 08:37:09 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l78Eb95H000908 for ; Wed, 8 Aug 2007 08:37:09 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-180-16.wecm.ibm.com [9.67.180.16]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l78Eb7mP000754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 08:37:09 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l78EaopY023696; Wed, 8 Aug 2007 10:36:56 -0400 Message-Id: <200708081436.l78EaopY023696@cichlid.raleigh.ibm.com> To: JFC Morfin Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. In-reply-to: <20070808120915.3EF841A359@smtp7-g19.free.fr> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> <20070808120915.3EF841A359@smtp7-g19.free.fr> Comments: In-reply-to JFC Morfin message dated "Wed, 08 Aug 2007 14:02:51 +0200." Date: Wed, 08 Aug 2007 10:36:50 -0400 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org JFC Morfin writes: > 2) Thomas, I think there is something missing in your summary: a > calendar. Time to get a solution, and how long it is expected to > stay. This will say if what is looked for at this stage has to be a > patch or can be an architecture. We need to see that clarified first. I don't believe putting in a concrete timetable is possible. My sense from having participated in many discussions with many different people is that there just is no concensus on this point. TO make predictions, one has to make assumptions about future growth and trends that we have little confidence in, and that different people have very different views on. I'm not sure it makes sense to ask whether a "patch" or an "architecture change" is the way to go. IMO, the right answer is that we go with a solution that solves the problem in a meaningful way, and that we believe can actually be deployed. Whether or not that involves an "architecture change" or not is sort of an academic point. Let's see proposed solutions please, evaluate them on their merits, and then chose the approach that makes the most sense. Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 14:08: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 1IIpxV-00053r-Cf; Wed, 08 Aug 2007 14:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIpxU-00053e-FH for ram@iab.org; Wed, 08 Aug 2007 14:08:36 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIpxS-0007Xo-UW for ram@iab.org; Wed, 08 Aug 2007 14:08:36 -0400 Received: (qmail 62853 invoked by uid 1007); 8 Aug 2007 18:08:33 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=a4bGVQx/ADJajfCgpYHbZehbVq2FT8HV5MomtfJA2Wq+r/9St1RjBVlxqhST4rhq ; Date: Wed, 8 Aug 2007 20:08:33 +0200 From: Gert Doering To: JFC Morfin Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. Message-ID: <20070808180833.GG69215@Space.Net> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> <20070808120915.3EF841A359@smtp7-g19.free.fr> Mime-Version: 1.0 In-Reply-To: <20070808120915.3EF841A359@smtp7-g19.free.fr> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Robin Whittle , Olivier.Bonaventure@uclouvain.be, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1732421718==" Errors-To: ram-bounces@iab.org --===============1732421718== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="58U/A6k471xnmLQu" Content-Disposition: inline --58U/A6k471xnmLQu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Aug 08, 2007 at 02:02:51PM +0200, JFC Morfin wrote: > 1) Sounds to me like a 1920 AT&T director explaining that people did=20 > not need a dedicated telephone number. This might have been true.=20 You *want* to misunderstand me. So how much more do I need to write to explain realities about end users? Guess why IPv6 (with "dedicated networks of incredible size!!") wasn't a huge success with end users? Because they *don't care* about how the network works, and whether they have a static for dynamic IP address. (It's not like there are no ISPs trying to sell IPv6-capable access products. We do, and have done so since > 5 years. Hasn't been a=20 tremendous success... real-world experience can be very frustrating at times). Please re-think my statement: there is different classes of "end users", undoubtedly, but closing your eyes before the reality that the *majority*= =20 of them is just not interested in "instant network mobility" or couldn't afford the occasional renumbering is just not true, and is not lending credibility to any conclusions ignoring that. Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --58U/A6k471xnmLQu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBRroGoakuBuNlUUl1AQKUNQP/dkIEJgk5si3LkYq9fW2gAnVWAsLNcbA/ B3hzIVDuBIgIF/gAHsX6CimFJ1I7wNrk6qtrb77syOwFoVB0Ju+G7fetCQg3ye00 LrmkDL4e+n70FZu+4d8K9UCXQ8cbjJKXjCCtNHrOFiM4rLsUhfsOVN0yzi9eUYL/ ZG9sZVKwysA= =fHBL -----END PGP SIGNATURE----- --58U/A6k471xnmLQu-- --===============1732421718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1732421718==-- From ram-bounces@iab.org Wed Aug 08 15:14: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 1IIqzC-0003qb-NV; Wed, 08 Aug 2007 15:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqzB-0003qW-Rp for ram@iab.org; Wed, 08 Aug 2007 15:14:25 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIqzA-0000UA-C0 for ram@iab.org; Wed, 08 Aug 2007 15:14:25 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id CB2481A3AD; Wed, 8 Aug 2007 21:14:23 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 8054B1A360; Wed, 8 Aug 2007 21:14:23 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Aug 2007 18:25:08 +0200 To: Thomas Narten From: JFC Morfin Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. In-Reply-To: <200708081436.l78EaopY023696@cichlid.raleigh.ibm.com> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> <20070808120915.3EF841A359@smtp7-g19.free.fr> <200708081436.l78EaopY023696@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070808191423.8054B1A360@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 16:36 08/08/2007, Thomas Narten wrote: >JFC Morfin writes: > > > 2) Thomas, I think there is something missing in your summary: a > > calendar. Time to get a solution, and how long it is expected to > > stay. This will say if what is looked for at this stage has to be a > > patch or can be an architecture. We need to see that clarified first. > >I'm not sure it makes sense to ask whether a "patch" or an >"architecture change" is the way to go. Dear Thomas, You talk of change. I do not. As you know I think the Internet can sustain the difficulty with the existing machines and architecture, but not in the way it is understood (paradigme) today by most of IETF participants, with their resulting solutions. Ex. the early XXth century did not build big high-ways to support huge cavalcades to transport an increasing number of people, they accomodated cars. This is why things must be organised. Not only between the IETF refinement you propose to avoid IPvnat solutions. Also, a paradigme change must be studied in parallel for a part of the time we have. If there is no time table for that, you know this will not happen (this would have happened already). This study must be conceived as a possible solution path but also as a way to further the other solutions through a better knowledge of the real needs evolution, of the hidden capacities of the existing solutions. At the end of the period there will be a decision: to drop the issue and to focus on the then consensual possibility or to pursue in the best way which will have been discovered. Otherwise, the new paradigme (distributed vs. decentralised) will continue to develop by its own, in diverse places, and the day it is accepted by the market it may result into a dramatic investment waste if the solution IETF developped does not match its growth orientations. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 18:58: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 1IIuTv-0005NM-DN; Wed, 08 Aug 2007 18:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIuTt-0005Mq-V8 for ram@iab.org; Wed, 08 Aug 2007 18:58:21 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIuTs-0004em-GI for ram@iab.org; Wed, 08 Aug 2007 18:58:21 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 916981A31F; Thu, 9 Aug 2007 00:58:19 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 3E43018312; Thu, 9 Aug 2007 00:58:15 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Aug 2007 00:58:16 +0200 To: Gert Doering From: JFC Morfin Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. In-Reply-To: <20070808180833.GG69215@Space.Net> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> <20070808120915.3EF841A359@smtp7-g19.free.fr> <20070808180833.GG69215@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Message-Id: <20070808225815.3E43018312@smtp7-g19.free.fr> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Robin Whittle , Olivier.Bonaventure@uclouvain.be, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 20:08 08/08/2007, Gert Doering wrote: >Guess why IPv6 (with "dedicated networks of incredible size!!") wasn't >a huge success with end users? Because they *don't care* about how >the network works, and whether they have a static for dynamic IP address= . I am really sorry Gert, but this is not the case. This is a recurrent=20 disagreement I have with the "technical" side of the TF, and a=20 support from the user side (and leadership). The reason why the users=20 are not interested in IPv6 is because they have no incentive to use=20 their addressing part because it is not protected by any standard,=20 what shows them the IETF has not understood their need so it is not=20 an exciting thing to consider as it is not supported. And ROAP is the=20 proof. You are concerned by the number of address for the network,=20 they are concerned by the number of their own addresses and how they=20 can distributed them across the world. I know we disagree. Even Thomas who asks for inputs for his summary=20 does not want to take into account an UP (User Protected) addressing=20 area. This is why I ask if we want more than a patch. (But I also way=20 that the current technology under a different paradigm should support=20 the need, because the need is for more and more addresses, not for=20 traffic). This is why I do not mind much about the solution you will=20 find - all I need is virtual bandwidth we can organise with the true=20 addressing we need. Obviously this will inelegantly and costly pile=20 unnecessary layers ... I work on semantic addressing, distributed translation memories,=20 referential systems. Address grids are certainly every user most=20 demanding IP=A8v6 address applications I know - right now. Billions of=20 metadata having its own ID in thousands of languages (have you only=20 considered what the RFC 4646 or a semantic network may require in=20 terms of hardware access to be workable). This is where the IETF decentralized paradigm is totally outdated. At=20 most the entire network may need 30 billions of user addresses. This=20 is very small when compared with plug and play multilingual semantic=20 sub-addressing grids on a family SNHN (small network home network).=20 SNHN are the core of the Internet. And you doubt they only need a=20 single IP ..... Please think distributed fractal networking, and stop=20 thinking decentralized host access supporting unified Google=20 information in a single language and a single presentation layer.=20 That was academic test 30 years ago. You certainly heard about what is an ontology and a thesaurus. The=20 largest taxonomy is probably a Dutch dictionary with 450.000 words.=20 Add all the names of all the people, all the possible conceptual=20 adjencies, etc. This is what every user need just to talk with his=20 own computer, like Hall in Space Odyssey, at a low cost and=20 acceptable robust rusticity. Not in 3010, but in 2001 (we are=20 probably 15 years late). Translation memory/semantic addressing call=20 for each Semantic Being to have an IP address. An ontology is built=20 by a person using a taxonomy to describe her vision of the world. I=20 suppose that a few years from now you will have your own and your own=20 knowledge base on your mobile. We still are on the same planet, but=20 in different worlds. Cheers ! jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 20:11:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIvcB-0004Ty-3p; Wed, 08 Aug 2007 20:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIvc9-0004Ts-2w for ram@iab.org; Wed, 08 Aug 2007 20:10:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIvc7-0005aO-Qy for ram@iab.org; Wed, 08 Aug 2007 20:10:57 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Aug 2007 02:10:56 +0200 X-IronPort-AV: i="4.19,237,1183327200"; d="scan'208"; a="150138301:sNHT45108058" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l790AtIr019966 for ; Thu, 9 Aug 2007 02:10:55 +0200 Received: from [192.168.254.137] (ams3-vpn-dhcp5043.cisco.com [10.61.83.178]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l790Asx0010225 for ; Thu, 9 Aug 2007 00:10:54 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070808225815.3E43018312@smtp7-g19.free.fr> References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> <20070808120915.3EF841A359@smtp7-g19.free.fr> <20070808180833.GG69215@Space.Net> <20070808225815.3E43018312@smtp7-g19.free.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. Date: Wed, 8 Aug 2007 17:11:01 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=470; t=1186618255; x=1187482255; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20Renumbering=20impossibility=3A=20TSL/ SSL=20certs,=20DNS=20delegation=20etc. |Sender:=20; bh=db8xLhis+tsZO67DE/88HBr2WNjbHkkd8iET+FgCQWE=; b=CnH6sbbzedYeZwUpFXlH/15t26Gty9B+Hl5JeozhNC5AwvxRo6cr2KlphOFK/2xmfhuzgNXx JbBdYCPF3/+SDRyjxbgrQoZ4LwR1EhjHeJhtL1Fsm/sMqYAiCMN5riIQ; Authentication-Results: ams-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Aug 8, 2007, at 3:58 PM, JFC Morfin wrote: > At most the entire network may need 30 billions of user addresses. I very strongly disagree with this, in an age of RFID-enabled supply- chains and of spimes. How precisely was this number derived? ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 22:45:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIy1d-0000bL-1B; Wed, 08 Aug 2007 22:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIy1b-0000bF-KV for ram@iab.org; Wed, 08 Aug 2007 22:45:23 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIy1a-0007kz-8h for ram@iab.org; Wed, 08 Aug 2007 22:45:23 -0400 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id C3C031A2B6; Thu, 9 Aug 2007 04:45:21 +0200 (CEST) Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 7B70719308; Thu, 9 Aug 2007 04:45:21 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Aug 2007 04:45:10 +0200 To: Roland Dobbins ,ram@iab.org From: JFC Morfin Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc. In-Reply-To: References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> <20070808120915.3EF841A359@smtp7-g19.free.fr> <20070808180833.GG69215@Space.Net> <20070808225815.3E43018312@smtp7-g19.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070809024521.7B70719308@smtp7-g19.free.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 02:11 09/08/2007, Roland Dobbins wrote: >On Aug 8, 2007, at 3:58 PM, JFC Morfin wrote: >>At most the entire network may need 30 billions of user addresses. > >I very strongly disagree with this, in an age of RFID-enabled >supply- chains and of spimes. How precisely was this number derived? The disagreement is over the meaning of the word "network". I use it here are the namespace concerned by what Thomas describes in his summary (out of what I call UP). I have no objection if you make it ten times larger. This is only pi x people and business number. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 08 22:57: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 1IIyCp-0001i3-S8; Wed, 08 Aug 2007 22:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIyCp-0001g7-2Z for ram@iab.org; Wed, 08 Aug 2007 22:56:59 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIyCl-0007tb-QZ for ram@iab.org; Wed, 08 Aug 2007 22:56:59 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 011CA59DA2; Thu, 9 Aug 2007 12:56:54 +1000 (EST) Message-ID: <46BA8263.5070009@firstpr.com.au> Date: Thu, 09 Aug 2007 12:56:35 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: Subject: [RAM] RADIR Problem Statement: timeframe, portability, mobility, FIB etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I am replying to Thomas Narten and Brian Carpenter, regarding http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem-statement-00.txt and their messages from the "Renumbering impossibility: TSL/SSL certs, DNS delegation etc." thread: TN (Re: Renumbering impossibility: TSL/SSL certs, ...) http://www1.ietf.org/mail-archive/web/ram/current/msg01785.html BC (First cut at routing & addressing problem statement) http://www1.ietf.org/mail-archive/web/ram/current/msg01786.html These were responses, in part, to my suggested rewrite of section 6 of the draft Problem Statement: http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html "End-user" in this message refers to those end-users with networks which need multihoming, TE and/or portability of their network's address range between ISPs. Hi Thomas, You wrote, in part: >> In that thread I argue that the RADIR Problem Statement should >> not be written as if there was even a slight possibility that new >> technologies could make today's networks reliably renumbered by >> some automated means. > > Why is it important to do this? If it is feasible to do this, we > shold. If it is not, we won't. Trying to rule it out as a > possibility from the problem statement point of view makes no > sense (IMO). I am sure that there is no prospect whatsoever of end-user's genuine needs for multihoming - or for ease of using another ISP - being met by some other mechanism than portability of their own address space. I don't think that you or anyone else has an argument as to why end-users would be happy with any conceivable mechanism other than portability. So by re-framing the Problem Statement to ignore this idea, I don't think you would be ruling out a possibility. It would be marvellous if mathematicians found more than 4 billion combinations of 32 bits . . . but since we all agree there is no possibility of this occurring, there is no point in an IPv4 addressing problem statement being written as if it was a possibility. > The purpose of the problem statement is to define the problem, and > not rule out _any_ solution, so long as it addresses the problem. I am certain that there is no solution to Multihoming or ISP choice other than portability. Are there any network operators on the list who disagree with this? > (And no, I'm not about to argue that getting automatic/painless > renumbering is about to happen. But let any proposed solution in > that direction be evaluated on its merits please!). I am evaluating "automatic/painless renumbering" it on its merits - its merits amount to zero. So let's not pretend that perhaps, by some new technique no-one has stumbled upon in all these years, there might be a technical approach which would make network operators happy to have their entire network suddenly renumbered the moment one multihoming link goes down, or that could provably make some automated renumbering system work flawlessly on a huge variety of networks in existence today, for which there is no clear enough definition to even start designing such an automated system. > It's much more productive to focus on solution aproaches that folk > think might be viable, than spending cycles trying to rule out > approaches that aren't being pushed very heavily... There is no reason to think that "automatic/painless renumbering" of today's networks might be viable. Because such a thing would be really highly desirable (from the point of view of having end-user networks use PA space so we don't need to have unconstrained growth in the global BGP routing table or alternatively have to create out an architecture which supports genuine portability), some folks tend to think it "might be viable", despite everyone else being adamant that it is impossible, and will forever remain so. The reason it is not being pushed very heavily is because the only people who want it are not the end-users, but those who want to keep end-users using PA space for the convenience of not having to design and run the Internet in a way which genuinely supports end-user needs. If this is a blue-sky, no deadline, Problem Statement then I think you can include "automatic/painless renumbering" as a design goal. With no deadline, you can easily make part of the solution a new set of standards to which all future networks and their devices and software must comply. Whether anyone living now will ever see such an architecture become widely adopted is highly debatable. What is the timeframe of the solution this Problem Statement describes the properties of? In a recent message TN (Re: Renumbering impossibility . . .) http://www1.ietf.org/mail-archive/web/ram/current/msg01803.html you wrote: > I don't believe putting in a concrete timetable is possible. My > sense from having participated in many discussions with many > different people is that there just is no concensus on this point. My understanding of what the RRG and this RAM list is working on is how to create an addition to the current architecture which will: 1 - Solve or significantly help with: a - Unconstrained growth in the number of advertised routes while supporting growing number of end-user networks which have multihoming, TE and portability (often referred to as "automatic/painless renumbering"). b - Enable better use of IPv4 space to accommodate more end-user networks, more actively used IP addresses etc. (This is the most urgent crisis, but it seems most folks just accept that nothing can be done. I think LISP/ eFIT-APT/Ivip could all make significant improvements.) 2 - Be incrementally deployable. This rules out any proposal which requires changes to hosts - including switching to IPv6. 3 - Not restrict the adoption of mobility, future architectures etc. I think RADIR needs to define the timeframe. Are you trying to define a new architecture for the future to which all users will ultimately migrate? That is a fine goal, and involves less constraints - because you don't need to be backwards compatible. Instead you need to define a much better end-point and devise the technical and business aspects of how and why people will progressively adopt the new architecture. Or are you looking for a solution which could start to be deployed in 2010 and be widely adopted - with major, lasting, benefits - around 2104? I am working on the latter. > TO make predictions, one has to make assumptions about future > growth and trends that we have little confidence in, and that > different people have very different views on. Sure, but does the 9 person RADIR Directorate: http://www3.tools.ietf.org/group/radir/ have a consensus? You can't be constrained by trying to agree with everyone else. If you can't agree among yourselves on whether your Problem Statement should be for near-term (3 to 8 years, benefits for IPv4 and IPv6, no host changes) or for some future architecture (15 to 30 years), then maybe you should make a separate Problem Statement for each timeframe. > I'm not sure it makes sense to ask whether a "patch" or an > "architecture change" is the way to go. IMO, the right answer is > that we go with a solution that solves the problem in a meaningful > way, and that we believe can actually be deployed. Assuming you mean "deployed in 3 to 8 years time" I think this rules out changes to IPv4 hosts and to considering "automatic/painless renumbering" as a possibility. > Whether or not that involves an "architecture change" or not is > sort of an academic point. I think improvements to BGP does not constitute "architecture change". I think that having a significant amount of the address space only reachable via a LISP/eFIT-APT/Ivip ITR-ETR mapping system is a significant architectural change, but it is not switching all users over to a completely new architecture. It is like building another few storeys on a building. The old building is still there, but people who use the building generally need to use the new addition as well. That addition is not going to go away in the future, so it needs to be planned in a way that doesn't preclude whatever important additions will be needed in the future. > Let's see proposed solutions please, evaluate them on their > merits, and then chose the approach that makes the most sense. I have a proposed solution with the Ivip I-D: http://www.firstpr.com.au/ip/ivip/ http://tools.ietf.org/html/draft-whittle-ivip-arch-00 You responded to some of my message, but not beyond the middle of my point 2 in my proposed rewrite of your Section 6. That was 11 days ago - 29 July: http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html I would be interested to know what you and other RADIR people thought of my proposed points 2 to 10. (There is no point 3.) >> As far as I know, this notion of IPv6 end-users supposedly being >> happy with PA space and automated renumbering has been going on >> for ten years or so. > > Um, AFAIK, people have NOT been making this argument. I think you are arguing that it is possible that at some time in the future (the so-far unspecified timeframe of the Problem Statement) that IPv6 end-users will be happy with automated renumbering. Hi Brian, You wrote: >> We would welcome comments on the document. In particular: >> >> - Do folk agree with the problem statement as written, or are we >> missing something fairly fundamental? > > Yes. I think it's correct to keep it down to the bare bones. But why make it some arbitrary length? The proposed changes are so extensive and will affect all Internet users forever. This is a very difficult set of problems to solve. Surely it would take a few few pages text to properly describe the constraints which exist on solutions, and goals we have for the next decade or two? I know it is convenient to have a short problem statement, but what if it leaves out important questions? What if the omission of certain criteria enables the selection of a solution which won't work, or which is far worse than a solution which would only have matched a more rigorous and longer statement, or which prevents us from achieving some other important goal we easily could have left ourselves open to? The current statement doesn't have a timeframe. Do you think it should be aimed at IPv4 over the next five to ten years (which rules out host changes) or is it aimed at developing a new architecture which everyone will migrate to after IPv4 has become unworkable? >> - Are there other pressures on the routing system that we have >> not listed or described completely? > > Not that I noticed. What about FIBs? They are burning up R&D dollars, manufacturing costs and electricity all over the world. All Internet users pay for this. Surely there is a difference between an architecture which handles packets with short prefixes rather than long ones. It seems monstrous to expect a router to chew through 48 bits on 50 low-key little VoIP packets a second, with perhaps 15 or 20 routers en-route performing these gymnastics. (PI IPv6 space as /48s for end-users is now part of ARIN, AfriNIC and RIPE policy.) Likewise, there is a huge difference in cost and performance for routers and therefore to some extent the working of the entire Internet, between solutions which do the job with no tunneling (I think there are no such solutions, other than a drastic BGP improvement, which seems impossible) or simple tunneling (Ivip) rather than with tunneling with nonces and other complex operations and lots of CPU time (LISP and eFIT-APT). The Internet is too complex for us to make it work better with a Problem Statement which is as short as the current version. I suggested a bunch of additional things for Section 6, at the end of: http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html You critiqued these up to the middle of my new point 2: http://www1.ietf.org/mail-archive/web/ram/current/msg01775.html and I responded to your critique: http://www1.ietf.org/mail-archive/web/ram/current/msg01779.html but I haven't seen your response to this. I corrected your misunderstanding that I meant more IPv4 end-users and more IPv4 IP addresses being actually used would involve more advertised prefixes. The way to do it is with LISP/eFIT-APT/Ivip etc. more finely dividing existing prefixes to serve more end users and have hosts on more IP addresses than is possible with BGP's slow, costly, coarse (256 addresses at a time) method of divvying up the space. I discussed how the more bits which need to be analysed in the FIB the more time and power is required. Surely we can't ignore FIB difficulties when selecting a new architecture. I was most perplexed when you wrote that you didn't think there was consensus that the core of the problem involved what I tried to describe: D. The complexity and size of the RIB and the complexity and volume of inter-router communications. Along with FIB difficulties and instability in the whole BGP system, these are the major problems - all driven primarily by the growth in the number of prefixes. I thought there was consensus on this. You didn't disagree with with my points 1F and 2, but said they were > really getting more into desirable properties of a solution, > rather than the problem. and I responded that this is in keeping with section 6, which defines the problem in terms of the properties of the desired solution. You didn't specifically mention my suggested points 4 to 10. >> - We intentionally did not include improving mobility as a core >> "problem", as explained in the document. (That doesn't mean we >> don't recognize that some of the solutions under discussion >> may also be applicable to mobility scenarios. Rather, we tend >> to see improved mobility as a possible benefit of certain >> classes of solutions.) > > I think this is correct. In many ways mobility is an overlay > on a routing system assumed to be stable and scaleable. It depends . . . if LISP or eFIT-APT are added to the Internet and are regarded as part of the routing system, then they will get in the way of the new techniques for supporting mobility which I discuss in: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor81 If Ivip is regarded as part of the routing system (I am not sure that it should be), then it does mobility as an integral part of the routing system. If you have a critique of these techniques, then please write about it to the list. I don't think it is right to support such a short Problem Statement without adequately considering a bunch of constructive stuff which argues that more things need to be considered when defining the properties of a solution, which is the purpose of Section 6. For instance, do you support this addition? 10. Either directly supports or at least does not preclude the use of the new architecture to be used for supporting Mobile IP in terms of greater flexibility, more optimal path lengths and communications with non-upgraded correspondent hosts. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Aug 09 08:35:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ7EO-0008C7-77; Thu, 09 Aug 2007 08:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ7EM-0008Ay-UU for ram@iab.org; Thu, 09 Aug 2007 08:35:10 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ7EL-0000kv-J8 for ram@iab.org; Thu, 09 Aug 2007 08:35:10 -0400 Received: by ug-out-1314.google.com with SMTP id c2so357443ugf for ; Thu, 09 Aug 2007 05:35:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jCbtehsEYT7mgtrnp1V8rnJs8+15aQy3X4r+CTSkftOsrUbShHT5PEZqWhsWVeg3GugeXvidTPVR+srnASvAzgaISpsJxEo0Yoto2XYTzUMDWSkIj0vdzn8bCgs4FfjWyB9bfCAzBmxHfqyWdAz7QtiLsL+MmXujUWwGsVBOm4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RJ7NqFCx2J1LRxhYKwV/8jpuMNSfN5TRH2L/n24Ax+oxqmBDs9gW+UwdgqU553VPjhxeTU9h1DWGC6aok/MKet/7H0MELhOkMJAUo6k9tjMAgdImMebXl19jomq2B/vzTUB8+BrCyn8smrcqBZT1gK/TJLxf+nc0YHOassttLFM= Received: by 10.66.236.13 with SMTP id j13mr2286641ugh.1186662908716; Thu, 09 Aug 2007 05:35:08 -0700 (PDT) Received: from ?10.10.50.8? ( [213.3.13.1]) by mx.google.com with ESMTPS id z40sm3030329ikz.2007.08.09.05.35.05 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Aug 2007 05:35:06 -0700 (PDT) Message-ID: <46BB09FE.1010808@gmail.com> Date: Thu, 09 Aug 2007 14:35:10 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robin Whittle References: <46BA8263.5070009@firstpr.com.au> In-Reply-To: <46BA8263.5070009@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ram@iab.org Subject: [RAM] Re: RADIR Problem Statement: timeframe, portability, mobility, FIB etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin, Briefly, On 2007-08-09 04:56, Robin Whittle wrote: ... > > I am sure that there is no prospect whatsoever of end-user's genuine > needs for multihoming - or for ease of using another ISP - being met > by some other mechanism than portability of their own address space. "Portability" is a word I associate with cell-phone numbers. If you're referring exclusively to IPv4, and to the class of mechanism described in RFC 4116, then yes. But your argument does not apply a priori to a scenario where address space and prefixes are plentiful. That is why IPv6 was designed from the start on the assumption that sites would have multiple simultaneous prefixes and hosts would have multiple simultaneous addresses. ... > It would be marvellous if mathematicians found more than 4 billion > combinations of 32 bits . . . but since we all agree there is no > possibility of this occurring, there is no point in an IPv4 addressing > problem statement being written as if it was a possibility. Yes, but that isn't the problem statement being written. ... >> (And no, I'm not about to argue that getting automatic/painless >> renumbering is about to happen. But let any proposed solution in >> that direction be evaluated on its merits please!). > > I am evaluating "automatic/painless renumbering" it on its merits - > its merits amount to zero. That's just polemic. > So let's not pretend that perhaps, by some new technique no-one has > stumbled upon in all these years, there might be a technical > approach which would make network operators happy to have their > entire network suddenly renumbered the moment one multihoming link > goes down, I'm not aware that anyone has ever suggested such a thing. > or that could provably make some automated renumbering > system work flawlessly on a huge variety of networks in existence > today, for which there is no clear enough definition to even start > designing such an automated system. There was certainly some thought about that in the early days of IPv6 design, but it's clearly impossible, which is why RFC 4192 was written. ... > The reason it is not being pushed very heavily is because the only > people who want it are not the end-users, but those who want to keep > end-users using PA space for the convenience of not having to design > and run the Internet in a way which genuinely supports end-user needs. This also verges on the polemic. To be clear, we've spent >10 years with the certain knowledge that the only way to avoid a BGP4 meltdown is to aggregate prefixes, and the only way to aggregate prefixes is to us PA space whenever possible (and I mean that strictly, i.e. not merely whenever convenient or preferred). Multi6 took that as a basic assumption and Shim6 (and I suppose Six/One) takes that as a basic assumption. This wasn't an assumption adopted for convenience; it was an assumption adopted to avoid meltdown. People thought that would be even less convenient. That's also why it would be pretty short sighted to hand out more than a few tens of thousands PI prefixes, of course, unless we have a viable solution in the LISP/iVIP/eFIT class ready to deploy. If this current effort leads to such a solution, net convenience will increase. But the problem statement cannot assume that such a solution can be found. ... >>> - Do folk agree with the problem statement as written, or are we >>> missing something fairly fundamental? >> Yes. I think it's correct to keep it down to the bare bones. I still think that. Short problem statements get read. Long ones don't. ... > and I responded to your critique: > > http://www1.ietf.org/mail-archive/web/ram/current/msg01779.html > > but I haven't seen your response to this. You won't. I will be mostly silent for the next month while moving jobs and land masses. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Aug 09 22:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJKSk-0002KB-3f; Thu, 09 Aug 2007 22:42:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJKSi-0002K3-VQ for ram@iab.org; Thu, 09 Aug 2007 22:42:52 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJKSd-0005Rf-BF for ram@iab.org; Thu, 09 Aug 2007 22:42:52 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 9ECB859E3C; Fri, 10 Aug 2007 12:42:45 +1000 (EST) Message-ID: <46BBD092.6020108@firstpr.com.au> Date: Fri, 10 Aug 2007 12:42:26 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Re: RADIR Problem Statement: timeframe, portability, mobility, FIB etc. References: <46BA8263.5070009@firstpr.com.au> <46BB09FE.1010808@gmail.com> In-Reply-To: <46BB09FE.1010808@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Brian, Thanks for your response. ("End-user" in the following means end-users who need multihoming, traffic engineering and what I try to describe, briefly, as "portability" of the address range their network uses.) You wrote: >> I am sure that there is no prospect whatsoever of end-user's genuine >> needs for multihoming - or for ease of using another ISP - being met >> by some other mechanism than portability of their own address space. > > "Portability" is a word I associate with cell-phone numbers. If you're > referring exclusively to IPv4, and to the class of mechanism described > in RFC 4116, then yes. But your argument does not apply a priori > to a scenario where address space and prefixes are plentiful. That is > why IPv6 was designed from the start on the assumption that sites > would have multiple simultaneous prefixes and hosts would have multiple > simultaneous addresses. I don't think the end-user's need for "portable" address space is related to the scarcity or otherwise of address space. The end-user wants and needs to run their network without sudden changes imposed by outside circumstances, such as the failure of a multihoming link, or the business or technical failure of an ISP. They also want and arguably need to be able to choose another ISP for reasons of cost, performance etc. without having to do anything disruptive or expensive to their network. I think it is a good use of IPv6's vast address space to have arrangements by which each host can have multiple IP addresses at the same time. Then SHIM6 or Six/One can use these to provide multihoming. SHIM6 does it without involving routers, but I think it involves longer packets, with the extension header. At least this length is not added en-route and there are no problems with Path MTU Discovery. Six/One does it by involving routers, and I think, without any extra headers - thanks to creative use of IPv6's huge number of address bits. However, I am not sure that Six/One's rewriting destination addresses won't cause trouble for PMTUD. Although there are better facilities in IPv6 for automated control of router and host addresses, this doesn't solve the problem of mobility - which ideally involves the host having one (or a stable set of) address (or the mobile network one stable set of addresses) no matter which provider network they connect to in a dynamic fashion. For the major goal of multihoming, as far as I know, the only way IPv6's "multiple addresses at once" approach can be used is SHIM6. A decade after the guts of IPv6 was defined, SHIM6 is still not finished. This makes me think it is a difficult protocol to devise, given its goals and constraints. Even if SHIM6 was here today and universally implemented in all IPv6 stacks, it would not provide multihoming the way most end-user networks want it. My understanding of the needs of end-user network multihoming requirements is that there must be a centralised, robust control system. Having to simultaneously control the multihoming behaviour of hundreds or thousands of different hosts is not practical. So the ten year long attempt at making IPv6 provide multihoming the way most end-user networks want and need has not worked and will not work. If it had, or if anyone expected it to work sometime soon, then there probably wouldn't have been the pressure to have IPv6 PI space for end-users. Likewise, if SHIM6 was expected to provide multihoming which was acceptable to most end-users, I doubt whether ARIN, AfriNIC and RIPE would have reversed long-standing policies and decided to provide PI /48s to end-users. The terms "portability" or "portable address space" are the shortest, most accurate, terms for what I think end-users (multihoming etc. end-users) need. It is a delicate enough business getting all the software working on one host, integrated with the external environment of nameservers and all the other hosts which communicate with it. It is also a delicate business getting a whole network running, with all sorts of different hosts, including some which don't have ongoing updates to their operating systems and those which run applications which are not completely up-to-date with recent RFCs. There is no way an end-user with such a network can be sure their network is going to keep running reliably if every host and router needs to switch over to another address range. IPv6 is intended to facilitate this, but even when SHIM6 is finished and widely implemented (2012?) it won't fulfil network multihoming needs because this is a host-based, approach. This seems to lead to portability as the only mechanism by which end-users can get what they need for multihoming. Portability is also the only practical way of allowing painless switching to another ISP. Portability, if it can be done fast enough, is clearly the best approach to mobility too - from the end-user's point of view. > ... >> It would be marvellous if mathematicians found more than 4 billion >> combinations of 32 bits . . . but since we all agree there is no >> possibility of this occurring, there is no point in an IPv4 addressing >> problem statement being written as if it was a possibility. > > Yes, but that isn't the problem statement being written. My point was that no-one mentions more than 4 billion IPv4 addresses because everyone agrees it is not a possibility. Thomas Narten and perhaps you seem to think that it is possible for multihoming and free choice of ISP to be achieved without what I call "portability". I believe this is not a possibility. My guess is that you hold on to the idea of it being possible because if it were possible, you would be able to retain the traditional and current Internet architecture without causing unsustainable growth in the global BGP routing table. I think you need to show why it is a possibility. It doesn't matter how convenient it would be for the rest of the Internet if it were possible. What counts is whether it is what end-users want and need in order to run their networks reliably and without excessive costs or other complications. I think you need to show why end-users could find your yet-to-be-developed solutions - which involve changing the addresses of their networks - robust, fully applicable to their actual networks and of sufficiently low cost that they would be about as happy with this as with what they currently want: "portability" - meaning their networks keep the same address space. > ... >>> (And no, I'm not about to argue that getting automatic/painless >>> renumbering is about to happen. But let any proposed solution in >>> that direction be evaluated on its merits please!). >> >> I am evaluating "automatic/painless renumbering" it on its merits - >> its merits amount to zero. > > That's just polemic. Yes, but at least it was brief! What are its merits? "Automatic/painless renumbering" (user networks adopting new addresses) would have enormous merits for the Internet's routing system because no further change is needed to the current routing architecture. But that doesn't matter unless you can show why this would be as good as true portability for the people who need to run their networks 24 hours a day without disruption or further complications. What is the time-frame within which the techniques you hope for will be developed and fully deployed? If the discussion is about IPv4, then you can't rely on host changes - because there is too much old stuff out there which can't and won't be upgraded. With IPv6, because it is so little used at present, you can probably require host changes, but I think you need to show how and why everyone would make these changes in the timeframe you are proposing. All such host changes need to support full backwards compatibility with non-upgraded hosts for as long as any non-upgraded hosts remain in use, perhaps until some far-off date where you nominate that those hosts will no longer be able to communicate fully. >> So let's not pretend that perhaps, by some new technique no-one has >> stumbled upon in all these years, there might be a technical >> approach which would make network operators happy to have their >> entire network suddenly renumbered the moment one multihoming link >> goes down, > > I'm not aware that anyone has ever suggested such a thing. SHIM6, when it is finished, should enable multihoming without this sudden change of addresses, because each host will already have a set of addresses from the PA space of each of the two or more ISPs through which the end-user network is multihomed. But this is IPv6 only, requires new host software in every host in the multihomed network and in all correspondent hosts. It doesn't exist yet and it is not a router-centric approach, which I understand is what most end-user networks want and need, rather than having to fuss over every host. Apart from this host-based, IPv6-specific, future possibility, as long as you want end-user networks not to have "portable" address space, then I think you are implying that when one link goes down, the network must switch to using the address space which is available on another link. LISP/eFIT-APT/Ivip are intended to provide address space which is genuinely portable between any ISP with an ETR. Ivip is intended to do this so fast that it will support mobility, with generally optimal path lengths from all correspondent hosts, without upgrades to those correspondent hosts, and for both IPv4 and IPv6. All these schemes have significant problems to do with tunneling overhead, breaking Path MTU Discovery etc. But unlike SHIM6 they give the end-user what they want and need. (I think Six/One can do multihoming with passive, not specifically controlled, hosts running suitable software - with the control being exercised at the network's CE router. So this may well provide the network-centric control of multihoming which end-user's need. Six/One's techniques can't be applied to IPv4.) With the possible exception of using Six/One for IPv6 only multihoming, I don't think you can give the end-user what they want and need as long as you can't give them "portable" address space. >> or that could provably make some automated renumbering >> system work flawlessly on a huge variety of networks in existence >> today, for which there is no clear enough definition to even start >> designing such an automated system. > > There was certainly some thought about that in the early days of > IPv6 design, but it's clearly impossible, which is why RFC 4192 > was written. Sections 3 and 4 consider some fundamental problems in implementing this, such as with dedicated devices (VoIP phones) which are not amenable to being upgraded to adopt the new addresses. There are also problems with securely automating DDNS and reverse mapping. Six/One would need to be implemented in all a network's devices, including phones and light switches, for it to be successful. > ... >> The reason it is not being pushed very heavily is because the only >> people who want it are not the end-users, but those who want to keep >> end-users using PA space for the convenience of not having to design >> and run the Internet in a way which genuinely supports end-user needs. > > This also verges on the polemic. To be clear, we've spent >10 years > with the certain knowledge that the only way to avoid a BGP4 meltdown > is to aggregate prefixes, and the only way to aggregate prefixes is to > us PA space whenever possible (and I mean that strictly, i.e. not > merely whenever convenient or preferred). But this "certain knowledge" is no longer true. LISP/eFIT-APT/Ivip all provide portable address - applicable for most of the purposes PI space is currently used for - without directly involving or burdening the BGP routing system. (LISP etc. mapped space can't be used for running ITRs, ETRs or any server which is part of the LISP/eFIT-APT/Ivip infrastructure.) They are all a kludge, with various degrees of ugliness and various amounts of new benefits, particularly in terms of the speed by which end users can control the behaviour of the global network of ITRs. If you and others had been successful in meeting the needs of end-users (who need multihoming, TE and "portability" = ease of switching to another ISP) by the use of PA space, then there wouldn't be unsustainable growth in the global BGP routing table. You haven't been successful. The task was - and remains - impossible. End-users with current network technology can only run their networks reliably with stable addresses - and you can't provide that with PI space. (Except that in the future SHIM6 or Six/One will be able to provide multihoming for IPv6 within limits such as those described above.) That is why we now have a crisis in routing and addressing for which the only potentially practical solution seems to be a kludge like LISP, eFIT-APT or Ivip. If RADIR wants to position its Problem Statement into the indefinite future, to provide a new architecture to which everyone will happily migrate within some time-frame - say 2020 or 2025 - with new host and router requirements which support robust, easy, renumbering of networks, then that would be great. That would be worth working for, rather than all this tunneling stuff and being stuck forever in the constraints of IPv4. In the meantime, I think there needs to be another Problem Statement and potential solutions to get us through to 2020 or 2025. > Multi6 took that as a basic assumption and Shim6 (and I suppose Six/One) > takes that as a basic assumption. This wasn't an assumption adopted for > convenience; it was an assumption adopted to avoid meltdown. People thought > that would be even less convenient. The idea of this global ITR network and tunneling overhead is pretty horrible, I think. The thought of the the BGP system progressively failing due to stability, RIB or FIB limits being breached by the number and length of advertised prefixes is much worse. I think I fully understand the motivation for this assumption. Unfortunately, by staying within the constraints of this assumption, it has not been possible to meet the needs of end-users with substantial multihomed networks (or those who want freedom of choice between ISPs). Nothing has changed. Apart from SHIM6 or Six/One there is no reason to think anything will change in the future. It was a noble effort. But it didn't work and I think it is best to recognise that it won't work in the future either - not through lack of effort, but because the task is impossible. > That's also why it would be pretty short sighted to hand out more than a > few tens of thousands PI prefixes, of course, unless we have a viable > solution in the LISP/iVIP/eFIT class ready to deploy. Thanks for moving Ivip up the pecking order! > If this current > effort leads to such a solution, net convenience will increase. But the > problem statement cannot assume that such a solution can be found. This makes me think that you see the RADIR Problem Statement as applying to a longer time-frame. I think there are two timeframes. Something like: Short timeframe: Start 2010 Wide adoption 2015 Last until at least 2025 Apply to IPv4 without requiring host changes? Yes Apply similar principles to IPv6 maybe with host changes? Yes Must solve: Million or more MH end-user networks without further significant growth in number or churn of BGP advertised prefixes. Should solve or Portability so end-user networks can at least not freely choose ISP without any impact prevent solution on their network. to: Mobility with generally optimal path lengths and fast (a few seconds, ideally) user control of mapping to whichever router is best for the mobile-node. Increased utilisation of IPv4 address space. Migration to IPv6 or whatever new architecture is optimal in the future. Long timeframe: Start 2020 Wide adoption 2025 Last until at least 2035 Apply to IPv4 without requiring host changes? No - may not support IPv4 at all, except by some tunneling and software hack for IPv4 applications. Apply similar principles to IPv6 maybe with host changes? Everything is up for grabs, so IPv6 might be extended or replaced. Must solve: Million or more MH end-user networks without further significant growth in number or churn of BGP advertised prefixes. Ideally solve: Portability so end-user networks can freely choose ISP without any impact on their network. Mobility for billions of devices - probably each with the functional equivalent of an IPv6 /64 with generally optimal path lengths and fast (a few seconds, ideally) user control of mapping to whichever router is best for the mobile-node. Get rid of kludgey LISP/eFIT-APT/Ivip tunnels and ITR stuff. >>>> - Do folk agree with the problem statement as written, or are we >>>> missing something fairly fundamental? >>> Yes. I think it's correct to keep it down to the bare bones. > > I still think that. Short problem statements get read. Long > ones don't. If additions to the Internet architecture are designed by people who won't read more than a few pages, then I think the outcome is likely to be a mess. The current draft's Section 6, which is what really matters, contains 90 words, not counting the final paragraph which is a qualification about what the section doesn't fully consider. The text I proposed in: http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html contains 515 words, not counting the stuff in brackets. That is not exactly long - about 1.6 pages My suggested text is for a short timeframe. I think it would be helpful if the RADIR statement specified the timeframe. I think it should be clear to the reader whether the intended solution is meant to support existing IPv4 hosts and networks, or whether it is meant to provide a new architecture in the longer term future to which all those users would ultimately migrate. I am proceeding on the basis that some people will devote the time to understanding the problem in all its facets - including how some solutions might support further benefits (eg. mobility) while other solutions make such benefits harder to achieve. Perhaps the solution properties should also include that each new architectural element should be, to the greatest extent possible, a building block which can be used with other building blocks, rather than a monolithic system which contains fixed ways of dealing with particular problems. >> and I responded to your critique: >> >> http://www1.ietf.org/mail-archive/web/ram/current/msg01779.html >> >> but I haven't seen your response to this. > > You won't. I will be mostly silent for the next month while > moving jobs and land masses. OK - that is a huge move. Good luck with it. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Aug 10 13:26:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYG8-0003WI-9i; Fri, 10 Aug 2007 13:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYG6-0003WD-Hp for ram@iab.org; Fri, 10 Aug 2007 13:26:46 -0400 Received: from web58704.mail.re1.yahoo.com ([66.196.100.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJYG5-0002wl-Cf for ram@iab.org; Fri, 10 Aug 2007 13:26:46 -0400 Received: (qmail 994 invoked by uid 60001); 10 Aug 2007 17:26:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=cyMgkPy3eml2tbhbsDKIxTXQmsOavrcRyYLPMTMwfWsTGAyTVIOyaM2a8IKE3/US0JPYKF/IeZuIvSUgBxQe7jHqypsWqYHKNJ2HKThYThv4LmShhXK2KtvQOHJjOWFUtDD5NQuB0tOM0tt+wRCDoiP7RwDy7QM2T3HCDWmPOyU=; X-YMail-OSG: CC7wOPIVM1lA2dQVzVdsVcw_0jI3QBZb2y5FWT2Bf_2aRsUrUlEQLST0HYuCroOXWsdeQ._XKi_PiF4bBpciNSigW3Qea2JHPrhlKkPRCWXcd6gEHaJazqmamwp1JdJUvJvBlsvK84BLK0m_ Received: from [24.114.255.3] by web58704.mail.re1.yahoo.com via HTTP; Fri, 10 Aug 2007 10:26:45 PDT Date: Fri, 10 Aug 2007 10:26:45 -0700 (PDT) From: Peter Sherbin To: ram@iab.org, RRG Mailing List In-Reply-To: <16360.63228.qm@web58704.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <168355.949.qm@web58704.mail.re1.yahoo.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [RAM] draft-sherbin-eia-00.txt X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Folks, Your comments are welcome and appreciated. This is an outline of one of the possibilities and it may require further detalization. Thank you, Peter A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sherbin-eia-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Elements of The Internet Architecture Author(s) : P. Sherbin Filename : draft-sherbin-eia-00.txt Pages : 8 Date : 2007-8-10 This document outlines the Internet architecture that can scale to interconnect a very large number of communicating devices. It aims at presenting a holistic view of the Internet various parts from routing to number management as well as their interdependencies. The draft also indicates the Internet cost drivers and cost vectors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sherbin-eia-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sherbin-eia-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sherbin-eia-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 20 09:47: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 1IN7aw-0007Ji-07; Mon, 20 Aug 2007 09:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7au-0007Jb-Hp for ram@iab.org; Mon, 20 Aug 2007 09:47:00 -0400 Received: from el-out-1112.google.com ([209.85.162.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN7at-0005ce-C9 for ram@iab.org; Mon, 20 Aug 2007 09:47:00 -0400 Received: by el-out-1112.google.com with SMTP id o28so119532ele for ; Mon, 20 Aug 2007 06:46:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Hf4JLXBGEAoAWLGhf//fDVz/SiLkLwQOOYIB2lNYfCI90nLowij13PNuJfEWFdypKqHWldj1i2HLObP0u/yF4HyBZr/QAXQ/WykUW6DWK+8gewB8im1k0g/cnRVDQo/cVKS8797YO95NW6yVwrOOtFKGOHGx9ll3PEn7J7o6FUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Ak3VYYGdnmSw7j1HtHr+eSdOZEgGgQqrbL5suT7qflhyFC2V66cJqBvGbgvpv+pf2EiIpkJ6FkRnJ1lxTWDVqAw13gzYafSpVpq6m56EgTP1io7aoI/q8J8+r9l3/tjCLa16icAX15jxWlTEatV9tO1ySV6sExAFoStX8bSUeVw= Received: by 10.142.110.3 with SMTP id i3mr371839wfc.1187617617544; Mon, 20 Aug 2007 06:46:57 -0700 (PDT) Received: by 10.143.159.7 with HTTP; Mon, 20 Aug 2007 06:46:57 -0700 (PDT) Message-ID: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> Date: Mon, 20 Aug 2007 09:46:57 -0400 From: "William Herrin" To: ram@iab.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 361dce180f07e6ae X-Spam-Score: 0.9 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [RAM] Tunnelling Route Reduction Protocol X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi folks, For your amusement, the Tunneling Route Reduction Protocol with proof of concept C code: http://bill.herrin.us/network/trrp.html Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 20 22:42: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 1INJhF-0005Ga-MX; Mon, 20 Aug 2007 22:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INJhF-0005Fu-9P for ram@iab.org; Mon, 20 Aug 2007 22:42:21 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INJhA-0001c6-Vg for ram@iab.org; Mon, 20 Aug 2007 22:42:21 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 485D859DA1; Tue, 21 Aug 2007 12:42:14 +1000 (EST) Message-ID: <46CA50F0.2040001@firstpr.com.au> Date: Tue, 21 Aug 2007 12:41:52 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Tunnelling Route Reduction Protocol References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> In-Reply-To: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Bill, Here are some thoughts after I had a quick read of: http://bill.herrin.us/network/trrp.html http://bill.herrin.us/network/trrp-implementation.html Very roughly, I think TRRP is like LISP 2, with a transitional arrangement for continued reachability during introduction, with longer-term administrative arrangements for removing prefixes of mapped addresses from the global BGP routing table. I think the biggest problem TRRP faces is that when a packet arrives at an ITR which has no mapping information, that the ITR must hold the packet until it gets that information. Via DNS, I guess that could take a second or two or more. Generally, I think this is an unacceptable delay, since the application which sent the packet will assume the packet or its response is lost, and will send another one. I think this is one major reason why no-one is seriously proposing LISP 2 as a solution to the routing and addressing problems. Another concern might be about overloading the DNS system with more tasks. Your multihoming service restoration system seems to rely on the ITR getting a "destination unreachable" response when it sends a data packet. Without this, the ITR assumes that the packet is received by the ETR and that the ETR can send the packet to the final destination. I think this would be a poor way of ensuring that the packets really do reach their destination. "Destination unreachable" packets could get dropped, and you would need to ensure there was no filtering of such packets between all ITRs and ETRs. Yet some networks like to drop "destination unreachable" packets to reduce the ability of an attacker to probe the existence of hosts in their network. This might limit how deep the ETRs are located. Yet having a deeper placement of ETRs helps with scaling - spreading the load among more of them. Deeper, closer, ETRs also reduces the path length to the destination host. So like LISP and eFIT-APT, TRRP's multihoming service restoration functions are hard-coded into the protocol and are implemented independently by each ITR. In contrast, Ivip has no built-in multihoming service restoration functions. It is up to the end user to choose and supply their own monitoring system, which can be arbitrarily flexible, complex and costly as they choose. This system is then given the power to control the mapping of their addresses. The Ivip system simply follows these instructions. The ITRs do not attempt to determine reachability or decide on alternative ETRs to tunnel packets to. This makes the Ivip system a relatively simple component, to be used with other user-supplied components, to achieve a variety of benefits - multihoming, TE, portability and mobility with generally highly optimal path length. You don't explain how an ETR can get packets to the intended destination. Presumably they could do so via a tunnel, in which case each host requires special software to decapsulate the packet. Otherwise, the ETR needs a direct link to each destination host, or the local routing system needs to be able to route the packets with their raw addresses (the IP address of the destination host). You would need to ensure that all packets addressed to the hosts with TRRP mapped addresses were sent via an ITR (apart from those emanating from an ETR). This is because only the ITR can have the latest information on where the packets should be sent to. The local routing system can't be expected to change so rapidly, or to make multihoming service restoration decisions. I think this is a common problem for LISP and Ivip (eFIT-APT too?). Also, I understand the outer packet source address of TRRP's tunneled packets is that of the ITR. This makes it very difficult for ETRs to protect against spoofed local source addresses when they decapsulate packets. Ivip uses the source address of the sending host as the source address of the outer IP header of the encapsulated packet. This enables the ETR to perform some simple tests when decapsulating the packet, which extends the reach of the network's border router's filtering of source address of incoming packets, to solve this problem: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor67 - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 21 09:30:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INToG-0002or-7Z; Tue, 21 Aug 2007 09:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INToF-0002ol-B3 for ram@iab.org; Tue, 21 Aug 2007 09:30:15 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INToE-0001Qh-HB for ram@iab.org; Tue, 21 Aug 2007 09:30:15 -0400 Received: by nz-out-0506.google.com with SMTP id i28so542206nzi for ; Tue, 21 Aug 2007 06:30:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=M5aCjP3FBq5k5miAm5AqmYffHof4egPwDQ6hBJg82YDU0oPVPrkTKai+ND7/yjYiglpXCqPL4BFEqS16FYK6bXIZlcGPyM1xROhyX8qD3rOS4qCwisu4Yb+ls2We19NqXbhGSC4Yl4mU+d6U0VCs5GVIwcw8X0HvFNZVxloQn7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=BshzOYn2W1tJ7WxZal95TXjvX0p0VAEdXs0/zIBPItt2nD1wn4kswjPN5xYQul4ChN6K9mE7WwA0QtNCdTmeDbryWNHYO9TthbrGhDN74glPiIJ2bgbjln7gpMownhBDgFu58X+R9phFA1Z7uPkgB/kvQTTWO+V/GbxFOfB+iOA= Received: by 10.142.232.20 with SMTP id e20mr778181wfh.1187703013310; Tue, 21 Aug 2007 06:30:13 -0700 (PDT) Received: by 10.143.159.7 with HTTP; Tue, 21 Aug 2007 06:30:13 -0700 (PDT) Message-ID: <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> Date: Tue, 21 Aug 2007 09:30:13 -0400 From: "William Herrin" To: ram@iab.org Subject: Re: [RAM] Tunnelling Route Reduction Protocol In-Reply-To: <46CA50F0.2040001@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> <46CA50F0.2040001@firstpr.com.au> X-Google-Sender-Auth: e7ea3ccf97a91b69 X-Spam-Score: 0.9 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Robin Whittle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 8/20/07, Robin Whittle wrote: > Here are some thoughts after I had a quick read of: > > http://bill.herrin.us/network/trrp.html > http://bill.herrin.us/network/trrp-implementation.html Hi Robin, Thanks for your response. > I think the biggest problem TRRP faces is that when a packet arrives > at an ITR which has no mapping information, that the ITR must hold > the packet until it gets that information. Via DNS, I guess that > could take a second or two or more. Generally, I think this is an > unacceptable delay, since the application which sent the packet will > assume the packet or its response is lost, and will send another > one. This is true for packets which will leave the local AS and cross the Internet. This brings up three points: 1. 99.9% of the time, the originator of the packet has already had to do a DNS lookup or some other lookup to map a name to an IP address. Doing another lookup for that first connection attempt leaves us in the same ballpark speed-wise. 2. This delay only occurs the -first- time the ITR sees a packet for a particular destination. After that, it has a destination cached. Even re-lookups are background tasks. The ITR is permitted to keep the destination cached long after the TTL expires. The only requirement is that it initiate a background relookup the first time it sees another packet for the destination. 3. Traffic within the AS (or the local portion of the AS for particularly large AS's) need not enter TRRP at all. Barring a passthrough-mode ITR close to the source, It moves normally as dictated by an interior routing protocol. > I think this is one major reason why no-one is seriously > proposing LISP 2 as a solution to the routing and addressing > problems. Another concern might be about overloading the DNS system > with more tasks. As always, the key portions of the root of the DNS tree get immediately cached by the resolver. TRRP has its own branch in the system, so as you get down to the components that are heavily used with a short timeout, the servers can be scaled to match. One of the benefits of using DNS for this is that we already have software which scales up to a massive level with little pain. > Your multihoming service restoration system seems to rely on the ITR > getting a "destination unreachable" response when it sends a data > packet. > So like LISP and eFIT-APT, TRRP's multihoming service restoration > functions are hard-coded into the protocol and are implemented > independently by each ITR. Actually, no. TRRP relies on the operator of the authoritative DNS server performing some sort of monitoring to determine when a particular ETR is no longer a reasonable target and then updating the DNS records. When the records expire at the ITR (which is intended to happen quickly) the relookup reveals a new destination. This monitoring is not defined by the protocol. It can be as simple (and slow) as "change by hand when there is a problem" or arbitrarily complex. Note that that the ITR has no other mechanism for detecting a failure downstream from the ETR. If the ETR is reachable but it can't reach the end-user network, the destination unreachable goes back to the sender, not the ITR itself. Ideally this can be handled by allowing the packet to drop into another ITR instead and be rerouted to an ETR which does have a route to the destination. Discovering the failure can be slow, taking up to the DNS TTL. The destination unreachable stuff is intended to provide the ITR with a shortcut to detect the failure sooner. The optional preemptive change notification also helps speed the process up. When not available, the regular timeout and relookup mechanism applies. Also, where the ITR is operating in passthrough mode on an originating host, TCP retransmits can be used to key a retry with an alternate ETR. That's the primary point of having a passthrough mode. Doesn't work through NAT though. That's unfortunate for IPv4. Should be a non-issue for IPv6. > This might limit how deep the ETRs are located. Yet > having a deeper placement of ETRs helps with scaling - spreading the > load among more of them. Deeper, closer, ETRs also reduces the path > length to the destination host. ETRs can be as deep or shallow as the destination network operator desires. They can sit just inside the AS if desired. Alternately, the service provider could assign 2 addresses from globally routable space to each customer and let the customer implement both the DNS server and the ETR on customer's own network. > You don't explain how an ETR can get packets to the intended > destination. > Otherwise, the ETR needs a direct link to each destination host, or > the local routing system needs to be able to route the packets with > their raw addresses (the IP address of the destination host). Correct, that's how it works during normal operations. Any place I didn't specify otherwise, packets are intended to move via plain old raw IP routing. In the case where the ETR's link to the customer network has been severed, the packet will ideally fall into another ITR and be rerouted to an alternate ETR. This is not a protocol requirement but it would shorten the recovery time after the loss of the link and before the propagation of the new ETR information via DNS. > Also, I understand the outer packet source address of TRRP's > tunneled packets is that of the ITR. Correct. > This makes it very difficult > for ETRs to protect against spoofed local source addresses when they > decapsulate packets. Ivip uses the source address of the sending > host as the source address of the outer IP header of the > encapsulated packet. This enables the ETR to perform some simple > tests when decapsulating the packet, which extends the reach of the > network's border router's filtering of source address of incoming > packets, to solve this problem: Hmm. Would you jimmie up an example of aberrant behavior you feel couldn't be adequately addressed within the ETR or ITR, or via existing mechanisms for protecting against spoofed addresses? Thanks again, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 21 10:43:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INUwx-0002ld-Sd; Tue, 21 Aug 2007 10:43:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INUww-0002lY-Rx for ram@iab.org; Tue, 21 Aug 2007 10:43:18 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INUwu-00048O-Hn for ram@iab.org; Tue, 21 Aug 2007 10:43:18 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id F1EFE5A674; Wed, 22 Aug 2007 00:43:12 +1000 (EST) Message-ID: <46CAF9EB.1010406@firstpr.com.au> Date: Wed, 22 Aug 2007 00:42:51 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Tunnelling Route Reduction Protocol References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> <46CA50F0.2040001@firstpr.com.au> <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> In-Reply-To: <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Bill, Thanks for clarifying some things. I understand - as I should have earlier - that your proposal involves a separate set of nameservers, which can be scaled to deal with the load of queries, including I guess by using anycast servers in multiple locations, as with the root nameservers. >> Your multihoming service restoration system seems to rely on the ITR >> getting a "destination unreachable" response when it sends a data >> packet. >> So like LISP and eFIT-APT, TRRP's multihoming service restoration >> functions are hard-coded into the protocol and are implemented >> independently by each ITR. > > Actually, no. TRRP relies on the operator of the authoritative DNS > server performing some sort of monitoring to determine when a > particular ETR is no longer a reasonable target and then updating the > DNS records. When the records expire at the ITR (which is intended to > happen quickly) the relookup reveals a new destination. > > This monitoring is not defined by the protocol. It can be as simple > (and slow) as "change by hand when there is a problem" or arbitrarily > complex. OK - I understand from this that TRRP and Ivip are both relatively simple "components" of the complete multihoming solution, with the end-user supplying their own monitoring system to update the mapping database. That is my view of how your system would work, since although you wrote: > TRRP relies on the operator of the authoritative DNS > server performing some sort of monitoring to determine when a > particular ETR is no longer a reasonable target and then updating > the DNS records. I figure that either the operator of the DNS server covers address space for many end-user networks, and that each end-user might want to choose some monitoring system which is different from whatever the DNS operator has available - and so would pay someone else to run that monitoring service and tell the DNS operator what changes to make to the mapping of their address space . . . Or that the authoritative controller of the DNS information (a subset of what a whole server controls) is the end-user organisation themselves. With Ivip, I aim to get those changes to ITRs within a few seconds. Your TRRP arrangement relies on cache time expiration, so the response speed for multihoming service restoration needs to be traded off against the amount of query traffic to the nameservers. Ivip is pretty ambitious in this attempt to transmit mapping changes to all the ITRs which need it so quickly. If this can be done, then it would support a mobility arrangement which I think can't be done by any of the other proposals including with the slower arrangements which I think your reliance on cache expiration require. > Note that that the ITR has no other mechanism for detecting a failure > downstream from the ETR. If the ETR is reachable but it can't reach > the end-user network, the destination unreachable goes back to the > sender, not the ITR itself. OK - so the ITR is not involved in this. Some separate monitoring system is required to find out which is the best ETR to use, irrespective of whether traffic packets are being sent to the destination host or not. I don't clearly understand quite a few of the next paragraphs - but it is late in the evening .... I will read them again in the next day or two. > Hmm. Would you jimmie up an example of aberrant behavior you feel > couldn't be adequately addressed within the ETR or ITR, or via > existing mechanisms for protecting against spoofed addresses? Sections 14.1 to 14.1.2.5 cover this: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor67 - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Aug 21 14:25:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYPf-0003Bg-O4; Tue, 21 Aug 2007 14:25:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYPe-0003Ba-2t for ram@iab.org; Tue, 21 Aug 2007 14:25:10 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INYPd-0003Ew-4L for ram@iab.org; Tue, 21 Aug 2007 14:25:10 -0400 Received: by nz-out-0506.google.com with SMTP id i28so605109nzi for ; Tue, 21 Aug 2007 11:25:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=d+xMDtHrmXJgjpEul/akzG3UJNpU3qZ4k6/RFE9BMKXOu6nbTl87aZGcwnCJMtKm3VHmKbeA0yyFRglJjwZikqj7Zuj3CgiISP65pcMPjo+AozFYT9aKCeZ3eMpmU0ABSYhwzCZOm2UHwlMbreimS2LSW3Sq4weh5BUJ1YhkB9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kQzSzTrVgBIS+UvqK108Ll+7BvUcv+OSbnuGSu6i0tYkFSUjET/pep7k2aLaEocwoY/HRjIgVK4mBoz3NUCFX1M9aXiI82/NUtLb6T9YdJGAgVo0XanSpAI3a24kWDP5rE3dFhmRSFC5q1+mMDSziI5Jx7MSmvZgATyxNrqlp9U= Received: by 10.142.246.8 with SMTP id t8mr1028746wfh.1187720706990; Tue, 21 Aug 2007 11:25:06 -0700 (PDT) Received: by 10.143.159.7 with HTTP; Tue, 21 Aug 2007 11:25:04 -0700 (PDT) Message-ID: <3c3e3fca0708211125k4cf981c5i3c58c9c606a63cfc@mail.gmail.com> Date: Tue, 21 Aug 2007 14:25:04 -0400 From: "William Herrin" To: ram@iab.org Subject: Re: [RAM] Tunnelling Route Reduction Protocol In-Reply-To: <46CAF9EB.1010406@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> <46CA50F0.2040001@firstpr.com.au> <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> <46CAF9EB.1010406@firstpr.com.au> X-Google-Sender-Auth: f9b18a09a29c3796 X-Spam-Score: 0.9 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Robin Whittle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 8/21/07, Robin Whittle wrote: > I understand - as I should have earlier - that your proposal > involves a separate set of nameservers, which can be scaled to deal > with the load of queries, including I guess by using anycast servers > in multiple locations, as with the root nameservers. Hi Robin, That's essentially correct. It starts at the same root as everything else but follows its own branch of the tree. > OK - I understand from this that TRRP and Ivip are both relatively > simple "components" of the complete multihoming solution, with the > end-user supplying their own monitoring system to update the mapping > database. Correct. > I figure that either the operator of the DNS server covers address > space for many end-user networks, and that each end-user might want > to choose some monitoring system which is different from whatever > the DNS operator has available - and so would pay someone else to > run that monitoring service and tell the DNS operator what changes > to make to the mapping of their address space . . . Or that the > authoritative controller of the DNS information (a subset of what a > whole server controls) is the end-user organisation themselves. Correct. I envision both operating mechanisms being used. I also expect a market to develop for an optimizing server which offers different answers depending on the source of the query, much like companies such as Akamai do now for http content. Such a device could take factors like latency, packet loss, the relative sizes of the customer's upstream connections and current use data to optimize traffic engineering. Because its keyed to individual IP addresses, the traffic engineering can extend all the way down to the host level if desired. Perhaps you'll program the mail servers to prefer the least-cost path while the web servers prefer the best performance path. Today this can only be done at the coarse /24 level and then only by deaggregating and polluting the DFZ. > With Ivip, I aim to get those changes to ITRs within a few seconds. > Your TRRP arrangement relies on cache time expiration, so the > response speed for multihoming service restoration needs to be > traded off against the amount of query traffic to the nameservers. Correct, although there is an optional component that allows the information to be propagated sooner, within a few seconds of the change. > > Note that that the ITR has no other mechanism for detecting a failure > > downstream from the ETR. If the ETR is reachable but it can't reach > > the end-user network, the destination unreachable goes back to the > > sender, not the ITR itself. > > OK - so the ITR is not involved in this. Some separate monitoring > system is required to find out which is the best ETR to use, > irrespective of whether traffic packets are being sent to the > destination host or not. Correct. > I don't clearly understand quite a few of the next paragraphs - but > it is late in the evening .... I will read them again in the next > day or two. Its more likely that I didn't explain myself well. I'll take another stab at it. The ITR primarily relies on the TTL offered in the DNS response packet to determine how long to cache the destination ETR before checking to see if its still valid. Even if you set the TTL to something like 60 seconds, that means a slow recovery to failure. I don't tackle this problem directly. Instead, I come at it from several sides: 1. ETR unreachable. The ITR ignores the TTL and performs a new lookup immediately. If the DNS hasn't been updated yet, it discards the unreachable ETR from the results and tries the next best. 2. No direct route to the Destination from the ETR. The packet moves towards the default route inside the AS which ends at another "end of the line mode" ITR. The ITR recognizes that there should have been a local route for the packet. As a result, it re-encapsulates the packet and sends it to the next best ETR which isn't local. This rerouting continues briefly until the DNS is updated and the ITR's copy of the DNS record expires. 3. No direct route to the Destination from the ETR. The ETR optionally sends a preemptive change notification to the ITR, advising it that it has no route to the destination. If the ITR is paying attention, it eliminates the ETR as a candidate for that destination. http://bill.herrin.us/network/trrp-preempt.html 4. DNS updated with new routes. The DNS server optionally sends a preemptive change notification to all addresses which recently requested the now-updated record. Where those DNS resolvers are also the ITRs, they'll re-lookup the route. http://bill.herrin.us/network/trrp-preempt.html 5. ITR is in "passthrough mode" rather than "end of the line" mode. In passthrough mode, the ITR attempts to encapsulate packets but retransmits them as raw IP towards the default route if it can't quickly do so. Passthrough mode is intended for a NAT firewall or the packet's originating host. These systems have state information about a number of the protocols moving through them. The ITR component can take a hint from lower-level retransmits and switch to an alternate ETR if the chosen ETR isn't getting the job done. The ITR has to be outside any NAT firewall for obvious reasons. As a result, "passthrough mode" is of limited utility in IPv4. IPv6 has no NAT, thus it should be possible to implement a passthrough-mode ITR on every IPv6 host that wants to with the resulting improvement in performance. 6. Simple case: the addresses are single-homed to a classic multihomed organization. For example, a customer of one ISP where the ISP is a DFZ participant. In this case, only one ETR is offered. Plain old BGP finds the new route to the CIDR block containing the ETR. The ETR itself is stateless; within the AS its address can be anycasted by any ETR device capable of doing the job. 7. Silent death. Either the ETR or destination is unreachable but none of the notifications make it back to the ITR. The destination remains unreachable until the TTL on the DNS response that provided it expires. The relookup is expected to withdraw the bad ETR and provide a new valid ETR. > > Hmm. Would you jimmie up an example of aberrant behavior you feel > > couldn't be adequately addressed within the ETR or ITR, or via > > existing mechanisms for protecting against spoofed addresses? > > Sections 14.1 to 14.1.2.5 cover this: > > http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor67 Thanks. I've read that, but I could use help constructing a scenario that behaves aberrantly under TRRP. For example, the ETR can be expected to filter packets claiming to be both from and to an address on its local lan. No properly configured ITR will generate such a packet. So, that case is eliminated as a spoofing possibility. Another example: an end-user org wants to stop spoofing at its upstream border even though it has multiple LANs and ITRs operating in passthrough mode. This remains possible. Implement a trivial split-horizon DNS at the resolver so that internal addresses are always directly routed. Then filter any packets with an internal source address at the ETR. So, this case is eliminated as a spoofing possibility. A bad example: an ISP wants to stop spoofing at its upstream borders. It can't do this for multihomed customers now. Packets from the customer could legitimately arrive from somewhere other than the customer's link. What's an example of a case that isn't susceptible to spoofing in today's network designs but would be susceptible with TRRP? Thanks, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 04:33: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 1INle3-0001Rn-S5; Wed, 22 Aug 2007 04:32:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INle2-0001Rc-BB for ram@iab.org; Wed, 22 Aug 2007 04:32:54 -0400 Received: from fk-out-0910.google.com ([209.85.128.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INle1-0005Ip-Fs for ram@iab.org; Wed, 22 Aug 2007 04:32:53 -0400 Received: by fk-out-0910.google.com with SMTP id 19so158613fkr for ; Wed, 22 Aug 2007 01:32:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cfGBPOSomBy+7nnHC7AAdayVa5OEiNzoSlPXFXT5OlllYstYvJoApl/xXoL6JoeybZJT7EUtsUlq1fFtLLNoh+drHHIWUkOOplxRu6GVTp6+18lTypIss3AxtFhR21iEPyWIXvF8Lug6edov0GZ8EHfz4t3GLLcpvSb9vwztVkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZtySiHkZ3y+egu038TGNoyNz8INhDcpwukCqkoEyhLucVFcHZazjcdGy946GLrWY6JU6PyQJ0q38PwFF4QnrX3/AYZ6iWLRyJYsHvaBHHRBCeeKqnIzXLJbbgmxffjFafNcOICad8NpTtunXdHm0+m/OxENG2i/9sQFpoEouV2g= Received: by 10.82.100.1 with SMTP id x1mr1017080bub.1187771572427; Wed, 22 Aug 2007 01:32:52 -0700 (PDT) Received: from ?192.168.1.58? ( [85.0.167.32]) by mx.google.com with ESMTPS id 2sm2202617nfv.2007.08.22.01.32.47 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Aug 2007 01:32:49 -0700 (PDT) Message-ID: <46CBF4A6.3020100@gmail.com> Date: Wed, 22 Aug 2007 10:32:38 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: William Herrin Subject: Re: [RAM] Tunnelling Route Reduction Protocol References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> <46CA50F0.2040001@firstpr.com.au> <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> In-Reply-To: <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-08-21 15:30, William Herrin wrote: ... > > 1. 99.9% of the time, the originator of the packet has already had to > do a DNS lookup or some other lookup to map a name to an IP address. > Doing another lookup for that first connection attempt leaves us in > the same ballpark speed-wise. Wouldn't that be 49.95%? Half of all first packets tend to be responses such as SYN/ACK that involve no DNS lookup. For a server handling thousands of requests per second, adding a lookup means holding thousands of TCBs in a wait state for the duration of the lookup. There are perhaps some interesting DDOS attacks there. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 10:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INraq-0005nB-5K; Wed, 22 Aug 2007 10:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrap-0005n6-4R for ram@iab.org; Wed, 22 Aug 2007 10:53:59 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INrao-0005MI-Re for ram@iab.org; Wed, 22 Aug 2007 10:53:59 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 90D7887303; Wed, 22 Aug 2007 10:53:50 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Tunnelling Route Reduction Protocol Message-Id: <20070822145350.90D7887303@mercury.lcs.mit.edu> Date: Wed, 22 Aug 2007 10:53:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Brian E Carpenter >> 99.9% of the time, the originator of the packet has already had to do >> a DNS lookup or some other lookup to map a name to an IP address. > Wouldn't that be 49.95%? Half of all first packets tend to be responses > such as SYN/ACK that involve no DNS lookup. For a server handling > thousands of requests per second, adding a lookup means holding > thousands of TCBs in a wait state for the duration of the lookup. True, but there's an obvious path to take in looking for delay improvments, which is to 'piggyback' the reverse mapping information on the connection opening. (Appending control traffic to user data is a technique with a long history in the data comm field, one that dates back to the ARPANet, where requests for the allocation of packet reassembly buffers in destination IMPs were piggybacked on the initial data fragment...) > There are perhaps some interesting DDOS attacks there. Alas, even with piggybacking on data traffic, there are a host of security issues. Sigh, TANSTAAFL... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 11:39:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsIg-0005Ll-PJ; Wed, 22 Aug 2007 11:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsIe-0005La-Om for ram@iab.org; Wed, 22 Aug 2007 11:39:16 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INsId-0006P8-Dh for ram@iab.org; Wed, 22 Aug 2007 11:39:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A80F51986A6; Wed, 22 Aug 2007 18:39:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5BF03198680; Wed, 22 Aug 2007 18:39:14 +0300 (EEST) Message-ID: <46CC58A2.6000309@piuha.net> Date: Wed, 22 Aug 2007 18:39:14 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc. References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> In-Reply-To: <46B8971C.3020008@firstpr.com.au> 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: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin, I'm in catchup e-mail mode... > Also, they would be running links to other offices, which would all > need to be broken and re-established on new IP addresses if > multihoming meant getting new addresses. > Just FYI... IPsec VPNs are are capable of surviving address changes when they are using either NAT traversal or IKE multihoming extensions (RFC 4555). > What about SSHing from outside into a server in the network? It > would be not such a good thing to find the server suddenly on > another IP address from last time, due to a multihoming service > restoration operation. I assume SSH would be fussy about that, but > perhaps I am wrong about that too. SSH could also be made resilient to address changes: http://www.usenix.org/events/usenix06/tech/full_papers/koponen/koponen_html/index.html This isn't used anywhere right now AFAIK and deals with the client side movements rather than the server. In any case... > Having the whole network suddenly adopt new addresses due to some > multihoming service restoration event sounds like 100% trouble and > 0% convenience and elegance. It would be far better to have > portable IP addresses which remained the same no matter what > happened with multihoming. > Sure -- I'm not advocating a model where all these things have to be taken into account by the individual protocols such as the ones above. However, given the state of the world right now, people have found ways to get many of their applications working despite IP address changes. Routing around damage, you might say... Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 15:24: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 1INvoi-00011Y-2t; Wed, 22 Aug 2007 15:24:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INvog-00011O-A6 for ram@iab.org; Wed, 22 Aug 2007 15:24:34 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INvoe-0002Df-PK for ram@iab.org; Wed, 22 Aug 2007 15:24:34 -0400 Received: from [131.179.33.100] (Cs-33-100.CS.UCLA.EDU [131.179.33.100]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l7MJOT3R000569; Wed, 22 Aug 2007 12:24:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8337AF64-9586-4265-8A92-0915457BF5C0@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Date: Wed, 22 Aug 2007 12:24:28 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.3 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IAB IAB Subject: [RAM] (no subject) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dear RAM list participants, As you all know, currently we have routing and addressing architecture discussions going on two separate mailing lists, RAM and RRG. This is solely a consequence of past events: RAM list was created November last year following the IAB workshop on routing and addressing. RRG was rechartered March this year to explore new routing architectures and protocols; since then RRG list has been carrying active discussions towards that goal. As RRG co-chairs, Tony Li and I would welcome all the related discussions occurring on the RRG list. However because RAM list started earlier, a big part of the discussions have continued on RAM list. Wearing my RAM list moderator hat, and with the agreement of the IAB, I would like to urge the community to move all the discussions around a new routing and addressing architecture research to RRG mailing list (To subscribe RRG list, send mail to rrg-request@psg.com with the word "subscribe" in the body of your email). The IAB plans to review, over time, whether the RAM list then continues to serve a useful function -- i.e., whether there are routing & addressing topics worthy of discussion that belong neither in the RRG discussions nor in any other existing IETF mailing list venue. Please feel free to help identify those topics and discussions. Other related IETF WGs include IDR and GROW at this time, and new venues may be created as results from the RRG or elsewhere reach status where standardization can begin. Lixia (with multiple hats on) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 18:41:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INytW-0007Rr-MJ; Wed, 22 Aug 2007 18:41:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INytW-0007Rc-5v for ram@iab.org; Wed, 22 Aug 2007 18:41:46 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INytU-0005js-Vc for ram@iab.org; Wed, 22 Aug 2007 18:41:46 -0400 Received: by nz-out-0506.google.com with SMTP id i28so197722nzi for ; Wed, 22 Aug 2007 15:41:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sQ7c4xk87iOv/5WmQaCZc6cloMzGxDqMzZ3rKqs7bXi+i3Xo0YIAPMmoaTAOhAq62+UxSTGzaWSv9A5y3srLMXU5BT35YTVt0pbM0bwFBEjs3jP1C0a191dzkj9rMTylfOpgHRWFRxH822vBPM3r5CADj8OVlQqIG49mmPK0bfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ksHbYTcKp9PITnB311rD5GAN5SqIdzR9CCd17Q1i5MnjFBo8QVrqlZTO5hiE8+g4y+DJwN03xupmM8sdaSKkK5zUkdqhL3fdkD2A86lUYIDcX0uJzkIlp8WRY33YEHyqI3L80XQbakAoga9eVT+qBhFyHwtwFVUCLusrGS/QEH8= Received: by 10.142.232.20 with SMTP id e20mr147075wfh.1187822503431; Wed, 22 Aug 2007 15:41:43 -0700 (PDT) Received: by 10.143.159.7 with HTTP; Wed, 22 Aug 2007 15:41:43 -0700 (PDT) Message-ID: <3c3e3fca0708221541w72cce046kbece41107e1da688@mail.gmail.com> Date: Wed, 22 Aug 2007 18:41:43 -0400 From: "William Herrin" To: "Brian E Carpenter" Subject: Re: [RAM] Tunnelling Route Reduction Protocol In-Reply-To: <46CBF4A6.3020100@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> <46CA50F0.2040001@firstpr.com.au> <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> <46CBF4A6.3020100@gmail.com> X-Google-Sender-Auth: efa6aa0dc0f7d712 X-Spam-Score: 0.9 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 8/22/07, Brian E Carpenter wrote: > On 2007-08-21 15:30, William Herrin wrote: > > 1. 99.9% of the time, the originator of the packet has already had to > > do a DNS lookup or some other lookup to map a name to an IP address. > > Wouldn't that be 49.95%? Half of all first packets tend to be > responses such as SYN/ACK that involve no DNS lookup. Hi Brian, Its still 99.9%; the return packet is part of the initial transaction. But you're right, there are potentially two extra lookup delays on that first transaction in addition to the original name to IP lookup. If the network operator is sloppy then there could be more. If the DNS resolver doesn't refer queries through a resolver on globally routable space or the authoratative name to ip DNS server isn't on globally routable space then there could be a dozen lookups to get to the point where the two endpoints are talking and all pertinent routes are cached. That's avoided by good operations practice, so I'm not too worried about it. > For a server > handling thousands of requests per second, adding a lookup means > holding thousands of TCBs in a wait state for the duration of the > lookup. There are perhaps some interesting DDOS attacks there. Shouldn't be much different that you see with SYN floods and SYN cookies now. I suspect the worst DOS would involve sending packets to random addresses. The ITR lookups run afoul of the same problem that Cisco fast-switching did: overwhelming the cache. The ITR would have to take care not to discard routes for sessions that have seen a lot of packets in favor of pending lookups or routes that have only seen a few packets. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 19:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzJ4-0006Ee-Vb; Wed, 22 Aug 2007 19:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzJ3-0006Dc-6w for ram@iab.org; Wed, 22 Aug 2007 19:08:09 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INzJ2-0006IM-PS for ram@iab.org; Wed, 22 Aug 2007 19:08:09 -0400 Received: by nz-out-0506.google.com with SMTP id i28so201162nzi for ; Wed, 22 Aug 2007 16:08:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bYJGbhsNMCL+z+4/opkYNj/j0zWy6bD397KOxW6powM8O1MiCZgIucVpeKMRDxolI0X5g3rt2ODly4lB+dUnueVOJmYzV6NK7WgJj4MK9R09z/pSR9ftWbcV1B/KicuisGLwHGVWpsY40hBo2CDkvtZgDMTcG7pQRXJrQEvRUWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UFMRMmZJ5p4XBPxzdMZpkRmCYUzgozvxs1bRqxw6sx9ECkuO6fhVbVbsFQpmxEadJHU5aCFj6v1p7s/OcR9zk/q0OEEbw6WDJD9IUiQembyj1GNghvsQ1QOvl8KSfmyHJpIR460JBzRifKNgFhxcw/AJUYh/nn/FzFJldbmfpDo= Received: by 10.142.232.20 with SMTP id e20mr147691wfh.1187824087907; Wed, 22 Aug 2007 16:08:07 -0700 (PDT) Received: by 10.143.159.7 with HTTP; Wed, 22 Aug 2007 16:08:07 -0700 (PDT) Message-ID: <3c3e3fca0708221608k736ded33n59604b68daba0998@mail.gmail.com> Date: Wed, 22 Aug 2007 19:08:07 -0400 From: "William Herrin" To: "Noel Chiappa" Subject: Re: [RAM] Tunnelling Route Reduction Protocol In-Reply-To: <20070822145350.90D7887303@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070822145350.90D7887303@mercury.lcs.mit.edu> X-Google-Sender-Auth: 9baec8cfae1e53bf X-Spam-Score: 0.9 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 8/22/07, Noel Chiappa wrote: > > Wouldn't that be 49.95%? Half of all first packets tend to be responses > > such as SYN/ACK that involve no DNS lookup. For a server handling > > thousands of requests per second, adding a lookup means holding > > thousands of TCBs in a wait state for the duration of the lookup. > > True, but there's an obvious path to take in looking for delay improvments, > which is to 'piggyback' the reverse mapping information on the connection > opening. Hi Noel, I considered such an approach. There are several potential problems but the most serious is authentication. I can generally trust a response to my own query that followed the authoritative server chain. Theoretically a man-in-the-middle attack is possible, but operationally it has proven to be a non-issue. I can never trust data encoded in a random received packet to give me valid route to a particular destination without first applying a fairly elaborate authentication scheme. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 19:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzPb-0007vW-1T; Wed, 22 Aug 2007 19:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzPa-0007vR-Ay for ram@iab.org; Wed, 22 Aug 2007 19:14:54 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INzPZ-0006NO-TN for ram@iab.org; Wed, 22 Aug 2007 19:14:54 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B474986AE1; Wed, 22 Aug 2007 19:14:49 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Tunnelling Route Reduction Protocol Message-Id: <20070822231449.B474986AE1@mercury.lcs.mit.edu> Date: Wed, 22 Aug 2007 19:14:49 -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: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: "William Herrin" >> an obvious path to take in looking for delay improvments, which is >> to 'piggyback' the reverse mapping information on the connection >> opening. > There are several potential problems but the most serious is > authentication. Yeah, I know - I've been doing some thinking in this area myself recently. I know about the authentication - what are the other problems? > Theoretically a man-in-the-middle attack is possible, but > operationally it has proven to be a non-issue. Well, there's also plain DoS - someone sends a packet claiming to be from X, with a mapping for X, and the mapping is bogus, and sends the traffic to somewhere random, or non-existent. (Or by MITM did you mean that a bogus mapping would send the reply traffic somewhere, which inspects it, and passes it on? I assumed you meant MITM in procuring the binding, not MITM in the ensuing user data traffic stream.) > I can never trust data encoded in a random received packet to give me > valid route to a particular destination without first applying a > fairly elaborate authentication scheme. Yes, that's the problem I'm struggling with ... :-( Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 22 19:52: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 1INzzt-0005aa-3e; Wed, 22 Aug 2007 19:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzzr-0005We-P6 for ram@iab.org; Wed, 22 Aug 2007 19:52:23 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INzzq-0007Js-Qw for ram@iab.org; Wed, 22 Aug 2007 19:52:23 -0400 Received: by nz-out-0506.google.com with SMTP id i28so205482nzi for ; Wed, 22 Aug 2007 16:52:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YHAOLN20FZGSRrPNGhZ5JiZnSMSV0UKnw+6s24cijJ8clkAiUcdN4wGQfMfWclkDuVt5E0i7cp0lgalygd70ffEDBCkpe0+nO/S7geDm3Stw/R+Act12zo7Qid7ErIxdZRr3plgXkIoY8PtzftmBMupOQLkRILUTdOHT6swcV+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Y0avGEAVhniyhNHa9vXc18sCVAZxFM4utyKAtaEtVdJeMdoCLx/aEsJDBXlNaUIUvah9spyeCKRUO2uKBvTasVns1puuGPoDMJpYygDr8Vv99MW12IOUz2It3cu9kjXmpF3Jry8zRQG8Pe9+smxVF11y/45Dmg+C8KKPKWa01bE= Received: by 10.143.10.15 with SMTP id n15mr147421wfi.1187826739858; Wed, 22 Aug 2007 16:52:19 -0700 (PDT) Received: by 10.143.159.7 with HTTP; Wed, 22 Aug 2007 16:52:19 -0700 (PDT) Message-ID: <3c3e3fca0708221652h4baffd8dia3dcfe338b258f8c@mail.gmail.com> Date: Wed, 22 Aug 2007 19:52:19 -0400 From: "William Herrin" To: ram@iab.org Subject: Re: [RAM] Tunnelling Route Reduction Protocol In-Reply-To: <20070822231449.B474986AE1@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070822231449.B474986AE1@mercury.lcs.mit.edu> X-Google-Sender-Auth: aa9c75767e52aa50 X-Spam-Score: 0.9 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 8/22/07, Noel Chiappa wrote: > > There are several potential problems but the most serious is > > authentication. > > Yeah, I know - I've been doing some thinking in this area myself recently. > I know about the authentication - what are the other problems? Hi Noel, Well, if the ITR is expected to encode the return information in its communication with the ETR then every possible ITR for a given source address needs authoritative knowledge of every possible ETR for that address and it has to be able to implement the policy rules for traffic engineering with respect to those addresses. That requires significant complexity in the ITRs and since the policy rules have to match what the ITRs are capable of implementing, they're not likely to be very flexible. With strictly forward-lookups like what I have in TRRP, traffic engineering is the responsibility of the route-server and it can be arbitrarily complex. > > Theoretically a man-in-the-middle attack is possible, but > > operationally it has proven to be a non-issue. > > Well, there's also plain DoS - someone sends a packet claiming to be from > X, with a mapping for X, and the mapping is bogus, and sends the traffic to > somewhere random, or non-existent. I meant that man-in-the-middle is a theoretical issue with a DNS lookup like proposed in TRRP. A MitM could forge the DNS reply, causing the ITR to route traffic by way of an ETR on a network that should never see it. That's what DNSSEC is all about: it eliminates the attack vector. DNSSEC hasn't been widely adopted because operationally the attack vector hasn't proven to be a enough of a problem. If its not a problem when mapping www.google.com to 1.2.3.4 then its not likely to be a problem for mapping IP addresses to ETRs. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 27 04:54: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 1IPaMt-0000yt-Op; Mon, 27 Aug 2007 04:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPaMs-0000vM-Vt for ram@iab.org; Mon, 27 Aug 2007 04:54:42 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPaMq-0003bL-76 for ram@iab.org; Mon, 27 Aug 2007 04:54:42 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNF00IQ2CJMOR@szxga01-in.huawei.com> for ram@iab.org; Mon, 27 Aug 2007 16:50:10 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNF00I05CJH3N@szxga01-in.huawei.com> for ram@iab.org; Mon, 27 Aug 2007 16:50:09 +0800 (CST) Date: Mon, 27 Aug 2007 16:50:05 +0800 From: Xu Xiaohu To: sbrim@cisco.com, rrg@psg.com, ram@iab.org Message-id: <000501c7e887$43bd58e0$5e0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acfoh0M85zztTCuTTCaI+X2LxI19Hg== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi all, I have a doubt about how to avoid black-hole in LISP-CONS with aggregation mechanism? My doubt is explained as follows: +---------+ 1.0.0.0/8 CDR-1 | CDR-3 | +----+---\+ 1.1.0.0/16 CDR-2 / \\ Push 1.0.0.0/8 / \ Push 1.1.0.0/16 // \\ +----/---+ 1.1.0.0/16 CAR-1 +--\-----+ | CDR-1 | 1.2.0.0/16 CAR-2 | CDR-2 | 1.1.0.0/16 CAR-3 +---+--\-+ +---+----+ | \\ | | \\ Push 1.2.0.0/16 |Push 1.1.0.0/16 Push 1.1.0.0/16 \\ | | \\ | +---+----+ +---\------+ +----+----+ | CAR-1 | | CAR-2 | | CAR-3 | +--------+ +----------+ +---------+ 1.1.0.0/24 1.2.0.0/24 1.1.2.0/24 1.1.1.0/24 1.2.1.0/24 1.1.3.0/24 As shown in the above figure, CAR-1 has two EID-prefixes, 1.1.0.0/24 and 1.1.1.0/24, and it sends an aggregated EID-prefix 1.1.0.0/16 to CDR-1. CAR-2 also sends an aggregated EID-prefix 1.2.0.0/16 to CDR-1. CDR-1 sends an aggregated EID-prefix 1.0.0.0/8 to its parent CDR, CDR-3. CAR-3 has two EID-prefixes, 1.1.2.0/24 and 1.1.3.0/24, and it sends an aggregated EID-prefix 1.1.0.0/16 to CDR-2. CDR-2 sends a EID-prefix 1.1.0.0/16 to its parent CDR, CDR-3. Now CDR-3 has two EID-prefixes, one is 1.0.0.0/8 with a nexthop of CDR-1, the other is 1.1.0.0/16 with a nexthop of CDR-2. If CDR-3 receives a mapping request for longest-matching entry for 1.1.1.1, it will result in a black-hole. How to avoid it? Use the same aggregation granularity within the same level? Or aggregation will not be available until all the component EID-prefixes exists in the EID-prefix database of the aggregation attempter? Best regards, Steven XU _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 27 04:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPaOn-000371-5c; Mon, 27 Aug 2007 04:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPaOk-00036Y-Gm for ram@iab.org; Mon, 27 Aug 2007 04:56:38 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPaOi-0003dC-5b for ram@iab.org; Mon, 27 Aug 2007 04:56:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNF00I1KCT1UU@szxga02-in.huawei.com> for ram@iab.org; Mon, 27 Aug 2007 16:55:49 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNF0079DCSXXM@szxga02-in.huawei.com> for ram@iab.org; Mon, 27 Aug 2007 16:55:49 +0800 (CST) Date: Mon, 27 Aug 2007 16:55:45 +0800 From: Xu Xiaohu In-reply-to: To: sbrim@cisco.com, rrg@psg.com, ram@iab.org Message-id: <000b01c7e888$0e6fe940$5e0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acfoh0M85zztTCuTTCaI+X2LxI19HgAAJacQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi all, I have a doubt about how to avoid black-hole in LISP-CONS with aggregation mechanism? My doubt is explained as follows: +---------+ 1.0.0.0/8 CDR-1 | CDR-3 | +----+---\+ 1.1.0.0/16 CDR-2 / \\ // \ // \\ Push 1.0.0.0/8 / \ Push 1.1.0.0/16 / \ / \\ // \ // \\ +----/---+ 1.1.0.0/16 CAR-1 +--\-----+ |CDR-1 | 1.2.0.0/16 CAR-2 |CDR-2 | 1.1.0.0/16 CAR-3 +---+--\-+ +---+----+ | \\ | | \\ | | \\ Push 1.2.0.0/16 |Push 1.1.0.0/16 Push 1.1.0.0/16 \\ | | \\ | | \\ | | \\ | +---+----+ +---\------+ +----+----+ |CAR-1 | |CAR-2 | |CAR-3 | +--------+ +----------+ +---------+ 1.1.0.0/24 1.2.0.0/24 1.1.2.0/24 1.1.1.0/24 1.2.1.0/24 1.1.3.0/24 As shown in the above figure, CAR-1 has two EID-prefixes, 1.1.0.0/24 and 1.1.1.0/24, and it sends an aggregated EID-prefix 1.1.0.0/16 to CDR-1. CAR-2 also sends an aggregated EID-prefix 1.2.0.0/16 to CDR-1. CDR-1 sends an aggregated EID-prefix 1.0.0.0/8 to its parent CDR, CDR-3. CAR-3 has two EID-prefixes, 1.1.2.0/24 and 1.1.3.0/24, and it sends an aggregated EID-prefix 1.1.0.0/16 to CDR-2. CDR-2 sends a EID-prefix 1.1.0.0/16 to its parent CDR, CDR-3. Now CDR-3 has two EID-prefixes, one is 1.0.0.0/8 with a nexthop of CDR-1, the other is 1.1.0.0/16 with a nexthop of CDR-2. If CDR-3 receives a mapping request for longest-matching entry for 1.1.1.1, it will result in a black-hole. How to avoid it? Use the same aggregation granularity within the same level? Or aggregation will not be available until all the component EID-prefixes exists in the EID-prefix database of the aggregation attempter? Best regards, Steven XU _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 27 09:19: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 1IPeVX-0006e1-Vx; Mon, 27 Aug 2007 09:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeVW-0006dw-Oh for ram@iab.org; Mon, 27 Aug 2007 09:19:54 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPeVV-0008PU-IX for ram@iab.org; Mon, 27 Aug 2007 09:19:54 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 21BB5872F4; Mon, 27 Aug 2007 09:19:53 -0400 (EDT) To: ram@iab.org, rrg@psg.com Subject: Re: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism? Message-Id: <20070827131953.21BB5872F4@mercury.lcs.mit.edu> Date: Mon, 27 Aug 2007 09:19:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Xu Xiaohu > how to avoid black-hole in LISP-CONS with aggregation mechanism? > ... > Now CDR-3 has two EID-prefixes, one is 1.0.0.0/8 with a nexthop of > CDR-1, the other is 1.1.0.0/16 with a nexthop of CDR-2. If CDR-3 > receives a mapping request for longest-matching entry for 1.1.1.1, it > will result in a black-hole. Yes, this is a problem. I identified the same problem back in early July, and raised it with the CONS authors privately. > How to avoid it? Use the same aggregation granularity within the same > level? Or aggregation will not be available until all the component > EID-prefixes exists in the EID-prefix database of the aggregation > attempter? It seemed to me that the only way it can work is to have the requirements that all CDRs which are 'authoritative' (to borrow terminology from DNS) for a particular portion S of the address space i) have to all be siblings, and ii) have to know which sub-portions of S each of their siblings is authoritative for, to allow requests to be forwarded to the correct sibling CDR, if it arrives at a CDR which is not authoritative for the particlar sub-portion of S which the request is in. I did discuss this with the authors, and I think that was the answer, but I can't verify that because we took the issue up on a conference call, and I don't have notes of everything that was said there! (Something to remember is that he CONS specification in the Internet-Draft is really a very early draft, and so there are some issues (such as this one) which aren't clearly covered yet.) Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 27 13:46:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPifE-0003a7-Bf; Mon, 27 Aug 2007 13:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPifD-0003ZQ-Ei for ram@iab.org; Mon, 27 Aug 2007 13:46:11 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPifC-000824-68 for ram@iab.org; Mon, 27 Aug 2007 13:46:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Aug 2007 10:46:09 -0700 X-IronPort-AV: i="4.19,312,1183359600"; d="scan'208"; a="172995271:sNHT515845449" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7RHk9CP022439; Mon, 27 Aug 2007 10:46:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7RHk9xl014641; Mon, 27 Aug 2007 17:46:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:46:09 -0700 Received: from [192.168.0.3] ([10.21.86.124]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:46:08 -0700 In-Reply-To: <000501c7e887$43bd58e0$5e0c6f0a@china.huawei.com> References: <000501c7e887$43bd58e0$5e0c6f0a@china.huawei.com> 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: Dino Farinacci Subject: Re: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism? Date: Mon, 27 Aug 2007 10:46:09 -0700 To: Xu Xiaohu X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Aug 2007 17:46:08.0748 (UTC) FILETIME=[2658D2C0:01C7E8D2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2768; t=1188236769; x=1189100769; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20How=20to=20avoid=20black-hole=20in=20LISP-CON S=20with=20aggregation=20mechanism? |Sender:=20; bh=MkoKVfIccKomapF0UeIXLGfCWsxM8XCV3JpTX5+dJO4=; b=VkIuKdJ9Tr7eCnbBoKmBRynWwHFCI7RPoPEX8xD8Wza8vZocC6FgFwH0y2wITd9mEcZJMI/z k1cgbp9B9TP8xehZoE1J8irGBLorRXg2hwIjd0AnKgoErhB1i5UqTwfO; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ram@iab.org, sbrim@cisco.com, rrg@psg.com X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Hi all, > I have a doubt about how to avoid black-hole in LISP-CONS with > aggregation > mechanism? My doubt is explained as follows: > +---------+ 1.0.0.0/8 CDR-1 > | CDR-3 | > +----+---\+ 1.1.0.0/16 CDR-2 > / \\ > Push 1.0.0.0/8 / \ Push 1.1.0.0/16 > // \\ > +----/---+ 1.1.0.0/16 CAR-1 +--\-----+ > | CDR-1 | 1.2.0.0/16 CAR-2 | CDR-2 | 1.1.0.0/16 > CAR-3 > +---+--\-+ +---+----+ > | \\ | > | \\ Push 1.2.0.0/16 |Push 1.1.0.0/16 > Push 1.1.0.0/16 \\ | > | \\ | > +---+----+ +---\------+ +----+----+ > | CAR-1 | | CAR-2 | | CAR-3 | > +--------+ +----------+ +---------+ > 1.1.0.0/24 1.2.0.0/24 1.1.2.0/24 > 1.1.1.0/24 1.2.1.0/24 1.1.3.0/24 > > As shown in the above figure, CAR-1 has two EID-prefixes, > 1.1.0.0/24 and > 1.1.1.0/24, and it sends an aggregated EID-prefix 1.1.0.0/16 to > CDR-1. CAR-2 > also sends an aggregated EID-prefix 1.2.0.0/16 to CDR-1. CDR-1 > sends an > aggregated EID-prefix 1.0.0.0/8 to its parent CDR, CDR-3. > CAR-3 has two EID-prefixes, 1.1.2.0/24 and 1.1.3.0/24, and it sends an > aggregated EID-prefix 1.1.0.0/16 to CDR-2. CDR-2 sends a EID-prefix > 1.1.0.0/16 to its parent CDR, CDR-3. > Now CDR-3 has two EID-prefixes, one is 1.0.0.0/8 with a nexthop of > CDR-1, > the other is 1.1.0.0/16 with a nexthop of CDR-2. If CDR-3 receives > a mapping > request for longest-matching entry for 1.1.1.1, it will result in a > black-hole. > > How to avoid it? Use the same aggregation granularity within the > same level? > Or aggregation will not be available until all the component EID- > prefixes > exists in the EID-prefix database of the aggregation attempter? The diagram has two problems: 1) You are aggregating to the same level (to CDR-3) with different mask-lengths. 2) CDR-1 and CDR-2 need to be part of the same CDR-mesh. That is all the CARs 1-3 are authoritative for the same length prefix and hence need to advertise to the same mesh upstream. Now having said that, you could have CAR-1 and CAR-3 advertise to the same CDR-1 mesh, but since CAR-2 has 1.2 as it's prefix, it could advertise into CAR-3 which is a different CDR-mesh. And then both CDR-1 and CDR-2 can advertise 1.0.0.0/8 upstream to CDR-3. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Aug 27 18:02: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 1IPmeh-0005XI-2h; Mon, 27 Aug 2007 18:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmef-0005Te-P8 for ram@iab.org; Mon, 27 Aug 2007 18:01:53 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPmee-00070v-Av for ram@iab.org; Mon, 27 Aug 2007 18:01:53 -0400 Received: from [192.168.100.152] (p1199-ipbf308kyoto.kyoto.ocn.ne.jp [122.22.1.199]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l7RM1URX015395; Mon, 27 Aug 2007 15:01:30 -0700 (PDT) In-Reply-To: <000501c7e887$43bd58e0$5e0c6f0a@china.huawei.com> References: <000501c7e887$43bd58e0$5e0c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CAA53D5-D9B9-43B8-B15D-3288D47C7797@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Date: Mon, 27 Aug 2007 15:01:33 -0700 To: Xu Xiaohu X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ram@iab.org Subject: [RAM] Re: [RRG] How to avoid black-hole in LISP-CONS with aggregation mechanism? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dear Steven XU, Please do not double-post to both RAM and RRG lists. Per my earlier message, please carry out this discussion on RRG list. Lixia (RAM moderator hat on) PS: to subscribe RRG list, send mail to rrg-request@psg.com with the word "subscribe" in the body of your email. On Aug 27, 2007, at 1:50 AM, Xu Xiaohu wrote: > Hi all, > I have a doubt about how to avoid black-hole in LISP-CONS with > aggregation > mechanism? My doubt is explained as follows: > +---------+ 1.0.0.0/8 CDR-1 > | CDR-3 | > +----+---\+ 1.1.0.0/16 CDR-2 > / \\ > Push 1.0.0.0/8 / \ Push 1.1.0.0/16 > // \\ > +----/---+ 1.1.0.0/16 CAR-1 +--\-----+ > | CDR-1 | 1.2.0.0/16 CAR-2 | CDR-2 | 1.1.0.0/16 > CAR-3 > +---+--\-+ +---+----+ > | \\ | > | \\ Push 1.2.0.0/16 |Push 1.1.0.0/16 > Push 1.1.0.0/16 \\ | > | \\ | > +---+----+ +---\------+ +----+----+ > | CAR-1 | | CAR-2 | | CAR-3 | > +--------+ +----------+ +---------+ > 1.1.0.0/24 1.2.0.0/24 1.1.2.0/24 > 1.1.1.0/24 1.2.1.0/24 1.1.3.0/24 > > As shown in the above figure, CAR-1 has two EID-prefixes, > 1.1.0.0/24 and > 1.1.1.0/24, and it sends an aggregated EID-prefix 1.1.0.0/16 to > CDR-1. CAR-2 > also sends an aggregated EID-prefix 1.2.0.0/16 to CDR-1. CDR-1 > sends an > aggregated EID-prefix 1.0.0.0/8 to its parent CDR, CDR-3. > CAR-3 has two EID-prefixes, 1.1.2.0/24 and 1.1.3.0/24, and it sends an > aggregated EID-prefix 1.1.0.0/16 to CDR-2. CDR-2 sends a EID-prefix > 1.1.0.0/16 to its parent CDR, CDR-3. > Now CDR-3 has two EID-prefixes, one is 1.0.0.0/8 with a nexthop of > CDR-1, > the other is 1.1.0.0/16 with a nexthop of CDR-2. If CDR-3 receives > a mapping > request for longest-matching entry for 1.1.1.1, it will result in a > black-hole. > > How to avoid it? Use the same aggregation granularity within the > same level? > Or aggregation will not be available until all the component EID- > prefixes > exists in the EID-prefix database of the aggregation attempter? > > Best regards, > Steven XU > > > > -- > to unsubscribe send a message to rrg-request@psg.com with the > word 'unsubscribe' in a single line as the message text body. > archive: & ftp://psg.com/pub/lists/rrg _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Aug 29 08:23: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 1IQMZY-00035z-AE; Wed, 29 Aug 2007 08:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMZW-00035p-4l for ram@iab.org; Wed, 29 Aug 2007 08:22:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQMZU-0005wX-UL for ram@iab.org; Wed, 29 Aug 2007 08:22:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Aug 2007 08:22:56 -0400 X-IronPort-AV: i="4.19,321,1183348800"; d="scan'208"; a="69411831:sNHT47648336" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7TCMu12029071; Wed, 29 Aug 2007 08:22:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7TCMuQM007578; Wed, 29 Aug 2007 12:22:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:22:56 -0400 Received: from sbrimMBP.local ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:22:55 -0400 Message-ID: <46D5651F.5050608@employees.org> Date: Wed, 29 Aug 2007 08:22:55 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism? References: <20070827131953.21BB5872F4@mercury.lcs.mit.edu> In-Reply-To: <20070827131953.21BB5872F4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 12:22:55.0836 (UTC) FILETIME=[5418C9C0:01C7EA37] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rrg@psg.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 8/27/07 9:19 AM, Noel Chiappa allegedly wrote: > > From: Xu Xiaohu > > > how to avoid black-hole in LISP-CONS with aggregation mechanism? > > ... > > Now CDR-3 has two EID-prefixes, one is 1.0.0.0/8 with a nexthop of > > CDR-1, the other is 1.1.0.0/16 with a nexthop of CDR-2. If CDR-3 > > receives a mapping request for longest-matching entry for 1.1.1.1, it > > will result in a black-hole. > > Yes, this is a problem. I identified the same problem back in early July, and > raised it with the CONS authors privately. > > > How to avoid it? Use the same aggregation granularity within the same > > level? Or aggregation will not be available until all the component > > EID-prefixes exists in the EID-prefix database of the aggregation > > attempter? > > It seemed to me that the only way it can work is to have the requirements that > all CDRs which are 'authoritative' (to borrow terminology from DNS) for a > particular portion S of the address space i) have to all be siblings, and ii) > have to know which sub-portions of S each of their siblings is authoritative > for, to allow requests to be forwarded to the correct sibling CDR, if it > arrives at a CDR which is not authoritative for the particlar sub-portion of > S which the request is in. Agreed. You simply wouldn't set up the CDR tree like this. In this case you would re-home the CARs so that they hung off the appropriate aggregating CDRs (for example, CAR-3 off CDR-1). This is an administrative tree and physical topology isn't a limiting factor. In fact you might expect authoritative CARs for a particular EID prefix to be geographically separated. Scott _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram