Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Chrysalis on August 20, 2019, 02:20:30 AM
-
Have a look at this data.
https://ipv6-test.com/stats/country/GB
The only 2 major isps to this date is still just BT retail and sky who have rolled out ipv6. Incidentally both using DHCP6 dynamic allocation.
It seems companies are waiting till they "have" to use it.
If I go FTTP with cityfibre residential I have to use vodafone who only use the legacy obsolete IPV4 technology.
EE have it on their mobile network but not home broadband.
Virgin Media seem to be in a never ending trial of it.
Bizarrely plusnet trialed it then dropped it.
-
Correct. Companies are waiting until they have to use it.
There are projects in progress to release some more IPv4, too. It's legacy but it's not obsolete. New addresses are being progressively freed up, much of the Internets still relies on it.
Virgin Media have their own reasons for not releasing v6 just yet. There are a few ways of implementing it and if the delay means they do it right that's all good.
EDIT: Just to point out if you have a look at unique IP address statistics so that they can't be skewed by tunneling the UK really isn't 'shameful'. More like mid-table obscurity. Hurricane Electric tunnels can skew statistics quite heavily.
-
I wouldn't call it "shameful" because IPv4 lets the average residential user do everything they need to. IPV6 is only a must for people like IT workers but then again such users won't really be using mass market ISPs since options like static IP addresses etc are usually available with the smaller ISPs. FWIW my ISP - FluidOne - offers me both IPv6 and IPv4, yet i prefer to use IPv4 since it just works without any fuss.
-
Thats why I consider it shameful psychopump, they only doing whats needed for users to get by, instead of been technical leaders and forward thinking.
CarlT, ask yourself tho, what is the point of it all, if you have a deadlock of (a) websites sticking to ipv4 single stack because consumer isp's dont see a need so they also dont see a need (kitz as an example), and isp's the same the other way round as they waiting for a large website to go single stack ipv6 before they roll it out, kind of like a wild west standoff.
Google have three times almost gone single stack ipv6 to "force things" but keep been talked out of it.
It feels like in 10 years time we will be in the same position. These projects to release ipv4 shouldnt even be happening, its kind of like a bandaid.
When you look at this from the broadband side of things, it probably seems I am making a fuss over nothing as everything "just works" right? But on the hosting side of things, there is extreme shortages, its routine now for many providers to run a single ipv4 policy, and they expect their customers to run everything on one ipv4, or run normally using ipv6, or pay a premium for multi ipv4.
What I would like to see is google apply a SEO penalty for ipv4 single stack, (website admins will suddenly treat ipv6 as an emergency implementation if their precious SEO is damaged), for google to do ipv6 only days multiple times a year where all their services go down for ipv4 users to "encourage isps". This may sound radical but google already do this, they use their market position to force tech adoption, but for some reason they held back on forcing ipv6 so far. Either that or countries like the UK legislate ipv6 availability enforced via ofcom. The latter solution avoids pains for consumers with services not going down to force things, as it looks to me a case of market failure where the market wont adapt a technology due to lack of commercial opportunity. There is already one clear consumer advantage to routed ipv6 which is if a household has multiple consoles, then the ports can be open and available for multiple consoles at once on one network, something not possible on ipv4 NAT.
Maybe I should contact anti piracy groups and any filtering groups to get them to lobby for it, as one thing the UK is a leader on is internet filtering, we love that as a country, and if those groups were to be convinced ipv6 helps that (ironically it does), then they could push things along.
-
Hi
It of course comes down to money, no ISP makes money providing IPv6, yet to implement it comes at a cost, so no incentive.
IPv4 addresses might be running out, but except for a tiny small percentage of people having to fill out forms to justify a few precious IPv4 addresses, it effects no one else, as everything still works, granted some things might work better on IPv6, but they still work by and large on IPv4. Whereas turn IPv6 on, and things can stop working for people as devices suddenly try routing over IPv6 that is either implemented incorrectly by the ISP, or more likely broken in the customers equipment somewhere.
The SEO penalty might push websites to support IPv6, but it doesn't push ISPs to provide IPv6, so not sure that will help. The industry is moving to dual-stack, not to IPv6 only, so IPv4 is expected to remain for decades to come and really there is no rush to move everyone over to IPv6, which is why we don't see any. It is a very slow burn :-)
I quite agree more ISPs should be moving over, but I can see why they are not.
Regards
Phil
-
IPv4 addresses ran out some time ago, in fact, 2011!
-
Thumbs up to Chrys. :thumbs:
-
Also, I just noticed the talk about internet filtering.
Internet filtering is bad, very bad.
-
IPv4 addresses ran out some time ago, in fact, 2011!
More are being freed up via previously reserved ranges and the selling off of blocks from organisations with insanely large supernets.
Had they irretrievably run out things would change.
-
Thats why I consider it shameful psychopump, they only doing whats needed for users to get by, instead of been technical leaders and forward thinking.
This isn't the Wild West. The UK is one of the most Internet dependent economies in the world. We don't have the luxury of being 'technical leaders' when people can get fined, sued and taken to task by the regulator for downtime.
VM could've actually provided IPv6 a while ago, however they've rethought how they're implementing in return for a better solution.
Either way conservatism is baked into the UK model due to regulation, etc.
-
More are being freed up via previously reserved ranges and the selling off of blocks from organisations with insanely large supernets.
Had they irretrievably run out things would change.
Whilst this is true, there are a lot of universities etc in the USA for example that are not selling their huge /8's.
The problem does not exist in the far east, where IPv6 adoption has been far quicker - mainly because they've had to.
NAT has just been too good.
-
Thumbs up to Chrys. :thumbs:
Wastage of IPv4 has been a major issue. ISPs handing residential users /26s to allow every device in a home to have a public IP for instance. :P
There's still some mileage in recovering it. VM are taking their time to provide a better solution. TalkTalk I have no comment on.
Either way we're fine. We innovate in the UK in terms of the applications running over networks and how we're using them. The actual networks themselves we have to operate with more caution.
Those paying attention would've noticed some IPv6 traffic from VM, and VM advertising IPv6 prefixes a little while back. Could actually ping them over 6 and everything bar the CPE are dual-stack, the VoIP telco is using v6 :)
-
We can argue til the cows come home as to whether IPv6 really matters to the home user.
And we can apportion blame to lazy ISPs for not making IPv6 available to those who, for very valid reasons, wish to use it.
But we often overlook the underlying 'blame' which imho should be apportioned to the internet protocol committees, for having originally adopted an inadequate protocol based on IP addresses of fixed length (32 bits). The competing protocol suite, as the public internet evolved, would have been the ISO/OSI stack. The rough ISO equivalent of an IP address is the NSAP, which has always been a variable length field, up to 20 bytes. :P
I recall proposals nearly 30 years ago, when the it was first foreseen that IP address space would be inadequate. One proposal was to adopt ISO CLNP as the IP layer, with TCP/UDP on top. Named TUBA (TCP and UDP with Bigger Addresses). I don't think proposals for TUBA ever got off the ground. Ive heard it suggested that a factor was dress code... on one side of the table were neatly groomed people in business suits (OSI), on the other side were long haired people in jeans & T-shirts (IP), and these two sides were never really going to bond. :D
TUBA:
https://tools.ietf.org/html/rfc1347
-
We are where we are.
If people are upset with all this dragging out of v4 they should love the more recent commits to the Linux kernel allowing use of the 0.0.0.0/8 range. 127.0.0.0/8 bar some exceptions coming soon, nearly all of 240.0.0.0/4 and most of 224.0.0.0/4 on the way.
EDIT: Just FYI in case I'm giving an incorrect impression I pay AAISP for an L2TP service to provide dual-stack functionality to my home network. Around 35% of traffic at home is IPv6. I would be delighted to not have to do this anymore however we're not in a shameful place in the UK. Mid-table obscurity.
-
To be honest I sometimes wonder if IPv6 will ever make it. How long has it been coming? Certainly before RFC1918 made private address space and NAT more acceptable. And back then it was claimed IPv6 was the only way to get QoS over IP. Given that it's been "just around the corner" for decades now it's not really surprising that ISPs aren't rushing to invest in a technology that their customers aren't asking for.
Referring to comments about IPv4 space being freed up, Amazon's recent acquisition of a /8 and a /10 suggests that they don't see an end to IPv4 any time soon. Which reminds me, one of the early mistakes was making these assignments permanent. Really any address space not announced on the Internet should have been reclaimed. At my last place we had a PI /24 from the days when the University of London was handling them out. There was never any pressure to justify our use, even though it was never routed on the Internet.
-
What is the hold up of IPv6? Is it money? (how much does it cost?), or is it the potential downtime and technical implementation that makes ISP's reluctant to start the process?
-
How long has it been coming?
A long time. Pretty sure I remember IPv6 dividing opinion among colleagues, and being ‘just around the corner’, early nineties. A quick glance at Wikipedia suggests one of the first RFCs was RFC1883, dated 1995....
https://tools.ietf.org/html/rfc1883
-
Couple of things strike me about v6 when I've been thinking about it recently. One is that it's almost as if the 128 bit length is too long, and people need to find ways to "use up" the space. For example the hardware derived interface ID being 64 bits rather than 48, with the extra 16 bits being completely wasted as they're always the same value. Or the recommended practice of using a minimum /64 for any network, even a point to point where you'd use a /31 currently. The other one is that it was a missed opportunity to make IP addresses multi dimensional, rather than just a very long linear list. Although on that second point I saw a blog by one of Cisco's head honchos suggesting something along those lines, he was proposing that we should consider a devices Interface ID as being it's globally unique identifier, and the Prefix identifies the connection through which it is currently communicating.
-
Just noticed in one of the blogs, back in 1990 it was predicted that we'd run out of IP addresses in 1994.
-
Just noticed in one of the blogs, back in 1990 it was predicted that we'd run out of IP addresses in 1994.
As a 1960s/70s school-kid, we were taught that the world would run out of oil by the year 2000. We were also taught that, even if we survived the crisis caused by loss of fuel, we’d each have only about a square yard on which to stand on the planet’s surface, owing to population growth.
And let’s not forget the 1990s forecasts of Y2K bugs, with airliners using flawed navigation systems crashing headlong into tins of baked beans with flawed expiry dates, the world over.
None of these happened. :)
-
I was put in charge of y2k bug hunting for core communications protocols when I worked at Psion. I’m pleased to say I didn’t find anything that needed fixing, and not was there anything. But long before that I was responsible myself for a y2k bug. I wrote the first Psion Organiser II diary program and that only had two digits for the year. (I can’t remember now, but later machines, might have had four digits for the year.) At the time, in 1986, it seemed inconceivable that the machines would still be around in the year 1999.
-
And let’s not forget the year 2038 draws closer every day, with possible dire consequences for any remaining 32 bit Unix like systems....
https://en.wikipedia.org/wiki/Year_2038_problem
I’m aware of bugs I wrote myself, that would manifest if certain sequence counters wrapped. Rather than a fixed date, the bugs I have in mind would require a sustained system up-time of several hundreds of years. I try not to worry about it.
-
Have some Unices has their time retval word width fixed anyway, regardless of any 32-bit vs 64-bitness of the o/s? I assume that a 64-bit o/s means that a pointer is 64-bits but in C a uint/int may by default be 32 bits firstly (i) because for many common use cases 64 bits is overkill, (ii) because 32-bits is probably enough - because software was tested with uint set to 32 bits in 32-bit architectures before and worked fine then so 32 bits is enough, and (iii) some compilers prefer to leave uint as 32 bits to reduce the chance if (reasonably rare) risks introduced when porting 32-bit-tested code to 64-bit systems, and (iv) in some 64-bit architectures 64-bit operations have a very very slightly higher cost than 32-bit ones - in x86-64 iirc the slight extra cost is in code size, zero difference in speed, 64-bit operations can have an extra byte in total opcode length compared to 32-bit operations the latter therefore can be regarded as the default.
The time retval typedef should be such that it’s independent of the width of an int or uint, but I suppose the choice for the value of a long or ulong could be a problem - I have no idea. If a time retval type has to be a long that is two machine words on a 32-bit machine then so be it.
(I haven’t done any C in a long while, although I did ten years of it professionally. D has taken over my life. In D, a uint is always 32-bits and a ulong is always 64-bits; and they are guaranteed to be fixed. I don’t like that because there’s no declaration of intent, so I often avoid using those types anyway, preferring uint32_t and uint64_t exact width types and their min width relatives where it matters or where there is any chance that it might matter, to avoid bugs where widths are either ‘just plain wrong’ and have to conform to something else or exact width is part of the algorithm, or where code can fail because of a ‘not wide enough’ error.)
On a 32-bit o/s it 64-bit o/s alike you could make the time retval into uint_least64_t or uint_fast64_t.
I’m just wondering now - there’s no possible reason to make them signed is there? If these times are signed then we could handle dates before 1970. But could that be a bad thing because of ambiguity and compatibility problems with old code and the meaning of the bit pattern that could be 1969 - I’m lost here. My instinct as always is to make such a thing unsigned.
-
Weaver, there was a time when I’d have enthusiastically embraced a debate about the merits vs downsides of signed vs unsigned for time_t, and about the merits vs downsides of extending it to 64 bits, where possible. These days, I have trouble justifying (to myself) coding decisions I took last week, so I’ll avoid discussing Unix internals. ::)
I did find this wiki page, which might be of interest.
https://en.wikipedia.org/wiki/Unix_time
In particular I liked...
Unix enthusiasts have a history of holding "time_t parties" (pronounced as "time tea parties") to celebrate significant values of the Unix time number.[16][17]
Now that’s new to me, but I can believe it. :D
@Chrysalis, apols this thread has drifted off topic. Feel free to bring us back into line, with a suitable rebuke.
-
Likewise off-topic apologies :blush: :(
-
IMO IPv6 is seriously flawed and router support is all over the place.
Even on pfSense, I can monitor traffic routed between the WAN and LAN very easily from within the UI, IPv6 you cannot.
Despite being on Zen I disabled IPv6 for the LAN as the Xbox One would get a different IP every time it rebooted, due to changing its UUID. This meant I couldn't tell the firewall to allow all traffic in/out to that IP address, killing connectivity in games. Which is absolutely bizarre when on IPv4 you can simply allow its IP to control uPNP and call it a day.
The fact some devices use DHCP6 and others use router announcements, it just completely screws up firewall management on the router. Plus its not like you can simply allow IPv6 everywhere, how do you know things like IoT devices are correctly firewalled? Why would I trust every client on the network to be correctly firewalled anyway? Windows has even been known to switch the firewall between Private and Public on a whim, I'd rather not trust it.
Basically IPv6 throws security out the window, plus I still had the odd connectivity issue with Android.
-
I hear your point about the difficulty of firewalling in IPv6 due to the unpredictability of IPv6 addresses. The fact that IPv6 addressing is all over the place is a feature not a bug. It’s supposed to be a privacy feature, and truly zero-config address auto assignment when for example based on MAC addresses, just works, every time, and no reliance on dhcpv4, no problems with networks not starting up because there is no dhcp server as it’s either out to lunch or has not booted faster than all the other devices. IPv6 zeroconfig just works 100% which is so good. The all-over-the place IPv6 address assignment is indeed really annoying to sysadmin such as you and me. It’s also promoted as a privacy feature which does work to stop eg cross-site tracking on the web. In fact this is not the fault of IPv6, but of operating systems which have failed to make decisions about who controls the freedom to use or not use privacy addresses, who must use admin-assigned static addresses and who must use dhcpv6. IPv6 dies specify a mechanism iirc for telling operating systems that they must use dhcpv6, or otherwise they can do what they like. I get the feeling that some operating systems might be ignoring this instruction, it’s a long long time since I read up on all of IPv6 autoconfig. The robustness of it is very impressive but null points for operating systems.
-
b*cat adds just a very small comment --
I'm waiting for IPv8 to appear. Basically 128 bit (like IPv6) but with logic and sanity in abundance. Until then I'll continue to use IPv4.
-
Hi
Basically IPv6 throws security out the window, plus I still had the odd connectivity issue with Android.
It doesn't throw security of the window, IPv6 is still fire-walled by the router, certainly on pfSense. pfSense is a stateful firewall, so all unsolicited incoming connections are blocked by default, but incoming connections initiated by an outgoing going connection is tracked and allowed in. No different to how IPv4 works, except IPv4 also typically is used with NAT that kind of acted like a second firewall, but that's by accident, not by design. The only way a IoT device would be accepting unsolicited incoming connections is if you put an exception in the pfSense firewall.
Regards
Phil
-
I would imagine if there were that many security concerns with v6 ISPs would be much more reluctant about deploying it.
When they deploy to their own CPE they ensure that stateful firewalling is in place. Such firewalling comes by default in most home routers, with NAT on top.
It shouldn't be a problem now and the evidence from millions of users in the UK alone is that it isn't.
-
I hear your point about the difficulty of firewalling in IPv6 due to the unpredictability of IPv6 addresses.
I would hope this isn't a problem for anyone. If anyone is firewalling based on IP addresses and require any manual programming they're doing it wrong.
Zone-based firewalls have been the cool thing for a long while now. No need to micromanage anything apart from any exceptions that may be needed.
-
What CarlT said. Watch the presentation from a Microsoft employee (https://indico.uknof.org.uk/event/41/contributions/541/) about their efforts to get rid of IPv4 completely in their internal corporate network and now also the guest wireless LAN they offer to visitors. This presentation concerning security and IPv6 (https://indico.uknof.org.uk/event/44/contributions/579/) might be of interest.
-
Some of our enterprise customers are likewise moving away from v4. It's being used as much as possible on public-facing edge infrastructure only. Some v4 needed for internal infrastructure but a massive saving.
Saves headaches with NAT and public IPs for offering cloud services in the case of Microsoft, Amazon, Google, etc.
Provides a source of extra cash for some institutions that have absurdly large allocations way in excess of their needs, too.
EDIT: Before the obvious question is asked as to why enterprises are able to do this it's simple: they control everything end to end until it leaves their network and the end users aren't paying customers but paid employees. ISP customers may demand dual-stack or equivalent, employees and users of guest networks can be pushed through gateways and address translate so v4 may be retired.
Someone like Weaver with his /26 would be quite stuck if told no more IPv4 full stop. Same for ISPs: CG-NAT.
-
I would hope this isn't a problem for anyone. If anyone is firewalling based on IP addresses and require any manual programming they're doing it wrong.
Zone-based firewalls have been the cool thing for a long while now. No need to micromanage anything apart from any exceptions that may be needed.
The point is people are USED TO firewalling based on IP address, as this was necessary due to NAT and it simply works. Also how is that much different to IP based routing, which is hardly an unusual thing to be doing?
So how exactly do I allow ALL incoming connections to the games consoles on v6 without allowing it for the entire LAN?
-
Clearly we have a lot of IPv6 expertise on here. I probably don’t have enough spare brain capacity to become expert myself, so I’m hoping somebody might be able to comment on a couple of concerns I have.
Iirc, one big win for NAT is that it (accidentally) provides a layer of privacy, as it is hard to associate the public IPv4 addresses with individual devices behind the NAT. IPv6 compensates for that, and even improves upon it, by using IPv6 addresses that change regularly, and are unpredictable. Correct?
Now to my concerns...
1. Is there a point of failure at whatever server assigns these addresses? I’m thinking of my favourite mantra “All software has bugs”. Assuming the IPv6 servers are also buggy, might vulnerabilities emerge that compromise the privacy of address allocation?
2. Will it be possible for future government interference (think RIPA) to mandate that ISPs disclose details that compromise the privacy of IPv6 address allocation?
Genuinely grateful for guidance on these questions. :)
I’d also be interested in an answer to Alex’s last question so to avoid burying it, I’ll repeat it.
So how exactly do I allow ALL incoming connections to the games consoles on v6 without allowing it for the entire LAN?
-
The point is people are USED TO firewalling based on IP address, as this was necessary due to NAT and it simply works. Also how is that much different to IP based routing, which is hardly an unusual thing to be doing?
So how exactly do I allow ALL incoming connections to the games consoles on v6 without allowing it for the entire LAN?
I would hope this isn't a problem for anyone. If anyone is firewalling based on IP addresses and require any manual programming they're doing it wrong.
Zone-based firewalls have been the cool thing for a long while now. No need to micromanage anything apart from any exceptions that may be needed.
https://docs.oracle.com/cd/E18752_01/html/816-4554/ipv6-overview-10.html
The rightmost four fields (64 bits) contain the interface ID, also referred to as a token. The interface ID is either automatically configured from the interface's MAC address or manually configured in EUI-64 format.
Can also be set statically or via DHCPv6. SLAAC, the stateless allocation scheme, is more interesting as above but there are ways and means.
Whichever it works same way but no NAT just a destination IP and an 'allow' statement. Same level of security - a badly done port forwarding will bone you every bit as much as a badly done IPv6 firewall allow statement.
Regarding IP based routing I'd hope that's not being done by individual IP. Replace 'zone' with 'subnet' and you're about there, especially with directly connected networks. These are implicitly 'zoned' to the interface they're connected to.
-
1. Is there a point of failure at whatever server assigns these addresses? I’m thinking of my favourite mantra “All software has bugs”. Assuming the IPv6 servers are also buggy, might vulnerabilities emerge that compromise the privacy of address allocation?
2. Will it be possible for future government interference (think RIPA) to mandate that ISPs disclose details that compromise the privacy of IPv6 address allocation?
I don't really understand the premise of the questions. As far as 1 goes it doesn't matter and with that in mind 2 doesn't matter either. The devices behind the router / NAT gateway are just IP addresses. To identify them it's necessary to either exchange traffic with them or obtain access to the LAN so that you can read MAC addresses.
If it makes you feel any better the router you connect to the ISP gets a prefix and it's that router that hands out IP addresses to your LAN clients, not the ISP, much as happens with DHCPv4 and NATed networks now.
It's not impossible to unmask IPv4 NATed devices anyway. All even static IPv6 addressing will tell people is how many devices may have been online at any particular time.
-
Thanks Carl, that helps. :)
However, the home router that hands out IP addresses will probably be running open source software. The ’heartbleed’ bug of some years ago is an example of the whopping vulnerabilities that open source software (and all other software) typically contains. Fortunately, heartbleed was able to be fixed with server updates, rather than updating everybody’s home router.
My reservation then would be that if IPv6 places responsibility for address allocation in the home router, then the inevitable open source vulnerability that compromises privacy of address allocation will be quite a biggie, leaving us without either IPv6 privacy or NAT privacy? Bearing in mind that home routers may never receive software fixes...
I don’t agree that an IPv4 router doing DHCP is quite the same hazard, even if the DHCP allocations were compromised. The NAT forms a natural firewall that means the NAT’d IPv4 addresses give little away in terms of privacy or attack. I rarely use DHCP anyway, much prefer static address allocation, for IPv4.
I do of course agree, IPV4 NAT routers also have bugs, and probably contain spectacular vulnerabilities yet to be disclosed. But I can’t think of an IPv4 home router point of failure that’s quite as devastating as my IPv6 scenario, above? :-\
-
Not sure why you mention open source vulnerabilities so much.
Closed source is not immune to vulnerabilities.
-
Not sure why you mention open source vulnerabilities so much.
Closed source is not immune to vulnerabilities.
I referred to..
the whopping vulnerabilities that open source software (and all other software) typically contains
However, one difference in the modern world of Open Source software is, when vulnerabilities surface, they affect a large number of devices, across a large number of manufacturers, because all are using the same source code.
Forty years ago, when each manufacturer wrote his own source, there were at least as many bugs. Probably more in fact, as fewer critical eyes were cast on the source code. But when a vulnerability surfaced it affected only that manufacturer, as other manufacturers had different source, and hence different vulnerabilities. :)
-
My point was that such privacy really doesn't matter in the grand scheme. There are far more alarming issues that have impacted home routers recently.
On the whole being able to play with how the router is allocating IP addresses suggests remote command execution as you're feeding the router code to execute or messing with parameters existing code is executing so can likely find some way to spawn a shell. A sense of privacy from which devices are using which IP addresses is likely the least of a user's concerns under those circumstances.
-
Granted, I probably attach too much significance to NAT privacy which in any case, might be largely a myth. :)
-
Hi
IPv6 can expose an actual devices MAC address, as the addressing scheme often uses the devices MAC address to create a unique IPv6 address.
To overcome this, operating systems can have private or temporary IPv6 addresses, for example Windows does this, to help overcome privacy concerns and to stop the leaking out of MAC addresses. It has a normal IPv6 address that typically doesn't change, then one or more temporary addresses that will change randomly. When we go on the Internet, traffic is sent from/returns to the temporary IPv6 address. This is possible due to the large amount of IPv6 addresses available, and helps stop the tracking of a single IPv6 address and the exposing of a MAC address.
https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/
Regards
Phil
-
https://docs.oracle.com/cd/E18752_01/html/816-4554/ipv6-overview-10.html
Can also be set statically or via DHCPv6. SLAAC, the stateless allocation scheme, is more interesting as above but there are ways and means.
Whichever it works same way but no NAT just a destination IP and an 'allow' statement. Same level of security - a badly done port forwarding will bone you every bit as much as a badly done IPv6 firewall allow statement.
Regarding IP based routing I'd hope that's not being done by individual IP. Replace 'zone' with 'subnet' and you're about there, especially with directly connected networks. These are implicitly 'zoned' to the interface they're connected to.
Right, but as I pointed out the Xbox One changes its UUID every reboot and that is what DHCPv6 uses to determine which client it is. So every reboot it stops getting the IP address I assigned to it so incoming traffic is no longer allowed to the Xbox One. Not sure if I can set it statically in the Xbox One UI, I don't think you could when I tried it only exposed IPv4.
I did try to look into SLAAC but honestly most of the IPv6 documentation is clear as mud to me. I know just enough about IPv4 to do what I require so the IPv6 documentation could just as well be another language.
I'd actually still use IPv6 on the network on specific clients only, but it seems you either have RA enabled and everything get the IPv6 routing, or you don't. I can see the logic in announcing the gateway like this, but it makes testing without a VLAN seem impossible. (don't even get me started on trying to get VLANs working)
Another reason I didn't try further is alll my outgoing server traffic is routed over a VPN via pfSense. Some ports are forwarded from the VPN (bittorrent) and others are forwarded from the WAN. So it kinda makes it complicated as all those ports would be exposed over IPv6 and even if I firewalled them on the server, I'm not sure if I can force torrents to only use IPv4.
-
I'd actually still use IPv6 on the network on specific clients only, but it seems you either have RA enabled and everything get the IPv6 routing, or you don't. I can see the logic in announcing the gateway like this, but it makes testing without a VLAN seem impossible. (don't even get me started on trying to get VLANs working)
Unless it is a limitation of your particular router, there's no reason why enabling IPv6 in any form should impact your IPv4 home network other than a few more broadcasts floating around. You might have to disable IPv6 on certain hosts if you want to keep them on IPv4.
-
Watch the presentation from a Microsoft employee (https://indico.uknof.org.uk/event/41/contributions/541/) about their efforts to get rid of IPv4 completely in their internal corporate network and now also the guest wireless LAN they offer to visitors..
That was a really good watch, thanks for the link Weaver. I’ll definitely be using some of that information in the future for work.
-
Unless it is a limitation of your particular router, there's no reason why enabling IPv6 in any form should impact your IPv4 home network other than a few more broadcasts floating around. You might have to disable IPv6 on certain hosts if you want to keep them on IPv4.
That's the thing, I think the Xbox One is the sticking point as IPv6 is mandatory. If you don't have native it will use Turedo, if it sees native it will use it. But seeing as that's the client I have the biggest problems with trying to allow traffic, its a none-starter.
-
I block Teredo seeing as it would be a hole in my firewall and I don’t have the tools to inspect it’s tunnel payload. I have native IPv6 so there’s something suspicious or very broken about anything that would even want to use Teredo under these circumstances.
-
I block Teredo seeing as it would be a hole in my firewall and I don’t have the tools to inspect it’s tunnel payload. I have native IPv6 so there’s something suspicious or very broken about anything that would even want to use Teredo under these circumstances.
I gotta admit its kinda weird how Microsoft use Teredo as it still seems to open Xbox Live ports the same as it always did over IPv4, so what is it even using it for? There were claims that Xbox One was "supposed" to exclusively use IPv6 for its networking, which surely makes no sense if its doing that?
I've also never seen evidence of Windows 10 using Teredo even when its installed. So its either being very sneaky about it, or flawed.
-
In Vista, if you did not have native IPv6, then certain applications such as Windows Live Messenger demanded IPv6 and so the o/s kicked Teredo into action. I am guessing that an app might insist on sending something to a target IPv6 address, and so a source IPv6 address has to be created somehow for the operation to proceed. It worked well for me. A lot of people moaned about the unreliability of Teredo at some point later on, but I get the feeling that their problems may just reflect problems with UDP-based higher protocols in general, and might not necessarily be confined to Teredo, it’s just that TCP was holding everything together with duct tape, assumptions and retx. If in fact an application is sending way too fast, without TCP then it is maybe no longer getting away with it. Or if there is packet loss in general for no good reason, with UDP alone and lacking extra clue on top of it, then you’re in trouble.
-
This has come to a head and aaisp has been ordered, ipv6 on sky is practically completely broken on pfsense now, same for Ned also.
-
This isn't the Wild West. The UK is one of the most Internet dependent economies in the world. We don't have the luxury of being 'technical leaders' when people can get fined, sued and taken to task by the regulator for downtime.
VM could've actually provided IPv6 a while ago, however they've rethought how they're implementing in return for a better solution.
Either way conservatism is baked into the UK model due to regulation, etc.
Interesting, do you mean a better ipv6 solution, or a better solution that doesnt utilise ipv6?
-
The point is people are USED TO firewalling based on IP address, as this was necessary due to NAT and it simply works. Also how is that much different to IP based routing, which is hardly an unusual thing to be doing?
So how exactly do I allow ALL incoming connections to the games consoles on v6 without allowing it for the entire LAN?
The answer is you get the message across to microsoft to fix their code. They need to disable the dynamic DUID or make it optional. However persistent ipv6 allocations can be done via other methods aside from DUID so its still possible.
One method I would use is exotic but should work.
Put the xbox one on its own VLAN
Setup a dhcp6 on that VLAN with only one ip in its pool also with a low ttl.
Make the appropriate firewall rule.
Another method is akin to what Carl mentioned in not using ip's statically in rules.
Setup an alias that automatically adds any ipv6 to its table, that it grabs from the dhcp6 mapping file. From the hostname you would be able to tell if allocated to the console. Then have a firewall rule that allows traffic to the ports that xbox live needs using the alias as the dest ip. (not sure why you adding rules that allow *, you only need specific ports)
-
I would hope this isn't a problem for anyone. If anyone is firewalling based on IP addresses and require any manual programming they're doing it wrong.
Zone-based firewalls have been the cool thing for a long while now. No need to micromanage anything apart from any exceptions that may be needed.
I meant to chip in on this one. By advising against creating firewall rules based on IP, and using zones instead, does that imply that any host needing special permissions needs to be placed in a different zone? I must admit that when I hear or see "zone" I think only of Cisco's Zone Base Firewall, in which a Zone is a group of interfaces. I don't think I've seen the term used in other firewall products that I've worked with, although they may have equivalent terms for groups of interfaces. Is there a more generic industry-wide concept of what forms a "zone"?
-
I have recently started using MAC address-based rules. A maintenance nightmare; on my wishlist for the firebrick is symbolic names/variable names available pervasively - allowed to be mentioned everywhere. They already have this feature - named sets of IP addresses and you could have a list with just one entry in it. However you cannot use this everywhere - it’s not universal and some things require literal addresses. Also you cannot name sets of MAC addresses, nor can you create named objects that are low…high address ranges nor can you use /nn notation for ranges in all cases. My wishlist item then is a universally valid ip-address expression that can contain sets of ranges and a range can use … or hyphen or /nn or a range can be a single address, and also the same set of ranges for MAC addresses instead.
It would be an aid to maintainability if I could make it easier to keep track of MAC addresses in the face of hw swap-outs.
I currently use a rule that says ”is_pondlife = ! ( mac_address == mac1 || mac_address == mac2 || … ) ; if is_pondlifr then go slow” so that guests get low traffic throttling, but I could use something like this to only allow certain administrators’ machines to access certain critical destinations, for example.
-
The answer is you get the message across to microsoft to fix their code. They need to disable the dynamic DUID or make it optional. However persistent ipv6 allocations can be done via other methods aside from DUID so its still possible.
One method I would use is exotic but should work.
Put the xbox one on its own VLAN
Setup a dhcp6 on that VLAN with only one ip in its pool also with a low ttl.
Make the appropriate firewall rule.
Another method is akin to what Carl mentioned in not using ip's statically in rules.
Setup an alias that automatically adds any ipv6 to its table, that it grabs from the dhcp6 mapping file. From the hostname you would be able to tell if allocated to the console. Then have a firewall rule that allows traffic to the ports that xbox live needs using the alias as the dest ip. (not sure why you adding rules that allow *, you only need specific ports)
I will probably give it another try if Fibre First do my area and I move back to only having Zen as my ISP. Its a none-starter right now as I load balance between Plusnet and Zen to speed up downloads.
-
This has come to a head and aaisp has been ordered, ipv6 on sky is practically completely broken on pfsense now, same for Ned also.
How so? What have they changed?
-
No idea what they changed, basically when initiating the connection it seems 50/50 it will come up, if it fails to come up the ipv6 requests will go unanswered for lifetime of session. If it does come up, usually within a day the ipv6 dhcp6 server sky side will stop responding to renewals and then it will stay down until a new session is started.
It possibly still works ok on sky's own CPE.