Re: Stupid Ipv6 question...
Hi Dan, I've got some slides from talks I've done, they cover this sortof stuff. You can see at http://www.sixlabs.org/talks/ Additionally, the size is 2^(128-prefixlen) [more or less] But you don't use all of them, obviously, it'd be fairly difficult, best part about a /64 is EUI-64 works (auto-address allocation based on MAC address) if you advertise it with radvd [or rtadvd if your freebsd, no idea about other oss, radvd seems to work in most places] Cheers, Trent Bur.st On Fri, Nov 19, 2004 at 03:06:43AM -0500, Dan Mahoney, System Admin wrote: In preparation for the upcoming advent of ipv6, I'm playing with a tunnel I've gotten from HE's cool tunnelbroker, and I'm plagued by the question that about an hour of google searching can't answer for me. I'm having trouble wrapping my head around ipv6 style suffixes -- does anyone have a chart handy? How big is a /64, specifically? Most of the tutorials I've found seem to be a bit over-the-top on this. -Dan -- Wrin quick, somebody tell me the moon phase please? Dan_Wood Wrin: Plummeting. -Undernet #reboot, 9/11/01 (day of the WTC bombing) Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- -- Trent Lloyd [EMAIL PROTECTED] Bur.st Networking Inc.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 17:58, Stephen Sprunk wrote: these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations. Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? That's right. If you need internet access, you need it to be faster than 16 kbps. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space. If I have a disconnected network, why would I use NATs or be forced to renumber periodically? I have no idea. Use unique local addresses instead. Why should disconnected networks use global addresses (and pay rent to the RIRs) in the first place? There aren't many networks around that are truly disconnected. Even disconnected networks connect to stuff that connects to other stuff that connects to the internet at some point. This means that disconnected address space must not overlap with addresses used on the internet. We have that in RFC 1918. However, disconnected networks tend to interconnect with other disconnected networks from time to time, which means trouble if they both use the same address space. This is where ULAs come to the rescue.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 18:50, Christian Kuhtz wrote: why would the enterprise care to switch to IPv6 in the first place? Because it's easier to build a big IPv6 network than to build a big IPv4 network. I think over the next few years we'll see people building IPv6 networks and then tunneling IPv4 over them as it's easier to have the infrastructure parts run IPv6, especially (but not exclusively) if IPv4 address space is less than abundant. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged Yes; I don't care. I'm assuming it is not possible to leave this out, but could you please have some kind of separator between your actual message and the lawyerese so it's easier to ignore the latter?
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 19:23, Owen DeLong wrote: There is no reason for RIRs to allocate addresses which would never be used on public networks. If the addresses are suppose to be unique, then, what is the reason NOT to have the RIRs allocate them? The reason is that the RIRs don't talk to end-users. (At least, they don't talk to 99.99% of all end-users.) Having to go through a LIR (ISP) to obtain addresses that may remain in use after a customer leaves also seems strange. Why set up a separate registry system for these addresses instead of making minor changes to the existing one to accommodate this need? This is a good point. But rather than reuse the RIRs for this, we should reuse the domain registry system for this. Domain sellers already know how to deal with millions of customers (collectively) and make a business based on very small yearly fees, they already deal with the majority of the prospective users of this address space and there is healthy competition.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 18:40, Owen DeLong wrote: Now I hate to be the bearer of bad news, but having unaggregatable globally routable address space just doesn't scale and there are no routing tricks that can make it scale, whatever you put in the IP version bits, so learn to love renumbering. This is patently false. If it were true, then I would have to renumber every time I changed telephone companies. I don't, so, obviously, there is some solution to this problem. Well, the old saying is that there is no problem in computer science that can't be solved by adding a layer of indirection. Apparently this applies to telephone networks as well, because your phone number is no longer an address these days: it's more like a domain name. When you dial a number it's looked up in a big database to see where the call should go to. And don't forget that you still have to change your phone number when you move a great enough distance. In IP we somehow feel it's important that there are no geographical constraint on address use at all. That's a shame, because even if we aggregate by contintent that would save up to four times in the number of entries in the routing table of any router.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
--On 19 November 2004 09:40 -0800 Owen DeLong [EMAIL PROTECTED] wrote: If it were true, then I would have to renumber every time I changed telephone companies. I don't, so, obviously, there is some solution to this problem. But I'm not sure you'd like it applied to the internet. Firstly, in essence, PSTN uses static routes for interprovider routing (not quite true, but nearly - if you add a new prefix everyone else has to build it into their table on all switches). Secondly, IIRC porting works in the UK something like - call delivered to switch of operator who owns the block, marked as ported number, lookup in central porting database (one for all operators), operator port prefix put on dialed number, call sent back out all the way to interconnect, enters new operator network, goes to switch managing ports, further signalling info added to make call go to the correct local switch, call goes to correct local switch, dross removed, call terminated. Roughly speaking this is the internet equivalent of: * Configure all interprovider routes by a static routing config loaded every week or so. * Handle porting by getting ICANN to run a box with a primative gated BGP feed connected to all your distribution routers. Where a packet is delivered to a distribution router and the IP address has changed providers, change the next hop received from the ICANN BGP feed to a GRE tunnel to the appropriate provider's tunnel termination box. * At that tunnel termination box, static route all ported-in IP addresses to the correct distribution router. Yum yum. Sometimes we don't have lessons to learn from the PSTN world, and instead the reverse is true. Alex
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 11/20/2004 8:18 AM, Alex Bligh wrote: But I'm not sure you'd like it applied to the internet. Firstly, in essence, PSTN uses static routes for interprovider routing (not quite true, but nearly - if you add a new prefix everyone else has to build it into their table on all switches). Secondly, IIRC porting works in the UK something like - call delivered to switch of operator who owns the block, marked as ported number, lookup in central porting database (one for all operators), operator port prefix put on dialed number, call sent back out all the way to interconnect, enters new operator network, goes to switch managing ports, further signalling info added to make call go to the correct local switch, call goes to correct local switch, dross removed, call terminated. Sounds like DNS. We also get semi-annual drive-by proposals to stick the routing info into DNS, of course. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sat, Nov 20, 2004 at 12:58:17PM +0100, Iljitsch van Beijnum wrote: On 19-nov-04, at 17:58, Stephen Sprunk wrote: Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. it is not rare at all, in my experience. my personal dealings with 50+ multinational corporations show that they -ALL- have their own corporate networks that are isolated from the Internet and nearly all run IP over these internal corporate networks. the trival cost of dedicated lines, or FR/ATM cloud, or VPN overlay is much cheaper than a dependance on upstream providers (since no single provider can support their needs) or exposing corporate/trade secrets to the broader internet. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. that does not follow, except from your faulty presumption above. -- bill
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 19-nov-04, at 17:58, Stephen Sprunk wrote: Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? That's right. If you need internet access, you need it to be faster than 16 kbps. Who said the only purpose of IP was to connect to the Internet? 16kbps is the lowest I've seen only because that's the smallest you can buy in the FR world (Sprint's 0kbps PVCs aside). Many businesses were fine (and still would be) using 2400 baud leased lines and upgraded to FR only because it cost slightly less. A couple cashiers typing text into a green-screen app don't need blazingly-fast IP service, nor would their employer be interested in paying them to surf the web while customers are waiting. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. At higher bw levels, that might be true, but at sub-T1 rates FR/ATM are often cheaper to build your own network and certainly offer lower latency and higher reliability; ditto for outside major cities, where FR/ATM typically offers a zero-mile loop whereas IP connections may need to be backhauled a hundred miles or more. If T1 Internet pipes are cheaper at a particular location, some people may choose to tunnel their corporate network over it, but that is typically _all_ traffic, not just internal traffic. There's also a security motivation as well: it's much simpler to maintain a couple firewalls at central sites (with technical staff present) than to manage thousands out at every site with a handful or even zero human users which may not even be allowed Internet access in the first place. Even Cisco, last I checked, only connected to the Internet in four places worldwide, though they have hundreds of offices (and full private internal connectivity). Presumably they know what they're doing, or at least have a better clue than enterprises in other industries. Consider that a best case. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone. learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space. If I have a disconnected network, why would I use NATs or be forced to renumber periodically? I have no idea. Use unique local addresses instead. Exactly. Why should disconnected networks use global addresses (and pay rent to the RIRs) in the first place? There aren't many networks around that are truly disconnected. Even disconnected networks connect to stuff that connects to other stuff that connects to the internet at some point. This means that disconnected address space must not overlap with addresses used on the internet. We have that in RFC 1918. However, disconnected networks tend to interconnect with other disconnected networks from time to time, which means trouble if they both use the same address space. This is where ULAs come to the rescue. ...and that's why ULAs were proposed by the IPv6 WG. Even networks that have no connectivity to the Internet are often connected to each other, and a subset of those networks will eventually have connectivity to the Internet or another network that does. But there are some truly disconnected networks as well, and ULAs are still a better choice than randomly picking a prefix out of 0::0. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Paul Vixie [EMAIL PROTECTED] [EMAIL PROTECTED] (Stephen Sprunk) writes: isc is multihomed, so it's difficult to imagine what isp we could have taken address space from then, or now. ... Some fear that you would more likely just generate a ULA, use that internally, and NAT at the borders. Or maybe you'd stick with IPv4 RFC1918 space internally and NAT to IPv6 PA space at your borders. the internet endpoint type trend is toward SOHO and dsl/cable, and the provider trend is toward gigantic multinational. companies who build their own networks tend to find that the cheapest interoffice backhaul is IP-in-IP VPN's. thus is the old model of a 1000-person company buying a T1 transit connection moving toward the margins. I'm not experienced with the 1000-person companies; the work I've done is for companies 20 to 100 times that size, so maybe my perception is skewed. SoHo and residential users are definitely a growing percentage of the Internet connection count, but I think they're still a minority of _hosts_ which have Internet connectivity. Enterprises can have tens or hundreds of thousands of hosts behind a single T1 or T3, and may expose only a handful of PA addresses due to NAT. Large universities are similar, except legacy allocations mean they usually don't need NAT. I've also seen a strong tendency in enterprises to backhaul even external traffic on IP VPNs, so that even users with a local Internet pipe have to go through the corporate firewalls to reach the outside world (if that's even allowed). as i continue to research my own premises, i find that the style of internetworking practiced at isc, which precludes PA space due to multihoming and due to possible renumbering penalties, So are you saying that if ISC had not gotten a legacy PI allocation, you wouldn't be using IPv6? Or that you wouldn't be able to design your network the way you'd want to, but would still use IPv6 anyways? is becoming quite rare as a percentage of the total number of network owners and the total number of endpoints thus interconnected. it's sad but it's true and it gives cause to ponder the future of enabling technologies like internet exchange points. I've run into very few enterprises that know they'd even be allowed to join an IX, much less actually interested in doing so. They'd rather pay one or two companies to drop big, fat pipes into their datacenter and collect on SLAs when something goes wrong. Very few, even in the Fortune 100, have the staff to handle their own BGP configs and keep things running smoothly. Humans cost more money than they'd probably save on transit, and the money often comes out of different pockets anyways. I see IXes (IXen?) as a solution for providers, not end-sites. With the relatively lax IPv6 PI policies for providers, the threat to IXes is minimal. this may yet lead to a mechanism for qualifying multihomed network builders to get PI space, since they'll be rare enough to have a low impact on the global routing table. We'll see what the reaction is on PPML. Based on the number of origin-only ASes in yesterday's Routing Table Report, we should expect to see about 16k prefixes from multihomed end-sites if adoption in IPv6 matches that in IPv4. on the other hand, transit-provider lock-in is not officially recognized as having any bearing on any RIR policy in any region; if that continues to be the case, the rare kind of network i'm most familiar with will continue to use ipv4 or will only use ipv6 via something like ULA's. what this may mean is that approving ULA's will make the situation better, since network owners will otherwise just pirate unused space at random. with ULA's we'll at least have a chance to trace leaks and try to make BCP38 happen in more places. Agreed. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] Why set up a separate registry system for these addresses instead of making minor changes to the existing one to accommodate this need? This is a good point. But rather than reuse the RIRs for this, we should reuse the domain registry system for this. Domain sellers already know how to deal with millions of customers (collectively) and make a business based on very small yearly fees, they already deal with the majority of the prospective users of this address space and there is healthy competition. This makes perfect sense. After all, RIRs are just renting domains out of in-addr.arpa. and ip6.arpa. whereas domain registrars are renting domains out of other TLDs. Any competent accountant can turn $15/yr domain rent into an up-front purchase fee to cover registration in perpetuity. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: who gets a /32 [Re: IPV6 renumbering painless?]
the internet endpoint type trend is toward SOHO and dsl/cable, and the provider trend is toward gigantic multinational. companies who build their own networks tend to find that the cheapest interoffice backhaul is IP-in-IP VPN's. thus is the old model of a 1000-person company buying a T1 transit connection moving toward the margins. I'm not experienced with the 1000-person companies; the work I've done is for companies 20 to 100 times that size, so maybe my perception is skewed. i think all oldtimers are skewed. growth in number of enterprises will be of the small kind where renumbering isn't so painful. exceptions where there is enough size to make renumbering painful won't overflow the routing table the way the ipv4 swamp threatened to do back in the days of 64MB RP cards. ... Enterprises can have tens or hundreds of thousands of hosts behind a single T1 or T3, and may expose only a handful of PA addresses due to NAT. Large universities are similar, except legacy allocations mean they usually don't need NAT. right. for all these reasons, large or multihoming endsystems will need V6 PI allocations and at some point the RIRs are going to have to define/allow this. (note that i'm not speaking for arin, nor as a member-elect of arin's board of trustees, i'm just another bozo on this bus.) as i continue to research my own premises, i find that the style of internetworking practiced at isc, which precludes PA space due to multihoming and due to possible renumbering penalties, So are you saying that if ISC had not gotten a legacy PI allocation, you wouldn't be using IPv6? Or that you wouldn't be able to design your network the way you'd want to, but would still use IPv6 anyways? the second. we'd have built a v6 bastion network and put our public services there and done some kind of overlay thing. for things like my desktop, we'd've stuck with ipv4, or we'd've pirated some site local ipv6 space. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. no, no, no, and again i say, no, that will not be done on my watch. ... it's sad but it's true and it gives cause to ponder the future of enabling technologies like internet exchange points. I've run into very few enterprises that know they'd even be allowed to join an IX, much less actually interested in doing so. They'd rather pay one or two companies to drop big, fat pipes into their datacenter and collect on SLAs when something goes wrong. Very few, even in the Fortune 100, have the staff to handle their own BGP configs and keep things running smoothly. Humans cost more money than they'd probably save on transit, and the money often comes out of different pockets anyways. during my time as president of paix, microsoft and yahoo and google all decided to try their hand at BGP, and all of them found that they could manage both risks and costs better by doing it in-house than by buying transit. if i were still at paix i'd no doubt have sold a few big banks and insurance companies on the concept by this time, as equinix is now doing quite successfully. i thought this was, and still think this is, the best possible direction for the ip connectivity community to grow in. it increases diversity, price pressure, and overall competitiveness. but without endsystem PI's for these large multihomers, it's only going to be the public servers and not the desktops who benefit from this. treating enterprise desktops as being just like the DSL market is a big mistake, and if it's not corrected, then equinix and paix/sd and others like them are going to see a flattening of their growth. I see IXes (IXen?) as a solution for providers, not end-sites. With the relatively lax IPv6 PI policies for providers, the threat to IXes is minimal. i used to love it when people would say that, because it meant i could walk right past them and take their customers simply by offering an alternative that the incumbants couldn't even see. -- Paul Vixie
Re: Diffserv service classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ietfreport is timing outhere's another url for this draft. http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.txt interesting read at: http://qbone.internet2.edu/papers/non-architectural-problems.txt regards, /vicky Sean Donelan wrote: | In the continuing effort to make Diffserv useful on the Internet, | the Transport Area working group has the draft: | | http://ietfreport.isoc.org/idref/draft-baker-diffserv-basic-classes/ | | The draft has a little bit for everyone. Lots of rope/flexibility for | application developers. But have any network operators thought how they | could actually support the framework in any meaningful way? And assuming | the network actually supported it, what happens when you throw such fine | grain differentiated traffic at the network? | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBn8EfpbZvCIJx1bcRAn4mAKCAjZu5k89IVIDXajJW9tp2MmO4+QCgrFmM ojED2CtlqNO92BqCcnWcG6Y= =5lJL -END PGP SIGNATURE-
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sat, Nov 20, 2004 at 08:45:34PM +, Paul Vixie wrote: the second. we'd have built a v6 bastion network and put our public services there and done some kind of overlay thing. for things like my desktop, we'd've stuck with ipv4, or we'd've pirated some site local ipv6 space. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. no, no, no, and again i say, no, that will not be done on my watch. Perhaps it is time to replace TCP with SCTP, where multihoming is not incompatible with PA addressing. If done as a socket shim, so applications don't have to be aware of it unless they want to be, it would appear to solve all of these problems. How much would it add to the pain of the v4-v6 transition, to just bite the bullet and do tcp-sctp at the same time? I'd sure rather be a network troubleshooter going through that than living with NAT forever. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
I've run into very few enterprises that know they'd even be allowed to join an IX, much less actually interested in doing so. Subject: Exchange Update - New Participant Date: Fri, 19 Nov 2004 15:49:59 -0800 Equinix would like to introduce the following peers to the GigE Exchange peering fabrics: - ASH: Walmart.com connected to the Ashburn GigE Exchange You may not have met them but they're out there They'd rather pay one or two companies to drop big, fat pipes into their datacenter and collect on SLAs when something goes wrong. We used to do that, we learned. Very few, even in the Fortune 100, have the staff to handle their own BGP configs and keep things running smoothly. Humans cost more money than they'd probably save on transit, and the money often comes out of different pockets anyways. Many CCIE(paper) end up in enterprises as they still have money and networks large enough to need engineers. I'm sure plenty of them are looking to keep the ISP section of their CV up to date by running the enterprises BGP. We also have enterprises doing BGP between each other on internal, non internet, networks Assumptions about what people should/will want to do are clouding engineering judgment and making things like IPV6 unworkable brandon
Re: Stupid Ipv6 question...
Date: Fri, 19 Nov 2004 10:11:36 -0800 From: Crist Clark [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Lars Erik Gullerud wrote: On Fri, 2004-11-19 at 16:36, Stephen Sprunk wrote: /127 prefixes are assumed for point-to-point links, and presumably an organization will divide up a single /64 for all ptp links -- unless they have more than 9,223,372,036,854,775,808 of them. While that would seem logical for most engineers, used to /30 or /31 ptp links in IPv4 (myself included) Aren't most engineers used to the fact that point-to-point links are not broadcast links and therefore the concept of a network/netmask for the interface is somewhat useless? In addition, link-local addressing eliminates many situations where you need to allocate tiny blocks for p2p links. Just to introduce a touch of practicality to this discussion, it might be worth noting that Cisco and Juniper took the RFC stating that the smallest subnet assignments would be a /64 seriously and the ASICs only route on 64 bits. I suspect that they influenced the spec in this area as expending them to 128 bits would have been rather expensive. In any case, if the prefix length is 64, routing is done in the CPU. IPv6 traffic for most tends to be light enough that this is not a big issue today, but the assigning /126 or /127s for P2P links is really, really not a good idea. the use of 127s also ignore the possibility of a anycast address. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: who gets a /32 [Re: IPV6 renumbering painless?]
How much would it add to the pain of the v4-v6 transition, to just bite the bullet and do tcp-sctp at the same time? I'd sure rather be a network troubleshooter going through that than living with NAT forever. it's the delta between the finite and the infinite. sctp requires a flag day whereas nat can be deployed incrementally. sctp isn't going to happen, at least not on the scale that nat has happened or that ipv6 will happen.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: i think all oldtimers are skewed. growth in number of enterprises will be of the small kind where renumbering isn't so painful. exceptions where there is enough size to make renumbering painful won't overflow the routing table the way the ipv4 swamp threatened to do back in the days of 64MB RP cards. Here is a possible multi level solution for end sites and non /32 qualifiers: - Sites that dual-home use alternate path encoding with PA /48's - Sites that tirpple home do the same but get PA /40's to make up for the loss of site subnet bits in tripple mode. - Sites that multihome 4 ways or more get a PI /40 - Large sites with more than X devices get a PI /40 if at least (dual|tripple)homed to avoid massive renumbering/provider lock-in. This would set the bar high enough to limit routing table growth while allocating PI space to those who need it the most. -- Kevin Loch
Re: who gets a /32 [Re: IPV6 renumbering painless?]
And don't forget that you still have to change your phone number when you move a great enough distance. In IP we somehow feel it's important that there are no geographical constraint on address use at all. That's a shame, because even if we aggregate by contintent that would save up to four times in the number of entries in the routing table of any router. Not necessarily true. I live in California. However, 703-842-5527 is a valid phone number for me. It even worked for me while I was in Puerto Vallarta, Mexico. I can take that number pretty much any where in the world, whether temporarily, or, even if I move there. Some exceptions would be the few countries that are attempting to block or make VOIP illegal, but, otherwise, I can pretty much take a VOIP phone number anywhere I like. Additionally, through FXP, you can take other numbers different places as well. However, I agree these are exceptions, not the general case. Nonetheless, the problem can be solved. I bet companies would be more willing to renumber when switching physical locations than they are to renumber when switching carriers at the same physical location. Owen pgpfAOP0uYWVb.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Alex, I am aware of how telcos work in general, and, in some detail in the united States. I also agree with most of what you said. However, consider that somehow, they have scaled this to many many more customers than the total number of internet subscribers. There must be something for us to learn there, even if we are missing what it is right now. Owen --On Saturday, November 20, 2004 13:18 + Alex Bligh [EMAIL PROTECTED] wrote: --On 19 November 2004 09:40 -0800 Owen DeLong [EMAIL PROTECTED] wrote: If it were true, then I would have to renumber every time I changed telephone companies. I don't, so, obviously, there is some solution to this problem. But I'm not sure you'd like it applied to the internet. Firstly, in essence, PSTN uses static routes for interprovider routing (not quite true, but nearly - if you add a new prefix everyone else has to build it into their table on all switches). Secondly, IIRC porting works in the UK something like - call delivered to switch of operator who owns the block, marked as ported number, lookup in central porting database (one for all operators), operator port prefix put on dialed number, call sent back out all the way to interconnect, enters new operator network, goes to switch managing ports, further signalling info added to make call go to the correct local switch, call goes to correct local switch, dross removed, call terminated. Roughly speaking this is the internet equivalent of: * Configure all interprovider routes by a static routing config loaded every week or so. * Handle porting by getting ICANN to run a box with a primative gated BGP feed connected to all your distribution routers. Where a packet is delivered to a distribution router and the IP address has changed providers, change the next hop received from the ICANN BGP feed to a GRE tunnel to the appropriate provider's tunnel termination box. * At that tunnel termination box, static route all ported-in IP addresses to the correct distribution router. Yum yum. Sometimes we don't have lessons to learn from the PSTN world, and instead the reverse is true. Alex pgp4A12aUgOcO.pgp Description: PGP signature
Re: Stupid Ipv6
Just to introduce a touch of practicality to this discussion, it might be worth noting that Cisco and Juniper took the RFC stating that the smallest subnet assignments would be a /64 seriously and the ASICs only route on 64 bits. I suspect that they influenced the spec in this area as expending them to 128 bits would have been rather expensive. darn... and we fought so hard last time we had to expunge classfull addressing asics/hardware in the late 1990s. looks like it crept back into vendor gear. IPv6 was -never- supposed to be classful. --bill
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Barney Wolff [EMAIL PROTECTED] Perhaps it is time to replace TCP with SCTP, where multihoming is not incompatible with PA addressing. If done as a socket shim, so applications don't have to be aware of it unless they want to be, it would appear to solve all of these problems. How much would it add to the pain of the v4-v6 transition, to just bite the bullet and do tcp-sctp at the same time? I'd sure rather be a network troubleshooter going through that than living with NAT forever. Almost no host OSes support SCTP today, which is the major barrier; it took a decade to get IPv6 widely implemented in hosts, and there's no reason to think SCTP implementation would be as fast or faster. That aside, SCTP sockets and TCP sockets are not created the same way nor behave the same way from the application's view. An API change would be needed to make this transparent to apps. Also, there's no way for one host to know if another supports SCTP _and_ is running SCTP-capable apps without actually attempting a connection, which costs time. It seems easier to try to back-port SCTP's multihoming features to TCP somehow than to deploy an entirely new transport protocol. It's unfortunate this wasn't addressed at the time IPng was being designed. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
RE: Stupid Ipv6
While the concept of classes has changed, I'm not so sure that I agree with the complaint here... Everything I've seen about the multi TLA/SLA concepts always seem to leave 64 bits at the end for the actual host address, so it would be a logical step at that point to have the ASICs spun so that 64 bits was the limit for routing tables. Perhaps I have had the same assumption/misunderstanding that the programmer guys have had then?!?!? Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, November 20, 2004 9:56 PM To: Kevin Oberman Cc: [EMAIL PROTECTED]; Lars Erik Gullerud; Stephen Sprunk; North American Noise and Off-topic Gripes Subject: Re: Stupid Ipv6 Just to introduce a touch of practicality to this discussion, it might be worth noting that Cisco and Juniper took the RFC stating that the smallest subnet assignments would be a /64 seriously and the ASICs only route on 64 bits. I suspect that they influenced the spec in this area as expending them to 128 bits would have been rather expensive. darn... and we fought so hard last time we had to expunge classfull addressing asics/hardware in the late 1990s. looks like it crept back into vendor gear. IPv6 was -never- supposed to be classful. --bill
Re: who gets a /32 [Re: IPV6 renumbering painless?]
It seems easier to try to back-port SCTP's multihoming features to TCP somehow than to deploy an entirely new transport protocol. It's unfortunate this wasn't addressed at the time IPng was being designed. this was tried. there was almost going to be a TCP6 which was capable of signalling an endpoint-renumber event using in-band control messages. alas, this approach was deemed overly complex, so TCP went unchanged. -- Paul Vixie
Re: who gets a /32 [Re: IPV6 renumbering painless?]
... all oldtimers are skewed. ... Here is a possible multi level solution for end sites and non /32 qualifiers: ... - Sites that multihome 4 ways or more get a PI /40 - Large sites with more than X devices get a PI /40 if at least (dual|triple)homed to avoid massive renumbering/provider lock-in. This would set the bar high enough to limit routing table growth while allocating PI space to those who need it the most. there are problems with this approach, having to do with the definition of multihoming, and with the possibility of someone claiming to qualify for PI space even though their providers are actually related parties. there is room for huge graft and corruption unless the definition is very careful and there's a budget for both initial and recurring audits. then there's the problem of falling out of qualification some time after a large network has been built. so while i don't disagree that multihoming appears to be a justification for PI space, i'm not sure all the wrinkles can be ironed out. more importantly though is your /40 example. ipv6 has enough address space in it to be able to give a /32 to every household on the planet, including a reserve for the ones without electric power or phones. giving out /40's makes no sense. what the world is short of is routing table slots, each of which adds universal cost to the internet for the sole benefit of the owner of the network thus made reachable. there's ram, cpu, churn... the works. when or if an endsystem PI policy is defined, it should not call for shorter prefixes, but rather, for making it really quite rare in a global sense for anyone to actually qualify for it. if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. -- Paul Vixie
RE: who gets a /32 [Re: IPV6 renumbering painless?]
what the world is short of is routing table slots, each of which adds universal cost to the internet for the sole benefit of the owner of the network thus made reachable. I see this point made often, and I've never understood it. If carrying a route only benefits the party that issued the route, why do it? It seems to me that being able to reach someone is of as much value to you as it is to them. I wonder why IBM, Apple, Cisco, and Ford don't connect their corporate web servers to routers that don't contains any of these expensive routes that are only for the benefits of the entities that announce them. Perhaps you should explain to them all the money they could save. Better connectivity on either end benefits both ends of the connection. DS
Re: Diffserv service classes
On Sat, 20 Nov 2004, Vicky wrote: interesting read at: http://qbone.internet2.edu/papers/non-architectural-problems.txt There is a long history of problems. But Internet2 also shows a success for Diffserv, namely there is demand for a worse effort. Are a dozen differnt classes useful to a network operator?
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 21 Nov 2004, Paul Vixie wrote: if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. s/if/when/ There some hope though that by that time routers will have slightly more memory and slightly better CPUs ... But I do think its clear that with IPv6 a solution needs to be found for the average joe-business-user who wants to have benefits of connectivity with several providers without necessity of doing BGP. IETF Multi6 seems to be the best effort we have in this area and its quite clear now from both that and from HIP and MIP that new host layer will have to be added to TCP/IP between IP and TCP and then connection will not be between one ip and another but between one host and another and simplified routing protocol will decide which of the ips (and each host may have multiple ones) are actually used for source and destination of data packets. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: who gets a /32 [Re: IPV6 renumbering painless?]
if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. -- Paul Vixie Nut-uh! *WHEN* the ipv6 routing table gets as large as the ipv4 routing table is today (late 2004, when you quote me later) it won't be a problem. As a matter of fact, I would bet that Cisco , Juniper, and any other edge/core router manufacturer are banking on this happening. Today's routing table can be carried on older edge routers very effectively (There are many 7500, 7200 series routers out there), and I predict that this will continue to be the case for quite some time (at least a few more years) This is not conducive to the business model of Cisco Systems. *WHEN* the IPv6 routing table is the same size that it is today, I seriously doubt that there will be any problem with finding a CPU fast enough, RAM with a memory rate high enough, or CPU to memory bandwidth wide enough to handle it. And when that time comes: I promise that any Cisco sales person will have at least more than a handful of routers to sell you that'll handle the load just fine. I'm Jerry Pasker, and I approved this message.
