IPV6...

[#1]

---

@VileReynard wrote:

But by virtue of hiding behind NAT, I can use fixed IPV4 addresses for local devices and associate host names with them.

DNS isn't applicable in this case.

---

You can do that with IPv6 too, without NAT. 

[#2]

---

@VileReynard wrote:

Since FTP is claimed to be unusable, obviously it would be better to use SFTP or SSH over IPV6 - except that local devices don't have fixed addresses so its hard to associate host names with IP addresses. So how would this work?

---

I didn't say FTP was unusable - it works WITH EXTRA WORK to gaffer tape over the problems caused by NAT. Extra work that could be better invested elsewhere.

And it matters not one bit what protocol you are using - if you want to connect to something, you need to know it's address. You can do that with dynamic addressing and dynamic DNS, or with fixed addressing, or ... - and that's the case with both IPv4 and IPv6.

If you think that IPv6 is restricted to only using dynamic and constantly changing addressing then you are misinformed.

[#3]

---

@MJN wrote:

---

@VileReynard wrote:

But by virtue of hiding behind NAT, I can use fixed IPV4 addresses for local devices and associate host names with them.

DNS isn't applicable in this case.

---

You can do that with IPv6 too, without NAT. 

---

But if I'm not using NAT, I need to have local IPV6 addresses regenerated randomly fairly frequently - I don't really want to publish my local devices addresses on the internet.

[#4]

---

@VileReynard wrote:

---

---

But if I'm not using NAT, I need to have local IPV6 addresses regenerated randomly fairly frequently - I don't really want to publish my local devices addresses on the internet.

---

It sounds like you might be mixing up different aspects of IPv6 and its addressing model/modes.

If you want to address local devices in a way that is completely disconnected from the Internet then you can use Unique Local Addresses . They can only be routed within your own network (and not on the Internet). They are in many ways analogous to RFC1918 'private' addresses in IPv4 with the notable exception that they are not intended to be used behind a NAT (if you want devices to access the Internet, and/or be accessed from the Internet, they should be given Global Unique Addresses instead (or in addition to if desired)). Alternatively, use GUA addresses for everything and firewall accordingly.

You are free to choose whether want your addresses to be assigned randomly, pseudo-randomly, dynamically, statically, autoconfigured, statefully configured etc.

[#5]

---

@VileReynard wrote:

Well - if you are going to use a proper firewall, as opposed to a consumer grade router, things are going to be more complex. 😀

I bet you get loads of attacks on that port 22!

---

Well yes of course; and thats why my final version didn't open port 22 like that (I really should update that page). But we are now straying into the subject of firewalls, think we should agree that this is different from NAT, and NAT is what IPv4 forces us into.

Under IPv6 we would still use firewalls, just as we do under IPv4, so this is agnostic when it comes to Internet Protocol.

Guess its my bad, that I only have a £50 router, and don't use a full proper commercial grade router. For what its worth though I like openwrt, as it means that I can do my own NAT and firewall rules. With the stock router software, firewalls couldn't be nearly as complex as mine is. Now this only really becomes an issue when you need open ports coming into  the router, but as FTP and the like show - this can happen quite easily ...

[#6]

---

@VileReynard wrote:

---

---

But if I'm not using NAT, I need to have local IPV6 addresses regenerated randomly fairly frequently - I don't really want to publish my local devices addresses on the internet.

---

Isn't fairly frequently regenerating IPv6 addresses a problem in its own right? E.g. I do stateless IPv6 behind my router, which uses 6to4. Now as when an IPv6 address changes, you still need to receive traffic sent to the old address. This means you need to remember all old addresses as well.

So take my NAS, these are the IP addresses currently assigned to just one interface:

<code>
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 5c:f4:ab:51:71:8f brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.111/24 brd 192.168.2.255 scope global dynamic eth0
       valid_lft 36394sec preferred_lft 36394sec
    inet6 2002:545d:afbe::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:545d:afbe:0:301d:86cf:cd26:77dc/64 scope global temporary dynamic
       valid_lft 590202sec preferred_lft 71655sec
    inet6 2002:545d:afbe:0:5ef4:abff:fe51:718f/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:545d:ab77::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:5770:29d3::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:5771:39b2::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:5770:eebb::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:5770:26e4::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:5770:e6a8::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:5770:ef15::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:545d:d6da::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:5771:831a::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:545d:5b4d::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2002:545d:3a3c::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fd84:32c:ad2f::111/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fd84:32c:ad2f:0:301d:86cf:cd26:77dc/64 scope global temporary deprecated dynamic
       valid_lft 102747sec preferred_lft 0sec
    inet6 fd84:32c:ad2f:0:5ef4:abff:fe51:718f/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::5ef4:abff:fe51:718f/64 scope link
       valid_lft forever preferred_lft forever</code>

---

[#7]

One philosophy recommended for IPv6 privacy is that the client device should use randomly generated addresses and rotate them frequently. However, that does not preclude them using other addresses at the same time.

So if you have a service you need to accept inbound connections to, assign it a static address* and bind ONLY that service to that address. For everything else, use dynamic addresses - in particular (and I don't think things are there yet), a web browser could use a different address for every site it visits, and change the addresses for those sites occasionally. Nothing to stop you having multiple services, all listening on their own addresses - and if you use the 2^64 addresses wisely, finding (eg) your web server on port 80/443 won't really help someone find your SSH server on another of your 2^64 addresses. Note that 2^64 is the minimum size for a subnet - the recommendation is that ISPs should delegate a minimum of a /56 to each customer giving 2^72 addresses, and preferably a /48 giving 2^80 addresses. Even a /64 gives you 2&32 times the size of the entire IPv4 address space to play in 😎

* And don't use <prefix>::nn. Can't remember where I saw it, but certain addresses (like <prefix>::2 and similar) turn out to be very commonly used - that's just human nature wanting easy to remember/type addresses rather than generating properly random ones.

[#8]

Why is a IPV6 address 128bits long?

Surely 64 bits (or even less) would be ample - and might provide a gradual upgrade path from IPV4 (if current protocols were retained).

Even a 33 bit bit address would double the existing address space... 🤣🤣🤣

[#9]

Address space bit length has no bearing on upgradability. IPv6 is a new protocol requiring a new protocol stack. Furthermore, don't fall into the trap of thinking the only difference between IPv4 and IPv6 is the size of the address space.

Regarding bit length, the reasoning behind 128 bits are myriad and not necessarily explicitly defined following original ratification. One key reason why it is considerably bigger than a 64 bit space is to allow a fixed 64 bit boundary separating the network and host ID, although this specific value was settled on much later on. RFC 7421 gives thorough coverage on the topic.

[#10]

---

@VileReynard wrote:

Even a 33 bit bit address would double the existing address space... 🤣🤣🤣

---

And be as incompatible with IPv4 as 128 bits.

It's a question that often comes up, some variation of "why couldn't we just add a few bits and stay compatible ?" The simple answer is that all IPv4 networking code is based on addresses being 32 bits. There is NO WAY WHATSOEVER to change that without breaking compatibility with existing devices and services - so going to 33 bits would involve as much disruption as going to 128 bits.

But given the upheaval needed in changing protocols, it makes sense to make a big change and do it once. The alternative is we get a decade or three down the line and find ourselves asking "why didn't we make it bigger, now we've got to go through the whole upheaval again".

As said, there is more to IPv6 than just more bits, though that does mean additional complexity and new learning to do - but the chance was taken to consider some of the problems that people have found with IPv4 which was designed in days when things were a lot simpler.

TL;DR version. ANY change to address length breaks compatibility with ANY protocol not designed from the outset to have variable length addresses. IPv4 is not such a beast.

[#11]

---

---

---

@SimonHobson wrote:

One philosophy recommended for IPv6 privacy is that the client device should use randomly generated addresses and rotate them frequently. However, that does not preclude them using other addresses at the same time

---

Its interesting how this thread is now expanding into implimentation of Ipv6 and how we'll use it.

Anyway I'm not sure I agree that IPv6 is a privacy issue. There are two main reasons:

1) If a computer uses an IPv6 address, then it has to recieve packets sent to that address. The low level computer OS typically does not know the life span of the IPv6 address, and so this means that the computer needs to recieve packets to that address for an extended (unknown) time period.

2) IP addresses (both IPv4 and IPv6) are used for routing, e.g. at least part of the address is needed for routing the packet back to the sending machine. This routing information is identification.

Both of these can be seen in the list of IPv6 addresses I gave associated with the ethernet on my NAS. My router uses 6to4 IPv6, where the IPv6 packet is inside an IPv4 packet. Now part of that IPv6 address is the IPv4 number of the router wan connection. My wan goes down a few times a day (known issue, not a worry to me). Each time the wan comes back up again I get a new IPv4 number, and so all the IPv6 address need to be reissued with the updated details. Now although the router knows the connection has been renewed, and the old IPv4 number won't be used again; my NAS has no knowledge of this. This means that the NAs still remembers the old IPv6 address, in case any packets are sent to that old address. Now that I get new addresses a few times a day, is what gives the 15 or so IPv6 addresses associated with the ethernet on the NAS. If applications regularly chose new IPv6 adresses, the ethernet interface would get all associated with it, and not knowing the lifetime of the address have to keep it. So it would soon be saturated with adresses.

The second issue can be seen by looking at one of the adresses: 2002:5770:29d3::111. The 2002 means its a 6to4 packet. The 5770:29d3 in 6to4 is the IPv4 adress embeded in the IPv6 address, this one expands to 87.112.41.211. Now you can look that up in whois, and the number is owned by plus.net (part of the dial-up and ADSL pool)(http://whois.domaintools.com/87.112.41.211). Indeed all 5770 adresses are inside plusnet - so you can see that all external IPv6 addresses that my NAS has, are asccoiated with plusnet. Now this was needed, so packets sent to those addresses, could be routed to plus.net - and then onto my machine. Hence I have no anonimity here, and plus.net probably has a record of the time period when I had each address.

So to my mind privary and IPv6 is a red herring. Security of IPv6, just as with IPv4, is done by firewalls. This won't change. If you really want to keep your IP address private, then just as in IPv4 you'll need to go via a third party.

[#12]

Indeed, there are already multiple techniques used by scum to identify and track people around. Not being able to use your IP address is of no consequence to them.
BTW, there is work going on in the IPv6 Ops IETF list around the problem of having stale addresses on end nodes when the prefix changes. It's especially a problem in mobile networks whete devices move around a lot.
PS, you can have a fixed IPv4 address from Plusnet - just turn it on in the control panel. One off £5 when you turn it on.

[#13]

Presumably these new-fangled "IoT" gadgets will be using manufacturers assigned IPV6 addresses - probably not even firewalled?

I wouldn't trust any supposed encryption on a cheap device...

[#14]

No, they'll have to use addresses appropriate to the network - same as with IPv4. In most cases that will mean SLAAC, but could include DHCP.
Firewall will be the users' firewall in the router.
And no, I'd not trust the encryption (what encryption ?) either.

[#15]

Just realised, although ispreview has said that IpV6 is comming to plus.net, there hasn't yet been an official annoucement from plus.net on any of the forums here. Indeed has there been any official annoucement anywhere?