Slashdot Mirror

So you want to hide your internal IPv6 network behind a NATv6 facade?

It's currently under discussion/development.

• IETF Draft: IPv6-to-IPv6 Network Address Translation (NAT66) (Nov 2008).
• 6net.org: IPv6 Network Architecture Protection (Jan 2005) - see 4.4 Privacy and topology hiding using IPv6 section.
• Cisco white paper: IPv6 Local Network Protection with Cisco IOS Routers and Switches - see Topology Hiding section.

Short answer: 10-1 odds says you can't, because your ISP will not offer you an IPv6 address.

Long answer:
Last I looked (which is over a year ago), the dhcp v6 specification was not even finished, and dhclient 3.1 (which is shipped with all distributions I know of) does not support it. A year ago I experimented with a client based on the DHCPv6 draft specification, Dibbler, but ISC has now released dhcp 4.0 (and 4.1) which can act as both dhcpv6 server and dhcpv6 client. However, it will not help you to switch to dhclient 4.x, because your ISP probably does not offer you an ipv6 address.

One of the advantages of IPv6 is that should not really need a DHCP client, because IPv6 has a lot better autoconfiguration than ipv4. If your (or your ISP's) router correctly advertises that it supports IPv6, current OSes (Vista, Linux, OS X) automatically set up an IPv6 address for you.

If you're really up for it, and you have a globally visible IPv4 address, you can also configure your PC to use IPv6-in-IPv4 routing, which gives you IPv6 connectivity using only your IPv4 address. Look up 6to4 routing, but don't expect any miracles. If implemented correctly, you should not (yet) notice any difference between using IPv4 and IPv6.

But the IPv6 overlords in their infinite wisdom have decided that we can't just use a 192.168.0.* equivalent, oh no. All addresses must be publicly routeable.

Others mention private alternatives; I'll summarize them here:

Site-local addressing fec0::/10 , deprecated . This is deprecated, but I don't expect these addresses to be reused for other purposes in...ever, I guess. Just pick a network address beginning with fec0: through feff: and have fun.

Unique local addressing fc00::/7 . For various reasons described elsewhere IETF would prefer all addresses be unique even if they aren't globally routable. Pick your own /48 between fc00:0:0: through fcff:ffff:ffff: and have fun. Or you can go to SixXS and have one non-authoritatively registered to you.

6to4 2002::/8 . If you have a public static IPv4 address then you automatically have a /48 starting with 2002: and then your hex-encoded IPv4 address. If not, then there should be no harm in using a private IPv4 address to make your 6to4 /48. For example, if your NAT router is 192.168.1.1 then your 6to4 subnet could be anything from 2002:c0a8:0101:0::/64 through 2002:c0a8:0101:ffff::/64 . (If you want to be sure no private packets escape to the real internet then null route 2002:/8 or 2002:c0a8:/16 at your IPv6 router if you have one.)

Which is fine - after all, there should be plenty of addresses, right? So why is there nowhere that will give me, as a private individual, an IPv6 address (officially, I mean - I'm aware of that website that generates an address that should be ok to use)?

See the SixXS link above. There is no official ULA registry, but they're the only ones I know of that are trying so far. The ULA addresses are not publicly routable, so a collision is not really a problem unless your network needs to someday merge with a colliding network. I could see that happening with major corporations, but it's not likely a problem with the typical home LAN.

Helpful tinkerer hint: Whenever you get an IPv6 range you generally get a /48, but as you assign IPv6 networks and routes to your network you will want to use /64 subnets. You don't have to, but things generally tend to make more sense that way, and default settings tend to assume that setup.

Now if you want to be on the live global IPv6 network then you can go to a tunnel broker and request a tunnel and/or subnet, and then you get a live address range. I'm in North America and use the free SixXS.

But the IPv6 overlords in their infinite wisdom have decided that we can't just use a 192.168.0.* equivalent, oh no. All addresses must be publicly routeable.

Others mention private alternatives; I'll summarize them here:

Site-local addressing fec0::/10 , deprecated . This is deprecated, but I don't expect these addresses to be reused for other purposes in...ever, I guess. Just pick a network address beginning with fec0: through feff: and have fun.

Unique local addressing fc00::/7 . For various reasons described elsewhere IETF would prefer all addresses be unique even if they aren't globally routable. Pick your own /48 between fc00:0:0: through fcff:ffff:ffff: and have fun. Or you can go to SixXS and have one non-authoritatively registered to you.

6to4 2002::/8 . If you have a public static IPv4 address then you automatically have a /48 starting with 2002: and then your hex-encoded IPv4 address. If not, then there should be no harm in using a private IPv4 address to make your 6to4 /48. For example, if your NAT router is 192.168.1.1 then your 6to4 subnet could be anything from 2002:c0a8:0101:0::/64 through 2002:c0a8:0101:ffff::/64 . (If you want to be sure no private packets escape to the real internet then null route 2002:/8 or 2002:c0a8:/16 at your IPv6 router if you have one.)

Which is fine - after all, there should be plenty of addresses, right? So why is there nowhere that will give me, as a private individual, an IPv6 address (officially, I mean - I'm aware of that website that generates an address that should be ok to use)?

See the SixXS link above. There is no official ULA registry, but they're the only ones I know of that are trying so far. The ULA addresses are not publicly routable, so a collision is not really a problem unless your network needs to someday merge with a colliding network. I could see that happening with major corporations, but it's not likely a problem with the typical home LAN.

Helpful tinkerer hint: Whenever you get an IPv6 range you generally get a /48, but as you assign IPv6 networks and routes to your network you will want to use /64 subnets. You don't have to, but things generally tend to make more sense that way, and default settings tend to assume that setup.

Now if you want to be on the live global IPv6 network then you can go to a tunnel broker and request a tunnel and/or subnet, and then you get a live address range. I'm in North America and use the free SixXS.

But the IPv6 overlords in their infinite wisdom have decided that we can't just use a 192.168.0.* equivalent, oh no. All addresses must be publicly routeable.

Others mention private alternatives; I'll summarize them here:

Site-local addressing fec0::/10 , deprecated . This is deprecated, but I don't expect these addresses to be reused for other purposes in...ever, I guess. Just pick a network address beginning with fec0: through feff: and have fun.

Unique local addressing fc00::/7 . For various reasons described elsewhere IETF would prefer all addresses be unique even if they aren't globally routable. Pick your own /48 between fc00:0:0: through fcff:ffff:ffff: and have fun. Or you can go to SixXS and have one non-authoritatively registered to you.

6to4 2002::/8 . If you have a public static IPv4 address then you automatically have a /48 starting with 2002: and then your hex-encoded IPv4 address. If not, then there should be no harm in using a private IPv4 address to make your 6to4 /48. For example, if your NAT router is 192.168.1.1 then your 6to4 subnet could be anything from 2002:c0a8:0101:0::/64 through 2002:c0a8:0101:ffff::/64 . (If you want to be sure no private packets escape to the real internet then null route 2002:/8 or 2002:c0a8:/16 at your IPv6 router if you have one.)

Which is fine - after all, there should be plenty of addresses, right? So why is there nowhere that will give me, as a private individual, an IPv6 address (officially, I mean - I'm aware of that website that generates an address that should be ok to use)?

See the SixXS link above. There is no official ULA registry, but they're the only ones I know of that are trying so far. The ULA addresses are not publicly routable, so a collision is not really a problem unless your network needs to someday merge with a colliding network. I could see that happening with major corporations, but it's not likely a problem with the typical home LAN.

Helpful tinkerer hint: Whenever you get an IPv6 range you generally get a /48, but as you assign IPv6 networks and routes to your network you will want to use /64 subnets. You don't have to, but things generally tend to make more sense that way, and default settings tend to assume that setup.

Now if you want to be on the live global IPv6 network then you can go to a tunnel broker and request a tunnel and/or subnet, and then you get a live address range. I'm in North America and use the free SixXS.

But the IPv6 overlords in their infinite wisdom have decided that we can't just use a 192.168.0.* equivalent, oh no. All addresses must be publicly routeable.

Others mention private alternatives; I'll summarize them here:

Site-local addressing fec0::/10 , deprecated . This is deprecated, but I don't expect these addresses to be reused for other purposes in...ever, I guess. Just pick a network address beginning with fec0: through feff: and have fun.

Unique local addressing fc00::/7 . For various reasons described elsewhere IETF would prefer all addresses be unique even if they aren't globally routable. Pick your own /48 between fc00:0:0: through fcff:ffff:ffff: and have fun. Or you can go to SixXS and have one non-authoritatively registered to you.

6to4 2002::/8 . If you have a public static IPv4 address then you automatically have a /48 starting with 2002: and then your hex-encoded IPv4 address. If not, then there should be no harm in using a private IPv4 address to make your 6to4 /48. For example, if your NAT router is 192.168.1.1 then your 6to4 subnet could be anything from 2002:c0a8:0101:0::/64 through 2002:c0a8:0101:ffff::/64 . (If you want to be sure no private packets escape to the real internet then null route 2002:/8 or 2002:c0a8:/16 at your IPv6 router if you have one.)

Which is fine - after all, there should be plenty of addresses, right? So why is there nowhere that will give me, as a private individual, an IPv6 address (officially, I mean - I'm aware of that website that generates an address that should be ok to use)?

See the SixXS link above. There is no official ULA registry, but they're the only ones I know of that are trying so far. The ULA addresses are not publicly routable, so a collision is not really a problem unless your network needs to someday merge with a colliding network. I could see that happening with major corporations, but it's not likely a problem with the typical home LAN.

Helpful tinkerer hint: Whenever you get an IPv6 range you generally get a /48, but as you assign IPv6 networks and routes to your network you will want to use /64 subnets. You don't have to, but things generally tend to make more sense that way, and default settings tend to assume that setup.

Now if you want to be on the live global IPv6 network then you can go to a tunnel broker and request a tunnel and/or subnet, and then you get a live address range. I'm in North America and use the free SixXS.

There is work on that arena. Basically, when HTTPBis WG was being chartered, during the BOF discussion it was acknowledged that authentication is too big can of worms to simply be considered a "revision", thus it's going to happen in a separate WG. In November, a BOF for OAuth was held...have to see if anything comes out of it.

There is work on that arena. Basically, when HTTPBis WG was being chartered, during the BOF discussion it was acknowledged that authentication is too big can of worms to simply be considered a "revision", thus it's going to happen in a separate WG. In November, a BOF for OAuth was held...have to see if anything comes out of it.

There is work on that arena. Basically, when HTTPBis WG was being chartered, during the BOF discussion it was acknowledged that authentication is too big can of worms to simply be considered a "revision", thus it's going to happen in a separate WG. In November, a BOF for OAuth was held...have to see if anything comes out of it.

If CmdrTaco is able to make these posts, he clearly has Internet access, so the obvious answer is RFC 3251, http://tools.ietf.org/html/rfc3251.

This context might be used to create, for example, a "shopping cart", in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user's previous reading affects which offerings are presented. -- http://tools.ietf.org/html/rfc2109

Magic cookies were already used in computing when Lou Montulli had the idea of using them in Web communications in June 1994.[28] At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for a customer. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart. -- http://en.wikipedia.org/wiki/Http_cookie#History

"It was designed so that anybody could be a client and anybody could be a server."

This is precisely why we deployed NAT and stateful filters everywhere in the Internet... to put a STOP to such nonsense. If the gods of the Internet had meant for just anyone to be able to run a server that could be reachable from anywhere, then they would have invented an end-to-end network security protocol for communicating between unauthenticated peers.

You must be referring to this: http://tools.ietf.org/html/rfc1149. Well you might be able to block them with deep pigeon inspection. If not a man on the firewall with a shotgun ("Media Sentry") will do the job easily.

After that, maybe they can start suing carrier pigeons. You know you can't trust *those* little bastards... just look at New York!

What's even better there is even a protocol for such a method! http://tools.ietf.org/html/rfc1149

Of course that requires that the use of the evil bit be mandated by law.

Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
http://www.ietf.org/rfc/rfc2324.txt

In other words, the Hyper Text Coffee Pot Control Protocol?

Once the mobile phones are on v6, you're going to want...

No, your phone will tunnel IPv4 over IPv6 to get out of the mobile network through a NAT gateway. This is the Dual-stack Lite architecture.

Git GPG signing, and KeyNote.

http://www1.cs.columbia.edu/~angelos/keynote.html

read the article: in it, you will see links to the fact that Git already has GPG signing on tags.

also, you will see references to KeyNote, aka RFC 2704. for convenience, i'm cut/pasting the top bit, here:

"Trust management, introduced in the PolicyMaker system [BFL96], is a unified approach to specifying and interpreting security policies, credentials, and relationships; it allows direct authorization of security-critical actions. A trust-management system provides standard, general-purpose mechanisms for specifying application security policies and credentials. Trust-management credentials describe a specific delegation of trust and subsume the role of public key certificates; unlike traditional certificates, which bind keys to names, credentials can bind keys directly to the authorization to perform specific tasks."

Use a GUID instead. There is an RFC http://www.ietf.org/rfc/rfc4122.txt and its the same algorithm Microsoft uses. It's pretty much guaranteed to be unique if everyone follows the same process. They're used everywhere.

I suggest you read RFC 5157: IPv6 Implications for Network Scanning. Do not think that just because a v6 end-user network has 2^64 addresses that you're safe.

The truth is that the BitTorrent folks are not playing ball with ISPs.

The very same people driving the development of uTP at BitTorrent Inc. are also pretty active in IETF, both pushing their protocol for standardization (guess who's chairing the LEDBAT working group) and discussing with ISPs ways to leverage topology information for optimizing peer selection (ALTO WG). They are a very imporant player in today's Internet and it seems they are not afraid of playing ball with the big guys.

The truth is that the BitTorrent folks are not playing ball with ISPs.

The very same people driving the development of uTP at BitTorrent Inc. are also pretty active in IETF, both pushing their protocol for standardization (guess who's chairing the LEDBAT working group) and discussing with ISPs ways to leverage topology information for optimizing peer selection (ALTO WG). They are a very imporant player in today's Internet and it seems they are not afraid of playing ball with the big guys.

Am I mistaken in believing that UDP has been around for 24 years?

p2p applications should switch to SCTP.

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

Both BitTorrent and Comcast are working in the IETF ALTO working group, which is intended to improve the use of bandwidth and other resources by P2P.

Having been in these sessions, it is clear to me that BitTorrent has no interest in melting down the Internet and is well aware of the implications of what they are doing. Note that if worse comes to worse, UDP can be blocked too.

Section 2.5.5.2 of RFC-4291: IP Version 6 Addressing Architecture describes what in IPv4 terms one might call a super-network prefix that does exactly that: map the existing Internet onto an infinitesimal corner of the huge IPv6 address space.

I love beating this dead horse: OpenPGP is the one scheme that authentication right, and DNS is Yet Another great example where OpenPGP should be used instead of the obsolete X.509.

Why would I trust the feds as an introducer? We already know that they do attempt MitMs sometimes, and there's already a history of DNS abuses ordered by presumably well-intentioned courts. But even if this organization had a good reputation, it's just plain dumb to put all your eggs in one basket. There should be provisions multiple certifiers of an identity, so that users decide who is trustworthy and who isn't.

If the feds are going to sign, I hope they use an OpenPGP signature (which apparently the spec allows!), but I somehow doubt they would want to lend any legitimacy to a scheme that actually lets people authenticate identities, instead of the one intended to create monopolies and single points of failure.

I have no problem with the feds helping out on this, but we shouldn't completely trust them, and we have the technology so that we don't have to. PRZ gave it to us a couple decades ago.

Thanks, that's really what I meant to ask. I found this thread on the IETF namedroppers list:

Re: Some notes on DNSCurve

Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.

I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.

DNSSEC is currently deployed live in multiple countries, .gov and .arpa are now signed (but only for testing purposes at the moment). Yes, the number of DNSSEC hosts is only in the low 5 digits, but that's still way more then DNSCurve. 11 vendors have DNSSEC compatible DNS servers, which I believe is 11 more then DNSCurve. DNSCurve would have to be significantly better in order to garner support at this stage, and I'm not seeing it.

DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.

DNSSEC is not.

This is a valid point. Only about 1/4 of recently tested home routers allowed DNSSEC traffic. It's also a problem that is trivial to solve in the long term. Once DNSSEC is deployed, routers will follow. Realistically however, all home routers will be DNSSEC capable before Windows can deal with the DNSSEC data. DNSSEC can still make policy decisions at the ISPs recursive resolver before that time however.

DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.

DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.

Strange that the link you send doesn't mention DOS attacks at all.
DNSSEC requires 0 more compute power, but does increase network traffic. DNSSEC can be extended to use ECC instead of RSA to reduce the network overhead, with NO computational overhead.

I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.

I don't think you know what you're talking about.

Oh? Read RFC 4034, then get back to me. Elliptic curve crypto already has a specified algorithm type, listed in appendix A.1. Unfortunately, the exact format hasnt been standardized yet. There are 245 more unassigned crypto specifications available for future use, I'd call that extensible.

DNSCurve does have some good ideas since it was designed to be easy to deploy, while DNSSEC deployment frankly sucks. DNSSEC is designed by committee,and it shows. On the other hand, it has many future-proof features like the ability to upgrade the crypto used in case RSA, DSA, ECC, or any other scheme falls like a house of cards, or simply need to be made longer in order to survive attacks.

If DNSCurve was proposed 5 years ago, it would have had a good chance of becoming the standard. Now, frankly, it's too late. Most of the major DNS servers support DNSSEC, .gov is currently signed and all US government sites must use DNSSEC by next year, the root servers and reverse .arpa domains have DNSSEC testbeds, Comcast has deployed their dnssec test servers. The political problems of who holds the root keys will be solved soon and DNSSEC will be live. Whether it takes off or not is a question for the market to decide.

you need to work on your reading comprehension skills.

DNSSEC exists plain and simple. it's already been deployed for a lot of domains and root nameservers. just because there are difficulties hampering its widespread adoption doesn't mean it doesn't exist. that's like saying IPv6 doesn't exist because it's still suffering from a lack of widespread adoption.

none of the factors preventing more widespread deployment are problems that need "solving." in fact, they're more social/political problems than they are technical problems. so the "solution" to these problems is simply to persuade/pressure/coerce DNS servers to adopt DNSSEC, which is what IETF is debating about.

1. backward-compatibility may be difficult to maintain, but this is a transitional problem, and it's not a real technical barrier to adoption at this point. BIND 9.3 (several older versions are compatible as well) officially supports DNSSEC, so does NSD, and Nominum's ANS and CNS. the fact of the matter is, there are tons of domains already using DNSSEC without issue.
2. the zone enumeration issue has already been solved with NSEC3 (RFC 5155) released in March--which you'd already know if you'd read the rest of that Wiki article.
3. this is a logistical problem that every new technology/protocol/standard faces. the main issue here is the last-mover advantage. nobody wants to be the first to adopt a new standard when there's no financial incentive to do so. but somebody has to go first. and at this point there is already a wide variety of software, prototype systems & tools available for implementing DNSSEC with little to no risk involved.
4. this is purely a political issue, and it has more to do with the U.S.'s monopolistic control over the DNS system than DNSSEC. perhaps if ICANN acted more impartially instead of getting in bed with Verisign and other commercial corporations we wouldn't have political BS hindering technological progress. in any case, this is an ICANN problem and could be solved by organizational reforms to make ICANN operate with more transparency and give other nations a voice in domain name management.
5. the perception of DNSSEC being too complex or difficult to adopt is just that--a problem with public perception. IETF is working on resolving this problem through education and training, which are on their deployment road map. there's a lot of good free resources out there to help ease others through this transitions and dispel false perceptions.

Stupid sensationalism.

You can right now use draft-vixie-dnsex-dns0x20 to protect against the kaminsky bug. This option is already available in the unbound nameserver.

Talking about totally talking out of context. Fools!

If IETF does something to mitigate, the unbelievers scream "see we dont need dnssec"

If IETF does not do something, the unbelievers scream "you're blackmailing us into dnssec"

Stop whining and put your foot where your mouth is.

Apparently iiNet didn't enforce the evil bit

They deserved to be sued.

Well, according to the "Font of all (quick) wisdom", the "official" name for this is IntetPlaNet which is backed in part by the (wait for it) InterPlanetary Internet SIG (that's Special Interest Group to you youngins).

They seem to have a whole bunch of papers on their website which might be easier to digest than an RFC, but the easiest way to find the RFC is to just google for "RFC DTN".

Delay-Tolerant Networking Architecture

Sadly it just defines the DTN architecture and is much less enjoyable than rfc2549 (IP over Avian Carriers with Quality of Service).

Well, according to the "Font of all (quick) wisdom", the "official" name for this is IntetPlaNet which is backed in part by the (wait for it) InterPlanetary Internet SIG (that's Special Interest Group to you youngins).

They seem to have a whole bunch of papers on their website which might be easier to digest than an RFC, but the easiest way to find the RFC is to just google for "RFC DTN".

Delay-Tolerant Networking Architecture

Sadly it just defines the DTN architecture and is much less enjoyable than rfc2549 (IP over Avian Carriers with Quality of Service).

With space you have no internet (i.e. road) and TTLs are too high to use the same technology we use here.

You might think so, but it *has* been shown to work. I mean, don't tell me you never heard of the pigeon protocol?

I'm thinking that's a server-side error, so it should actually be 563 No More Kitten if you're following RFC 2616 correctly.

Oh indeed, not all messages will be sent or received encrypted; but Exchange, SendMail et al support it out of the box. My server talks to gmail encrypted, even hotmail.

It's still SMTP, but the first operation opens a TLS channel; it works in the same way that HTTPS does; it's still HTTP under the hood, just wrapped. The RFC is here if you want to have a read.

Perhaps someone could point D-Link at http://tools.ietf.org/id/draft-bellis-dnsext-dnsproxy-00.txt ?

Start by taking a look at RFC 2827/BCP 38, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing."

Sadly, ten years since publication we're still not there, which would seem to suggest (GP's wishful thinking notwithstanding) that you not hold your breath.

what's so wrong with wanting original IP's?

For one, you could only use them to communicate with 30 other hosts.

Thank you, I'm here all week. Try the v6 ;)

See http://www.ietf.org/rfc/rfc1.txt; destaddr is five bits; 00000 is unused [says Peter Salus, I didn't read the whole rfc and I don't remember this bit].

If you don't use computers, how did you post on /.?

Typewriter.

Then IP over Avian Carriers

Oh, FFS, get with the times. This was solved years ago. Most torrent clients set this by default, and it's been working pretty well to prioritize Linux ISOs over movies for the last five years now. I'm actually kind of surprised that this tool uses hash checking instead, but whatever, ISPs are clearly morons.

How many websites around now are pre November 1995 when the HTML2.0 standard was released.

"HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML)."

A similar issue arises with providers who place their subscribers behind twice-NAT on addresses they aren't stealing from somebody else. The free Wi-Fi service on the commuter shuttles provided by my employer is operated by an ISP that does this. It mostly works, except when it falls over and dies.

Why would you do this? So that you can conserve your own IP address space without having to worry about address realm conflicts between your subscribers and the services you are providing to them. Why does this suck? As you know, Bob, it's because applications quite naturally assume that any IPv4 address outside the RFC 1918 ranges are global scope. (That's because— you know— they are.)

So these applications assume they can stop attempting their NAT traversal strategy because they think they've fixed the public address properly when they really haven't.

I do so dearly love people who refuse to learn the lessons of RFC 3424.

Solution: http://tools.ietf.org/html/rfc4193

Right now, they charge an additional fee for each DHCP lease you consume. Since DHCP6 has an IPv6 prefix delegation option, you can expect that your home gateway will get at least a /64, and probably a /56 or better (depending on the outcome of discussions in IETF around this active Internet Draft currently in the RFC Editor Queue.

"When every lightbulb has an IP address, the vast address range of IPv6 sounds like a pretty good idea."

Sigh. It would be nice of the know-nothings who keep mocking IPv6 for its 128-bit address space would read RFC 4941, and take the time to comprehend what it means, before spouting off.

Haha, that's a perfect combination of Roald Dahl's short story The Great Automatic Grammatizator and RFC 439.