Re: And Now for Something Completely Different (was Re: IPv6 news)
Randy; we are living on Earth with small size (only 6,000 km in radius), so we will never see unlimited grouth in multihomed networks. It is not a problem. We are not building Internet for the whole universe. Good old Moore can deal with our planet very well. I repeated many times - IPv6 idea of changing multihome approach is VERY BAD and will not survise for more that 1 - 2 years. (if IPv6 survive at all, which I have many doubts about). - Original Message - From: Randy Bush [EMAIL PROTECTED] To: Daniel Golding [EMAIL PROTECTED] Cc: Tony Li [EMAIL PROTECTED]; Fred Baker [EMAIL PROTECTED]; Per Heldal [EMAIL PROTECTED]; nanog@merit.edu Sent: Monday, October 17, 2005 2:16 PM Subject: Re: And Now for Something Completely Different (was Re: IPv6 news) There is a fundamental difference between a one-time reduction in the table and a fundamental dissipation of the forces that cause it to bloat in the first place. Simply reducing the table as a one-off only buys you linearly more time. Eliminating the drivers for bloat buys you technology generations. If we're going to put the world thru the pain of change, it seems that we should do our best to ensure that it never, ever has to happen again. That's the goal here? To ensure we'll never have another protocol transition? I hope you realize what a flawed statement that is. tony probably did not think about it because that's not what he said at all. he was speaking of routing table bloat, not transitions. and he was spot on. randy
Re: IPv6 news
We do not think, that _it wil be IPv6_. IPv6 is a good example of _second_ system, and do not looks as _succesfull_ for now. And it is not definitely _LAST PROTOCOL_. It _can be_ IPv6, true. But it can be other protocol (or just workaround for IPv4, as we had CIDR and CLASSLESS) instead. - Original Message - From: Gregory Edigarov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 17, 2005 3:42 AM Subject: Re: IPv6 news Just my 5 cents to the topic: Don't you all think that IPv6 would not be so neccessary for the very long time yet, if the IPv4 allocation scheme would be done right from the very very beginning? If the allocation policies would be something like the ones for ASn's. I.e. when you ask for IP space allocation you must be in the need to set your own routing policies. In any other cases you should use private network space with only one IP shown outside the network. Yes, this would be a headache for some appplications like IP telephony, but, I don't see any problems in making the _correct_ protocols so they could work through NAT. As what I see now is that a very large address blocks are allocated to large companies, what companies do with them? Correct, they ae installing them as IP's of workstations, when, if IPs would be treated as a very valuable resource from the beggining, they would have to use at max /24 (well, may be 2 or three /24) for access routers. When they are proposing /48 allocation scheme for IPv6 they must be out of their mind, because in case such allocation will be ineffect, IPv6 address space will end shortly too. Again, IPv6 is creating more problems then solve. Better solution would be to freeze IPv4 allocation, then force big IPv4 users to return the addresses to the public pool, and start allocation from the white piece of paper, doing the things right. -- With best regards, GRED-RIPE
Re: IPv6 news
On 24/10/05, Alexei Roudnev [EMAIL PROTECTED] wrote: We do not think, that _it wil be IPv6_. IPv6 is a good example of _second_ system, and do not looks as _succesfull_ for now. And it is not definitely _LAST PROTOCOL_. enter jim fleming (or those chinese guys, more recently) with ipv9 srs
Re: IPv6 news
We do not think, that _it wil be IPv6_. IPv6 is a good example of _second_ system, and do not looks as _succesfull_ for now. And it is not definitely _LAST PROTOCOL_. enter jim fleming (or those chinese guys, more recently) with ipv9 No, enter the National Science Foundation... http://www.nsf.gov/cise/geni/ Jim Fleming's idea wasn't all that crazy and some people are looking at similar partitioning schemes to make IPv6 multihoming practical. The IPv9 idea from China had nothing to do with IP, it was just a catchy marketing name for yet another domain naming scheme like RealNames. There really is serious, non-crazy research work going on to make a better replacement for the Internet Protocol. And Dave Clark, author of this interesting document on Internet routing: http://www.networksorcery.com/enp/ien/ien46.txt has recently been going around giving talks on fundamental re-architecting the Internet. At MIT he is a director of the CFP which is getting NSF GENI grant money to explore this: http://cfp.mit.edu/groups/internet/internet.html This is not the 1990's any more. ISO/CLNP has gone away. ATM has been embraced in MPLS. PSTN is being embraced in VoIP such as the British Telecom 21CN initiative. What was crazy yesterday, is thinkable today. In the end, IPv6 may be able to incorporate enough of these new ideas to continue as the last protocol. But we don't know that yet. --Michael Dillon
Re: And Now for Something Completely Different (was Re: IPv6 news)
Obviously if the RIRs contacted the folks responsible for a given block and were provided justification for its continued allocation, then it should not be reclaimed. On the other hand, folks sitting on several class Bs and not using them could have their blocks reclaimed trivially; ditto for companies that no longer exist. The last is certainly doable without much risk of controversy. This is exactly what the Internic did many years ago. I, like many other people, had registered a .com domain name at no cost. Then suddenly one day, the Internic said that I had to pay an annual subscription fee for this domain name. Like many others, I paid my fees. There were a few complaints about this but by and large people accepted the idea that you had to MAINTAIN a business relationship with the domain name registry in order to continue using a domain name. For some reason, this concept of MAINTAINING a business relationship with the registry, has not caught on in the Regional IP Registry arena. Of course, a large number of IP address users do pay annual membership subscription fees to ARIN (or other RIRs) but not all. And the RIRs seem unwilling to withdraw services (in-addr.arpa) from those who do not MAINTAIN a business relationship. However, one of the articles referred to recently in this thread (I forget which) showed that even if we reclaimed all of the address space that is currently unannounced (in use or not), we'd buy ourselves a trivially short extension of the IPv4 address space exhaustion date. Considering the cost of performing the task, doing so seems rather pointless; our time would be better spent getting IPv6 deployed and either reengineering the routing system or switching to geo addresses. Probably this article from the Cisco IP Journal which has been mentioned a few times in the past week. http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html From the viewpoint of avoiding an addressing crisis and avoiding a v6 transition crisis, your advice is sound. However, from the viewpoint of having a sensibly functioning RIR system, I think we still need to deal with two issues. One is that the holders of IP address allocations should be required to maintain a business relationship with the RIR or lose the right to use those IP addresses. The other is that the RIRs need to fix the whole debacle that is whois and routing registries. There should be no need for 3rd party bogon lists. The RIR's should publish an authoritative registry, rooted in IANA, that covers the entire IPv4 and IPv6 address spaces. An operator faced with receiving a new BGP announcement should be able to query such a registry and find out whether or not the address block is allocated, who it is allocated to, and whether that party intends to announce that exact block size from that exact AS number. --Michael Dillon
Re: IPv6 news
Again, phone numbers and their portability can and should not be compared with the IP address portability issues. They're very different animals. That's your elephant. My elephant looks different. Phone numbers and IP addresses are exactly the same. They are numbers used to identify the location to which I want to connect. They are allocated from a numbering plan with a fixed number of digits/bits. The numbering plans are running out of space. One solution being used in both telephony and IP networks, is to carve out smaller allocations (CIDR/pooling) to make the number plan last longer. Sometimes the fact that phone networks are like pink elephants, not grey, is important. Other times The grey elephant keepers watch the behavior of pink elephants to learn about elephants in general. I never suggested that one could mindlessly apply techniques from the telephony world in the IP network world. But we can understand our problems better if we compare them to the telephony world, the ATM world, and maybe even the world of Advanced Data Path Routing Techniques for Three Tier KVM Networks? http://www.tron.com/i032.html There are also lessons to be learned outside the world of telecoms networks by studying the distribution of market towns in ancient Mesopotamia or the crystalline lattice of the skeletons of diatoms and dinoflagellates. --Michael Dillon
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Tue, 2005-10-18 at 15:52 -0700, David Conrad wrote: Hmm. Are the aliens who took the _real_ IETF and replaced it with what's there now going to give it back? :-) Sure they'll hand it back ... when there is no more money to be made from IETF-related technology and politicians no longer feel it's interesting ;) Otoh, the IETF is a function of its partitipants. Businesses today have such fear of competitors and interllectual-propery-issues that they hardly can cooperate on anything. Thus, the number of technology reasearchers available to partitipate in public forums is just a fraction of what it was 20 or 30 years ago. If enough people find IETF unworkable, wouldn't they just form an alternative forum that would be to the IETF what the IETF has been to ITU? //Per
Re: IPv6 news
On Wed, 19 Oct 2005, [EMAIL PROTECTED] wrote: Again, phone numbers and their portability can and should not be compared with the IP address portability issues. They're very different animals. That's your elephant. My elephant looks different. Survey says... BZT. Read about SS7 LNP implementation before speaking, please. They are very different creatures. Something that resembles telephony LNP will not scale to the quantity of micro-streams currently used by WWW applications. The reason it works (FSVO works) for telephony is because, unlike TCP streams, telephone circuits are comparatively large streams with much longer keepalive times. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: IPv6 news
Survey says... BZT. Yaur argument is fallacious. Read about SS7 LNP implementation before speaking, please. I never said anything about SS7 implementation of LNP. They are very different creatures. Something that resembles telephony LNP will not scale to the quantity of micro-streams currently used by WWW applications. The reason it works (FSVO works) for telephony is because, unlike TCP streams, telephone circuits are comparatively large streams with much longer keepalive times. This is a strawman argument. I certainly agree with what you have said about TCP streams versus calls on the PSTN but that has nothing whatsoever to do with what I was talking about. Why is it that whenever people suggest that the IP networking world can learn from the experience of the telephony world, some people assume that the proposal is to imitate the telephony world in every detail? The fact is that both worlds are completely different in the details. But these different details lead the telephony world to make different technology choices and then gain real world operational experience with those choices. As the IP world evolves and changes (remember this started with a discussion of IPv6) it is possible that some of the hard-won experience from the telephony world can be applied in the IP world. No doubt it will be necessary to implement things differently in the IP world because of the details. But it is crazy to reject the hard won experience of the telephony world wholesale just because you worship at the temple of IP. In any case, the telephony world owns and runs the Internet today. Bellhead and nethead arguments belong in the past. Today's bellheads are running IP networks and VoIP along with all the PDH, SDH, X.25, SS7, ATM, Frame Relay etc. --Michael Dillon
Re: IPv6 news
On Oct 19, 2005, at 9:39 AM, [EMAIL PROTECTED] wrote: Why is it that whenever people suggest that the IP networking world can learn from the experience of the telephony world, some people assume that the proposal is to imitate the telephony world in every detail? Seems to me to be a species of the broader attitude among some that any analogy or reference to anything outside of the IP world is inherently flawed. On this view, there is no such thing as a good analogy or comparison. All are equally bad and misleading. Full stop. Perhaps an ungenerous observation, but this is exactly the sort of attitude that one would expect of narrow experts in the field who have no knowledge whether and how it might resemble or relate to anything else... Private editorial ends. TV
Re: non-provider aggregation, was: IPv6 news
On 17-okt-2005, at 14:18, Jeroen Massar wrote: Another alternative is to force-align allocation and topology in some way /other/ than by Providers (geographical allocation in whatever hierarchy, IX allocation, whatever), such that networks were easily aggregatable. Lots of objections though (the providers and geography don't align one though is ultimately slightly bogus, because with non-provider-aligned allocation policies in place it would be in providers interests to align their peering to match the allocation policy). The current assumption is that all aggregation happens on ISP. Replacing that with the assumption that all aggregation will happen on geography isn't all that useful. The important thing here is that you can aggregate on pretty much anything: hair color, router vendor, market capitalization, you name it. In the end, you always aggregate on the way the addresses are given out, which may or may not be meaningful. Aggregating on provider is the most powerful because the aggregate leads you fairly directly to the place where you need to go as long as the destination is single homed. But suppose at some point we end up with a routing table consisting of 10 million PI blocks from multihomers and some unimportant stuff that disappears in the error margin (i.e., those 5000 IPv6 /20s for huge ISPs). Also suppose that it's possible to build a reasonably cost effective router that handles 1M routes, but this router technology doesn't scale to the next order of magnitude. The simple solution is to build a big router that actually consists of 11 small ones: 10 sub-routers that each hold one tenth of the global routing table, and an 11th sub-router that distributes packets to the sub-router that holds the right part of the global routing table. So sub-router 1 has the part of the global IPv6 routing table that falls within 2000::/6, sub-router 2 has 2400::/6, sub-router 3 2800::/6 and so on. So we're aggregating here, but not really on something. This has the unpleasant side effect that we now have to spend 11 times more money to keep a 10 times larger routing table. Alternatively, we can trade hardware costs for bandwidth, by having 10 routers that are present in the network anyway each handle part of the global routing table. So a router in Boston would handle everything under 2000::/6, a router in Chicago 2400::/6, one in Seattle 2800::/6 and so on. Obviously this isn't great if you're in Boston and your address is 2800::1, but it doesn't require additional hardware. This scheme can be optimized by aligning addressing and geography to a reasonable degree. So if you're in Boston, you'd get 2000::1 rather than 2800::1. But that doesn't magically shrink the routing table to one route per city. In the case of Boston, it's likely that the source and destination ISPs for a certain packet don't interconnect within the city itself. So someone sitting in New York probably won't see much difference: he or she still has to carry all the routes for multihomers in Boston. Some of these will point to her own customers in Boston, some to peers in New York, others to peers in DC, and so on. However, as distance increases the difference between this packet needs to go to a customer in Boston, this packet needs to go to a peer in New York and this packet needs to go to a peer in DC becomes meaningless, so it's possible to replace a large number of individual routes by a single city or region aggregate. So even without magic interconnection dust, aggregation based on geographical addressing can have benefits. However, it has several limitations. An important one is that early exit routing is replaced by late exit routing. Also, when someone multihomes by connecting to ISPs in Miami and Tokyo you don't get to aggregate. But worst case, you just don't get to aggregate, either because people multihome in weird ways, for traffic engineering reasons or because of lack of interconnection (however as interconnects become really sparse the savings go up again) so you're no worse off than today. But if and when the routing tables explode and routers can't keep up, having geographical addressing in place for multihoming allows for a plan B that we don't have today. I think we need a researcher to sit down and figure out exactly what this would look like in a sample city and a sample national provider. There has been quite some research on it, there where ideas, there was even talk of a vendor going to implement it, but it never happened. It won't work because of cash reasons (read: telco/transit don't want it) I'm not familiar with that... Do you have a reference? For your 'city data' check: http://unstats.un.org/unsd/demographic/default.htm or for pre-processed files: http://arneill-py.sacramento.ca.us/ipv6mh/ under Geographical data. Note that this page hasn't been updated in more than
Re: non-provider aggregation, was: IPv6 news
Hi, On Wed, 19 Oct 2005, Iljitsch van Beijnum wrote: On 17-okt-2005, at 14:18, Jeroen Massar wrote: Another alternative is to force-align allocation and topology in some way /other/ than by Providers (geographical allocation in whatever hierarchy, IX allocation, whatever), such that networks were easily aggregatable. Lots of objections though (the providers and geography don't align one though is ultimately slightly bogus, because with non-provider-aligned allocation policies in place it would be in providers interests to align their peering to match the allocation policy). Iljitsch, fix your attributions, that's my text. (Jeroen might not appreciate you attributing my incoherent mumblings to him). The current assumption is that all aggregation happens on ISP. Replacing that with the assumption that all aggregation will happen on geography isn't all that useful. That's a bold assertion. You'll have to show why because the fact is that that is how other networks achieve portability (after which multi-homing is easy). Fact is I can change my fixed phone provider and my mobile phone provider, but I can't change my ISP without some pain (and I'm a /tiny/ site ;) ). The important thing here is that you can aggregate on pretty much anything: hair color, router vendor, market capitalization, you name it. Hmm, no ;). In the end, you always aggregate on the way the addresses are given out, which may or may not be meaningful. No, you have to aggregate on topology. Aggregating on provider is the most powerful because the aggregate leads you fairly directly to the place where you need to go as long as the destination is single homed. Sure. But it means you're tied to the provider (for that address at least). interconnect within the city itself. So someone sitting in New York probably won't see much difference: he or she still has to carry all the routes for multihomers in Boston. Some of these will point to her own customers in Boston, some to peers in New York, others to peers in DC, and so on. But at least, to the rest of the world, all the multihomers in Boston and New York have reduced down to just 2 routes. That's a significant step forward. (And eventually those ISPs back-hauling lots of very specific Boston customer prefixes to New York will figure out they should just peer in Boston and confine the very specific Boston routes there). limitations. An important one is that early exit routing is replaced by late exit routing. Can you expand on this? Also, when someone multihomes by connecting to ISPs in Miami and Tokyo you don't get to aggregate. Or, that entity just gets two prefixes, one for its Miami site allocated from the Miami area prefix and one for its Tokyo site allocated from the Tokyo area prefix. Really large networks with their own internal-transit across multiple areas for whom this would not work can just get a global prefix. But those kinds of networks are rare, a fraction of multi-homers. So it's still a step forward. really sparse the savings go up again) so you're no worse off than today. You're better off, because small/medium sites can be aggregated with all the other small/medium sites in their $AREA. The really large trans-$AREA networks are rare. Let's be honest, the reasons that make $AREA-allocated addresses and aggregation difficult are /not/ technical. ;) (Paul Jakma wrote something to the effect that I am involved with shim6 so that says something about other options. It doesn't, as far as I'm concerned. But shim6 is a worthy pursuit in its own right.) I said possibly is telling ;). But apologies for any presumption ;). regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: fortune: not found
Re: And Now for Something Completely Different (was Re: IPv6 news)
True enough, but unfortunately, it's not done in a way that we can make use of the identifier in the routing subsystem or in the transport protocols. The transport protocols, well they generally act on behalf of something which can do the lookup and supply transport with right address, as long the DNS server does not require who-where indirection ;). The transport protocols unfortunately need the identifier in the packet to demux connections. Tony
Re: IPv6 news
On Mon, Oct 17, 2005 at 11:39:37AM +0100, [EMAIL PROTECTED] wrote: Here, the suggestion is that netblocks should be allocated to cities, not to providers. Within I am a multihomed customer and my ISPs are in two different cities. What are my IP addresses going to be? This situation happens all the time, by the way. In fact, the closer you get to smaller, consumer grade connectivity, the more you will see backhauling below the network layer in providers' networks that will make this happen. -Phil
Re: IPv6 news
Here, the suggestion is that netblocks should be allocated to cities, not to providers. Within I am a multihomed customer and my ISPs are in two different cities. What are my IP addresses going to be? Your assumptions are flawed. I never suggested that there would be a flag day. I never suggested that geotopological addressing would work everywhere or solve all problems. I never suggested that we should turn off the existing provider aggregatable IP address allocations. I just suggested an alternative way of issuing addresses so that they are geotopologically aggregatable, not provider aggregatable. There are sufficient reserved addresses in the IPv6 address space to do this. We could start issuing geotopological netblocks and try it for 5 years or so to see whether it works better or not. In any case, you are located in Montreal which is such a major city that I expect any ISP selling service (geotopologically) in Montreal would use Montreal address space even if they backhauled at layer two to some other city. However, there will likely be lots of situations where people in small towns roughly equidistant from two cities will choose to multihome with links to separate cities. This will either have to be done using provider-aggregated addresses or by using addresses from one of the cities with a longer prefix inside that city's routing table to direct the traffic to the neighboring city. If this is suboptimal, it won't be by much considering that these are neighboring cities. I'm not suggesting any change to IPv6 stacks or to routing protocols. I'm just suggesting that we could allocate the same IPv6 addresses to operators in a way that allows geotopological aggregation rather than the existing provider aggregation. Combine this with local traffic exchange in every city and you have a more robust Internet with lower overall latency that will run with a smaller global routing table. I know that some individual operators, such as the one I work for, have very robust IP networks with low overall latency. But when we talk about the Internet, then we include all the private interconnects and public exchange points and tromboning of traffic due to peering issues, etc. --Michael Dillon --Michael Dillon
Re: And Now for Something Completely Different (was Re: IPv6 news)
check out The Landmark Hierarchy: A New Hierarchy for Routing in Very Large Networks; Paul Tsuchiya; 1989. great stuff... i have a hardcopy. is it online yet? Just google for landmark routing and you will find lots of papers and presentations that deal with the topic. If OSPF area boundaries were more fluid, rather like the period covered by a moving average... Of course, this might not be so nice if it was done across AS boundaries. --Michael Dillon
Re: IPv6 news
On Tue, 18 Oct 2005, william(at)elan.net wrote: I reread this and still don't see how geographical ip address allocation is going to work if typical customer connections are network-centric That's a today's operator view of customers though. Many customers view their network as being situated in one or more fixed geographic locations (not in terms of which provider gives them transit), which rarely change. (Road warriors just connect to HQ or their home site via VPN or whatever). and any large area has number of competitive access providers (unless you're fine with multiple providers announcing aggregate summary in anycast fashion). Yep, they'd have to. They'd also have to figure out the billing side of it for any traffic differentials. Essentially, when seen globally - the providers would service the geographic /area/, not the customers. When seen within this arbitrary area, you'd see routes for each customer and to which exact provider they'd have to go. Would also encourage peering generally to occur as close as possible to the arbitrary areas as possible, one suspects (so the providers own routing table wouldn't have to carry the detail further than needed). regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Between grand theft and a legal fee, there only stands a law degree.
Re: IPv6 news
Paul Jakma wrote: On Mon, 17 Oct 2005, Andre Oppermann wrote: We all know how well carrier phone number routing and number portability works, don't we? EWORKSFORME (and everyone else here). Took a good bit of very firm pressure from ComReg, the telecoms wathdog/regulator here, to overcome negative reaction from the operators though. We don't want them involved in Internet routing, do we? (There's no such pressure which could be applied on IP operators, but same processes essentially could be applied at least for IP connectivity at national regulatory levels at least - trade /32's at INEX, the IX here and figure out billing. If only ComReg had the authority.. ;) ). Do you have any idea how this works internally? Apparently not. Phone numbers are an interesting species. On a global level they are used for call routing. On a local level however it's not more than a DNS name mapping to some real on-net identifier. Unfortunatly anyone calling your ported mobile number from outside the mobile networks ends up with the number range holder (you former number range holder) who in turn has to forward the call to your current mobile operator. On a TDM network this works pretty OK as the quality parameters are standardized and fixed (64kbit transparent voice channel, call capacity, etc). Outgoing are not affected because the TDM network always sets up parallel in/out path's. The return channel for your outgoing call doesn't come back through your former mobile operator. Now compare this to the Internet and IP routing. See some little differences and diffculties here and there? Yea, I thought so. Conclusion: Applying the phone number portability to the Internet is broken by design. -- Andre
Re: IPv6 news
On Tue, 18 Oct 2005, Andre Oppermann wrote: We don't want them involved in Internet routing, do we? Which, POTS telco's or ComReg? :) The latter does a good job afaict. Do you have any idea how this works internally? Apparently not. I have had telco people vaguely explain some of the issues and abstracts of SS7 signalling involved in calls they were handling for me to me. Phone numbers are an interesting species. On a global level they are used for call routing. Yep. On a local level however it's not more than a DNS name mapping to some real on-net identifier. Within a telco? There's a myriad of ways to do it afaict. The case I know best though involved calls inbound to an operator specific prefix (there are a set of 4 or so major telco peering exchanges in Ireland, where the domestic and transit telcos /must/ be avilable for peering). The operator used custom software to map specific numbers to X.25 addresses (I forget the exact X.25 jargon) on their own network to deliver the calls to various locations on our network. Unfortunatly anyone calling your ported mobile number from outside the mobile networks ends up with the number range holder (you former number range holder) The operator's prefix, yes. who in turn has to forward the call to your current mobile operator. Yep. Outgoing are not affected because the TDM network always sets up parallel in/out path's. The return channel for your outgoing call doesn't come back through your former mobile operator. I didn't know that, but sounds exactly what you want. Now compare this to the Internet and IP routing. See some little differences and diffculties here and there? Yea, I thought so. There are huge differences in the details, obviously. The basic concepts though are at least interesting to consider, if not directly applicable to IP (technically at least - operationally/politically is another question): 1. Providers servicing these prefixes must peer and exchange the prefix information 2. Providers must be prepared to carry other providers traffic into the area 2a. The providers within the area have to figure out how to bill for the difference of this traffic. Conclusion: Applying the phone number portability to the Internet is broken by design. Right, cause phone number portability is up and running for several sets of prefixes in various regions across the world[1], so there's definitely nothing we can learn from them. ;) 1. Does the US have number portability anywhere? If so, that would be a /huge/ region, and very interesting to examine to see how they manage it. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Plan to throw one away. You will anyway. - Fred Brooks, The Mythical Man Month
Re: IPv6 news
Paul Jakma wrote: On Tue, 18 Oct 2005, Andre Oppermann wrote: On a local level however it's not more than a DNS name mapping to some real on-net identifier. Within a telco? No. Within a region. Normally area codes are a region. Sometimes entire country codes are a region in this sense. Depends on the size of the region/country though. In some cases there is even more than one area code for the same region. For every area code there is a 'default' carrier. Usually this is the incumbant. They've got the obligation to forward inbound calls to the true carrier of that particular number holder. However this only works if the target carrier has some kind of interconnect with said default carrier. On top of this forwarding doesn't come for free. Depending on my call volume with that area I have to look into direct termination of ported numbers. Usually the regulator or some party designated by the regulator runs a number portability registry with the true carrier information for every number. If I want to optimize my call routing I have to periodically synchronize the call routing tables on my switches with that registry. In a very competitive area this lead to 30-50% of all numbers being ported and thus showing up in my routing table. As we know from the Internet DFZ the routing table becomes very large. Fortunatly for the TDM network I have to do the routing table lookup only once when setting up the call, not for every voice sample. Thus I pay the lookup cost only once for x minutes of voice traffic. Very DNS like. And because of the area code hierarchy even more so. That's why number portability is normally only offered within the same area code or region. So you can't take your NY fixed line phone number to LA. Unless of course you have someone picking up the call in NY and transporting it to you in LA. For non-US mobile networks the number portability works the same. The mobile network(s) have got their own area codes. There's a myriad of ways to do it afaict. The case I know best though involved calls inbound to an operator specific prefix (there are a set of 4 or so major telco peering exchanges in Ireland, where the domestic and transit telcos /must/ be avilable for peering). The operator used custom software to map specific numbers to X.25 addresses (I forget the exact X.25 jargon) on their own network to deliver the calls to various locations on our network. You can forget that X.25 stuff. It's only used for SS7 message routing and doesn't have anything to do with call routing as such. The telco peering points is just a technicality. It's there just for optimization. Most regulators have set up an easy interconnection policy to prevent your favorite incumbant from offering 'peering' only on lands end. Outgoing are not affected because the TDM network always sets up parallel in/out path's. The return channel for your outgoing call doesn't come back through your former mobile operator. I didn't know that, but sounds exactly what you want. Sure. However this is the main difference between the TDM network and the Internet. Due to this fact many things work on the phone network like carrier pre-selection, phone number portability, etc., that do not work on an IP network. Now compare this to the Internet and IP routing. See some little differences and diffculties here and there? Yea, I thought so. There are huge differences in the details, obviously. The basic concepts though are at least interesting to consider, if not directly applicable to IP (technically at least - operationally/politically is another question): 1. Providers servicing these prefixes must peer and exchange the prefix information On the phone network the prefix information is not dynamically exchanged. There are number portability registries whose data you can download every night or so and then dump it into your own switch or IN platform. 2. Providers must be prepared to carry other providers traffic into the area Only one of them. The 'default' carrier. There are many phone networks and carriers carrier who do not have 100% coverage. 2a. The providers within the area have to figure out how to bill for the difference of this traffic. No. Usually the tariff is set by the regulator based on some fixed interconnection charge and network element usage. Conclusion: Applying the phone number portability to the Internet is broken by design. Right, cause phone number portability is up and running for several sets of prefixes in various regions across the world[1], so there's definitely nothing we can learn from them. ;) Well, we can learn from them that circuit switched networks are different than packet switched networks. Beyond that not much. 1. Does the US have number portability anywhere? If so, that would be a /huge/ region, and very interesting to examine to see how they manage it. See above for an explanation. To summarize the differences
Re: IPv6 news
On Tue, 18 Oct 2005, Andre Oppermann wrote: No. Within a region. Normally area codes are a region. Sometimes entire country codes are a region in this sense. Depends on the size of the region/country though. In some cases there is even more than one area code for the same region. Ah, yes, that I know. I thought maybe you were referring to number - GSM SIM IMSI mapping within a telco, or whatever is the equivalent for fixed-line. (How roaming is done is really interesting btw). snip interesting details said default carrier. On top of this forwarding doesn't come for free. Of course not. the call routing tables on my switches with that registry. In a very competitive area this lead to 30-50% of all numbers being ported and thus showing up in my routing table. Yep. Any geographic solution must consider that disaggregation will always tend towards 100%. As we know from the Internet DFZ the routing table becomes very large. However, it can be confined to that arbitrary area. That's why number portability is normally only offered within the same area code or region. So you can't take your NY fixed line phone number to LA. Unless of course you have someone picking up the call in NY and transporting it to you in LA. Yep, obviously ;). You can forget that X.25 stuff. It's only used for SS7 message routing and doesn't have anything to do with call routing as such. Ah, it was used for everything in that network actually - but that was a very very specialised telco network. (And they had started moving to IP when I last worked with them.) Outgoing are not affected because the TDM network always sets up parallel in/out path's. The return channel for your outgoing call doesn't come back through your former mobile operator. Sure. However this is the main difference between the TDM network and the Internet. Due to this fact many things work on the phone network like carrier pre-selection, phone number portability, etc., that do not work on an IP network. I'm not source how assymetric paths affect portability etc. Also, IP is well capable of that, and makes life easier. On the phone network the prefix information is not dynamically exchanged. Uhm, sure it is. There are number portability registries whose data you can download every night or so and then dump it into your own switch or IN platform. The number portability registries can be updated infrequently, yes. The telco prefix routing information however most definitely *is* routed dynamically. Maybe you don't have to participate in this routing (your not a telco?), but between the telcos - most definitely ;). (If not, we were scammed for a fortune for dynamically routed redundancy of calls across a set of exchanges ;) ). 2. Providers must be prepared to carry other providers traffic into the area Only one of them. The 'default' carrier. There are many phone networks and carriers carrier who do not have 100% coverage. Let me restate that: 2. One or more providers must be prepared to carry any providers traffic into the area Same thing. The incentive for providers to announce such an area-prefix to as many other providers outside of the area as possible would be to reduce settlement fees within the area for the smaller providers, and for the big ones - make money. 2a. The providers within the area have to figure out how to bill for the difference of this traffic. No. Usually the tariff is set by the regulator based on some fixed interconnection charge and network element usage. How they figure it out (with or without a regulator) doesn't matter. It just has to be figured out. We don't have IP regulators, so for IP providers would have to figure it out all by themselves obviously. ;) That'd be the stumbling block I suspect. Well, we can learn from them that circuit switched networks are different than packet switched networks. Beyond that not much. If you want to focus on the differences between IP and POTS/GSM, sure, they're completely different. However, the point is to examine the abstract model for how telcos manage to achieve number portability without global-scope exchange of subscriber information and see what, if any, techniques could apply to IP. To summarize the differences between PSTN and Internet routing: o PSTN ports numbers only within regions/area codes We're discussing what would be possible with area (rather than provider) assigned IP addresses. Ie, this is as possible for IP as PSTN, if $RIR decides to make some allocations in this way. o PSTN routes the return path along the forward path (symetric) I thought you said it didn't? No matter, IP is assymmetric. o PSTN calls have pre-determined characteristics and performance (64kbit) No bearing on routing. o PSTN has static routing with periodic sync from porting database The important point is that information to describe number-provider is exchanged
Re: And Now for Something Completely Different (was Re: IPv6 news)
# True enough, but unfortunately, it's not done in a way that we can make # use of the identifier in the routing subsystem or in the transport # protocols. # # The transport protocols, well they generally act on behalf of something # which can do the lookup and supply transport with right address, as long # the DNS server does not require who-where indirection ;). # # The transport protocols unfortunately need the identifier in the packet to # demux connections. the idea of a transport protocol comes from the OSI Reference Model which might not be the best conceptual fabric for re-thinking Internet routing. we know it's a distributed system and we know that various waypoints will or will not have state, but i don't think we know that there will always be a layer that does what the transport protocol does in the OSIRM. i mention this because padlipsky's mantra about maps and territories came into my head just now as i was listening to folks talk about what the transport protocol had to have or had to provide. there's only a transport protocol if we decide to keep thinking in ISORM terms. and with that, i do indeed wonder if this has stopped being operational and if so, whether nanog wants to overlap THIS much with the irtf? refs: http://www.amazon.com/exec/obidos/tg/detail/-/0132681110/103-3252601-1266225
Re: IPv6 news
On Tue, 18 Oct 2005 10:49:36 +0100 [EMAIL PROTECTED] wrote: I reread this and still don't see how geographical ip address allocation is going to work if typical customer connections are network-centric and any large area has number of competitive access providers Inside the city, you see lots of longer prefixes from that city's netblock. Outside the city you see only the single aggregate prefix. The only way I see that geographical addressing might have some advantage is if the area is covered by large monopoly that connects everyone else there Monopoly? Not necessary. Yes, you need to have universal exchange of local traffic in the city but that can happen through private interconnects and multiple exchange points. No need for a monopoly. The major change is that providers which participate in geotopological addressing would have to interconnect with *ALL* other such providers in that city. This would mean more use of public exchange points. Also, I think it makes sense to have a second regional layer of aggregation where you group neighboring cities that have a lot of traffic with each other. I think this would result in no more than 20-30 regions per continent. --Michael Dillon I think that levels of multi-homing are likely to develop for small entities : Multi-homing-0 : You have two or more connnections, but no real sharing of information between them. (I have this now at home, with a Cable modem and dial up for backup. They always appear to the outside as two disjoint networks, and in fact never overlap in time.) I would argue that the vast majority of residences and small offices are are likely to fall into this category; the goal is really internal failover from the preferred provider to the secondary, with automatic renumbering courtesy of DHCP. Multi-homing-1 : You have two or more connections, but can do no traffic engineering, and have to assume an equal preference for each connection. Say there is some sort of geographical or topological prefix. From the outside, they could all be viewed as belonging to some preferred carrier, or to a local exchange point, or a protocol could be created to do some sort of topogolocal or geographical provider discovery. It seems to me that this means accepting some sort of hot potato routing, and also some interaction between providers. (The routing would go something like, this is a packet for Clifton, VA; Cox and Verizon cover Clifton Virginia; pick one of these and give it to them and let them worry about the details.) Of course, this scheme it would be highly likely in such a scheme that outbound and inbound traffic for the same flow could use different providers. Multi-homing-2 : What we would now consider as multi-homing, with full control and full BGP. Why would you want Multi-homing-1 ? Well, it should be cheaper than MH-2, with no user administration but you should still get some load balancing and also fast failover if a circuit goes down. That would more than meet the needs of most home offices. If BGP table growth is an issue, I think that some sort of MH-1 is inevitable. I think that inevitably means some sort of geographical or topological based prefix, less-than-optimal routing for at least some packets, and much less user control compared to MH-2. Regional exchanges might be nice, but are not necessary. Regards Marshall Eubanks
Re: IPv6 news
On Tue, 18 Oct 2005, Paul Jakma wrote: If you want to focus on the differences between IP and POTS/GSM, sure, they're completely different. However, the point is to examine the abstract model for how telcos manage to achieve number portability without global-scope exchange of subscriber information and see what, if any, techniques could apply to IP. Eg, given some arbitrary area: - RIR assigns a prefix to that area - For that area, for the set of ISPs providing service in that area (the area-ISP set) which are all peered with each other (eg at some IX in or near the area concerned), each ISP: - announces the area prefix as far and wide as they can (doing so will be an advantage for settlement with the other area-ISP set ISPs) - exchanges very very specific routes of: area-site - AS with the other area-ISP set ISPs (if they peer locally, they can keep these very specific routes local too) - keep track of how much traffic to the area-prefix is handed off to other area-ISP set ISPs (and to which, obviously), and how much is received. - periodically, for every other area-ISP, reconcile traffic handed off / received and either send your or wait for their invoice as appropriate. Fraught with some difficulties obviously. (Politics of settlement, particularly when there is no benevolant entity to arbitrate and/or impose - before you ever get to the question of how to define an area). If it seems too difficult and the status quo is preferred - no worries, the hosts will figure out some kind of indirection. Bit less efficient than if ISPs would route natively/locally, but hey it won't require any difficult decisions and co-ordination in the ISP community. And maybe that'd be for the best. ;) regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Nowlan's Theory: He who hesitates is not only lost, but several miles from the next freeway exit.
Re: IPv6 news
Paul Jakma wrote: On Tue, 18 Oct 2005, Andre Oppermann wrote: As we know from the Internet DFZ the routing table becomes very large. However, it can be confined to that arbitrary area. Yes, but it's a very cumbersum process. You have to track this stuff for all regions and countries. They all vary how they do it. For example your ComReg publishes a couple of tables now and then with new/changed information. (Look for ComReg 04/35, 03/143R, etc.) You can forget that X.25 stuff. It's only used for SS7 message routing and doesn't have anything to do with call routing as such. Ah, it was used for everything in that network actually - but that was a very very specialised telco network. (And they had started moving to IP when I last worked with them.) SS7 over IP is quite popular these days. However call routing != SS7 message routing. Sure. However this is the main difference between the TDM network and the Internet. Due to this fact many things work on the phone network like carrier pre-selection, phone number portability, etc., that do not work on an IP network. I'm not source how assymetric paths affect portability etc. Also, IP is well capable of that, and makes life easier. IP routing is not symmetric whereas circuit switching is. In a case of individual IP address portability the return traffic always goes back to the ISP who has that particular prefix. No matter who 'opened' the connection. If I port my static dial-up IP to my new super FTTH ISP then suddenly up to 100Mbit of return traffic have to pass from Dial-Up ISP to FTTH ISP. I'd say this screws the Dial-Up ISP pretty royally. And you too because he most likely doesn't have that much capacity. On the phone network the prefix information is not dynamically exchanged. Uhm, sure it is. Nope, it's not. Can you name a phone prefix routing protocol? There are number portability registries whose data you can download every night or so and then dump it into your own switch or IN platform. The number portability registries can be updated infrequently, yes. The telco prefix routing information however most definitely *is* routed dynamically. Maybe you don't have to participate in this routing (your not a telco?), but between the telcos - most definitely ;). (If not, we were scammed for a fortune for dynamically routed redundancy of calls across a set of exchanges ;) ). That works differently. In the PSTN you always have multiple routes to a destination. If you have a direct trunk between two CO's then it will fill that first. When the direct trunk is full, the local switch has got an overflow route towards a neighboring or higher switch. It can have multiple overflow routes with different priorities. You can replace full trunk with dead trunk to get your redundancy. However there is no dynamic call routing as we know it from BGP or OSPF. At least not directly. Some switch vendors have developed call optimization software which runs in some sort of central intelligence center in the network and tries to optimize the trunk usage and priorities based on statistical and historical data. 2a. The providers within the area have to figure out how to bill for the difference of this traffic. No. Usually the tariff is set by the regulator based on some fixed interconnection charge and network element usage. How they figure it out (with or without a regulator) doesn't matter. It just has to be figured out. We don't have IP regulators, so for IP providers would have to figure it out all by themselves obviously. ;) That'd be the stumbling block I suspect. The stumbling block is that all IP packets return to the prefix holder (the old ISP) and the end-user bandwidth is not fixed. To summarize the differences between PSTN and Internet routing: o PSTN ports numbers only within regions/area codes We're discussing what would be possible with area (rather than provider) assigned IP addresses. Ie, this is as possible for IP as PSTN, if $RIR decides to make some allocations in this way. $RIR making allocations that way is not sufficient. It would need regulatory backing to enforce IP address portability. Every established carrier is not very interested in porting IP addresses to competitors. o PSTN routes the return path along the forward path (symetric) I thought you said it didn't? No matter, IP is assymmetric. IP is asymmetric and PSTN is symmetric. There you have the first major problem with IP in this szenario. o PSTN calls have pre-determined characteristics and performance (64kbit) No bearing on routing. Very much so. See my Dial-Up vs. FTTH ISP example. o PSTN has static routing with periodic sync from porting database The important point is that information to describe number-provider is exchanged betweeen providers in the area only. Whether it's done by dynamic protocols, email or post is an irrelevant detail, all that matters is that we have a way to
Re: IPv6 news
Right, cause phone number portability is up and running for several sets of prefixes in various regions across the world[1], so there's definitely nothing we can learn from them. ;) Well, we can learn from them that circuit switched networks are different than packet switched networks. Beyond that not much. I disagree. There are many parallels and in many ways the telephony operators are struggling with the same kinds of problems that we are. NANPA has forecast that the North American number plan will be exhausted within 20 years. Just like the IPv4 address space. Their plan is to extend the number plan by two digits using 4-digit area codes and 4 digit central office codes. Rather like IPv6's extended address length. The new digits will be introduced at the same time so that everyone will dial an extra digit at the end of their existing area code, and another extra digit at the beginning of their central office code. Today you would dial (703)227-0660 to reach ARIN's help desk. After the change you would dial (7030)0227-0660. Full details here: http://www.atis.org/inc/docs/finaldocs/020107029.doc NANPA's website points to more information. http://www.nanpa.com/index.html There is also a North American Numbering Council that meets regularly and has several working groups. http://www.nanc-chair.org/docs/documents.html It is foolish to regard people outside the IP networking industry as inferior. Good ideas can come from anywhere and we can often understand our own area of interest much better by comparing and contrasting with other similar areas of interest. --Michael Dillon
Re: IPv6 news
Paul Jakma wrote: On Tue, 18 Oct 2005, Paul Jakma wrote: If you want to focus on the differences between IP and POTS/GSM, sure, they're completely different. However, the point is to examine the abstract model for how telcos manage to achieve number portability without global-scope exchange of subscriber information and see what, if any, techniques could apply to IP. Eg, given some arbitrary area: - RIR assigns a prefix to that area - For that area, for the set of ISPs providing service in that area (the area-ISP set) which are all peered with each other (eg at some IX in or near the area concerned), each ISP: - announces the area prefix as far and wide as they can (doing so will be an advantage for settlement with the other area-ISP set ISPs) - exchanges very very specific routes of: area-site - AS with the other area-ISP set ISPs (if they peer locally, they can keep these very specific routes local too) - keep track of how much traffic to the area-prefix is handed off to other area-ISP set ISPs (and to which, obviously), and how much is received. - periodically, for every other area-ISP, reconcile traffic handed off / received and either send your or wait for their invoice as appropriate. Fraught with some difficulties obviously. (Politics of settlement, particularly when there is no benevolant entity to arbitrate and/or impose - before you ever get to the question of how to define an area). If it seems too difficult and the status quo is preferred - no worries, the hosts will figure out some kind of indirection. Bit less efficient than if ISPs would route natively/locally, but hey it won't require any difficult decisions and co-ordination in the ISP community. And maybe that'd be for the best. ;) Again, this fails with the asymmetric nature of IP routing. On top it fails on bandwidth issues. What if super-cheap pron hoster X is in that area doing streaming full-res HDTV to it's suckers? I bet some participants in your service area face some serious link saturation issues. None of the participants have any control or estimates over the traffic that is and will be passing through them. Traffic flows will just happen there. Forget capacity planning. You'd have a hard time finding ISP's interested in that. -- Andre
Re: IPv6 news
1. Does the US have number portability anywhere? If so, that would be a /huge/ region, and very interesting to examine to see how they manage it. In the USA this is called LNP (Local Number Portability). This article has a couple of pages of history and then a technical overview of how LNP works. http://scholar.lib.vt.edu/ejournals/JOTS/Winter-Spring-2001/pdf/obermier.pdf This document explains the architecture of LNP in today's phone network: http://www.verisign.com/stellent/groups/public/documents/white_paper/001950.pdf However, LNP is not as simple as most laypeople think. It has other applications than simply consumer convenience. For instance, disaster recovery http://www.neustar.com/pressroom/datasheets/DisasterRecPress.pdf Read this description of number pooling http://www.verisign.com/stellent/groups/public/documents/white_paper/001949.pdf and reflect on how similar this seems to injecting longer prefixes into BGP (hole punching) to support moving a customer from another network. LNP and routing are the same problem. The details of the solutions differ because the technology environment and constraints differ. But you will never understand IP routing unless you understand how non-IP networks solve these same problems. That's why some people use RIP to teach routing even though it is considered bad practice to run RIP on any network in this day and age. People need to learn routing theory separately from How to configure BGP on your brand-X boxes. --Michael Dillon
RE: IPv6 news
No. Within a region. Normally area codes are a region. Sometimes entire country codes are a region in this sense. Depends on the size of the region/country though. In some cases there is even more than one area code for the same region. LATA's are geographic areas and NPX(prefix) are switching areas within the LATA(Local Access and Transport Area). The geo regions(LATA) are set up to differentiate local and long distance inside the US. There's a three level hiearchy within each LATA, and there are three levels in the United States as defined by the regulators, post divestiture. I'd have to say your definition may be accurate outside the US, but not inside. [ SNIP ] The telco peering points is just a technicality. It's there just for optimization. Most regulators have set up an easy interconnection policy to prevent your favorite incumbant from offering 'peering' only on lands end. They're more than a technicality. They are required by the regulator. There are commodity markets related to IXC minutes exchange as well. This helps to keep LD cheap (as it can be) and reliable as if one carrier is unable to carry minutes, others can. The basic telco archictecture in the USA is EO, TO, and AT. In the case of LD, it's EO, TO, to a POP, and IXC. EO, TO and AT are all interconnected some symetrically, some asymetrically, with the exception of the IXC which is all symetric. Personally, this is a very interesting thread to me, but I think this is starting to go way off topic for NANOG. -M
Re: And Now for Something Completely Different (was Re: IPv6 news)
this because padlipsky's mantra about maps and territories came into my head S.I. Hayakawa - Language and Thought in Action The symbol is not the thing the thing symbolized; The map is not the territory: The word is not the thing. Nevertheless, Padlipsky is a good thing to read. Here is the book review from the Cisco IP Journal with a taste of the book. http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac179/about_cisco_ipj_archive_article09186a00800e55d2.html --Michael Dillon
Re: IPv6 news
On Tue, 18 Oct 2005, Andre Oppermann wrote: Again, this fails with the asymmetric nature of IP routing. The assymetric nature is plus-point. It means the traffic out of the area goes out via the correct provider (ie the one whose customer it is). On top it fails on bandwidth issues. What if super-cheap pron hoster X is in that area doing streaming full-res HDTV to it's suckers? It goes via the ISP(s) which super cheap hoster X pays for transit. I bet some participants in your service area face some serious link saturation issues. None of the participants have any control or estimates over the traffic that is and will be passing through them. Yep. Traffic flows will just happen there. Forget capacity planning. You'd have a hard time finding ISP's interested in that. Maybe. Look at it the other way though, it's a business opportunity - you can make money by attracting as much area-destined external traffic as possible and handing it off to correct intra-area ISP for that subscriber. The more the better, it's a potential revenue source. It's in your interest to be able to carry all the external traffic into the area that you can get. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Profanity is the one language all programmers know best.
Re: IPv6 news
[EMAIL PROTECTED] wrote: Right, cause phone number portability is up and running for several sets of prefixes in various regions across the world[1], so there's definitely nothing we can learn from them. ;) Well, we can learn from them that circuit switched networks are different than packet switched networks. Beyond that not much. I disagree. There are many parallels and in many ways the telephony operators are struggling with the same kinds of problems that we are. NANPA has forecast that the North American number plan will be exhausted within 20 years. Just like the IPv4 address space. Their plan is to extend the number plan by two digits using 4-digit area codes and 4 digit central office codes. Rather like IPv6's extended address length. The new digits will be introduced at the same time so that everyone will dial an extra digit at the end of their existing area code, and another extra digit at the beginning of their central office code. Today you would dial (703)227-0660 to reach ARIN's help desk. After the change you would dial (7030)0227-0660. Full details here: http://www.atis.org/inc/docs/finaldocs/020107029.doc NANPA's website points to more information. http://www.nanpa.com/index.html There is also a North American Numbering Council that meets regularly and has several working groups. http://www.nanc-chair.org/docs/documents.html It is foolish to regard people outside the IP networking industry as inferior. Good ideas can come from anywhere and we can often understand our own area of interest much better by comparing and contrasting with other similar areas of interest. There is a major difference between phone numbers and IP addresses which makes direct comparisons harder. Phone numbers are more like Domain names (+email addresses behind them) than IP addresses. People use phone numbers the same way they use domain names. They remember them and use them to access other people, or companies. I haven't seen many billboards with IP addresses on them lately. Nobody cares about the actual IP address. Only the computer does at the time of the DNS lookup. So an IP address is only used as underlying transport vehicle of data. For the enduser it doesn't have any direct significance. A phone number has significance to the end user and has a hybrid function as underlying routing element to varying degrees too. The entire problemset with IP address portability comes from two issues: Ease of ISP changes and redundant connectivity. The former could theoretically be solved with with better procedures and methods for host address assignment. However it still requires some labor intensive transition period and the IP addresses are much tangled with other things like DNS and so on. The second issue is IP architecture specific. The PSTN, due to its symmetric nature, doesn't have the redundancy problem to the same extent as the Internet. For the IP prefix however you have to participate in the global routing system to survive link losses. Without any shim6 or SCTP stuff that is. Again, phone numbers and their portability can and should not be compared with the IP address portability issues. They're very different animals. -- Andre
Re: IPv6 news
On Tue, 18 Oct 2005, Andre Oppermann wrote: you care whether it is Sprint, Level(3) or Cogent? Apparently you don't. With your proposed you don't have much/any influence on the way your packets take. They might take much better routes actually than is possible today. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: The early worm gets the bird.
Re: IPv6 news
On Tue, 18 Oct 2005, Andre Oppermann wrote: don't. With your proposed you don't have much/any influence on the way your packets take. Oh, NB: It's not my proposal at all. I'm merely exploring it. ;) Further, most of the thinking on this was done by the likes of Marcelo Bagnulo, Iljitsch van Beijnum and others. The fact that both of them are working on SHIM6 now probably is telling. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Yeah. Maybe I do have the right ... What's that stuff? -- Homer Simpson Deep Space Homer
Re: IPv6 news
Paul Jakma wrote: On Tue, 18 Oct 2005, Andre Oppermann wrote: you care whether it is Sprint, Level(3) or Cogent? Apparently you don't. With your proposed you don't have much/any influence on the way your packets take. They might take much better routes actually than is possible today. Yea, but only by chance, not by design. ;-) -- Andre
Re: IPv6 news
On Tue, 18 Oct 2005, Andre Oppermann wrote: Yea, but only by chance, not by design. ;-) Nope, by design. Routing would generally be better. The entire area would effectively be multihomed to the set of area-ISPs. There'd be some downsides too, eg where a provider attracting traffic for the prefix has some failure internally and for some reason doesn't withdraw the area-aggregate to ASes wholly external to the area. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: To give of yourself, you must first know yourself.
Re: IPv6 news
Paul Jakma wrote: On Tue, 18 Oct 2005, Andre Oppermann wrote: SS7 over IP is quite popular these days. However call routing != SS7 message routing. By call-routing you mean the actual circuit switching of each call? I don't mean that, I mean the number routing, which SS7 /does/ do - you referred to it as being more analogous to DNS iirc in operation. Nope, it's not. Can you name a phone prefix routing protocol? Ehm, SS7 ;). You might call it DNS-like because it's request based, but it still provides routing information. SS7 is not a routing protocol. SS7 is a transport stack like what we refer commonly to as TCP/IP. There are a number of protocols that run atop the basic SS7 transport network. Some protocols are datagram oriented and some are session oriented. For call handling ISUP or derivates are used. The main difference to the IP world is the limited scope in the PSTN. A PSTN switch consults its (static) number routing table for the trunk to forward the call on. Then it contacts the switch at the other end of the tunk and hands over further forwarding to it. If that doesn't work out the circuit gets shut down backward switch to switch. For special numbers like 800 and 900 there is another protocol called IN (Intelligent Network) which is nothing else than DNS. Each special number has a 'real' number in its shadow. The originating switch requests the real number through IN and then the normal call forward happens. IN may deliver different numbers based on the location of the orginating switch or daytime or any other criteria you may think of. A little bit like Akamai if you wish. However there is nothing akin BGP or OSPF in the SS7 suite of protocols. All the forwarding/trunk tables are computed offline for each switch and then stored on the switches by some bulk data transfer. Variantions are emerging with extended IN platforms where you have one more central databases of forwarding information but that is just a large geographically distributed switch then. -- Andre
Re: And Now for Something Completely Different (was Re: IPv6 news)
Tony, On Oct 16, 2005, at 1:15 AM, Tony Li wrote: A real locator/identifier separation requires a rewrite. Not necessarily. If you transition at the edge, what happens within the site matters only to the site and what matters to the core only matters to the core. No stacks, either core or edge, need to be rewritten. Any system that provided site-wide source address control was going to require a rewrite. Not necessarily (depending on what you mean by the ambiguous term address). A lot depends on the actual requirements for source locator or identifier control. David, I should point out that if only a small number of folks care about multihoming, then only a small number of folks need to change their stacks. I thought all clients would have to be modified if they wanted to take full advantage of a shim6 enabled multi-homed server? And even in your solution, there would need to be some changes to the end host if you want to support exit point selection, or carry alternate locators in the transport. One of the problems that I have seen in the IETF is calling desires requirements. How important is exit point selection? Are there ways of implementing exit point selection without changing the IP stack? How critical is it that alternate locators be carried in the transport? Does the lack of that functionality make the protocol unusable? What _are_ the actual requirements (not the Goals)? From my perspective, the really, really critical flaw in both IPv4 and IPv6 is the lack of _transparent_ renumberability. Multi-homing is also a flaw, but less critical and I believe it can be addressed with the right solution to renumberability. A few folks worry about multi- homing. Everybody worries about end site renumbering. It's just a mess. I think that we all can agree that a real locator/identifier split is the correct architectural direction, but that's simply not politically tractable. Right. And since it couldn't be done the right way in the protocol, we make the protocol much more complicated and force a reset to address functionality that relatively few folks need. I'm suggesting not mucking with the packet format anymore. It might be ugly, but it can be made to work until somebody comes up with IPv7. Instead, since the locator/identifier split wasn't done in the protocol, do the split in _operation_. Make the edge/core boundary real. Both edge and core could be addressed without hierarchy, but the mapping between the edge and core would change such that the edge would never be seen in the DFZ. Within the core, nothing new or different need be done (well, except for deploying IPv6 and running the core/edge translators). Within the edge, nothing new need be done either. Yes, it is a hack. But I suspect it would address the real requirements (or, at least my pet requirement :-)). Rgds, -drc
Re: IPv6 news
At 07:36 AM 10/18/2005, Andre Oppermann wrote: [... items deleted ...] To summarize the differences between PSTN and Internet routing: o PSTN ports numbers only within regions/area codes o PSTN routes the return path along the forward path (symetric) o PSTN calls have pre-determined characteristics and performance (64kbit) o PSTN has static routing with periodic sync from porting database o PSTN pays the routing table lookup only once when doing call setup o PSTN call forwarding and peering is not free or zero settlement -- Andre Largely true; influenced by history and the difference between circuit-switched networks and packet-switched networks. LNP is more like DNS than multihoming. Sort of. Imagine TCP using domain names rather than IP addresses. I should note however, that in the U.S., Number Portability (LNP) rarely uses call forwarding anymore. Except in legacy rural areas, the LNP dip occurs before reaching the host office and is thus shunted to the correct carrier earlier up in the stream. At minimum it is done by the N+1 switch. However, it is common for the IXCs (LD Carriers) and CLECs do it even earlier to avoid paying the local ILEC database lookup fees. In that scenario, it routes perfectly to the correct carrier. BTW, telephone networks are generally do not multihome and are very fragile. Node (Switch) failure brings down large sections of the network. They instead concentrate on 99.99%+ uptime for the switches themselves. In other words, they concentrate on internal component redudancy and same-destination route redundancy rather than handling an outage of the entire switch. The SS7 network has removed some of this fragility, but not all. Not by a long shot. Describing this in a picture: Internet way: route around problems A - B - C \ / \-D-/ The Telco way: try to make problems never happen A--B--C A--B--C Where the AA in the Telco model is essentially the same equipment in the same room with redundant components. Anyway, ... TCP using DNS rather than IP?... Interesting thought. John
Re: And Now for Something Completely Different (was Re: IPv6 news)
[EMAIL PROTECTED] (David Conrad) wrote: I'm suggesting not mucking with the packet format anymore. It might be ugly, but it can be made to work until somebody comes up with IPv7. Instead, since the locator/identifier split wasn't done in the protocol, do the split in _operation_. It has been done a long time ago, IMHO. I wonder whether I am the only one seeing this, but we already have a (albeit routing-) locator (ASN) and an identifier (IP address), that are pretty much distinct and where the routing locator is not used inside the local network, but only outside. There's your edge/core boundary. Every multi-homer will be needing their own ASN, so that's what clutters up your routing tables. It's economy there. Btw, a lot of ASNs advertise one network only. People surely think multihoming is important to them (and I cannot blame them for that). Hierarchical routing is one possible solution, with a lot of drawbacks and problems. Forget about geographic hierarchies; there's always people who do not peer. Visibility radius limitation is another (I cannot believe the idea is new, I only don't know what it's called). Cheers, Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
RE: And Now for Something Completely Different (was Re: IPv6 news)
Nanog, I've been thinking a bunch about this IPv6 multihoming issue. It seems that the method of hierarchical summarization will keep the global tables small for all single-homed end user blocks. But the multihomed ones will be the problem. The possible solution I've been thinking about is 'adjacency blocks', for lack of a better term. In theory, the first customer to home to two different ISPs causes a new large address block to be advertised upstream by these two ISPs. Further customers homing to these two ISPs get an allocation out of this same block. The two ISPs will only announce the large block. Of course there are issues involving failure and scalability... Failure would involve an ISP losing contact with end customer, but still announcing the aggregate upstream. This can be solved by requiring that two ISPs must have a direct peering agreement, before they can accept dual-homed customers. Or a possible method (maybe using communities?) where ISP B will announce the customer's actual block (the small one) to it's upstreams, if notified by ISP A that it's not reachable by them. When ISP A resumes contact with end customer, ISP B retracts the smaller prefix. Scalability is an obvious issue, as the possible number of these 'adjacency blocks' would be N * (N-1), where N is the number of ISPs in the world. Obviously pretty large. But I feel the number of ISPs that people would actually dual home to (due to reputation, regional existence, etc) is a few orders of magnitude smaller. ~100,000 prefixes (each can be an ASN, I suppose) should cover all needs, doing some simple math. The downside is that end customers are going to lose the ability to prefer traffic from one ISP versus another for inbound traffic. That alone might be a show-stopper, not sure how important it is. Since IPv6 is a whole new ballgame, maybe it's ok to change the rules... Looking for any thoughts about it. I'm sure there's things I haven't considered, but the people I've bounced it off of haven't seen any obvious problems. Flame-retardant clothes on, just in case though. Chuck Every multi-homer will be needing their own ASN, so that's what clutters up your routing tables. It's economy there. Btw, a lot of ASNs advertise one network only. People surely think multihoming is important to them (and I cannot blame them for that). Hierarchical routing is one possible solution, with a lot of drawbacks and problems. Forget about geographic hierarchies; there's always people who do not peer. Visibility radius limitation is another (I cannot believe the idea is new, I only don't know what it's called).
Re: And Now for Something Completely Different (was Re: IPv6 news)
the principal issue I see with your proposal is that it is DUAL homing vs MULTI homing. To make it viable, I think you have to say something like two or more ISPs must participate in a multilateral peering arrangement that shares the address pool among them. The location of the actual peering is immaterial - doing one for Santa Barbara County in California might actually mean peering at One Wilshire Way in LA, for example. However, the peering arrangement would have to be open to the ISPs that serve the community; otherwise, it would be exposed to anti-trust litigation (if Cox and Verizon, the Cable Modem and DSL providers in Santa Barbara, did this, but it was not open to smaller ISPs in the community, the latter might complain that it had the effect of locking out competition). But yes, communities of a rational size and density could get an address block, the relevant ISPs could all advertise it into the backbone, and the ISPs could determine among themselves how to deliver traffic to the homes, which I should expect would mean that they would deliver directly if they could and otherwise hand off to another ISP, and that handoff would require an appropriate routing exchange. Can you say lots of long prefixes within a limited domain? They would want to configure the home's address block on its interior interface and route to it through their own networks. Note that NAT breaks this... this requires end to end connectivity. I should expect that they would not literally expect the homes to run BGP (heaven forfend); I could imagine the last mile being the last bastion of RIP - the home sends a IP update upstream for its interior address, and the ISP sends a default route plus routes to its own data centers down. The biggest issue here might be the effect on cost models in routing. Today, hot potato routing makes a some relationships relatively cheap while other relationships are more expensive; this reverses those. Today, if a datagram is handed to me that will be delivered in your network, I hand it to you at my earliest opportunity and you deliver it. In this model, I can't tell who will deliver it until I get relatively close to the community. Hence, I will carry the packet to that exchange point, and only then hand it to you. Funny. I described this in an internet draft nearly a decade ago, and got dumped on because of this issue - something about living in an ivory tower and playing with people's livelihoods, as I recall. I'll see if I can resurrect that, if you like. On Oct 18, 2005, at 10:40 AM, Church, Chuck wrote: Nanog, I've been thinking a bunch about this IPv6 multihoming issue. It seems that the method of hierarchical summarization will keep the global tables small for all single-homed end user blocks. But the multihomed ones will be the problem. The possible solution I've been thinking about is 'adjacency blocks', for lack of a better term. In theory, the first customer to home to two different ISPs causes a new large address block to be advertised upstream by these two ISPs. Further customers homing to these two ISPs get an allocation out of this same block. The two ISPs will only announce the large block. Of course there are issues involving failure and scalability... Failure would involve an ISP losing contact with end customer, but still announcing the aggregate upstream. This can be solved by requiring that two ISPs must have a direct peering agreement, before they can accept dual-homed customers. Or a possible method (maybe using communities?) where ISP B will announce the customer's actual block (the small one) to it's upstreams, if notified by ISP A that it's not reachable by them. When ISP A resumes contact with end customer, ISP B retracts the smaller prefix. Scalability is an obvious issue, as the possible number of these 'adjacency blocks' would be N * (N-1), where N is the number of ISPs in the world. Obviously pretty large. But I feel the number of ISPs that people would actually dual home to (due to reputation, regional existence, etc) is a few orders of magnitude smaller. ~100,000 prefixes (each can be an ASN, I suppose) should cover all needs, doing some simple math. The downside is that end customers are going to lose the ability to prefer traffic from one ISP versus another for inbound traffic. That alone might be a show-stopper, not sure how important it is. Since IPv6 is a whole new ballgame, maybe it's ok to change the rules... Looking for any thoughts about it. I'm sure there's things I haven't considered, but the people I've bounced it off of haven't seen any obvious problems. Flame-retardant clothes on, just in case though. Chuck Every multi-homer will be needing their own ASN, so that's what clutters up your routing tables. It's economy there. Btw, a lot of ASNs advertise one network
Re: And Now for Something Completely Different (was Re: IPv6 news)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Fred! On Tue, 18 Oct 2005, Fred Baker wrote: But yes, communities of a rational size and density could get an address block, the relevant ISPs could all advertise it into the backbone, and the ISPs could determine among themselves how to deliver traffic to the homes, That assumes they can agree on how to get traffic to/from the world and the local IX. One of our local ISPs goes the cheap way and uses an overloaded (and therefore cost effective) link to a cheap tier 2. Another pays a premium price to have a lightly loaded link for it's customers. They will never agree on their business model, not should they have to. By forcing local ISPs to use the same routing prefix you force them to share the same routing strategy to the outside world. For semi-isolated communities this is a big issue. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDVV4g8KZibdeR3qURAuhjAKCuvsd/ZmXebyyTNkfdQ3tBbQvdmACg1OnL RE0lRoxSElVzNaZFpdYcObA= =b5O1 -END PGP SIGNATURE-
Re: And Now for Something Completely Different (was Re: IPv6 news)
Thus spake [EMAIL PROTECTED] E.g prevously announced address-blocks that has disappeared from the global routing-table for more than X months should go back to the RIR-pool (X=6). In RFC 2050 section 3 a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. Seems to me that the Internet routing table contents past and present are irrelevant. Note also that the so-called Internet routing table contents vary depending on where you look at it. Obviously if the RIRs contacted the folks responsible for a given block and were provided justification for its continued allocation, then it should not be reclaimed. On the other hand, folks sitting on several class Bs and not using them could have their blocks reclaimed trivially; ditto for companies that no longer exist. The last is certainly doable without much risk of controversy. However, one of the articles referred to recently in this thread (I forget which) showed that even if we reclaimed all of the address space that is currently unannounced (in use or not), we'd buy ourselves a trivially short extension of the IPv4 address space exhaustion date. Considering the cost of performing the task, doing so seems rather pointless; our time would be better spent getting IPv6 deployed and either reengineering the routing system or switching to geo addresses. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: And Now for Something Completely Different (was Re: IPv6 news)
David, A real locator/identifier separation requires a rewrite. Not necessarily. If you transition at the edge, what happens within the site matters only to the site and what matters to the core only matters to the core. No stacks, either core or edge, need to be rewritten. Transitioning at the edge implies to me that the hosts need to know about different semantics for the IPv6 header. That, in turn, implies that there is different code for the hosts. Alternately, if there is no new code anywhere, it's clear that you must necessarily have the same semantics and must not have made a change. Any system that provided site-wide source address control was going to require a rewrite. Not necessarily (depending on what you mean by the ambiguous term address). A lot depends on the actual requirements for source locator or identifier control. Again, source address selection is going to require something different than what we have today. The host might have to interact with some centralized policy server, execute a selection algorithm, or consult an oracle. Whatever that might be, there is new code involved. David, I should point out that if only a small number of folks care about multihoming, then only a small number of folks need to change their stacks. I thought all clients would have to be modified if they wanted to take full advantage of a shim6 enabled multi-homed server? The keyword there is full. Unmodified clients can still interact with a multi-homed server in a legacy manner. And even in your solution, there would need to be some changes to the end host if you want to support exit point selection, or carry alternate locators in the transport. One of the problems that I have seen in the IETF is calling desires requirements. How important is exit point selection? Are there ways of implementing exit point selection without changing the IP stack? How critical is it that alternate locators be carried in the transport? Does the lack of that functionality make the protocol unusable? What _are_ the actual requirements (not the Goals)? From my perspective, the really, really critical flaw in both IPv4 and IPv6 is the lack of _transparent_ renumberability. Multi-homing is also a flaw, but less critical and I believe it can be addressed with the right solution to renumberability. A few folks worry about multi-homing. Everybody worries about end site renumbering. As with any political process, the stated requirements are a function of perspective. The stated requirements may or may not have anything to do with reality, realizability, practicality, or architectural elegance. It's just a mess. I think that we all can agree that a real locator/identifier split is the correct architectural direction, but that's simply not politically tractable. Right. And since it couldn't be done the right way in the protocol, we make the protocol much more complicated and force a reset to address functionality that relatively few folks need. It could have been done the right way in the protocol, but it wasn't. Yes, the result is that the subsequent 'work around' solution is much more complicated than it could have been. Again, between multihoming and mobility, the ubiquity and necessity of Internet access, and the reliability of the last mile, this is not going to remain a rare or even minority issue. Regards, Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
Daniel, But wasn't that the rationale for originally putting the kitchen sink into IPv6, rather than fixing the address length issue? The stated rationale was to fix the address length issue. I think we missed a lot of opportunities. Amen. We're 10 years on, and talking about whether there will need to be more than one massive pain of migration, because the kitchen sink didn't take into account multihoming. More generally because we were unwilling to make changes to the routing architecture. Now we're talking about a solution that appear to be an even worse Rube Goldberg than token ring source-route bridging. No one has proposed anything that is as bad as the exponential traffic explosion caused by explorers. Moore will likely have to continue to produce the solution. What happens if he can't? Silicon technology *is* topping out. What happens to v6 if every single household and business on the planet decides to multihome? Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
Tony, On Oct 18, 2005, at 1:56 PM, Tony Li wrote: Not necessarily. If you transition at the edge, what happens within the site matters only to the site and what matters to the core only matters to the core. No stacks, either core or edge, need to be rewritten. Transitioning at the edge implies to me that the hosts need to know about different semantics for the IPv6 header. That, in turn, implies that there is different code for the hosts. Alternately, if there is no new code anywhere, it's clear that you must necessarily have the same semantics and must not have made a change. No. The only code change that must occur is at the core/edge transition device _at both ends_. Let me try explaining this by example: Assume you have: - ISP A providing service to site X. - ISP B providing service to site Y. - ISP A has locator prefix A000::0 - ISP B has locator prefix B000::0 - Site X has identifier prefix 1000::0 - Site Y has identifier prefix 2000::0 - Host 1000::1 wants to send a packet to host 2000::2 Then: 1. Packet leaves host 1000::1 destined for 2000:2 and ends up at the site edge router for ISP A. 2. The site edge router for ISP A sees destination 2000:2 and looks up the locator in some globally distributed database using the identifier prefix 2000::0, getting back locator prefix B000::0. 3. The site edge router for ISP A rewrites the destination address with the locator prefix, i.e., B000::2. 4. The site edge router for ISP A forwards the packet to the next (core) hop for destination B000::2. 5. The site edge router for ISP B receives the packet destined for B000::2 6. The site edge router for ISP B rewrites the destination prefix with the identifier prefix, i.e., 2000::2 7. The site edge router for ISP B forwards the packet to the destination. You want multi-homing? Site Y has two ISPs, each having their own locator prefix, e.g., ISP B (B000::0) and ISP C (C000::0). The lookup at step 2 returns two locators and the site edge router for ISP A can choose which path to take (perhaps with advice from the administrator of Site Y encoded in the response from the lookup, e.g., a preference or priority value). Transparent renumbering is obvious. Mobility might be possible with a little work and the old site edge router forwarding to the new site edge router for the duration of the cached response from the lookup. No code changes within the site or within the core would be necessary. Of course, the tricky bit is in looking up the locator in the globally distributed database and caching the response (which presumably would be necessary because the lookup will take a long time, relatively speaking). When a new 'conversation' between two hosts start, the initial packet will obviously have increased latency, but subsequent packets could rely on cached information. Again, I realize this is a hack, but I suspect it is a hack that impacts fewer points than something like shim6. Again, source address selection is going to require something different than what we have today. The host might have to interact with some centralized policy server, execute a selection algorithm, or consult an oracle. Whatever that might be, there is new code involved. Well, yes, if source address selection is important. My point was that there didn't have to be new code in the IP stack. As with any political process, the stated requirements are a function of perspective. The stated requirements may or may not have anything to do with reality, realizability, practicality, or architectural elegance. Hmm. Are the aliens who took the _real_ IETF and replaced it with what's there now going to give it back? :-) It could have been done the right way in the protocol, but it wasn't. Yes, the result is that the subsequent 'work around' solution is much more complicated than it could have been. I grant additional complexity is necessary. However, additional complexity in every system seems like a bad idea to me. Again, between multihoming and mobility, the ubiquity and necessity of Internet access, and the reliability of the last mile, this is not going to remain a rare or even minority issue. I very much agree. Rgds, -drc
Re: shim6 (was Re: IPv6 news)
On Fri, 14 Oct 2005, John Payne wrote: I'm also undecided about how I feel about the extra packets caused by the (I forget the official term) discovery packets for shim6 for an end site with say a hundred machines each with thousands of short lived TCP sessions. The shim6 capability detection can (and I expect it will) be postposed to be done only when arbitrary policy criteria have been met (e.g., the session has lasted more than 30 seconds). It doesn't need to be done before establishing the session. IMHO, this is a MAJOR benefit of the current shim6 approach, compared to other mechanisms or approaches (e.g., HIP). -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IPv6 news
RFC 3068 also has another problem -- not enough relays, or at least not enough in logical locations. From my home in Texas, a traceroute shows the topologically closest instance of 192.88.99.1 to be in France. Nice to see that GBLX's native IPv6 network doesn't have any 6to4 relays in the US, and that ATT doesn't have any at all. (Or if they do, they need serious anycast tuning) This seems like a problem that could be solved in the style of the CIDR report. Regular weekly reports of v6 relays and locations as seen from various major ASes. --Michael Dillon
Re: IPv6 news
Paul Jakma wrote: And 6to4 obviously won't fly for long after the 4 tank runs dry. Hopefully it won't need to at that point as it is only intended as a transitional step. I like the simplicity of 6to4 and the way it preserves end-to-end addresses. If only there was a way to adapt it's stateless automatic tunneling to solve the IPv6 multihoming/PI problem. I took a quick hack at it and the result is interesting though far from perfect: http://kl.net/ipv6/pi-in-6.txt - Kevin
Re: IPv6 news
there is no hope in having operators explain to ietf that the current path is fruitless? certainly they can be made to see the light, yes? you have not spent much time with the ivtf, have you? In case you have never heard of the IVTF, Randy eloquently summarizes it here: https://rip.psg.com/~randy/050721.ccr-ivtf.html --Michael Dillon
Re: And Now for Something Completely Different (was Re: IPv6 news)
man, 17,.10.2005 kl. 07.17 +0200, skrev Mikael Abrahamsson: Both MPLS and any tunneled VPN over IP means the core won't have to know about all those prefixes (think aggregation of addresses regionally in the IP case and outer label in the MPLS case). Hope you don't imply NAT and private addresses like it is usually associated with VPN in the IPv4 world ;) So if you're building a 100G capable platform that'll do IPv6 and MPLS, how much difference would it be if you only had to support 16000 labels and 16000 IPv6 prefixes, rather than 2 million? Then of course I guess the argument can be made to put everything on MPLS to avoid the core knowing about anything but outer labels. flameMPLS on its own won't solve anything. Although MPLS has its uses, it smells too much like another desperate attempt from the telco-heads in the ITU crowd to make a packet-switched network look and behave like a circuit-switched network./flame What this discussion boils down to is that a long term solution has to remove the size of the routing-table as a limiting factor in internet routing. Something must eliminate the need for every node in the default-free transit-network to know how to reach every allocated address-block at all times. Allocation policies, operational agreements on filtering, BCPs etc can only slow the growth of the routing-table. Growth can't be eliminated. In the future network you'll have routers that may know a lot about their local region of the network but have to rely on nodes that are several hops (even AS-hops) away to pass the packets to more remote destinations. These trust-relationships have to be built and maintained automatically (may involve packet tagging / tunnelling etc), similar to current route-cache mechanisms, but will require a whole new set of routing protocols. Despite lots of research there's no such solution today or anytime soon. Just think of the added complexity. How do you build trust with remote nodes given the problems you see in trusting your direct peers in the BGP world today? How can routing loops be prevented in such a network? All we know is that if there is no such solution, at some point in time the network will fragment due to its size and complexity. In the meantime we have to manage with what we've got, and treat v6 just like we've done with v4 - multihoming and all. We know we'll run out of v4 addresses at some point, and that v6 is the only realistic alternative. Without improved routing protocols, all we can do is to pray that the development of routing hardware in terms of memory and processing capability outpaces the growth of the routing table. Initiatives like shim6 that changes the behaviour of leaf-nodes are only a supplement and won't replace the need for true multi-homing for end-sites. Here we have to adapt to business needs, and businesses have made it pretty clear that it is unacceptable to them to be tied to any single provider. Besides, shim6 doesn't eliminate the need for a mechanism to locate any globally unique address. What if there's suddenly 10M LIR's, or otherwise a trend towards a market with very small providers each handling only a small number of customers? Who gets to decide who may peer with whom, or decide which providers will be denied the ability to build redundant connectivity with multiple upstreams? //Per
Re: IPv6 news
Another alternative is to force-align allocation and topology in some way /other/ than by Providers (geographical allocation in whatever hierarchy, IX allocation, whatever), such that networks were easily aggregatable. Lots of objections though (the providers and geography don't align one though is ultimately slightly bogus, because with non-provider-aligned allocation policies in place it would be in providers interests to align their peering to match the allocation policy). I think we need a researcher to sit down and figure out exactly what this would look like in a sample city and a sample national provider. This is one of those inversion situations where we are turning the existing model inside out. Some people may be familiar with the inversion of control in user interfaces that came about when Windows/Macintosh became the standard UI. Here, the suggestion is that netblocks should be allocated to cities, not to providers. Within a city, providers would get a subset of the city address block to meet their local infrastructure needs. They would interconnect with each other a local exchange points to exchange local traffic as Paul Vixie is suggesting here: http://news.com.com/5208-1028-0.html?forumID=1threadID=10554messageID=77189start=-1 Addresses from other cities would be viewed as a single aggregate for that city and these could be even further aggregated at some regional level such as Northwest, Southwest, Midwest, Southeast and Northeast. It's different than what we have now, but not extremely different. It is doable with IPv6 without any protocol changes because there is sufficient reserve address space available. It meets the concept of Internet as utility or mission-critical Internet because it mandates local interconnect. The customer point of view is that low latency and consistent latency is best and that mandates local interconnect. --Michael Dillon
Re: IPv6 news
Just my 5 cents to the topic: Don't you all think that IPv6 would not be so neccessary for the very long time yet, if the IPv4 allocation scheme would be done right from the very very beginning? If the allocation policies would be something like the ones for ASn's. I.e. when you ask for IP space allocation you must be in the need to set your own routing policies. In any other cases you should use private network space with only one IP shown outside the network. Yes, this would be a headache for some appplications like IP telephony, but, I don't see any problems in making the _correct_ protocols so they could work through NAT. As what I see now is that a very large address blocks are allocated to large companies, what companies do with them? Correct, they ae installing them as IP's of workstations, when, if IPs would be treated as a very valuable resource from the beggining, they would have to use at max /24 (well, may be 2 or three /24) for access routers. When they are proposing /48 allocation scheme for IPv6 they must be out of their mind, because in case such allocation will be ineffect, IPv6 address space will end shortly too. Again, IPv6 is creating more problems then solve. Better solution would be to freeze IPv4 allocation, then force big IPv4 users to return the addresses to the public pool, and start allocation from the white piece of paper, doing the things right. -- With best regards, GRED-RIPE
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Mon, 17 Oct 2005, Per Heldal wrote: man, 17,.10.2005 kl. 07.17 +0200, skrev Mikael Abrahamsson: Both MPLS and any tunneled VPN over IP means the core won't have to know about all those prefixes (think aggregation of addresses regionally in the IP case and outer label in the MPLS case). Hope you don't imply NAT and private addresses like it is usually associated with VPN in the IPv4 world ;) No, no NAT and RFC1918 implied, even though it might be part of it. Then of course I guess the argument can be made to put everything on MPLS to avoid the core knowing about anything but outer labels. flameMPLS on its own won't solve anything. Although MPLS has its uses, it smells too much like another desperate attempt from the telco-heads in the ITU crowd to make a packet-switched network look and behave like a circuit-switched network./flame Why? The initial argument for MPLS was that it would solve the core problem and put intelligence at the edge. You would have a core that only needed to know about hundreds of nodes instead of 100.000:nds of nodes. Growth can't be eliminated. In the future network you'll have routers that may know a lot about their local region of the network but have to rely on nodes that are several hops (even AS-hops) away to pass the packets to more remote destinations. These trust-relationships have to Yes, that is what's being proposed. Know your internal nodes, announce single big prefix externally. With ISPs only having a single prefix and no single customer prefixes, routing table can be kept low. Redundancy can be solved with for instance shim6. alternative. Without improved routing protocols, all we can do is to pray that the development of routing hardware in terms of memory and processing capability outpaces the growth of the routing table. We have done this for 15 years or so, what good has it brought us? Yes, TCAM size etc has been fairly good in keeping up with routing table size, but at quite high cost. Initiatives like shim6 that changes the behaviour of leaf-nodes are only a supplement and won't replace the need for true multi-homing for end-sites. Here we have to adapt to business needs, and businesses have Why? What problem does multihoming with single prefix solve that a fully working shim6 doesn't? What is the argument that the internet needs to know about a lot of end-users, instead of the end-user knowing that each end user might have n number of IP addresses and that there are n^2 combinations to send packets? Convergence time in the real world today is in the minutes, with shim6 it would for the end user be much quicker to route around the problem. Shouldn't be any problem to have failover in the subsecond timeframe, even thought that might need some kind of hello mechanism that is suboptimal because it sends traffic not carrying any data. single provider. Besides, shim6 doesn't eliminate the need for a mechanism to locate any globally unique address. What if there's I thought DNS solved that? suddenly 10M LIR's, or otherwise a trend towards a market with very small providers each handling only a small number of customers? Who gets to decide who may peer with whom, or decide which providers will be denied the ability to build redundant connectivity with multiple upstreams? It costs money to maintain a LIR which limits the number of LIRs economically viable in the world. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: IPv6 news
They've been asking for that as well I think. I certainly don't want to have 1M+ routes for JUST the Internet to worry about anytime soon, I'd hate to see over 300k for real Internet routes anytime soon :( Much of today's hardware doesn't seem so happy around that number :( Operators and IETF need to hit a middle ground. There are 437 cities of 1 million or more population. There are roughly 5,000 cities of over 100,000 population. And there are 3,047,000 named communities in the world. Seems to me that the number of routes in the global routing table should logically be closer to 5,000 than to 3,000,000. I'm not sure I agree that the end state is 100% multihoming. I can certainly agree that more multihoming is coming. Many more people are pushing for multihoming today than in previous years, apparently telco instability (financial not technical) is/has driven this :) (among other things I'm sure) I agree that the end state is *NOT* 100% multihoming. It is too complex for most people and there is no business justification for it. But an awful lot of business customers will be able to justify multihoming. That is part and parcel of the mission critical Internet. --Michael Dillon
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Sun, 16 Oct 2005, Tony Li wrote: This is completely orthogonal to a real identifier/locator split, which would divide what we know of as the 'address' into two separate spaces, one which says where the node is, topologically, and one which says who the node is. Hmm, no idea whether it's a good idea or not, but from POV of scaling while it might make 'where' scaleable, you still have to find a way to tie who to where. Some might say we already have this split though, DNS. Tony regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Robotic tape changer mistook operator's tie for a backup tape.
Re: IPv6 news
On Mon, 17 Oct 2005, [EMAIL PROTECTED] wrote: I agree that the end state is *NOT* 100% multihoming. It is too complex for most people and there is no business justification for it. But an awful lot of business customers will be able to justify multihoming. That is part and parcel of the mission critical Internet. Portability is another aspect. You mightn't need multihoming for failover (don't know about you, but my ISP is plenty reliable), but you might want the ability to be multihomed over time. Course, IPv6 makes renumbering really easy, so maybe that argument is moot. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: The secret source of humor is not joy but sorrow; there is no humor in Heaven. -- Mark Twain
Re: IPv6 news
[EMAIL PROTECTED] wrote: Another alternative is to force-align allocation and topology in some way /other/ than by Providers (geographical allocation in whatever hierarchy, IX allocation, whatever), such that networks were easily aggregatable. Lots of objections though (the providers and geography don't align one though is ultimately slightly bogus, because with non-provider-aligned allocation policies in place it would be in providers interests to align their peering to match the allocation policy). I think we need a researcher to sit down and figure out exactly what this would look like in a sample city and a sample national provider. This is one of those inversion situations where we are turning the existing model inside out. Some people may be familiar with the inversion of control in user interfaces that came about when Windows/Macintosh became the standard UI. Here, the suggestion is that netblocks should be allocated to cities, not to providers. Within a city, providers would get a subset of the city address block to meet their local infrastructure needs. They would interconnect with each other a local exchange points to exchange local traffic as Paul Vixie is suggesting here: http://news.com.com/5208-1028-0.html?forumID=1threadID=10554messageID=77189start=-1 Addresses from other cities would be viewed as a single aggregate for that city and these could be even further aggregated at some regional level such as Northwest, Southwest, Midwest, Southeast and Northeast. Err... Sounds awfully like E.164. Why don't we use phone number instead of IP numbers? We all know how well carrier phone number routing and number portability works, don't we? It's different than what we have now, but not extremely different. It is doable with IPv6 without any protocol changes because there is sufficient reserve address space available. It meets the concept of Internet as utility or mission-critical Internet because it mandates local interconnect. The customer point of view is that low latency and consistent latency is best and that mandates local interconnect. I'm sorry, but your geographical approach is broken by design. -- Andre
Re: IPv6 news
On Mon, Oct 17, 2005 at 12:08:38PM +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 28 lines which said: There are 437 cities of 1 million or more population. There are roughly 5,000 cities of over 100,000 population. And there are 3,047,000 named communities in the world. Seems to me that the number of routes in the global routing table should logically be closer to 5,000 than to 3,000,000. If there is an exchange point per city over 100,000 (the route goes to the IXP and then to the actual provider)... Otherwise, there is a flaw in your calculation.
Re: IPv6 news
On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote: I agree that the end state is *NOT* 100% multihoming. It is too complex for most people and there is no business justification for it. But an awful lot of business customers will be able to justify multihoming. That is part and parcel of the mission critical Internet. The year is 2011. Last week my DSL provider died for 6 hours and my family was unable to get to the Internet. A friend suggests I try Suparoute11 (tm), I download the program and install on my Xbox 5. A few seconds later it uses my Xbox's 802.66 wireless port to contact several other people running the program within a few blocks of my house. Options are displayed on my screen, one guy's hub is offering a backup 10Mb/s home link, tunneled and advertised to TIX across a large cable provider. My son tells me that is what I want so I setup a payment of $5 per month to him. In 10 minutes from start to finish my house's /54 is multi-homed, whatever that means. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ To stay awake all night adds a day to your life - Stilgar | eMT.
Re: IPv6 news
On Mon, 2005-10-17 at 11:39 +0100, [EMAIL PROTECTED] wrote: Another alternative is to force-align allocation and topology in some way /other/ than by Providers (geographical allocation in whatever hierarchy, IX allocation, whatever), such that networks were easily aggregatable. Lots of objections though (the providers and geography don't align one though is ultimately slightly bogus, because with non-provider-aligned allocation policies in place it would be in providers interests to align their peering to match the allocation policy). I think we need a researcher to sit down and figure out exactly what this would look like in a sample city and a sample national provider. There has been quite some research on it, there where ideas, there was even talk of a vendor going to implement it, but it never happened. It won't work because of cash reasons (read: telco/transit don't want it) For your 'city data' check: http://unstats.un.org/unsd/demographic/default.htm or for pre-processed files: http://arneill-py.sacramento.ca.us/ipv6mh/ under Geographical data. especially: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt will be quite of your liking. 8- Allocation: IANA block = 2346::/16 Ratio in use: one /48 site for 4 persons Allocation: 6bone block = 3FFE:FB00::/24 Ratio in use: one /48 site for 1024 persons 8 Which indeed seems quite reasonable. The problem with this is: 'who is paying for which traffic and to whom' One solution is an overlay network Notez bien, though this solves multihoming, it doesn't solve relocation, thus if your company moves it has to renumber, and renumbering is no fun, then again, you can most likely start from mostly scratch in the new location and you might be able to tunnel (parts of) the old allocation to the new site depending on which subnets/hosts one has moved already. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: IPv6 news
On Tue, 2005-10-18 at 01:07 +1300, Simon Lyall wrote: My son tells me that is what I want so I setup a payment of $5 per month to him. In 10 minutes from start to finish my house's /54 is multi-homed, whatever that means. You cover the payment part, partially. But now the fun parts: - which prefix - where did you get the prefix - who says you are you and thus that you are allowed to use that prefix (someone has a working PKI available? :) - routing table size? - is the other end of the possible communication going to be able to reach this prefix? - will everybody accept you as being the endpoint? - what about a broken prefix 'upstream' (you just said your primary link goes down, thus it might be a misconfig 'upstream') - insert various other 2011 stories... Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: IPv6 news
Is VJ compression considered a violation of the end-to-end principle? VJ compression happens in the middle of the network, between two routers/gateways. End-to-end refers to the hosts, i.e. the computers which host the end users' applications. Of course, in the old days, many of these hosts also carried out the function of a gateway using a dialup modem, but that is still not violating the end-to-end model because the end user application never knows about the VJ compression. NAT is different because it causes some end-user applications to fail entirely. For instance an application which sends its IP address to another host with the instructions call me back when something interesting happens. The NAT box in the middle causes the callback to fail in most cases. And end-to-end multihoming solution that is consistent with the end-to-end model will allow any application to communicate with another host even when one of the hosts moves to a different network location. BGP multihoming achieves this by announcing the small number of possible locations where a particular netblock can be found. The telephone system solves this by providing a central directory service where the network looks up an 800 number (or any portable number) to find the current location of the destination. Some people have used DNS techniques to do a similar sort of IPv4 multihoming, notably Paul Vixie and an Israeli box vendor whose name escapes me at the moment. Theoretically, in a network, a router/gateway could have some intelligence/state so that it does not simply forward packets based on destination addresses in the routing table. Instead it does some kind of query/lookup to identify the real destination location. If you stick this functionality directly in the end hosts themselves, then you have SHIM6. If you stick the functionality in the provider edge router then you have MPLS. --Michael Dillon
Re: IPv6 news
Many people pick this up and twist it into ~the network has to be application agnostic~ and then use this against NATs or firewalls, which is simply a misuse of the principle. Personally, I think that NAT's interference with the communication between hosts is similar to the way in which error-detection and retransmission interfere with realtime voice communication, as described in Saltzer's end-to-end paper: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt It seems that the end-to-end principle is more of a metaphor for how to look at the design problem rather than a hard and fast rule. http://www.postel.org/pipermail/end2end-interest/2002-March/001848.html --Michael Dillon
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Mon, 17 Oct 2005, Per Heldal wrote: Well, let's try to turn the problem on its head and see if thats clearer; Imagine an internet where only your closest neighbors know you exist. The rest of the internet knows nothing about you, except there are mechanisms that let them track you down when necessary. That is very different from today's full-routing-table. Yes, it's true that it's different, but is it better? It does not provide 100% provider-indepence to begin with. Depending on who you ask that alone is a show-stopper. Well, the reason for people wanting to stick to their own IP adresses are administrative and technical. If we solve that then hopefully, it wont be such a big hassle to renumber to go to another provider. Also, if everybody got their equal size subnet delegation from each ISP then it shouldnt be that much of a problem to run two networks side-by-side by using the subnet part of the delegation equal to both networks, but keep the prefix separate. If you switch providers you change the prefix part. This means we need new mechanisms to handle this, but I feel that's better than doing the routing mistake again. The internet shouldn't need to know anything about individual users to begin with, provided there are mechanisms avilable track them down. By that I mean that algorithms to locate end-nodes may include mechanisms to interrogate a large number of nodes to find the desired location as opposed to looking it up in a locally stored database (routing-table). So what is it you're proposing? I understand what shim6 tries to do (since it basically keeps most of todays mechanisms) but I do not understand your proposal. Could you please elaborate? I thought DNS only provided a name for an address ;) How does DNS tell us that e.g. 193.10.6.6 is part of a subnet belonging to AS2838 and how to get there? Should end users really care for that level of routing information? Also, your proposal seems to indicate that we need something that sounds like a proxy server that actually do know more about the internet and who needs to keep state, this doesn't sound scalable? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: IPv6 news
I think we need a researcher to sit down and figure out exactly what this would look like in a sample city and a sample national provider. especially: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt will be quite of your liking. Not at all. This proposal is all about allocating addresses based on country boundaries and I reject this model. The Internet is a network of cities, not countries. The national boundaries are completely random in technical terms, but the cities are not random. The cities are where the people are, where the railways and roads are, where the channels of trade and communication begin and end. Which indeed seems quite reasonable. The problem with this is: 'who is paying for which traffic and to whom' Customers pay for all the traffic on their link and they pay their money to their Internet access provider. But that is beside the point. Notez bien, though this solves multihoming, it doesn't solve relocation, thus if your company moves it has to renumber, and renumbering is no fun, Not true. If a company moves across the city and connects to a different access provider, they don't have to renumber. After all, they are still in the same city. It just means that inside that city, the providers will carry an additional longer prefix in their routing tables. But the global view will be unchanged. In fact, the smaller global table allows for much more detail to be carried locally, given the same constraints of RAM and processing power in routers. --Michael Dillon
Re: IPv6 news
man, 17,.10.2005 kl. 14.22 +0200, skrev Jeroen Massar: On Tue, 2005-10-18 at 01:07 +1300, Simon Lyall wrote: My son tells me that is what I want so I setup a payment of $5 per month to him. In 10 minutes from start to finish my house's /54 is multi-homed, whatever that means. You cover the payment part, partially. But now the fun parts: This story may be a lot closer to reality in 2011 than you seem able to accept. It's a mere illusion given limitations in current (2005) routing-protocols, but those protocols may also be nothing more than a distant memory by 2011. - which prefix Why shouldn't it be his own? - where did you get the prefix Maybe it's assigned to him? - who says you are you and thus that you are allowed to use that prefix (someone has a working PKI available? :) The allocating entity should be able to authorise that - routing table size? Who says everybody has to know about everybody else all the time. Maybe it's enough to know where to go when you need to get there. (more in other thread). - is the other end of the possible communication going to be able to reach this prefix? ditto - will everybody accept you as being the endpoint? Why not. As long as it is unique. - what about a broken prefix 'upstream' (you just said your primary link goes down, thus it might be a misconfig 'upstream') Yeah. There will probably be many failure modes in future networks too. - insert various other 2011 stories... ... and get some vision about the future. Don't assume the world will stop. //Per
Re: IPv6 news
so, if we had a free hand and ignored the dogmas, what would we change about the v6 architecture to make it really deployable and scalable and have compatibility with and a transition path from v4 without massive kludging, complexity, and long term cost? Isn't that GENI already out of the bottle? http://www.nsf.gov/cise/geni/ http://www.ana.lcs.mit.edu/papers/PDF/Rethinking_2001.pdf http://cfp.mit.edu/docs/overview.pdf http://cfp.mit.edu/groups/internet/internet.html Seems like there is enough interest in this to plan something for NANOG 36 early next year. --Michael Dillon
Re: And Now for Something Completely Different (was Re: IPv6 news)
is that anything like using, in Cisco terms, a fast-switching cache vs a FIB? On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote: Well, let's try to turn the problem on its head and see if thats clearer; Imagine an internet where only your closest neighbors know you exist. The rest of the internet knows nothing about you, except there are mechanisms that let them track you down when necessary. That is very different from today's full-routing-table.
Re: shim6 (was Re: IPv6 news)
On Sat, 15 Oct 2005, Paul Vixie wrote: ...the necessary evil called CIDR. evil because it locked customers into their providers, entrenched the existing large providers against future providers, and made it hard or impossible for the average endusing company to multihome. Uh, perhaps I'm being dense, but how does moving masking off byte boundaries have any of the above effects? -Bill
Re: And Now for Something Completely Different (was Re: IPv6 news)
man, 17,.10.2005 kl. 07.25 -0700, skrev Fred Baker: is that anything like using, in Cisco terms, a fast-switching cache vs a FIB? I'll bite as I wrote the paragraph you're quoting; Actually, hanging on to the old concepts may be more confusing than trying to look at it in completely new ways. Imagine a situation with no access to any means of direct communication (phone etc). You've got a message to deliver to some person, and have no idea where to find that person. Chances are there's a group of people nearby you can ask. They may know how to find the one you're looking for. If not they may know others they can ask on your behalf. Several iterations later the person is located and you've established a path through which you can pass the information you wanted. Translated into cisco terms this mean that the FIB is just a partial routing database, enough to start the search and otherwise handle communications in the neighborhood (no more than X router-hops, maybe AS-hops away). When the destination is located you keep that information for a while in case there are more packets going to the same place, similar to what you do with traditional route-cache. On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote: Well, let's try to turn the problem on its head and see if thats clearer; Imagine an internet where only your closest neighbors know you exist. The rest of the internet knows nothing about you, except there are mechanisms that let them track you down when necessary. That is very different from today's full-routing-table.
Re: And Now for Something Completely Different (was Re: IPv6 news)
Paul, This is completely orthogonal to a real identifier/locator split, which would divide what we know of as the 'address' into two separate spaces, one which says where the node is, topologically, and one which says who the node is. Hmm, no idea whether it's a good idea or not, but from POV of scaling while it might make 'where' scaleable, you still have to find a way to tie who to where. True. Even better, you get to change this binding (mobility) or have multiple bindings (multihoming). Some might say we already have this split though, DNS. True enough, but unfortunately, it's not done in a way that we can make use of the identifier in the routing subsystem or in the transport protocols. Tony
Re: IPv6 news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Michael! On Mon, 17 Oct 2005, [EMAIL PROTECTED] wrote: Here, the suggestion is that netblocks should be allocated to cities, not to providers. Within a city, providers would get a subset of the city address block to meet their local infrastructure needs. They would interconnect with each other a local exchange points to exchange local traffic And who is going to force the ISPs to interconnect at the city level? For competitive reasons there is no peering in my city. The nearest peering points are several hundred miles away, in different directions, and even those are not shared in common by the local ISPs. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDU9eq8KZibdeR3qURAnBfAKC4ZBCUrGq9HgW80FJxIGqfbR7mowCgi4GD ykujmYnq/FPv6MA1nKdf49A= =aUG/ -END PGP SIGNATURE-
Re: And Now for Something Completely Different (was Re: IPv6 news)
That reminds me of anycasting or routing issues. Hackers did use this technique to make use of ip addresses not really allocated. There would be no need for IPv6 if this was more widespread. How about claiming to be f.root-servers.net and setting up our own root :) Regards, Peter and Karin Dambier is that anything like using, in Cisco terms, a fast-switching cache vs a FIB? On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote: Well, let's try to turn the problem on its head and see if thats clearer; Imagine an internet where only your closest neighbors know you exist. The rest of the internet knows nothing about you, except there are mechanisms that let them track you down when necessary. That is very different from today's full-routing-table.
Re: IPv6 news
On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote: I'm not sure I agree that the end state is 100% multihoming. I can certainly agree that more multihoming is coming. Many more people are pushing for multihoming today than in previous years, apparently telco instability (financial not technical) is/has driven this :) (among other things I'm sure) I agree that the end state is *NOT* 100% multihoming. It is too complex for most people and there is no business justification for it. But an awful lot of business customers will be able to justify multihoming. That is part and parcel of the mission critical Internet. It'd be interesting to see how many 'providers' can't qualify for a /32 and will have multihomed in v6 and will thus have more than 1 /48 assigned and thus more than 1 /64 per customer... Say someone like Covad or Rythyms or perhaps even a cable-isp? In these instances each consumer will actually be multihomed, yes? The complexity just landed on your grandmama's doorstep. -Chris
Re: And Now for Something Completely Different (was Re: IPv6 news)
OK. What you just described is akin to an enterprise network with a default route. It's also akin to the way DNS works. The big question becomes not only who knows what I need to know, but how do I know that they actually know it?. For example, let's postulate that the concept is that each ISP advertises some sort of routing service that will install routes on demand, but requires that someone initiate a request for the route, and requires either the target system or the edge router in that domain that is closest to the target respond with a route. Simplistically, perhaps I am trying to route from my edge network (A) towards your edge network (B), and we are both customers of some ISP (C). The host A' that is trying to get to your host B' initiates a request. Lets presume that this goes to some name in domain A that lists all border routers, or some multicast group that they are members of. Presumably every border router does this, but for present discussion the border router in A connecting to router C' in C asks all of his peers (POPs?) for the route, and some other router C asks B's border router. B's border router has the route, and so replies; C replies to C', C' to A's border router, and that router to A'. A' can now send a message. Presumably, if someone else now ask C about the route, either C' or C, or if the route was multicast to all of C's edge routers then any router in C would be able to respond directly. This becomes more interesting if C is in fact a succession of peer ISPs or ISPs that purchase transit from other ISPs. It also becomes very interesting if some router D' is misconfigured to advertise itself as B. It's not dissimilar to ant routing. For that, there is a variety of literature; Google is your friend. In manet and sensor networks, it works pretty well, especially in the sense that once it finds a route it keeps using it while it continues working even if other routes are changing around it, and it can use local repair to deal with local changes. At least as the researchers have described it, it doesn't do policy very well, and in networks that tend to be stable (such as wired networks) its load and convergence properties can be improved on. I'll let you read there. On Oct 17, 2005, at 9:20 AM, Per Heldal wrote: man, 17,.10.2005 kl. 07.25 -0700, skrev Fred Baker: is that anything like using, in Cisco terms, a fast-switching cache vs a FIB? I'll bite as I wrote the paragraph you're quoting; Actually, hanging on to the old concepts may be more confusing than trying to look at it in completely new ways. Imagine a situation with no access to any means of direct communication (phone etc). You've got a message to deliver to some person, and have no idea where to find that person. Chances are there's a group of people nearby you can ask. They may know how to find the one you're looking for. If not they may know others they can ask on your behalf. Several iterations later the person is located and you've established a path through which you can pass the information you wanted. Translated into cisco terms this mean that the FIB is just a partial routing database, enough to start the search and otherwise handle communications in the neighborhood (no more than X router-hops, maybe AS-hops away). When the destination is located you keep that information for a while in case there are more packets going to the same place, similar to what you do with traditional route-cache. On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote: Well, let's try to turn the problem on its head and see if thats clearer; Imagine an internet where only your closest neighbors know you exist. The rest of the internet knows nothing about you, except there are mechanisms that let them track you down when necessary. That is very different from today's full-routing-table.
Re: And Now for Something Completely Different (was Re: IPv6 news)
man, 17,.10.2005 kl. 15.47 +, skrev Mikael Abrahamsson: On Mon, 17 Oct 2005, Per Heldal wrote: Well, let's try to turn the problem on its head and see if thats clearer; Imagine an internet where only your closest neighbors know you exist. The rest of the internet knows nothing about you, except there are mechanisms that let them track you down when necessary. That is very different from today's full-routing-table. Yes, it's true that it's different, but is it better? This thread, as well as most messages on this mailinglist in the last 2 days says so. Everyone uses all their energy trying to work within the limits of the current scheme. Common sense says it would be to eliminate the problem. What happens to policies if there's no limit to the size of the routing-table? It does not provide 100% provider-indepence to begin with. Depending on who you ask that alone is a show-stopper. Well, the reason for people wanting to stick to their own IP adresses are administrative and technical. If we solve that then hopefully, it wont be such a big hassle to renumber to go to another provider. I'm not so sure it will be that easy to get the flexibility you want. How do you for example enforce rules of flexibilty on *all* dns-providers. Also, if everybody got their equal size subnet delegation from each ISP then it shouldnt be that much of a problem to run two networks side-by-side by using the subnet part of the delegation equal to both networks, but keep the prefix separate. If you switch providers you change the prefix part. This means we need new mechanisms to handle this, but I feel that's better than doing the routing mistake again. True, but it creates unnecessary complexity for end-systems. It still doesn't help for scaleability on the next level up. The internet shouldn't need to know anything about individual users to begin with, provided there are mechanisms avilable track them down. By that I mean that algorithms to locate end-nodes may include mechanisms to interrogate a large number of nodes to find the desired location as opposed to looking it up in a locally stored database (routing-table). So what is it you're proposing? I understand what shim6 tries to do (since it basically keeps most of todays mechanisms) but I do not understand your proposal. Could you please elaborate? What I've got can't be called a proposal. There's no solution to propose. I just think that network complexity should be handled in the network and not by exporting the problem to connected clients. BGP and its related path-selection algorithms have served us well for many years, but there's a need for alternatives and somebody have to get involved. I thought DNS only provided a name for an address ;) How does DNS tell us that e.g. 193.10.6.6 is part of a subnet belonging to AS2838 and how to get there? Should end users really care for that level of routing information? I never said so. Their equipment, their upstream, or the upstream's upstream may need to know to get there though. Also, your proposal seems to indicate that we need something that sounds like a proxy server that actually do know more about the internet and who needs to keep state, this doesn't sound scalable? There's no proxy server involved unless you count forwarding of route location requests between inter-domain routers as proxy. If so, all intra-domain routers would be proxies. Data transport along an established forwarding path would not change. This mailinglist isn't really the place to discuss future concepts and further discussion should move to the IETF Inter-Domain-Routing working-group or other suitable forum. //Per
Re: And Now for Something Completely Different (was Re: IPv6 news)
man, 17,.10.2005 kl. 19.16 +0200, skrev Peter Dambier: That reminds me of anycasting or routing issues. Hackers did use this technique to make use of ip addresses not really allocated. There would be no need for IPv6 if this was more widespread. How about claiming to be f.root-servers.net and setting up our own root :) Yeah, you'd love that, wouldn't you? ;) Trust that security considerations would be an important part of the design of any replacement for current routing protocols. //Per
Re: And Now for Something Completely Different (was Re: IPv6 news)
Imagine a situation with no access to any means of direct communication (phone etc). You've got a message to deliver to some person, and have no idea where to find that person. Chances are there's a group of people nearby you can ask. They may know how to find the one you're looking for. If not they may know others they can ask on your behalf. Several iterations later the person is located and you've established a path through which you can pass the information you wanted. Translated into cisco terms this mean that the FIB is just a partial routing database, enough to start the search and otherwise handle communications in the neighborhood (no more than X router-hops, maybe AS-hops away). When the destination is located you keep that information for a while in case there are more packets going to the same place, similar to what you do with traditional route-cache. check out The Landmark Hierarchy: A New Hierarchy for Routing in Very Large Networks; Paul Tsuchiya; 1989. randy
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Mon, Oct 17, 2005 at 09:03:45AM -1000, Randy Bush wrote: Imagine a situation with no access to any means of direct communication (phone etc). You've got a message to deliver to some person, and have no idea where to find that person. Chances are there's a group of people nearby you can ask. They may know how to find the one you're looking for. If not they may know others they can ask on your behalf. Several iterations later the person is located and you've established a path through which you can pass the information you wanted. Translated into cisco terms this mean that the FIB is just a partial routing database, enough to start the search and otherwise handle communications in the neighborhood (no more than X router-hops, maybe AS-hops away). When the destination is located you keep that information for a while in case there are more packets going to the same place, similar to what you do with traditional route-cache. check out The Landmark Hierarchy: A New Hierarchy for Routing in Very Large Networks; Paul Tsuchiya; 1989. great stuff... i have a hardcopy. is it online yet? --bill (checking citesear...) randy
Re: And Now for Something Completely Different (was Re: IPv6 news)
mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker: OK. What you just described is akin to an enterprise network with a default route. It's also akin to the way DNS works. No default, just one or more *potential* routes. Your input is appreciated, and yes I'm very much aware that many people who maintain solutions that assume full/total control of the entire routing-table will be screaming bloody murder if that is going to change. Further details about future inter-domain-routing concepts belong in other fora (e.g. ietf's inter-domain-routing wg). The long-term operational impact is that the current inter-domain-routing concepts (BGP etc) don't scale indefinitely and will have to be changed some time in the future. Thus expect the size of the routing-table to be eliminated from the list of limiting factors, or that the bar is considerably raised. --- Note that I'm not saying that nothing should be done to preserve and optimise the use of the resources that are available today just because there will be something better available in a distant future. I'm in favor of the most restrictive allocation policies in place today. The development of the internet has for a long time been based on finding better ways to use available resources (CIDR anyone). To me a natural next-step in that process is for RIR's to start reclaiming unused v4 address-blocks, or at least start collect data to document that space is not being used (if they're not already doing so). E.g prevously announced address-blocks that has disappeared from the global routing-table for more than X months should go back to the RIR-pool (X=6). //Per
Re: And Now for Something Completely Different (was Re: IPv6 news)
check out The Landmark Hierarchy: A New Hierarchy for Routing in Very Large Networks; Paul Tsuchiya; 1989. great stuff... i have a hardcopy. is it online yet? dunno if i would say great. but certainly good. http://portal.acm.org/citation.cfm?id=52329 randy
Re: And Now for Something Completely Different (was Re: IPv6 news)
--bill (checking citesear...) does that only yield rare papers :-) and citeseer does not have the paper, only a few cites to it randy
Re: And Now for Something Completely Different (was Re: IPv6 news)
That is an assumption that I haven't found it necessary to make. I have concluded that there is no real debate about whether the Internet will have to change to something that gives us the ability to directly address (e.g. not behind a NAT, which imposes some interesting requirements at the application layer and gateways of the sort which were what the Internet came about to not need) a whole lot more things than it does today. The debate is about how and when. when seems pretty solidly in the 3-10 year timeframe, exactly where in that timeframe being a point of some discussion, and how comes down to a choice of IPv6 or something else. Fleming's IPv8 was a non-stupid idea that has a fundamental flaw in that it re-interprets parts of the IPv4 header as domain identifiers - it effectively extends the IP address by 16 bits, which is good, but does so in a way that is not backward compatible. If we could make those 16 bits be AS numbers (and ignoring for the moment the fact that we seem to need larger AS numbers), the matter follows pretty quickly. If one is going to change the header, though, giving up fragmentation as a feature sees a little tough; one may as well change the header and manage to keep the capability. One also needs to change some other protocols, such as routing AS numbers and including them in DNS records as part of the address. From my perspective, we are having enough good experience with IPv6 that we should simply choose that approach; there isn't a real good reason to find a different one. Yes, that means there is a long coexistence period yada yada yada. This is also true of any other fundamental network layer protocol change. The RIRs have been trying pretty hard to make IPv6 allocations be one prefix per ISP, with truly large edge networks being treated as functionally equivalent to an ISP (PI addressing without admitting it is being done). Make the bald assertion that this is equal to one prefix per AS (they're not the same statement at all, but the number of currently assigned AS numbers exceeds the number of prefixes under discussion, so in my mind it makes a reasonable thumb-in-the-wind- guesstimate), that is a reduction of the routing table size by an order of magnitude. If we are able to reduce the routing table size by an order of magnitude, I don't see that we have a requirement to fundamentally change the routing technology to support it. We may *want* to (and yes, I would like to, for various reasons), but that is a different assertion. On Oct 17, 2005, at 12:42 PM, Per Heldal wrote: mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker: OK. What you just described is akin to an enterprise network with a default route. It's also akin to the way DNS works. No default, just one or more *potential* routes. Your input is appreciated, and yes I'm very much aware that many people who maintain solutions that assume full/total control of the entire routing-table will be screaming bloody murder if that is going to change. Further details about future inter-domain-routing concepts belong in other fora (e.g. ietf's inter-domain-routing wg). The long-term operational impact is that the current inter-domain- routing concepts (BGP etc) don't scale indefinitely and will have to be changed some time in the future. Thus expect the size of the routing-table to be eliminated from the list of limiting factors, or that the bar is considerably raised. --- Note that I'm not saying that nothing should be done to preserve and optimise the use of the resources that are available today just because there will be something better available in a distant future. I'm in favor of the most restrictive allocation policies in place today. The development of the internet has for a long time been based on finding better ways to use available resources (CIDR anyone). To me a natural next-step in that process is for RIR's to start reclaiming unused v4 address-blocks, or at least start collect data to document that space is not being used (if they're not already doing so). E.g prevously announced address-blocks that has disappeared from the global routing-table for more than X months should go back to the RIR-pool (X=6). //Per
Re: And Now for Something Completely Different (was Re: IPv6 news)
Fred, If we are able to reduce the routing table size by an order of magnitude, I don't see that we have a requirement to fundamentally change the routing technology to support it. We may *want* to (and yes, I would like to, for various reasons), but that is a different assertion. There is a fundamental difference between a one-time reduction in the table and a fundamental dissipation of the forces that cause it to bloat in the first place. Simply reducing the table as a one-off only buys you linearly more time. Eliminating the drivers for bloat buys you technology generations. If we're going to put the world thru the pain of change, it seems that we should do our best to ensure that it never, ever has to happen again. Regards, Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
works for me - I did say I'd like to change the routing protocol - but I think the routing protocol can be changed asynchronously, and will have to. On Oct 17, 2005, at 1:51 PM, Tony Li wrote: Fred, If we are able to reduce the routing table size by an order of magnitude, I don't see that we have a requirement to fundamentally change the routing technology to support it. We may *want* to (and yes, I would like to, for various reasons), but that is a different assertion. There is a fundamental difference between a one-time reduction in the table and a fundamental dissipation of the forces that cause it to bloat in the first place. Simply reducing the table as a one- off only buys you linearly more time. Eliminating the drivers for bloat buys you technology generations. If we're going to put the world thru the pain of change, it seems that we should do our best to ensure that it never, ever has to happen again. Regards, Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
It doesn't look like were talking about the same thing. A. Address conservation and aggregation (IPv4 and IPv6) is very important to get the most out of what we've got. Read; limit the combined routing-table to a manageable size whatever that may be. B. There seems to be widespread fear that the global routing-table will grow to a non-manageable size sooner or later regardless of the efforts under A. So the limit has to be removed. What you address below mostly belong under A (and I mostly agree), whereas I so far have focused on B. On Mon, 2005-10-17 at 13:12 -0700, Fred Baker wrote: That is an assumption that I haven't found it necessary to make. I have concluded that there is no real debate about whether the Internet will have to change to something that gives us the ability to directly address (e.g. not behind a NAT, which imposes some interesting requirements at the application layer and gateways of the sort which were what the Internet came about to not need) a whole lot more things than it does today. The debate is about how and when. when seems pretty solidly in the 3-10 year timeframe, exactly where in that timeframe being a point of some discussion, and how comes down to a choice of IPv6 or something else. Sure, something has to replace IPv4 sooner or later and IPv6 is almost certainly the thing. Personally I belive the most trustworthy projections points towards 2010 as the time we'll run out of addresses in V4 with an additional 2-3 years if we can manage to reclaim up to 90% of those previously allocated addressblocks which are not used or not announced to the public internet. Fleming's IPv8 was a non-stupid idea that has a fundamental flaw in that it re-interprets parts of the IPv4 header as domain identifiers - it effectively extends the IP address by 16 bits, which is good, but does so in a way that is not backward compatible. If we could make those 16 bits be AS numbers (and ignoring for the moment the fact that we seem to need larger AS numbers), the matter follows pretty quickly. If one is going to change the header, though, giving up fragmentation as a feature sees a little tough; one may as well change the header and manage to keep the capability. One also needs to change some other protocols, such as routing AS numbers and including them in DNS records as part of the address. For the record: You brought up IPv8. Nothing of what I've mentioned requires any change to transport protocols wether implemented on top of IPv4 or 6. From my perspective, we are having enough good experience with IPv6 that we should simply choose that approach; there isn't a real good reason to find a different one. Yes, that means there is a long coexistence period yada yada yada. This is also true of any other fundamental network layer protocol change. The RIRs have been trying pretty hard to make IPv6 allocations be one prefix per ISP, with truly large edge networks being treated as functionally equivalent to an ISP (PI addressing without admitting it is being done). Make the bald assertion that this is equal to one prefix per AS (they're not the same statement at all, but the number of currently assigned AS numbers exceeds the number of prefixes under discussion, so in my mind it makes a reasonable thumb-in-the-wind- guesstimate), that is a reduction of the routing table size by an order of magnitude. I wouldn't even characterise that as being bald. Initial allocations of more than one prefix per AS should not be allowed. Further; initial allocations should differentiate between network of various sizes into separate address-blocks to simplify and promote strict prefix-filtering policies. Large networks may make arrangements with their neighbors to honor more specifics, but that shouldn't mean that the rest of the world should accept those. If we are able to reduce the routing table size by an order of magnitude, I don't see that we have a requirement to fundamentally change the routing technology to support it. We may *want* to (and yes, I would like to, for various reasons), but that is a different assertion. Predictions disagree. //Per
Re: And Now for Something Completely Different (was Re: IPv6 news)
works for me - I did say I'd like to change the routing protocol - but I think the routing protocol can be changed asynchronously, and will have to. and that is what the other v6 ivory tower crew said a decade ago. which is why we have the disaster we have now. randy
Re: And Now for Something Completely Different (was Re: IPv6 news)
There is a fundamental difference between a one-time reduction in the table and a fundamental dissipation of the forces that cause it to bloat in the first place. Simply reducing the table as a one-off only buys you linearly more time. Eliminating the drivers for bloat buys you technology generations. If we're going to put the world thru the pain of change, it seems that we should do our best to ensure that it never, ever has to happen again. That's the goal here? To ensure we'll never have another protocol transition? I hope you realize what a flawed statement that is. tony probably did not think about it because that's not what he said at all. he was speaking of routing table bloat, not transitions. and he was spot on. randy
Re: And Now for Something Completely Different (was Re: IPv6 news)
At 04:51 PM 10/17/2005, Tony Li wrote: Fred, If we are able to reduce the routing table size by an order of magnitude, I don't see that we have a requirement to fundamentally change the routing technology to support it. We may *want* to (and yes, I would like to, for various reasons), but that is a different assertion. There is a fundamental difference between a one-time reduction in the table and a fundamental dissipation of the forces that cause it to bloat in the first place. Simply reducing the table as a one-off only buys you linearly more time. Eliminating the drivers for bloat buys you technology generations. If we're going to put the world thru the pain of change, it seems that we should do our best to ensure that it never, ever has to happen again. But wasn't that the rationale for originally putting the kitchen sink into IPv6, rather than fixing the address length issue? I think we missed a lot of opportunities. Extended addressing may well have been possible to integrate in the mid 1990's ahead of much of the massive Internet expansion. Too late. We're 10 years on, and talking about whether there will need to be more than one massive pain of migration, because the kitchen sink didn't take into account multihoming. Now we're talking about a solution that appear to be an even worse Rube Goldberg than token ring source-route bridging. Moore will likely have to continue to produce the solution.
Re: And Now for Something Completely Different (was Re: IPv6 news)
Daniel, If we're going to put the world thru the pain of change, it seems that we should do our best to ensure that it never, ever has to happen again. That's the goal here? To ensure we'll never have another protocol transition? I hope you realize what a flawed statement that is. We can't see into the future. However, assuming that IPv6 is the Last Protocol seems a bit short sighted. If we get 20 years out of IPv6, that will be just peachy. I see that as a worthy goal and no, I don't see that as flawed. While we certainly cannot guarantee that v6 will be the last protocol, we should certainly be designing for it to be the best that we can possibly make it. Just how many times do you think that we will replace all implementations? This change is simply fundamental to the way the Internet works. There is almost as much pain associated with this change as if we were to change the electric outlet voltage in every single country to a mutually incompatible standard. Can you imagine power companies making that change and then telling consumers to expect another such change in 20 years? To not even *attempt* to avoid future all-systems changes is nothing short of negligent, IMHO. Of course, if we can't get PI address space for enterprises and real multihoming, there won't be any real IPv6 deployment. Lots of (possibly illegitimate) IPv4 trading and NAT, but not IPv6. These aren't nice to haves. Even if it shortens the life of IPv6, that is an acceptable trade-off. IPv6 is not the Last Protocol. If you do get PI space for multihoming, then by definition, it cannot be the last protocol. In fact, it will have cemented v6's lifetime as just 10 more years. Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
we agree that at least initially every prefix allocated should belong to a different AS (eg, no AS gets more than one); the fly in that is whether there is an ISP somewhere that is so truly large that it needs two super-sized blocks. I don't know if such exists, but one hopes it is very much the exception. The question is does every AS get a prefix. Under current rules, most AS's assigned to edge networks to support multihoming will not get a prefix. I personally think that's probably the wrong answer (eg, you and I seem to agree on PI space for networks that would warrant an AS number does to size, connectivity, and use of BGP to manage their borders), but it is the current answer. On Oct 17, 2005, at 2:06 PM, Per Heldal wrote: The RIRs have been trying pretty hard to make IPv6 allocations be one prefix per ISP, with truly large edge networks being treated as functionally equivalent to an ISP (PI addressing without admitting it is being done). Make the bald assertion that this is equal to one prefix per AS (they're not the same statement at all, but the number of currently assigned AS numbers exceeds the number of prefixes under discussion, so in my mind it makes a reasonable thumb-in-the-wind- guesstimate), that is a reduction of the routing table size by an order of magnitude. I wouldn't even characterise that as being bald. Initial allocations of more than one prefix per AS should not be allowed. Further; initial allocations should differentiate between network of various sizes into separate address-blocks to simplify and promote strict prefix-filtering policies. Large networks may make arrangements with their neighbors to honor more specifics, but that shouldn't mean that the rest of the world should accept those.
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Oct 17, 2005, at 2:24 PM, Tony Li wrote: To not even *attempt* to avoid future all-systems changes is nothing short of negligent, IMHO. On Oct 17, 2005, at 2:17 PM, Randy Bush wrote: and that is what the other v6 ivory tower crew said a decade ago. which is why we have the disaster we have now. and there I would agree, on both points. now, the proposal put forward lo these many moons ago to avoid any possibility of a routing change was, as I recall, Nimrod, and the Nimrod architecture called for variable length addresses in the network layer protocol and the use of a flow label (as in IPv6 flow label) as a short-form address in some senses akin to a virtual circuit ID. There has been a lot of work on that in rrg among other places, but the word from those who would deploy it has been uniformly think in terms of an incremental upgrade to BGP and maybe MPLS will work as a virtual circuit ID if we really need one. As you no doubt recall all too well, the variable length address was in fact agreed on at one point, but that failed for political reasons. Something about OSI. The 16 byte length of an IPv6 address derived from that as well - it didn't allow one to represent an NSAP in IPv6, which was an objective. So the routing problem was looked at, and making a fundamental routing change was rejected by both the operational community and the routing folks. No, IPv6 doesn't fix (or even change) the routing of the system, and that problem will fester until it becomes important enough to change. But lets not blame that on the ivory tower folks, at least not wholly. We were all involved.
Re: And Now for Something Completely Different (was Re: IPv6 news)
On Mon, 17 Oct 2005 14:24:08 -0700 Tony Li [EMAIL PROTECTED] wrote: Dear Tony et al.; This is beginning to sound like an IETF or IRTF mail list, and, lo!, I get an email today from Leslie Daigle : A new mailing list has been created to provide a forum for general discussion of Internet architectural issues: [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/architecture-discuss The architecture-discuss list serves as a technical discussion forum for all members of the IETF community that are interested in larger architectural issues. It is meant to be an open discussion forum for all long and/or wide range architectural concerns related to the Internet Architecture. In particular, it may be used to discuss and bring forth different points of view on controversial architectural questions. Discussions that drill down and dwell on specifics of individual protocols or technologies are to be discouraged, redirected to appropriate other fora, or re-cast to discussions of broader implications for Internet architecture. Maybe this conversation should move there. Maybe a lot of operators should join that list. Probably couldn't hurt. Regards Marshall Eubanks Daniel, If we're going to put the world thru the pain of change, it seems that we should do our best to ensure that it never, ever has to happen again. That's the goal here? To ensure we'll never have another protocol transition? I hope you realize what a flawed statement that is. We can't see into the future. However, assuming that IPv6 is the Last Protocol seems a bit short sighted. If we get 20 years out of IPv6, that will be just peachy. I see that as a worthy goal and no, I don't see that as flawed. While we certainly cannot guarantee that v6 will be the last protocol, we should certainly be designing for it to be the best that we can possibly make it. Just how many times do you think that we will replace all implementations? This change is simply fundamental to the way the Internet works. There is almost as much pain associated with this change as if we were to change the electric outlet voltage in every single country to a mutually incompatible standard. Can you imagine power companies making that change and then telling consumers to expect another such change in 20 years? To not even *attempt* to avoid future all-systems changes is nothing short of negligent, IMHO. Of course, if we can't get PI address space for enterprises and real multihoming, there won't be any real IPv6 deployment. Lots of (possibly illegitimate) IPv4 trading and NAT, but not IPv6. These aren't nice to haves. Even if it shortens the life of IPv6, that is an acceptable trade-off. IPv6 is not the Last Protocol. If you do get PI space for multihoming, then by definition, it cannot be the last protocol. In fact, it will have cemented v6's lifetime as just 10 more years. Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
- Original Message - From: Fred Baker [EMAIL PROTECTED] To: Per Heldal [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Monday, October 17, 2005 15:12 Subject: Re: And Now for Something Completely Different (was Re: IPv6 news) That is an assumption that I haven't found it necessary to make. I have concluded that there is no real debate about whether the Internet will have to change to something that gives us the ability to directly address (e.g. not behind a NAT, which imposes some interesting requirements at the application layer and gateways of the sort which were what the Internet came about to not need) a whole lot more things than it does today. The debate is about how and when. when seems pretty solidly in the 3-10 year timeframe, exactly where in that timeframe being a point of some discussion, and how comes down to a choice of IPv6 or something else. Fleming's IPv8 was a non-stupid idea that has a fundamental flaw in that it re-interprets parts of the IPv4 header as domain identifiers - it effectively extends the IP address by 16 bits, which is good, but does so in a way that is not backward compatible. If we could make those 16 bits be AS numbers (and ignoring for the moment the fact that we seem to need larger AS numbers), the matter follows pretty quickly. If one is going to change the header, though, giving up fragmentation as a feature sees a little tough; one may as well change the header and manage to keep the capability. One also needs to change some other protocols, such as routing AS numbers and including them in DNS records as part of the address. From my perspective, we are having enough good experience with IPv6 that we should simply choose that approach; there isn't a real good reason to find a different one. Yes, that means there is a long coexistence period yada yada yada. This is also true of any other fundamental network layer protocol change. The RIRs have been trying pretty hard to make IPv6 allocations be one prefix per ISP, with truly large edge networks being treated as functionally equivalent to an ISP (PI addressing without admitting it is being done). Make the bald assertion that this is equal to one prefix per AS (they're not the same statement at all, but the number of currently assigned AS numbers exceeds the number of prefixes under discussion, so in my mind it makes a reasonable thumb-in-the-wind- guesstimate), that is a reduction of the routing table size by an order of magnitude. If we are able to reduce the routing table size by an order of magnitude, I don't see that we have a requirement to fundamentally change the routing technology to support it. We may *want* to (and yes, I would like to, for various reasons), but that is a different assertion. On Oct 17, 2005, at 12:42 PM, Per Heldal wrote: mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker: OK. What you just described is akin to an enterprise network with a default route. It's also akin to the way DNS works. No default, just one or more *potential* routes. Your input is appreciated, and yes I'm very much aware that many people who maintain solutions that assume full/total control of the entire routing-table will be screaming bloody murder if that is going to change. Further details about future inter-domain-routing concepts belong in other fora (e.g. ietf's inter-domain-routing wg). The long-term operational impact is that the current inter-domain- routing concepts (BGP etc) don't scale indefinitely and will have to be changed some time in the future. Thus expect the size of the routing-table to be eliminated from the list of limiting factors, or that the bar is considerably raised. --- Note that I'm not saying that nothing should be done to preserve and optimise the use of the resources that are available today just because there will be something better available in a distant future. I'm in favor of the most restrictive allocation policies in place today. The development of the internet has for a long time been based on finding better ways to use available resources (CIDR anyone). To me a natural next-step in that process is for RIR's to start reclaiming unused v4 address-blocks, or at least start collect data to document that space is not being used (if they're not already doing so). E.g prevously announced address-blocks that has disappeared from the global routing-table for more than X months should go back to the RIR-pool (X=6). //Per
Re: And Now for Something Completely Different (was Re: IPv6 news)
Thus spake Fred Baker [EMAIL PROTECTED] The RIRs have been trying pretty hard to make IPv6 allocations be one prefix per ISP, with truly large edge networks being treated as functionally equivalent to an ISP (PI addressing without admitting it is being done). Make the bald assertion that this is equal to one prefix per AS (they're not the same statement at all, but the number of currently assigned AS numbers exceeds the number of prefixes under discussion, so in my mind it makes a reasonable thumb-in-the-wind- guesstimate), that is a reduction of the routing table size by an order of magnitude. If we are able to reduce the routing table size by an order of magnitude, I don't see that we have a requirement to fundamentally change the routing technology to support it. We may *want* to (and yes, I would like to, for various reasons), but that is a different assertion. If we reduce the average number of prefixes per AS by an order of magnitude, IMHO the result will be that there will be an order of magnitude growth in the number of ASes. We're just going to trade one problem for another. What we need is an interdomain routing system that can either (a) drastically reduce the incremental cost of additional prefixes in the DFZ, or (b) move the exist cost out of the DFZ to the people who want to multihome. Both probably mean ditching BGP4 and moving to some sort of inter-AS MPLS scheme, but it will never see the light of day unless it allows leaving hosts and intra-site routing intact (i.e. hop-by-hop routing and a single prefix per site). This last is why shim6 is DOA. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: And Now for Something Completely Different (was Re: IPv6 news)
What we need is an interdomain routing system that can either (a) drastically reduce the incremental cost of additional prefixes in the DFZ, or (b) move the exist cost out of the DFZ to the people who want to multihome. Both probably mean ditching BGP4 and moving to some sort of inter-AS MPLS scheme, but it will never see the light of day unless it allows leaving hosts and intra-site routing intact (i.e. hop-by-hop routing and a single prefix per site). This last is why shim6 is DOA. or... drop the idea of A/THE default free zone and recognize that the concept is based on a flawed assumption. --bill S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: And Now for Something Completely Different (was Re: IPv6 news)
Fred, So the routing problem was looked at, and making a fundamental routing change was rejected by both the operational community and the routing folks. No, IPv6 doesn't fix (or even change) the routing of the system, and that problem will fester until it becomes important enough to change. From this end of the elephant, we looked at Nimrod and saw potential there, but did not buy off on it. We also looked at GSE and the routing folks at the very least seemed bought into that, but it died, under what I would characterize as a purely political hailstorm. Yes, the lack of a scalable routing architecture will continue to fester until it has sufficient political visibility that it exceeds our pain threshold and we decide to make the change. The problem with this model is that the pain of change grows daily. Each and every v6 system that is deployed is yet another bit of installed base that will need to be updated someday. The Internet community needs the IETF leadership to understand this very clearly and to take action to resolve this issue sooner, not later. As others have said, this is a pay now or pay later situation, and the pay later portion is MUCH more expensive. Specifically, the IAB should call for a halt to IPv6 deployment until consensus is reached on a scalable routing architecture. I realize that this is painful, but continuing to deploy is simply creating a v6 mortgage that we cannot afford to pay off. Regards, Tony
Re: And Now for Something Completely Different (was Re: IPv6 news)
[EMAIL PROTECTED] (Tony Li) writes: Specifically, the IAB should call for a halt to IPv6 deployment until consensus is reached on a scalable routing architecture. I realize that this is painful, but continuing to deploy is simply creating a v6 mortgage that we cannot afford to pay off. well, maybe so. but IAB could never make deployment start, and IAB cannot make deployment stop. deployment happens on its own terms. leadership has a built in time delay and a couple layers of indirection between intent and action and results. if you want IAB to lead somehow, give them some runway. -- Paul Vixie
