[Fwd: Re: Fourth alternative [was Re: Moving forward ....]]
FYI, I sent this while the list was having problems yesterday. Since then, I have come to understand that one or more proposals may be coming out of the multi6 wg in the near future. Looking forward with an open mind to what may be in the proposals. Fred [EMAIL PROTECTED] Original Message Subject: Re: Fourth alternative [was Re: Moving forward ] Date: Wed, 20 Aug 2003 10:02:25 -0700 From: Fred Templin [EMAIL PROTECTED] To: Erik Nordmark [EMAIL PROTECTED] CC: Bob Hinden [EMAIL PROTECTED], Ralph Droms [EMAIL PROTECTED], [EMAIL PROTECTED] References: [EMAIL PROTECTED] Erik, Erik Nordmark wrote FWIW, I think a multi6 solution with id/loc separation will make the local addressing concerns go away. As I asked others in earlier discussion, if you know of a multi6 solution proposal please do tell. I have been loosely following the HIP work, and I see the benefits of a stable, portable identifier for use by applications that can be dynamically (re)associated with locators by the network, e.g., due to roaming events. Can HIP or something like it do this? Will we be seeing a multi6 proposal in the near future? Thanks - Fred [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
On Tue, 19 Aug 2003 18:04:05 -0700 Tony Hain [EMAIL PROTECTED] wrote: Erik Nordmark wrote: ... FWIW, I think a multi6 solution with id/loc separation will make the local addressing concerns go away. Well a 'solution' might do that, but I don't see one happening in our lifetimes. Any separation will require a mapping infrastructure to dynamically bind the values back together. agreed. Such a mapping infrastructure will have all of the scaling concerns of DNS, Not clear. Nothing says that the mapping service has to be organized like DNS. It is not inherently necessary (though quite possibly desirable) that assignment of stable IDs be federated similarly to the way address blocks are federated, so that the service can do mapping on a per-block basis rather than a per-address basis. However, there is no inherent reason that the servers that provide the mapping have to be provided by the assignees of those ID blocks. Nor is there any inherent reason that propagation of updates has to be like DNS. plus the constraint that its convergence times are extremely short. There is no well-known technology for running a global multi-master, cross trust boundary, database, with appropriate caching for scale, and convergence times that are useful for application failover. What would you call BGP then? Granted, it's not exactly a database, but it's certainly multi-master and cross trust boundary and it at least attempts to converge within a timeframe in which apps can fail over. I'm not claiming that defining this mapping infrastructure is an easy problem - certainly it is not. However it doesn't seem like a good idea to assume that it needs to look like DNS. If anything, it's precisely because we know the pitfalls of DNS, that we should look for a somewhat different solution. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Erik Nordmark wrote: FWIW, I think a multi6 solution with id/loc separation will make the local addressing concerns go away. If it provides something that is almost as good as PI. Tony Hain wrote: Any separation will require a mapping infrastructure to dynamically bind the values back together. Keith Moore wrote: agreed. Ditto. Such a mapping infrastructure will have all of the scaling concerns of DNS, Nor is there any inherent reason that propagation of updates has to be like DNS. Agree. plus the constraint that its convergence times are extremely short. There is no well-known technology for running a global multi-master, cross trust boundary, database, with appropriate caching for scale, and convergence times that are useful for application failover. It is not needed as long as the id/loc system does not need the full database to be fully replicated all over the world at all times. In other words, the requirements for that global multi-master, cross trust boundary database can be lessened by an id/loc system that could accommodate a partial picture as a bootstrap phase for its own mapping, and the convergence time can be brought by the id/loc protocol instead of database convergence. What would you call BGP then? Granted, it's not exactly a database, but it's certainly multi-master and cross trust boundary and it at least attempts to converge within a timeframe in which apps can fail over. I think that for practical purposes it's close enough of the definition of a database. Granted, it is not nearly as complex as OSPF but it could be called a database. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
It's from my reading of the discussion (on the mailing list and in the meetings) and the fact that the working group decided to accept draft-hinden-ipv6-global-local-addr-02.txt as a working group document in Vienna. I didn't know there were such side effects associated with accepting that as a WG document. My assumption was that it was a fine thing to work on possible replacements and to understand the cost/benefit tradeoffs of such replacements. But presumably the WG should be capable to still say we don't like any of them. Your logic seems to preclude such a conclusion. FWIW, I think a multi6 solution with id/loc separation will make the local addressing concerns go away. Erik IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Erik: I'm going to poke my nose into this thread in hope of alleviating some possible misapprehension concerning interpretation of the original fourth alternative text. Please see below for comments. On Tue, 19 Aug 2003, Erik Nordmark wrote: It's from my reading of the discussion (on the mailing list and in the meetings) and the fact that the working group decided to accept draft-hinden-ipv6-global-local-addr-02.txt as a working group document in Vienna. I didn't know there were such side effects associated with accepting that as a WG document. My assumption was that it was a fine thing to work on possible replacements and to understand the cost/benefit tradeoffs of such replacements. But presumably the WG should be capable to still say we don't like any of them. Your logic seems to preclude such a conclusion. From a review of previous messages in this thread, the text which seems to have trigged the above is: Furthermore, based on the record of the question from the minutes of the SF meeting and the question put to the ipng mailing list, how was this conclusion arrived at: A fourth alternative is to not replace site-local addresses in any form, but I think the working group has made it clear that this is not a reasonable alternative. As I interpret Bob's text cited at the head of this note, the citing of the decision to accept draft-hinden-ipv6-global-local-addr-02.txt as a WG document is evidence in support of the assertion that the fourth alternative (specifically, to decline to replace site locals in any form) has not found any credible level of support in the list. As I interpret the history, and based on my memory of the tenor of disussions at Vienna (yes, I snuck in), the decision to accept said draft as a WG document was a direct result of the WG collective opinion that one or more alternatives to SL are clearly necessary, and that draft-hinden-ipv6-global-local-addr-02.txt offers at least the potential of a workable alternative. Based on this sequence and history, the decision to accept the Hinden draft was a consequence, rather than the origin, of the disapprobation of the suggestion to deprecate Site-Locals without pursuing work on suitable replacements for local addressing allocations. As I remember the discussions, it is not Bob's logic, but rather the collective logic of the group as demonstrated in the WG decision (expressed as a show of hands), which precludes the conclusion that SL may or should be deprecated without some provision for work on viable alternatives. Notwithstanding the very strong IETF tradition of stare decisis, it is possible (although not, IMO, likely) that after discussion we will conclude that we cannot find a workable alternative. Should we reach this eventuality, we will have, if deprecation of SL proceeds before viable alternatives are codified, exactly the condition postulated in the fourth alternative; but that is, as I read the history, clearly _not_ the intended outcome. (If anyone is brave enough to attempt a diagram of that last sentence, I'd love to see the result. ;-( ) FWIW, I think a multi6 solution with id/loc separation will make the local addressing concerns go away. While a multi6 solution such as you suggest above would undoubtedly obviate one set of requirements which drive demand for local addressing, other requirement sets now extant will not be obviated thereby; the demand for local addressing will persist until _all_ requirement sets which drive that demand are satisfied by other solutions. Some of these requirement sets (such as address stability and address portability for enterprise networks across ISP changes) are perhaps less amenable to engineered solutions than are the multihoming issues. I devoutly wish that the issue of local addressing were so straightforward that a single solution would resolve the issue entirely; sadly, that does not appear to be the case, based discussions in this WG. Regards, AEB -- Alan E. Beard [EMAIL PROTECTED] AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Erik, At 07:02 AM 8/19/2003, Erik Nordmark wrote: I didn't know there were such side effects associated with accepting that as a WG document. My assumption was that it was a fine thing to work on possible replacements and to understand the cost/benefit tradeoffs of such replacements. But presumably the WG should be capable to still say we don't like any of them. Your logic seems to preclude such a conclusion. I don't think it precludes such a conclusion in the future as any solution will need to go through normal IETF processes to advance. But I do think it represented a reasonable conclusion at the time based on the Vienna IETF sessions and subsequent discussion. FWIW, I think a multi6 solution with id/loc separation will make the local addressing concerns go away. Also FWIW, I think opinions differ on this topic and we will know more when there is a specified solution so it's benefits and weaknesses can be evaluated. I note that people have been talking about for almost as long as IPv6 has been around. However, I think it would be unwise for the working group to defer what we can do now in this area to wait for this to happen. When or if it happens, it's benefits will encourage everyone to adopt it quickly. Bob IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Erik Nordmark wrote: ... FWIW, I think a multi6 solution with id/loc separation will make the local addressing concerns go away. Well a 'solution' might do that, but I don't see one happening in our lifetimes. Any separation will require a mapping infrastructure to dynamically bind the values back together. Such a mapping infrastructure will have all of the scaling concerns of DNS, plus the constraint that its convergence times are extremely short. There is no well-known technology for running a global multi-master, cross trust boundary, database, with appropriate caching for scale, and convergence times that are useful for application failover. If one exists, maybe the end system stacks can be rebuilt to use it within a decade ... Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On onsdag, aug 6, 2003, at 06:40 Europe/Stockholm, Michel Py wrote: That being said, the hard facts are that a) as of today 42% of my IPv6 BGP routing table is made of /48s, /64s and other crud and b) lots of ISP will think twice before refusing my $2.5k/yr to announce my prefix. That is also because the ISPs realize that the current ~400 routes are far from a problem. Actually the 130k routes in IPv4 is not creating a problem either. Other characteristics of BGP might, but I haven't seen a reference to the number of routes creating a problem. Yes, they will cost the ISPs money, but that is why they are accepting your money. Filtering routes have it's advantages, especially in IPv4. With 400 routes, I still fail to see the problem. On the contrary, it tells me we have plenty of time to solve the real problem. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkKsqarNKXTPFCVEQLnngCgumYK3h6qjsqZyF3zPhVrr7EYAwwAnRH9 8u8GKMxnvcBIAxYq8hxIvmOT =/sYB -END PGP SIGNATURE- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
(The reason for the late reply and all the late emails is that my laptop had a disk crash during my vacation, but I had a backup with mails I had replied to but not sent...) Tony, On Thursday, August 7, 2003, at 09:06 PM, Tony Hain wrote: This whole discussion is about multihoming, which points out the failure of the approach to move the multihoming discussion into a separate WG. Multi6 should be closed NOW, and that work should be folded back into the IPv6 WG so there can be a comprehensive approach to the issues (this is independent of the fact that the thread in an Ops WG is really about rearchitecting the Internet). I disagree with this. The multihoming problem is not a ipv6 problem alone. As we stand now, all discussions about multihoming are assumed to be taking place over there, so we don't recognize the address selection discussion as being the same thing. This is not entirely true. I remember the chairs in Vienna actually asking what we should do with this issue and where it belongs. This was also brought up in the multi6 meeting. So the issue is recognized as being similar, if not the same. Best regards, - kurtis - IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
On Thursday, August 7, 2003, at 11:37 PM, Michel Py wrote: which points out the failure of the approach to move the multihoming discussion into a separate WG. Multi6 should be closed NOW. As a matter of fact, by reading its charter it should have been rechartered or shutdown in September 2001, almost two years ago. But I hear that being two years behind objectives without any result is not a big deal in the IETF. Why do this when there finally is momentum? What makes the solutions better if we just move them to another WG? The charter and milestones are issues that needs to be address though. - kurtis - IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving backward [Re: Fourth alternative [was Re: Moving forward....]]
Alain Durand wrote: Brian E Carpenter wrote: Hinden/Haberman leads to simple, straightforward changes to shipping code and that's all we can afford now. If apps could have dealt with those addresses the same way that they deal with regular global unicast address, this would be true. I'm affraid you're overlooking the impact on address selection here. Yes, certainly the default address selection rules would have to be adapted. I don't see that as very tricky though. The tricky case is when the default rules aren't suitable, but that isn't new. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
Alain Durand wrote: I'm affraid you're overlooking the impact on address selection here. Back to the flat earth concept ... Insisting on a single address per interface is the only way to avoid address selection. Until we have a globally routed PI space we know there will be multiple PA addresses to deal with, and in any case we know there will be routing filters. Therefore there will be address selection with all the potential for delays, so app developers simply have to get over it. Complaining about address selection will not make routing filters go away, because filtering is not something the IETF gets to decide. There is a requirement for local application stability no matter what is happening with the set of ISP interconnects. Unless applications have an affinity for a limited range prefix, they will be susceptible to disruption from external events. These external events would normally have absolutely nothing to do with the operation of the local app, but if the external interconnect is the only source of the address prefix these internal-only apps will fail. This failure mode from prefix instability is absolutely unnecessary and unacceptable. There is also a requirement to provide mechanisms that are simple for the non-technical consumer to understand and deploy. This is the only way to replace existing consumer friendly technologies like NAT. Telling the consumer 'replacing the NAT is easy, all you have to do is configure the filter for the port number ...' will ensure they continue using the automated tool. Building automated tools requires simple deterministic mechanisms that just work out of the box. This includes working in the case where there is no external Internet connection, but may be a connection to another out of the box network. This whole discussion is about multihoming, which points out the failure of the approach to move the multihoming discussion into a separate WG. Multi6 should be closed NOW, and that work should be folded back into the IPv6 WG so there can be a comprehensive approach to the issues (this is independent of the fact that the thread in an Ops WG is really about rearchitecting the Internet). As we stand now, all discussions about multihoming are assumed to be taking place over there, so we don't recognize the address selection discussion as being the same thing. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Tony Hain writes: Michael Thomas wrote: The problem is that this draft proceedes from the premise that the answer is consing up limited range addresses. It is not intended to. It is trying to point out the requirements that network managers have. It uses examples where they have found limited range addresses meet the need to explain it for those who don't believe their requirements are real. Tony, quit patronizing me and everybody else. I've not seen one person here who is insensitive to the actual needs of network managers. What I've seen is differing opinions of how to weigh the conflicts and most especially what the long term implications are of any particular approach. Your trying to frame these conversations as a one-man crusade against the IETF ivory-tower is lame and insulting. Your draft is not helpful because it starts out with a conclusion and works back from there, much like yellowcake and WMD. The bias is in the title of the draft, for gawd sake. What we really need is something that lays out all of the requirements -- and local scope is not a requirement, it's a solution -- and tries to analyze the problem space without bias to a particular solution; laying out the good, bad and the ugly for each possible approach. That's incorrect and not helpful. We need to start by determining what the *requirements* are, That is the point of the draft. It fails. See above. Unfortunately some on this list want to argue that some requirements are not real, rather than accept that different situations create different requirements. Given that not everyone has expierenced every situation, the draft needs to provide enough context around a requirement so that others can see the issue. And now your patronizing the group again. Stop it. and only then outline what the range of solutions are, and what their problems and possible consequences are. Until we can get an consensus on what we need to do, and what the engineering tradeoffs are, we will never come to closure. Yes and no. There is no way to achieve a single optimal solution for the diverse set of requirements, so we know the outcome will be a compromise. Bob's draft (as did the others to randomize SL) meets the requirements in the current draft. You mean the requirements of do no harm wrt NAT and DFZ route pollution? Oh, golly, I guess I didn't find those in the draft. Both of these requirement are downsides of limited scope addresses approach, btw. That in a nutshell is why I have a problem with the religiosity on both sides of this argument. My religion is that the deploying network manger is right, no matter what the IETF decides. If the IETF decides to provide tools to make deployment easy, that will be the path of least resistance. If not, the network manager will demand ad-hoc tools to get the job done. Aside from the preposterous notion that you're the torch bearer of the poor under represented network manager (::snort::), this isn't helpful because what we need here is to balance out the conflicting requirements both in whose work load is affected, as well as the general architecture of the net. The network manager is *one* voice that needs to be considered, not the *only* voice. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Michael Thomas wrote: Brian E Carpenter writes: Eliot, That seems to me to be orthogonal. I agree that it would be good to see renumbering support (maybe it's a v6ops item??). But that doesn't destroy the value of Bob's proposal. I disagree. What we seem to be dancing around with here is an aversion to dealing with the actual requirements of people who deploy networks. Even though Bob's proposal polishes the site local t***, it's still a dangerous stopgap and doesn't address _why_ this requirement for stability in the here and now is so strong, and the fact that we don't have a credible answer. Why is addressed in draft-hain-templin-ipv6-limitedrange-00.txt That document may need more work, but it certainly attempts to answer the question, convincingly to my mind. Brian P.S. I fully concur that the renumbering document is needed too. See author list of RFC 1900. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards Technology, IBM NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
Tony, Tony Hain wrote: Insisting on a single address per interface is the only way to avoid address selection. There are ample comments that a lot of enterprise managers will be favorable to that concept. This whole discussion is about multihoming It has always been the sticking point. which points out the failure of the approach to move the multihoming discussion into a separate WG. Multi6 should be closed NOW. As a matter of fact, by reading its charter it should have been rechartered or shutdown in September 2001, almost two years ago. But I hear that being two years behind objectives without any result is not a big deal in the IETF. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]]
Brian E Carpenter writes: Michael Thomas wrote: Which leads *directly* to NAT's at local boundaries and /48's in the DFZ. As has been said by various people, all this is somewhat orthogonal to whether NAT's appear. If we provide a) unambiguous provider-independent prefixes b) good mechanisms for running with these *in parallel* with routeable provider prefixes c) site multihoming d) renumbering tools we'll have done about all we can do, I believe, to make NAT unnecessary and more painful than the alternative. But as usual, it's not the IETF that decides what gets sold and used. It seems to me that in order to make progress you seem to be saying that I have to make a leap of faith that non-globally routable provider independent addresses will not be abused. That is, that people will not try to make the globally routable by either NAT'ing them, or getting providers to advertise the prefix. I'm sorry, but nothing that goes on today gives me any reason to make such a leap. And Fred's draft really shows how little we know about renumbering in the real world. I think we are way past the point in history where it is fruitful to make the sort of free-space wish-the-world-was-different analysis you are advocating. Hinden/Haberman leads to simple, straightforward changes to shipping code and that's all we can afford now. I'm having a very difficult time reconciling what you're saying here with your Let's abolish post. Why? My point about the existing notion of scope is that it is not useful, so we can drop it. Well, I don't disagree. My larger point is the desire for scoped addresses are a symptom of requirements not being met (duh) but the heart of the problem is that they are ignoring other serious problems and/or requirements in their rush to make a stopgap. Having all of the requirements well know would be extremely helpful so that the deficiencies can be evaluated instead of swept under the rug. No. I'm very frustrated at how slowly all this has developed, but we should certainly get a) through d) above done. What do you propose? The sticking point is and has for a very long time been (a). You see it as resolved, I don't. Why should I believe that this will not result in NAT's, exponential route growth, or most likely both? Also: you I believe questioned the very premise of whether local applications (eg, could use non-globally routable addresses) were even particularly useful in real life. If that's true, then what problem is (a) solving? Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Eliot, Eliot Lear wrote: I guess my concern is that ISPs end up routing the address space in Bob's proposal and that we'll have another PI problem. So while there's nothing wrong with Bob's proposal in theory (indeed I prefer it vastly to the other SL approaches), if customers believe they have stable addresses we could end up right back where we were in the early '90s. I don't see this happening for DSL customers but it could happenfor medium to large size businesses who have the power of the purse. I raised this very issue a long time ago, but that is not the worst problem we have. Finish the reasoning down that same path: - Sites will get unaggregatable portable /48s. - Their wallet will get them routed. - Everyone is happy, no renumbering issues, multihoming is possible. So, everyone will spend 5 bucks registering their /48, some (the ones that currently have an AS or will request one) will actually announce it, and we're all fat and happy. Until the GRT reaches 10k (and probably until it reaches 50k by the time that happens given better hardware) it won't be a concern. What happens next is more interesting. Re-using some wording I have read yesterday, this will become a self-regulating system, meaning that only those who can afford it will be able to announce their /48 after some time. The question is: in 5 or 10 years, what are these people that are running production networks configured with addresses that they own going to do when they can't announce their prefix anymore? Bingo, welcome to NATv6. Replacing site-locals with NATv6. Think about it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
August 05, 2003 12:02 PM Keith Moore wrote: I concur. A real story for renumbering is probably the biggest missing piece of the IPv6 puzzle, and we need to be devoting our energies to solving this important problem rather than to propagating past errors. August 05, 2003 12:29 PM Keith Moore wrote: ... It is not acceptable for the network to break address stability. You know it would help if your arguments were self consistent. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
On Tue, Aug 05, 2003 at 05:29:37PM +0200, Brian E Carpenter wrote: Eliot, That seems to me to be orthogonal. I agree that it would be good to see renumbering support (maybe it's a v6ops item??). But that doesn't destroy the value of Bob's proposal. Best practice and standards consideration to make IPv6 renumbering less painful than IPv4 would seem an ideal v6ops WG item. It doesn't remove the need for PI, but it could help in the meantime. Tim IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Michael Thomas wrote: The problem is that this draft proceedes from the premise that the answer is consing up limited range addresses. It is not intended to. It is trying to point out the requirements that network managers have. It uses examples where they have found limited range addresses meet the need to explain it for those who don't believe their requirements are real. That's incorrect and not helpful. We need to start by determining what the *requirements* are, That is the point of the draft. Unfortunately some on this list want to argue that some requirements are not real, rather than accept that different situations create different requirements. Given that not everyone has expierenced every situation, the draft needs to provide enough context around a requirement so that others can see the issue. and only then outline what the range of solutions are, and what their problems and possible consequences are. Until we can get an consensus on what we need to do, and what the engineering tradeoffs are, we will never come to closure. Yes and no. There is no way to achieve a single optimal solution for the diverse set of requirements, so we know the outcome will be a compromise. Bob's draft (as did the others to randomize SL) meets the requirements in the current draft. That in a nutshell is why I have a problem with the religiosity on both sides of this argument. My religion is that the deploying network manger is right, no matter what the IETF decides. If the IETF decides to provide tools to make deployment easy, that will be the path of least resistance. If not, the network manager will demand ad-hoc tools to get the job done. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
I disagree. What we seem to be dancing around with here is an aversion to dealing with the actual requirements of people who deploy networks. What we seem to be dancing around with here is an aversion to dealing with the actual requirements of people who write applications. It is not acceptable for the network to break address stability. It is not acceptable for the network to expect apps to do routing. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Moving backward [Re: Fourth alternative [was Re: Moving forward ....]]
Brian E Carpenter writes: Michael, Sorry, but I think you are dead wrong, and you are moving us backward and risking another year or two of wasted time. There is nothing new in this whole argument. As I pointed out in the IAB architecture session in Vienna, these issues have been around for 6 years at least. We know what we can do with today's routing mechanisms, today's renumbering mechanisms, and today's security mechanisms, and that leads *directly* to the requirements in the Hain/Templin draft, and IMHO *directly* to the solution in the Hinden/Haberman draft. Which leads *directly* to NAT's at local boundaries and /48's in the DFZ. And Fred's draft really shows how little we know about renumbering in the real world. I think we are way past the point in history where it is fruitful to make the sort of free-space wish-the-world-was-different analysis you are advocating. Hinden/Haberman leads to simple, straightforward changes to shipping code and that's all we can afford now. I'm having a very difficult time reconciling what you're saying here with your Let's abolish post. It's almost like you're saying we should do nothing at all. While nothing is often better than a bad something, in this case there's shipping product to fill the vacuum: NAT's. And they are well understood given their v4 deployment. Is that what you're ceding? Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Moving backward [Re: Fourth alternative [was Re: Moving forward ....]]
Michael, Sorry, but I think you are dead wrong, and you are moving us backward and risking another year or two of wasted time. There is nothing new in this whole argument. As I pointed out in the IAB architecture session in Vienna, these issues have been around for 6 years at least. We know what we can do with today's routing mechanisms, today's renumbering mechanisms, and today's security mechanisms, and that leads *directly* to the requirements in the Hain/Templin draft, and IMHO *directly* to the solution in the Hinden/Haberman draft. I think we are way past the point in history where it is fruitful to make the sort of free-space wish-the-world-was-different analysis you are advocating. Hinden/Haberman leads to simple, straightforward changes to shipping code and that's all we can afford now. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards Technology, IBM NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK Michael Thomas wrote: [EMAIL PROTECTED] writes: If you think the document has a scoping issue (no pun intended), then let's discuss that with a measured tone. Yes, I think it has scoping issues. A name change, for starters. It should first lay out requirements of network operators, etc in terms of what they need to accomplish not how they can accomplish it. Take as a very large for example, address stability. That's not the requirement, per se. What they want is for topology tweaking to not adversely affect running applications. However protocols such as TCP are incapable of sustaining sessions across address changes which is typically needed when you want to move topology around. That's the reason I say that stability is a solution, not a requirement. Keeping addresses the same is *a* way of keeping applications from breaking, but not the only one. Mobile IP obviously comes to mind, and there are other ways we could envision like Fred's attempt at operational renumbering. Another example is your well known prefix. I'd think that the requirement is that certain services and/or classes of devices need to be isolated and/or invisible from the other parts of the net. A well known prefix is a way to do that, but it doesn't necessitate local scope and again isn't the only way to wall stuff off. I really don't want to drag this into a meta argument about the merits of various solutions, but only to point out that the entire document is structured in a way that the answer is foregone. That's not what we need right now. We need something that tries to be unbiased about the ultimate compromises we're going to have to make by saying what we want (requirements), what the possible frameworks are for addressing the requirements, and most especially what their possible downsides are. We don't need boosterism which tries to paper over the warts; all possible solutions have problems, what we need is an honest evaluation so that we can decide which path is the least objectionable. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving backward [Re: Fourth alternative [was Re: Moving forward....]]
Leif, I wish I could give you such a reference. In my mind it is a logical path that started with RFC 1900 and RFC 2101, parts of RFC 2775 and RFC 2956, parts of draft-irtf-nsrg-report-09.txt, and multiple discussions on multi6, ipng and other lists over the years, and of course what we have been told about operational practice. Yes, it would be good to write it up. Brian Leif Johansson wrote: Brian E Carpenter wrote: snip around for 6 years at least. We know what we can do with today's routing mechanisms, today's renumbering mechanisms, and today's security mechanisms, and that leads *directly* to the requirements in the Hain/Templin draft, and IMHO *directly* to the solution in the Hinden/Haberman draft. Could you give a reference to some text which describes this reasoning in more detail? I confess that I don't see the connections as clearly as you do. To me Michael has presented some pretty good points and even if you are right about the logical inevitability of the Hain/Templin draft it could imo benefit from a bit more stringency. Cheers Leif -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards Technology, IBM NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Thirded, and agreed. IPv6 or V6Ops though? On Tue, Aug 05, 2003 at 11:07:53AM -0700, Michael Thomas wrote: Eliot Lear writes: I'd like to put Fred on the spot (not having asked him) and propose that his draft be adopted as a WG doc. I'd like to second that. Fred's document if nothing else shows how close we aren't to meeting the operational goal of renumbering without significant blood-letting. Also: Fred's document is aimed at a solution for somebody with enough leverage to join the providers BGP cabal. While that's a start, it doesn't explore this problem nearly enough, IMO, especially for BGP have-nots. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
Alain Durand wrote: So what we have here is a case where you are multihomed with one side that is permanently unreachable from a large portion of the universe. This is a feature, not a bug. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Fred Templin writes: Mike, Let me see if I can understand your concerns better. It seems to me that your main objection to the hain/templin draft is that you see it as implying a particular solution genre, that being a limited range addressing scheme to replace site-locals. If this is what you find objectionable, then may I assume you are of the opinion that site locals don't *need* to be replaced? If so, then it seems you would favor an IPv6 addressing architecture that contains only link-local and global unicast addresses, i.e., nothing in between? My inclination is that limited scope (excluding link local) is extremely problematic, but that's not really my larger point. The larger point is that there are a set of requirements that are driving people to use NAT's in ipv4 today, some of which are well addressed by ipv6, some of which are not as well addressed. And suspect that we all know that ipv6 will get NAT's if those bread and butter requirements cannot be met easily... NAT is the devil they know right now, for better or worse. However, limited scope addresses are but *one* way to deal with this set of requirements. What I think has been getting short-shrift here is that it seems to be a foregone conclusion amongst many people -- especially those who were not in favor of deprecation -- that the set of engineering tradeoffs amongst the options is well known and that local scoped addresses are the lesser of evils. I find that far from clear, and to my knowledge this working group has never formally evaluated those options or even enumerated them for that matter. I think it would be wise to take on that work, so that we can make an informed documented decision, and hopefully come to consensus with our eyes wide open. The hain/templin draft discusses requirements for sites that frequently change provider points of attachment, sites that are disconnected or intermittently-connected to providers, sites that merge with other sites, etc. I think your draft would make a fine starting point for the work I think needs done if it were morphed into something that didn't proceed from a solution and work backward as it seems to do now. In these cases, we require local application stability independent of any provider-assigned addressing. This requirement is not satisfied by link-locals for medium/large sites that comprise multiple links. Thus, all we have left are globals and the only way the active sites I described above could use these would be if the global prefixes could be obtained independent of any provider. Fine; so this just means that the sites would get their own prefixes and tell providers which prefixes to advertise instead of the other way around - right? This would all be fine were it not for the fact that it would lead to immediate global routing table explosion on the order of the number of sites that procure their own prefixes which could be quite large. I'm willing to suspend disbelief and say that sometime down the road we might have a solution for scalable global routing, but in what timeframe can we expect to see something like that deployed? 1yr? 5yrs? 10yrs? longer? Scalable global routing in a flat addressing space certainly seems like a utopian scenario if it can be achieved. But, if the deployment timeframe is looking like mid/long term, then we still need some sort of replacement for site-locals in the near term - right? It's all of these questions and tradeoffs etc, which I think need to be *documented* and that we need to get rough consensus about the *problem* space itself. I don't believe after googlebytes of email on site locals we even have consensus on what problems must be solved in order to have a deployable IPv6 without NAT's being a necessary evil. Also: I think we are far away from actually determining that the principle alternatives (renumbering, PI) are dead letters, or that there aren't other more creative ways of solving for the problems/requirements. Brian thinks this is a waste of time, I respectfully disagree. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving backward [Re: Fourth alternative [was Re: Moving forward....]]
Brian E Carpenter wrote: Hinden/Haberman leads to simple, straightforward changes to shipping code and that's all we can afford now. If apps could have dealt with those addresses the same way that they deal with regular global unicast address, this would be true. I'm affraid you're overlooking the impact on address selection here. - Alain. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Tim, Michel Py wrote: - If globally unique IPv6 address space is free, I am willing to give these $2.5k/yr to my ISP to announce my /48. Tim Chown wrote: Well, the ISP announces it, but how far does it get? It gets to you, where you filter it but it does get to you. You filter it and here's why: as a NREN, your customers don't come to you and say you have 2 solutions: 1. you keep my business and here's extra cash to forget to filter prefixes; 2. someone else will be happy to have both my business and the extra cash. So you do have the luxury to do things the right way, which we thank you for. However, for for-profit ISPs that do not have the taxpayer's money to create a network, the choice is not as easy and will be choosing between a) do things right and don't capture the emerging IPv6 market and b) look the other way and get extra cash much needed to finance building the IPv6 infrastructure. There is a critical mass factor in this. Sure, if it's only one guy trying to get his prefix announced, it goes nowhere. Trouble is that announcing prefixes, although it does create problems in the long run, solves so many issues in the short term that every enterprise is going to do it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Mike, Let me see if I can understand your concerns better. It seems to me that your main objection to the hain/templin draft is that you see it as implying a particular solution genre, that being a limited range addressing scheme to replace site-locals. If this is what you find objectionable, then may I assume you are of the opinion that site locals don't *need* to be replaced? If so, then it seems you would favor an IPv6 addressing architecture that contains only link-local and global unicast addresses, i.e., nothing in between? The hain/templin draft discusses requirements for sites that frequently change provider points of attachment, sites that are disconnected or intermittently-connected to providers, sites that merge with other sites, etc. In these cases, we require local application stability independent of any provider-assigned addressing. This requirement is not satisfied by link-locals for medium/large sites that comprise multiple links. Thus, all we have left are globals and the only way the active sites I described above could use these would be if the global prefixes could be obtained independent of any provider. Fine; so this just means that the sites would get their own prefixes and tell providers which prefixes to advertise instead of the other way around - right? This would all be fine were it not for the fact that it would lead to immediate global routing table explosion on the order of the number of sites that procure their own prefixes which could be quite large. I'm willing to suspend disbelief and say that sometime down the road we might have a solution for scalable global routing, but in what timeframe can we expect to see something like that deployed? 1yr? 5yrs? 10yrs? longer? Scalable global routing in a flat addressing space certainly seems like a utopian scenario if it can be achieved. But, if the deployment timeframe is looking like mid/long term, then we still need some sort of replacement for site-locals in the near term - right? Thanks - Fred [EMAIL PROTECTED] Michael Thomas wrote: [EMAIL PROTECTED] writes: If you think the document has a scoping issue (no pun intended), then let's discuss that with a measured tone. Yes, I think it has scoping issues. A name change, for starters. It should first lay out requirements of network operators, etc in terms of what they need to accomplish not how they can accomplish it. Take as a very large for example, address stability. That's not the requirement, per se. What they want is for topology tweaking to not adversely affect running applications. However protocols such as TCP are incapable of sustaining sessions across address changes which is typically needed when you want to move topology around. That's the reason I say that stability is a solution, not a requirement. Keeping addresses the same is *a* way of keeping applications from breaking, but not the only one. Mobile IP obviously comes to mind, and there are other ways we could envision like Fred's attempt at operational renumbering. Another example is your well known prefix. I'd think that the requirement is that certain services and/or classes of devices need to be isolated and/or invisible from the other parts of the net. A well known prefix is a way to do that, but it doesn't necessitate local scope and again isn't the only way to wall stuff off. I really don't want to drag this into a meta argument about the merits of various solutions, but only to point out that the entire document is structured in a way that the answer is foregone. That's not what we need right now. We need something that tries to be unbiased about the ultimate compromises we're going to have to make by saying what we want (requirements), what the possible frameworks are for addressing the requirements, and most especially what their possible downsides are. We don't need boosterism which tries to paper over the warts; all possible solutions have problems, what we need is an honest evaluation so that we can decide which path is the least objectionable. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
Alain Durand wrote: So what we have here is a case where you are multihomed with one side that is permanently unreachable from a large portion of the universe. The only difference between this and the case for 90% of the deployed end systems today is the multihoming. Using PA addresses with filtering doesn't change anything about the permanently unreachable state, it just makes it impossible for anything to figure out which prefix is more likely to be filtered. Applications don't have to try to figure it out, because not doing so has exactly the same effect as filtered PA's. Those that choose to take the hint can establish an affinity for the one more likely to that app. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
On Tue, Aug 05, 2003 at 09:40:52PM -0700, Michel Py wrote: - If globally unique IPv6 address space is free, I am willing to give these $2.5k/yr to my ISP to announce my /48. Well, the ISP announces it, but how far does it get? On the operator side, I do acknowledge that we have some of them around that do what they are supposed to and filter, thanks to people that promote routing table health such as Jeroen and Gert. That being said, the hard facts are that a) as of today 42% of my IPv6 BGP routing table is made of /48s, /64s and other crud and b) lots of ISP will think twice before refusing my $2.5k/yr to announce my prefix. That 42% is skewed due to IPv6 not being considered a production service (and the traffic volume is low) by many people carrying/transiting the traffic. Tim IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Brian E Carpenter writes: Eliot, That seems to me to be orthogonal. I agree that it would be good to see renumbering support (maybe it's a v6ops item??). But that doesn't destroy the value of Bob's proposal. I disagree. What we seem to be dancing around with here is an aversion to dealing with the actual requirements of people who deploy networks. Even though Bob's proposal polishes the site local turd, it's still a dangerous stopgap and doesn't address _why_ this requirement for stability in the here and now is so strong, and the fact that we don't have a credible answer. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Eliot Lear wrote: I guess my concern is that ISPs end up routing the address space in Bob's proposal and that we'll have another PI problem. So while there's nothing wrong with Bob's proposal in theory (indeed I prefer it vastly to the other SL approaches), if customers believe they have stable addresses we could end up right back where we were in the early '90s. I don't see this happening for DSL customers but it could happenfor medium to large size businesses who have the power of the purse. It is possible to write sufficient restrictions and avoid both the drift towards announcing /48 in the DMZ and using the unique local addresses in a NATv6 configuration. The requirement is that the site local replacement be special. We can for example request that backbone routers ignore announces that fall in the special prefix unless a /48 has been explicitly. As a result, even if someone convinces their local ISP, they will not be able to get connectivity to the whole Internet, and the addresses will not be usable as globally routed PI. In fact, we should do that. -- Christian Huitema IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]]
Michael Thomas wrote: Brian E Carpenter writes: Michael, Sorry, but I think you are dead wrong, and you are moving us backward and risking another year or two of wasted time. There is nothing new in this whole argument. As I pointed out in the IAB architecture session in Vienna, these issues have been around for 6 years at least. We know what we can do with today's routing mechanisms, today's renumbering mechanisms, and today's security mechanisms, and that leads *directly* to the requirements in the Hain/Templin draft, and IMHO *directly* to the solution in the Hinden/Haberman draft. Which leads *directly* to NAT's at local boundaries and /48's in the DFZ. As has been said by various people, all this is somewhat orthogonal to whether NAT's appear. If we provide a) unambiguous provider-independent prefixes b) good mechanisms for running with these *in parallel* with routeable provider prefixes c) site multihoming d) renumbering tools we'll have done about all we can do, I believe, to make NAT unnecessary and more painful than the alternative. But as usual, it's not the IETF that decides what gets sold and used. And Fred's draft really shows how little we know about renumbering in the real world. I think we are way past the point in history where it is fruitful to make the sort of free-space wish-the-world-was-different analysis you are advocating. Hinden/Haberman leads to simple, straightforward changes to shipping code and that's all we can afford now. I'm having a very difficult time reconciling what you're saying here with your Let's abolish post. Why? My point about the existing notion of scope is that it is not useful, so we can drop it. It's almost like you're saying we should do nothing at all. While nothing is often better than a bad something, in this case there's shipping product to fill the vacuum: NAT's. And they are well understood given their v4 deployment. Is that what you're ceding? No. I'm very frustrated at how slowly all this has developed, but we should certainly get a) through d) above done. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards Technology, IBM NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
[EMAIL PROTECTED] writes: If you think the document has a scoping issue (no pun intended), then let's discuss that with a measured tone. Yes, I think it has scoping issues. A name change, for starters. It should first lay out requirements of network operators, etc in terms of what they need to accomplish not how they can accomplish it. Take as a very large for example, address stability. That's not the requirement, per se. What they want is for topology tweaking to not adversely affect running applications. However protocols such as TCP are incapable of sustaining sessions across address changes which is typically needed when you want to move topology around. That's the reason I say that stability is a solution, not a requirement. Keeping addresses the same is *a* way of keeping applications from breaking, but not the only one. Mobile IP obviously comes to mind, and there are other ways we could envision like Fred's attempt at operational renumbering. Another example is your well known prefix. I'd think that the requirement is that certain services and/or classes of devices need to be isolated and/or invisible from the other parts of the net. A well known prefix is a way to do that, but it doesn't necessitate local scope and again isn't the only way to wall stuff off. I really don't want to drag this into a meta argument about the merits of various solutions, but only to point out that the entire document is structured in a way that the answer is foregone. That's not what we need right now. We need something that tries to be unbiased about the ultimate compromises we're going to have to make by saying what we want (requirements), what the possible frameworks are for addressing the requirements, and most especially what their possible downsides are. We don't need boosterism which tries to paper over the warts; all possible solutions have problems, what we need is an honest evaluation so that we can decide which path is the least objectionable. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
August 05, 2003 12:02 PM Keith Moore wrote: I concur. A real story for renumbering is probably the biggest missing piece of the IPv6 puzzle, and we need to be devoting our energies to solving this important problem rather than to propagating past errors. August 05, 2003 12:29 PM Keith Moore wrote: It is not acceptable for the network to break address stability. You know it would help if your arguments were self consistent. there's nothing inconsistent between those two statements. yes, we need to be able to renumber, but not without adequate notice and overlap, and not in a way that invalidates the identifiers that apps use to refer to their peers. (and no, DNS names are not sufficient) IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving backward [Re: Fourth alternative [was Re: Moving forward....]]
Brian E Carpenter wrote: snip around for 6 years at least. We know what we can do with today's routing mechanisms, today's renumbering mechanisms, and today's security mechanisms, and that leads *directly* to the requirements in the Hain/Templin draft, and IMHO *directly* to the solution in the Hinden/Haberman draft. Could you give a reference to some text which describes this reasoning in more detail? I confess that I don't see the connections as clearly as you do. To me Michael has presented some pretty good points and even if you are right about the logical inevitability of the Hain/Templin draft it could imo benefit from a bit more stringency. Cheers Leif IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
On Wed, 6 Aug 2003, Michael Thomas wrote: [...] I really don't want to drag this into a meta argument about the merits of various solutions, but only to point out that the entire document is structured in a way that the answer is foregone. [...] Exactly. Some others have also voiced concerns on this. For example, Rob Austein made a similar comment at the Vienna meeting (I was already walking to the queue but he got there first :-). At least I interpreted it like that. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Eliot / Bob, Bob Hinden wrote: Is this sufficient? Would it better to also include an operational considerations or similar section? More text on why this is important? Eliot Lear wrote: Venders speak the language of money, So do operators and so do enterprises. Allow me to share the way it works for enterprises: - I am already paying $2.5k/yr to ARIN for portable IPv4 address space. - Although I could do without, I am ready to pay another $2.5k/yr for portable IPv6 address space (when IPv6 takes off, that is). - If globally unique IPv6 address space is free, I am willing to give these $2.5k/yr to my ISP to announce my /48. - On top of that, if doing so also solves the IPv6 multihoming issue, where do I sign? On the operator side, I do acknowledge that we have some of them around that do what they are supposed to and filter, thanks to people that promote routing table health such as Jeroen and Gert. That being said, the hard facts are that a) as of today 42% of my IPv6 BGP routing table is made of /48s, /64s and other crud and b) lots of ISP will think twice before refusing my $2.5k/yr to announce my prefix. and that overrides whatever language is in the draft :-( Which is doubly lame, because 1) I should not offer the money and 2) they should not accept it; bottom line though is that both them and I run a business, not a charity. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Eliot, That seems to me to be orthogonal. I agree that it would be good to see renumbering support (maybe it's a v6ops item??). But that doesn't destroy the value of Bob's proposal. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards Technology, IBM NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK Eliot Lear wrote: Bob, I am sorry, but while it is a good attempt to come up with a happy medium between SLs and global addresses, I disagree with the approach that draft-hinden-ipv6-global-local-addr-02.txt takes. I would prefer an approach that makes the stability of the IP address less important rather than attempting to stablize it (a seemingly lost cause). What this means to me is that first we need to promulgate something along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It needs some expanding to further automate the process. The more we automate the less pain the network manager will feel during a renumbering event. This changes the problem from one of a scoped address to one of a standard default and reduces any ambiguity that we might have. It leaves open the question of how to find a name server, and how a name server finds you, but the former can be found with SLP, and the latter can then be handled with DDNS. I'd like to put Fred on the spot (not having asked him) and propose that his draft be adopted as a WG doc. Eliot IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Bob Hinden wrote: Is this sufficient? Would it better to also include an operational considerations or similar section? More text on why this is important? Bob, Putting aside Michel's comments just for the moment, this would seemingly be necessary, but I don't know if there is anything you can write to make it sufficient. That will be a test of time. As I said earlier, I think the draft is a substantial advance over previous attempts. I do think Michel's comments need to be addressed. The issue is really an expectations game. Venders speak the language of money, and that overrides whatever language is in the draft :-( Eliot IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Bob, I am sorry, but while it is a good attempt to come up with a happy medium between SLs and global addresses, I disagree with the approach that draft-hinden-ipv6-global-local-addr-02.txt takes. I would prefer an approach that makes the stability of the IP address less important rather than attempting to stablize it (a seemingly lost cause). What this means to me is that first we need to promulgate something along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It needs some expanding to further automate the process. The more we automate the less pain the network manager will feel during a renumbering event. This changes the problem from one of a scoped address to one of a standard default and reduces any ambiguity that we might have. It leaves open the question of how to find a name server, and how a name server finds you, but the former can be found with SLP, and the latter can then be handled with DDNS. I'd like to put Fred on the spot (not having asked him) and propose that his draft be adopted as a WG doc. Eliot IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
What this means to me is that first we need to promulgate something along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It needs some expanding to further automate the process. The more we automate the less pain the network manager will feel during a renumbering event. I concur. A real story for renumbering is probably the biggest missing piece of the IPv6 puzzle, and we need to be devoting our energies to solving this important problem rather than to propagating past errors. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Interesting point. Feel free to look up 192.102.91.0. It is being NAT'ed for a client of mine. I've not convinced them yet to route it with a real firewall to their isp ;-( -- Todd Fries .. [EMAIL PROTECTED] Free Daemon Consulting, LLCLand: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 ..in support of free software solutions. Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) Penned by Michel Py on Tue, Aug 05, 2003 at 11:26:32AM -0700, we have: | Eliot, | | Eliot Lear wrote: | I guess my concern is that ISPs end up routing the address | space in Bob's proposal and that we'll have another PI problem. | So while there's nothing wrong with Bob's proposal in theory | (indeed I prefer it vastly to the other SL approaches), if | customers believe they have stable addresses we could end up | right back where we were in the early '90s. I don't see this | happening for DSL customers but it could happenfor medium to | large size businesses who have the power of the purse. | | I raised this very issue a long time ago, but that is not the worst | problem we have. Finish the reasoning down that same path: | | - Sites will get unaggregatable portable /48s. | - Their wallet will get them routed. | - Everyone is happy, no renumbering issues, multihoming is possible. | | So, everyone will spend 5 bucks registering their /48, some (the ones | that currently have an AS or will request one) will actually announce | it, and we're all fat and happy. Until the GRT reaches 10k (and probably | until it reaches 50k by the time that happens given better hardware) it | won't be a concern. | | What happens next is more interesting. Re-using some wording I have read | yesterday, this will become a self-regulating system, meaning that only | those who can afford it will be able to announce their /48 after some | time. | | The question is: in 5 or 10 years, what are these people that are | running production networks configured with addresses that they own | going to do when they can't announce their prefix anymore? Bingo, | welcome to NATv6. | | Replacing site-locals with NATv6. Think about it. | | Michel. | | | | IETF IPng Working Group Mailing List | IPng Home Page: http://playground.sun.com/ipng | FTP archive: ftp://playground.sun.com/pub/ipng | Direct all administrative requests to [EMAIL PROTECTED] | IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Christian, It is possible to write sufficient restrictions and avoid both the drift towards announcing /48 in the DMZ and using the unique local addresses in a NATv6 configuration. The requirement is that the site local replacement be special. We can for example request that backbone routers ignore announces that fall in the special prefix unless a /48 has been explicitly. As a result, even if someone convinces their local ISP, they will not be able to get connectivity to the whole Internet, and the addresses will not be usable as globally routed PI. In fact, we should do that. I agree, and it is already in the draft. The current draft includes text on this in two places. In section 4.0 Routing: Any routing protocol that is used between sites is required to filter out any incoming or outgoing Local IPv6 unicast routes. The exception to this is if specific /48 IPv6 local unicast routes have been configured to allow for inter-site communication. If BGP is being used at the site border with an ISP, by default filters MUST be installed in the BGP configuration to keep any Local IPv6 address prefixes from being advertised outside of the site or for these prefixes to be learned from another site. The exception to this is if there are specific /48 routes created for one or more Local IPv6 prefixes. and in section 6.0 Site Border Router and Firewall Filtering: While no serious harm will be done if packets with these addresses are sent outside of a site via a default route, it is recommended that they be filtered to keep any packets with Local IPv6 destination addresses from leaking outside of the site and to keep any site prefixes from being advertised outside of their site. Site border routers SHOULD install a black hole route for the Local IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 destination addresses will not be forwarded outside of the site via a default route. Site border routers and firewalls SHOULD NOT forward any packets with Local IPv6 source or destination addresses outside of the site unless they have been explicitly configured with routing information about other Local IPv6 prefixes. The default behavior of these devices SHOULD be to filter them. Is this sufficient? Would it better to also include an operational considerations or similar section? More text on why this is important? Bob IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
