back to article Slow IPv6 adoption is a GOOD THING as IETF plans privacy boost

The glacial pace of the worldwide IPv6 rollout might cause hand-wringing among 'net boffins, but at least it's leaving time for engineers to pry around for possible problems before the whole world's on the protocol. Since the transition is still at an early stage, it's easy to forget that IPv6 has, as a document, been around …

COMMENTS

This topic is closed for new posts.

Page:

What IPV6 really needs

Is the ability to NAT. Seriously. I'd like to plop one machine behind a dual-homed firewall and just use the firewall to block unwelcome traffic. Much more time saving than going to the machine one by one and setting up a handful of allow rules by hand (plus, leaving the machine connected to the net is still prone to IPV6 spoofing and MAC spoofing even with said rules in place. With a dual-homed firewall I can tell the firewall to shoot down any connect requests coming from the public facing interface, since the computers will only be making requests from the private facing interface and thus any request from the public interface is a spoof).

11
20
Silver badge

Re: What IPV6 really needs

I believe the designers of IPv6 were trying to avoid NAT. NAT breaks that whole ethos of the Internet that any node can talk to any node. Some protocols like FTP* and SIP break by default through NATs. They need extensions/workarounds to support devices through NAT.

* Yes, I know FTP is totally insecure, but it's still used as a means to allow clients to upload large files.

10
3
Silver badge

Re: What IPV6 really needs

I don't think you need NAT to implement a firewall. Your firewall can still shoot down those incoming connection request packets you want shot down, even if it does not do address translation.

18
2

Re: What IPV6 really needs

linux already hast ipv6 nat. i know i am going to use it when i'm forced to deploy this ugly protocol.

4
10
Silver badge

"ethos of the Internet that any node can talk to any node"

Any node being able to talk to any node is a disaster waiting to happen for the security and privacy of home users.

They have a firewall protecting them today, but don't know it. With IPv6, a firewall needs to be implemented to protect them, but leaves the real addresses of each device exposed - which is the whole point of this worry about tracking you.

Today, if I have a tablet and I browse the network from home, it shows up with my home's IP. Maybe that doesn't help much, since most houses have a single digit number of people sharing that IP. Move to a coffee shop, to a small business, to a large enterprise, and the traffic you generate is progressively more hidden amongst all the rest (assuming you clean up cookies, etc.)

Unless you use IPv6. Worst case, you have a single IP address linked to you everywhere, but thankfully the IETF wants to fix that issue. What if in that corporate environment, for ease of tracking, they assign your device an IP address once and it keeps it forever, so your traffic will now be easy to pick out of the 10,000 other devices even if it is intercepted 1000 miles away?

NAT definitely needs to stay, even if some don't like it, because it throws a few nails in the road for the NSA. It won't stop them if they're targeting you specifically, but it will damn sure help make their job a lot harder if they want to hoover up data on everyone!

17
11
Silver badge

Re: What IPV6 really needs

>NAT breaks that whole ethos of the Internet that any node can talk to any node.

So does IPv6!

The problems with FTP and other early DARPA protocols have been know for decades, it is pure laziness (by the IETF) that they haven't been amended. Likewise new protocols that were defined after NAT should either work with NAT by design or have good reason why they can only work in particular network topologies.

To me this initiative seems to be an admission by the IETF that IPv6, as originally defined, wasn't properly thought through. I wonder whether another contributory reason is that relevant people in the IETF have moved on...

5
7

Re: What IPV6 really needs

NAT is a pain. In the simple world of fixed identifiers, it is trivial to set up your firewall to block all incoming connects to your IPv6 allocation and then allow individual ports/addresses, similar to how you do port forwarding through NAT. It has the added advantage that you can then have multiple devices with port 80 accessible because they'll all have a different address. Just as with IPv4 and NAT, it is necessary for the server machines to have a fixed address.

For the client machines, it would be nice to have something similar to DDNS so that on the local network, a client can remain known to the sysadmin if it rolls its address - correlate local MAC address with given IP address.

The only time I'd like NAT is to globally change prefix, so that if I've got multiple connections to the internet via different ISPs, I can have servers that will cope with incoming requests on any interface and have them respond with the correct prefix on the correct interface. Having a single firewall/router to do all of that would be nice.

9
4

Re: What IPV6 really needs

I have a 6in4 IPv6 tunnel running on my home network. My router (Asus RT-N66U with Merlin firmware) is running an IPv6 firewall which automatically drops any unsolicited incoming traffic. I can set rules in the firewall to permit traffic to individual hosts (e.g. I could have multiple hosts all with their own port 80 services). All my hosts retain end-to-end IPv6 routing without any of that NAT nonsense.

7
1

Re: What IPV6 really needs

You are way off the bat here (sorry but it's true). NAT and firewalling are not the same thing, and a lot of people just genuinely don't seem to get this. The lack of encouraged/standardised NAT in IPv6 doesn't suddenly mean firewalls suddenly stop working.

You would not need to go around to each machine on your local network segment and set individual firewall rules up (although depending on OS a lot are on by default now) anymore than you would on IPv4 - the traffic still comes into your network via a router, and this is still where the firewall action happens. The only difference is that with v4 your local IP addresses are all non-routable and translated into one or more public IPs at this point too - this is not a security feature, it was designed so everyone could use the same address range at home, thus negating the need to hand out public IPs for every device and exhaust them even faster.

IPv6 devices being publicly routable does not suddenly mean anyone can log into them/ping them/whatever else, when a proper firewall is in place. Firewall != NAT.

10
1
Gold badge

Re: What IPV6 really needs

"The problems with FTP and other early DARPA protocols have been know for decades, it is pure laziness (by the IETF) that they haven't been amended."

Umm, FTP *was* amended -- http://en.wikipedia.org/wiki/File_Transfer_Protocol#NAT_and_firewall_traversal

3
0
Boffin

NO WE DO NOT NEED NAT

NAT is an abomination in the world of IP and should be thrown away. It only exists because we were running out of IPv4 addys and needed a quick fix while IPv6 came out. Of course, IPv6 itself is now 15+ years late in being globally deployed so NAT has become a "given" everywhere. But it has damaged the network mindset of at least one IT generation, which now thinks that NAT is extra security. It isn't.

The reason most people think NAT adds security is because every NAT device is also running a firewall that blocks incoming requests as well. But the added "block by default" security can be implemented even without NAT. This myth should be put out to pasture and the real internet concept of "every node reachable in the net" should be reinstated. Sure, for all means you should have firewalls to block unwanted access to servers in the backend, and servers that don't need internet access should get only private IPv6 addys. But no more NAT voodoo tricks please!

4
4
Alert

Re: NO WE DO NOT NEED NAT

The RFC1918 address blocks are why we need NAT; and NAT for IPv6 makes sense in the equivalent context (link- and network-local addresses). Whether you use it is entirely up to you.

3
1
Boffin

Re: NO WE DO NOT NEED NAT

But the RFC1918 addys were needed … for IPv4. IPv6 added the link-local and site-local addresses, in addition to the global-scope addys. You can, and should, use the local addys for most internal networks stuff, while the global ones are supposed to be used only for internet-bound traffic. Even Microsoft has got that right, with Windows stuff using link-local whenever possible.

I'm not quite sure why site-local was deprecated, because that was basically RFC1918 for IPv6. But something similar was drafted for private addresses anyway, so it isn't like the need isn't covered already.

0
0
Silver badge

RFC 4941

Saying that there are only MAC-based IPv6 addresses isn't correct. RFC 4941 describes temporary IPv6 addresses. These have the nice property that they can change over the lifetime of the devices network connection. This is ideal for clients. (My work desktop is currently showing 8 temporary IPv6 addresses.)

For servers at our place, we are encouraged to statically assign addresses which are different to the hosts MAC, to facilitate moving services between hosts.

15
0

Re: RFC 4941

This is also known as "Privacy Extensions", and as you say: it does exactly as expected.

8
0

Re: RFC 4941

It's also irritating - I ssh from my desktop machine to other machines on the network, often leaving a terminal open for monitoring. The desktop machine uses a privacy address to do this, which is fair enough. What is annoying is that at some point, the system decides it's had enough of that address and deletes it, causing connections which are still using it to be dumped. Either I've missed an obscure setting that will stop this happening or there's something they need to sort out. I can see why there's a need to ultimately dump the resources associated with the address because over time there could be one of these per address used and the system would run out of memory, but every few days I find things disconnect for no good reason. I could force IPv4 connections but where's the fun in that?

2
0

Re: RFC 4941

While your computer is using privacy extensions it should in addition still maintain a MAC-derived address (at least, it does on Windows - I don't know if the same is true on Linux or OSX). Can you force your SSH client to use this interface rather than the temporary ones?

0
0
Anonymous Coward

SLAAC is the problem, not the solution

DHCP is a solid, reliable, battle-tested protocol which didn't need replacing. Unfortunately the muppets at the IETF with no operational experience decided it would be fun to design a new and unnecessary way of auto-configuring global IP addresses; and they are too proud to admit they made a mistake.

SLAAC is fine for autoconfiguration of link-local addresses, and because these are not globally routable there are no privacy concerns. But DHCP gives centralised control and logging, as well as auto-configuration of other parameters like DNS servers, NTP servers, diskless booting etc.

So ignore this RFC and:

* disable SLAAC on all router interfaces (1)

* turn on stateful DHCPv6 - which works exactly the same as IPv4 DHCP

* relax

(although for security you should also disable SLAAC on all clients as well)

(1) Cisco:

interface Foo

ipv6 nd prefix default no-advertise

ipv6 nd ra suppress [all] <-- only in very recent IOS

9
1
Boffin

Re: SLAAC is the problem, not the solution

I remember a specific command I could use in Solaris 10 to set up my own preferred device ID when using SLAAC. Can't remember the exact command but it was something like

ifconfig en0 inet6 token ::1337:b00b:cafe/64

you had to put something akin to this on the hostname6 file for it to persist across reboots. The end result was that even using SLAAC you would get a "static" IPv6 addy with the added benefit of having all the IPv6 routing configured automatically.

Sadly, I haven't seen if this is possible on Linux.

0
0
Vic

Re: SLAAC is the problem, not the solution

> Sadly, I haven't seen if this is possible on Linux.

Trivially.

ifconfig works in much the same way. You can also add and delete ipv6 addresses on running interfaces.

Making an address permanent can be performed by putting the relevant directives in /etc/sysconfig/network-scripts/ifcfg-ethX (or similar for other variants). You can set a single address/prefix (with /64 being the default if not specified) with the IPV6ADDR directive, and you can add extra addresses with IPV6ADDR_SECONDARIES .

Vic.

0
0
Silver badge

Ironically...

one of the reasons it took such a long time to nail down IPv6 was the amount of effort that went in to the mobility problem - making sure your address (and the traffic routed to it) followed you round as you moved.

Of course, the address prefix assigned by your ISP will pretty much identify you (at home), the prerfix assigned by your mobile ISP will pretty much identify you (on the move, along with your location) and the address assigned by your workplace will pretty much identify you when you arrive. This is pretty much a problem the NSA have already cracked with IPv4, so the only way to avoid these being correlated is never to access the same third party service using the same credentials from a different location.

Nothing here to change my assumption that by the time IPv6 arrives at an endpoint near me I'll be able to derive my address from a quasiperfect number.

2
0

NAT has to go, yes

I think, contrary to some, NAT has to go.

The problem is, NAT evolved from a terrible burden due to address exhaustion, to a security measure hiding internal hosts from the internet. This was NOT the intend !

As a result, yes, endpoint security has become freaking terrible, and removing NAT will expose the weak internal hosts.

However, in the grand scheme of things, the end game should really be:

- fully meshed network (all hosts communicated with all hosts of da net)

- security ensured by updated V6 firewalls (I'm sure we have already V6 FW that can stack rules on V6 nets and V6 hosts in the relevant manner, without having as many rules as hosts to be written)

Back on topic, indeed, another thing of V6 is each hosts may have a unique and persistent address. This RFC should address it. Provided each host cannot be uniquely identified by other endpoint problems (browser for example).

Still many years of work ...

7
9
Anonymous Coward

Re: NAT has to go, yes

As a result, yes, endpoint security has become freaking terrible, and removing NAT will expose the weak internal hosts.

And there is one of the biggest problems with IPv6, just imagine the 1990s on IPv6, all them Windows hosts directly addressable from anywhere on the internet... imagine the size of the botnet you could build.

Although I should point out that my particular love of IPv6 is the "YOU WILL HAVE AN IPV6 ADDRESS ASSIGNED TO EVERY INTREFACE" directive.

It's not like I might want to decide which interfaces are used for what?

It's not like I might want to use protocols other than IP?

I wonder how many systems there are in the world running IPv6 addresses on interfaces which have absolutely no protection on them at all?

What's that you say... it's only a LLA address and can't be routed across the internet? So you mean I only have to worry about all the others hosts in the datacenter being compromised and used as a jump off point to get to my server?

IPv6 is a fucking mess, designed by people who gave absolutely no consideration to security or privacy. People who were unable to see the positive (if unintended) consequences of how IPv4 had been put to use in the real world. There just aren't words suitable for publishing anywhere which can convey my absolute contempt for it.

20
6

Re: NAT has to go, no..

NAT has the advantage that only the NAT gateway knows the addresses and how many of them there are, of packet sources it stands to masquerade for.

Sure,a stateful proxy does the same, but that too is in a sense NAT..

The issue here is that we have moved on from 'running out of IP addresses' and from 'every device can communicate with every other device;' to 'how can we ensure that we only communicate with and allow communication from, such devices as we can trust?'.

I.e. the game is less about building an open Internet, than using an open internet to carry secure private traffic.

And here the problem is that right now we can obfuscate and/or encrypt the packet payload, but we can't obfuscate or encrypt the the routing header information.

There's a lot of cash waiting for someone who dreams up a way..

With radio comms WWII encryptions served to deal with content, and destinations was largely unknown.. today all comms pass through backbones and source and destinations are clearly marked on each packet to enable routing to actually work.

I can envisage perhaps a 'random routing' algorithm where packets for the first 5 hops get routed to almost anywhere on a totally arbitrary basis before vectoring in on their destinations, which might help those not monitoring EVERY path.

But still they must carry at least a destination in order to arrive. They dont need to carry a source mind you, if the host at the other end is stateful. Return address could be in some encrypted payload.

So this is my half way house.

DNS contains in addition to destination address, a public key.

The IP packet header contains only the destination address in clear and a return address encrypted with that public key and the senders own public key.

Each end of the link now knows each others public keys. IN the middle you have encrypted traffic to known destinations but from unknown (except by traffic analysis) sources.

I am not sure its possible to do better than that over any routed mesh network.

In the limit the ideal security would be all the internet traffic in the world available to everyone, on the basis that you would pick out 'your ' packets because they had some arbitrary and rather large and constantly changing number in the headers..

15
0
Silver badge

Re: NAT has to go, no..

Brilliant idea *thumbs up* (Icons don't work from this phone)

1
0
Silver badge

Re: NAT has to go, yes

On dial in they, generally, were directly on the internet, without a firewall or NAT...

0
0
Silver badge

Re: NAT has to go, yes

@Git

I take it you don't have a mobile phone, or you have at least programmed it to change its IMEI, SIM number and telephone number every time it moves between a cell tower?

3
1
Silver badge

Re: NAT has to go, yes

We used NAT + Firewall + Proxy server as single access point to Dial up 1994 to 2005. Couldn't get Broadband till then.

0
0
Gold badge

Re: NAT has to go, yes

"And there is one of the biggest problems with IPv6, just imagine the 1990s on IPv6, all them Windows hosts directly addressable from anywhere on the internet... imagine the size of the botnet you could build."

A reachable address only helps you build a botnet if you have an exploit to throw at it. Also, in practice just about every Windows machine is reachable "in reverse" because you can persuade the end-user to click on a link and tunnel through their NAT on your behalf. I think you'll find securing (or simply not running) servers is considerably easier than teaching end-users not to click on dodgy links whilst running as admin, so it isn't clear to me that universal addressability actually makes things much worse than they are at present.

"Although I should point out that my particular love of IPv6 is the "YOU WILL HAVE AN IPV6 ADDRESS ASSIGNED TO EVERY INTREFACE" directive."

Got a reference for that? On second thoughts, don't bother. All of the systems I'm familiar with are quite happy to let you enable or disable IPv6 on different interfaces just as you please. Indeed, it is hard to see how a router with an IPv6-capable subnet on one side and a legacy subnet on the other could possibly work otherwise.

"IPv6 is a fucking mess, designed by people who gave absolutely no consideration to security or privacy."

That would be a "mess" that seems to work fine for millions of people, including some of the world's largest web organisations, and "no consideration" apart from making IPsec support compulsory. Maybe it is your understanding of IPv6 that is a mess.

8
2
Silver badge

Re: NAT has to go, yes

"The problem is, NAT evolved from a terrible burden due to address exhaustion, to a security measure hiding internal hosts from the internet."

Not entirely true!!!!

It is convenient to overlook what was happening in the world. The mid to late 80's saw a massive increase in the number of LAN's based around minicomputer systems running a Unix distribution, which generally included an Ethernet board (with 10Base5 AUI and/or 10Base2 interfaces) and TCP/IP for free. Naturally for many companies these were totally private networks hence were set up using either arbitary IP address range(s) or the address ranges reserved for private networks - very few actually bothered to request an IP address range from the IETF's predecessor. Roll forward when companies merged or increasingly wanted to directly communicate with each other and the scene was set for problems, particularly in the early 90's with the spread of the WWW and the rise of the PC-based office LAN.

Network address translation provided a very useful way of easily permitting systems on these private networks on to the public WWW/Internet, without requiring every business to apply for a private IP address range and renumber their networks etc. Hence why RFC 1631 was seized on as a way to solve a number of looming problems. I think the acknowledgements section of this RFC allude to the other thinking and work going on around the question does an organisation actually need to use public IP addresses internally.

As an aside: I've not paid too much attention to the allocation of IPv6 addresses, but one of the issues with IPv4 was that the internet community was too liberal in its allocations, so some organisations who got in early got very large public address spaces which they didn't really need, hence why IP address exhaustion (through insufficient subnets remaining for the number of organisations needing to connect) became an issue several years before it became the problem it is today (insufficient IP addresses for all end points on the public network).

4
0
Anonymous Coward

Re: NAT has to go, yes

A reachable address only helps you build a botnet if you have an exploit to throw at it.

Just as well there's never been any exploits which could be thrown at network attached hosts then isn't it... oh hang on?

Also, in practice just about every Windows machine is reachable "in reverse" because you can persuade the end-user to click on a link and tunnel through their NAT on your behalf.

And you think taking the idiot users out of the loop and making that step unnecessary will make it all better somehow, when the next exploit comes along? Really?

I must admit I have on the odd rare occassion used the "only problem with computers is the users" joke myself, but I did hope everyone present got that it was a joke...

I think you'll find securing (or simply not running) servers is considerably easier than teaching end-users not to click on dodgy links whilst running as admin, so it isn't clear to me that universal addressability actually makes things much worse than they are at present.

I'm sorry is that a deliberate troll post? Or are you seriously saying that you can't see the difference in providing black hats with more targets, many of which will be run/managed by end users who know as much about system security as the last baby you held?

Got a reference for that?

I was going to provide you with a reference where I asked which fucking idiot decided that ipv6 in linux should auto assign LLA addresses to every network interface in the system, many of which were then being brought up without any kind of packet filtering. The one where I was told that was as per the design, and I should just shut the fuck up... but as you don't want it I won't.

That would be a "mess" that seems to work fine for millions of people, including some of the world's largest web organisations, and "no consideration" apart from making IPsec support compulsory. Maybe it is your understanding of IPv6 that is a mess.

Better hope not I've got real IPv6 systems in real big organisations... but then my comments about IPv6 couldn't possibly have come from actual experience... could they?

3
0
Anonymous Coward

Re: NAT has to go, yes

@Git

I take it you don't have a mobile phone, or you have at least programmed it to change its IMEI, SIM number and telephone number every time it moves between a cell tower?

I'm guessing that's me?

I take you have given in then, and taken the position that because they cell network operators can track you, you shouldn't expect/demand that others provide you with a better untrackable service?

Good for you, I hope you enjoy the peace and quiet you'll no doubt get from the position you've taken. Do allow us others who haven't given in yet our leaway though, you know to point out the flaws in the wonderful latest and greatest technology which provides an even easier way for everyone to be tracked even more than they are already. There's a good chap.

2
0
Silver badge

Re: NAT has to go, no..

@itzman: "DNS contains in addition to destination address, a public key."

Unfortunately, you do a DNS query and you do not really know whose public key you got with the address...

2
0

Re: NAT has to go, yes

@Roland6,

I agree 100%, NAT has indeed its use for mergers with companies that just ... didn't bother.

This will unfortunately survive IPV4 and will of course be here in IPV6.

I was more speaking of consumer NAT used in every day box/router. Point noted.

1
0

Re: NAT has to go, yes

"IPv6 is a fucking mess, designed by people who gave absolutely no consideration to security or privacy. People who were unable to see the positive (if unintended) consequences of how IPv4 had been put to use in the real world. There just aren't words suitable for publishing anywhere which can convey my absolute contempt for it."

I'll give you credit for 2 points:

- IPV6 designers gave no consideration for privacy. yes, indeed.

- They didn't give a shit about IPV4 -> V6 transition. yes, indeed, but some people woke up late on this (See RFC 6144)

However, I maintain the argument that it's not the network's responsibility to maintain a barrier between devices because device's developer have been completely careless on security.

If things have degenerated this way (and they have), then the end game must be that:

- device devs have to get their acts in order

- IP V6 has to be deployed

3
3

Re: NAT has to go, no..

@itzman

Very interesting post, mate, have an upvote.

It seems to me you're describing a TOR network on IPV6.

It really seems to me this could be the future ...

1
0
Gold badge

Re: NAT has to go, yes

No I wasn't trolling. Taking Windows as an example and looking at the last few years of patches, it is pretty obvious that putting a Windows box on the public internet adds only a handful of possible exploits to, compared to the dozens that exist if we go through the end-user. It is also pretty obvious that any system you put on the net now is going to have a default firewalling option of "nothing in", so the reachability of the address is irrelevant unless you have an end-user (or crapplication) willing to help from the other side.

Oh, and thanks for holding back on the reference. Anonymous Linux fanbois don't have quite the "RFC status" that I was looking for.

"Better hope not I've got real IPv6 systems in real big organisations... but then my comments about IPv6 couldn't possibly have come from actual experience... could they?"

Based on your posts so far, I'm surprised to hear this claim. Perhaps your experience is out of date. Modern Linux and Windows systems are far better protected and far more configurable than your posts suggest.

0
2
Anonymous Coward

Re: NAT has to go, yes

Based on your posts so far, I'm surprised to hear this claim. Perhaps your experience is out of date. Modern Linux and Windows systems are far better protected and far more configurable than your posts suggest.

You can rest assured my systems are very well protected, it's because I take the protection of my systems very seriously, that I first became aware of the flaws in the Linux kernel options for IPv6, but it's OK, because I coded around SLAAC being broken in the kernel implementation of IPv6.

I suppose it might have been fixed in a later level kernel than the one I built, I have't bothered to look yet, I'll get to that at some point, for now my code will stop an unprotected IPv6 interface becoming available on any system I create.

Do feel free to keep trying the "it must be because you're an incompetent fuckwit" line of attack on me, it isn't going to change my views about IPv6. I wonder what everyone else is making of you personally attacking someone who dared to state an opinion you disagreed with though.

4
0

Dismisinformation

NAT induces problems while providing something more than a tad short of comprehensive ingress filtering. Those who favor NAT likely favor wearing hair shirts.

DHCP and DHCPv6 are not security instruments, despite being wielded as a NAC talisman by some.

SLAAC is much easier to provide than DHCPv6. It works quite well. RFC7217 provides an improvement.

DHCPv6 is not the same as DHCP(v4). DHCPv6 can be used with or without SLAAC, and need not be used to dole out addresses.

Some common contemporary network implementations in a SLAAC environment use RFC4941 addresses, and use them preferentially.

Not all contemporary network implementations support DHCPv6: Android does not at this time (nor does it support RDNSS, so DHCPv4 is also required).

I suspect the resistance I often observe regarding IPv6 addressing, loathing of SLAAC, and devotion to DHCP, is fundamentally Calvinistic.

http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-03 is also worth reading.

6
4
Gold badge

Re: Dismisinformation

"I suspect the resistance I often observe regarding IPv6 addressing, loathing of SLAAC, and devotion to DHCP, is fundamentally Calvinistic."

No, it has everything to do with wanting control over out own networks and endpoints. Even little things like "renumbering" in failover or dual-homing scenarios for SMBs that don't have BGP. We don't care what ivory tower intellectuals want. We want functional, cheap, secure and private. IPv4 does that now. IPv6 destroys it.

4
3
Silver badge

Won't someone think of the routers?

"Moreover, since there's a to-most-intents-and-purposes-inexhaustible supply of IPv6 addresses, your device can have the same address forever, regardless of which network it's connected to"

Ummm. Nope. Portable IP addresses for hosts is not the same as portable IP blocks with AS assignations

0
0

Getting more peopel to adopt IPv6

For consumers he easiest way to get people to adopt IPv6 would be to modify the DHCP protocol so devices can declare they are DHCP servers themselves and would receive a block of IP addresses in addition to the single address it would already get. Why introduce new protocols when slight tweaks to current, well understood protocols would work just as well.

Example:

A consumer's router boots up and connects to the ISP and requests an IPv6 address and assigns it to its external-facing port, it would then start its DHCP server daemon which would connect the ISP's DHCP server as well and request a block of IPs which it will use to assign addresses to its clients in turn. The ISP's server would then update RIP/OSPF/etc to route all traffic for that IPv6 block to the external port of the consumer's router. The consumer router would act as a firewall and host other services like IDS, malware scanning, etc (With today's many-core ARM chips, you could build a router to do all this for under $100) to protect the clients it serves (especially if the router had an auto-update feature). And with all that, you'd have a modern, fully protected network without needing the consumer to do anything except plug in (and configure the WiFi, but that is a whole other battle.

2
0
Gold badge

Re: Getting more peopel to adopt IPv6

How is that better than (or, in any significant way, different from) what my router does now?

It gets a /48 prefix from my ISP. My ISP presumably routes packets in my direction based on that prefix. My router advertises the prefix. My IPv6-capable devices figure out addresses based on that prefix. My router blocks all incoming connections by default. My router cost about £50.

As far as I can see, IPv6 already works, is already here, and the only problem is that most of the world either hasn't heard or has decided to be "in denial" as part of some lifestyle choice. Still, eventually we'll be able to switch off IPv4 support on our own networks and all the denialists will disappear at a stroke.

3
3
Gold badge

Re: Getting more peopel to adopt IPv6

My ISP doesn't hand a prefix. It only hands off individual IPv6 addresses to devices directly connected to the modem*. Nothing else.

No other ISPs offer IPv6 to end customers at all here.

Even if I could get prefixes, what if I want to dual-home, or to switch from one ISP to another? The end-customer and SMB ISPs don't offer BGP to us, and that's assuming we're even trained to handle such a thing. I can buy dual-port IPv4 routers that do load balancing and failover and don't require me to renumber my entire network to accomplish it every time there's a failover.

How does IPv6 handle these scenarios? Hmm?

I'm deeply interested, because all I get from the ivory tower types it "sit on it and rotate, those scenarios don't matter, prole."

My response to them is "your end-to-end doesn't matter, assclown" followed by IPv6 NAT. When the protocol is ready to meet my needs then I'll use it as designed. Until then, fucks given about ideological purity of the protocol = 0.

*I don't care if you want to "blame my ISP." Eat 10,000 sacks of wiggling phalluses if that's your response. There are no choices of ISP for the end customer. What the ivory tower douchepopsicles have failed to comprehend from day one is that the ISPs dictate terms to customers, not the other way around. And the ISPs give zero fucks about anything except how to extract the most possible money. I don't care about what the spec is, or how it's intended. Only how it is actually used and what's available to me. Both from ISPs and from device vendors. Everything else is masturbation of the most pointless and vapid variety.

5
1

Re: Getting more peopel to adopt IPv6

I'll start with just changing ISPs because that is the more common scenario: radvd supports renumbering of the prefix.

For load balancing, You can use SNAT with load balancing scripts balancers that already exist to manage two or more ISPs at the same time.

0
0
Gold badge

Re: Getting more peopel to adopt IPv6

"I don't care about what the spec is, or how it's intended. Only how it is actually used and what's available to me. Both from ISPs and from device vendors. Everything else is masturbation of the most pointless and vapid variety."

Then you could avoid a number of pointless and vapid arguments by criticising your ISP and device manufacturere in future rather than IPv6. Remarks like "How does IPv6 handle these scenarios?" lead the naive reader to believe you are blaming the protocol.

1
2
Gold badge

Re: Getting more peopel to adopt IPv6

To my understanding radvd still requires the systems ask for new IPs when a change occurs. In an IPv4 world, I never have to have my internal systems change anything, ask for a change, restart, hup or whatever. The external IP changes but the internal IP stays the same. Everything behind the firewall continues to work *exactly* as it was before, with zero administration. All that changes is the edge device (which picks up that the IP address changeover has occurred) and DNS (driven dynamically by the edge device.)

Now, I could try mucking about with prefix validity lifetimes, but then I'm still changing the IP address that the applications on that system see. There's all sorts of applications that need restarts to handle address changes and that's very, very bad.

The solution, of course is using ULAs with 1:1 NPTv6 or Map66 at the edge.

Ivory tower types my not like that we all have 30+ years of legacy cruft to drag around, but fuck them in the face with a rototiller. I couldn't care less. We do have 30+ years of legacy cruft and that isn't going away.

Applications don't like having their IP addresses changed. That means that you either have to set up the application for all possible IP addresses (and defend all possible IP addresses) before the app starts. Frankly, this is often not possible in cases where you are trunking in a second ISP to handle load changes or ahead of a known outage/changing contracts/etc.

Alternately, you have to restart your apps every time a change occurs. That's just flat out unacceptable.

Radvd doesn't solve these problems. All it can let you do is assign new global IPs to your systems when a change occurs, assuming that the stars align right and the things actually handle multi-IP stacks properly, actually honour route expiration and so forth.

Load balancing, as you said, requires NAT. I don't think the future is overloading NAT as we have in the IPv4 world, unless you live in Canada where the ISPs are douchecanoes that don't hand out prefixes. (May they burn in the eternal fires of their own greed.)

At a minimum you are going to do 1:1 prefix translation NAT to get proper load balancing, which is exactly what I use and advocate, and something that makes the ivory tower nerds' heads explode in an ideological rage.

To them, end-to-end is a religious concept that takes precedence over ease of use, profitability, manageability and even common sense. They will attack your professionalism, question your parentage and I wouldn't be surprised if they'd just shank you in the street with a sharpened toothbrush for having the temerity to suggest that "horrible internet breaking kludges" like 1:1 prefix NATing are required in the real world.

I can't stand those fascist wastes of carbon. I would not shed a tear if each and every last one of them get cholera and shit themselves to death. We wouldn't be in this mess, requiring "kludges" like prefix NAT if they had removed head from sphincter at any point in the multi-decade development of the IPv6 protocol to acknowledge the actual functional reality of the world in which the protocol - and the applications that use it - must actually function.

The network will adapt to serve the needs of the applications that make the business money. The business will not adapt to serve the desires of the people designing the protocol. That's life, and the ivory tower types need to fucking deal with it.

3
1
Gold badge

Re: Getting more peopel to adopt IPv6

"Then you could avoid a number of pointless and vapid arguments by criticising your ISP and device manufacturere in future rather than IPv6. Remarks like "How does IPv6 handle these scenarios?" lead the naive reader to believe you are blaming the protocol."

I am blaming the protocol. Many of us have been saying for well over a decade that exactly this was going to happen, despite protestations of the ivory tower elite. Shock of fucking shocks, the shit we warned about actually came to pass.

It is the job of engineers to design for the real world, not to create religions and ideologies and expect the world to conform.

The protocol should have been designed such that it would take into account that A) device vendors are not going to put even the faintest bit of effort into creating devices that do more than the bare minimum and B) ISPs will not all "follow the rules" and assign whole prefixes. This was mentioned SEVERAL times by people far more important and well credentialed than me.

The response of the ivory tower types? "The community must pressure these organizations into compliance." That was a spectacularly stupid plan for dealing with these issues and it didn't fucking work.

So, I have two options: I can cripple myself and the companies I support by trying to support a religious ideal of "end-to-end" that I don't actually believe is all that important (things work just fine without honouring that today), or I can say "fuck the theologists", break the spec and have shit Just Work.

I choose the latter.

4
2
Gold badge

Re: Getting more peopel to adopt IPv6

"The protocol should have been designed such that it would take into account that A) device vendors are not going to put even the faintest bit of effort into creating devices that do more than the bare minimum and B) ISPs will not all "follow the rules" and assign whole prefixes."

Sorry, Trevor, but I'm really struggling to see how anyone can design a protocol that is resistant against people just ignoring the protocol and doing something else.

You are right that you have options and your personal priority should be to make things work for you and your customers. I just don't feel that the IPv6 protocols are a sensible target for your anger.

"The response of the ivory tower types? "The community must pressure these organizations into compliance." That was a spectacularly stupid plan for dealing with these issues and it didn't fucking work."

Actually I'd hold your judgement on that. We (as in end-users) haven't really tried that yet. As IPv4-fixated ISPs try increasingly unfriendly options (like CGN) to postpone that job they don't want to do, customers (largely isolated from the problem until very recently) may start to take an interest and, then, letting the market sort itself out may prove to be a perfectly reasonable way forward. We're told that the backbone is already IPv6-friendly, and modern OSes are certainly happy to use it. ISPs and their bundled routers are really the only sticking point and in many parts of the world there is competition in that market.

2
2
Gold badge

Re: Getting more peopel to adopt IPv6

"Sorry, Trevor, but I'm really struggling to see how anyone can design a protocol that is resistant against people just ignoring the protocol and doing something else."

It's very simple. You accept the proposals that were repeatedly submitted for incorporating NAT officially into the spec. At the very least Prefix translation NAT, but NAPT66 as required for various emergencies. You put aside the end-to-end religion and you focus on reality.

The issue here is that actual solutions to the problems encountered were proposed. They were rejected because they broke end-to-end. End-to-end has become a religion. It is in the way of solving real problems. Smart people with credentials are proposing solutions. The hivemind says no.

"Actually I'd hold your judgement on that. We (as in end-users) haven't really tried that yet. As IPv4-fixated ISPs try increasingly unfriendly options (like CGN) to postpone that job they don't want to do, customers (largely isolated from the problem until very recently) may start to take an interest and, then, letting the market sort itself out may prove to be a perfectly reasonable way forward. We're told that the backbone is already IPv6-friendly, and modern OSes are certainly happy to use it. ISPs and their bundled routers are really the only sticking point and in many parts of the world there is competition in that market."

That is exactly the sort of airy-fairy "hope"-based thinking that has driven the IPv6 theologists from day one. It hasn't happened yet. It is extremely unlikely to happen in the future. The belief that people will pressure their ISPs and device vendors into behaving is based on the idea that humans are rational actors. People are not rational actors. Every single piece of economic theory based around that ridiculous idea is false and doomed to failure.

What people will start doing is paying money for IPv4 addresses. They will also start using NAT with IPv6 and damned be the nerds that cry "no!". It is happening today. It will continue to happen in the future.

The idea that end customers give a rat's ass about the end-to-end model was patently ridiculous from the start adn that hasn't changed one whit. In fact, in a post-Snowden world, there are a lot of people who are nearly violently opposed to the end-to-end model for any number of reasons. There will be no grassroots revolution demanding ISPs and device vendors get their shit together and properly support IPv6 protocol spec in order to make the end-to-end-model possible.. Nobody except the religious ivory tower elite and lazy developers who loathe having to actually engage brain and think about NAT when designing applications cares.

Market pressures will not force ISPs and device vendors to conform on IPv6, they'll force developers to design applications that work with IPv6 NAT. ISPs and device vendors are so powerful they dictate terms to end customers, not vice versa. That dynamic will not change within my lifetime.

Developers, on the other hand, are cheap and disposable. For every recalcitrant douche who refuses to write their IPv6 application to cope with NAT there are 10,000 more willing to write a similar app that will. End customers do dictate to developers. That's where the fold will occur.

4
1

Page:

This topic is closed for new posts.

Forums

Biting the hand that feeds IT © 1998–2018