Forgot your password?
typodupeerror

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

by MajroMax (#43045789) Attached to: Home Server On IPv6-only Internet Connection?

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

by MajroMax (#42753545) Attached to: Microsoft Embraces Git For Development Tools

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

by MajroMax (#42753495) Attached to: Microsoft Embraces Git For Development Tools

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

by MajroMax (#42753371) Attached to: 150 Copyright Notices For Mega

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

by MajroMax (#42726193) Attached to: WTO Approves Suspension of US Copyright in Antigua
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

by MajroMax (#42609073) Attached to: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
... 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

by MajroMax (#42609025) Attached to: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

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

by MajroMax (#42608953) Attached to: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

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

by MajroMax (#42606657) Attached to: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

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

by MajroMax (#42558209) Attached to: Symbian Sells Millions, Despite Nokia Pushing Windows Phone

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

by MajroMax (#42479925) Attached to: Worldwide IPv6 Adoption: Where Do We Stand Today?

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

by MajroMax (#42479819) Attached to: Worldwide IPv6 Adoption: Where Do We Stand Today?

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

by MajroMax (#42479697) Attached to: Worldwide IPv6 Adoption: Where Do We Stand Today?

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.

Comment: Re:More maths (Score 1) 328

by MajroMax (#42288647) Attached to: Is It Worth Investing In a High-Efficiency Power Supply?

shared university general purpose math servers, and the like.

Not even then. I've accidentally killed computing nodes before by overloading system memory with job submission. Technically the system doesn't die, but swap-storms made it so unresponsive that the sysop had to get to the physical console to reboot.

Old programmers never die, they just become managers.

Working...