Slashdot Mirror

Every website and their mother was moving to XHTML, the XHTML debacle is that Internet Explorer wouldn't support the application/xhtml+xml media type. That's it. It's perfectly fine to use XHTML now that IE6 is no longer a thing.

And no, their fork is not authoritative, it's only defined for Web browsers, it lacks features required for Internet media types in general, the IETF assigned authority for HTML to the W3C in RFC2854, and the IANA still registers text/html as maintained by the W3C. https://www.iana.org/assignmen...

Permanent DST sucks for Spain in the winter.

Agreed. Permanent DST makes no sense.

I always thought Spain would be in WET ? Maybe it's just is in the wrong time zone ? Why not take the opportunity and fix that too by switching from CET to WET and enjoy noon at midday ?

Btw: I just recently had the pleasure to try to fit the tzdata file into an embedded system with 1MB flash. I nearly went crazy sifting through the data. We couldn't do it anyway and had to settle for a compromise.

Every person that has to do with software has to encourage any attempt to get rid of DST switching. Look into the source files at https://www.iana.org/time-zone... and bee blown away. :-)

It is unassigned, asshat. https://www.iana.org/assignmen...

Don't be a doofus. It is unassigned. https://www.iana.org/assignmen...

So now we have DNS servers on 1.1.1.1, 4.4.4.4, and 8.8.8.8. Who has 2.2.2.2 and can they put a DNS server on it?

https://www.iana.org/assignmen...

2/8 is allocated to RIPE (Europe) by IANA in 2009
Whois shows 2.2.0.0/16 as France Telecom Orange

1/8 is allocated to APNIC (Asia Pacific) by IANA in 2010
4/8 and 8/8 is allocated to Level 3 (one of the larger backbones) in 1992

As to if they can put a DNS server on that address, technically speaking of course they can, the real question is who "they" might actually be. It may be in a block allocated to a customer.

Nah, it will just be another footnote in The TZ Database, similar to the existing notes and commentary about timezone changes resulting from wars, dictatorial decrees, and bureaucracy from Human history across the globe. It's a really interesting read if you have a weekend to sift through it, or many months to try to implement a library to handle timezone translation across known history (I pity you, even with the TZ database it's not going to happen.) Incidentally, because this is a historical record the decision in the EU can only impact future timekeeping, so they actually add more work by changing anything because you still have to account for the existing rules if you want to handle any dates prior to their decision or import old data.

The IANA provide reserved names for testing to avoid this type of situation. https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

.test should be fine even if you are pedantic about naming a dev domain. There is .example and example.com/org/net as well.

so your comparisons to Google's situation fall apart right from the get-go.

The subject of the thread still lists hosters (of services) in addition to registrars. Moreover, registrars — such as Google — have an even greater responsibility. Whereas a hosting provider may choose to discontinue service to a particularly unpleasant customer, a registrar should not have such ability — certainly not without first seeing the customer's domain safely migrated elsewhere.

Speaking of IANA, it, rather than the US government, is the organization with the authority you're talking about. The USG gave it away in 1998 to ICANN

Bullshit. Whatever it is ostensibly, the governance of the Internet is still very much controlled by the US government with ICANN allowed to do its thing only as long the US is Ok with it. Many of the root DNS-servers are US-owned...

As I said earlier, the domain-registrars are very government-like in their very purpose, like Registries of Deeds, for example...

The courts have repeatedly ruled that inciting violence—which is what The Daily Stormer is accused of—is an unlawful form of speech

You aren't offering any citations — how is mere accusation of inciting violence sufficient for government to suppress speech?..

But, meanwhile, do I understand you correctly, that you'll have no problem with any and all "Antifa" sites losing their domains? They aren't merely "accused" of inciting violence, not even merely observed engaging in it, they openly admit it.

don't you dare suggest that private entities are obligated to assist them

Just as Daily Stormer agreed to Google's terms, Google have agreed to — and did for a while — host them regardless of their views, voluntarily. They did not have to take them, but they did.

Notary Publics are private too, and they aren't obligated to serve anyone in particular. But, once they notarize your signature, they can't — should not be able to — withdraw their certification on the basis of you being an asshole...

The sudden pull of the domain-registration is a scandal and a violation of the Nazis' civil rights.

Example.com is owned by IANA.

This type of example is precisely what example.com is set up for, and is defined in RFC 2606.

The root domain is signed with 2048 bit RSA keys (the root trust anchor is a 2048 bit key since 2010 and it has been using 2048 bit keys to sign zones since last year). Many/most TLDs have 2048 bit SEP and are in the process of moving to 2048 bit zone signing keys.

Browsers won't support DANE because there's a lot of influence and money to be had by being the gatekeepers to the root CA lists. They also each run their own CA, so they don't feel any pain from the CA process.

There are also .eu and .asia. Additionally, the number of TLDs has become quite big and their justification unclear. How could you restrict the access to a list including .eurovision or .firestone?

Hmm. Ford still has a legacy /8 IPv4 address block, I see. Maybe Google's first mass-market autonomous vehicle will be a Ford, eh? Or Ford's will be a Google, or whatever. Hostile takeover maybe, given the culture clash, though, so don't call your broker right away. ;-)

By the way, here is a link to the Root Zone file if you want to see what it is.

There is also is a human readable version here.

So now, you have just the global prefix space. Of this, the first 2 bytes are assigned by the IANA to the RIR - the 2001, the 2400.... It's not a part of what your RIR gets to give you.

I've been trying to work out what you mean by all this.
IANA doesn't allocate to RIRs on /16 (2 bytes) boundaries. It allocates based on whatever is appropriate. The latest allocation was a /12 to ARIN. I don't see that it has ever allocated a /16 either. (a /16 was reserved for 6to4) http://www.iana.org/assignment...

Now, depending on the geographic reach of the ISP, they may need thousands of offices nationwide, and in each office, service several thousands of people. Let us assume that we have 16 million routers serviced that way - that is 2^14. So your 32 bits are now down to 18. So it now comes down to how many people are serviced by a single central office router. Lets assume it's 128, which is 2^7, and you are down to 11.

This really doesn't make sense to me. Firstly 2^14 is around 16k, not 16 million... What are these routers that you are servicing? CPEs? In this scenario you require 16 million /48s which would fit into a /24 quite nicely.

So you are already cutting into the subnet address space of the IPv6 address, since you have only 11 bits to give a customer for subnetting. Giving everyone a /48, as you mentioned, would give each customer 16 bits of subnetting address, so you now have a deficit of 5. Which is why RIRs like APNIC and RIPE assign /56s instead. Each customer that way gets 8 bits of subnetting, instead of 16. Which may or may not be adequate.

I genuinely don't understand what you are talking about. Maybe a diagram would help? You mention an inherent structure in v6 addresses. Maybe that is where you are getting confused, because other than the 64:64 split, there is none as such...

There are people out there who want new for new's sake. They are desperately bored with their lives and demand novelty. Long-term thinking is alien as well as boring. They're going to demand the mallard duck and the avocado, cheer when they are approved, and then never use them. Next round of Unicode, they'll have more dumb ideas to include.

Coming up: Unicode 16, when the committee gets fed up with all these dumb symbols that nobody uses and purges the list.

Everyone wants to lift their leg and etch their mark on the Monolith. For example, I have my very own IANA-allocated SNMP Community Enterprise Number. It has four digits in the mid-5000s allocated some 20 years ago and since they're up to ~46,000 now that makes me an Internet alpha male. When I'm drinking at bars late at night I rehearse pickup lines in my head, you know, let's get out of here and I'll show you my private IANA SNMP CEN. Over the years it's really paid off and I'm now well rehearsed, able to deliver a pickup line should the occasion ever arise.

Some day I'll finally settle down with some other SNMP Community Enterprise Number. The circle of life goes ever on and on, down from where it began. C'mon Baby, let's go load Unicode Support. Would you like to see my avocado?

But for real excitement we could dispense with all these centralized standards committees and map ABSOLUTELY EVERYTHING into DNS-and-BIND namespace. Then we can map DNS namespace through a virtual device driver into an NTFS filesystem. Then use de-frag in Windows XP de-frag the whole damned Web and condense it into a single spherical shiny clump. Then jump back and see where it rolls.

Yeah, typing them out's a pain. I wish we could have a shorthand format like "~::2" which took the first N bits from your current network prefix. But I almost never type v6 addresses; it's usually DNS, or then copy/paste if I really am dealing with IPs for some reason. For that matter, I don't even know the v4 addresses for most of my machines -- I could give you the subnet, but I have no idea which IPs are which.

For what it's worth, v6 assignments currently start with 2001 or 2{4,6,8,a,c}0*, which is pretty similar to the well-known RFC1918 ranges. And you'll see your own prefix often enough to remember it, hex or no hex.

There is already a check of the file type, by the application and by the shell (for native executables). So, I don't see any problems. Why shouldn't the system being exempt from counting a file type look-up as a use? The Linux file utility and the libmagic library can already detect thousands of different file types, and servers already make the check for the MIME type of a file for security reasons. The focus should be on security not on simplicity.

http://en.wikipedia.org/wiki/F...
https://github.com/threatstack...
http://www.iana.org/assignment...

https://www.iana.org/domains/r... served from the authoritative DNS root servers http://www.root-servers.org/

APK

P.S.=> For anyone that's interested in the specifics here... apk

And yet somehow, there is always a key - some centralized process somewhere that is the Achilles' heel.

And this is why there are hundreds of root DNS servers with over a dozen "names" (list).

TOR has (or had) "directory servers." Although it was discarded as not being practical, TOR or its predecessors considered using fully-distributed directory information (see 2004 documentation). TOR now has the option of using bridge-nodes. The addresses of these nodes are typically distributed "out of band" (e.g. by email or personal contact) on a need-to-use basis.

In short, "centralized servers" are not a bad thing as long as there are enough of them without any significant risk of common failure (short of a catastrophic event that would take down the whole Internet or for that matter the whole planet).

It's not really analogous to zip codes because zip codes are an internal system of the post office. But authority for TLDs is farmed out to various agencies, governments, or companies, who make money off them and get to decide the rules for registering names under that TLD. See http://www.iana.org/domains/ro...

So .ir is under the authority of the Institute for Research in Fundamental Sciences (http://www.ipm.ac.ir/25/index.jsp) which is "a government-sponsored advanced research institute founded in 1989 in Tehran, Iran. The institute was the first Iranian organization to connect to the Internet. It is also the domain name registry of .ir domain names." (source: http://en.wikipedia.org/wiki/I...)

It's that authority that the plaintiffs want to take away from Iran, not the name of Iran or the letters ".ir" or whatever.

So... How is this even tangentially related to being newsworthy for a tech site?

Like, seriously, WTF?!

It's newsworthy because we finally have proof that another countries legislature is at least, just as ridiculous as our own.

Note that the quoted statement can be made in a number of different countries; if you want proof that a lot of countries fuck around with daylight savings time rules, etc., just download the tzdata files and read.

How about we give out 240/8 to 255/8 first? That range is reserved for "future addressing modes", presumably something like how 225-239/8 are reserved for multicast, but I haven't heard of any new addressing modes on the horizon.

But ignoring that for the moment... there's 126 class As (1-126; 0 and 127 are special), but only 40 of them are "legacy"; the rest are already handled by ARIN, RIPE, etc. So at 10 days each, that would handle 13 months of demand, after which, back to hosed. Not really a big win.

We need to get the ground work done so that IPv8 can be introduced smoothly

I think most people gave up on PIP already.

In addition "MS" is no more valid of an abbreviation than "M$".

Completely wrong.

* It's their vender prefix on the Internet: http://reference.sitepoint.com/css/vendorspecific. Note also that mso is called out separately as Microsoft Office.
* Until the latest IE they had MSIE for "Microsoft Internet Explorer" in their user agent string
* The Microsoft developer network is called msdn.
* Microsoft Network is abbreviated msn.
* Look at their original logo: http://www.pcgameshardware.de/Microsoft-Firma-15584/News/Microsoft-Logo-Windows-8-1020153/galerie/1984053/
* It's composed of the words Microcomputer Software
* It's in a lot of the old 8.3 exe file names, eg. msoffice.exe
* Look at all of these MIME-types that specifically have ms as the abbreviation for Microsoft: http://www.iana.org/assignments/media-types/application, http://www.iana.org/assignments/media-types/video

Using the stock ticker symbol as the "only valid abbreviation" is bizarre.

Otherwise Microsoft wants the name spelled out.

This might even be true in some senses eg. for publicity (I can't find anything to specifically confirm or deny that in a quick search), but it definitely wasn't always true and they're still generating new things with MS as the abbreviation so it's at best inconsistent.

Trying over and over and over to tell people they are "childish" just makes you look childish.

How so? I don't see it. And obviously since you're telling him he looks childish, you therefore look childish for telling him that (and by extension, I'm being childish now by pointing that out).

If it's "childish" then it will stand on it's own that way

People like you posting this sort of knee-jerk response every single time somebody says M$ just looks like desperation.

I don't even understand. Desperation? I literally don't know what you're trying to communicate there -- I know it's negative, but I don't know what negative thing.

There are a lot of childish nicknames that go around for things people don't like: M$, Faux News, Obummer, Mittens (for Mitt Romney), Rethuglicans, Demoncrats, Scroogled, Crapple, and on and on and on. Even when I'm on somebody's "side" in a particular argument, it makes me discount them (for instance, I'm unlikely to be on the side of Republicans on many debates, but "Rethuglicans" is just crass).

I'm pretty sure Microsoft themselves aren't all that pleased with South Korea's ActiveX install base. If you follow the browser at all, they've been trying to kill ActiveX more and more for the past half decade or so (with Flash as a very notable exception).

In addition "MS" is no more valid of an abbreviation than "M$".

Completely wrong.

* It's their vender prefix on the Internet: http://reference.sitepoint.com/css/vendorspecific. Note also that mso is called out separately as Microsoft Office.
* Until the latest IE they had MSIE for "Microsoft Internet Explorer" in their user agent string
* The Microsoft developer network is called msdn.
* Microsoft Network is abbreviated msn.
* Look at their original logo: http://www.pcgameshardware.de/Microsoft-Firma-15584/News/Microsoft-Logo-Windows-8-1020153/galerie/1984053/
* It's composed of the words Microcomputer Software
* It's in a lot of the old 8.3 exe file names, eg. msoffice.exe
* Look at all of these MIME-types that specifically have ms as the abbreviation for Microsoft: http://www.iana.org/assignments/media-types/application, http://www.iana.org/assignments/media-types/video

Using the stock ticker symbol as the "only valid abbreviation" is bizarre.

Otherwise Microsoft wants the name spelled out.

This might even be true in some senses eg. for publicity (I can't find anything to specifically confirm or deny that in a quick search), but it definitely wasn't always true and they're still generating new things with MS as the abbreviation so it's at best inconsistent.

Trying over and over and over to tell people they are "childish" just makes you look childish.

How so? I don't see it. And obviously since you're telling him he looks childish, you therefore look childish for telling him that (and by extension, I'm being childish now by pointing that out).

If it's "childish" then it will stand on it's own that way

People like you posting this sort of knee-jerk response every single time somebody says M$ just looks like desperation.

I don't even understand. Desperation? I literally don't know what you're trying to communicate there -- I know it's negative, but I don't know what negative thing.

There are a lot of childish nicknames that go around for things people don't like: M$, Faux News, Obummer, Mittens (for Mitt Romney), Rethuglicans, Demoncrats, Scroogled, Crapple, and on and on and on. Even when I'm on somebody's "side" in a particular argument, it makes me discount them (for instance, I'm unlikely to be on the side of Republicans on many debates, but "Rethuglicans" is just crass).

I'm pretty sure Microsoft themselves aren't all that pleased with South Korea's ActiveX install base. If you follow the browser at all, they've been trying to kill ActiveX more and more for the past half decade or so (with Flash as a very notable exception).

I bet you didn't click on the ID link describing how to fix it did you?

I did and, first of all, your link describes a proposed standard 5 years ago. I do not see that it has been accepted as a standard to IETF. Second in Eastlake's presentation he notes: "Provides weak authentication of queries and responses. Can be viewed as a weak version of TSIG. No protection against “on-path” attackers, that is, no protection against anyone who can see the plain text queries and responses"

I read that as it probably would work if adopted but it is only slightly more secure than DNS but not my much. Port randomization probably does more.

But yea major re-architecture..blah blah blah..

Well if you need a more thorough explanation you can read this much more detailed and illustrative one.: "As has been alluded to several times, it's the small space — just 16 bits — of the Query ID that makes this attack possible. Though certainly one might wish to increase that ID to something larger (perhaps 32 bits), it's simply not possible do that in the short term because it would break DNS on the internet: the fields are what they are, and they can't be changed casually.

Don't care about popularity contests or who said what.

So you don't care how the hacker who found the problem proposes to fix it. By the way, Kaminsky has never liked DNSSec but he says it's the best solution for now. He actually would prefer DNSCurve but at the time was not ready. It might eventually replace DNSSec. Who do you care about? What about IANA: "DNSSEC is the current answer to this problem. This attack provides clear incentive to deploy a solution like DNSSEC, because without security the DNS will continue to be vulnerable to cache poisoning attacks."

The transport picture and the risk it represents to the larger network is unacceptable regardless of how "secure" DNSSEC is.

In response to this attack all the root servers implemented the solution Kaminksy suggested. People who know far more about Internet security than you and me did this. Either they implemented a popular but less secure solution. Or they don't know as much as you. Or they know what they are doing.

If you are wondering why its there, look here

You only need paid support from Oracle if you want updated timezones faster than they do regular updates of the JRE (at least 4 times a year with the new Java CPU scheduling) and you can't build the timezone packaging kit previously mentioned in that blog post.

That's at the administrative level, not the technical level. At the technical level, v6 routing is the same as v4 routing.

Also your table doesn't really reflect the administrative splits that we're seeing on the internet, other than the first 3 bits and the last 64 bits. For instance, many ISPs only give a /56, /60 or /64 to end users, who have a "subnet identifier" part of the address that is 8, 4 or 0 bits long.

Or similarly, ARIN allocates /32s to LIRs, but actually reserves a /29 for them -- for instance, take the allocations around 2001:470::/32: the next 7 /32s are unallocated, and the next allocation is 2001:478::/32. The next one after that is 2001:480::/32. In this case ARIN have reserved 3 bits for expansion of the /32s -- but note that this isn't nasty routing stuff, the space is being left deliberately so as to avoid nasty routing fragmentation in the future.

There's also the IANA global unicast address assignment list, which has allocations from all over the shop.

You've got the right idea in the sense that allocations are heirarchical, but the strict bit boundaries are mostly ignored. And it's all administrative anyway; the computers doing the routing couldn't care less.

of course when converting from natural date to offset from epoch, you use a database that keeps track of the details as to what offset from UTC is used when. That said, date math is a fucking PITA even when you have all the tools at hand.

You probably ban by the first /64 of the IPv6 address which is effective

Thinking about it i'd probablly agree with you. Some ISPs give their customers more than one /64 but frankly anyone who knows how to change which /64 their lan is using probablly has other methods of ban evading available.

incidentally is also too big (current technology) to use the brute force run through the hash algorithm

Note that while the ipv6 unicast internet is nominally 2000::/3* all IPv6 addresses allocated to RIRs or other global unicast uses so-far have been from one of the following prefixes (this is a summary of http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml).

2001::/16 (early allocations)
2002::/16 (6to4)
2003::/18 (ripe)
2400::/12 (apnic)
2600::/12 (arin)
2800::/12 (lacnic)
2A00::/12 (ripe)
2C00::/12 (afrinic)

Further of those blocks allocated to RIRs afaict only a small fraction are actually used on the internet. Afaict this places the brute force problem into the category of "painful but doable".

* IPv6 Ips outside this range are allocated to various other uses including private networks and multicast http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml.

You probably ban by the first /64 of the IPv6 address which is effective

Thinking about it i'd probablly agree with you. Some ISPs give their customers more than one /64 but frankly anyone who knows how to change which /64 their lan is using probablly has other methods of ban evading available.

incidentally is also too big (current technology) to use the brute force run through the hash algorithm

Note that while the ipv6 unicast internet is nominally 2000::/3* all IPv6 addresses allocated to RIRs or other global unicast uses so-far have been from one of the following prefixes (this is a summary of http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml).

2001::/16 (early allocations)
2002::/16 (6to4)
2003::/18 (ripe)
2400::/12 (apnic)
2600::/12 (arin)
2800::/12 (lacnic)
2A00::/12 (ripe)
2C00::/12 (afrinic)

Further of those blocks allocated to RIRs afaict only a small fraction are actually used on the internet. Afaict this places the brute force problem into the category of "painful but doable".

* IPv6 Ips outside this range are allocated to various other uses including private networks and multicast http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml.

Plenty of people have noticed this before now, IANA has published a table showing all the /8 allocations pretty much since they were formed. Anything flagged as "LEGACY" was assigned before the current RIR/LIR assignment process was implemented. Someone even complied a table showing which parts of the legacy IP assignments were not routed some years back, which must have included the DWP's /8 as well unless they were actually advertising it at the time that the table was compiled.

The only thing that makes this slightly newsworthy is this about a cash strapped sovereign government sitting on a sizable pool of "spare" IPv4 space that has suddenly become a much more valuable commodity following the recent announcement that RIPE is now down to its final /8 and IPv4 allocations within Europe and those parts of Asia that fall under RIPE's remit are now heavily restricted. You can probably expect a similar story about the dozens (see the table above) of underused /8s that are held by US corporations and government agencies, the DoD especially, when ARIN's IPv4 approaches exhaustion as well.

Which reminds me, whatever happened to IPv1, IPv2 and IPv3?

They are mostly forgotten. It is possible to find the version 2 specification on the web. It does differ en some important ways. For example back then the separation between IP and TCP had not yet happened. So the specification is actually called TCP version 2. The IP and TCP fields were not as clearly separated, and the version number was not even the first field in the packet. It is a bit tricky to find out what the version number is when its location depend on the version number. That is probably also the reason it isn't officially allocated in the registry.

I predict, that if there is ever going to be a successor to IPv6, there will be a worry that the version numbers will run out. Thus it will be decided to introduce a variable length version number field to ensure that never runs out. An agreement will only be reached after a heated discussion. The problem is, that people have an aversion against variable length fields in the IP header. And that aversion people have for a good reason. It is OK to change the length of fields between version. And some people will have a hard time understanding, that this means the version field itself can be variable length without problems, because within each version it is a fixed value and thus fixed length.

Why not just use IPv9

In reality version number 9 is actually assigned to the TUBA protocol.

No, people could have public IPs starting w/ 2001, 2400, 2600 and so on, so that one doesn't guarantee uniqueness. I agree though that it's not too hard, but am surprised that nobody figured out how to guarantee something to that effect.

They went to the RIRs and were allocated accordingly. Actually, even from the above list, some of the legacy addresses were turned back to the IANA and allocated to the RIRs. Problem is that even if all of them went back to the RIRs, it still wouldn't be enough to sustain the growth of the internet.

The first part isn't really almost fixed to 2001 -- the actual RIR allocations are listed here. The RIRs have /12 blocks assigned to them, with space to expand that to a /7. They also have older /23 blocks allocated out of 2001::/16. The first part might look like it's fixed to one of a few values, but that's because the address space is big enough that the RIRs haven't needed to use those bits yet. They'll use them when they need to.

Likewise, the minimum ISP allocation is /32, but each /32 is actually taken from a /29 reservation that the ISP can grow into. ISPs that are already large get bigger allocations -- mine has a /24, with a /21 to grow into. Allocation isn't done strictly on word boundaries.

It's perfectly fine for sufficiently large companies to get allocations in the /32 range. We have a billion /32s available. That's only one per seven people, sure, but we've just said we're talking about very large companies -- they have a lot more than seven employees each. (Of course the allocation should reflect the size of the company's network; if they're too big for a /48 but too small for a /32 then they should get something inbetween. I've seen /40 and /44 allocations to universities, for instance.)

Even taking the HD-ratio into account doesn't change things that much. If you use a HD-ratio of 0.8 (which is fairly low; IPv4 was around that number in 1998-99 or so) my "5000/person" figure from before becomes something more like 10-20 /48s per person. This is a number a person can realistically manage to hit, but I still don't see everybody on the planet managing that.

Finally, we have five more unused /3s that we can do this all over again in. We could even change the allocation strategy in those /3s, if we discover that our current strategy is bad. I don't think we'll fill 2000::/3, but there's an escape plan available if we do. We could have done it using your split, but we didn't, and from the numbers I don't believe the split we did decide on is going to be problematic.

I didn't get the joke. 2600 is one of the /12 blocks assigned to ARIN. Other than that, not commenting much - not sure I understand what Nmap is in the first place.

Internet Assigned Numbers Authority.

Nothing you pasted contradicts anything I've said, your quote merely reiterates that the US administers them and has recently decided to start applying it's laws to them, this doesn't inherently mean they're not international domains though. Rather than repaste the same thing, see shutdown -p's comment here:

http://slashdot.org/comments.pl?sid=2700853&cid=39213127

You can also see the IANA's official list:

http://www.iana.org/domains/root/db/

Note how .com, .net and .org are listed as generic tlds, whilst others such as .gov and .mil which are US tlds are sponsored?

All IANA's documentation also refers to them as international and as I've said elsewhere, even the US government would likely accept they're international, the only dispute is about who administers them.

Here's the list of /8 subnet holders.... how many of these companies really need /8 address space?

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Ford? Bell Northern Research (aka Nortel)?

There's still plenty of IPs, they just are in someone's closet.

Sigh. As one of the Righthaven tools[1] found out the hard way ... the CM/ECF system used by all Federal District Courts has been tested to work with FF 3.5; from extensive personal experience it also works fine with FF 3.6. It does not work at all with FF 4.0+ (in that you can't use FF to upload PDFs, which is all you'd use the Electronic Case Filing system for (document retrieval is done through PACER, though they overlap).

For some stupid reason, ECF specifies an ACCEPT parameter of “image/*” for the PDF upload forms, which of course is incorrect (PDFs are MIME type “application/pdf” per IANA; see also, e.g., RFC 3778).

As of FF 4.0 (https://developer.mozilla.org/en/HTML/Element/input), that 'accept' parameter is honored and FF filters the file selector box to only permit image filetypes to be uploaded. End result? #massivefail

Yes, ECF is broken. But try getting not one, but 89, Federal bureaucracies to fix their tech in a timely fashion... (Each district court runs its own ECF system.)

Sigh.

[1] Declaration of Shawn A. Mangano, Esq., Righthaven LLC v. Democratic Underground, LLC, No. 10-cv-01356-RLH-GWF, docket entry 127-1 (Dist. Of Nevada, June 29, 2011)

Does current time code even have the sufficient smarts currently to handle specific countries CHANGING their TZ on a particular date?

Yes. Linux/Unix has a long history of tracking timezone changes for specific countries, states, provinces, etc. It's called the Olsen Timzone Database. It was recently taken over by IANA, and is hosted here http://www.iana.org/time-zones

They are discussing this specific issue here:
http://mm.icann.org/pipermail/tz/2011-December/008458.html

This makes me wonder. Are people going to be paid/charged interest for a non-existing 12-30-11 there?

It depends. I work for a time and attendance company as software developer, so I have some insight. Basically, this is handled just like a DST change, but for a much longer period.

Many timekeeping systems (hardware and software alike) just keep track of "local time". Some have the ability to keep a list of DST changes that need to be applied at specific times, and some use NTP or other protocols to sync their clocks and pickup timezone changes that way. While these systems handle "spring-forward" changes ok, they are usually flawed in the way they handle "fall-back". If someone clocks in or out DURING the fall-back period, there is no way to tell if they get an extra hour or not, because there is no recorded distinction between the two times that are both called the same thing. The good thing about DST is that the change usually happens in the middle of the night, which minimizes the number of manual corrections that have to be made.

The solution to all of this, of course, is recording time as UTC and converting it for proper display depending on context. Some systems out there caught on early, but really this idea is just now making its way into the market. This is where the timezone database is very valuable. Windows also has a timezone database (different than the Olsen DB), but Microsoft only pushes it out every few months (via windows update), so it is often behind in various parts of the world. Microsoft timezone info here: http://blogs.technet.com/b/dst2007

Since Samoa and Tokelau are skipping a day, this is a "spring-forward" scenario - which is very easy to calculate. It is highly unlikely that they will have issues with paying an extra day (or charging an extra day's interest), as long as they consider the change like any other DST change. I would think that this is big news there, so anyone with custom code will probably be aware of the situation and make the correction.

Of course, if you have a bank account in another country, they are going to say a big "screw you" to your request to be charged one day's less interest just because your homeland is skipping a day. :)

You're right, and I omitted that consideration from my post. (You're misunderstanding the allocations though -- APNIC have 2001:0400::/23, which is 2001:0400:0000:: through to 2001:05ff:ffff::. They also have 2400::/12, which is 2400:0000:0000:: though to 240f:ffff:ffff::. Also, if you look at the list of allocations, they've obviously been left the whole of 2400:0000:0000: up until 25ff:ffff:ffff:: to expand into. Even the smaller /23 block has room for more than 65,536 corporations, let alone the /7 reserved block.)

The allocations are being done sparsely like this in the interest of route aggregation. The idea is to issue an ISP a /32, for example, but then skip the next 7 /32s. This means that the ISP can expand right up to a /29 while continuing to take up only a single routing table entry. If you want to put a negative spin on it, you could claim that this is only "12.5% efficient", or that it "wastes 87.5% of addresses", but this is not true: the gaps are being used to minimize routing table fragmentation.

How does this affect my assessment? RFC 3194 is required reading here. It defines the "H-density ratio", as a means of measuring how painful address allocation is becoming in a network with a hierarchical structure. Even if we take the low-end 80% used in that RFC, that would still be 70 billion /48s, or 10 per person on the planet. It's reasonable to expect some people to admin more than 10 networks and thus need more than 10 /48s, but I feel that it's unreasonable to expect that to be true of every single person on the planet.

For comparison, it looks like IPv4 passed its HD ratio of 80% (51 M hosts) in about 2000 or so. Clearly a network can continue operating beyond 80% if necessary; it just means that you have to start sacrificing route aggregation for a higher allocation percentage.

(Once again, I did these calculations for the 45-bit space in 2000::/3. The "we can start over in one of the other five /3s" argument is just as valid here too.)

I think you might not have quite gotten your head around just how much bigger 2^128 is compared to 2^32.

There are 5000 /48s per person on the planet -- out of 2000::/3 alone. (Remember that a single /48 has 80 bits of addresses in it. You could take the 2^32 addresses in IPv4, copy them 2^32 times and still only use 1/65536th of the space in a /48.)

If we do somehow manage to allocate the entire of 2000::/3, there are an additional five completely unused /3 blocks available, in which we can simply start over with tighter allocation policies.

It's going to be enough.

The URL at ICANN seems to be http://www.iana.org/time-zones

But then the major distros will just cache this page instead: http://www.iana.org/domains/example/

Whereas the addressing always implied "one ipv6 for each of your devices"(almost like rfid for bluetooth devices, on the internet, all the time), they didn't figure out the firewalling ?

IPv6 has a section for private use.

FD00::/8

So the home router manufacturers could have the exact same configs as today (with IPv4) with IPv6. With all the same benefits and problems that we have today. And that people are familiar with. And familiarity is the important thing here.

Beyond that, it's just a matter of phrasing. The techs designing the home routers/firewalls know what the technology can do. The issue is phrasing that in a way that the home user can make an informed choice on what options they want to enable for which of their machines (connecting to which machines on the Internet).

Make that FC00::/7, as per the IETF definition for unique local unicast

But in IPv6, a device can have multiple IPv6 addresses from different networks (unlike in IPv4). One from the ISP, but then if the consumer happens to have his own /64, he has IPs for say his own website, cellphone, IPAD, and so on. Let's say he's trying to connect to his work VPN - he'd get an address from there as well. So he'll have a bunch of addresses, and anyone from within any of those networks should be able to access him, so long as he's online.

So if he's doing a home networking, getting private addresses here may be redundant. As for the routers, I can see them being more like site-local addresses (think of a gateway address in IPv4). So the address of a wireless router would be something like ff05::2, as a router on the site. Natting wouldn't be done here, since that would disrupt the peer to peer paradigm which is why one would want it in the first place. But these addresses are automatically assigned - you have

0 reserved
1 interface-local scope
2 link-local scope
3 reserved
4 admin-local scope
5 site-local scope
8 organization-local scope
E global scope
F reserved

and multicast groups

1 node
2 router
5 OSPF IGP router
6 OSPF IGP Designated router
9 RIP router
a EIGRP router
b mobile agent
109
d PIM router
16 MLDv2 capable router
fb DNS server
101 NTP server
108 NIS+ server
1:2 DHCPv6 relay agent or server
1:3 DHCPv6 server (but not relay agent)

As a result, one would have multicast addresses like

ff02::1 All nodes on the local link
ff05::1 All nodes in the organization
ff02::2 All routers on the local link
ff05::2 All routers in the site
ff02::fb All DNS servers on the local link
ff08::fb All DNS servers in the organization

Note that all these addresses are automatically created when an IPv6 address is created - the node doesn't have just one IP. All this alone would allow the devices to work within that local network.

Why don't you use dude@example.com or nospam@example.org? Almost no sites filter it, and there's no chance of it causing spam for anyone.

By assignment of IPs, I meant do they get the global unicast addresses, like in the 2000 range, or link-local unicast, or multicast addresses? See this table and you'll understand what I'm asking.

For wireless routers, thinking about it some more, I'm guessing that a wireless router would get its global routable address from an ISP, use the subnet bytes to get a network address of its own, and then the interface part of the addresses would just be any clients hooking on to it.

In IPv6, there are no broadcast addresses since that would bring things to a crawl, if you tried broadcasting to 2^64 i.e. 18 quadrillion addresses. In other words, broadcast just doesn't scale when going from v4 to v6, which is why it was dropped. In v4, network addresses were used in routers to help route traffic - you'd use them mainly w/ the routing protocols. So here, I'm guessing that saying something like 2001:0459:de11:0001::/64 would define a network? In other words, are all zeros in the interface ID excluded from usage?

Actually, your post was a great help.