Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment Re:Solution (Score 1) 185

I guess by use of VPNs, as it works now (see http://btguard.com/, https://www.ipredator.se/ etc). So essentially it won't get sold, but rented (it might get rented for indefinite amount of time for fixed one-time price, though - depending on the bussiness model chosen). Of course, your latency will go up compared to normal IPv4, but hey...

Also, you CAN transfer an IP range, and not just give it up.
See for example https://www.arin.net/resources/request/transfers.html, but other RIRs have similar policies. You just agree with potential customer that you'll transfer part of your IPs to them after they make a payment to you. So while you're not technically selling them IPs, practically you are (you're transfering them your IPs only after they give you their money). But it would be more "gray" than "black" market...

Comment Re:Typical West-European sensibilities (Score 1) 185

Still, about half of the Europe (as in the continent) is not in GMT+1, but in GMT, GMT+2, and GMT+3.

Hence my remark that your claim "Europe is in GMT+1" shows as much elitism and unawareness of timezones, as you accuse the OP of.
Just pointing out your hypocrisy, no need to get so upset about it :)

(and you'd be amazed how many people in those other timezones there are - way way more then in just the example city of Moscow. But I'll leave finding that number as a homework, you might learn few things about Europe in a process)

Comment Re:Never do today what you can put off 'til tomorr (Score 1) 185

Yes, there always needs to be some incentive to force them to make a change. However, a market itself will be force enough to force it. Not yet though for those looking only on short-term (and hence losing market in the long term) - I guess it will be at least two to three years before interesting stuff appears on internet as IPv6-only, and IPv4-only people will not be able to get to those. But from that moment onward, it will start hitting such IPv4-only ISPs harder and harder every day with customers leaving for ISPs that lets them see "whole Internet" without blackholes.

Comment Re:Solution (Score 1) 185

Sure, there is possibility for such a black market of reselling IPv4 address space to happen, but I don't think it will happen (at least not much).
It is not even expected that people will be giving back their pools of IPv4 addresses, much less that anything depends on it at this time. In fact it may even be counterproductive on wasting time to return IPv4 pools by now.

IPv6 is going to be more and more present and value of IPv4 lower and lower. And even people with IPv6-only would probably have means to access IPv4-only networks, with their ISPs (or other third parties) providing IPv4 connectivity via NAT64, DS-Lite and other solutions (so they wouldn't be likely to shell out big bucks for IPv4 VPNs on black market)

Comment Re:We want NAT-PT! (Score 1) 185

NAT-PT was obsoleted due to quite a few problems, see http://tools.ietf.org/html/rfc4966

Anyway, you would still need support for both IPv6 and NAT-PT on router appliance (and if you have working IPv6 on it, you can run dual stack quite easily on most OSs and many devices already). And NAT-PT was only intended as temporary IPv4 to IPV6 transition mechanism, not as "solution" anyway. So you'd have to do transition sooner or later anyway.

However, if you insist on leaving local network on IPv4 (which will actually make your problems worse as time goes by, but whatever, your choice) you can implement 4to6 (see http://tools.ietf.org/html/rfc2473) instead of NAT-PT.

But I really would recommend some other transition method - either classic Dual stack, or perhaps DSlite or NAT64+DNS64.

Comment Re:I Want to have a multicast address (Score 2) 185

See http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
224/8 to 239/8 are actually used for multicast. We use them in our company for example (makes for *great* bandwidth saver for media streamings and stuff)
240/8 to 255/8 (so called E-classes in old days) however were "reserved for future use".

The problem with reusing them is exactly what you state -- way too many firewalls and routers around the world drops those, and so they are effectively unusable for global (Internet) routing - you would need to fix the whole world before you could safely use them (who'd want IPv4 adresses that won't work on 99% of the Internet?), and apparently fixing the whole world is much much more complicated than just deploying IPv6.

Comment Re:Call me retro (Score 1) 164

Then there's the boneheaded idea of making 127.0.0.1 the "localhost" network, instead of something otherwise unusable like 255.255.255.254, or at least the high end of the smallest class C net (223.0.0.1). Also, who needs 256 private class C subnets (192.168/16), in addition to 16 class B (172.16/12) and a class A (10/8)? That could have been pared back some. And why does AutoIP need to use 169.254/16 instead of the, say, 240.0/16 region?

While those are tehnically correct, they are irrelevant really. Watch http://www.ipv4depletion.com/?page_id=326, current rate of burning IPv4 address space is about 1.5 /8 (called "A-class" in good ol' pre-CIDR days) per month. So even if they didn't reserve even *single IP* for 127.0.0.1, nor for private class A,B,C nor /16 for AutoIP; you'd still only extend the IPv4 deadline for what, less than two months?

Even if none of the E-classes (240-255 /8) were reserved, you would get less than additional year (you can play nice what-if IPv4 endgame results with the tool at http://www.ipv4depletion.com/?page_id=77 )

And given that the industry quite cheerfully ignored IPv6 for more than a decade, I think that one can say with surety that just one threatening anonymous call to, say, cisco CEO would've helped waaaay more :-)

Comment Re:Call me retro (Score 1) 164

In all seriousness, I don't know how they're going to deal with people with legacy devices, which may not be upgradable to IPv6 compatible.

Yes, that is exactly why there was a (completely ignored, of course) warning about 7 years ago that is last moment to start implementing IPv6 in devices, so that when 2010 came, all legacy IPv4-only devices would be dead.

But did they listen? Noooo... But that is not the end of the world. People will just buy more new IPv6 enabled equipment than they would normally and throw away their old stuff (we all love this consumerist society, yes?), and we'll be running IPv4+IPv6 for some time before IPv4-only sites start to become unreachable without hacks anyway.

But due to ignoring the problem for the last decade, there *will* be some pain and expenses which could've easily been avoided. For example, if companies started demanding 8 years ago that all new routers/etc they buy must be IPv6 enabled, all their old stuff would be replaced by now with no additional expense. As they didn't, they'll have to shell out some extra monies and upgrade their hardware much sooner than their useful life is over.

Maybe that will teach companies to listen to techies in the future (yeah, right)

Comment Re:Call me retro (Score 1) 164

It's unlikely that we ever will run out of IPv6 addresses as there's enough addresses to give each person living on Earth roughly 5×10^28 addresses. Which is quite likely going to be enough for anybody that could possibly follow in the future. So, it's technically possible, but for reasons related to the speed of light, physical size of the Earth and solar system it would be very difficult to ever get to the point where you need an IPv7.

You seem to grossly underestimate the power of human stupidity.

Here is a just a hint of one of the possible millions things that might go wrong:

(time:current) in IPv4, many web sites want to have redundancy and be multihomed. For that, they get AS number, their provider independent IPv4 block and then they BGP peer with (at least) two ISPs. However, a catch: due to routing table sizes, many routers won't accept BGP prefixes less than /24, which makes a web site which would be content with /30 request /24 (or it's multihoming redundancy won't work most of the time). So we're wasting 6 bits here, or over 18% of IPv4 address space.

(time: near future) in IPv6, many web sites still have redundancy and so be multihomed. While there are some other ideas, none of them are currently really working or deployed, except the PI & BGP, same as in IPv4. And while it is intended for most companies to get /48 in IPv6, BGP routers still have same problem, or even worse - multiplied by size of routes. So they'd probably do in IPv6 what they've did in IPv4 - only accept BGP routes of at least /32. Which makes every SME wanting at least /32... Net result?
While some small company might need much less than /64, they're now grabbing /32. 32bits wasted in a blink of and eye. And it wouldn't stop there probably...

Problem is, BGP doesn't scale. It haven't with IPv4, and it will get worse with IPv6 when in catches on.
But it is familiar and it works, so people will go with that by inertia.

There were attempts at fixing it. For example, SCTP allows many-to-many bindings, so if HTTP would be modified to use SCTP instead of TCP, web server could have one IP from one ISP, other IP from other ISP, and SCTP would take care of redundancy. And there would be no specific routes to be kept for web site on routers, so it would be O(1) no matter how many multihomed web sites you had.

But you would first have to convert whole of the Internet (or at least stuff like WWW, IMAP, SMTP, ...) to use SCTP instead of TCP all over the world. FAIL.

There is an easier way. Let's say we modify the web browser behavior if the site it accesses has multiple A/AAAA record. It would try to connect to one of the IPs, but if the 3-way TCP handshake did not complete in some predefined time (say 2 seconds?) it would initiate connection to all the other IP(s) and pick one that was fastest (RSTing all others), and remember that decision for some time (say 15 minutes? Or an hour?)

That way, if everything worked, the behavior would be same as the current one.
For sites with only one A record, the behavior would always be same to the current one.

However, if site had multiple A/AAAA records, and if one IP failed (timeouted), there would be a one-time small burst of several (depending on the number of DNS records) connection attempts, the user would experience one-time-only 2 seconds delay, and then the working address would be cached in browser and it would work automagically. same as SCTP, but much easier to implement, and it is much easier to implement gradually (which is the only way, really)

Comment Re:ISP-supplied modems/routers IPV6 compatible? (Score 1) 164

Google doesn't: they want only those with non broken IPv6 networks to use it (probably in order not to get involved with a lots of bogus IPv6 problems from newbies who heard IPv6 is all the rage nowdays and now it is "no work"). So you have to opt-in, have network in good condition and have your users aware of the fact and allowing them to opt-out.

Then again, one might just use Hurricane Electric public DNS recursor 2001:470:20::2 which does provide google AAAA to anyone who asks for it (not just tunnelbroker.net tunnel users)

Comment Re:carrot and stick (Score 1) 164

It's actually much much worse than that--GUI apps (though not command line apps) will almost always ignore AAAA records if the host has a CNAME record,

Huh, what are you talking about here? If I recall RFC1034, if CNAME record is present, no other data should be present (check section 3.6.2).

All the main Google and Youtube servers become inaccessible in Safari and Firefox (my DNS provider has Google's AAAA records so that's not the issue), along with roughly 2/3s of the IPv6 web servers and 1/2 of the download mirrors.

I just don't see it. Here, CNAME and AAAA are never mixed for google nor for youtube:

# host www.youtube.com
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 209.85.135.93
youtube-ui.l.google.com has address 209.85.135.91
youtube-ui.l.google.com has address 209.85.135.136
youtube-ui.l.google.com has address 209.85.135.190
youtube-ui.l.google.com has IPv6 address 2a00:1450:8007::be
# host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.135.104
www.l.google.com has address 209.85.135.99
www.l.google.com has address 209.85.135.147
www.l.google.com has address 209.85.135.106
www.l.google.com has address 209.85.135.105
www.l.google.com has address 209.85.135.103
www.l.google.com has IPv6 address 2a00:1450:8007::6a

so only A and AAAA are mixed.

I wouldn't know about MacOS X specific problems, though, but it doesn't seem to be related to what you are talking above.

Slashdot Top Deals

Prediction is very difficult, especially of the future. - Niels Bohr

Working...