Become a fan of Slashdot on Facebook


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Re:You can always get to IPV6 on the out (Score 1) 164

There's a small privacy aspect present since that other server sees your source and destination trying to start a connection, but all the real traffic is direct, peer-to-peer.

That's not the case. Unfortunately, Teredo requires relay of all data in the tunnel. There's simply no guarantee that an IPv4-only host has a direct, peer-to-peer path to and from an IPv6-only host, as is the case here in the original question.

Teredo will probably work as a proof-of-concept, but for anything requiring more than a trickle of bandwidth a dedicated tunnel (Hurricane Electric or Sixxs) would be a better idea.

Comment Re:GPL Breaks this process. (Score 1) 227

Any derived work of something, like git, which is GPLed, must be GPLed. That means that if you fork, the main branch, the main branch is free to use your extensions. This makes it difficult for replacement to work.

I think that neither the on-disk nor wire protocols of git have special copyright protection. If it so chose, Microsoft could develop a fully closed-source git implementation from scratch that is "fully compatible" with, say, git1.8 but has proprietary Windows extensions.

Comment Re:1st step. (Score 1) 227

Afaict git has no good system for answering these questions. Reflog can give you this information but afaict it can only be used if you have direct shell access to the main repository and only if the relavent entries haven't been expired from the reflog.

Set up a central, "authoritative" git server for a project that rejects all non-fastforward pushes, and you have exactly the same guarantees. In the meantime, local developers who don't need monotonic history can use the full features of git, and the restrictions can also be relaxed if necessary. For example, a dedicated (trusted) project maintainer could be permitted to make non-ff merges, so development-branch history can still be retained in the central repository.

Subversion doesn't break these guarantees, but that's because it's not powerful enough to do so.

Comment Re:Hmm... (Score 1) 199

Ok, lets infringe a bit of copyrights from around the world... think in the number pi. There, you have it, inside it probably are encrypted all the past, present and future movies, books, songs, images, genes, or whatever could be ever copyrighted in the most stupid copyright system of the history. Also you have the text of all national security documents, the passwords of all the servers and personal computers of the world, all the pins from all credit cards and detailed instructions on how to build any weapon, to name just a few things.

So, as you have all that information (no matter if you can actually access to it or not), you get sued.

Oh, the dictionary argument: since the dictionary contains all English words, no composition using strictly dictionary words should be copyrightable. Eh, eh? *wink wink*

It's bull.

When you have "the text of all national security documents" et cetera inside pi, it's all useless unless you have a key to actually specify and find the information you're looking for. By uniquely specifying a position and length within the digits of pi, you've just defined an encoding.

You're precisely one step beyond "it can't be a movie, it's just a string of ones and zeroes!" It's juvenile and unoriginal.

Comment Re:RIAA maths (Score 1) 225

Speaking seriously, it's unlikely that the math here involves the same kind of statutory damages that arise from copyright violations in the US. Statutory damages are the result of the $500/share/song fees, and those are allowed specifically by law as a penalty. Since this set of copyright-suspensions is fully legal, US law would doubly-not-apply on the matter. At best, this might be calculated based on retail price.

Comment Re:IP v6 was not well thought out. (Score 1) 445

... in what fantasy world would this have worked? Upgrading the IP version number by itself is an incompatible change, and any address-space extension means that a stateless, 1:1 address mapping is impossible. Once a stateless mapping is impossible, we're right back to the current mess of transition, since new-IP hosts would not be able to talk to old-IP hosts without an intermediary.

Comment Re:Carrier Grade NAT.... (Score 1) 445

Carrier Grade NAT refers to an implementation of NAT444. What distinguishes this implementation is that the customer is given an IP address (or several) from within a private or shared range managed by the ISP, which is itself address-translated to a small pool of public addresses.

Hence, a customer's home network (IPv4) is translated to a provider's private network (IPv4) and again to the public Internet at large (on IPv4): NAT444.

Algorithmically it's the same network address translation you do at home, but if you were to stack two NAT-routers on top of each other to build a double-NAT at home you'd be a damn fool. When the provider does it, it gets a fancy name.

Comment Re:My Rant.... (Score 1) 445

And even worse, there's no way for either end to tell - unlike IPv4 where if your local IP is in the reserved range, you can pretty much assume NAT, with IPv6, you can get a route check and get a valid IP for the 'net (the machine will also have a link-local and maybe a reserved address as well, hence doing a route-check and figuring out which IP you will be using), and not realize that you still can't communicate.

If, if business or network requirements mandate the use of NAT66 for reasons that can't be worked-around with other, more sensible approaches, then local hosts should exclusively use addresses from the Unique Local Address space. It's like private IPv4 addresses, only with near-zero chance of collision if different domains interact (like VPNs, organization mergers, or leaking of private addresses onto public spaces). A host with (seeming) internet connectivity that has an address in a ULA range must obviously be behind address translation.

Besides, what really breaks devices isn't NAT so much as many-to-one NAT. If (again, for some bizarre reason) an organization chooses to implement NAT66, then they should be using many-to-many NAT, where each internal host still maps to a unique -- but not predictable -- public address. If the public address is rotated every few minutes/hours for new connections (like already happens with stateless autoconfiguration + privacy extensions), then it will be impossible for an attacker to track hosts over the long-term.

Comment Re:Not "instead of", but "in addition to" (Score 1) 445

I never really understood why we didn't just map all the IPv4 addresses to a IPv6 subset and provide a very simple rule to translate, say by adding all zeros or some other number to the IPv4 address to get its IPv6 one.

We can do that; for legacy reasons IPv4 addresses can be embedded perfectly in the IPv6 space. However, there's no way to do so and ensure compatibility, because an IPv4-only application will simply be unable to handle IPv6 addresses. For IPv4-only applications (on either endpoint) to work on an IPv6 connection, some device in between has to translate the network addresses, or some anagram thereof.

From the perspective of the IPv6-end of things, this is a solvable problem. NAT64 effectively allows a router to proxy the entire IPv4-space, allowing a 6-only host to more-or-less transparently deal with IPv4-only hosts. DNS64 also proxies the DNS records to construct suitable (NAT64-based) addresses for hosts with only A (IPv4) DNS records.

The problem of IPv6 adoption is a classic chicken-and-egg. The differing address lengths mean that compatibility for IPv4-hosts must be broken; the pigenhole principle means that there literally cannot be a stateless mapping between IPv4 addresses and IPv6 addresses, even ignoring the traditional NAT problems of addresses-in-protocols. Some kind of translation intermediate will be necessary until we can finally turn off the IPv4 lights.

Comment Re:Astroturfing (Score 1) 218

Those numbers are a bit out of date. The current Wikipedia page has an updated bar graph; in the most recent quarter listed (Jul-Sept 2012), the iPhone sold 26.9 million units.

If we're to assume that Nokia's goal is to sell a dominant phone platform, rather than a very niche product, these reported sales figures are underwhelming.

Comment Re:That's easy. (Score 4, Interesting) 327

ISPs don't want to do carrier-grade NAT, because then they have to maintain carrier-grade NAT.

CGN is a stateful protocol, meaning that each of their implementing-boxes needs to maintain and process state for each data flow to or from your devices. That's no big deal for a single home, but it's a problem for a carrier. If the boxes are too far towards the customer-end of their network, they will be small but they will also be numerous, making maintenance more frequent. If the boxes are too far towards the core of their network, an ISP will only need a few, but the hardware requirements are much heftier to provide acceptable performance. (Already, bittorrent can saturate some of the cheaper home routers).

Simply routing packets is technically far, far easier than running network address translation. Even ISPs that use deep-packet inspection have the option of turning it off if things go wrong -- the network fails open. Carrier grade NAT doesn't have that option.

Comment Re:IP6 addresses are a pain (Score 1) 327

If DNS/DHCP is so difficult, then you can do exactly the same address assignment with ipv6 that you do with ipv4: give out a static /64 to each group-of-VMs, and let the testers/devs themselves pick individual machine numbers from that prefix.

If you want to be really short, then generate an unique local prefix (/48) for your test networks, and subdivide from there according to whatever scheme you want, like fd8a:db80:db80:building:floor::[machine]

Comment Re:That's easy. (Score 4, Insightful) 327

That won't work in the long-term. The problem with carrier-grade NAT is that the ISPs have to... maintain carrier-grade NAT.

Network Address Translation is a stateful protocol, and it's orders of magnitude more expensive to maintain connection tracking on a per-connection basis for your customers than it is to simply route packets between networks. Even ISPs that use Deep Packet Inspection have the luxury of looking at selected traffic flows; carrier-grade NAT has to cover everything or it doesn't work.

"Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right', and 'build car'." --John Sladek