Slashdot Mirror

Yeah? It's not fundamentally any different to a v4 header. It's got a new protocol number and more of it is dedicated to storing addresses. Yes, it's 2x the size, but that's because the src+dst addresses are already 32 bytes to v4's 20 bytes total.

Presumably you were suggesting to do the same thing, because there's no way to fit a pair of 128-bit addresses into the v4 header without making it bigger.

(Ab)using the version field (not the protocol field!) is not the only way to extend IPv4, probably not even a good way, however that is a red herring. The point is, there is no such thing as an IPv6 packet that looks like IPv4, even when the source and destination addresses permit it. That is the big gaping flaw of IPv6 that lead to the adoption fiasco.

Nothing wrong with the technique, but there's something wrong with IPv6, namely not the slightest attempt to retain backward compatibility with IPv4 at the protocol level.

Well, there's that version number in the header, which allows the two to coexist.

Not only as separate protocols, but separate infrastructures. IPv6 has its own home rolled approach to multicast for example, which nobody uses as opposed to IPv4 multicast which is heavily used (and will not be going away any time soon because it runs the world's financial systems). IPv6 has its own NIH address syntax. Everything that could possibly be made different about IPv6 was made different. Second system syndrome in its most ugly form.

But more to the point: how is your v4x any different to this? You're suggesting doing exactly the same things v6 did.

(Note that I'm not shouting you down here; I'm pointing out that you're proposing essentially the thing that we already did.)

I'm not making a proposal. I am saying that the time is right to make a proposal. I didn't know that there's actually a proposal on the table, here. I will be taking some time to study it, I suggest you do too. It seems I'm far from the only person who thinks that IPv6 is still a disaster and there is room to attack the problem from another direction.

Privacy addresses don't overflow your ARP tables. And in any case, you don't need privacy addresses to keep your MAC out of your address; RFC 7217 is a thing and Windows 7+ use it (or something very similar) by default out of the box, or you can use DHCPv6 or even just manually pick an address.

And I can't seriously believe that you're arguing that we want an address shortage. We don't.

(In a similar vein, we don't want to pay tons of money to deal with NAT forever, which is why people are telling you that using NAT on v6 is dumb: because it'll make networks more complicated, and thus more expensive, more or less forever.)

You should check out RFC 4941 for temporary IPv6 addresses. If you take a look at your IPv6 interfaces on a Mac or Windows PC you'll see those temporary addresses. This addresses (ha!) the problem you refer to.

I had a lengthy conversation with netflix support, apparently, there is NO way to view 4K netflix content except for a smart TV that supports "software" as they call it. Essentially, its DRM as demanded by studio.

Is it DRM or is it just because Netflix is encoding their 4K content with H.265 (aka HEVC). There is no H.265 support in browsers and it's unlikely there ever will be due to patent licensing issues (two separate patent pools which means two separate patent licenses and there are rumours that there will be a third pool). Fortunately, the future for web video is AV1, royalty-free and aiming to be better than H.265 (see Alliance for Open Media and NetVC). In the meantime, Netflix is looking to stream 4K with VP9 so that may be an option for you soon.

See https://tools.ietf.org/html/rf... .

An internet is any computer network which is addressed by Internet Protocol.

The Internet is the large super-network of a bunch of interconnected internets.

RFC-1918 is the perfect example of these distinct uses. I firmly believe that since the second aforementioned use is a particular collection of internets, that the correct usage is as a proper noun. You can connect multiple private internets, but that would not constitute the Internet.

You need to be looking into open protocols, and implement them using free and open source software:
https://www.ietf.org/proceedin...

They invented peer-to-peer! A very new concept first envisioned in RFC 1 as host-to-host. Money well spent.

Who would have think that "put all eggs in one basket" was wrong?

While dated, much of FYI-28 / RFC 1855 is still applicable and the world would be a better place if more folk followed it.

RFC 4042

Even though 169.254.x.x is not supposed to be directly routable to the internet, it appears that it can be routed anywhere within a domain of internet-valid IPs, which could make it vulnerable to an unintended routing configuration error. ...

If I wished to "guarantee" there would not be a way to hack a direct connection from the internet to a machine in a private network, I would be using RFC1918 defined IPs, not link-local addresses.

Link local addresses cannot be routed. RFC6890 specifically states this. If you're willing to assume equipment that violates this, then there's no reason to assume that a private network address will be treated any differently.

Your zeal to be correct ignores the original problem -- RFC1918 defined IPs are forwardable. Consumer equipment already, by default, assignes a private network IP and forwards the traffic to the global network. That is what the original poster specifically did not want to have happen. The original poster does not care whether there is a "direct" or forwaded connection -- he or she wants no connection whatsoever.

Your solution is simply not a solution.

This is a squarely people issue. When will people figure out that if you don't have the source code and build toolchain, you don't own the product?

I mean, sure, there are self-contained devices that might have an Atmel chip or even some kind of ARM. My MP3 player is a good example. It has several well-defined functions--things that it does--and it doesn't do anything fucking else. No cloud. No updates. I can plug it into my computer, it exposes a vfat filesystem, I can copy over some MP3, and it will play them. I have no need to have the source code if there even is any.

When you have shit connecting up to the internet, updating, telemetry, APPS! etc, you need the source code of everythinginvolved, especially the server component. My treadmill came with one of those fitbit thingies. Of course it's useless to me. It wasn't part of my criteria when I selected a treadmill. I've poked the thing a bit and may be able to reverse engineer whatever service in the clouds that gets its data with enough effort, but I'm lazy! The thing is worthless.

We see the same thing with Revolv here. It's now worthless. They won't tell you about the protocol it uses to go up and down to the clouds. They don't give you an install CD if you want to run your own Revolv server. You might be able to reverse engineer it. It might be hopelessly DRMed. Who knows? It's worthless.

So, given the choice between IoT coffee pots, which one do I want? Do I want the iSmug Brewer+? Does it support RFC 2324? Not on your life unless it advertises support. Does it push updates to the clouds when my coffee is ready? Sure, it might advertise that, but will they let me change which server to connects to and how and what data it sends? Hell no.

Instead I want a Libre OpenBarista. It's fully RFC 2324 compliant. Whatever extension to HTCPCP enables it to do a web query against a service in the clouds when my coffee is ready will also be open and the thing will let me configure it to go to MY cloud.

"Consumers" (COWS) are just going to have to feel sufficient pain before they realize why they want a Libre OpenBarista instead of the iSmug Brewer+.

https://tools.ietf.org/html/rf...

Best part is that this enhancement will run of peanuts and popcorn. Worst part is a potential denial of service mentioned by Tom Lehrer.

https://en.wikipedia.org/wiki/...

https://www.ietf.org/rfc/rfc35...

Just require that the dark net be RFC 3514 compliant.

Hello fellow victim of RFC 3696:

Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters

            ! # $ % & ' * + - / = ? ^ _ ` . { | } ~

period (".") may also appear, but may not be used to start or end the local part, nor may two or more consecutive periods appear.

The wording isn't grammatically correct. There's two interpretations:

local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters [including period] may also appear, but may not be used to start or end the local part

--or--

Sentence 1: Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters [special characters follow].
Sentence 2: Period (".") may also appear, but may not be used to start or end the local part, nor may two or more consecutive periods appear.

The first applies the ending character restriction to all special characters, while the second only to period.

The correct question is why do ISPs allow packets to enter their networks with spoofed source addresses, something upon which reflection attacks depend.

Ummm, no. It is difficult for ISPs to determine if packets with spoofed source addresses are coming in (unless those ip addresses belong to the ISP).

For example: my border router receives a packet from 8.8.8.8. Is that packet actually from 8.8.8.8 or was it spoofed? I have to depend on my upstream for that question.

What ISPs can easily do is block outgoing packets with spoofed source addresses.

Which is described in the document you linked to: http://tools.ietf.org/html/bcp...

Same reason someone might want to run a *publicly* accessible http server - to make content available.

The correct question is why do ISPs allow packets to enter their networks with spoofed source addresses, something upon which reflection attacks depend. BCP38 has been around for over 15 years, and the problem and solution were well known before that.

What, exactly, did Microsoft do to Kerberos? They wrote a binary-only extension that prevented non-Windows systems from talking to Windows' implementation of Kerberos. How did that impact the kerberos project itself, exactly? Their extension simply isolated Windows systems from non-Windows systems - doesn't seem to have slowed down the adoption of non-Windows systems at all, in fact.

As far as I can see, the Kerberos project is still going strong today, and Microsoft has since released the specs for its extensions under its Open Specification Promise (https://msdn.microsoft.com/en-us/openspecifications/), and as RFCs:
- RFC 3244 - https://tools.ietf.org/html/rf...
- RFC 4757 - https://tools.ietf.org/html/rf...
- RFC 1510 - https://tools.ietf.org/html/rf...
- RFC 1964 - https://tools.ietf.org/html/rf...

Looking at this, it looks to me like Microsoft's "embrace" of open source ended up with Microsoft itself being much more open. And you think that's a bad thing?

What, exactly, did Microsoft do to Kerberos? They wrote a binary-only extension that prevented non-Windows systems from talking to Windows' implementation of Kerberos. How did that impact the kerberos project itself, exactly? Their extension simply isolated Windows systems from non-Windows systems - doesn't seem to have slowed down the adoption of non-Windows systems at all, in fact.

As far as I can see, the Kerberos project is still going strong today, and Microsoft has since released the specs for its extensions under its Open Specification Promise (https://msdn.microsoft.com/en-us/openspecifications/), and as RFCs:
- RFC 3244 - https://tools.ietf.org/html/rf...
- RFC 4757 - https://tools.ietf.org/html/rf...
- RFC 1510 - https://tools.ietf.org/html/rf...
- RFC 1964 - https://tools.ietf.org/html/rf...

Looking at this, it looks to me like Microsoft's "embrace" of open source ended up with Microsoft itself being much more open. And you think that's a bad thing?

What, exactly, did Microsoft do to Kerberos? They wrote a binary-only extension that prevented non-Windows systems from talking to Windows' implementation of Kerberos. How did that impact the kerberos project itself, exactly? Their extension simply isolated Windows systems from non-Windows systems - doesn't seem to have slowed down the adoption of non-Windows systems at all, in fact.

As far as I can see, the Kerberos project is still going strong today, and Microsoft has since released the specs for its extensions under its Open Specification Promise (https://msdn.microsoft.com/en-us/openspecifications/), and as RFCs:
- RFC 3244 - https://tools.ietf.org/html/rf...
- RFC 4757 - https://tools.ietf.org/html/rf...
- RFC 1510 - https://tools.ietf.org/html/rf...
- RFC 1964 - https://tools.ietf.org/html/rf...

Looking at this, it looks to me like Microsoft's "embrace" of open source ended up with Microsoft itself being much more open. And you think that's a bad thing?

What, exactly, did Microsoft do to Kerberos? They wrote a binary-only extension that prevented non-Windows systems from talking to Windows' implementation of Kerberos. How did that impact the kerberos project itself, exactly? Their extension simply isolated Windows systems from non-Windows systems - doesn't seem to have slowed down the adoption of non-Windows systems at all, in fact.

As far as I can see, the Kerberos project is still going strong today, and Microsoft has since released the specs for its extensions under its Open Specification Promise (https://msdn.microsoft.com/en-us/openspecifications/), and as RFCs:
- RFC 3244 - https://tools.ietf.org/html/rf...
- RFC 4757 - https://tools.ietf.org/html/rf...
- RFC 1510 - https://tools.ietf.org/html/rf...
- RFC 1964 - https://tools.ietf.org/html/rf...

Looking at this, it looks to me like Microsoft's "embrace" of open source ended up with Microsoft itself being much more open. And you think that's a bad thing?

Sounds like Twitter forgot to take advantage of RFC 3514. More generally, I'd like to see this implemented more generally. It would make things a LOT easier!

Early days of the internet: all standards fully and publicly documented, easily supported on any make and type of device that could be connected to the net, not controlled by any single entity, could be implemented by anyone who has a compiler, choice of many possible programs to use.

Modern internet: no standards, private company able to control which devices are allowed to use "their" messaging scheme used by billions of people and which devices should be excluded, also able to decide what content is acceptable, not implementable by anyone who has a compiler, only a single company-proprietary app can be used making ecosystem more vulnerable.

That's sure an improvement.

Networks sending RAs too often are badly configured, but according to that thread, Samsung's behavior sort of encouraged people to do exactly that. Sending RAs very often restores an expired IPv6 route quickly on a Samsung device when the screen is turned on after several hours of idle. Sending RAs rarely would leave IPv6 broken for several minutes on such devices since they don't send a RS when the screen is turned on.

I have read that some other phones rate-limit RA packets in the wifi firmware instead of dropping all IPv6 packets in the wifi firmware. That solution would make much more sense than what Samsung has been doing. The networks that send RA packets too often should still be fixed as the RFC 7772 says. Your idea of having the phones warn about such networks sounds good to me.

Except the experience doesn't let you check how much water is in the kettle first, the kettle cannot keep a stable wifi connection, and as far as boiling water goes; it's a really bad kettle and it takes a really long time.

Granted, RFC 2324 is somewhat vague on the details, but you should be able to accomplish this with a single BREW request. Are you getting a 418 error code?

Why would I expect a kettle company to build a phone app with good UX?

I wouldn't. RFC 2324 is more than sufficient!

An IPv6 network is much easier to set up properly. Check out the HomeNet stuff, where you just chuck a bunch of routers together more or less randomly, with connectivity from cable and DSL and 4G, plus a bunch of wifi routers, and it all Just Works.

The IETF Homenet Working Group

Non-official Homenet HOWTO

I consider gmail to by my biggest threat to the privacy of my email.

If I want end to end security, well there is a standard for that. I use it. It works.

But gmail is close to having a monopoly on email. It isn't quite yet, but almost everyone I know uses exclusively gmail now. That means if I want to email them, Google IS the man in the middle. I can't easily email my friends without giving Google the contents of my email, which they will use to build a profile of me - and I've never signed up for any of their services or estasblished any kind of business relationship with them.

Furthermore, most small to medium businesses are using gmail.

Think about this: we used to have a decentralized, non-censorable, email standard that no one entity could control or pervert for their own ends. But the whole world said, "Fuck that, we want one advertising company to see everybody's email!.

Google is the main threat to the privacy of email today. Like Bruce Schneier observed, they want you to have email privacy from everyone except them.

-They did away with private addressing (site-local) "because it breaks the openness of the internet and firewalls". Tell that one to someone who's seen hackers use a Java-based PS2 Video broadcasting software to send files across the internet. Lets automatically use public addresses on air-gapped networks.

No they didn't.

See https://tools.ietf.org/html/rf... - Site-local was the original spec and that's deprecated since it doesn't allow for easily merging of two existing private networks. ULA fixes that. So damn right you can have private networks.

The standard has changed so many times in the last 10 years nobody can comprehend it; every book has a different set of material on it, every programmer has set their infrastructure up differently.

Oh please. Only things that have really fundamentally changed are the IPv4IPv6 transition mechanism. Now that NAT64 and DNS64 are in use, you can pretty much work with an IPv6-only network (ironically, a couple years ago everything else, including gaming, worked via a NAT64, except for Skype, which is supposed to go through anything)

They did away with IPV4's simplistic subnetting and supernetting, and introduced EUI-64 addressing which can track devices as they move from network to network. Marketing companies like Google and Microsoft were helping to write the standard.

Oh please, even Windows uses privacy extensions for IPv6. No one forces you to use EUI-64.

Very Few large deployments.

Tell that to the Chinese. They have *huge* networks, IPv6 only.

In short, I've never seen a good, clean, reliable way to link a user to a session that doesn't involve cookies. If you've got the magic solution to that, please...I'm all ears.

Have the user create a username and password and use RFC 7617 basic authentication. Or have the user create a TLS client certificate.

teach me how to logout (note: "close your browser" is not an acceptable answer) and I might stop despising basic authentication.

TLS client certificate? lol...ok, I'm sure all my users will love that. I'll get on that right away.

Apparently you didn't see where I said "good, clean"

In short, I've never seen a good, clean, reliable way to link a user to a session that doesn't involve cookies. If you've got the magic solution to that, please...I'm all ears.

Have the user create a username and password and use RFC 7617 basic authentication. Or have the user create a TLS client certificate.

Forums have several options to keep a user logged in without a persistent cookie:

• Switch to Basic authentication (RFC 7617)
• Switch to TLS client certificate authentication
• Use a session cookie and rely on the client-side password manager

PPP ECP (RFC 1968) is a common one.

https://www.ietf.org/rfc/rfc11...

All we have to do is check to see if the evil bit is set!

and until one single company, alliance of companies, or single open standard becomes globally adopted at the same level as the phone number, Facebook or anyone else isn't going to replace it.

Internationally, phone numbers are a messy hodgepodge of formats suited to whatever hack-jobs local telecoms used to get the job done.

Meanwhile, there exists an open standard that has been globally adopted more widely than any phone number format that Facebook relies upon for its entire livelihood.
The original.
The update when things got too crowded.
The formalized address scheme for the update to handle all of the wonderful, weird things that the original allowed for, but in a more organized way.

We're less "a long, long way from that" than you think, but we are a long way from Facebook controlling more than a tiny fraction of it. Thank god.

and until one single company, alliance of companies, or single open standard becomes globally adopted at the same level as the phone number, Facebook or anyone else isn't going to replace it.

Internationally, phone numbers are a messy hodgepodge of formats suited to whatever hack-jobs local telecoms used to get the job done.

Meanwhile, there exists an open standard that has been globally adopted more widely than any phone number format that Facebook relies upon for its entire livelihood.
The original.
The update when things got too crowded.
The formalized address scheme for the update to handle all of the wonderful, weird things that the original allowed for, but in a more organized way.

We're less "a long, long way from that" than you think, but we are a long way from Facebook controlling more than a tiny fraction of it. Thank god.

and until one single company, alliance of companies, or single open standard becomes globally adopted at the same level as the phone number, Facebook or anyone else isn't going to replace it.

Internationally, phone numbers are a messy hodgepodge of formats suited to whatever hack-jobs local telecoms used to get the job done.

Meanwhile, there exists an open standard that has been globally adopted more widely than any phone number format that Facebook relies upon for its entire livelihood.
The original.
The update when things got too crowded.
The formalized address scheme for the update to handle all of the wonderful, weird things that the original allowed for, but in a more organized way.

We're less "a long, long way from that" than you think, but we are a long way from Facebook controlling more than a tiny fraction of it. Thank god.

https://www.ietf.org/rfc/rfc35...

Name another media company that went out of their way to develop a patent-free media codec that was independent and competitive with other codecs of the time?

All the companies involved with the Alliance for Open Media and NetVC.

The requirement for client credentials in implementations of OAuth produces a couple practical problems.

OAuth 1 and OAuth 2 are unrelated protocols with similar names. The spec for each discourages servers from requiring client credentials (a client ID and client secret) in an API intended for use in an app that runs on the user's computer, such as a desktop or mobile app. As stated in section 4.6 of the OAuth 1 RFC:

In many cases, the client application will be under the control of
potentially untrusted parties. For example, if the client is a
desktop application with freely available source code or an
executable binary, an attacker may be able to download a copy for
analysis. In such cases, attackers will be able to recover the
client credentials.

Likewise section 9 of the OAuth 2 RFC:

Native applications that use the authorization code grant type
SHOULD do so without using client credentials, due to the native
application's inability to keep client credentials confidential.

And the article "OAuth 2 Simplified" by Aaron Parecki states:

If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used.
[...]
mobile apps must also use an OAuth flow that does not require a client secret.

Yet several service providers offering APIs built on OAuth 1 or OAuth 2, notably Twitter, require them. Despite it being trivial to pull client credentials out of an executable with tools such as strings, Twitter has been known to disable any client credentials that leak to the public. There are two workarounds, both cumbersome:

• The first, recommended by OAuth 1 spec author Dick Hardt, is to proxy all API calls through a server that the app developer operates. The API keys then never leave this server. Yet the app developer needs to find some way to recover the cost of operating this proxy server.
• The other, as recommended by Raffi Krikorian and Chris Steipp, requires each user to register with the service provider as a developer, obtain API credentials through the developer console, and enter those into the user's own copy of the application. Because providers tend to refuse to offer a means of automating application registration, each application has to include a walkthrough for registering a copy of an application and update this walkthrough whenever the service provider changes the design of the developer console. In addition, developer consoles tend to require a minimum age of 18 to rather than 13.

OpenID 2.0, an authentication protocol, did not require relying parties to obtain client credentials. It was intended that a user would paste his identifier URI into a form on the relying party's web site (or use a browser extension to autofill it), and the user would be briefly redirected to the identity provider's web site for verification. Very few identity providers required relying parties to register; the only one I could think of was PayPal.

But unlike OpenID 2.0, which was open by default, the OAuth 2-based OpenID Connect is closed by default. It requires each relying party to obtain client credentials from each identity provider's developer console, which requires O(n^2) contract executions. There's theoretically a way for a relying party to obtain client credentials automatically, called Dynamic Client Registration (dyn-reg), but to my knowledge

The requirement for client credentials in implementations of OAuth produces a couple practical problems.

OAuth 1 and OAuth 2 are unrelated protocols with similar names. The spec for each discourages servers from requiring client credentials (a client ID and client secret) in an API intended for use in an app that runs on the user's computer, such as a desktop or mobile app. As stated in section 4.6 of the OAuth 1 RFC:

In many cases, the client application will be under the control of
potentially untrusted parties. For example, if the client is a
desktop application with freely available source code or an
executable binary, an attacker may be able to download a copy for
analysis. In such cases, attackers will be able to recover the
client credentials.

Likewise section 9 of the OAuth 2 RFC:

Native applications that use the authorization code grant type
SHOULD do so without using client credentials, due to the native
application's inability to keep client credentials confidential.

And the article "OAuth 2 Simplified" by Aaron Parecki states:

If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used.
[...]
mobile apps must also use an OAuth flow that does not require a client secret.

Yet several service providers offering APIs built on OAuth 1 or OAuth 2, notably Twitter, require them. Despite it being trivial to pull client credentials out of an executable with tools such as strings, Twitter has been known to disable any client credentials that leak to the public. There are two workarounds, both cumbersome:

• The first, recommended by OAuth 1 spec author Dick Hardt, is to proxy all API calls through a server that the app developer operates. The API keys then never leave this server. Yet the app developer needs to find some way to recover the cost of operating this proxy server.
• The other, as recommended by Raffi Krikorian and Chris Steipp, requires each user to register with the service provider as a developer, obtain API credentials through the developer console, and enter those into the user's own copy of the application. Because providers tend to refuse to offer a means of automating application registration, each application has to include a walkthrough for registering a copy of an application and update this walkthrough whenever the service provider changes the design of the developer console. In addition, developer consoles tend to require a minimum age of 18 to rather than 13.

OpenID 2.0, an authentication protocol, did not require relying parties to obtain client credentials. It was intended that a user would paste his identifier URI into a form on the relying party's web site (or use a browser extension to autofill it), and the user would be briefly redirected to the identity provider's web site for verification. Very few identity providers required relying parties to register; the only one I could think of was PayPal.

But unlike OpenID 2.0, which was open by default, the OAuth 2-based OpenID Connect is closed by default. It requires each relying party to obtain client credentials from each identity provider's developer console, which requires O(n^2) contract executions. There's theoretically a way for a relying party to obtain client credentials automatically, called Dynamic Client Registration (dyn-reg), but to my knowledge

I don't think drones are covered by the existing standard, better talk to the IETF about updating it.

And let's not forget good ol' RFC 1149.

That's an interesting question... I don't think the owner of the server can revoke the certificate, only the owner of the key that was used to register it can do it.

https://tools.ietf.org/html/dr...

Also, while IPv4 is structured in a way that one can determine the netmasks and determine how it is structured, and easily deduce the number (or at least maximum number) of boxes on the subnet, that's not even possible in IPv6.

No, not really (unless you're talking about the old classful addressing system? Nobody uses that anymore.) The only reliable way to determine who owns what IP ranges is to pull out your BGP looking glass (there are a bunch of them owned by major peering providers; google "bgp looking glass".) The same thing works for IPv6, by the way.

However none of that tells you anything about the internal (RFC1918) addresses they use beyond that. I.e. are they on a 10 net? A 172.16.x net? A 192.168.x net? Only way to know is to either have physical access or some kind of inside informer.

Also I'm not sure why people say you can't NAT with IPv6. Indeed you can, there's even an official RFC for it:

https://tools.ietf.org/html/rf...

Though as you can read in the RFC, the IETF really frowns upon NAT, they only added it if your internal network MUST have privacy for whatever reason. (That is, you don't want outsiders to be able to uniquely identify the IP address of machines that are highly sensitive from a security perspective, and you certainly don't want any traffic to even be routable to them.) That address space is defined in RFC4193 and is FC00::/7, the "English" term for it being a Unique Local Unicast address.

I have a feeling it will come in demand one day for those trying to avoid e.g. ad trackers, which otherwise (in IPv6) have the ability to uniquely identify your machine without using cookies or anything, even if you e.g. hop on a Starbucks wifi. Why? Because your NIC's MAC address is (in the vast majority of cases) globally unique and shows up in the final /64 of an IPv6 address as part of NDP (the IPv6 version of ARP.)

that's not how email works. See: retry interval https://tools.ietf.org/html/rf...

Is there something about IPv6 that precludes the implementation of NAT?

Check out RFC 6296

Or, you might want to read up on Privacy Extensions before you start talking about exposing internal information which hasn't been valid since 2001. Yes, that's 15 years ago, as modern as 2001 may feel to us old guys.

The problem stems from the fact that when you go full on IPV6 and allow an internal host to transit your firewall outbound, you have exposed more than just the router's IP, but internal network information too

This isn't true though, since address randomisation arguably makes you expose less information since individual hosts will change their IP address at some random interval. This will make it pretty hard to figure out if the packet you received an hour ago was from the same host as the one just now.

Because some browser makers aren't smart enough to apply different policies to private internets from those that they apply to the public Internet. There's a reason IE implements the "Intranet zone", and other browser makers could likewise offer an option to be more lenient with addresses in 10/8, 172.16/12, and 192.168/16 prefixes.