Where to buy Internet IP addresses
Optimum Online business only offer 5 static IP address. Where can I buy a block of Internet IP address for Business? How much does it cost? Most of our devices only require an internal IP address to reach the internet, but we have a Juniper DX for load balancing. We must provide Juniper DX with an internet IP address and point it to internal IP address for customers to be able to reach it from the internet. this is for testing and development purposes and will expect several servers on Load-balancer. The 5 static IP addresses just won't be enough. Thanks in advance Louis
LEdouard Louis wrote:
Get a different ISP. You can't "buy addresses." You can apply to your RIR for addresses, but it sounds like you wouldn't qualify if your price range is 5 statics from your ISP. Also see huge debate on arin-ppml about buying and selling addresses. ~Seth
LEdouard Louis wrote:
Only five? Really? Our basic residential users get 18 quintillion addresses, and business users get 65536 times that many. Tell them you need a few more. :-) Seriously, we do indeed provide that many addresses, but that's on a new protocol being implemented to avoid the exact problem you're having. Talk to your sales guy and see if they will assign a "/28" to you, which would give you 13 usable addresses for your hosts. If not, and you have a valid need for more space, switch ISPs. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
In message <49FB4661.8090503@west.net>, Jay Hennigan writes:
Actually residential users do. One /64 is not enough. On can argue about whether a /56 or a /48 is appropriate for residential users but a single /64 isn't and residential ISP's should be planning to hand out more than a single /64 to their customers.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Sat, May 02, 2009 at 09:40:23AM +1000, Mark Andrews wrote:
How many home users (or even small businesses) have more than one subnet at the moment (behind NAT, presumably)? As a percentage of subscribers, what does that equate to? Handing out an IPv6 /56 to a DSL or cable customer should be handled much the same way as giving them an IPv4 /29 is today -- ask, and it shall be provided, but it's wasteful[1] to do so by default. - Matt [1] Just because we've got a lot of it, doesn't mean we should be pissing it up against the wall unnecessarily. A motto for network engineers and economists alike. -- [M]ost of the other people here [...] drive cars that they have personally built (starting with iron ore, charcoal, and a Malaysian turn-signal tree) [...] but I wimp out on all of those points. Sometimes there are advantages to paying somebody else to do it for you. -- Matt Roberds, in the Monastery
In message <20090502002406.GK4507@hezmatt.org>, Matthew Palmer writes:
I know on quite a few none geek households that have multiple nets today using double or triple NAT. These households will be your multi-subnet IPv6 customers. The NAT boxes will be replaced with ones that do DHCPv6 PD (both up and down stream).
One won't hand out a /56. Think about how the above CPE boxes will work with PD. You will get multiple /64 requests from the border CPE box with different IAID on them, one for each subnet in use. The border CPE box could also consolidate the requests from downstream if it so desired but I would expect that would not be the default configuration. Mark
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Sat, 2 May 2009, Matthew Palmer wrote:
You can't be wasteful with something that you know is already extremely plentyful. We currently have 72 million billion /56:es. If we do /56:es of the current /16 being handed out and then change our mind, we can still hand out 1100 billion /56:es before we can discover this was wasteful and then we will have spent one 65536th of the address space available. Give people a /56 and if they only use one NOW, you still won't have to handle administration of the customer when they change their mind. Current NAT boxes solve the problem of people only getting a single IP address. People adapt to the conditions we give them. When IPv6 is readily available there will be products that use several subnets in the home, if we start to just give them a single /64 there won't be a market to solve it this way, and people will continue to use a single /64. You can say you were right, there was no need, but you killed the multisubnet solution before it was even born. -- Mikael Abrahamsson email: swmike@swm.pp.se
@Mikael - "I agree 100% with the give them more than they know they need, so when they do need it we don't need to do anything" (Nit-we are allocating from a /3 (2000::/3) today) @Matthew - Obviously, I (respectfully) disagree with treating IPv6 allocations that similarly to IPv4 allocations - the "v6 way" is to let the protocol encourage innovation, not stifle it ... If it turns out to be a bad idea, we can revise the procedures for 4000::/3 (although I doubt it will be a problem). :) /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Mikael Abrahamsson <swmike@swm.pp.se> Date: Sat, 2 May 2009 07:42:21 To: Matthew Palmer<mpalmer@hezmatt.org> Cc: <nanog@nanog.org> Subject: Re: Where to buy Internet IP addresses On Sat, 2 May 2009, Matthew Palmer wrote:
You can't be wasteful with something that you know is already extremely plentyful. We currently have 72 million billion /56:es. If we do /56:es of the current /16 being handed out and then change our mind, we can still hand out 1100 billion /56:es before we can discover this was wasteful and then we will have spent one 65536th of the address space available. Give people a /56 and if they only use one NOW, you still won't have to handle administration of the customer when they change their mind. Current NAT boxes solve the problem of people only getting a single IP address. People adapt to the conditions we give them. When IPv6 is readily available there will be products that use several subnets in the home, if we start to just give them a single /64 there won't be a market to solve it this way, and people will continue to use a single /64. You can say you were right, there was no need, but you killed the multisubnet solution before it was even born. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
On Sat, 2 May 2009, Matthew Palmer wrote:
There is no resource that cannot be pissed away, if you try hard enough.
Philosophical: You know, if we are just going to act as if ipv6 has only 64 bits, why didnt we just design it with only 64? Practical: Think of the routing table. How many /48's in a /32?
Give people a /56 and if they only use one NOW,
Give people a /96. Thats a whole internet. Whats that? They resurrected classfull addressing for ipv6?
Oh! You mean, like the way we piss away IPv4 addresses?
Well, if you look at it the right way, we *did*. While you can drill down into the lower 64 bits, the design intent was clearly to let that be handled by end users and stateless autoconfig, etc. So, from a design viewpoint, you treat a /64 the way we treat an IP address. Except that unlike an IP address, there's a lot more /64's, and each /64 can hold an IPv4 Internet - squared.
No! That's very bad. That breaks stateless autoconfig. That's awful. What in the world is the justification for that? We can give every person likely to be on the planet in the next 100 years a /48 and not be even remotely close to running out.
Whats that? They resurrected classfull addressing for ipv6?
Pfft. We *want* things like IPv6 stateless autoconfig to work. It's a great idea. We *want* a protocol simple enough that we don't have to deal with stateful DHCP, we *want* something that is hard to screw up. We also don't want to force everyone into a single broadcast domain, or to have to break stateless autoconfig by subnetting deeper than a /64. Sure, *today*, the average person has a handful of networked devices, and *today*, the average person might not need more than a "public" net and a "local/printer" net. However... twenty years ago, only a few of us had a network at home. It's hard to predict what will be coming in twenty years, but I expect there'll be more networking, not less. Microprocessors are getting smaller and cheaper. The devices that support Internet connections are growing, such as all the ethernet ports that have sprouted on televisions in recent years. In order to get multiple broadcast domains and retain stateless autoconfig, you give people more space than a /64. But there are plenty of reasons that you might want the wifi on a separate network from the home computer network, and both of that separate from other networks with highly restrictive access, such as a network for the printer, or your light switches, or your HVAC management, or your alarm system, or your gaming network, or your kitchen electronics, or your A/V, etc. Under IPv6, there will (hopefully) be a demand for home networking switches and firewalls that greatly simplify security, and one of the things I'd like to see is the separation of devices at L3, so that a home user can use a graphical firewall tool that simply determines which networks are accessible from which other networks in a visual manner, etc. This is so much easier with something greater than a /64. So if you can justify giving people a /96, but you can't see why it'd be better to give them (at least!) a /56 instead, that just makes no damn sense. IPv6 was built around the concept that we wanted to make space as close to *free* as possible. The designers intended that it not be a horribly big deal to have to choose between a /64 and a /56 and a /48; space is plentiful enough that if you're not absolutely positive that one size is adequate, that you should then go a little larger. Just to be safe. Because, remember, we're talking tiny slivers of space. Think about what a /48 *means*. Today, you get a single IP address on the IPv4 Internet, one single IP address, and that's a /32. We're talking much smaller allocations, and a /48 is an extremely powerful allocation from the user's point of view. We will find creative uses for the space. Look at RFC3041, which is a credible use for a /64's worth of space that provides a variety of benefits. Any IPv4 engineer who has been working for the last decade will look at IPv6 and be aghast over the apparent waste, but take a little time to look at the realities and possibilities before reaching rash conclusions. I do see the sheer vastness of a /64 as something that's very difficult to wrap your head around: all of the space on today's Internet would be just a drop in a /64 bucket. However, if you can get past that and see the /64 as just a basic "network," that's a good first step in understanding IPv6. Then you should be thinking about the fact that we will probably be living with this for many years to come, and if we make poor choices now about how we allocate to users, that will haunt us for years to come. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Very few viewpoints are universal. I've just waded through a debate on another mailing list about how broadband providers are going to only want to allocate you a single IPv6 address... bleah.
IPv6 stateless autoconfig can be screwed up, DHCP can be screwed up.
Everything *can* be screwed up. You know what Scotty says.
For my IPv6 networks I plan to stick with fixed IPv6 address or DHCP.
That's fine, but I don't want to lose the option of stateless autoconfig just because someone doesn't grasp the size of the address space and the intent of the designers. Allocating everyone a /48 does not preclude the use of stateless autoconfig, DHCP, or manual configuration. Allocating everyone a /96, on the other hand? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Sun, May 03, 2009 at 05:01:10AM -0500, Joe Greco wrote:
That's pretty much what I'm thinking of. I'm sure that, had their been a NANOG at the time IPv4 was being rolled out, there would have been an equivalent discussion, except substitute /8 for /48, and probably site for end user -- but the arguments, I'm sure, would have been the same, and they would have sounded just as rational to the participants then, too. In fact, there are probably people on this list now who *were* around when the initial IPv4 addressing policies were thought up... - Matt -- "People can be divided into three classes: The few who make things happen, the many who watch things happen, and the overwhelming majority who have no idea what has happened." (Author unknown)
On Mon, 4 May 2009, Matthew Palmer wrote:
We shouldn't waste the IPv6 addresses, but giving each end user a /56 isn't wasteful. It's even less than the protocol was designed for, and there is nobody who has conceived so far how this would be a problem before we've even used up 1/(2^16) of the available space and we can fix any problem seen by then with 65536 times more addresses to use in a less "wasteful" manner. Crippling IPv6 by just giving people a /64 isn't helping anybody, it's just delaying and complicating the IPv6 rollout to end users. We should make sure people are used to the fact to have routing in their home (or at least the possibility to do so). -- Mikael Abrahamsson email: swmike@swm.pp.se
And I think I'd like to say that, as someone who was around in some of the earlier days of the 'net, there were a lot of questions even at that time about allocation of /8's - it was obvious that, even at the time, we weren't going to be able to allocate every school a /8, and there were questions about how to make the class B and C spaces work well. Regardless of your opinion of what might have happened at the time, we were aware that there were limits. IPv6 was explicitly designed for this. If it would happen to turn out to be a problem, which appears exceedingly unlikely within any reasonable timeframe, as noted, we have the option to change strategy. Allocating smaller blocks will just encourage brokenness. This is not a desirable goal. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
David Schwartz wrote:
Also the wrong question. The question will become, what will the home routers support. The most common expectation of home routers will decide the defaults for most ISPs. One thing I currently dislike with implementations (and probably in the spec, though I haven't checked), is lack of support for variable PD requests. Sure, it's possible to configure radius to hand out specific prefixes, but what about variability. Many households will only need a single /64, while some will need a /60 (being nice on the nibbles). A more dynamic protocol would have been nice given that they were redesigning everything. That way a router needing only one subnet could request a /64, and then another router hooked up behind it could request a /64 proxied through the first, or perhaps when the second router asks the first, it renumbers asking for a /63, which the ISP might instead respond with a /60. A boy can dream. Jack
Seth Mattinen wrote:
I hear this a lot, but how many "linksys default channel 6" end users really have more than one subnet, or even know what a subnet is?
By definition, every single one of them that buys wireless router, then buys another and hangs it off the first. That happens more often then you would think.
~Seth
At our helpdesk we hear customers hanging their wireless router off their NATed PPPoA DSL modem all the time, such that its double-NATed. That things work as well as they do is a testament to the resiliency of IP (and applications and servers) in the face of NAT. Frank -----Original Message----- From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Friday, May 01, 2009 8:46 PM To: Seth Mattinen Cc: nanog@nanog.org Subject: Re: Where to buy Internet IP addresses Seth Mattinen wrote:
I hear this a lot, but how many "linksys default channel 6" end users really have more than one subnet, or even know what a subnet is?
By definition, every single one of them that buys wireless router, then buys another and hangs it off the first. That happens more often then you would think.
~Seth
On Fri, May 1, 2009 at 8:46 PM, Joel Jaeggli <joelja@bogus.com> wrote:
A /62 takes care of that unusual case, no real need for a /56 for the average residential user; that's just excessive. Before wondering about the capabilities of home routers.. one might wonder if there will even be _home_ "routers" ? The consumer-level boxes for home users that do NAT for V4, for V6 may well act more like Layer 3 bridges, and (once need for IPv4 support goes away) be simple Layer 2 bridges that can be small lower-powered, fairly dumb devices that just act as pass-through for the ISP router with a basic transparent firewall. And only route/NAT for IPv4. There are reasons to doubt that PD will be supported on consumer level devices; or to expect devices may have only limited support for PD. The availability of an entire /64 means users' 'internet sharing boxes' no longer benefit from NAT or routing capabilities; the user has all the IPs they need from the ISP, and doesn't _need_ to create their own subnets. NAT'ing/routing in IPv6 becomes more of a feature only Service providers and large entities really need. -- -J
James Hess wrote:
I think you'd want to do a /60 so it's on a "nibble" boundary. But by then you might as well do a /56. My personal feeling is that 99% of home networks will use a single /64, but we'll be giving out /60s and /56s to placate the 1% who are going to jump up and down and shout at us about it because of some reason that they feel makes it all unfair or that we're "thinking like ipv4 not ipv6" etc. It's possible that home networks will gain some ability (in a standard fashion) to use more than one /64, but I doubt it - it's much easier to do resource discovery on a single broadcast domain for things like printers, file sharing etc. MMC
On Sun, 3 May 2009, Matthew Moyle-Croft wrote:
IPv6 was designed around handing out /48s to everybody. There are 281 thousand billion /48s in the IPv6 space. We are 6 billion people on the earth. If we hand out a /48 to each, we still have a lot to spare (99.999% left), then we can decide if this was a problem or not.
Don't think now or next year, think in 10 years. Think hundreds of devices in your home, you don't want your sensor network to be on the same subnet as your computers, and you want a DMZ, and you want your video on a separate subnet (because you have cheap switches which do not have MLD snooping) etc. There is NO reason of scarcity to NOT hand out at least a /56 to each end user. Stop thinking IPv4 and start to think IPv6, we're going to be living with this for tens of years and you have no idea what people want to do in the future. Give them the chance to innovate and they (or someone they purchase products from) will. It's short sighted and silly to design your service around handing out /64s to people and then you have to redesign it when demand for multiple subnets come around. Design it around /56 to begin with, and you will have solved the problem for the future, not just for now. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
Then tell RIR's to quit insisting that /56's have SWIP's. They can't very well be dynamic in nature via PD if they are being SWIP'd. Until then, /60 sounds fine. Allows higher capacity per /48 on a node and will give most customers more than they will ever use. Jack
* Jack Bates
Then tell RIR's to quit insisting that /56's have SWIP's. They can't very well be dynamic in nature via PD if they are being SWIP'd.
I believe this is not the case with RIPE, you'll only need to register assignments that are larger than /48 in their database. See ripe-466 section 5.5. BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
On Mon, 4 May 2009, Jack Bates wrote:
Then tell RIR's to quit insisting that /56's have SWIP's. They can't very well be dynamic in nature via PD if they are being SWIP'd.
I never heard of this requirement before, but I am not in the ARIN region. There is no technical reason why you can't give the user the same /56 each time via PD, the same way some offer static IPs via DHCP.
Until then, /60 sounds fine. Allows higher capacity per /48 on a node and will give most customers more than they will ever use.
Try to change the policy instead. -- Mikael Abrahamsson email: swmike@swm.pp.se
On May 4, 2009, at 6:21 AM, "Jack Bates" <jbates@brightok.net> wrote: [...]
Then tell RIR's to quit insisting that /56's have SWIP's. They can't very well be dynamic in nature via PD if they are being SWIP'd.
If you are referring to section 6.5.4.4 of ARIN's NRPM, it does not require you to use SWIP. It requires that an ISP have records which allow ARIN to evaluate a request for a subsequent allocation. SWIP would work if ARIN wanted potentially 10s of millions of /56s in its whois database but it is not explicitly required and ARIN staff can presumably advise on suitable alternatives. Regards, Leo
a consumer auto-provisioning system which only gives out one size? there is not a web site on which the customer can choose dynamically? how 20th century. folk who think about provisioning consumers should go to paris for a week and be a free.fr customer. brilliantly done. [ and i am sure you can find other things to do in paris as well. ] randy
On 3/05/2009, at 7:53 PM, Matthew Moyle-Croft wrote:
17% of packets leaving an ISP here in NZ were from behind double NAT. (or, they went through 2 routing hops in the home, which I suspect is fairly rare) Why does this happen? $customer has an ADSL router with no wireless, then they go buy a "wireless router" and plug the ADSL router in to the "internet" port. I suspect your market is not that different to NZ.
The above mentioned sort of stuff will keep happening, I'm sure, and because the ADSL router and the wireless router are the only devices on the same subnet, no service discovery things need to happen. I have an idea brewing to allow routers to forward PD requests. The idea would be that a BRAS/LNS only assigns a /64 for each PD request, and the customer router forwards PD requests for routers attached to their inside interface. That way, we can chain up to 16 subnets in the home. The BRAS can reserve a /60 or /56 or whatever for each customer so they are contiguous, or whatever. -- Nathan Ward
On 3 May 2009, at 05:20, James Hess wrote:
A /62 takes care of that unusual case, no real need for a /56 for the average residential user; that's just excessive.
There are about 11 million /56s per person on the planet, we're not about to run out. As there's nothing to conserve why follow the conservative strategy implied by shifting to longer netmasks? Why not stick with a regular scheme of escalating /64 -> /56 rather than an irregular one of /64 -> /62 -> /56?
Ian Mason wrote:
There are about 11 million /56s per person on the planet, we're not about to run out.
"We have enough addresses for about four billion of these." http://www.cs.utexas.edu/users/chris/think/ARPANET/images/imp.gif "We're not about to run out." -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
And while the two bear some level of similarity, and the comparison makes a great throw-away joke - the difference is in scale. Orders of orders of orders of orders (give or take a few more orders) of magnitude in difference. Taking the usual liberty with the math - 4.3B maximum addresses, compared to 18BB or so network segments (each of which supports as many hosts as we want). Also, the quote was accurate - they were not about to run out. That was more than several years down the road. Not bad for an experiment that escaped the lab ... Accounting for the aforementioned growth in the space, a run life of several centuries for IPv6 should be sufficient. /TJ
The potential problem is segmentation. Start assigning meanings to chunks of bits, like routing info or even customer type (mobile, static, etc) or geography, and the bits can get used up pretty quickly. Or put another way the address space becomes sparsely populated but inflexible. I know, "don't do that", well, when they give you (for any "you") that job be sure to send us a postcard... Any resource which is cheap (free!) and seemingly plentiful will get "abused", used in a way the engineers never intended (one word: spam!) Hey, anyone want to buy an ipv6 prefix which spells out their last name or company name when interpreted as UTF-8?! Q00l! :-) -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
* Joel Jaeggli:
Isn't the traffic bridged, so that you don't have to route WINS and other stuff? Then it's still a single subnet. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Mon, 4 May 2009, Florian Weimer wrote:
Most people don't have the skill to do this, so they just hang the second NAT box behind the first and it "works". So the lesson from this is that any home IPv6 gateway needs to be able to both receive (from ISP) and provide PD (towards other home devices), as this is something people will want to do (because they do it today). -- Mikael Abrahamsson email: swmike@swm.pp.se
On 4/05/2009, at 7:19 PM, Mikael Abrahamsson wrote:
I think that they have to be forwarded. What do you do if people chain three routers? How does your actual CPE know to dish out a /60 and not a /64 or something? What if someone chains four? What if someone puts three devices behind the second? These are weird topologies, sure, but coming up with some algorithm to handle some of them and not others is going to be too complicated, and leave some people without a workable solution. Forwarding these requests up to the ISP's router and having several PDs per end customer is in my opinion the best way to go. -- Nathan Ward
On Mon, 4 May 2009, Nathan Ward wrote:
This is a CPE problem, the main homegateway can decide to dish out /64s to all other home routers, this means they can have a bunch. It also means they can't chain 3 in serial, unless the home user decides to hand out /60s to each and only have 3 of them connected to the main CPE.
This is where innovation will happen in the home market, but only if we hand them a /56 to start with.
Forwarding these requests up to the ISP's router and having several PDs per end customer is in my opinion the best way to go.
Why is this better? Why do you want to waste your tcam entries like that? A single /56 per customer makes you have the fewest amount of tcam entries in any solution I can imagine. All other solutions require more. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 4/05/2009, at 8:31 PM, Mikael Abrahamsson wrote:
That is one way to do it, sure. However it makes things hard for end users, having to figure out how all this stuff fits together. My non technical friends have a enough time with 3.5mm jack to RCA audio cables, but they managed to get a wireless router and plug it in and have it magically work for them.
Because it allows the home user to arrange their network however they want, up to 16 subnets, without having to have any knowledge of how things actually work. I'm sure we can both think of a few ways to make this not cost a whole lot of TCAM entries, either with protocol support, or in internal implementation specific ways. I can immediately think of two ways that cost no extra TCAM entries. -- Nathan Ward
On Mon, 4 May 2009, Nathan Ward wrote:
I don't see how your idea of doing on-demand-/64 is any easier than handing them 256 /64:s to begin with. But it seems we're nog getting any further here. I don't understand why you want to complicate things, you don't understand why I want to do things the way I do, let's just leave it at that. -- Mikael Abrahamsson email: swmike@swm.pp.se
back to the subject matter... i've been told that in the (roughly) NANOG region, that ARIN's 2008-6 or some rough analog should be in place on or before 01jun2009. What is 2008-6? https://www.arin.net/policy/proposals/2008_6.html Draft Policy 2008-6 Emergency Transfer Policy for IPv4 Addresses Author: Bill Darte Date: 24 January 2009 Policy statement: 8.4 Emergency Transfer Policy for IPv4 Addresses For a period of 3 years from policy implementation, authorized resource holders served by ARIN may designate a recipient for number resources they release to ARIN. ok... so lets just presume, for the mo, that I am an "authorized resource holder served by ARIN" and I have a /9 that is becoming a bother. One of my clients, holding discontigious /16's in that /9, desires to use 2008-6 ... and I have no problems w/ that ... HOWEVER. I want to dump the whole /9. How do I find viable receipients for the rest of the space? Get out my pushcart and roam the streets with my bullhorn; "... /16's, /24's... alive, alive Oh!...." --bill
In a message written on Mon, May 04, 2009 at 11:34:20AM +0000, bmanning@vacation.karoshi.com wrote:
i've been told that in the (roughly) NANOG region, that ARIN's 2008-6 or some rough analog should be in place on or before 01jun2009. What is 2008-6?
I strongly recommend waiting a few days before thinking about this issue too hard. The policy results of ARIN XXIII will be posted in a few days to arin-ppml and should provide some clarity. The wait will not be long. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
How is it the ISP's router is able to handle this? Be specific. Now explain why that can't be made to work at the CPE level. There hasn't been a lot of consensus on exactly how this should work (haberman, bykim, arunt, rao, stenberg, etc). so I am conveniently doing a bit of handwaving, perhaps. One of the goals of providing larger address spaces was to reduce (and hopefully eliminate) the need to burn forwarding table entries where doing so isn't strictly necessary. When we forget this, it leads us to the same sorts of disasters that we currently have in v4. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
I don't know that I'm *en*couraging /48 handouts, but on the other hand, I'm not sure I'm *dis*couraging it either. On one hand, there's a reasonable argument to be made that the average home user does not currently have enough devices to fill more than a /124's worth of space. But. You have RFC3041 and similar techniques, stateless autoconfig, and a variety of other general things that make it really awful for the default ethernet network size to be something besides a /64. Further, it seems clear from most discussions I've had, that people really do want or need the ability to have multiple networks, for a variety of practical reasons. Many of these have to do with keeping different zones firewalled in particular ways, So, really, I think the question is, how many unique firewalling policies is a household likely to have, and then, maybe how many other neighbors/friends/etc are also freeloading on that connection, each with the same needs? A /56 allows up to 256 networks. For today, that's pretty clearly all that I can reasonably imagine even a sophisticated home network along with several neighbors needing. Probably even within the next ten years. At some point, however, it is possible that a /48 would be a better choice. I would definitely prefer to see a /56, or maybe a /48, handed out today. If we get into the practice of handing out /64's, it is just going to encourage bad hacky design compromises and CPE/SOHO gear kludges in the future? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
When I first started looking at IPv6, the bottom 64 bits were divided into the bottom 48 bits for a MAC address and 16 more bits that could either be zeros or could be used as a subnet number in roughly Novell Netware style (modulo a local/global bit if you needed one). If you wanted to assign addresses instead of autoconfiguring, that was ok too, but it was obvious how autoconfig would work. It was simple, clean, and flexible, and obviously intended that an ISP would hand most customers a /64, which could easily handle an entire building or medium-complexity campus. Then I ignored those bits for a decade or more, because nobody's IPv6 was much more than experimental. When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Bill Stewart wrote:
When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet.
It's supposed to be a /48 per customer, on the assumption that 16 bits of subnet information is sufficient for virtually anyone; exceptions should be rare enough that they can be handled as special cases. The /56 monstrosity came about because a US cable company wanted to assign a prefix to every home they passed, regardless of whether it contained a customer, so that they'd never need to renumber anything ever again. However, that would require they get more than the /32 minimum allocation, and ARIN policy doesn't allow _potential_ customers as a justification for getting a larger allocation, so they had to shrink the per-customer prefix down to a /56 to fit them all into a single /32. If all those assignments were to _real_ customers, they could have gotten a /24 and given each customer a /48 as expected. And, after that, many folks who can't wrap their heads around the size of the IPv6 address space appear to be obsessed with doing the same in other cases where even that weak justification doesn't apply...
Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them?
Why the switch from EUI-48 to EUI-64? Someone in the IEEE got worried about running short of MAC (er, EUI-48) addresses at some point in the future, so they inserted 16 bits in the middle (after the OUI) to form an EUI-64 and are now "discouraging" new uses of EUI-48. The IETF decided to follow the IEEE's guidance and switch IPv6 autoconfig from EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to transform it into the EUI-64 that IPv6 expects. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
This has been a fascinating theoritcal discussion.. how do existing providers hand out space? Hurricane electric (via its tunnel service) hands out a /64 by default and a /48 is a click away. How do other providers handle it? I'm in the us and only have native v4 connectivity :( Do the various traditional last mile providers (sprint/Verizon/att/patch etc ) offer it for t1 and better? If they do then what do they hand out by default, what's available, at what price point and what's the upgrade path? Is it one click like he? No provider I have talked to offers it for residential connectivity in the united states. What does free.fr do? If there is this level of confusion and disagreement around addressing schemes then will it ever be offered to residences over traditional last mile loops? Sent via BlackBerry from T-Mobile -----Original Message----- From: Stephen Sprunk <stephen@sprunk.org> Date: Mon, 04 May 2009 16:36:16 To: Bill Stewart<nonobvious@gmail.com> Cc: north American Noise and Off-topic Gripes<nanog@merit.edu>; Joe Greco<jgreco@ns.sol.net> Subject: Re: Where to buy Internet IP addresses Bill Stewart wrote:
When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet.
It's supposed to be a /48 per customer, on the assumption that 16 bits of subnet information is sufficient for virtually anyone; exceptions should be rare enough that they can be handled as special cases. The /56 monstrosity came about because a US cable company wanted to assign a prefix to every home they passed, regardless of whether it contained a customer, so that they'd never need to renumber anything ever again. However, that would require they get more than the /32 minimum allocation, and ARIN policy doesn't allow _potential_ customers as a justification for getting a larger allocation, so they had to shrink the per-customer prefix down to a /56 to fit them all into a single /32. If all those assignments were to _real_ customers, they could have gotten a /24 and given each customer a /48 as expected. And, after that, many folks who can't wrap their heads around the size of the IPv6 address space appear to be obsessed with doing the same in other cases where even that weak justification doesn't apply...
Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them?
Why the switch from EUI-48 to EUI-64? Someone in the IEEE got worried about running short of MAC (er, EUI-48) addresses at some point in the future, so they inserted 16 bits in the middle (after the OUI) to form an EUI-64 and are now "discouraging" new uses of EUI-48. The IETF decided to follow the IEEE's guidance and switch IPv6 autoconfig from EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to transform it into the EUI-64 that IPv6 expects. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Mon, May 4, 2009 at 11:57 PM, <Charles@thewybles.com> wrote:
Free does 6rd and allocate a /64 per customer. Here is a presentation how they do this : http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free.pd...
On May 4, 2009, at 23:36, Stephen Sprunk wrote:
FireWire is the only significant user of EUI-64 addresses
Yesterday, it was. You might want to read up about IEEE 802.15.4 and 6LoWPAN. We are not joking when we talk about the next billion nodes on the Internet. For those who are worried about running out on /56s: There are 9000 trillion of those in the current 2000::/3 that is being handed out. Each /56 is about a customer relationship, a home, a wire, ... Say, each of them only needs a single dollar to get set up. We are talking about 9000 trillion dollars being spent before we have to open up the next /3. (2008's world domestic product, measured in purchasing power parity was about $ 69.49 trillion, by the way. I'm talking about spending 129.6 years of world productivity for one dollar per /56, here.) Folks: There will *never* be a reason to hand out /60s, /62s, /64s, or, heaven forbid, /96s. And I mean *never*: It's much more useful to discuss this issue on fundamentals than on past practices. Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten
Stephen Sprunk <stephen@sprunk.org> writes:
FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses
Zigbee has been around a lot less time than FireWire, but is hardly insignificant (ask anyone who's working on smartgrid or green home stuff). I'm sure there are others that just aren't on any of our personal radars. -r
On Mon, 04 May 2009 17:03:31 -0400, Bill Stewart <nonobvious@gmail.com> wrote:
"64bit MAC" -- which pretty much exists nowhere. It's a repeat of the mistakes from IPv4's early days: CLASSFUL ROUTING. I'm with you. I wish vendors and spec designers would just get over it and let people subnet however they want. If I want to set a network to be /96 or /120, I should be allowed to do so. Yes, I know autoconfig will not work -- and I don't want it to. I can make /31 IPv4 routes -- no router I've ever used complained about it. (that sends 2 addresses to one place; what happens in the place is not the router's concern.)
Ricky Beam wrote:
"64bit MAC" -- which pretty much exists nowhere. It's a repeat of the mistakes from IPv4's early days: CLASSFUL ROUTING.
Given there is no CLASS, but just a separation of network and host, I'd hate to compare it to classful routing. They probably would have been happy with a /96 network except for stateless autoconfig, which is quite nice for some stuff actually.
I've not tried every vendor out there, but I've noticed some implementations handle /127 just fine from a routing perspective. I personally enjoy my /64 of /128 loopbacks. I'll be dead before I run out. :) Jack
On Mon, 04 May 2009 18:01:32 -0400, Jack Bates <jbates@brightok.net> wrote:
Ok, calling it "classful routing" might be a little melodramatic. I would love to be able to set interfaces on my cisco hardware to /96's, but it's not allowed. Autoconfig screws that up. Even if it's not used, you're forced to live with it. Linux, BSD, etc. don't care. (and the instant they do, I can remove that stupid code.)
I've not tried every vendor out there, but I've noticed some implementations handle /127 just fine from a routing perspective.
So far, Cisco's gear is the only IPv6 routers I've messed with. And they will not let you set an interface to anything smaller than a /64. Loopbacks have slightly different rules, but in my case (IPv6 tunnels) that fact hasn't proven very useful.
In a message written on Mon, May 04, 2009 at 06:38:13PM -0400, Ricky Beam wrote:
My 12.0(S), 12.4, and IOS-XR boxes are operating quite well with /112's and /127's on GigE interfaces to each other, on GSR's, 7300's, and 7200's. We also use /128's on loopbacks. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Mon, 04 May 2009 18:50:04 -0400, Leo Bicknell <bicknell@ufp.org> wrote:
Must have been old (very old?) code when I first tried this. 12.4(15)T doesn't seem to care. But it still doesn't allow transitional addresses: gw(config-if)#ipv6 address 0::101:101/96 %FastEthernet0/0: Error: ::1.1.1.1/96 is invalid gw(config-if)#ipv6 address 0::101:101/128 %FastEthernet0/0: Error: ::1.1.1.1/128 is invalid If I cannot set an IPv4 address like that, the tunnel won't work. DHCPv6 requests end up outside the tunnel. (it's been many months since I messed with it, so the interface isn't in the config anymore, but the IPSEC setup still is :-)) I can send you the packet dumps if you want to scratch your head over it.
Actually, that's exactly wrong. It takes the good stuff from one of the failures of IPv4... CLASSFUL ROUTING... and does it right: Fundamentally, IPv4 got one part of it right with classful routing. Giving service providers large blocks of space, large enough to allow them to announce a single route out on the Internet. The problem is that the address space wasn't really large enough to support this in a sane manner, because growth wasn't predictable and mistakes would result in waste. IPv6 is *designed* for waste. You are *expected* to have vast realms of completely unused IP(v6) addresses. So there is no damage to be had by giving someone a delegation that's an order of magnitude too large, and even giving someone a delegation that's an order of magnitude too small is survivable without real problems. We can also delegate based on much more distant projections. Reducing the routing table size is one of the BEST ideas from classful routing, it just didn't pan out because it was done as classful routing. Now, we get a chance to learn from that mistake, and we can do it right. Using a 64-bit MAC when most current MAC's are 48 is not a mistake. It shows that someone somewhere had some vision towards the future.
You *can* do that. Nobody has said that it is impossible to set up an interface with a /130-slash-/131 if you want a point to point. But what we're talking about is service providers delegating to customers. Customers should *also* be allowed to subnet "however they want." Something they can't do right now, because they aren't given the space. If service providers are allowed to delegate teeny prefixes (meaning /64 or less), we're going to see consumers finding "ways" around that restriction, and then we're down an ugly road that's reminiscent of IPv4 and NAT and "you get one IP address, deal with it." That should be avoided at all costs. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Joe Greco wrote:
Customers should also be able to implement multiple networks with support for stateless autoconfig. Doing away with NAT means new ways of handing out networks, which I believe the IETF has come short on, but the start is to accept that they'll need at least a /64 per layer two segment for compatibility reasons. Implementations will vary, as will the knowledge of the customer, but it is safe to assume at this point that there will be implementations with support for stateless autoconfig and multiple networks/subnets/etc. Jack
On Mon, 04 May 2009 18:27:32 -0400, Jack Bates <jbates@brightok.net> wrote:
If I'm allowed to subnet my single /64, then I'm still not using NAT. And as long as I don't go beyond /80, autoconfig can still work, at least on ethernet -- which is pretty much 99.999% of cases. (not that I advocate the use of autoconfig. *grin*)
Ricky Beam wrote:
Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig, and it expands the 48 bits to 64 bits by inserting FFFF or FFFE depending on if the original is a MAC-48 or EUI-48 identifier. That being said, you might be able to use stateless with tokens which can be less than 64 bits, though not sure how well implementations will handle stateless autoconfig with less than a /64. You can also use DHCPv6 with TA/NA addresses, though Cisco doesn't support those options in their IOS implementation at this time, open source DHCPv6 servers do. You can also backup to static assignments. Jack
Valdis.Kletnieks@vt.edu wrote:
I think Ricky's point is that he could do autoconfig in a /80 as long as there isn't the semi-gratuitous MAC-48->EUI-64 expansion.
Is there an implementation of autoconfig that doesn't do the expansion? I haven't tested it, but I'm not even sure that autoconfig would work with a token using a smaller than /64 prefix. It may work, but it's definitely outside the standard and would be implementation specific. Jack
On Mon, 04 May 2009 22:29:29 -0400, Jack Bates <jbates@brightok.net> wrote:
EUI-64 is required for autoconfig...
"On paper" :-) There's no technological reason why the 48bit MAC wouldn't be enough on it's own. Tacking on an extra (fixed) 16bit value doesn't make it any more unique. Doing so also would not add any level of complexity to address determination -- it's still a simple concat. Show of hands. How many people have massive firewire based IP networks? *crickets* Right. (I've used ip1394 like twice in over a decade... a file transfer between a laptop and desktop.)
For today. But, remember, this sort of shortsightedness is what landed us in the current IPv4 pain. Do you have anything beyond hysterical raisins to justify not making a future-proofing change now, before IPv6 is widely deployed, and changes can be easily made?
Tacking on an extra (fixed) 16bit value doesn't make it any more unique.
For ethernet, today.
Doing so also would not add any level of complexity to address determination -- it's still a simple concat.
Correct. So it's trivial to do, and it future-proofs us to be able to support EUI-64. That means that when the next great networking technology comes about, we don't need to make invasive changes, devise transition strategies, or wreak havoc.
Show of hands. How many people have massive firewire based IP networks?
Who the fsck cares.
*crickets* Right. (I've used ip1394 like twice in over a decade... a file transfer between a laptop and desktop.)
Yeah, that's nice. Who the fsck cares. Most of the significant problems with IPv4 are due to people thinking small, and not having a vision towards the future. Back when "computers" meant something the size of a VAX 11/750 or bigger, it is easy to see how designers didn't really have the concept that maybe someday there would be microprocessors all around us, that we'd be walking around with cell phones that had more computational capabilities than their entire computer. Likewise, I am afraid to wonder what we're going to see in another 30 years, but my bet is that it'll be networked! So, please, please, either explain why EUI-64 is such a horrible, awful, terrible hardship for you to endure. If it's because your Atari 400 doesn't have the cycles to keep up with EUI-64 translation at gigabit speed, then say that. Or you can outline some other way in which it is fundamentally a bad idea to future-proof by using the latest EUI standard, rather than an old, dated standard. If you don't actually have a rational explanation, then you just appear to be a troll. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Tue, 05 May 2009 00:08:51 -0400, Joe Greco <jgreco@ns.sol.net> wrote:
For today. But, remember, this sort of shortsightedness is what landed us in the current IPv4 pain.
48bit MACs have caused IPv4 address exhaustion? Wow. I didn't know that.
... justify not making a future-proofing change now, before IPv6 is widely deployed, and changes can be easily made?
It's not very widely deployed now, and it's already too late to make simple changes. ONE single, simple protocol change requires a lot of people to do a lot of work.
For ethernet, today.
IPv6 is a decade old and there still aren't many people using it. Ethernet is 30 years old. Do you honestly think you'd be able to roll out EthernetV2(tm) with 64bit MACs anytime in the next century? Ethernet is far more fundamental than IPv4, grown into the silicon of almost everything. Even though there are alternatives to ethernet (infiniband anyone?) ethernet is still *everywhere*.
Correct. So it's trivial to do, and it future-proofs us to be able to support EUI-64. ...
And the only reason we'd need to use EUI-64? Because some twits decided to use a Layer 2 address in a Layer 3 address. Or have we exhausted EUI-48 as well?
Most of the significant problems with IPv4 are due to people thinking small, and not having a vision towards the future. ...
I'm thinking small? No. I'm being frugal and efficient -- "conservative". FORCING networks to be no smaller than /64 -- per the fundamental requirement for SLAAC -- when there's absolutely no forseeable need for 18billion billion hosts per network is wasteful beyond measure. I see this a fundamentally the same as handing out /8's 25 years ago -- "because the protocol (classfulness) requires it." Just because *we* see the IPv6 address space as unbelievablly huge *today*, doesn't mean we should carve it up in recklessly huge chunks. That's exactly how IPv4 was seen long ago, and we've been and will be living with that mistake for decades. So, to sum up... we're being locked into using /64's as a minimum allocation simply because a fundamental part of IPv6 (SLAAC) requires an EUI-64 -- taking a layer-2 address and promoting it to a layer-3 address, more or less because it's there and supposed to be globally unique (read: we're lazy and don't want to figure out another way to be "stateless".) This despite no current internet devices using EUI-64[*], and the overwelming technology leader (ethernet) doesn't and very likely never will (given the millions of tons of existing hardware in use.) ([*] according to the wiki, firewire and zigbee are the only things using EUI-64. I don't know of anyone using firewire as a network backbone. (obviously, not that you care.) Zigbee is relatively new and similar to bluetooth; will people use them as a NIC or connect little zigbee gadgets to the internet -- well, there are coffee makers, vending machines, and christmas lights on the internet, so as a novelty, certainly. How many bluetooth devices are running IP over bluetooth? That said, I could see PAN meshes (personal area networks) eating a huge number of addresses, but /64???)
On Tue, 5 May 2009, Ricky Beam wrote:
That's exactly how IPv4 was seen long ago, and we've been and will be living with that mistake for decades.
It was fixed 15 years ago, but not before more than half the space was "wasted". With IPv6 we can use current policy and only "waste" a /3 and then we can change policy and do something smarter if needed. This /3 will last us a long time and we have plenty of time to create something better than SLAAC. It's time to deploy IPv6 *NOW* with what we have, not to start to change it in fundamental ways and delay deployment several more years by starting to change IPv6 stacks who are by now fairly mature. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
Fixing ipv4 didnt erase the pain of the brokeness. Odds are it will be much much worse if that happens with ipv6. Doing potentially stupid things now because we can fix it later isnt intelligent. One potential problem scenario is larger proliferation of DFZ routes than would have otherwise been necessary - simultaneous with large scale ipv4 de-aggregation. About 13% of ipv6 is assigned for addressing purposes. According to IANA, the /3 is about 0.8% allocated and we already have 1700 ipv6 routes, which according to statistics is about 0.014% of the /3. And we arent even using it for anything important yet, meaning something that could not be done over ipv4 internet or ipv4 vpn. At this rate, the /3 will be full with about 12 million routes. That isnt far fetched assuming most corporations and other tech savvy users go with PI over the next 15-30 years. Even if we can stick to roughly one prefix per AS, my best guesstimate is anywhere between 50-250k ipv6 routes until ipv4 routes start declining, depending on how long that takes. Expecting organizations to renumber into larger assignments in order to keep overall prefixes low is an unrealistic hardship. If the goal is to keep each organization to a single prefix, /48 per customer suggest a minimum allocation on the order of either /24 (16m customers, 2m per /3) or a /28 (1m customers, 34m in the /3) instead of a /32 (65k customers, 530m in the /3). Are there any better numbers out there other than these hastily scribbled back of envelope ones? I suppose the question is, are we building a system that can stand for decades or centuries? Right now it seems to be optimizing for both. Joe
No, thinking small is what landed us in the current IPv4 pain.
No, it's not too late to make simple changes. We're still figuring out lots of bits about it.
Yes, I do think that something fundamental like that will happen at some point. On the other hand, can you *guarantee* that it will not? Because if you cannot *guarantee* that it will not, then that raises doubts as to the wisdom of your advice. And quite frankly, you've already conceded that a technology - firewire - exists that does use EUI-64.
Do you have an equally brilliant but completely different suggestion as to how to implement reliable stateless autoconfig in IPv6? But it's not the only reason we need to use EUI-64. We know that someday, even if it's many years out, we'll run out. And further, I believe that the rate of depletion will only increase, as the number of network-capable devices explodes.
Or have we exhausted EUI-48 as well?
No. Do we have to do that before we figure out what to do next? Are we too stupid to learn from the period of history we're going through right now? With IPv4, we've waited until we're just about out in order to figure out where to go from here. That was dumb. Predictable but dumb. Why wait for resource depletion in another realm, when we already know that's a bad thing to do?
Yes, that's thinking small, because IPv6 was *designed* to be liberal. Intentionally. By massive amounts, so that no credible claims could be mounted that there was any good reason for "being [excessively] frugal."
RFC3041. That's a need. It works today. It's implemented on FreeBSD, Linux, and Microsoft stacks, among others. We just went through an educational process with the DNS protocol to learn why the ability to do this sort of thing is a completely credible "need", as well. So I'm sorry to say, but you're just wrong, that's a need, and it's there now.
You don't think that the IPv6 designers thought long and hard on that very question? You're second-guessing them? I'm sure we'd all appreciate a presentation as to why 128 bits isn't enough. Really, if it's a problem, now is the time to decide to go to 256 bits and IPvX. These are huge numbers that we're talking about. At the time IPv4 was created, people were looking at 4 billion and refrigerator-sized routers and thinking, "this'll last us for a while." And it did. But I don't recall them assuming that IPv4 was the end of the road. With IPv6, we've made some very clear decisions about what we need to last us for a while. One of the most visionary things we've done is to set aside a huge space for local network addressing. This leaves us with a huge amount of space to work with in the future, if, for whatever reason, the current ideas don't pan out.
You're not being locked into it. Nobody's forcing you to use it. I'm sure that you can find someone willing to delegate you a single /64 for you to subnet along the lines of the traditional IPv4 ways.
They have to use it as a network backbone? Why, exactly? It has to be a technology that we are using today? We're not allowed to look at the way technology has developed and extrapolate that we might have many, many more uses, new technologies, and needs in the future? Hey, you know what, I'm just going to say this. Your thinking is definitely small-scale. There is nothing in IPv6 that prevents you from making a network work on the teeny scale. However, if we were to deploy your ideas IPv6-wide, then those of us who can think on the grand scale would find ourselves shortchanged for no good reason. Therefore, IPv6 deployment needs to continue in the way it was designed and envisioned, so that you are able to do your thing, and I am able to do mine. HTH, HAND, etc. I'm out of here. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Tue, 05 May 2009 09:13:06 -0400, Joe Greco <jgreco@ns.sol.net> wrote:
No, it's not too late to make simple changes. We're still figuring out lots of bits about it.
Yes, it is too late. IPv6 as it stands is a huge pile of crap and bloat. We'd be better off straping the whole mess and starting over, but that ain't gonna happen. Over the next dozen decades and hundreds of RFCs, we might have something that looks like it was designed by competent people instead of glued together mess we have today that was created by committees with multiple personal and political agendas.
On the other hand, can you *guarantee* that it will not?
Yes. Yes, I can. Ethernet has been around for decades from 10M to 100M to 1G to 10G and now we're working on 100G. Look around the room and count the number of devices containing ethernet technology. It's f'ing EVERY. WHERE. Every single piece will have to be replaced to support EUI-64. It's grown into the silicon, so there's no amount of software updates that can fix it like we're attempting to do with IPv4-to-IPv6.
And quite frankly, you've already conceded that a technology - firewire - exists that does use EUI-64.
True. But you ignore the fact that firewire isn't used as an internet transport technology. Where's the 24 or 48 port firewire switches? You can run IP over fibre channel, but I don't know of anyone who does so outside of private (read: internal) networks. (Clusters often use FC-IP within the SAN for node-to-node signaling.) Ethernet won. It uses 48bit addressing. It's not going to change. That "mistake" is now cast in diamond. The world is not going to throw away all the ethernet gear because someone wants to change the addressing scheme.
Do you have an equally brilliant but completely different suggestion as to how to implement reliable stateless autoconfig in IPv6?
Sure I do. And I'm not the only one. In fact, many IPv4 systems have an address generator... the thing that builds "local" 169 addresses. The simple fact is they took the dirty, brainless simple path of using what is supposed to be a unique identifier (Layer-2's MAC-48) and directly attching it to the layer-3 (IPv6) address. Everyone is confusing "stateless" with "constant" and "consistent". SLAAC doesn't need to generate the exact same address everytime the system is started. Stateless simply implies a host is not depending on data maintained from an external source. A host can generate whatever random number it needs. It doesn't have to be *globally* unique; it only need be *locally* unique. There are plenty of ways to generate and verify local uniqueness.
No. Do we have to do that before we figure out what to do next?
Do we have to replace trillions of dollars in hardware because of a problem we don't have?
You must be new here. IPv6 was designed a long time ago. Long before we "ran out of addresses". Nobody has deployed it because nobody has deployed it. IPv4 works. We still have address space to hand out -- and will for several more years. IPv4 will *continue* to work long after IANA has no more blocks to assign. Bottom line... there's no pressing reason to make the jump, and a whole bunch of reasons to hold off. But you don't seem to care about any of that -- we should all continue driving our pintos with the exploding gas tank until your local shop has time to replace it. No. Thanks.
RFC3041.
Ah, so you conceed there *are* ways to generate addresses that aren't the MAC address. Therefore, they don't have to be 64bits. However, it's easier to be unique with larger numbers.
I'm not guessing at all. I know they didn't. And where the f*** have I ever said 128bit isn't enough. My whole issue is with forcing people into 0% utilization of their address space "because we have lots of address space" and "eventually we'll need that space." Yet, you seem to think we're justified in giving people billions upon billions upon billions of addresses because we might, someday, somehow, have millions of gadgets that need to be globally addressable. But that's completely different from the mess we have with IPv4... handing out /8's because we could, then throwing on the breaks and promoting (even demanding) "responsible use", all the way to today where everyone asks for more address space than they currently need because "we might need it later" but later never comes. 128bit addressing is uber-plenty and will last us a long time as long as we continue to practice "responsible use".
And you don't see the repeat with IPv6? *sigh* I see it everywhere... the address space is *HUGE*. there's no way we'll ever use it all. "enough addresses to assign every grain of sand on the planet it's very own..." But yet, day one we slice the address space in half and place a "globally unique" (probablly) number in the lower half. And then propose slicing the uper half into chunks large enough to give every house 256 to 65,536 *individual* globally unique spaces.
Yes, we all are. We will all be given a minimum of a /64, while no one has a need for even a billionth of that space, and aren't likely to for the forseeable future. When they do, *then* give them the space they need. Ah, but "renumbering is a pain", you say. That's another of those IPv6 fundamentals... renumbering your network is supposed to be easy -- prefix delegation and autoconfig makes it all Magic(tm).
Ricky Beam wrote:
Actually, they probably would have stuck to a 64 bit address space and it was debated. Then it came down to, let's make it a 64 bit network space, and give another 64 bits for hosts (96 bits probably would have worked, but someone apparently feels the next bump from 64bit is 128bit so there we go). Renumbering, when the system works is a breeze. Of course there are a billion places where autoconfiguration doesn't work well, and those will still require effort to renumber. At least with this method, if Cisco supports DHCPv6 IA_TA option and proxy-nd similar to how they support IPv4, then a single pool will handle an entire pop no matter what. I'm sure 32bit host addressing would have been fine too, but then we're stuck with that 96bit value that no one likes. Jack
On Tue, 05 May 2009 16:13:05 -0400, Jack Bates <jbates@brightok.net> wrote:
Ah, but they half-assed the solution. IPv6 makes no distinction between network and host (eg. "classless"), yet SLAAC forces this oddball, classful boundry. Routing doesn't care. Even the hosts don't care. Only the tiny craplet of autoconfig demands the network and host each be 64bits. That's brilliant!
Ricky Beam wrote:
So ask the IETF to drop it to generic 32bits. I presume they can draw up mathematical formulas to show that 32 bits can autogen and avoid a conflict with the maximum number of IPs likely to be found on a segment without having to do excessive DAD requests. Of course, they'll have to obsolete the 64 bit model and I suspect the vendors will complain about it. Jack
I would venture a guess that there are atleast two divergent opinions here that will "never" be reconciled. I propose you agree to disagree and move forward ... or take the argument back in time about 15 years, when these issues were being debated and solutions (great, good, mediocre, bad - efficient, wasteful - constraining, freeing ... whatever) were decided upon. /TJ ... Also thinking the level of vitriol is a bit counter-productive, but this is the Internet ... Sent from my Verizon Wireless BlackBerry -----Original Message----- From: "Ricky Beam" <jfbeam@gmail.com> Date: Tue, 05 May 2009 15:58:16 To: Joe Greco<jgreco@ns.sol.net> Cc: nanog list<nanog@nanog.org> Subject: Re: Where to buy Internet IP addresses On Tue, 05 May 2009 09:13:06 -0400, Joe Greco <jgreco@ns.sol.net> wrote:
No, it's not too late to make simple changes. We're still figuring out lots of bits about it.
Yes, it is too late. IPv6 as it stands is a huge pile of crap and bloat. We'd be better off straping the whole mess and starting over, but that ain't gonna happen. Over the next dozen decades and hundreds of RFCs, we might have something that looks like it was designed by competent people instead of glued together mess we have today that was created by committees with multiple personal and political agendas.
On the other hand, can you *guarantee* that it will not?
Yes. Yes, I can. Ethernet has been around for decades from 10M to 100M to 1G to 10G and now we're working on 100G. Look around the room and count the number of devices containing ethernet technology. It's f'ing EVERY. WHERE. Every single piece will have to be replaced to support EUI-64. It's grown into the silicon, so there's no amount of software updates that can fix it like we're attempting to do with IPv4-to-IPv6.
And quite frankly, you've already conceded that a technology - firewire - exists that does use EUI-64.
True. But you ignore the fact that firewire isn't used as an internet transport technology. Where's the 24 or 48 port firewire switches? You can run IP over fibre channel, but I don't know of anyone who does so outside of private (read: internal) networks. (Clusters often use FC-IP within the SAN for node-to-node signaling.) Ethernet won. It uses 48bit addressing. It's not going to change. That "mistake" is now cast in diamond. The world is not going to throw away all the ethernet gear because someone wants to change the addressing scheme.
Do you have an equally brilliant but completely different suggestion as to how to implement reliable stateless autoconfig in IPv6?
Sure I do. And I'm not the only one. In fact, many IPv4 systems have an address generator... the thing that builds "local" 169 addresses. The simple fact is they took the dirty, brainless simple path of using what is supposed to be a unique identifier (Layer-2's MAC-48) and directly attching it to the layer-3 (IPv6) address. Everyone is confusing "stateless" with "constant" and "consistent". SLAAC doesn't need to generate the exact same address everytime the system is started. Stateless simply implies a host is not depending on data maintained from an external source. A host can generate whatever random number it needs. It doesn't have to be *globally* unique; it only need be *locally* unique. There are plenty of ways to generate and verify local uniqueness.
No. Do we have to do that before we figure out what to do next?
Do we have to replace trillions of dollars in hardware because of a problem we don't have?
You must be new here. IPv6 was designed a long time ago. Long before we "ran out of addresses". Nobody has deployed it because nobody has deployed it. IPv4 works. We still have address space to hand out -- and will for several more years. IPv4 will *continue* to work long after IANA has no more blocks to assign. Bottom line... there's no pressing reason to make the jump, and a whole bunch of reasons to hold off. But you don't seem to care about any of that -- we should all continue driving our pintos with the exploding gas tank until your local shop has time to replace it. No. Thanks.
RFC3041.
Ah, so you conceed there *are* ways to generate addresses that aren't the MAC address. Therefore, they don't have to be 64bits. However, it's easier to be unique with larger numbers.
I'm not guessing at all. I know they didn't. And where the f*** have I ever said 128bit isn't enough. My whole issue is with forcing people into 0% utilization of their address space "because we have lots of address space" and "eventually we'll need that space." Yet, you seem to think we're justified in giving people billions upon billions upon billions of addresses because we might, someday, somehow, have millions of gadgets that need to be globally addressable. But that's completely different from the mess we have with IPv4... handing out /8's because we could, then throwing on the breaks and promoting (even demanding) "responsible use", all the way to today where everyone asks for more address space than they currently need because "we might need it later" but later never comes. 128bit addressing is uber-plenty and will last us a long time as long as we continue to practice "responsible use".
And you don't see the repeat with IPv6? *sigh* I see it everywhere... the address space is *HUGE*. there's no way we'll ever use it all. "enough addresses to assign every grain of sand on the planet it's very own..." But yet, day one we slice the address space in half and place a "globally unique" (probablly) number in the lower half. And then propose slicing the uper half into chunks large enough to give every house 256 to 65,536 *individual* globally unique spaces.
Yes, we all are. We will all be given a minimum of a /64, while no one has a need for even a billionth of that space, and aren't likely to for the forseeable future. When they do, *then* give them the space they need. Ah, but "renumbering is a pain", you say. That's another of those IPv6 fundamentals... renumbering your network is supposed to be easy -- prefix delegation and autoconfig makes it all Magic(tm).
On Tue, 2009-05-05 at 15:58 -0400, Ricky Beam wrote:
"stateless" with "constant" and "consistent". SLAAC doesn't need to generate the exact same address everytime the system is started.
No - but it is *phenomenally useful* if it does. Changing addresses is only ever something you want in very specific circumstances.
Wow, that's a metaphor that has been not merely mixed, but shaken and stirred as well. Are you for a move to IPv6 now or not? Is the Pinto IPv4 or IPv6? What does the exploding gas tank represent? If you mean we should hold off on moving to IPv6, then I disagree strongly. Here's a quote I like (because it's mine :-) "[...] the storm clouds have well and truly gathered, thunder is rolling in the hills, great big rain drops are splotting into the dust all around us, and what are we doing? Wandering around the outside of the Ark tut-tutting about the quality of the woodwork and loudly suggesting the construction of various sorts of rowboats." For what it's worth, I actually agree with you that 64 bits is way too short a prefix for the job. 80 would have been better, and some framework for *choosing* the prefix length and (say) hashing the MAC would have been even better. As it does you, the waste offends me, because I DO think we are repeating an IPv4 mistake. On the other hand - we have DHCPv6 to work around it. Noone HAS to use SLAAC. DHCPv4 is in every piece of home kit these days, with useful defaults, there's no show-stopper reason that DHCPv6 cannot do the same job. With a bit of work it could do a much better job. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On Tue, 05 May 2009 20:39:23 -0400, Karl Auer <kauer@biplane.com.au> wrote:
I'm complaining that the IPv6 we're all being asked to use is a buggy contraption that's best parked until more of it's issues are resolved. Once we start down the path capable of supporting SLAAC's /64 requirement, there's no going back. The address space has be carved out; there's no "uncutting" that pie. (much in the same way the /8 handed out in the early 80's aren't being reclaimed.)
If you mean we should hold off on moving to IPv6, then I disagree strongly. Here's a quote I like (because it's mine :-)
The flood hasn't started yet. And the ark isn't finished; with enough people bailing water, it might stay afloat. :-)
On the other hand - we have DHCPv6 to work around it. Noone HAS to use SLAAC. ...
Yes, but as long as it exists, someone *will*.
On Tue, 2009-05-05 at 22:43 -0400, Ricky Beam wrote:
I'm complaining that the IPv6 we're all being asked to use is a buggy contraption that's best parked until more of it's issues are resolved.
Using it is the fastest way to get issues resolved. It worked for IPv4... :-) Expecting all the issues to be fixed before we start using it is the best way of all to ensure that it never gets off the ground at all. It's an excuse, and not a very good one.
I disagree. I can see several ways to retrofit more and better functionality in this area later.
The flood hasn't started yet. And the ark isn't finished; with enough people bailing water, it might stay afloat. :-)
Hm, like the fellow falling out of a tall building. As he flashed past each window on his way down, people on each floor heard him murmuring "so far so good...". Look, the Ark *is* finished. It floats. It can be steered. It has space for everyone. The fact that some of the plumbing is a bit iffy is just not a major issue right now; getting everybody on board is. We have LOTS of very clever people ready to bail, many of whom are quite capable of inventing bilge pumps from scratch. Sure the flood hasn't started. The fact that we are up to our ankles in water is a purely temporary phenomenon, nothing to worry about. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On Wed, May 06, 2009 at 06:57:53AM -0700, David Conrad wrote:
Speaking as a builder, I have to say the screen doors were on the plans when I got there. I gather the planners believed they would facillitate use of the ark by hybrid human-acquatic lifeforms that did not exist at the time, nor do they exist today, but were hoped to exist because mermaids and mermen are, like, totally hot. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Subject: Re: Where to buy Internet IP addresses Date: Tue, May 05, 2009 at 10:43:17PM -0400 Quoting Ricky Beam (jfbeam@gmail.com):
I believe Net 14 has been. http://www.ripe.net/ripe/meetings/ripe-55/presentations/vegoda-reclaiming-ou... Please do note that a /8 is being eaten every month by todays consumption rate.
The flood hasn't started yet. And the ark isn't finished; with enough people bailing water, it might stay afloat. :-)
My feet are humid... Not from Python boots. -- Måns Nilsson
On Wed, 6 May 2009, Karl Auer wrote:
You'll love RFC 4941 as implemented by Windows Vista and later. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
On Wed, 2009-05-06 at 14:24 +0100, Tony Finch wrote:
The fact that MS chose to use that as the default with Vista is odd, and I think a bad choice, but RFC4941 is not a bad thing in itself. It is an alternative that makes good sense in some contexts - but not, I think, in most contexts. And it's easy enough to turn off. XP uses temporary addresses too, also easy to turn off. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Nope, different. No EUI64 at all - goes straight to randomized IIDs, but (cough) not to be confused with Temporary/Privacy IIDs. Randomized Link-local, randomized non-link local (Site|UniqueLocal|Global). FWIW - WinXP uses 24hours/change_in_prefix/reboot as the default criteria for new Privacy IID creation, is that not aggressive enough? I'd be curious to know what makes it "awful" IYO, I use it daily and have few complaints ... ? (I think the bigger / better complaint against WinXP is the lack of IPv6-transport support for DNS ... and perhaps the lack of DHCPv6 client functionality as well) /TJ
On Wed, 06 May 2009 16:50:15 -0400, TJ <trejrco@gmail.com> wrote:
FWIW - WinXP uses 24hours/change_in_prefix/reboot as the default criteria for new Privacy IID creation, is that not aggressive enough?
I define that as "not aggressive". (I've seen ISPs rotate addresses (DHCP) faster than that.)
I'd be curious to know what makes it "awful" IYO, I use it daily and have few complaints ... ?
Where's the GUI for dealing with it? It's Windows(tm) after all. And it brings along a few other things we didn't ask for... a Toredo(?) tunnel interface, for one. But yes, it is functional. It'll get you to the small assortment of ipv6 websites around.
Yes, but those things require more than just an IPv6 stack. Service components have to be changed to handle DNSv6 and DHCPv6.
Fair enough, but IMHO it is aggressive enough to accomplish the design goal.
Gotchya, sure some GUI would be nice ... but "netsh inter ipv6 install" + SLAAC (+IPv4 DHCP) isn't too bad :)
6to4, ISATAP and Teredo all come along for the ride. While they may not have been asked for, the catch there is to make it easier for us poor users during this "transition" period ("transition in scary quotes because that is a terrible name ... much better : integration / co-existence).
Charles Wyble wrote:
A million addresses is 1/16th of one OUI in EUI-48, and there are 4,194,304 OUIs (after you take out the local/global and multicast/unicast bits). Billions or even trillions of addresses are manageable without needing EUI-64; millions is a drop in the bucket. Still, it's good to know that another link layer -- which people _will_ be running large IPv6 networks on -- is using EUI-64 and that it's not just a FireWire thing. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Tue, 05 May 2009 13:28:25 -0400, Charles Wyble <charles@thewybles.com> wrote:
Utility companies utilize Zigbee pretty extensively. So that's millions and millions of addresses right there.
But does the entire planet need to talk to those critters? No. Nor should they even be able to. Those little gadgets can very happily live within a link-local only network, or isolated private network. I know the subject of "nat" in IPv6 will have people chasing me with pitchforks, but there are a lot of things in the world that don't need to be accessable by the entire world and should be (must be) protected from even accidentally being exposed to the Evil Internet(tm). Everyone will chime in with "firewall them", but the risk exists as long as they have global addresses. Having to break into a machine in order to get at the internal network (ala today's NAT) makes the network much safer -- not "safe", but safer than directly naked on the internet. (If you want to do numbers... the utility company could hang 2billion zigbee's on every human on Earth and still not fill *one* /64. [global pop ~ 6.77 billion])
Ricky Beam wrote:
Really.... we don't have enough debates going on in this thread?
Those little gadgets can very happily live within a link-local only network, or isolated private network.
Exactly. Behind the utilities (closely monitored and highly restrictive) firewall. Most likely behind multiple firewalls. (border fw, internal operations fw, monitoring network firewall). No reason they shouldn't have a fully routeable address.
This is no different then having machines with a public IP on the net today. A firewall is such a small part of an overall security architecture. Don't troll.
* Jack Bates:
I'm rather puzzled why this blatant layering violation is still sold as a must-have feature. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer wrote:
It's not a must have if you manage your own network. There are always other options. That being said, if you are an ISP handing out prefixes to customers, there is an expectation that the customer will probably use it given the direction CPE implementations are going. Thus you have to predict that if you don't want to setup all your customer's networks for them, they'll probably be using /64 per subnet. Jack
you can. there was a bit of a war in the ietf some years back, and yhe 64 bit boundary is a convention. hardware must route and forward on 128 bits. do other than 64 and you do not get auto-conf. some do not consider this a loss, others do.
So far, Cisco's gear is the only IPv6 routers I've messed with. And they will not let you set an interface to anything smaller than a /64.
i wonder what strange gear you tried. all routers, cisco and other, i play with operate on 128 bits. randy
On Tue, 2009-05-05 at 04:49 +0200, Randy Bush wrote:
This is an important distinction. - you CAN subnet however you like, with any number of bits in your prefixes - autoconfiguration will work only in subnets with a 64 bit prefix. The two matters are quite independent of each other, as far as I can tell. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On Tue, 05 May 2009 13:04:49 +1000 Karl Auer <kauer@biplane.com.au> wrote:
Older protocols, like classful IPv4, Appletalk etc. put a hard boundary between the network and node portion. That was simple and, in the case of IPX, Appletalk and DECNET, it was very convenient to have fixed length network and node portions. IPv4 originally had a single boundary between the network and node portion - if you look up the early RFCs/IENs, the IPv4 addressing format was similar to Class A. Of course in the case of IPv4, those classful hard boundaries caused problems when we needed to squeeze more addresses out of the 32 bits by moving to a fully varying boundary between the network and node portions. IPv4 software in all nodes needed to be upgraded to work. I think of the way IPv6 has done it is the middle ground. For forwarding, the boundary between the network and node portions isn't hard - it's purely longest match on the whole 128 bits. However, because we've got so many bits, within a portion of the address space, a harder (but not hard) boundary exists, to benefit from the convenience of having fixed length node addresses, which results in things such as much simpler autoconfiguration etc. Regards, Mark.
On Mon, 4 May 2009, Ricky Beam wrote:
Blame IEEE. They claimed that for identifying network cards 64 bit ID will be used in th future.... (Already used in IEEE 1394)
I did not get any problem setting up any sunet length manually all the systems I tested. Best Regards, Janos Mohacsi
Mohacsi Janos wrote:
Even if that is true and doesnt require ethernet as we know it to be forklifted which may be enough to rule it out from ever happening (see 1500 mtu for reference), address auto configuration does not require 64 bits. Its just nicer that way. What IEEE is concerned about is global uniqueness purity. Global uniqueness into perpetuity isnt required operationally on a lan, its just nicer that way. Gateway directed auto-conf enable-able on any bit length, with icmp conflict detection seems no worse that what we have now with either dhcpv4 or apipa. Joe
If you are handing out /48s then if have more than 64k clients (or will in the next few years) then You should ask (or should have asked) for more than a /32 (Need 128k clients? == /31) ... (Need 512k clients? == /29) ... ... ... (Need ~512,000k clients? == /19) And, again, each of those clients has 64k subnets. With each subnet supporting as many hosts as they want to put there. And, we can allocate 2^16 (64k) of THOSE (/19) sized allocations from the CURRENT (2000::)/3. IMHO - While that should last us a "long time", we can follow that up with 4000::/3 - and revisit policies then, as needed. And, we could do something like use /56s for home-users and the math above "shifts larger" ... Ask, and ye shall receive. /TJ
Joe Maimon wrote:
What remains to be seen is what will happen when someone says "hey, my /32 is full, I need another one". Will it be: a) Sure, here's another /32, have fun! b) You didn't subnet very efficiently by current standards even though it was encouraged in the past; try to reclaim some space internally. ~Seth
On Mon, 4 May 2009, Seth Mattinen wrote:
We returned our vintage year 2000 /32 to RIPE and got a brand shiny new /25 instead. It helps to have a couple of tens of million customers. We hope we never have to pollute the DFZ, by just having a single prefix for the forseeable future. -- Mikael Abrahamsson email: swmike@swm.pp.se
Joe Greco wrote:
How is it the ISP's router is able to handle this? Be specific.
The primary benefit of chaining is to allocate the correct network length to a router. We are not just talking from the ISP to the customer, but from the customer's CPE out to other routers. I believe chaining also needs support for network length memory (ie, hey, I've been handing out 18 networks, so a /59 is my aggregate I should ask for), and of course, network length negotiation for PD.
Now explain why that can't be made to work at the CPE level.
If the ISP hands out a /56, the CPE will still need support for chaining. All devices from the ISP out to the furthest customer daisy chained router would need support for it. Anything else requires manual configuration which is beyond some people's capabilities. If someone wants to daisy chain 4 routers serially, with 2 subnets per router off a routing CPE, then even if the ISP hands out a /56, each of those routers needs to support chaining PD requests and ideally support only requesting exactly what they need. So: ISP -> CPE router /56 -> Linksys1 /61 -> Linksys2 /62 & /63 -> Linksys3 /62 -> Linksys4 /63 This is without the ISP participating in the chaining since they are automatically assigning a /56. However, with negotiation in place, an ISP could set a cap on network length (/56 or /48 as they may see fit) and can participate in chaining. So customer starts out with a /64, adds a router than supports 4 networks and the ISP switches them to at least a /61, possibly even just issuing a renumber, reclaiming the original /64. It would also be possible to define boundary caps in addition to upper caps in negotiation. ie, if you only want a /64, we give that to you. If you want a /62, perhaps a /60 is handed out instead. This is probably more useful for the ISP than it is CPE side, as the CPE has no idea up front how much they can obtain and wasting networks downstream through the home network could cause them to run out of assignment space. In addition, most home network equipment should be able to support individual /64 chained PD's without that much trouble given their smaller routing tables. So a chained PD request for /64's across home networks might work. however, How's a home router supposed to know it's actually chaining in the home and not talking to an ISP? So whatever we did, it would have to be somewhat generic to support both topologies. Or the protocols need to also support flags to define "Hey! I'm an ISP!" Which actually isn't a bad idea. See below.
I agree. That being said, if I presume one table entry per customer, it doesn't matter if that entry is a /64, /60, or a /56. Unfortunately, DHCPv6 itself doesn't seem to support dynamic length negotiation at this time, or chaining requests for supporting the automatic numbering of an entire home network with 5+ routers connected however the user wanted to connect them, perhaps completely inefficient and with routing loops. To work properly, this will have to be standardized, or home router implementations won't handle clueless home networking very well in a number of configurations. It may be useful to treat PD or some other protocol that handles the numbering, routing, and loop detection differently for home based networks where there is a presumption that just plugging something in should work without any knowledge of what happens inside the device. Jack
Joe Greco wrote:
I view with suspicion the notion that an ISP is going to take addressing direction from their customers, willy-nilly.
Now explain why that can't be made to work at the CPE level.
Home devices chain with NAT because that is the scheme most likely to work well enough by default 99% of the time out of the box, without requiring ANY upstream cooperation. Home devices that work out of the box for the common usage scenarios generate profit, those that dont generate loss. Joe
You snipped two of the three paragraphs I was responding to. The reply I made was not a response to the last sentence, which was all that you quoted, and so you may be confused about what I meant. I was talking the other direction. Internet routes a prefix to the ISP. ISP routes a (smaller) prefix to the access concentrator. Access concentrator routes a (smaller) prefix to the customer. Now, the question is, if you're sending all these prefix requests up to the ISP's router, why is *that* device able to cope with it, and why is the CPE device *not* able to cope with it?
Again, since I think you misunderstood my earlier question, I don't think my opinion was different than that. Throwing out any real world implementations, for the sake of a clean slate to see what "makes sense," let's sketch. You have an ISP network, with a large amount of space available, and a lesser amount of space dedicated to the POP. You have a customer network, assumed to live within some customer delegation. So what we want is something that can intelligently handle delegation in an automatic fashion, which probably includes configurable settings to request/register delegations upstream, and to accept/manage them downstream. There's no reason that this shouldn't be basic router capabilities. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Joe Greco wrote:
The CPE cannot cope with it due to lack of a chaining standard and the lack of customer understanding of configuring a router. An ISP, as currently designed will manually assign prefix lengths and how they are handed out at each layer of the network. A home user should not be expected to understand this level of complexity. A CPE would have to be told HOW to divide it's variably received prefix to assign it's own networks and then issue prefixes to other routers behind it. What is missing, unless I've missed a protocol (which is always possible), is an automated way for a CPE to assign it's networks, pass other networks out to downstream routers in an on-need basis. I say on-need, as there may be 3 routers directly behind the CPE and each of those may get additional routers and so on and so forth. A presumption could be made that route efficiency is not necessary at this level. ie, would it be practical or expected that an automatically configured network support > 100 routes or whatever a CPE can normally handle? Of course, if this support is built at a CPE level, there's no reason the protocol can't be extended and supported at the ISP level as well for those who wish to utilize it. An ISP, would of course prefer prefix aggregation and controls to set minimum and maximum aggregate space for a customer.
You have an ISP network, with a large amount of space available, and a lesser amount of space dedicated to the POP.
This setup in the ISP network is handled by hopefully clueful engineers and probably not automatically assigned by some cool protocol that routers speak (which would be cool, though, even if impractical).
For the home router, I believe that this is mandatory if we wish to continue to allow self configuring networks for home users. A little extended logic and it can also be useful in larger networks, possibly even to the point of an enterprise network able to completely number itself (including renumbering itself as necessary). Jack
On Tue, 5 May 2009, Jack Bates wrote:
Why wouldn't DHCPv6-PD work within the home as well as between the ISP and the home? I see little reason why the main home gateway can't get a /56 from the ISP, and then hand out /62 (or whatever) to any routers within the home that asks for PD? -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
Why wouldn't DHCPv6-PD work within the home as well as between the ISP and the home?
DHCPv6-PD requires manual configuration.
Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that? What if the ISP only gave a /60? The problem with automatic arbitrary splitting of a prefix into smaller prefixes is that the entire topology is unknown. In such a case, bidirectional communication is useful, as is multiple prefix assignments to a single node generated from chaining DHCPv6-PD requests. PD is not designed for multiple stage delegations without manual configuration for each stage. Even the PD clients I tried on linux failed horribly in how they assigned a prefix to the interfaces. One of them just took the prefix length and divided it by the number of interfaces. Another, which I ended up using allowed you to set the bits to use as a subnet, but that meant you had to know the length from the ISP, and then the desired length on each of the interfaces to set the appropriate SLA (ie, I couldn't tell it I want a /64 on the interface, but instead had to tell it the SLA is 4 bits, which from a /60 would give a /64, but if I received a /56 it would break and have to be changed to 8 bits). -Jack
On Tue, 5 May 2009, Jack Bates wrote:
DHCPv6-PD requires manual configuration.
Are you sure? Isn't it just that the current implementations do?
Guess someone needs to write a draft with BCP regarding this, or perhaps extend the protocol to include that the requestor can ask for a preferred size (or do multiple /64 PDs).
PD is not designed for multiple stage delegations without manual configuration for each stage.
I see no problem with sane defaults solving that problem. Now, if every ISP now adhered to handing out at least a /56 to each home, sane defaults could be created. If each ISP does it its own way, sane defaults won't work. So just hand out a /56 or /48 and be done with it. Your idea of chained /64 doesn't really solve anything that couldn't be solved with a /64 default PD handout in the home gateway as far as I can see it? -- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, May 05, 2009 at 02:49:01PM -0500, Jack Bates wrote:
In IA_NA's, there is a (undocumented in RFC 3315) convention to permit a client to supply an IAADDR with a zeroed address. This convention allows the client to supply preferred and valid lifetime hints without knowing a specific address it would like. I see no reason why a similar convention can't take root here; the bottom-most client supplies an IAPREFIX in its IA_PD with a zeroed network number, and the desired prefix length (suppose: /64 for its one downstream interface). The next hop combines the sum total of bitspaces required by its clients and presents a suitable requested size upstream (with memory, and resizing/renumbering as you go).
What if the ISP only gave a /60?
Then someone gets a STATUS_NoAddrsAvail. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Jack Bates wrote:
It doesn't need to; that's just a flaw in current implementations.
I think some folks are getting the model wrong. Each router requests from its upstream router the delegation of a /64 for each downstream link and inserts the appropriate route when a response arrives. If it receives a PD request on its downstream interface, it forwards it upstream; when the reply comes back, it inserts the appropriate route and forwards the reply to the requester. Presto, a non-geek user can chain as many CPE devices as desired and they automagically configure themselves. (The ISP who's serving all these requests _could_ preallocate a /48 or /56 per customer, which might make aggregation in the PE router easier, or they could just have a gigantic pool per PE router and hand out as many /64s as required to each customer, which would [unnecessarily, IMHO] conserve address space.) However, as interesting as this may be, it's not particularly useful to discuss how consumer ISPs _might_ do DHCPv6 PD when none of them have shown much interest in providing any IPv6 connectivity at all and many are blocking (through mandatory NAT) even 6to4. And, until the eyeballs can speak IPv6, the content isn't going to speak it either... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
For now: Reserve a /64 for your own allocations (SAA), then hand out half of what you have (i.e., of a /56 for the first CPE, so a /57) to the first asker, then a /58, then a /59 etc. The first asker (nested CPE) has a /57, reserves a /64 for itself (SAA), hands out a /58 to its first child (double-nested CPE), then a /59. This algorithm restricts width plus depth to 8 (64 - 56), which is probably fine for most residential applications. The probabilistic aspect (FCFS) may cause you cognitive dissonance, but little technical problem. (Something that could be said about many of the "I grew up on IPv4 so I don't understand IPv6" postings here.)
What if the ISP only gave a /60?
Don't do that then! (http://www.jargondb.org/glossary/dont-do-that-then) Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten
On Wed, 2009-05-06 at 07:12 +0200, Carsten Bormann wrote:
Really, /56 for everyone is the only way back to an Internet.
Sorry, I don't see why /56 is qualitatively different to a /60. Honest question - what's the difference?
Gruesse, Carsten
Gruesse, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On Wed, 6 May 2009, Karl Auer wrote:
Because more is more, and it makes it less likely that people will start to invent silly solutions to problems that do not really exist. With a /56, I can't really imagine this being not enough for 99.9% of households in 10 years, whereas I CAN imagine a household that needs more than 16 subnetworks, plus the PD model described in an earlier email makes a /56 more suited for chaining. We have no address shortage, there is little good to come out of trying to use as few IPv6 addresses as possible by means of constraints that are not necessary (let's be "wasteful" the first 50-100 years and "waste" the first /3, then we can look into if this is a problem or not). -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, 2009-05-06 at 07:49 +0200, Mikael Abrahamsson wrote:
Sorry, I don't see why /56 is qualitatively different to a /60.
OK, I'm convinced :-) Thanks, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Carsten Bormann wrote:
This makes a lot of assumptions that may not hold true and restricts home devices to treating IPv6 similar to how they treat IPv4. It's not scalable and it doesn't promote usage of multiple segments per device. The restriction is actually 6 if you make a more sane assumption of /61 per device and not /64. Standard CPE's can support multiple wireless networks and Ethernet segments. An ISP might divide up in a provided CPE, for example, wireless, data, voice, and video (which still needs unicast in addition to multicast). The netgear I configured last night for a customer supports 4 wireless networks plus ethernet.
I have little trouble with understanding IPv6, but I do have issues with the current state of it both in standards and in implementations. FCFS only works if home routers continue to work similar to the way they do.
See, that's where we disagree. Better standards is the only way back to the Internet. Solving all problems from end to end in diverse networks is the way back to the Internet. /56 is arbitrary. Making assumptions about how a network will be restricts the Internet. Jack
On May 6, 2009, at 14:52, Jack Bates wrote:
Better standards
Sure! (You are preaching to the choir here.) While we are still on the way there, we just: 1) Shouldn't waste time reinventing decisions that are a done deal (say, EUI-64 in SAA). 2) Shouldn't use the lack of our favorite feature as an excuse to do nothing (or worse, to dig the NAT hole deeper). 3) Shouldn't practice denial, but plan for at least a /56 for every customer relationship. Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten (This is my last message on this subject.)
Some times ago, i would say 6 or 7 years, there was a BoF proposition at IETF to deal with such issue. Work areas were to propagate routing mesh configuration information and automatic assignment of subnet prefixes to links. There were quite a lot of persons interested in such issues and some drafts were proposed. The name of the BoF was zerouter. Unfortunately, the working group was not created despite some real interest. David
********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************
On Tue, May 05, 2009 at 04:22:04PM -0400, Paul Timmins wrote:
Customer premise gear has a 'front side' and a 'back side', and it is already well ingrained behaviour for 'back-to-back port chaining' to create a single large bridged network in the home. What is the customer's anticipated result from front-to-back chaining? That seems much more reliable a hint to me than conditional behaviour. DHCPv6 PD is applicable to the ISP customer premise. DHCPv6 PD 'chaining' however is probably only applicable in some promised future where there are alternative home network medias to Ethernet, or to the Enterprise where the boundaries drawn in broadcast domains are administrative in nature and not technical (but still, all automated). -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
David W. Hankins wrote:
I presume by front you mean wan and back you mean lan? and it is
already well ingrained behaviour for 'back-to-back port chaining' to create a single large bridged network in the home.
Really? What CPE? My topology at home is motorolla dsl modem[1]->cisco 1841->catalyst 2924->wireless router->clients The connection between the modem and router is a routed connection. The default configuration of the Linksys kit I have seen is routed. I had to change it to operate as a bridge (a one click option in the gui), and turn off the local DHCP server to make a flat wired/wireless network. Otherwise it insists on being a router. [1] (It would appear that SBC recently changed their network to only allow their CPE with it's very limited configuration options. It's routed. Public IP on the WAN and a fixed private IP (192.168.1.254). It hands out 1 private DHCP address (192.168.1.64) What is the
customer's anticipated result from front-to-back chaining?
I'm not sure how many people do this. Many people have one integrated device hanging off their DSL modem. They then purchase wireless extenders to increase the reach. This is what I overhear being recommend by Frys and BestBuy sales folks, and it seems to work well. I don't know how many will do it in the future. I imagine that vendors will just make beefer wireless routers to handle increased load. They already have different models and software feature sets for "high end gamers".
That doesn't seem like a problem from the set of unsolvable problems. We have current protocols that do substantially more complicated things in a standard and interoperable way. Your average current everyday IPv4 CPE has a DHCP server on it, for example, which very roughly approximates the complexity of the issue.
Actually, my own belief is that this /would/ be practical, and it might even be made to work efficiently. A "home router" maintains a list of space that it has been delegated, and a list of actually-used space (assigned to directly connected interfaces, along with any routed blocks). Upon receipt of a delegation request, the router starts an algorithm to see what it can do. Because it has been allocating out of a /56, the "primary" /64 was delegated at offset 0. Two requests from secondary routers came in, one was offered a /64 at offset 128, one at offset 192. That ought to make reasonable sense. The first "secondary" router learns that it has a bunch of downstream routers, and in the worst case asks for a delegation one at a time for each. The primary router assigns the subnet at offset 129, updates its route to the larger netmask, and away it goes. There's actually no increase in the number of forwarding entries, and this can be done a number of times. Further, if the primary router decides that it is allocating a lot of space to a secondary router, it can assign a larger hunk of space, saving some setup time, or it can try to optimize for bit boundaries. Not all cases will be this optimal. However, it seems reasonable to try.
Exactly.
Yes, but I'm really just talking about the idea of doing meaningful aggregation and simplification.
Oh, yeah, let me say: I am assuming that it *is* mandatory that we come to a solution of some sort. It may not need to be day 1, but it ought to be.
A little pie in the sky, but I *want* to see that as an option. Not to trivialize Real Network Engineers(tm), but not everything has to be super complicated. I would like to see IPv6 reach a point where a mildly clueful person could plug in a "workgroup switch" into a managed corporate network, maybe even a few of them daisy-chained, and run a little web setup GUI that allows some basic network setup in fairly abstract terms, such as setting up a "protected" printer network that was only accessible to certain parties. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On May 4, 2009, at 10:08, Nathan Ward wrote:
Forwarding these requests up to the ISP's router and having several PDs per end customer is in my opinion the best way to go.
If the ISP sees (and has to hand out) the PD, some bean counter will put a price tag on it ("differential pricing"). If there is a price tag on it, nobody will pay the higher price, and everybody will put in a kludge to get by with one /64. Think about it: That's exactly the reason why we got mired in the InterNAT. Really, /56 for everyone is the only way back to an Internet. Gruesse, Carsten
On Fri, May 01, 2009 at 02:29:24PM -0400, LEdouard Louis wrote:
how much is Optimum Online charging you for each of the five? practically, you can not buy IP addresses. you can buy companies who have the right to use IP addresses (hard), or you can go to ARIN and justify your own "right to use" (not as hard, but then you have to deal w/ your ISP accepting routes for them), -OR- switch ISPs. if you are willing to wait for a while (12-18 months) - rumors are that folks might be able to swap/trade their IP space IRU's fairly easily... but thats just a rumor at the moment. Check the ARIN meeting minutes for the SAT mtg last week.
Thanks in advance
Louis
--bill
Thanks all! I will look into the various suggestions. --Louis -----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Friday, May 01, 2009 3:07 PM To: LEdouard Louis Cc: nanog@nanog.org Subject: Re: Where to buy Internet IP addresses On Fri, May 01, 2009 at 02:29:24PM -0400, LEdouard Louis wrote:
how much is Optimum Online charging you for each of the five? practically, you can not buy IP addresses. you can buy companies who have the right to use IP addresses (hard), or you can go to ARIN and justify your own "right to use" (not as hard, but then you have to deal w/ your ISP accepting routes for them), -OR- switch ISPs. if you are willing to wait for a while (12-18 months) - rumors are that folks might be able to swap/trade their IP space IRU's fairly easily... but thats just a rumor at the moment. Check the ARIN meeting minutes for the SAT mtg last week.
Thanks in advance
Louis
--bill
On Fri, May 1, 2009 at 2:29 PM, LEdouard Louis <LEdouard@edrnet.com> wrote:
Optimum Online business only offer 5 static IP address.
Correct, this is a business grade cable modem service, where the only allocation they will provide is a /29. But what do you expect for a triple play residential product for ~150/month that is asymmetric in nature (since it's designed around a residential users experience).
Where can I buy a block of Internet IP address for Business? How much does it cost?
If you need a larger allocation of IP space, you would need to look at the commercial grade services, specifically within Cablevision, that would be the Optimum Lightpath, but there are alternatives. There is a huge difference in quality and price between the OOL and the OLP product sets, but the later is symmetric.
Most of our devices only require an internal IP address to reach the internet, but we have a Juniper DX for load balancing.
The symmetric, commercial service seems a lot more up your alley if you are looking for server load balancing. Also, keep in mind, with the greater price tag comes a much greater SLA for service guarantees.
Well, in the OLP product set you would be able to obtain as much address space as you can reasonably justify (as is with most commercial product offerings). charles
Louis, may be a provider independent network is what you are looking for. This is an end-user block of IP addresses moving with you from one ISP to another, also can be multihomed to several ISPs together. Our company helps to obtain such networks and autonomous system numbers, from /24 (256 IPs, the least routed block in Internet) to even /18. There is no huge hardware requirements for obtain and using such networks, even PC router with free quagga software is enough. LEdouard Louis wrote:
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
participants (47)
-
Barry Shein
-
Bill Stewart
-
bmanning@vacation.karoshi.com
-
Carsten Bormann
-
Charles Gucker
-
Charles Wyble
-
Charles@thewybles.com
-
David Conrad
-
David Schwartz
-
David W. Hankins
-
david.binet@orange-ftgroup.com
-
Durand, Alain
-
Florian Weimer
-
Frank Bulk
-
Ian Mason
-
Jack Bates
-
James Hess
-
Jay Hennigan
-
Joe Greco
-
Joe Maimon
-
Joel Jaeggli
-
Karl Auer
-
LEdouard Louis
-
Leo Bicknell
-
Leo Vegoda
-
Mans Nilsson
-
Mark Andrews
-
Mark Smith
-
Matthew Moyle-Croft
-
Matthew Palmer
-
Max Tulyev
-
Mikael Abrahamsson
-
Mohacsi Janos
-
Nathan Ward
-
Paul Timmins
-
Randy Bush
-
Ricky Beam
-
Robert E. Seastrom
-
Seth Mattinen
-
Stephen Sprunk
-
sthaug@nethelp.no
-
TJ
-
Tony Finch
-
Tore Anderson
-
trejrco@gmail.com
-
Valdis.Kletnieks@vt.edu
-
Youssef Ghorbal