Slashdot Mirror
Search
Search the archive with full-text matching across story titles, bodies,
and comments. Phrases are quoted; or, -word,
and parentheses behave as in a web search. Queries must be at least
3 characters.
Search the archive with full-text matching across story titles, bodies,
and comments. Phrases are quoted; or, -word,
and parentheses behave as in a web search. Queries must be at least
3 characters.
The other option is to install a client-server VPN package such as Infoexpress. With this, each windows client runs a simple program that automatically connects to the server to establish the appropriate tunnel. Although Infoexpress is commercial, it is very versatile and robust. It's definitely worth of consideration.
Actually, the recommended minimum subnet to allocate for ipv6 is /64 ..
And yes, that does mean you can host the whole internet on your next LAN. Several times.
To be exact, you'd have 18,446,744,073,709,551,616 adresses. (ref http://www.bind.com/?path=netmasks6 )
From http://en.wikipedia.org/wiki/Subnetwork#IPv6_subnetting
An RFC 4291 compliant subnet always uses IPv6 addresses with 64 bits for the host portion. It therefore has a /64 routing prefix (128â'64 = the 64 most-significant bits). Although it is technically possible to use smaller subnets, they are impractical for local area networks networks based on Ethernet technology, because 64 bits are required for stateless address auto configuration. The Internet Engineering Task Force recommends to use /64 subnets even for point-to-point links, which consists of only the two hosts.
Yes, but... if you can think of the internet as a hierarchical tree instead of a web. People think of it as peer-to-peer like a web. But it is really subnet-backbone-subnet, both physically, and logically (DNS). All ISPs have to physically feed into a higher level link until you reach the tier-1 providers which put it on the backbone. Then the tier-1s have to resolve at the 13 root name servers to know where to send it. At each level of the tree, each subnet gets gate-wayed/routed to the higher (or lower) layer. Each level of subnet should have discrete sets of blocks of ICANN assigned numbers right down to the neigborhood dsl-exchange.
So, ICANN could, at least theoretically, make "being connected" conditional on a provision that would flow from tier-1 down to the neighborhood ISP -- "you only resolve and forward out-ward traffic if its origin headers match the assigned block(s) of the origin subnet(s)". If a subnet starts spewing spoofed packets, the next higher tier (up to tier-1) disconnects them until they agree to fix (or filter) the problem. ICANN then rides herd on tier-1 to keep it enforced.
It should be up to users to protect themselves, or it should be an OPT-IN value-added service provided by the ISP, even if it costs extra.
I pay for bandwidth, plain and simple. I want every port open for whatever use I so desire, with no blockage from the ISP period.
Some morons at certain ISPs recently decided to block all pings, period, on their broadband networks. I run a small computer consulting business, one of my specialties is ipsec-connected subnet-to-subnet VPNs for small businesses with dynamic IP broadband connections. The scripts that make all this work depend(ed) on being able to ping various places to determine if the internet was up, if the peer host was up, and if the tunnel was up.
Since someone didn't RTFM on stateful packet filtering, and figure out how to safely allow ping traffic while blocking DDOS attacks, all my scripts broke (well, among those home users using those certain ISPs that connected into the office). Who in the seven hells ever thought an ISP would block ping!!! I can see a popular website doing it, but an ISP?!? Across their entire network?!?!? Baka!
Anyway, I had to quickly rewrite the scripts to pull entire webpages down to test connectivity, and dump them into the bit bucket, instead of nice, tiny little ping packets. (Let's see 'em block http) Wastes bandwidth, and less elegant too! wheee!
Cookie-cutter broadband ISPs without the technical knowledge to properly configure their routers are NOT people who I want determining what ports/protocols I can and can't use. I pay for bandwidth. Leave my ports alone!
Why would the demise of @Home (essentially only the content aspect of the service) have anything to do with ATT's port filtering? Anyway, the port filtering is done subnet-by-subnet. I definitely have ports 21,22,25,80, and 110 available incoming, so YMMV as it has previously.
Note that the quad boundary only matters if you are using subnets in octet size; the Ciscos don't like any subnet with a subnet address of zero. For example:
Suppose your ISP assigns you a chunk of 256 routable IP addresses, say 123.45.67.0/24. You decide you want to split this among four offices using private T1s between your Cisco routers. You break them up this way:But the Ciscos in their default configuration will choke on this; they don't like the top one because its subnet address is all zeros (or, IIRC, the bottom one because it is all ones). The especially ridiculous case is if you try to split the net in half (e.g., 123.45.67.0/25) in that case my recollection is that it won't allow use of either subnet. In this case, the "ip subnet-zero" instruction is vital.
Caveat: It's been a few years since I had to beat a Cisco into submission. But a quick search on the net suggests that things are still the same.
The issue is that YouTube (GOOGLE) directs you to a specific CDN based entirely on the location of the name server you are using rather than your actual location. This means that even if your ISP has a nice YouTube (GOOGLE) CDN that can deliver terabits of YouTube video per second, it wont use it if your name server is one of the public ones located on another leg of the internet (such as GOOGLES public name servers.
Not true. https://developers.google.com/speed/public-dns/faq#cdn. Most site's nameservers that serve geo-sensitive results (including Youtube's) respect the edns-client-subnet information that most public DNS resolvers send, including Google's Public DNS. That means that regardless of where the public nameserver is located, it'll fetch the appropriate results from the authority as if it was on your network.
If other sites work at full speed, it's possible that your ISP's peering with Google is the bottleneck, not the last mile. It would be tricky to get much visibility into that though.
There's no global ip-to-email or ip-to-person db. But there is a subnet-to-isp db, generally associated with an abuse@isp address. No information need pass from the ISP back to whatever authorities, but information most definitely should be flowing from the authorities to the ISPs which should take action.
Large-subnet fingerprint scanners and scripted exploits mean there's no safety in numbers.
Google and OpenDNS implemented edns-client-subnet feature. This solves the CDN issues that they had earlier, most CDNs including akamai support this feature. So i see no issues using google dNS or OpenDNS with netflix.
That is correct. That is why the Google DNS servers add your IP subnet (roughly) to the request they send to the authoritative DNS servers. See for example Which CDNs support edns-client-subnet? on CDN Planet for more information.
I commented on the reddit thread in the same vein as you and got downvoted. So I did some research. Several contributors to that thread suggest that Google DNS has solved the CDN problem by adding and original IP field that the CDN can use to geolocate the subscriber. This is due to Google implementing edns-client-subnet EDNS0 extensions as of late-2011.
It's actually premised on customers geting /56 prefixes (or shorter prefixes for networks that request them) except when there is reasonable reason to believe a single subnet is sufficient.
Cellular IP terminations are recommended to have /64 prefixes, which can't normally be subnetted, but still allow the assigned link address to be used to provision a single subnet (one link segment or more if weird in subnet but off link rules are used in neighbor discovery). Therefore you can use the /64 prefix from your mobile operator to tether notebooks and what have you to your phone, but you can't use it to provide internet connectivity to a multi-subnet organisation, and you don't want to do that anyway (in the rare case that was necessary you probably have some special arrangement with the cellular network operator).
I don't know what this weird nonsense about tethering is in the US. I don't know of a single network in NZ that doesn't allow tethering, you have to pay for the data, so why would they care HOW you use it. The alternative to issuing a /64 is issuing a /128 host address, and that is very inconvenient from the network operators point of view, and against IETF and RIPE guidelines, so they are not likely to do that.
I've been thinking about the saying "A poor workman blames his tools" a lot lately.
My conclusion after a lot of thinking is that it isn't that the workman who doesn't like his tools isn't skilled, or doesn't take care of his tools Maybe his set of tools is just worn out and it's the workman's duty to acquire a new tool set. The tools change over time.
I'm a SQL Server DBA. SQL Server as a product is great. The tools, however, suck. Random crashes. Random issues. Inconsistent UI. Example 1: Mouse wheel doesn't work in a combo box. Why? Who decided that was "OK"? Lots of other piddly issues that just tick me off all day long. I hate my tools. It's probably time to try something else. This really came to roost when we put Windows Server 2012 on a box so we could do cross-subnet clustering. Love the cross-subnet clustering. The UI, however, is Metro. "Go hover over an invisible spot on the upper-right-hand corner of the UI to get to something sorta-like a start menu so you can run SQL Server Configuration Manager". Why? Why?
The user interfaces, now "improved" through the use of Visual Studio integration, are absolute crap.
I'm getting tired of being stressed on poor tools when I'm stressed on a ton of other things that actually I should be stressed on, like data integrity, performance, and efficiency. Instead I get to spend a ton of time figuring out how to start applications? Every single day I start working and I find something new that makes me go "Why do these guys think they can make good user interfaces that work consistently? Who allows them to do this?"
I have had a "FreeWiFiGetItHere" SSID broadcasting my open wireless network for years. It has no upstream connectivity though, and all traffic is redirected to a subnet-local website that only serves up "The Goat" jpg. I am much pleased to be part of this ultimate vision.
The unique part about his equipment is that it's actually working like it's supposed to. The all-zeros address is the subnet-router anycast address, and if you attempt to talk to it, you should receive a reply from one of the routers on the subnet.
Linux implements this. If forwarding is enabled for an interface, then it will respond to traffic to the all-zeros address on any subnets on that interface.
(I'm not quite sure what happens for internal traffic if you have multiple routers on a single subnet. Maybe you'll end up sending packets to whichever one responds to NDP first? It's not an issue for traffic from outside the subnet, since that will just naturally hit one of the routers, which will handle the response.)
It wasn't at all clear to me from your question what you expected .here to be for... your comparison to E911 made me think you were talking about regional resources, i.e. stuff within tens of miles, and it was really unclear to me how that would be useful, much less how it could be defined or implemented. But the analogy with RFC 1918 makes it much clearer... you're talking about subnet-local resources.
That's really easy to build on top of IPv6, and you don't need a new .TLD to do it. Just define some canonical link local addresses. For example this draft RFC suggests defining fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 and fec0:000:0000:ffff::3 as canonical local DNS servers. I think the current plans are to handle local DNS differently, with local multicast addresses, but you get the idea. With such a large address space it's easy to carve out bits of it that have specific canonical purposes. So there could be a fixed address for any sort of defined local resources, e.g. print servers. In addition, it would be a simple matter to pick an address for a "local resource registry". Hosts that provide specific services could contact this address to register their services and hosts that desire specific services could contact it to get a list of what's available.
For identifying nearby hosts with names, the .local TLD already exists. Given a canonical way for hosts to reach a local DNS server, they should automatically register themselves whenever they join a network, so <yourhostname>.local can always be used to reach your machine. If in addition to that hosts registered their willingness to be advertised through a local resource registry it would be easy to discover the existence of a host and then resolve it through DNS. Many sites would probably configure their DNS resolvers to use ".local" as a default domain so in practice you'd really only need to type the hostname.
IPv6 opens up a wealth of opportunities to create far better solutions to these problems than we ever had with IPv4.
Do you see a use for subnet-independent multicast? By this I mean: instead of one address, the packet has a list of addresses and is only duplicated when routing requires. It seems to me this could drastically reduce the bandwidth needs in cases like broadcast video streaming.
Streaming has a lot of downsides for me. Its really bad at fast-forward / rewind. It does not support subtitles. Extra DVD features are not present. So I like DVDs better. That said, they could get around some of these issues by caching the content at my house. If I put movies into my streaming queue, the content should begin downloading to my home right then, and not wait until I want to watch it. Sort of like a dvr with remote PUSH capability. Also if I an my neighbour add the same movie, then we should be able to help each others caching. And your netflix devices should just grab local cached data instead of streaming it from the internet. Doing it this way, the downloads could be done slowly, some could be done at night in off hours. And same-subnet boxes could scatter-gather the content to be even more efficient. The local cache would make the FF/RW perform much better. And extra features could be added as extra chapters that you can skip to.
An IPv6 address is much more difficult to read.... Not only did they (needlessly) do away with the . separator, making it intrinsically incompatible (and more difficult to read), they made decimal representation of an address difficult.
Seriously? IPv6 addresses are no more "intrinsically incompatible" with IPv4 address than any address with more than 32 bits must be. Strings of hex digits separated by colons are no more difficult to read than strings of decimal digits separated by periods. There is absolutely no need to represent addresses in decimal, which is harder to work with for bit-oriented protocols anyway.
Nevermind netmasks and broadcast.
Netmasks in IPv6 are identical to netmasks in IPv4: "192.168.0.0/16" vs. "aaaa:bbbb:cccc::/48". There are more bits involved, but the format is the same. There are no subnet-specific IPv6 broadcast addresses; a reserved multicast address is used instead (ff02::1, similar to 224.0.0.1 in IPv4).
Quick: which subnet is 3ffe:0501:9999:ffff:: in?
The subnet is 3ffe:0501:9999:ffff::/64, of course. IPv6 subnets are always 64 bits, with the remaining 64 bits reserved for autoconfiguration.
Quick: which subnet is 10.133.180.131 in? 10.0.0.0/8? 10.133.180.0/21? 10.133.180.128/30?