Slashdot Mirror

Why is IPv6 not based on MAC adresses? I've never understood this.

Well, first of all, it sort of is. The typical way to get an address on an IPv6 network is stateless auto-configuration, which basically allows your client to combine an advertised route prefix with the EUI-64 (basically a longer version of a MAC address that can be generated from a MAC address) to determine its IP. You don't need any configuration for new clients and they always get the same IP address. Note that Windows Vista/7 use a hashing function with random data and the MAC address so that you can't track a single machine based on its IPv6 address, which solves privacy concerns.

Second, you can't just use the MAC address because it's not easy to route traffic that way. Routing works today because networks are assigned contiguous blocks of addresses, so it's easy to tell where to route traffic based on the address prefix. If we just had MAC addresses (which contain no information about which devices are connected to which networks), routing would require huge tables that would frequently change. This works OK for a small to medium sized network (e.g. switched Ethernet) but it doesn't work at all for the Internet. Even medium-large organizations need to use subnets to effectively manage traffic, which aren't possible without network prefixes.

This might have been a good case for accepting the proposal 'Redesignation of 240/4 from "Future Use" to "Private Use"':
http://tools.ietf.org/html/draft-wilson-class-e-02 ... as beneficiaries would have some degree of control over the equipment linking the two sites. However the proposal is expired.

I suppose now would be a good time to point out that RFC 5681 is the most current specification of the standard for TCP congestion control. Would it be asking too much for people to stay current on the RFC series before they start cracking off about standards compliance?

http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-01

http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf

We would atleast still need something like DNSSEC to validate what is stored in DNS. So that we can store in DNS, not just the A- or AAAA-record, but also which CA is allowed to sign your certificates.

But by the time you're using DNSSEC, the domain registry is already acting as an ersatz CA by signing the CERT record (RFC 4398) that you have added to your domain. So I agree that DNSSEC is the real answer to TLS PKI.

I though it would be useful to have a post or two here that mostly ignores exhibit Apple and talks about the book.

A guy by the name of Adam Thierer has put quite a bit of work into Thoughts on Tim Wu's Master Switch. What makes it interesting is the Tim Wu dropped into the discussion thread to rebut several points, and then Adam writes a response to that rebuttal.

Unfortunately, Adam makes a mistake that Russ Roberts sometimes makes on EconTalk (which I generally enjoy). The story goes like this: something big is happening, some enlightened souls speak out "we should worry about this", someone loosely affiliated with the furrowed forehead sect spouts a rabid depiction of this which the MSM circulates aggressively, the bad outcome does not materialize, and in the aftermath, some careless bloghards conclude we were wrong to worry so much in the first place.

This has been said about Y2K. It's still being said about the CDC and the imminent (or not-so-imminent) global influenza pandemic. Big flu blew over. Should the CDC stand down?

Larry Brilliant [still] wants to stop pandemics.

One possible version of the true story is that we might need to maintain a permanent vigilance on the rise of corporate gorillas. Sure AOL/Warner face-planted. Some gorillas are clumsy. And there was a time when Google was vulnerable and might not have become a counter-balancing force. These are contingent outcomes.

I have to say I think it's a bit of a dim bulb argument to argue from a catastrophe averted that there wasn't much risk in the first place, unless the belief is that the warning system was operating in complete isolation on an entirely separate plain of reality.

I loved Google from the outset, but my loyalty hung by a thread if Google had taken certain corporate directions. I've been around long enough to recall IBM as the 800 pound gorilla. I didn't much enjoy living through the Microsoft replacement.

Seth Godin said in a lecture at Google (four years ago) that Google has promoted their brand to such a degree that to backtrack on their declared values would cause them immeasurable brand injury. I tend to agree. They aren't going to poop the bed for small potatoes.

Microsoft did succeed in stifling innovation for a few years. It might have been a lot worse if they hadn't misjudged the internet, and been forced to take a tripping penalty on Netscape, and then spend two minutes in the FTC penalty box around the time of Google's nascence.

There are 17,000 federal lobbyists in Washington, DC. They exist to promote regulatory capture for vested interests. What will Apple do a year after losing Steve when their share price has contracted 40 percent? Will they reinvent, or run for cover?

I'm inclined to ascribe more of our good fortune (so far) to a small group of determined people tirelessly trying to do the right thing as described in RFC 2468.

Should we worry, or not?

...with RFC 2324?

http://tools.ietf.org/html/rfc2324

Doesn't adoption of IPv6 remove one of the more effective layers of security we have today, the obfuscation layer, being hidden behind the router?"

Please read Local Network Protection for IPv6 [RFC 4864].

Wayland is a display server, like X. Why wouldn't it be possible to forward Wayland over SSH?

The RFC for SSH (section 6.3) has specific provisions to allow X11 forwarding which includes authentication and session information; this is implemented separately from tcp port forwarding.

If Wayland uses basic TCP and does not have the same display/auth features, then this isn't an issue - standard port forwarding would work just fine. Further -- reading quickly through the site doesn't say if it's a networked provider at all -- but given the info that *is* present, I suspect not.

Not quite; 6to4 requires more than this scheme.

Not much more. The IPv6 header that 6to4 inserts is mostly just address bits, which your suggestion would also require, perhaps using RFC 2004 or loose source routing. Most of the remaining 8 bytes are equivalent to fields in the v4 header. Only the (optional) flow label is unique to IPv6 (for now, see the IPv4 flowlabel draft).

6to4 [...] requires a relay router to reach native ipv6 hosts.

As opposed to your proposal, which offers no method to reach native v6 hosts.

What it does have is compatibility with far more equipment.

Which equipment? 6to4 is already 'compatible' with the routers on the public v4 internet, by virtue of hiding the v6 stuff entirely. NAT devices have to be upgraded in either scheme, as do the hosts and the applications that run on them, to accommodate the new addressing scheme. And yes, your proposal does introduce a new addressing scheme, in which hosts without public v4 addresses will require multiple v4 addresses to identify them uniquely (just how many are needed depends on how many layers of NAT it's hiding behind). Your scheme may avoid the need to upgrade any links and routers between the host and it's NAT device, but ISATAP or 6over4 can do the same for IPv6.

The updates would be simpler as well.

Simpler how? By introducing a variable-length addressing scheme, you actually seem to be making things more complex.

Not quite; 6to4 requires more than this scheme.

Not much more. The IPv6 header that 6to4 inserts is mostly just address bits, which your suggestion would also require, perhaps using RFC 2004 or loose source routing. Most of the remaining 8 bytes are equivalent to fields in the v4 header. Only the (optional) flow label is unique to IPv6 (for now, see the IPv4 flowlabel draft).

6to4 [...] requires a relay router to reach native ipv6 hosts.

As opposed to your proposal, which offers no method to reach native v6 hosts.

What it does have is compatibility with far more equipment.

Which equipment? 6to4 is already 'compatible' with the routers on the public v4 internet, by virtue of hiding the v6 stuff entirely. NAT devices have to be upgraded in either scheme, as do the hosts and the applications that run on them, to accommodate the new addressing scheme. And yes, your proposal does introduce a new addressing scheme, in which hosts without public v4 addresses will require multiple v4 addresses to identify them uniquely (just how many are needed depends on how many layers of NAT it's hiding behind). Your scheme may avoid the need to upgrade any links and routers between the host and it's NAT device, but ISATAP or 6over4 can do the same for IPv6.

The updates would be simpler as well.

Simpler how? By introducing a variable-length addressing scheme, you actually seem to be making things more complex.

1. (1) The valid_policy ...
2. (2) The qualifier_set ...
3. (3) The criticality_indicator ...
4. (4) The expected_policy_set ...

http://www.ietf.org/rfc/rfc3280.txt The camelcase and prefix 'm' are not that far fetched. Variables named 'parent' and 'children' seem to make sense. Only mOriginalExpectedPolicySet seems troubling to me.

Well if it's just plain text they could open the file in an editor, highlight the text, and use copy/paste to drop it in a textarea field in an HTML form.

So let's make the problem harder. How would I have enabled uploading of a binary object in 2001? I'd do the same thing I do today; use "forms-based file uploading."

RFC 1867 defining "forms-based file uploads" appeared in 1995, some months before Berners-Lee and company released RFC 1945 proposing HTTP 1.0. HTML 3.2 (1997) defined the "file" input type that Web applications use for file uploads. That element is usually displayed as a text box into which a file path can be entered, along with a "Browse" button that opens the local file browser.

Of course, there were many other ways to upload a file to a web server by 2001. I wrote a PHP-based application for a legal foundation that enabled subscribed attorneys to share documents in an online archive. Members could register a document online. They'd then receive a mail message to which they would reply after attaching the file. The message included a unique code that so the file could be matched to the registration entry in the database. This worked especially well with people on services like AOL whose interfaces at the time were not friendly to RFC-1867 uploads. (Nowadays I'd probably use either WEBDAV or dspace depending on how much structure I'd need.)

Sometimes I'd use Samba to export directories from a Linux application server to the Windows desktops. Then staff members could simply drop HTML files into pre-determined folders and have them appear within the context of the website. Nowadays, though, I handle pretty much all the content editing on the browser side with forms and TinyMCE. That way I get reasonably clean HTML code as opposed to what you get from someone copying and pasting from Word into a text box.

I wouldn't have thought uploading files was a key obstacle in the way of platform-independent development in 2001. Surely there must have been some bigger roadblocks.

If you're talking about an application that periodically collects files from a Windows workstation, in 2001 I'd have used an automated shell script running smbclient to connect to the workstation using SMB/Netbios and collect the file(s). What happens next depends on the application. I often run PHP scripts from the command line to process text files because I know it well, because of the enormous array of functions it offers, and, frankly, because I've always found Perl's syntax rather intimidating. grep, sed, and awk go a long way, too. Automatically manipulate a graphic image? ImageMagick.

IPv6 addressing is wonderfully simple.

IPv6 addressing is brain damaged for at least two reasons:

1) It overflowed the 16 bytes prudently allocated for struct sockaddr_in by people who understand backwards compatibility better than the IPv6 designers.

2) The existing IPv4 address space was embedded at the least significant instead of most significant end of the IPv6 address. What on earth were they thinking?

Various apologists usually trot out the security argument, which is bogus (a form of security by obscurity) and some bafflegab about routing advantages. The fact is, IPv6 addresses put four times the cache pressure on routers compared to IPv4 and failed to drain the swamp. Bottom line is, 128 bit IPv6 addresses was a massive mistake. One of many in the slowl motion IPv6 train wreck.

Is this a backwards opportunity taken for asserting that he is one of the Fathers of the Internet?

I would say so. Below is the references section of RFC 791. Cerf shows up only on the "Catenet" article while the bulk of the heavy lifting was apparently done by John Postel, a rather more humble person it would appear. And Bob Kahn, who for some reason does not appear in these references. On the whole, Cerf seems to have mainly acted as a PM and money man.

[1] Cerf, V., "The Catenet Model for Internetworking," Information
          Processing Techniques Office, Defense Advanced Research Projects
          Agency, IEN 48, July 1978.

[2] Bolt Beranek and Newman, "Specification for the Interconnection of
          a Host and an IMP," BBN Technical Report 1822, Revised May 1978.

[3] Postel, J., "Internet Control Message Protocol - DARPA Internet
          Program Protocol Specification," RFC 792, USC/Information Sciences
          Institute, September 1981.

[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing,"
          COMPCON, IEEE Computer Society, Fall 1978.

[5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences
          Institute, September 1981.

[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"
          Computer Networks, v. 3, n. 1, February 1979.

[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and
          Newman, August 1979.

[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences
          Institute, September 1981.

[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
          Institute, September 1981.

This would mean updates to all hosts and all NAT devices...

And that's why what you're talking about wouldn't have been any better than IPv6. It requires updates to almost every unmanaged residential host and gateway before anybody would be able to rely on it, which is the main problem with IPv6. Only, your proposal doesn't fix any of the other problems in IPv4 in the process. it just adds address space, and in that sense, isn't really better or different than Realm-specific IP [RFC 3103], which ended in precisely the same ignominious failure that your idea would have met. QED.

Anyone got links to confirm / disprove this theory?

Short version: Cox was just wrong. Cisco wasn't shipping big IPv6 routers in 2004 (although they were shipping other IPv6 hardware and software), but it wasn't because of patents. It was because there was no demand from the telecommunications companies, who knew they had several years before IPv4 ran out. Furthermore, Cisco's current largest routers (the carrier grade CRS series) support IPv6 (example), yet 20 years from the publication of the main IPv6 RFC is December 2018. So Cox's theory is plainly invalidated.

Long version: The closest anything has come to a patent scare is Microsoft's 6,101,499 patent, but "After extensive review by our technical experts, Microsoft does not believe that the 499 patent includes any claims which cover RFC 2462 or RFC 2464 [i.e., IPv6]." (source). So Microsoft, about as big a software player as there is, went out of its way to clear a patent that a third party (PUBPAT) had identified as potentially related to IPv6.

Furthermore, Apple, Google, Microsoft, Sun/Oracle, and VMware all ship IPv6-compatible software. Lots of home routers, including Apple's, also support it. Cisco has supported it in IOS since 2001. IBM has supported it in z/OS since 2002.

Since major companies have been shipping hardware and software that implements IPv6 for years with nary a peep from anybody, laches becomes a serious issue for any potential plaintiff. Of course, all of these large companies have legal departments that have analyzed IPv6 for patent issues, as have groups like PUBPAT. It seems unlikely that they would all miss a problematic patent of any significance.

No, the hold up seems to be entirely on the infrastructural side, which is much more a problem of cost than capability. The routers and switches that make up the Internet infrastructure are extremely expensive (tens of thousands to millions). Here's one example. ISPs and long-haul fiber operators aren't going to spend untold millions of dollars on upgrading their equipment and training their staff while the old stuff still works fine and they're still making money off of it.

And who authorizes the 'signature' to ID that something can be written to the hard drive? The JRE (Java Runtime Environment)? If there's a bug in the JRE which can be exploited, then it doesn't matter if it's signed or not.

It's not like Java forces you to set the Evil Bit before you can compromise a system. It's not magickally immune just because it runs bytecode. Somewhere, somehow, the code has to get interpreted and executed. If there's a bug ANYWHERE along the line that someone can figure out (buffer overflows being a common one, but there's other ways), and they figure out how to abuse it in just the right way so to break out of the so-called 'sandbox', then it's got potential to infect your machine with worms and trojans.

It's the same issue as with both PDF and Flash. The difference is that there has been a lot of negative press for Adobe for the lax security in their software (and rightly so). Java hasn't had as much press on it from what I've seen on /., but there's likely a lot of defects and exploits still present.

After reading their FAQ, looks like Comcast is doing the right thing and also admitting the DNS Redirector/Helper wasn't the right solution.

Are customers who have opted in to or out of Comcast Domain Helper impacted by this?

        * When DNSSEC is deployed on all of our DNS servers, the web error redirect function at the core of Comcast Domain Helper will be disabled, as this is not technically compatible with DNSSEC.
        * Customers that have opted out of Domain Helper will be the first customers that we migrate to the new DNSSEC servers. Domain Helper will not be active.
        * Comcast does plan to turn off Domain Helper when DNSSEC is fully implemented.

What happens to Comcast Domain Helper, which offers DNS redirect services, when you fully implement DNSSEC?

        * We believe that the web error redirection function of Comcast Domain Helper is technically incompatible with DNSSEC.
        * Comcast has always known this and plans to turn off such redirection when DNSSEC is fully implemented.
        * The production network DNSSEC servers do not have Comcast Domain Helper's DNS redirect functionality enabled.
        * We recently updated our IETF Internet Draft on this subject, available at http://tools.ietf.org/html/draft-livingood-dns-redirect, to reflect this.

Error 402
Give me moar money!

And how will they choose which IP to use? If all computers in my network have two IPs then they'll probably use one of them randomly, which means that some established internal connections will break after the public IP changes.

Not randomly. See Default Address Selection for Internet Protocol version 6 (IPv6).

I think you are overreacting a little bit. The expectation always was that one or more root servers would be unavailable at any one time - hence why there are 13 different root server systems available. More than one can be unavailable for days, and due to redundancy and caching it won't affect anything - as expected, nobody has really noticed this blip.

There should be a good mix of technologies used in the different root server systems - different architectures, OS, etc. Some sites use anycast which gives massive redundancy within that system as well as providing good performance. However other architectures have their place and may be more robust to attack or certain failures. We need the variety.

So technically it's a shame that H has gone down - they don't seem to have a good track record. Fortunately this time it isn't an issue.

You can deploy an IPv6-only network where the clients can still connect to IPv4-only servers.

It's called NAT64:
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful

It is highly stressed that inside a single network only IPv4 or IPv6 be used.

Bullshit. Dual-stack has *always* been part of the transition plan.

Now, design a method of tunneling IPv4 packets across an IPv6 network

Why would you ever need that? The core network can be dual-stack. Edges slowly migrate to v6-only. v4 machines work as they always have.

Now also design a way to tunnel IPv6 packets between two IPv6 networks separated by an IPv4 network.

There are *myriad* solutions for this. Hell, 6to4 was first described nearly ten years ago!

Now we need the ability for IPv6 only clients to be able to connect to IPv4 only servers.

NAT64 and DNS64.

but as far as I can tell, they were not all ready when IPv6 was first announced.

That's only true for your last example... unfortunately, the IETF failed hard, there, underestimating the cost and complexity of transition. Fortunately, companies like Comcast, dealing with the real-world issues of transition, convinced them than NAT64/DNS64 are necessary technologies to make the transition possible.

I think you want this one for serious usage.

One of the suggestions I've read around here is to support public keys in DNS records. If the DNS records are signed, then you can verify the public key did, in fact, come from the domain owner.

That feature has been in DNS and SSH for several years now. The optional SSHFP record contains a fingerprint of the public key, and if the ssh client has VerifyHostKeyDNS set to "yes", you don't have to manually verify the host key.
The question then is whether the DNS can be trusted.

Anyhow, to generate a couple of DNS entries for a host to insert into the zone file, do something like:

#!/bin/sh
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key | cut -d\ -f2 \
  | sed 's/://'g | xargs echo -e `hostname` "\t\tSSHFP 1 1"
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key | cut -d\ -f2 \
  | sed 's/://'g | xargs echo -e "\t\t\tSSHFP 2 1"

If your DNS server doesn't support the SSHFP RR identifier, you may have to use the numeric code, 44, instead.

a: Its actually ubiquitous in the LAN these days. Both Apple and Microsoft use IPv6 link local operations very heavily, because it Just Works with nice stateless autoconfiguration and multicast.

You do realize that XP does this out of the box ... over IPv4 right? And there are RFCs and standards that make it really easy for an IPv4 device to auto configure itself in a link local manner ... right?

Windows XP, OSX, and my FreeBSD machine with isc-dhcpd will all fallback to link local addresses if DHCP fails.

Unfortunately, every generic home router defaults to not using link local address space by default and uses some other private address space and DHCP so most people, even techies are entirely unaware of the fact that this isn't unique to IPv6 in any way. Of course, most of the same people don't realize that IPX did it as well because they don't even know what IPX is.

http://tools.ietf.org/html/rfc3927

The RFC is from 2005, but it was done in at least 2001 by Microsoft that I'm aware of, and probably well before that by Cisco and Bay and those guys, but I haven't been a router flunky in a long time so I don't really recall more details.

When the "internet" was generally available in the form of social networking sites like Slashdot, somebody thought the Usenet Netiquette FAQ was obsolete so people ignored common sense and wrote whatever thought that popped in their heads. I'm not sure if people actually paid attention to the Netiquette back in the mid 1990s but at least they should be aware of such a thing. http://tools.ietf.org/html/rfc1855

Get with the program, man, that was released on Friday.

I kid - the only way I found it was to search on the gp's suggestion, find an article on wikipedia about a different record type, linked to a wikipedia page on dns record types, found an SSH type (SSHFP) that was sort of like what you suggested, and then from there reasoned that the right type should be called 'TLSFP', and voila, Google RFC out on Friday. Freakin' intarwebs.

They thought of a few features I missed in the few minutes between clicks above, it looks pretty sold.

It's good they're fixing the TLS MITM problem.

You mean like RFC4398? :)

http://tools.ietf.org/html/rfc4398

There is unfortunately no browser support, which surprises me ...

What is the Microsoft Loopback adapter

http://www.windowsitpro.com/article/john-savills-windows-faqs/what-is-the-microsoft-loopback-adapter-and-why-do-i-need-it-for-sql-server-.aspx

PERTINENT QUOTE/EXCERPT:

----

"If you don't have a network card then go to control panel/networks, choose add adapter and then add the Microsoft loopback adapter - which is just a "dummy driver, no hardware involved. This needs to have working network protocol(s) bound to it.

----

So in other words, all the loopback adapter is, is a dummy network card interface (that's all).

Want more?? OK:

http://tools.ietf.org/html/rfc1223

"Although the type field cannot change the protocol server at the final destination of the message, the type field can be used by intermediate processes on the network to process the message before it reaches the server destination. An obvious example is the 0xFF00 message loopback type function, where network processing to loop back the message results in nondelivery to the TO address."

And, as you can see, and as I stated here many times now as well? Additional processing does occur, which means more work, which means loopback adapter address work means more work and that it is slower because it's doing more work!

Here's even MORE backing that as well from more RFC's:

http://tools.ietf.org/html/draft-ietf-ipoib-channel-adapter-mib-08

"Loopback support allows for the sending and receiving of self-addressed packets that do not go out on the wire."

And also again: It's not a loopback jack (dongle type) in hardware, it's just a dummy interface if you install the optional loopback so that stuff like SQL Server can work if you don't have a NIC... but it always works at the 127.0.0.1 loopback adapter address, and yes, it does extra processing vs. using 0 or 0.0.0.0 which do immediate drops & with less work and thus, less time and processing vs. 127.0.0.1 (all per the links and RFC's above)...

Plus, in memory or not (it always is, even with a driver for the loopback adapter dummy driver itself)? You're just plain doing MORE WORK using 127.0.0.1 & doing loopbacks than not using 0 &/or 0.0.0.0 (& both of these latter resolve out to 0.0.0.0), and besides: ALL I EVER MENTIONED WAS THAT 127.0.0.1 IS THE IP ADDRESS USED TO TALK TO THE LOOPBACK ADAPTER (though sometimes, I have even seen 192.18.1.1 used this way also).

APK

P.S.=> As per usual, myself vs. my "naysayers" here (who are usually just a pack of amateurs & wannabes, who when proven wrong troll, impersonate, and continually try to harass me to no avail via impersonating me or unjustly modding down my posts with no technical justifications why via their multiple registered usernames here (see this entire exchange as evidence to that effect) lol!)? Ah, lmao, I gotta say it - "too, Too, TOO EASY!" (just TOO easy)... apk

What is the Microsoft Loopback adapter

http://www.windowsitpro.com/article/john-savills-windows-faqs/what-is-the-microsoft-loopback-adapter-and-why-do-i-need-it-for-sql-server-.aspx

PERTINENT QUOTE/EXCERPT:

----

"If you don't have a network card then go to control panel/networks, choose add adapter and then add the Microsoft loopback adapter - which is just a "dummy driver, no hardware involved. This needs to have working network protocol(s) bound to it.

----

So in other words, all the loopback adapter is, is a dummy network card interface (that's all).

Want more?? OK:

http://tools.ietf.org/html/rfc1223

"Although the type field cannot change the protocol server at the final destination of the message, the type field can be used by intermediate processes on the network to process the message before it reaches the server destination. An obvious example is the 0xFF00 message loopback type function, where network processing to loop back the message results in nondelivery to the TO address."

And, as you can see, and as I stated here many times now as well? Additional processing does occur, which means more work, which means loopback adapter address work means more work and that it is slower because it's doing more work!

Here's even MORE backing that as well from more RFC's:

http://tools.ietf.org/html/draft-ietf-ipoib-channel-adapter-mib-08

"Loopback support allows for the sending and receiving of self-addressed packets that do not go out on the wire."

And also again: It's not a loopback jack (dongle type) in hardware, it's just a dummy interface if you install the optional loopback so that stuff like SQL Server can work if you don't have a NIC... but it always works at the 127.0.0.1 loopback adapter address, and yes, it does extra processing vs. using 0 or 0.0.0.0 which do immediate drops & with less work and thus, less time and processing vs. 127.0.0.1 (all per the links and RFC's above)...

Plus, in memory or not (it always is, even with a driver for the loopback adapter dummy driver itself)? You're just plain doing MORE WORK using 127.0.0.1 & doing loopbacks than not using 0 &/or 0.0.0.0 (& both of these latter resolve out to 0.0.0.0), and besides: ALL I EVER MENTIONED WAS THAT 127.0.0.1 IS THE IP ADDRESS USED TO TALK TO THE LOOPBACK ADAPTER (though sometimes, I have even seen 192.18.1.1 used this way also).

APK

P.S.=> As per usual, myself vs. my "naysayers" here (who are usually just a pack of amateurs & wannabes, who when proven wrong troll, impersonate, and continually try to harass me to no avail via impersonating me or unjustly modding down my posts with no technical justifications why via their multiple registered usernames here (see this entire exchange as evidence to that effect) lol!)? Ah, lmao, I gotta say it - "too, Too, TOO EASY!" (just TOO easy)... apk

Mailing list posting from one of the sysadmins (Too bad they don't do word wraps).

http://www.ietf.org/mail-archive/web/78attendees/current/msg00848.html

Staying up until 7 AM so that bunch of geeks could get decent connectivity in their hotel - kudos.

There was also the nice orange Cat6 cable running through the parking lot, going through windowframes and doorways and ending up at a Catalyst switch taped to a window :)

All closed source war dialing apps follow RFC 3514n, ATMs simply firewall all incoming packets with the evil bit set.

This does not work so well when the feature is present but buggy in various browsers, or for features whose presence or absence cannot easily be detected, the result would be inconsistent rendering if user agent was not checked to redirect the user to the proper page.

It is not a best practice to rely on attempts to "test for the presence" of a feature, to determine whether it should be used.

"Detection" is only possible if using javascript: not all browsers support, and some users might have it turned off.

User agent is commonly used for this purpose, and it is the best practice as defined by the standard to use the user agent field for the purpose of tailoring responses to avoid particular user agent limitations

See RFC 1925, rule 3.

NTP solved this ages ago by distributing atomic clock accuracy through the network.

Wrong. NTP is rarely as good as a millisecond. Atomic clocks should be accurate to better than a microsecond.

There is an IETF effort, TicToc, intended to help improve time transfer to better than NTP accuracy, but that requires router assistance (i.e., participation by the ISP), as routers and switches will introduce large and indeterminate delays by atomic clock standards.

"Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view."

This was discussed a lot in 1996 in the IETF NewDom Working Group, which I participated in, and which partially lead to the creation of ICANN. What a zoo that was - it ended with Eugene Kashpureff going to jail for attacking the DNS root servers. For some reason, ".xxx" seemed to drive people crazy, and I am not sure it is much different today.

Doesn't anyone bother to read the RFCs? (probably not, they're too interested in trying to sell domains to make money)

• RFC 3675 : .sex considered harmful

So they just add it to the TLS handshake...
See TLS Extensions.

Extended hello format:

struct {
                    ProtocolVersion client_version;
                    Random random;
                    SessionID session_id;
                    CipherSuite cipher_suites;
                    CompressionMethod compression_methods;
                    Extension client_hello_extension_list;
            } ClientHello;

They can put whatever they want in there without corrupting the handshake.
(Though, I may be wrong, any TLS geeks care to comment?)

RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Windows does this by default.

Kind of two separate arguments.

Lets look at the original posters claim

MAC address sure, since your device's MAC address isn't used after your packets reach the ISP's border. However, I invite you to try to establish a full duplex connection using a spoofed IP.

Now his point is that your MAC is irrelevant beyond your layer 2 link. OK, correct on ipv4.

However, what if you use ipv6 and RFC 2462 "Stateless Address Autoconfiguration" which basically picks your ipv6 address based on your MAC address. Wedging a 48 bit mac address into, say, a /28 of ipv4 space isn't going to work too well, but wedging a 48 bit mac address into a /64 LAN of ipv6 works pretty well.

http://www.ietf.org/rfc/rfc2462.txt

Now the argument is that no matter which ISP you connect to, or which starbucks you connect to, etc, you can always correlate that large collection of 128 bit ipv6 addresses in a log by trashing the upper 64 bits and figuring out which 48 bit mac addresses map into the /64 ipv6 addresses.

Even worse, the top 24 bits of the mac define the device manufacturer, so no matter where you go in the world, people know you've got an apple, or whatever.

So, "your device's MAC address isn't used after your packets reach the ISP's border" isn't really true if your layer 3 address depends directly on your layer 2 address.

On the other hand, if instead of using your autoconfigured address, you fake or "spoof" some other random /64 on the LAN, then you can't be tracked. Now if you do this at work, your local net nanny is going to get all teed off that some "unknown" mac address is online, because look at that ipv6 address that doesnt match any known inventoried hardware MAC address.

You can insist that using a "fake" MAC is not spoofing, or whatever, but then you're getting into pointless naming games.

These are people who are paid with the expectation that they know these things. Half of the time, the first words out of their mouth is "What's a RFC?"

You wouldn't like me, I have a tendency to quote things from RFC 1796 when I don't follow RFCs in certain instances due to my own 'good reasoning' which people may oppose.

And now, I shall quote you a piece:

It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal.

Proper email validation is not trivial

The regular expression, if one must be used, doesn't need to be any more complex than:

^[^@]+@[^@]+$

Actually, the local part of an e-mail address can be a quoted string, containing pretty much any character, so "user@host"@example.org is a perfectly valid e-mail address, and doesn't match your regex. Most systems won't accept it, but it's valid...

Considering how many entry forms still don't allow '+' in an e-mail address (or, worse, allow it in the sign-up box but not in the unsubscribe box), and considering how many banks still restrict you to an 8-character password, does it come as any surprise that they have difficulty with something that isn't defined in an RFC?

Your five megabytes of HOSTS file is probably irrelevant compared to real performance problems. That's not what a HOSTS file is meant for, and you should generally not optimize for the abusive case. Ideally you'd just use your application's native method for dealing with address-blocking, and if you need a blanket block such a huge number of addresses then a local proxy is the way to go, eg. Privoxy.

Micro-optimization is the root of all evil. The way to tune performance is to measure where the biggest problem is, and then reduce that. You do not hone in on a few bytes from a file format. For instance, look at http://en.wikipedia.org/wiki/Amdahl's_law. It's not worth putting even ten minutes of time into something that makes no noticeable difference to just about anybody, when you could spend that time working on a problem that will make a noticeable difference to some people. Therefore, the "math" does not yet support you; at least not given the evidence provided. You have to show that a reasonable HOSTS file used as recommended (or as there is no more reasonable alternative) makes a more significant difference to some important aspect of performance than any other change that could be made as easily.

Now, if you look at the Standard for IPv4 addressing, http://www.ietf.org/rfc/rfc1123.txt, you will see that dotted-decimal notation is required for Standards-compliant IPv4 applications (you can add further restrictions but not relieve restrictions), and if you look at http://tools.ietf.org/html/rfc952, the HOSTS file is required to have all four components. IPv6 does have a summary version in the standard, but I'm sure you won't like what IPv6 does to the size of the average HOSTS file (that is to say, marginally increase it). It's bad to break Web Standards without a really excellent reason. It had better be security, or a performance gain so bountiful and universal that none could fault it, such as when browsers started going to 6 connections per web server rather than 2.

Your five megabytes of HOSTS file is probably irrelevant compared to real performance problems. That's not what a HOSTS file is meant for, and you should generally not optimize for the abusive case. Ideally you'd just use your application's native method for dealing with address-blocking, and if you need a blanket block such a huge number of addresses then a local proxy is the way to go, eg. Privoxy.

Micro-optimization is the root of all evil. The way to tune performance is to measure where the biggest problem is, and then reduce that. You do not hone in on a few bytes from a file format. For instance, look at http://en.wikipedia.org/wiki/Amdahl's_law. It's not worth putting even ten minutes of time into something that makes no noticeable difference to just about anybody, when you could spend that time working on a problem that will make a noticeable difference to some people. Therefore, the "math" does not yet support you; at least not given the evidence provided. You have to show that a reasonable HOSTS file used as recommended (or as there is no more reasonable alternative) makes a more significant difference to some important aspect of performance than any other change that could be made as easily.

Now, if you look at the Standard for IPv4 addressing, http://www.ietf.org/rfc/rfc1123.txt, you will see that dotted-decimal notation is required for Standards-compliant IPv4 applications (you can add further restrictions but not relieve restrictions), and if you look at http://tools.ietf.org/html/rfc952, the HOSTS file is required to have all four components. IPv6 does have a summary version in the standard, but I'm sure you won't like what IPv6 does to the size of the average HOSTS file (that is to say, marginally increase it). It's bad to break Web Standards without a really excellent reason. It had better be security, or a performance gain so bountiful and universal that none could fault it, such as when browsers started going to 6 connections per web server rather than 2.

It's also OpenSource: Note: see mDNSResponder source code at www.macosforge.org, which includes a full implementation of the DNS-SD/mDNS Sleep Proxy Service, available under the Apache 2.0 Open Source license. AND written up as a specification http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-11

Meaning if Linux or *BSD wanted to they too could also have it too. In fact, I'm really hoping that they do because I'd love to not have to send a WOL to my HTPC or Server when I want it to download something. I can just have my sheevaplug wget an address and have it wake itself.

http://tools.ietf.org/html/rfc114