Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Tony Hain wrote: If a bof were proposed on the topic, would it be turned down as out of scope and in conflict with the currently stated solution in shim6? I'm not sure what exact BOF proposal you had in mind, but the existence of Shim6 WG should not prevent further discussion. I at least do not take it for granted that Shim6 solves ALL our needs in this space. For instance, it could be that we need more than one solution for the continuum that starts from large organizations and continues through medium and small size organizations to homes and hosts. Shim6 looks like a very promising solution for some parts of this continuum, but it is up for discussion whether something else is needed too. (Assuming we have a credible proposal for that something else, of course -- some of these problems are very hard.) --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Tony Hain wrote: Brian E Carpenter wrote: ... Scott Leibrand wrote: .. I agree, especially in the near term. Aggregation is not required right now, but having the *ability* to aggregate later on is a prudent risk reduction strategy if today's cost to do so is minimal (as I think it is). I think that's an understatement until we find an alternative to BGP aggregation. That's why my challenge to Iljistsch was to simulate 10B nodes and 100M sites - if we can't converge a reasonable sized table for that network, we *know* we have a big problem in our future. Not a risk - a certainty. The problem with your challenge is the lack of a defined topology. The reality is that there is no consistency for topology considerations, so the ability to construct a routing model is limited at best. Actually my challenge asked for an assumed geographical distribution and an assumed set of ISPs and interconnects, I believe. Obviously one needs to know how robust the result is under reasonable variations of the assumed topology. The other point is that the protocol is irrelevant. Whatever we do the architectural problem is finding an aggregation strategy that fits a routing system in hardware that we know how to build, at a price point that is economically deployable. Yes, but BGP4 is a surrogate for that. As far as I am concerned BGP is not the limitation. The problem is the ego driven myth of a single dfz where all of the gory details have to be exposed globally. If we abolish that myth and look at the problem we are left with an answer where BGP passing regional aggregates is sufficient. I'm sorry, I don't think I've ever seen a convincing argument how such aggregates could come to pass in the real world where inter-regional bandwidth is partitioned at link level or dark fibre level. There just isn'tany forcing function by which mathematically close prefixes will become topologically close, because there's nothing that forces multiple providers to share long-distance routes. Yes there will be exception routes that individual ISPs carry, but that is their choice not a protocol requirement. Complaining that regional aggregates are sub-optimal is crying wolf when they know they will eventually loose to the money holding customer demanding non-PA space. The outcries about doom and gloom with PI are really about random assignments which would be even less optimal. The fundamental question needs to be if there is an approach to address allocation that can be made to scale under -any- known business model, not just the one in current practice. It is not the IETFs job to define business models, rather to define the technology approaches that might be used and see if the market picks up on them. Unfortunately over the last few years the process has evolved to excluding discussions that don't fit in the current business models, despite the continuing arguments about how those models are financial failures and need to change. The point that Scott was making is that there are proposals for non-random assignments which could be carried as explicit's now and aggregated later. I understand his point very well and I'm even in favour of it, because statistically it can only help aggregation and certainly not damage it. But I think that without some radically new principle it will at best very slightly reduce randomness. Brian What we lack is a forum to evaluate the trade-off's. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 21-apr-2006, at 15:47, Brian E Carpenter wrote: If we abolish that myth and look at the problem we are left with an answer where BGP passing regional aggregates is sufficient. I'm sorry, I don't think I've ever seen a convincing argument how such aggregates could come to pass in the real world where inter-regional bandwidth is partitioned at link level or dark fibre level. There just isn'tany forcing function by which mathematically close prefixes will become topologically close, because there's nothing that forces multiple providers to share long-distance routes. Obviously it would be tremendously helpful if ISP A would handle region X, ISP B region Y and ISP C region Z, so it's just a matter of dumping the traffic for a certain region with the ISP in question but for various reasons this will never work, if only because the whole point is that multihomers have more than one ISP and each of their connections to their ISPs may be down at any point in time. Let me try out a new analogy. There are many languages in the world, and most international businesses have to be able to work in more than one language. Now wouldn't it suck if in a business that has customers in 25 countries with 20 languages, EVERY office would have to have people that speak EVERY language? Fortunately, although there is no fixed relationship between language and geography, in practice there is enough correlation so that you can have the office in Sweden handle all Swedish speaking customers and the offices in Portugal and Brazil the Portugese speaking customers. Back to networking: send the packets to the place where all the more specifics are known. If the place where all the more specifics are known is close to the places where those more specifics are used, that works out quite well. If the more specifics are used randomly all over the place then this technique adds detours, which is suboptimal. The point that Scott was making is that there are proposals for non-random assignments which could be carried as explicit's now and aggregated later. I understand his point very well and I'm even in favour of it, because statistically it can only help aggregation and certainly not damage it. But I think that without some radically new principle it will at best very slightly reduce randomness. I guess I'll work on my simulations... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Brian E Carpenter wrote: ... The problem with your challenge is the lack of a defined topology. The reality is that there is no consistency for topology considerations, so the ability to construct a routing model is limited at best. Actually my challenge asked for an assumed geographical distribution and an assumed set of ISPs and interconnects, I believe. Obviously one needs to know how robust the result is under reasonable variations of the assumed topology. I may have missed part of the thread, but the message I was reacting to just said: You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. I'm serious. Let me throw out an example: With existing IGPs the number of nodes has no impact on the routing system, but I would interpret the 10B requirement to mean at least 10k subnets, and more likely 50k subnets per site. This would imply we are working with a site prefix of /48. Given that today we think we can build routers capable of 1M entries, it is not much of a stretch to get to 5M by the time there would be wide-scale deployment of PI. Take this completely arbitrary list as an example of regional exchange centers: 5 Million Moscow 5 Million Istanbul 5 Million London 5 Million Paris 5 Million Newark 5 Million Atlanta 5 Million Seattle 5 Million San Jose 5 Million Mexico City 5 Million Bogota 5 Million Sao Paulo 5 Million Tokyo 5 Million Beijing 5 Million Shanghai 5 Million Hong Kong 5 Million Singapore 5 Million Sydney 5 Million Bangkok 5 Million Bangalore 2.5 Million Cape Town 2.5 Million Dakar I am too detached from current cable-heads to know the right list, but the example list could aggregate your 100M requirement. If you want to fit in current technology find an appropriate list of 100 cities at 1M each. In the example case assume 10 inter-regional transit providers, each with 3 diverse paths to each of the cities in a full mesh; their routers would be parsing through local needs plus ~70 entries. In the 100 city case it would be local plus ~310. Either way the 'system' would handle 100M sites in chunks that are manageable by individual routers. Realistically there would probably be another 20-50k entries for organizations with enough money to influence some of the providers and gain a widely-distributed routing slot, but if individual providers want to distribute more detailed knowledge to optimize their traffic/circuit mappings, it is their trade-off to make. The rest of the world doesn't need to know the mess they have made for themselves. The point is that BGP does not require any router to have full information. That requirement comes from ego's about who is paying for transit. Making this example work requires redefining the operational roles of exchange points and transit providers, as well as a workable settlements standard. The issue on the table is that we have RIRs trying to create policy to restrict access to PI space to only the 20-50k deep-pockets with no solid metric to set a bar; when the reality is that everyone except the carrier looking for a lock benefits from PI. The challenge is aggregating out those who only need local independence to foster serious competition. ... As far as I am concerned BGP is not the limitation. The problem is the ego driven myth of a single dfz where all of the gory details have to be exposed globally. If we abolish that myth and look at the problem we are left with an answer where BGP passing regional aggregates is sufficient. I'm sorry, I don't think I've ever seen a convincing argument how such aggregates could come to pass in the real world where inter-regional bandwidth is partitioned at link level or dark fibre level. There just isn'tany forcing function by which mathematically close prefixes will become topologically close, because there's nothing that forces multiple providers to share long-distance routes. There are only 2 forcing functions for any carrier action; regulation pain/cost mitigation (well 3 if you count greed as distinct from and the income side of cost). Why don't carriers carry full real-time explicit routes for all existing hosts or even subnets today (there are periodic attempts to push a global spanning-tree)? They have chosen an existing pain/cost mitigation technical approach known as BGP, which aggregates out irrelevant details for those outside the local delivery network. Why are we having this discussion? Because carriers have been allowed to run amuck and deploy random topology, trading low fiber cost against any concern about the impact to their routing system (note the worst offenders for routing table bloat are pushing deaggregates to optimize traffic to their random topology). Regulators -could- put a stop to that, but I would encourage the carriers to take voluntary action to mitigate the pain. Unfortunately that path requires
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
I'm patient, but when you have a heavily loaded VAX-11/780 (I think this was before the host apple.com was upgraded to a VAX-8650) doing netnews, where even the highly optimized compress program beats on the CPU, and a Cray X/MP-48 just sitting there across the LAN ... So, I set up a TCP compression service set up on the Cray (bits go in, compressed bits come out; inetd makes this easy and UniCOS came with the compress) and blasted netnews batches across the 10Mb/s Ethernet from the VAX and captured the results for transmission to Apple's UUCP-based netnews neighbors. It was lots faster that way and it took a large load off the VAX. Unfortunately, I had to discontinue the practice when some of my netnews neighbors complained of corrupted batches; it seems that there were some subtle 32 bit assumptions in compress that I didn't have the time to track down. Still, it was fun to play with a supercomputer at a place where they believed in interactive computing, and didn't charge for CPU time. Then there was the time I ported pathalias to the Cray ... Erik [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Hi, Things work a lot better if IETF and RIRs work hand-in-hand - that is, IETF makes standards that people can work with, and RIRs use allocation policies that somewhat reflect what the protocol designers had in mind. This is a proper model which should remain this way with a little fix. IETF engineering effort is funded (indirectly) by the employers of the engineers. RIRs administrative work is funded through membership and allocation fees, which essentially equals selling of IP addresses. Because the Internet is a shared resourse its enablers such as IP addresses are not for sale but rather for a free assignment to everyone. RIRs function should be funded through a politically / economically neutral body, e.g. UN. Technically the current way of RIR cost recovery hinders the network neutrality. Peter --- Gert Doering [EMAIL PROTECTED] wrote: Hi, On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote: The IETF has NOTHING to say anymore than any other body about any RIR policy. I want it to remain that way. IETF job is a standards body not a deployment body. Things work a lot better if IETF and RIRs work hand-in-hand - that is, IETF makes standards that people can work with, and RIRs use allocation policies that somewhat reflect what the protocol designers had in mind. For IPv6, this isn't a huge success story yet... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AGMail: [EMAIL PROTECTED] Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Peter Sherbin wrote: This is a proper model which should remain this way with a little fix. IETF engineering effort is funded (indirectly) by the employers of the engineers. RIRs administrative work is funded through membership and allocation fees, which essentially equals selling of IP addresses. Because the Internet is a shared resourse its enablers such as IP addresses are not for sale but rather for a free assignment to everyone. RIRs function should be funded through a politically / economically neutral body, e.g. UN. Technically the current way of RIR cost recovery hinders the network neutrality. I wouldn't consider any policital body, especially the UN to be politically (and thus economically) neutral. I also don't see how RIR fees affect policy in any way. At least in ARIN, anyone is allowed to participate in the policy process regardless of resources delegated or fees paid. - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Kevin Loch wrote: ... In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. Kevin, I realise you may have felt provoked by the tone of some earlier messages, but I must point out that (a) the shim6 work is only at the stage of WG discussion, so reject is really not relevant at this point, and (b) I know personally of people in the operational community who, far from rejecting it, are actively working on the specifications. That being said, constructive technical input from the operational community is very welcome and is always listened to. Shim6 *is* listening to it. This failure of leadership from the IETF to provide a roadmap for a viable alternative to PI is a factor in the support for going with the current technology. First of all, the IETF is the set of people who choose to work in the IETF. So if there is a failure, all of us here should look in the mirror together to find the culprits. Second, I believe that the failure is much deeper, at the mathematical level - we need an alternative to the BGP4 model we've been based on for ten years, and that is a truly hard problem. Scott Leibrand wrote: .. I agree, especially in the near term. Aggregation is not required right now, but having the *ability* to aggregate later on is a prudent risk reduction strategy if today's cost to do so is minimal (as I think it is). I think that's an understatement until we find an alternative to BGP aggregation. That's why my challenge to Iljistsch was to simulate 10B nodes and 100M sites - if we can't converge a reasonable sized table for that network, we *know* we have a big problem in our future. Not a risk - a certainty. Edward Lewis wrote: ... The debate between 1) what happens to router tables with PI prefixes, 2) what happens when the protocol is crimped into a comfortable-to-operate fashion, and 3) what customers are will to bear, has been raging for more than a year. It's plain to see that PI space threatens to blow up routing. It's plain to see that IPv6 is supposed to allow for end-to-end flexibility. It's plain to see that customers no longer want to be tied to ISPs. With all due respect to the debates in the RIRs, these three facts were well known when the multi6 WG was created, four years before the shim6 proposals emerged. Also, I refer you to a recent message in a forked part of this thread: http://ops.ietf.org/lists/shim6/msg01288.html in which Scott Leibrand nicely positions shim6 and PI as parts of the overall solution space. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Brian E Carpenter wrote: ... Scott Leibrand wrote: .. I agree, especially in the near term. Aggregation is not required right now, but having the *ability* to aggregate later on is a prudent risk reduction strategy if today's cost to do so is minimal (as I think it is). I think that's an understatement until we find an alternative to BGP aggregation. That's why my challenge to Iljistsch was to simulate 10B nodes and 100M sites - if we can't converge a reasonable sized table for that network, we *know* we have a big problem in our future. Not a risk - a certainty. The problem with your challenge is the lack of a defined topology. The reality is that there is no consistency for topology considerations, so the ability to construct a routing model is limited at best. The other point is that the protocol is irrelevant. Whatever we do the architectural problem is finding an aggregation strategy that fits a routing system in hardware that we know how to build, at a price point that is economically deployable. As far as I am concerned BGP is not the limitation. The problem is the ego driven myth of a single dfz where all of the gory details have to be exposed globally. If we abolish that myth and look at the problem we are left with an answer where BGP passing regional aggregates is sufficient. Yes there will be exception routes that individual ISPs carry, but that is their choice not a protocol requirement. Complaining that regional aggregates are sub-optimal is crying wolf when they know they will eventually loose to the money holding customer demanding non-PA space. The outcries about doom and gloom with PI are really about random assignments which would be even less optimal. The fundamental question needs to be if there is an approach to address allocation that can be made to scale under -any- known business model, not just the one in current practice. It is not the IETFs job to define business models, rather to define the technology approaches that might be used and see if the market picks up on them. Unfortunately over the last few years the process has evolved to excluding discussions that don't fit in the current business models, despite the continuing arguments about how those models are financial failures and need to change. The point that Scott was making is that there are proposals for non-random assignments which could be carried as explicit's now and aggregated later. What we lack is a forum to evaluate the trade-off's. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Tue, Apr 18, 2006 at 03:45:17PM -0400, Keith Moore wrote: not in my recollection. It's been awhile, but I recall pathalias being used to do source routing - given a hostname, to specify a complete path to that host. (I also recall it sometimes being used to do rerouting - discarding the current source route and replacing it with one thought to be better. It's also my recollection that the latter tended to cause routing loops and dropped messages.) I don't recall pathalias being used to replace a global location-independent identifer with an aggregatable global locator. UUCP didn't have any such beast. Fair enough. I was thinking of the rerouting hacks that would replace UUCP bang paths with a shortcut routing using SMTP mail. That was fairly reliable, from my memory. This probably isn't an exact analogy for the aggregatable global locator that you were referring to, but it had that effect, roughly speaking. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Keith Moore moore@cs.utk.edu Number portability, after all, only requires a layer of indirection. We can certainly engineer that! And we have. It's called the DNS. no it's not. DNS sucks for that. it's too slow, too likely to be out of sync. DNS names are the wrong kinds of names for this. Pardon me, but my bogometer just pinned. You keep bitching about the DNS, and a lot of your complaints have a point, but this one is too much. The whole effing point of the DNS is to translate from 'service-names' (to coin a term) to addresses. If the DNS can't do that, what the hell is the point of it? we can build indirection into the routing infrastructure. Can I get you to be a little more precise in terminology here? Are you talking about putting indirection into the routing (i.e. path-finding, including databases and algorithms), or into the forwarding? From your later message it seems you visualize more the latter? And you do not seem to be visualizing doing this mapping at every hop? In other words, architecturally speaking, you're proposing jacking up the current 'internetwork' layer and putting a new, second, 'internetwork' layer underneath it? In other words, you'd be creating a new name-space *below* the current 'addresses', which would become mostly just identifiers? Shortly after being emitted, packets would be wrapped up in a lower-layer, but still internetwork-wide header, which contained the 'locator' of their destination? This is not an unreasonable approach. (Not too surprising that I approve, since I proposed the same basic mechanism myself, several decades ago, as a way of introducing a new addressing/routing architecture!) Now, if only we could actually design that layer, as opposed to creating it incrementally by various small accretions/kludges... identifer to locator mappings that is distributed via BGP. BGP has a hard enough time as it is. You complain about people wanting to dump the kitchen sink of functionality into DNS, because it's there, but you're happy to commit the same sin yourself, elsewhere... Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Terry Gray [EMAIL PROTECTED] Would you agree with the thesis that *without* pervasive PI, the future of NAT (or some other mechanism for providing address autonomy to organizations) is absolutely guaranteed forever (even with v6)? The use of NAT to provide local addressing regions (to avoid the need to renumber) is just a symptom of the fact that the architecture doesn't have enough namespaces (and layers of binding between them). But rather than fix that *real* problem, we'd rather go for easy kludges that fix only a tiny part of the problem, and have minimal cost in the short term, ignoring the fact that in the long term they create more problems than they solve. Hey, wait a minute, that sounds just like a description of NAT too! Funny thing about that... It does make me wonder if there is any hope for resurrection of 8+8... That's about as likely as the adoption of a restricted subset of the CLNP specification, on which mandated a globally unique ID portion of the NSAP (I think that was called TUBA, IIRC). That was rejected because it would be incompatible with the installed base. The fact that in so rejecting it, that decision doomed CLNP, was apparently not clearly obvious to everyone. Now we hear that anything like 8+8 is infeasiable because it's incompatible with the installed base (all 17 of them). Hey, wait a minute... Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Original Message From: Keith Moore moore@cs.utk.edu Number portability, after all, only requires a layer of indirection. We can certainly engineer that! And we have. It's called the DNS. no it's not. DNS sucks for that. it's too slow, too likely to be out of sync. DNS names are the wrong kinds of names for this. Pardon me, but my bogometer just pinned. You keep bitching about the DNS, and a lot of your complaints have a point, but this one is too much. The whole effing point of the DNS is to translate from 'service-names' (to coin a term) to addresses. If the DNS can't do that, what the hell is the point of it? 'service-name' is a pretty vague term. what one person means by that term might not be the same as what a different person means by that term. also, while DNS might be used for mapping service names to addresses, that (in my understanding) is not quite the same thing as what it was designed to do - DNS has become the proverbial hammer that has been used to drive all kinds of things that only vaguely resemble nails. what I want is a layer of indirection that (a) accepts things that look like IPv6 addresses (so that the host to network and the API doesn't change, and also so that it's possible to send traffic directly to a locator using the same interface on the occasions where that is appropriate) (b) is highly likely to be in sync with reality, in that it's inherently maintained by the same people who maintain routers and network links and advertise BGP locator prefixes. DNS is sometimes maintained by these folks, sometimes not, as it's really more of an application layer concern, though it has often been corrupted by tying it to DHCP. but I digress. (c) is coarse (meaning that it doesn't try to provide indirection on a per-identifier or per-locator basis, because that would impair the next goal) (d) provides fast lookups (meaning that the indirection data is replicated so widely that in most, maybe all, cases there's no need for a lookup to an external host - the router that adds the forwarding header already has that redirection information on hand). in other words, the data is flooded, not merely cached. (e) supports multihoming we can build indirection into the routing infrastructure. Can I get you to be a little more precise in terminology here? Are you talking about putting indirection into the routing (i.e. path-finding, including databases and algorithms), or into the forwarding? by 'infrastructure' what I mean is that this is a new service that would be provided by augmenting the functions that routers currently perform. From your later message it seems you visualize more the latter? And you do not seem to be visualizing doing this mapping at every hop? correct. I want to do the mapping on the periphery of the network, at what I think of as border routers but at any rate no later than the boundary of the default-free zone. part of this stems from a desire to avoid having to do wire-line speed lookups in portions of the network where the wires are so fast that memory lookups are too slow (though I don't pretend I can avoid all of those cases). more generally I think there's an inevitable trend towards state at the edge of the network (rather than just state at the endpoints) and I think it makes architectural sense to try to collect that state in one place for better fate sharing. so I can imagine that the same box that adds the outer header on transmission and strips it on receipt also implements a firewall and a home agent for mobile IP. In other words, architecturally speaking, you're proposing jacking up the current 'internetwork' layer and putting a new, second, 'internetwork' layer underneath it? In other words, you'd be creating a new name-space *below* the current 'addresses', which would become mostly just identifiers? Shortly after being emitted, packets would be wrapped up in a lower-layer, but still internetwork-wide header, which contained the 'locator' of their destination? in a nutshell, yes. I don't pretend it's that simple - in particular I think that having different zones of the network (one where identifiers are used, another where locators are used) would have 'interesting' ripple effects on the architecture, and that it would take some time to understand those and to minimize the worst effects. for instance, I doubt that we can cleanly separate the two zones. but that's the basic idea. identifer to locator mappings that is distributed via BGP. BGP has a hard enough time as it is. You complain about people wanting to dump the kitchen sink of functionality into DNS, because it's there, but you're happy to commit the same sin yourself, elsewhere... fair point. But I don't see BGP as doing anything other that carrying the data. in other words I don't think that this should affect forwarding table computations or
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 18-apr-2006, at 13:50, Noel Chiappa wrote: Now we hear that anything like 8+8 is infeasiable because it's incompatible with the installed base (all 17 of them). 18 if the IETF would finally start eating its own dog food... Let me observe once again that 8+8/GSE is incomplete because it doesn't provide a secure binding between the id and the loc, which is very necessary in a few places, and because it doesn't have any failover mechanisms. So even if compatibility with existing IPv6 wouldn't be an issue, 8+8/GSE would need significant amounts of work. But in the IETF compatibility with existing deployments is historically considered important (and even though IPv6 isn't deployed very widely, it's already in a lot of software and even some hardware so changing it now would create more problems than deployment figures suggest). If you add security, failover and backward compatibility to 8+8/GSE you get something that looks a whole lot like shim6. The only part that's missing is rewriting locators by routers, which wouldn't be extremely hard to add to shim6 but since today's routers can't do it shim6 needs to work without this capability first. And while I'm observing, the recent exchange between you and Keith is exactly the kind of stuff that makes making fundamental changes in our architecture and/or base protocols so hard as we saw in multi6: the routing, DNS, transport and application people all want someone else to suffer the pain caused by something new. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Keith, sort of. MPLS with globally-scoped tags, and a database of [course] (think subnet sized) identifer to locator mappings that is distributed via BGP. border routers look at the destination host identifier, find the set of locators that correspond to it, and pick the best locator given current routing conditions. Haha. Check out some stuff Professor Dave Cheriton did at http://www-dsg.stanford.edu/triad/ It smells remarkably like pathalias to me ;-) Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
It smells remarkably like pathalias to me ;-) except that I'm not proposing that border routers do source routing, just that they map from PI identifiers to PA locators and prepend a header that causes the payload to be routed to the locator. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Tue, Apr 18, 2006 at 11:42:27AM -0400, Keith Moore wrote: It smells remarkably like pathalias to me ;-) except that I'm not proposing that border routers do source routing, just that they map from PI identifiers to PA locators and prepend a header that causes the payload to be routed to the locator. And that sounds exactly like pathalias and what the Usenet/SMTP smart routers did, yes? Hopefully though they wouldn't require as much CPU power to calculate as pathalias database required --- as I recall Erik Fair at Apple used a Cray for that purpose, because he didn't like waiting :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Tue, Apr 18, 2006 at 11:42:27AM -0400, Keith Moore wrote: It smells remarkably like pathalias to me ;-) except that I'm not proposing that border routers do source routing, just that they map from PI identifiers to PA locators and prepend a header that causes the payload to be routed to the locator. And that sounds exactly like pathalias and what the Usenet/SMTP smart routers did, yes? not in my recollection. It's been awhile, but I recall pathalias being used to do source routing - given a hostname, to specify a complete path to that host. (I also recall it sometimes being used to do rerouting - discarding the current source route and replacing it with one thought to be better. It's also my recollection that the latter tended to cause routing loops and dropped messages.) I don't recall pathalias being used to replace a global location-independent identifer with an aggregatable global locator. UUCP didn't have any such beast. Hopefully though they wouldn't require as much CPU power to calculate as pathalias database required pathalias was trying to add automatic routing to uucp. we're already doing routing in the internet, and I don't see how what's being discussed here will increase the complexity of those computations over what they already are. as far as I can tell, we're talking about ways to make routing computations _more_ efficient. adding a layer of indirection that hides locators from end networks should allow locators to be strictly PA and even to be renumbered from time to time without impacting users. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Tue, 18 Apr 2006 14:46:15 -0400, Theodore Ts'o [EMAIL PROTECTED] wrote: On Tue, Apr 18, 2006 at 11:42:27AM -0400, Keith Moore wrote: It smells remarkably like pathalias to me ;-) except that I'm not proposing that border routers do source routing, just that they map from PI identifiers to PA locators and prepend a header that causes the payload to be routed to the locator. And that sounds exactly like pathalias and what the Usenet/SMTP smart routers did, yes? Hopefully though they wouldn't require as much CPU power to calculate as pathalias database required --- as I recall Erik Fair at Apple used a Cray for that purpose, because he didn't like waiting :-) Peter Honeyman optimized my original algorithm considerably; there's even a paper on it on my web page. There were two more fundamental problems that neither of us every really solved. One is relatively easy today: we didn't have good maps of connectivity for each site. Today, though, we have routing protocols that are supposed to disseminiate such data. Even now, though, there's a tension between physical connectivity and policy; we ran into that, too. The harder problem, though was metrics. Simple hop count gave bad results; bandwidth varied. (That said, the probability of uucp silently dropping the message was high enough that maybe we should have stayed with just that as a metric) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Apr 16, 2006, at 3:17 AM, Iljitsch van Beijnum wrote: On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: Wow, Iljitsch, I have never lost so much respect so quickly for someone who was not flaming a specific person or using profanity. Congratulations. Well, that's too bad. But several years of trying to get a scalable multihoming off the ground (flying to different meetings on my own dime) where first my ideas about PI aggregation are rejected within the IETF mostly without due consideration because it involves the taboo word geography only to see the next best thing being rejected by people who, as far as I can tell, lack a view of the big picture, is enough to make me lose my cool. Just a little. Thank you for believing my opposition of your ideas is simply because I lack a view of the big picture. Note that it is entirely possible I believe the reverse to be true. Or perhaps you see a big picture, and I just see a bigger one. However, I probably won't lose my cool since, as I stated before, the overwhelming majority of people who run the Internet seem to see my bigger picture. Back on topic, it is not just those 60 people - the playground appears to overwhelmingly agree with their position. I know I do. Don't you think it's strange that the views within ARIN are so radically different than those within the IETF? Sure, inside the IETF there are also people who think PI in IPv6 won't be a problem, but it's not the majority (as far as I can tell) and certainly not anything close to 90%. Now the IETF process isn't perfect, as many things depend on whether people feel like actually doing something. But many of the best and the brightest in the IETF have been around for some time in multi6 and really looked at the problem. Many, if not most, of them concluded that we need something better than IPv4 practices to make IPv6 last as long as we need it to last. Do you think all of them were wrong? Yes. And so does essentially everyone else who runs an Internet backbone. These are some of the best and brightest in the world, and most of them have been around for .. well, 'forever' in Internet terms. But decision such as these really shouldn't be decided simply because someone has been doing this longer. I am sorry your technical arguments have not persuaded us in the past. But I would urge you to stick to those, Stay tuned. I'll try. But honestly, reading the same arguments over and over gets tiresome, especially when so many well-qualified people have explained the opposing PoV so well. Oh, and one thing I should have said last time: Technical arguments are important, but they are only part of the decision process. People (like me) have explained that the Internet is a business, and in addition to being .. technically unsavory to many people, shim6 is simply not viable in a business setting. Neither backbone operators (vendors) nor end users (customers) are warming to the idea. Just the opposite. (At least in general, the one-in-a-million end user with DSL and cable who likes the idea 'cause he can't figure out how to spell B-G-P or doesn't want to pay for it is irrelevant.) So how do you get a technology widely accepted when the majority of people involved do not think it is the best technical solution? When the majority of vendors supposed to implement it will not do so for technical -and- business reasons. When the majority of end users who are supposed to buy the service will not? Okie, trick question. :) You don't. -- TTFN, patrick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 4/14/06, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI.6 voted against.Wow, 10 to 1. Amazing.Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet.Where is ICANN when you need it? This little experiment in playgrounddemocracy has to end before people get hurt.I am a member of the ICANN ASO AC and I was there, but I'm not sure you meant that, and, the ARIN forums are open to all.The vote was a display to our advisory council to what the constituents want.The ARIN mailing lists get just as much consideration.Where are you? -M___ Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. Wow, Iljitsch, I have never lost so much respect so quickly for someone who was not flaming a specific person or using profanity. Congratulations. Back on topic, it is not just those 60 people - the playground appears to overwhelmingly agree with their position. I know I do. I am sorry your technical arguments have not persuaded us in the past. But I would urge you to stick to those, or at least consider why we remain unconvinced, rather than devolve into .. whatever that post was supposed to be. -- TTFN, patrick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
I agree. /jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick W. Gilmore Sent: Sunday, April 16, 2006 12:10 AM To: Iljitsch van Beijnum Cc: Patrick W. Gilmore; shim6-wg; [EMAIL PROTECTED]; [EMAIL PROTECTED]; IETF Discussion; [EMAIL PROTECTED]; v6ops@ops.ietf.org Subject: Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN] On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. Wow, Iljitsch, I have never lost so much respect so quickly for someone who was not flaming a specific person or using profanity. Congratulations. Back on topic, it is not just those 60 people - the playground appears to overwhelmingly agree with their position. I know I do. I am sorry your technical arguments have not persuaded us in the past. But I would urge you to stick to those, or at least consider why we remain unconvinced, rather than devolve into .. whatever that post was supposed to be. -- TTFN, patrick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ppml] [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
This message was cross posted to a large number of lists. I would like to make the root of the discussion clear, without taking an opinion. This link is the original message, best I can tell. Hopefully from there each individual on this message can tell how they came to receive it. http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00162.html Please go back to the header as well. Lists from several different organizations have been CC'ed, and each will have their own opinion. All are available on the web. A well informed reply is the best reply. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpOrmumakdQN.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Hi, On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote: The IETF has NOTHING to say anymore than any other body about any RIR policy. I want it to remain that way. IETF job is a standards body not a deployment body. Things work a lot better if IETF and RIRs work hand-in-hand - that is, IETF makes standards that people can work with, and RIRs use allocation policies that somewhat reflect what the protocol designers had in mind. For IPv6, this isn't a huge success story yet... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AGMail: [EMAIL PROTECTED] Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Number portability, after all, only requires a layer of indirection. We can certainly engineer that! And we have. It's called the DNS. no it's not. DNS sucks for that. it's too slow, too likely to be out of sync. DNS names are the wrong kinds of names for this. the protocol is poorly adapted for this purpose, the infrastructure is worse. I agree with Christian. we can build indirection into the routing infrastructure. it's probably the right way to go. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Keith Moore wrote: ... I agree with Christian. we can build indirection into the routing infrastructure. it's probably the right way to go. One could argue that we already have. It's called MPLS... Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Keith Moore wrote: ... I agree with Christian. we can build indirection into the routing infrastructure. it's probably the right way to go. One could argue that we already have. It's called MPLS... sort of. MPLS with globally-scoped tags, and a database of coarse (think subnet sized) identifer to locator mappings that is distributed via BGP. border routers look at the destination host identifier, find the set of locators that correspond to it, and pick the best locator given current routing conditions. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Noel Chiappa wrote: ... it is manageable to deal with porting between providers within a city, but not between cities Metro addressing! All those old classics are making a comeback... Ideas never die; some are just ahead of their time. ;) those groups couldn't see the forest for the trees. They were absolutely technically informed, but completely unwilling to listen to the big picture political reality. And the current group has a superior grasp of the all-around picture? Ah, got it. I didn't say that. Note they did not specify exactly how they were going to do it, just that it would be done. If the technical group has approaches that are better than first-come from a swamp-block, now is the time to get them on the table. They have called the bluff of the PA-only tantrum and will do random assignments if nothing better emerges. an attempt to get in front of what is a growing wave of demand to head off an outright pronouncement from outside the community which will result in number portability. Since there's no technical difference between PI and number portability, I expect approval of PI-space will lead to portability anyway. Yes, the current criteria for PI-space are rather limited, but since there's no particular technical rationale for picking /N versus /M, I expect to see a salami-slicing political debate in which people will demand smaller and smaller blocks be supported, because to do anything else is dumping on the little guy, while letting the big players have acess to something the small players don't. I happen to agree with you here, which is why I have been advocating a particular geo approach that can work with existing BGP and be scaled up and down as far as necessary to contain the routes. Unfortunately to date, the IESG has not understood the necessity to have a working group to refine a globally acceptable approach. Sigh, we're going to be paying the price for not (long ago) setting up a charging system for having a route be visible in the default-free zone. The existence of a default-free-zone was long ago relegated to myth status. There are different views of what this mythical entity contains, so by definition there is no single zone. Rather than fight to maintain an ego driven myth, we should be accepting reality and organizing structure in what appears where. there is a middle ground that gets messy because it does not have simple solutions without constraining topology. ... That set of requirements leads to structured allocations and topology constraints. Both sides will have to give I'm curious to hear what the ISP's will have to say about this topology constraints stuff... They never like it because it restrains their freedom. At the same time the carrier side of the house has learned to deal with it in the PSTN context, so the ISP side will be getting an education in dealing with customer/governmental requirements. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 17-apr-2006, at 21:20, Tony Hain wrote: I have been advocating a particular geo approach that can work with existing BGP and be scaled up and down as far as necessary to contain the routes. Unfortunately to date, the IESG has not understood the necessity to have a working group to refine a globally acceptable approach. Since this has been coming up from time to time for over a decade, why not look at it, document the results and be done much faster when it comes up again and again the following decade, I would think. But I also happen to think that aggregation inside ISP networks based on geography (which has little to do with metro addressing as proposed but never worked out in detail 10 years ago) can actually work. Unfotunately when it was time to decide on an approach to further develop in multi6 there was no support for this so shim6 happened (which is also a good approach in its own right) but now the operator / policy making community balks at shim6... Anyway, here's the draft once again for those looking for some reading material: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt But it's really a no-brainer: with straight PI we know that smarter routing is never going to help us for those prefixes. But if PI addresses are given out in _some_ aggregatable we at least have a chance that we can clean up the routing tables later. Geography makes sense to aggregate on as a next best thing when provider aggregation can't be used because it optimizes for one of the few network properties that are more or less constant: the speed of light. (With apologies to Brian for not having run my 100M BGP table simulations.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Christian Huitema [EMAIL PROTECTED] only requires a layer of indirection. We can certainly engineer that! Yes, but we aren't. E.g. it would be really wonderful if we had some way of finding out what range(s) of addresses belonged to XYZ Corporation, so that the configuration of the firewall of their commercial partner, ABC Corporation, could contain a single entry for XYZ Corp's addresses, rather than list the actual addresses. As long as we are configuring things with actual addresses, it will remain incredibly painful to change them. Even worse, we're going in the *other* direction, and instead of adding another level of indirection, to provide new functionality, we're loading additional functionality (PI) onto the same old level of naming we already have. Architecturally-speaking, this design gets an 'F'. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Tony Hain [EMAIL PROTECTED] Since there's no technical difference between PI and number portability, I expect approval of PI-space will lead to portability anyway. Yes, the current criteria for PI-space are rather limited, but since there's no particular technical rationale for picking /N versus /M, I expect to see a salami-slicing political debate in which people will demand smaller and smaller blocks be supported, because to do anything else is dumping on the little guy, while letting the big players have acess to something the small players don't. I happen to agree with you here, which is why I have been advocating a particular geo approach ... be scaled up and down as far as necessary to contain the routes. ... the IESG has not understood the necessity to have a working group to refine a globally acceptable approach. Perhaps I'm not understanding your point, but the whole point of my comment is that there's no bright technical line differentiation between one size and another, and we'll inevitably wind up being forced to support the smallest possible one. Perhaps the IESG's reluctance is because this now turns into something like the old (PC-incorrect) joke about the gentleman and the debutante in the railway - we've already decided what we are, now we're only haggling about the price (or block-size, as the case may be). Sigh, we're going to be paying the price for not (long ago) setting up a charging system for having a route be visible in the default-free zone. The existence of a default-free-zone was long ago relegated to myth status. There are different views of what this mythical entity contains, so by definition there is no single zone. I am fully aware that for a variety of reasons, including policy limitations, as well as different aggregation action boundaries (i.e. places where routes to X.1 ... X.n get discarded in favour of a single route to X), different in the 'core' (to use another somewhat nebulous term) routers will have somewhat different routing tables. My reference was more in the sense of 'routers which do not have a routing table which consists of a small number of destinations, and use a default for the rest' - i.e. routers which *do* have to have routing information for the vast majority of the destinations in the entire network. If we had a cost-structure which actually reflected reality (so that PI-address X, which has to have a routing table entry in every router which wants to be able to send traffic to it, had to pay for those routing table entries), we might have a little less enthusiasm for the PI-approach. PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Noel Chiappa wrote: PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Where are these free routers and how do I get one? - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Mon, 17 Apr 2006, Noel Chiappa wrote: PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Noel, While I might have chosen a different metaphor, I can agree with the basic point, yet I wonder: Would you agree with the thesis that *without* pervasive PI, the future of NAT (or some other mechanism for providing address autonomy to organizations) is absolutely guaranteed forever (even with v6)? To me, that seems obvious, so I'd be interested in counter arguments. It does make me wonder if there is any hope for resurrection of 8+8... -teg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
If I the only choices available are widespread PI and widespread NAT, then we need to really change the way we approach things. Either of those is a very bad answer. Now, at least some of the folks supporting this PI assignment initiative have indicated that they do not believe it will be widespread (either because the barriers will still be high or because the demand for BGP based multi-homing is small, or maybe for some other reason.) If that assumption is correct, then the comparison with NAT is irrelevant. Yours, Joel M. Halpern At 06:57 PM 4/17/2006, Terry Gray wrote: On Mon, 17 Apr 2006, Noel Chiappa wrote: PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Noel, While I might have chosen a different metaphor, I can agree with the basic point, yet I wonder: Would you agree with the thesis that *without* pervasive PI, the future of NAT (or some other mechanism for providing address autonomy to organizations) is absolutely guaranteed forever (even with v6)? To me, that seems obvious, so I'd be interested in counter arguments. It does make me wonder if there is any hope for resurrection of 8+8... -teg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Iljitsch van Beijnum wrote: ... Since this has been coming up from time to time for over a decade, why not look at it, document the results and be done much faster when it comes up again and again the following decade, I would think. That was why I proposed a bof, and will do so again. Noel Chiappa wrote: ... Perhaps I'm not understanding your point, but the whole point of my comment is that there's no bright technical line differentiation between one size and another, and we'll inevitably wind up being forced to support the smallest possible one. That was my point as well. Given that all uses of PI are as legitimate as any other, the issue boils down to finding a way to bucket the results into manageable pieces that will fit in known routers and protocols. Perhaps the IESG's reluctance is because this now turns into something like the old (PC-incorrect) joke about the gentleman and the debutante in the railway - we've already decided what we are, now we're only haggling about the price (or block-size, as the case may be). The first step on the path to deciding price is to do the AA thing and acknowledge that there is no single global perception of all possible routes (ie: there are already buckets). Once that is acknowledged, we know the system doesn't collapse in the presence of buckets, so the next step is to decide who plays which role in the scenario. The pragmatist says our job is to find the point of equally shared pain. The ISPs want all the pain to be at the edge, and randomly assigned PI puts all the pain in the middle. There are alternatives to be explored. Iljitsch and I have similar approaches where the basic difference is who gets to decide the blocks and on what frequency they might change. Either will work, but there may be others that a working group should evaluate for their trade-offs. Keith Moore wrote: ... One could argue that we already have. It's called MPLS... sort of. MPLS with globally-scoped tags, and a database of coarse (think subnet sized) identifer to locator mappings that is distributed via BGP. border routers look at the destination host identifier, find the set of locators that correspond to it, and pick the best locator given current routing conditions. My point was that the technology exists. Yours is that it is currently deployed and operated in a closed manner. I suspect that the difference was because closed was easier than opening it up to manage a global tag list, and that sufficient motivation would change that. Terry Gray wrote: ... It does make me wonder if there is any hope for resurrection of 8+8... The time for that was before the APIs were defined. At this point it would need to be 6+10 (though the e.g.b. control-mongering ISPs are pushing to reduce the amount of space that a sight can have to make it 7+9), but either way it is nothing more than shim6 being done by the edge routers rather than the end systems. The application wants persistence and the network wants the freedom to randomly over-write bits to improve its efficiency (never mind that the process of deciding and over-writing is inherently inefficient). Given that the application is closest to the end user, the end user doesn't care about efficiency unless they are given quantitative feedback about cost, and the globally distributed cost of a routing slot in a fictitious single routing zone is difficult to define, the winner should be obvious. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Terry/David, Terry Gray wrote: *without* pervasive PI, the future of NAT (or some other mechanism for providing address autonomy to organizations) is absolutely guaranteed forever (even with v6)? To me, that seems obvious Obvious it is to me too. Problem is: there are way too many people in here who have successfully renumbered their 4-host home network and never worked into a larger environment who think that because they successfully renumbered their home network in an hour the same can happen with an enterprise network. They've never been out in the real world, no wonder why they still wonder why the real world has embraced NAT. It does make me wonder if there is any hope for resurrection of 8+8... There is not. First, 8+8 had disadvantages. Second, even though GSE and later MHAP tried to reduce the inconvenience, the fact if the matter is that nothing is as simple as raw PI; any dual-space ID-LOC system introduces yet another layer of complexity, bugs, incompatibilities, etc. In the end, it's all about money and timing is important: 8+8 was written when a core router had less memory and processing power than the cell phone I carry. As of today, it costs less to go PI than to go 8+8, without the shortcomings of 8+8. No brainer. David Conrad wrote: The end point identifier's upper 48 (or whatever) bits is being network address translated into the routing locator (the lower 80 bits would be untouched). But to avoid the soul-searing EVIL (plain and simple, from beyond the 8th dimension) of NAT, you simply reverse the translation, restoring the upper 48 bits (which, conveniently, don't have to be carried around in the packet since the destination is pretty much guaranteed to know what end point identifier prefix it is at). The two EVILs cancel each other out. A while ago, I designed exactly what you are describing: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt It's going the same place than 8+8 and GRE: in the grave. Nice idea, but too much politics and money involved in deploying. Back to raw PI. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Kevin Loch wrote: In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. Whatever. This is all quite silly. SHIM6 is still speculative in nature and for the operational community to attempt to quash it is an exceedingly ridiculous waste of their time. But heck, at least its their time and not my time. As has been shown many times, the Internet and capitalist economics tend to use the most efficient routes over time. The nice thing about the current SHIM6 design is that it's backward compatible with the rest of the world, so if some SPs don't like SHIM6 and it turns out to work for enterprises and consumers, tough noogies. Otherwise, tough noogies to those who do use it when it doesn't work. As to allocating out PI address space, be my guest. There would be no better way for the operational community to assure that they pay for VERY high end routers for the foreseeable future, and that will line my and every other CSCO and JNPR shareholders' pockets for a time while putting out of business smaller ISPs who can't afford such specialized high end gear (we generally call those people NANOG attendees). And if this decision was disconnected from those people then clearly something is wrong with the RIR governance model (I don't think this is true - I think the RIRs generally understand this problem). Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 14-Apr-2006, at 14:01, Kevin Loch wrote: Iljitsch van Beijnum wrote: I'm not saying that these people expected the internet to melt down by supporting this policy, but that's exactly the problem. Within the IETF, we've been working long and hard to find a way to allow for multihoming that we KNOW won't melt the internet, and now just as these efforts are getting close to paying off (shim6) In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. Given that it's current form is ante-natal, this seems healthy and constructive. I presume you're not saying that the operational community has rejected all possible, future alternatives to open slather on PI, nor that the vast majority of Internet users who are (for example) not served by the ARIN proposal should never be allowed to multi-home. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
[very nice cross posting going on here ;) ] On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote: [... large snip about trying to bash shim6 which is not finalized yet, thus how can you bash it ? Note: extra sarcasm included in this post. Eat the eggs with salt. ...] Oh, and one thing I should have said last time: Technical arguments are important, but they are only part of the decision process. In other words: You are right with your arguments, but I just threw your args away as they are futile based on the comparison of money earned this way or the other People (like me) have explained that the Internet is a business, and in addition to being .. technically unsavory to many people, shim6 is simply not viable in a business setting. And as you will only care for your business for the coming 10 or maybe 20 years you really can't care what happens to the internet afterward. The idea of IPv6 is (still not was) to have it around for quite some time longer than the lifespan of IPv4. Fortunately, the PI thing is far from the end of the world and will only help catch on, see below. Of course any vendor will love the idea of having to do another IP version of course, bring in the cash ;) Neither backbone operators (vendors) nor end users (customers) are warming to the idea. Just the opposite. (At least in general, the one-in-a-million end user with DSL and cable who likes the idea 'cause he can't figure out how to spell B-G-P or doesn't want to pay for it is irrelevant.) Irrelevant for you as they don't give you money. Indeed, you only look at your own business interrest (and who can blame you for that ;) (Once though the internet was there for the masses and not only for the ones with cash) So how do you get a technology widely accepted when the majority of people involved do not think it is the best technical solution? When the majority of vendors supposed to implement it will not do so for technical -and- business reasons. There is for you indeed a business reason to not like it: the end-site won't have any reason to stick to the upstream. Which is indeed a bad business for many of the 'vendors' you mean. As Eliot Lear also said very clearly: Thanks for lining the vendors and all the stockholders pockets ;) That is in the long run, most likely in the coming 10-20 years the IPv6 routing tables will not have 'exploded' yet, but the folks selling equipment and having stocks of those venders after that most likely will have a nice retirement fund. Thanks to you! Nevertheless, the PI thing is really *not* a bad thing, as it can be used as an identifier for shim6, which is actually perfect. It just saves on having to do a complete policy process for getting address space for this type of usage. But thanks to this, this won't be needed and thus in the end anybody who can get PI can use a shim6-alike solution and won't have any problem with the upstream that actually wanted to lock them in by letting them pay loads for an entry in the BGP tables. Thus people voting for PI, thanks for helping shim6 or another solution in that space, progress a lot :) And finally on a much brighter note, especially for the shim6 folks: I know of quite a number of endsites that don't want to use BGP, the don't care about an entry in the routing tables, but do want to be multihomed in an easy way and also want to have 1 unique address space on their local network, but do want to use different upstreams. Shim6 will be perfect for this and thanks to the PI space their is the perfect identifier. Greets, Jeroen (being sarcastic, I guess the amounts of chocolate did it, but hey, I have a great excuse being only 7 mins away from the LindtSprungli factory outlet, happy easter! ;) signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Joe Abley wrote: On 14-Apr-2006, at 14:01, Kevin Loch wrote: In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. I presume you're not saying that the operational community has rejected all possible, future alternatives to open slather on PI, nor that the vast majority of Internet users who are (for example) not served by the ARIN proposal should never be allowed to multi-home. No, I'm not saying that at all. This policy change is about creating a viable migration path for non-isp PI users before the IPv4 panic begins. Shim6 was seen as not doing that even if/when it was widely deployed. A scalable routing architecture that is a suitable replacement for PI for end sites would be great. Please don't give up on that. - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 16-Apr-2006, at 14:18, Kevin Loch wrote: Joe Abley wrote: On 14-Apr-2006, at 14:01, Kevin Loch wrote: In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. I presume you're not saying that the operational community has rejected all possible, future alternatives to open slather on PI, nor that the vast majority of Internet users who are (for example) not served by the ARIN proposal should never be allowed to multi-home. No, I'm not saying that at all. Excellent, thanks :-) A scalable routing architecture that is a suitable replacement for PI for end sites would be great. Please don't give up on that. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Noel Chiappa wrote: Metro addressing! All those old classics are making a comeback... http://arneill-py.sacramento.ca.us/ipv6mh/metro-addr-slides-jul95.pdf Noel, it's not old, only 11 years old ;-) I found another use for ipv6mh after all: museum. Tony Hain wrote: those groups couldn't see the forest for the trees. They were absolutely technically informed, but completely unwilling to listen to the big picture political reality. And the current group has a superior grasp of the all-around picture? Ah, got it. :-D Kevin Loch wrote: A scalable routing architecture that is a suitable replacement for PI for end sites would be great. Please don't give up on that. This means replacing BGP, it's no small task and will take a long time. Yes, the current criteria for PI-space are rather limited, but since there's no particular technical rationale for picking /N versus /M, I expect to see a salami-slicing political debate in which people will demand smaller and smaller blocks be supported, because to do anything else is dumping on the little guy, while letting the big players have access to something the small players don't. This looks very clear to me as well. And while the results are not good, the process itself is sound (if we are not to protect the little guy against the large corporate evil, who is). I will say something about it though: If you look who's behind 2005-1, you will find many ISPs, the same crowd that lobbied to have to PI in IPv6 years ago. Therefore I think what Jeroen wrote below is relevant: Jeroen Massar wrote: Iljitsch, please stop seeing the 'bad' side about this. If people really are going to stick millions of routes into BGP they will hang themselves anyway as they will be the ones having to buy the fat new shiny routers for lots of cash, Yes yes yes! which can then be provided by all those nice consultants and vendors who thrive on things like that. YES YES YES! :-D Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Hello; On Apr 14, 2006, at 4:05 PM, Scott Bradner wrote: Michel sed breaking news The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html note the move it to last call teh last call (very much like teh IETF last call) will be on the ARIN ppml - see http://www.arin.net/policy/index.html for information on the policy process and instructons on how to subscribe to the mailing list if you have an interest in this topic please do join the list and the discussions - silence is seen as agreement If you are going to join the discussion now, you might want to look at the Montreal presentations on the two proposals. http://www.arin.net/meetings/minutes/ARIN_XVII/PDF/monday/ 2005-1_2006-4_intro.pdf http://www.arin.net/meetings/minutes/ARIN_XVII/PDF/monday/ 2005-1v4_2006-4.pdf Note that 2005-1 has been under discussion since Feb 2005, and has been brought up at 3 ARIN meetings to date, so there is also a pretty extensive email archive, with hundreds of messages in all. Scott Regards Marshall ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Tony Hain [EMAIL PROTECTED] portability could be one outcome. Given that the point of this PI exercise seems to be to increase the viability of IPv6, maybe you should go for it, and add number portability too? That should further increase the viability. it is manageable to deal with porting between providers within a city, but not between cities Metro addressing! All those old classics are making a comeback... those groups couldn't see the forest for the trees. They were absolutely technically informed, but completely unwilling to listen to the big picture political reality. And the current group has a superior grasp of the all-around picture? Ah, got it. an attempt to get in front of what is a growing wave of demand to head off an outright pronouncement from outside the community which will result in number portability. Since there's no technical difference between PI and number portability, I expect approval of PI-space will lead to portability anyway. Yes, the current criteria for PI-space are rather limited, but since there's no particular technical rationale for picking /N versus /M, I expect to see a salami-slicing political debate in which people will demand smaller and smaller blocks be supported, because to do anything else is dumping on the little guy, while letting the big players have acess to something the small players don't. Sigh, we're going to be paying the price for not (long ago) setting up a charging system for having a route be visible in the default-free zone. there is a middle ground that gets messy because it does not have simple solutions without constraining topology. ... That set of requirements leads to structured allocations and topology constraints. Both sides will have to give I'm curious to hear what the ISP's will have to say about this topology constraints stuff... Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
portability could be one outcome. Given that the point of this PI exercise seems to be to increase the viability of IPv6, maybe you should go for it, and add number portability too? That should further increase the viability. The IETF is an engineering organization. Engineers are good at engineering, not so good at setting policy. Let's assume that the policy is driven externally, and that engineers cannot impose their preferred solution. Some will say that the sky has begun to fall, and retire in an ivory tower of gloom. The optimistic engineer, on the other hand, will take that as a challenge. Clearly, the current set-up based on BGP and default-free tables is not set to absorb more than a small number of PI prefixes -- maybe a few thousands, maybe a few tens of thousands, certainly not a few hundred of millions. But who says that we cannot change it? Number portability, after all, only requires a layer of indirection. We can certainly engineer that! -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 15-apr-2006, at 18:54, Christian Huitema wrote: Clearly, the current set-up based on BGP and default-free tables is not set to absorb more than a small number of PI prefixes -- maybe a few thousands, maybe a few tens of thousands, certainly not a few hundred of millions. But who says that we cannot change it? 10 years of discussions within the IETF and basic information theory say routing won't work on the scale of the current and future internet without aggregation with reasonable hardware price/ performace ratio assumptions. Number portability, after all, only requires a layer of indirection. We can certainly engineer that! And we have. It's called the DNS. But it seems people need more indirection. Where do we draw the line? Portable street addresses? Portable GPS coordinates? It's really too bad, because we almost have what we need to pull this whole scalability thing off in IPv6: stateless autoconfig, DHCPv6 prefix delegation, dynamic DNS updates, MIPv6, shim6. The only thing missing is some finishing touches (ok, more than some for shim6, but it is moving along) and for firewall vendors to jump on the bandwagon and move away from hardcoded IP address based filters. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Sat, 2006-04-15 at 19:49 +0200, Iljitsch van Beijnum wrote: On 15-apr-2006, at 18:54, Christian Huitema wrote: [..] It's really too bad, because we almost have what we need to pull this whole scalability thing off in IPv6: stateless autoconfig, DHCPv6 prefix delegation, dynamic DNS updates, MIPv6, shim6. The only thing missing is some finishing touches (ok, more than some for shim6, but it is moving along) and for firewall vendors to jump on the bandwagon and move away from hardcoded IP address based filters. Iljitsch, please stop seeing the 'bad' side about this. If people really are going to stick millions of routes into BGP they will hang themselves anyway as they will be the ones having to buy the fat new shiny routers for lots of cash, which can then be provided by all those nice consultants and vendors who thrive on things like that. The funniest thing is that due to the open process we can always point fingers *evil grin*. But I don't see a problem at all as I mentioned before. The bright point is that the PI space provides something really good: - Folks will have their Globally Unique address space. On which they can rely that it will be theirs for a long time. Which means that it can be used as a perfect identifier for setups like shim6. The PI space will then reside in their own network, while when the packet goes over the internet, at the moment it crossed their border, the packet gets translated to the address space of the upstream provider, when arriving at the other side it gets translated back into the PI space. This will make them happy and keep the routing table very small. Just like the original idea of doing IPv6 PA was :) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
The end sites are demanding autonomy with a stable routing system. That set of requirements leads to structured allocations and topology constraints. ...it should be noted that the ones holding the money are the end sites. Which makes a case for concentrating the effort on a stable routing serving autonomous end sites. Frankly paying for an IP address makes as much sence as buying a street address (how about the Post Office putting hot street addresses on sale). It appears that IP address assignment reaches far and beyond Internet engineering and should be administered by the international politically / economically independed structure guided through RFC. [EMAIL PROTECTED] --- Tony Hain [EMAIL PROTECTED] wrote: Noel Chiappa wrote: the desire not to pass a PI for everyone policy that would explode the routing table. Interesting that you should mention that, because there's zero technical differentiation between PI space and portable addresses. So I have to wonder if this initiative will raise the pressure from users for portable addresses. Depending on how they actually get defined and handed out, portability could be one outcome. Scott a few others of us are working on the next step which would put limits on the extent of that portability (ie: it is manageable to deal with porting between providers within a city, but not between cities). PS: From: Kevin Loch [EMAIL PROTECTED] I find this comment extremely offensive. ... Your implication that the participants were either uninformed or diddn't care about the consequences is completely off base. There's a certain deep irony here, because PI-addresses have been considered at length in the IETF in at least two different WG's - CIDR-D and Multi-6. Both rejected them after extensive discussion. Nevertheless, a policy-making body has seen fit to ignore that, and make an engineering decision to deploy PI-space. It's hard to read that decision any other way than to have it imply that the decisions in those WG's were technically uninformed. No, those groups couldn't see the forest for the trees. They were absolutely technically informed, but completely unwilling to listen to the big picture political reality. This thread is arguing that this policy decision has the opposite problem, but in fact it does not. It is an attempt to get in front of what is a growing wave of demand to head off an outright pronouncement from outside the community which will result in number portability. By moving first we can put in enough technical structure to contain foreseeable problems, while if we wait we will be forced into a quick and dirty random approach that we all know will fail. I was not happy with the policy as worded, but willing to live with it for now as a first step to really fixing the problems facing edge networks. The locator/id split approach is a nice thing to work on, but it will take more than a decade to deploy even if people agree to the result. The fundamental problem is that most of the meager security architecture we do have relies heavily on those being aligned. If they are split all of the firewall silicon will have to be rebuilt and new mechanisms for tracking the identity in flight will have to be developed. Of course none of that work will start until the non-deployable shim approach has proven itself viable. Add to that the fact that it moves any semblance of control the ISP thought they had to the end node and you will find that as they already have said they will do all they can to block its adoption. The IETF has consistently refused to acknowledge that prefixes independent of PA are necessary. The intense focus on maximum aggregation at all costs is just not viable for end customers. A broken routing system is equally not viable, but there is a middle ground that gets messy because it does not have simple solutions without constraining topology. These are all trade-offs, and the ISPs are demanding unconstrained topology with a minimal routing table. That set of requirements leads to efforts like shim6. The end sites are demanding autonomy with a stable routing system. That set of requirements leads to structured allocations and topology constraints. Both sides will have to give, but it should be noted that the ones holding the money are the end sites. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 04/14/06 at 5:07pm +0200, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Did you participate in the process? Even if you can't justify travel to Montreal, the PPML is wide open. ARIN doesn't go solely by the vote in the room; they also consider whether there was consensus on the PPML. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. I think the ARIN process is closer to the IETF's rough consensus process than to democracy. If you think the PI policy ARIN passed will blow up the internet, I would encourage you to participate in drafting policy proposals to help limit the impact of PI on the routing table. Bear in mind that we didn't approve an IPv6 PI for everyone policy precisely to avoid blowing up the Internet: instead we only extended existing IPv4 policy to IPv6. As I've written before, I'm attempting to draft an ARIN policy proposal to ensure PI addresses are assigned in a regular fashion instead of the random chronological fashion we do now with IPv4. As you seem to support that, I would encourage you to help draft such a policy proposal and help get people to support it. -Scott P.S. I don't think we need quite so much cross-posting as this... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Iljitsch van Beijnum wrote: Wow, 10 to 1. Amazing. Sounds like a rough consensus to me. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. I find this comment extremely offensive. Nobody in that room would have supported a policy they actually believed would blow up the Internet. Your implication that the participants were either uninformed or diddn't care about the consequences is completely off base. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. You would actually prefer ICANN replace the open policy process of the RIR's? ARIN participants are simply following the principles the IETF used to use: rough consensus AND running code. - Kevin (trimming the cc: list for everyone's sanity) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 14-apr-2006, at 18:51, Kevin Loch wrote: Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. I find this comment extremely offensive. Nobody in that room would have supported a policy they actually believed would blow up the Internet. Your implication that the participants were either uninformed or diddn't care about the consequences is completely off base. I'm not saying that these people expected the internet to melt down by supporting this policy, but that's exactly the problem. Within the IETF, we've been working long and hard to find a way to allow for multihoming that we KNOW won't melt the internet, and now just as these efforts are getting close to paying off (shim6) a small group of people decides to throw caution in the wind and adopt a policy that opens the door to exactly the problems the IETF has been working so hard to avoid. The trouble is that we don't know for sure that doing this will turn out very bad, but there is a risk and with something as important as the internet has become, it's a very bad idea to take these kinds of risks. We have two failures: lack of foresight by the 60 people who are in favor of this, and a failure to set the I* community decision making up in a way that various parts support the same outcome. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. You would actually prefer ICANN replace the open policy process of the RIR's? Openness is good, but I'll take good decisions, however they're reached, over ones of questionable quality that were reached in an open process any day. ARIN participants are simply following the principles the IETF used to use: rough consensus AND running code. Both the IETF and the RIRs suffer from the problem that the people that speak up are self-selected. Also, the fact that each RIR comes up with its own policies but that the result shows up in routing tables world wide makes no sense. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Iljitsch van Beijnum wrote: I'm not saying that these people expected the internet to melt down by supporting this policy, but that's exactly the problem. Within the IETF, we've been working long and hard to find a way to allow for multihoming that we KNOW won't melt the internet, and now just as these efforts are getting close to paying off (shim6) In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. This failure of leadership from the IETF to provide a roadmap for a viable alternative to PI is a factor in the support for going with the current technology. - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
At 19:03 +0200 4/14/06, Iljitsch van Beijnum wrote: Both the IETF and the RIRs suffer from the problem that the people that speak up are self-selected. Also, the fact that each RIR comes up with its own policies but that the result shows up in routing tables world wide makes no sense. I disagree with that. Each RIR is a membership-supported organization, with membership largely based upon operational use of the Internet. By that I mean - if you want to operate on the Internet, you need addressing numbers. To get addressing numbers you can either buy up the assets of something that has pre-RIR space or join an RIR. The latter entails signing up to an agreement, getting space, and paying cost-recovery dues (as opposed to rent). Don't confuse the RIR public policy meetings like the one held this week in Montreal with what happens at an IETF. The *public* policy meetings are held to gain access by the general populace to the process; these meetings by themselves do not produce policy. Policy within the RIRs are formally adopted only after internal review - e.g., in the ARIN region, ratified by the Board who is (all but one) elected by designated representatives of the membership. If 60 people smoking a controlled substance voted for an unwise policy I believe checks and balances would kick in before something regretful happened. Bad policies may get through - but not because a majority of people who happened to find the right hotel room. Second point, the RIR polices try hard, but don't always succeed, in staying away from the routing tables. Within ARIN, there is a special sensitivity to that - the ISP participants try hard to make sure that ARIN dictates nothing with respect to the routing table. E.g., recently a policy went away from recommending /56 allocations to a certain class of customers to saying that ARIN would measure utilization (for the purposes of granting more space) base on /56 deployment. Any statement regarding how an ISP (LIR) is supposed to run is being replaced by statements focusing only on what the RIRs ought to do, and that is stewardship of the numbers. I would encourage anyone that is concerned about there being five separate RIR policy processes and yet only one global routing table to take time to understand the dynamics of the situation before drawing conclusions. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Iljitsch van Beijnum wrote: However, geographic addressing could give us aggregation with provider independence. Brian E Carpenter wrote: You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. The problem with geo PI aggregation is expectations: if we set any aggregation expectations it won't fly because too many people have legitimate concerns about its feasibility. Personally I think that some gains are possible, but I'm not sure these gains will offset the amount of work required. My $0.02 about geo PI: a strategy change is needed. Instead of presenting geo PI as the solution that would give PI without impacting the routing table (this will not fly because there are too few believers and too many unknowns), present it as the icing on the cake of a comprehensive non-geo PI proposal. Michel Py wrote: That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. Eliot Lear wrote: I think we bite the bullet and go to IPv6. I just rubbed my desktop lamp and I regret to report that no genie came out of it to grant your wish. Screwing around with Class E address space at this late date is counterproductive. Not screwing around with it means more dirty tricks and more double NAT. IMHO the strategy of keeping class E reserved hoping that it will accelerate the deployment of v6 is futile. Iljitsch van Beijnum wrote: [ARIN PI policy] and now just as these efforts are getting close to paying off (shim6) a small group of people decides to throw caution in the wind and adopt a policy that opens the door to exactly the problems the IETF has been working so hard to avoid. These people are tired of hearing the broken record getting close to that they heard consistently for the last 10 years. Kevin Loch wrote: In case you (IETF) didn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. This failure of leadership from the IETF to provide a roadmap for a viable alternative to PI is a factor in the support for going with the current technology. I have to agree with Kevin here. Michel. A little late and off-topic: Iljitsch van Beijnum wrote: Peer-to-peer isn't a good example, because of the high built-in redundancy. Even someone who can only set up outgoing sessions can run BitTorrent without too much trouble because there are plenty of peers without NAT or portmappings of some kind (manual, uPnP or NAT-PMP) that can receive the incoming sessions. When the sessions are up, traffic can flow both ways. Technically speaking you are correct (this is called tit-to-tat I believe), but it does not work in the real world, reason being UL/DL ratios. Many interesting (use your own definition of it) torrent sites have dedicated trackers that enforce ratios; relying on the mechanism you describe can never achieve a UL:DL of 1. I do acknowledge that there are scores of leechers out there, but most of them sooner or later will open the ports in order to be able to seed completed torrents and up their ratio. Demographics show large number of teens who are technically savvy enough to get into the Web interface of their NAT box with admin/admin and open the ports. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 04/14/06 at 11:05am -0700, Michel Py [EMAIL PROTECTED]: Iljitsch van Beijnum wrote: However, geographic addressing could give us aggregation with provider independence. Brian E Carpenter wrote: You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. The problem with geo PI aggregation is expectations: if we set any aggregation expectations it won't fly because too many people have legitimate concerns about its feasibility. Personally I think that some gains are possible, but I'm not sure these gains will offset the amount of work required. I agree, especially in the near term. Aggregation is not required right now, but having the *ability* to aggregate later on is a prudent risk reduction strategy if today's cost to do so is minimal (as I think it is). My $0.02 about geo PI: a strategy change is needed. Instead of presenting geo PI as the solution that would give PI without impacting the routing table (this will not fly because there are too few believers and too many unknowns), present it as the icing on the cake of a comprehensive non-geo PI proposal. That's exactly what I'm pushing for. I'm in the process of brainstorming with other interested parties (and potential co-authors) to put together an ARIN public policy proposal that directs ARIN to assign PI netblocks in a regular fashion instead of the current random (chronological) fashion used for IPv4. As I stated above, I don't think aggregating is necessary or wise just yet, but I think that setting things up now, to make it possible to do so later if needed, is wise and prudent, and can be done with little or no additional complexity (cost). -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Kevin Loch [EMAIL PROTECTED] Nobody in that room would have supported a policy they actually believed would blow up the Internet. Who was in the room, BTW? How many of those 60 were from ISP's? Also, does that group have any commitments from ISP's (particularly the large global backbones) to carry these PI addresses? (I assume the group is expecting that PI addresses will be supported by the routing, not by some as-yet-undefined other mechanism.) Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 04/14/06 at 2:17pm -0400, Noel Chiappa [EMAIL PROTECTED] wrote: From: Kevin Loch [EMAIL PROTECTED] Nobody in that room would have supported a policy they actually believed would blow up the Internet. Who was in the room, BTW? How many of those 60 were from ISP's? Noel, Jason had the chair ask how many folks in the room were in the Default Free Zone, and 20 people raised their hands. So from that I conclude at the very least that 14 of those 20 did not oppose the PI proposal. I suspect a number of them, like myself, actually supported the proposal as a good balance between the need for workable multihoming and the desire not to pass a PI for everyone policy that would explode the routing table. Bear in mind that the number of IPv4 PI blocks ARIN has given out is rather small, and there's little reason to think that will change in the near term. Also, does that group have any commitments from ISP's (particularly the large global backbones) to carry these PI addresses? (I assume the group is expecting that PI addresses will be supported by the routing, not by some as-yet-undefined other mechanism.) I suspect they will indeed be accepted. At least initially, all the transit providers I know of will accept such routes from their customers, and I suspect they will begin accepting them from their peers as well as multihoming enterprises demand it. -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Fri, 2006-04-14 at 14:17 -0400, Noel Chiappa wrote: From: Kevin Loch [EMAIL PROTECTED] Nobody in that room would have supported a policy they actually believed would blow up the Internet. Who was in the room, BTW? How many of those 60 were from ISP's? Also, does that group have any commitments from ISP's (particularly the large global backbones) to carry these PI addresses? (I assume the group is expecting that PI addresses will be supported by the routing, not by some as-yet-undefined other mechanism.) I guess actually that the larger ISP's are not too happy about PI space in general, as with the Aggregate system they can nicely lock-in customers. As for global backbones, check GRH (http://www.sixxs.net/tools/grh/) and look at the amount of /48's and up seen in the routing tables and which transits are providing these in BGP today. Most, if not all, do this thus this will pose no problem whatsoever. Let's see how it all will take of, when GRH shows a large increase in new allocations we'll notice quickly if this is a success or not. We'll max out the 16-bit ASN space first anyhow ;) In the very very very long run, your undefined mech, we might end up using these PI /48's for 'identifiers', using the upstream's /48 as the locator space. No renumbering will thus be required, only some border changes, and the tricky bit: a signaling protocol for notifying the other end who we are so they can map it back to the PI /48. IHMO that will become a real solution for many problems. Announcing multiple prefixes and using source-address selection for instance is far from pretty. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Michel Py wrote: Iljitsch van Beijnum wrote: However, geographic addressing could give us aggregation with provider independence. Brian E Carpenter wrote: You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. The problem with geo PI aggregation is expectations: if we set any aggregation expectations it won't fly because too many people have legitimate concerns about its feasibility. Personally I think that some gains are possible, but I'm not sure these gains will offset the amount of work required. My $0.02 about geo PI: a strategy change is needed. Instead of presenting geo PI as the solution that would give PI without impacting the routing table (this will not fly because there are too few believers and too many unknowns), present it as the icing on the cake of a comprehensive non-geo PI proposal. The best possible way to prevent IPv6 is give prefix::1 to somebody in Newyork, prefix::2 to somebody in Kapstadt, prefix::x to Newyork again ... and wait for the routers to crash because of memory exhaustion. Next wait for somebody to build routers with Gigabyte memory and wait for them to find an entry. If it really can find it you might try to retract and renew it in 2 hour intervalls. I am shure you will bring them down :) Michel Py wrote: That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. Eliot Lear wrote: I think we bite the bullet and go to IPv6. I just rubbed my desktop lamp and I regret to report that no genie came out of it to grant your wish. Screwing around with Class E address space at this late date is counterproductive. Not screwing around with it means more dirty tricks and more double NAT. IMHO the strategy of keeping class E reserved hoping that it will accelerate the deployment of v6 is futile. Iljitsch van Beijnum wrote: [ARIN PI policy] and now just as these efforts are getting close to paying off (shim6) a small group of people decides to throw caution in the wind and adopt a policy that opens the door to exactly the problems the IETF has been working so hard to avoid. These people are tired of hearing the broken record getting close to that they heard consistently for the last 10 years. We already have a solution. IPv9 TUBA China has deployed it already. TUBA is the only way for both the USA and China each of them to have 75% of all ip addresses. Every country will have 75% of all ip addresses. There is no way to prevent this because there is no better way for total control and censorship. And everybody can keep and run his old IPv4 stuff. No need to learn semething new. Dictators will love it. They even will pay for it. They can, because it is us who will pay the bill finally. Kevin Loch wrote: In case you (IETF) didn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. This failure of leadership from the IETF to provide a roadmap for a viable alternative to PI is a factor in the support for going with the current technology. I have to agree with Kevin here. Michel. A little late and off-topic: Iljitsch van Beijnum wrote: Peer-to-peer isn't a good example, because of the high built-in redundancy. Even someone who can only set up outgoing sessions can run BitTorrent without too much trouble because there are plenty of peers without NAT or portmappings of some kind (manual, uPnP or NAT-PMP) that can receive the incoming sessions. When the sessions are up, traffic can flow both ways. Technically speaking you are correct (this is called tit-to-tat I believe), but it does not work in the real world, reason being UL/DL ratios. Many interesting (use your own definition of it) torrent sites have dedicated trackers that enforce ratios; relying on the mechanism you describe can never achieve a UL:DL of 1. I do acknowledge that there are scores of leechers out there, but most of them sooner or later will open the ports in order to be able to seed completed torrents and up their ratio. Demographics show large number of teens who are technically savvy enough to get into the Web interface of their NAT box with admin/admin and open the ports. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Scott Leibrand [EMAIL PROTECTED] the desire not to pass a PI for everyone policy that would explode the routing table. Interesting that you should mention that, because there's zero technical differentiation between PI space and portable addresses. So I have to wonder if this initiative will raise the pressure from users for portable addresses. PS: From: Kevin Loch [EMAIL PROTECTED] I find this comment extremely offensive. ... Your implication that the participants were either uninformed or diddn't care about the consequences is completely off base. There's a certain deep irony here, because PI-addresses have been considered at length in the IETF in at least two different WG's - CIDR-D and Multi-6. Both rejected them after extensive discussion. Nevertheless, a policy-making body has seen fit to ignore that, and make an engineering decision to deploy PI-space. It's hard to read that decision any other way than to have it imply that the decisions in those WG's were technically uninformed. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Jason had the chair ask how many folks in the room were in the Default Free Zone, and 20 people raised their hands. So from that I conclude at the very least that 14 of those 20 did not oppose the PI proposal. its a bit harder to say than that - the 2nd question (how many from default free ISPs) was done asking only one person per default free ISP to rase their hand - the hands showed that there were one or more reps from 20 default free ISPs in the room. Since a number of organizations sent more than one person the 14 Thomas mentions is the low end of the number of the 60 that were from default free ISPs since there was no one-hand-per-isp limit on the 1st show of hands. in fact - most of the people in the room were from ISPs of one size or another Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
At 15:13 -0400 4/14/06, Noel Chiappa wrote: There's a certain deep irony here, because PI-addresses have been considered at length in the IETF in at least two different WG's - CIDR-D and Multi-6. Both rejected them after extensive discussion. Can you point to documents that give the results of this? (Please don't cite mail archives, following threads is not very efficient.) If the reasons for the rejection are obscure, the uninformed will be likely to stay that way. Nevertheless, a policy-making body has seen fit to ignore that, and make an engineering decision to deploy PI-space. It's hard to read that decision any other way than to have it imply that the decisions in those WG's were technically uninformed. It's hardly an engineering decision. The sense was that without PI space, IPv6 will remain in a state that will not get it deployment experience. Having (personally) sat through the discussions at ARIN, RIPE, and APNIC, and having seen IPv6 grown in the IETF, I wouldn't characterize the anything as uninformed. The debate between 1) what happens to router tables with PI prefixes, 2) what happens when the protocol is crimped into a comfortable-to-operate fashion, and 3) what customers are will to bear, has been raging for more than a year. It's plain to see that PI space threatens to blow up routing. It's plain to see that IPv6 is supposed to allow for end-to-end flexibility. It's plain to see that customers no longer want to be tied to ISPs. My personal take is that IPv6 answers to a set of requirements devised 10 years ago and that no longer captures all the needs of the Internet. Route aggregation is good, but it relies on business assumptions that are unrealistic. Further, layer violations have become rampant, even if they are architecturally distasteful, they have become part of the operations landscape. In today's Internet, an end user whose cash flow depends on the network will be willing to rely on one provider, nor be willing to be locked into any set of providers over time. (Note that providers are the least financially stable players in the game.) Even if you have two providers today - what if they merge? I've known many who thought they had redundant paths, only to see that through mergers on the other side, all they had was on the same fiber. Many times customers walk because of business decisions, as in disputes over billing practices. This was added to a comment I had made within ARIN some time back. The moral is that an assumption that address assignments/allocations from RIR to LIR to subLIR to user isn't universally loved. Renumbering is not pleasant. Renumbering IPv6 style (prefix from the infrastructure, suffix from something else) isn't as promised thanks to things like firewall rules and other in-network beasts that configure addresses. You can say that these middle boxes don't belong, but try running an enterprise network without them. (I haven't been without a firewalled and/or NATted address since 1996, even through different employers.) Before IETF'ers start pointing fingers at uniformed decisions of other groups, it's worth asking ourselves where the misinformation comes from and, possibly, whether what has been developed is still relevant. I hear folks saying the IPv6 has bigger addresses and there's no other option, so we might as well go to IPv6. Is that all it comes to, 96 more bits than v4 and the only game in town? (I ask rhetorically.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Michel Py wrote: My $0.02 about geo PI: a strategy change is needed. Instead of presenting geo PI as the solution that would give PI without impacting the routing table (this will not fly because there are too few believers and too many unknowns), present it as the icing on the cake of a comprehensive non-geo PI proposal. Scott Leibrand wrote: That's exactly what I'm pushing for. I'm in the process of brainstorming with other interested parties (and potential co-authors) to put together an ARIN public policy proposal that directs ARIN to assign PI netblocks in a regular fashion instead of the current random (chronological) fashion used for IPv4. As I stated above, I don't think aggregating is necessary or wise just yet, but I think that setting things up now, to make it possible to do so later if needed, is wise and prudent, and can be done with little or no additional complexity (cost). Feel free to re-use this: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Which is by no means the only way to go. That being said, Noel Chiappa wrote: There's a certain deep irony here, because PI-addresses have been considered at length in the IETF in at least two different WG's - CIDR-D and Multi-6. Both rejected them after extensive discussion. Nevertheless, a policy-making body has seen fit to ignore that, and make an engineering decision to deploy PI-space. It's hard to read that decision any other way than to have it imply that the decisions in those WG's were technically uninformed. Noel has a point here. This certainly will be percept as ARIN handling matters that belong to the IETF. It does not mean that the IETF was right, though. breaking news The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Michel sed breaking news The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html note the move it to last call teh last call (very much like teh IETF last call) will be on the ARIN ppml - see http://www.arin.net/policy/index.html for information on the policy process and instructons on how to subscribe to the mailing list if you have an interest in this topic please do join the list and the discussions - silence is seen as agreement Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
now is the time to comment if you want to - a lack of comment means agreement from ARIN Member Services The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites and has determined that there is community consensus in favor of the proposal, as edited below, to move it to last call. The AC added the final sentence to section 6.5.8.2. as shown below. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on April 11, 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_1.html Comments are encouraged. All comments should be provided to [EMAIL PROTECTED] This last call will expire at 12:00 Noon, Eastern Time, April 28, 2006. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Fri, 14 Apr 2006 15:53:03 -0400, Edward Lewis [EMAIL PROTECTED] wrote: It's hardly an engineering decision. The sense was that without PI space, IPv6 will remain in a state that will not get it deployment experience. This is a very important point. Without expressing an opinion on the proposal itself, I'll note that this answers one very important question: why should an organization deploy v6? The ability to secure PI space is a very powerful answer for some companies. (Some people will say and that's why they use NAT today. True -- but companies who use 1918 space and NAT get into trouble when they create private interconnects to other such companies -- or, worse yet, to a group of other such companies that are working together on something. Now, if they could qualify the locally-unique address with a site prefix it would be easier, but that's more or less 8+8 which is what IPv6 addressing should have been from the beginning... I digress -- that issue was hotly debated when IPv6 was being created, and though some of us were strongly in favor of it others were strongly opposed. There was simply no consensus to do the right thing. Hmm, my biases are showing...) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Noel Chiappa wrote: the desire not to pass a PI for everyone policy that would explode the routing table. Interesting that you should mention that, because there's zero technical differentiation between PI space and portable addresses. So I have to wonder if this initiative will raise the pressure from users for portable addresses. Depending on how they actually get defined and handed out, portability could be one outcome. Scott a few others of us are working on the next step which would put limits on the extent of that portability (ie: it is manageable to deal with porting between providers within a city, but not between cities). PS: From: Kevin Loch [EMAIL PROTECTED] I find this comment extremely offensive. ... Your implication that the participants were either uninformed or diddn't care about the consequences is completely off base. There's a certain deep irony here, because PI-addresses have been considered at length in the IETF in at least two different WG's - CIDR-D and Multi-6. Both rejected them after extensive discussion. Nevertheless, a policy-making body has seen fit to ignore that, and make an engineering decision to deploy PI-space. It's hard to read that decision any other way than to have it imply that the decisions in those WG's were technically uninformed. No, those groups couldn't see the forest for the trees. They were absolutely technically informed, but completely unwilling to listen to the big picture political reality. This thread is arguing that this policy decision has the opposite problem, but in fact it does not. It is an attempt to get in front of what is a growing wave of demand to head off an outright pronouncement from outside the community which will result in number portability. By moving first we can put in enough technical structure to contain foreseeable problems, while if we wait we will be forced into a quick and dirty random approach that we all know will fail. I was not happy with the policy as worded, but willing to live with it for now as a first step to really fixing the problems facing edge networks. The locator/id split approach is a nice thing to work on, but it will take more than a decade to deploy even if people agree to the result. The fundamental problem is that most of the meager security architecture we do have relies heavily on those being aligned. If they are split all of the firewall silicon will have to be rebuilt and new mechanisms for tracking the identity in flight will have to be developed. Of course none of that work will start until the non-deployable shim approach has proven itself viable. Add to that the fact that it moves any semblance of control the ISP thought they had to the end node and you will find that as they already have said they will do all they can to block its adoption. The IETF has consistently refused to acknowledge that prefixes independent of PA are necessary. The intense focus on maximum aggregation at all costs is just not viable for end customers. A broken routing system is equally not viable, but there is a middle ground that gets messy because it does not have simple solutions without constraining topology. These are all trade-offs, and the ISPs are demanding unconstrained topology with a minimal routing table. That set of requirements leads to efforts like shim6. The end sites are demanding autonomy with a stable routing system. That set of requirements leads to structured allocations and topology constraints. Both sides will have to give, but it should be noted that the ones holding the money are the end sites. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Kevin Loch wrote: Iljitsch van Beijnum wrote: I'm not saying that these people expected the internet to melt down by supporting this policy, but that's exactly the problem. Within the IETF, we've been working long and hard to find a way to allow for multihoming that we KNOW won't melt the internet, and now just as these efforts are getting close to paying off (shim6) In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. As shim6 effort was initiated by stupid majority ignoring various operational and other issues that I'm glad it is treated properly by the operational community. Steven M. Bellovin wrote: Now, if they could qualify the locally-unique address with a site prefix it would be easier, but that's more or less 8+8 which is what IPv6 addressing should have been from the beginning... I digress -- that issue was hotly debated when IPv6 was being created, and though some of us were strongly in favor of it others were strongly opposed. There was debate. But, 8+8 was rejected without any discussion or reasoning. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Sat, 15 Apr 2006, Masataka Ohta wrote: There was debate. But, 8+8 was rejected without any discussion or reasoning. Could someone tell me where I can read about 8+8? -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
