NPTv6 / RFC 6296 Support?

RouterOS General
41

I am reading this thread and I am seeing impending doom (only to a few).

Many raised points are valid:

  • not designed for that - per say
  • dual-stack
  • dynamic allocations
  • avoid IPv4 issues

It is like creating an engine with sprockets in which production has a loose variance allowance. Normally that works, but adding two sprockets from the very far end from variance can either stop engine as it will block, or it will spin without even touching each other teeth.

I will post my perspective:

  1. I don’t like dynamic allocations, but I understand why it is done. Removing dynamic allocation will fix the issues for the very few and create issues for many, many more users. We are here quite an internet savvy but think about guys who want just to plug-and-play. Who should give them support to set up static IPv6 prefixes in multiple different routers? We are minority
  2. Dual-stack argument is BS. I am based in the US. T-Mobile US mobile carrier (not mine, just to show the point) is IPv6 only with NAT64 - not always working properly for IPv4 - huge issues with IPv4 wireguard only. My home ISP (Verizon FiOS) is deploying now dual-stack but large portion of the network is IPv4 only. Internet savvy people will go for HE.net tunnel but again - this is a very, very small minority
  3. What I would love the most is own /48 prefix with the possibility of moving this between ISPs. Similar to MNP (Mobile Number Portability) - I can pay for this (i.e. $2-5/month), but it needs to work. This is also minority of users.
  4. I travel a lot so ability to have wireguard at home’s router is very important to me. Hence dual-stack and ability to connect via IPv4 or IPv6 is super extremely important for me. I work in the industry which does not allow to use VPNs and we are locked into country specific IPs (fin-tech - Big 4 banks). Some of my travel is accepted but with the caveat that I will connect to work from home IP range. Again minority
  5. Having all of the above issues/problems/perspectives - NPTv6 with ULA translated to GUA is crucial for me. Paying $200 more to get business service with my ISP does not make sense. Either we want to be trailblazers or followers, and that makes a big difference for me. If I have to change the hardware to something else - I will. Just don’t kid around that this is ICT grade stuff.
42

`
Strongly, strongly disagree. Having think tanks…err, “standards bodies” dictate how operators that are actually “in the trenches” so to speak should design and engineer their networks is NOT the right answer to the problem at hand.

It is exactly this kind of mentality that has gotten us to where we are in the first place. Why do you think that IPv6 has taken so long to gain momentum? Well, if you give network operators a bunch of “thou shalt nots” that, when all taken together, the only way for them to not run afoul of the rules is if they completely tear down their existing networks and rebuild from scratch, then what you have effectively done is put a HUGE barrier to entry in front of them, which ACTIVELY DISCOURAGES them from pursuing v6 roll-out. Whereas if they could simply start handing out v6 addresses to their existing customers OVER THEIR EXISTING NETWORK INFRASTRUCTURE without making a bunch of drastic, time-consuming, and expensive changes, maybe, just MAYBE, there would be a higher adoption rate & more rapid buy-in.

When it comes to the issue of dynamic prefixes in particular, people seem to be under the impression that ISPs only do dynamic addressing in v6 because they are looking at things from a “stone-age v4 mind-set” where IP conservation was the rule. But even if they were right about how some operators are thinking about v6, this still completely gets wrong WHY dynamic IPs exist in the first place in a broadband context. Hint: it’s got nothing to do with conserving IP addresses.

Sure, maybe back in the days of dial-up, it did. After all, if only 10-20% of your subscribers are connected to your network at any given time, then sure: you can oversubscribe IPs just like you can oversubscribe NAS ports/phone trunks, or bandwidth. But in today’s world of fixed broadband where every subscriber’s connection is up 24/7, dynamic IPs still exist EVEN THOUGH you can’t get away with not having AT LEAST one IP address per subscriber allocated at all times.

So it’s not because ISPs are trying to “conserve” their addresses, because if that were the goal, then dynamic IPs in an always-on world would buy you nothing in that regard. You still have to have just as many IPs as you do customers, static or not. No, the reason dynamic IPs are still a thing because it turns out that building a network that can both scale as well as have redundancy built into it is difficult, and can often require trade-offs.

Let’s say that I run an ISP, and I have 10,000 subscribers. And let’s say that I wanted to build it so that I had multiple customer gateways at multiple data centers for redundancy purposes: one gateway goes dark at one data center, a redundant one takes over for it. One whole data center goes dark, then one or more gateways at a different one can take on gatewaying duties for those customers affected by that outage.

Now let’s say that I gave each of those 10,000 customers a single IPv4 static, routable IP address. If any customer on my network could potentially be getting serviced by any gateway, then I now have to inject at least 10,000 separate host routes into my IGP.

Yuck.

So dynamic IP pools are a tool that can be used to summarize prefixes & thus reduce routing table bloat. If every customer serviced by a particular gateway gets assigned an IP address from a block allocated just to that particular gateway, then I can announce out prefixes at least as short as /24, and perhaps even shorter. This helps not only with keeping my routing tables within my AS small, but also makes traffic engineering between my network and the internet at large easier, especially since most upstreams are going to filter out any v4 prefix announcements longer than a /24 anyway. At the same time, for any customer of mine who wants or needs a static IP, I can still throw their address into our internal tables as a /32. But not having to do that for EVERY SINGLE CONNECTION is a big win.

The same principle applies to IPv6: if I give every single customer their own static v6 prefix, now I have to carry all 10,000 of those separate prefixes in the tables of each router on my network. It’s no different.

43

I just love that analogy, and exactly the same all Telecom were saying going against MNP. Oh - thousands lines of code, databases, who will be responsible, etc. My number started years ago with Sprint, then it went to T-Mobile, than to At&T, to now Verizon. As a consumer I don’t care. It has to work!!!

On the other hand, people who want their own prefixes to be static are really really scarce. I don’t know if even 1% of customers would want that.

I work for a company where I do have my own IPv4 public IP address in the corporate network.We have thousands of employees, and hundreds of applications running on own IP addresses. We consume a lot, and we pay for this a lot. As individuals, SME (including SOHO) we can’t do much, it is what it is.

In my previous life I worked for a company doing crazy IoT work (a cross between security/logistics/safety in healthcare). We used a small device to talk with WiFi, our device was working only on 2.4GHz, certain networks which didn’t want to allow fallback to 802.11b had to add certain provisions to its WiFi for us to work. There was always a question - when will you go to 5GHz. And the answer was - never. Multiple reasons, partially it was battery life, partially number of possible configurations at 5GHz vs 2.4GHz, partially physics behind was not as solid on higher frequency than on lower. Go and check IoT devices - if they operate on WiFi it is 99% on 2.4GHz. Because all of the problems with 2.4GHz - most of other manufacturers went to Zigbee or other closed solutions.

We are doing stuff the same way here. We are talking about big ideas, about perfect solutions but life is life. ULA will stay and making it as easy as possible to translate to GUA should be our goal, even it if will cost us some speed.

44

`
I think that you possibly misunderstand my perspective a bit.

See, I am actually 100% in complete agreement with your last paragraph. “We are talking about…perfect solutions but life is life.” EXACTLY.

My read on the reason that IPv6 rollout has been so stagnant for so long is because everybody involved with developing the IPv6 ecosystem has decided that things must be done in some kind of idealistic manner. Where this leads is to: how dare you talk about “hacks”. Hack like… like NAT of any form (even NPT). Hacks like stateful, centralized address assignment and management (i.e., DHCPv6 in “address mode”, vs. SLAAC). Hacks like prefix assignments not along nibble boundaries.

Or even hacks like dynamic prefix allocation.

According to the ideologues, all of these options are off the table, and are to be condemned.

What I’m trying to say is that by taking any and all of these tools off of the table, all that you have done is discouraged and suppressed IPv6 roll-out. It could be so much more entrenched on the internet now if it wasn’t for insisting on “perfection”. It is this insistence that things be done “perfectly” by all parties on the first attempt that has held back progress!!!

But as the saying goes, perfect is the enemy of the good.

Would you rather have imperfect IPv6 roll-out? Or would you rather have none at all? Because what you are getting by insisting on perfection is the latter.

Or, to quote a wise person, “life is life”. :slightly_smiling_face:

If we can come up with tools down the line that enable “portability” of IPv6 address space down to the level of the individual subscriber, I AM ALL FOR THAT. I have nothing against it. But what I’m talking about is what is REALISTICALLY possible TODAY, with the tools that exist right now. I’m not going to delay the roll-out of IPv6 on my network while I wait for people to figure out a more efficient way of extending Provider-Independent prefix routing on the internet to everybody. If easy PI IPv6 routing happens someday, I will be the first in line to cheer it on and implement it!

I am also very much in favor of including as many features into RouterOS as possible that would allow us to deal with oddball problems during this transitionary period. This includes NPT. I would love to see NPT in RouterOS, as well as all other forms of NAT. Should it be our first instinct to use it? No. But can it be a potentially useful tool in the toolbox in certain situations? Absolutely YES! For example, at the moment I’m trying to deal with figuring out how to support IPv6 on MikroTik routers that are sitting behind a mobile LTE hotspot. Since most mobile providers only allocate a single /64 to subscribers, the “best” way of dealing with this would be ND-Proxy, but RouterOS doesn’t HAVE an ND-Proxy feature. Okay, well then guess what the next-best option is? That’s right: NAT. Which RouterOS 7.4 now supports! So absent an ND-Proxy feature, I guess I’m going to be deploying NAT66 behind LTE UEs. And if anybody doesn’t like that, they’ve only got MT to blame for having no ND-Proxy feature in RouterOS, in the year 2022.

My only point here at the outset was to caution against the instinct to punt decisions about the exact details of how network operators “should” engineer their networks up to the think-tanks. That way lies madness, because those guys have proven that they are not about practical and incremental solutions. The only thing that mandating things like “no dynamic IPv6 prefixes” does is put handcuffs on network operators, who are then likely to take a second (or third, or fourth, …) look at IPv6 and go, “screw this”.

45

And all this because it’s hard for him to manage dynamic IPv6 prefixes over Wireguard “for his friends”. http://forum.mikrotik.com/t/wireguard-ipv6-dynamic-prefixes-script-other-solution/159980/1
Probably barking at the wrong tree? I don’t mean to go over and bark at the Wireguard tree, there’s no easy solution to this with any VPN solution (that I know of).
Sure there are things you can do on servers and such but when it comes down to .. smartphones for example, there aren’t many possibilites.

46

One thing that may have gotten lost in the shuffle (and because of the horrible forum software’s way of formatting quote-replies): my initial response here was not to pawlisko, whose response just happened to get in between me and the one I was really responding to, which was pe1chl’s comment that “standards bodies” should make it “formally forbidden” to provide “dynamic IPv6 prefixes to fixed line consumers”.

While we are at it, there are all sorts of other things I suppose that we should “formally forbid”, too.

47

(goes on about how difficult it would be to have static addresses)

Well, it has not prevented our local (Netherlands) fiber and DSL operators from doing it. They all use PPPoE and have several redundant PPPoE servers where customers
connect via the connection network, and everyone has a “static” IPv4 address and IPv6 /48 network. These addresses change only very seldomly and only when there
has been some big architectural change, subscribers receive a letter about it. Maybe once in 5-10 years.
Apparently they have been able to get the routing working correctly. These providers have hundreds-of-thousands to millions of customers.
These PPPoE servers (which of course are not MikroTik, but Juniper or Cisco etc) apparently can handle it.
Not really a surprise, because on internet there are similar numbers of routes. Of course you do not need to load both the internet BGP routes and the local customer
routes in the same router, when you have separate internet-facing and customer-facing routers, so it should be possible to get that right.

I think in countries where dynamic addresses are used, there usually is a bogus “privacy” motive. You get a new address every day, so “the big guys” would not be
able to recognize that you are the same person. Of course that has stopped working years ago, but they still maintain that system (e.g. in Germany this is normal).

Some other ISPs seem to believe that by using dynamic customer addresses they can prevent their customers from “running services” or “use it for business purposes”.
With DynDNS like services, also this can be circumvented.

There should be no real reason not to use static addresses on fixed lines, and it would solve a lot of the issues we see now.
When there really is no will to change this, we should “be allowed to do NAT”. I.e. a range for local addresses that does not have silly strings attached should be
allocated, and it should not be discouraged to do NAT in a consumer router between a static LAN range and the dynamic range they have at that time.

48

Hi,
I agree, most providers understandably just act along their financial interests. If there is no push from the governments (in form of creating regulations which go into enough technical details), they won´t give private households fixed IPs. Even with IPv6 rolled out you only get a /64 , so that you can´t subnet. In Germany they had a long dispute over the obligatory use of provider supplied (and configured) routers.
It´s simple: they will maximize profits and protect the opportunity of selling IPs, selling their hosting business, their cloud services, their IoT offerings etc. If you want better WIFI coverage, buy their better router. Most of the simple end users will not set up DynDNS or configure VPNs, etc. So these protective measures are good enough for the providers.
CGNAT cost them less than to deploy IPv6 with /56 and lose a big chunk of centralised services (what good is it for them if you can just control the heating in your home directly, without relying on a cloud provided servce?).
The costs of IPv6 deployement is in itself negligible, IPv6 is already mostly deployed everywhere, just not on the last mile.
The rules and regulations are always lagging behind.
So what I see as a solution is to have the technology to circumvent most restrictions until politicians catch up and learn the difference between an IPv6 address and an IPv4 address .
NPTv6 is part of it.

The capability of using Netmasks >/64 rfc7608 and full NAT66 are further enhancements.

Regards
W

49

The resource costs of NPTv6 are manageable and RFC6296 IPv6-to-IPv6 Network Prefix Translation has been implemented in RouterOS quite a while ago as @Sob has pointed out at the end of last April (all it takes are two entries in ipv6/firewall/mangle). The real issue is the current state of RFC6724 section 2.1. Policy Table.


If there would be will to assign higher precedence by default to RFC4193 conforming fd00::/8 prefix (ULA) than ::/0 (or at least higher than IPv4) in a manner shown in the RFC6724 section 10.5. Configuring a Multi-Homed Site example (and said change would be implemented by three household name companies who’s operating system are running on the overwhelming majority of client devices) than the case would be closed.

50

On the other side of the pond just Nieuw Amsterdam (currently New York City) urban area has significantly higher population than the Netherlands. Since practically there is no single telecom market in the EU, ISPs face an order of magnitude smaller problems on the East side of the Atlantic.


While being so “advanced” those ISPs still use the CPU cycle intensive PPPoE instead of the CPU cycle frugal DHCP for accounting.


Actually @NathanA has just given some very real reasons of the advantages that dynamic IP addresses may provide for an ISP. Whether the cost savings result in lower fees for their customers is a different story.

CCR1036-2S+ PPPOE-SERVER 600 users fiber with wifi-speed issues on wifi6
51

The reason is that the connection networks and the internet services are handled by different companies here, that are forced to open their services to anyone
who requests. So, there are companies that manage fiber, DSL and cable networks to connect customers, and there are (other) companies that provide internet
services to the customers connected to those networks.
To separate customers of different internet providers at the connection network, PPPoE is used.
Another reason is that that it is mandatory to provide capability to intercept each customer’s line. So while it would be attractive to put decentralized routers which
serve local customers and assign addresses from a local pool, then route that all through the network, that would be difficult to deploy in a legal way, so instead
centralized PPPoE concentrators are used and all customer traffic is sent there.

52

You can use QinQ or just dotQ with PON port isolation + filtering on the OLT itself to prevent intra-VLAN communication based on MAC filers.

This way, you can remove the ancient PPPoE and use a centralised DHCP concentrator instead. No overhead or MTU problems like PPPoE.

53

This objection overlooks the case where SMBs or home users are self-hosting public web services. In these cases, the consumer of said services won’t even be able to detect that the service is being hosted via a ULA address, given that that public DNS will route to a GUA and the NPTv6 translations all happen internally. In cases that involve load balancers which need static IP ranges to operate e.g. most Kubernetes ingress, NPT is a simpler and more reliable solution than passing through dynamic address ranges to each web service and expecting each one of them to reconfigure themselves each time the prefix changes. In fact, pfSense implemented these changes last year (https://redmine.pfsense.org/issues/4881) and they are extremely straightforward to configure and use. And since it happens at the router, the update happens near-instantly. At any rate, claiming that ULA is functionally useless in dual-stacked networks is just flat-out wrong. Rather, the author seems to be missing some of the potential use cases.

54

But that is often not even allowed by those ISPs that change the addresses, or at least the ISP does not want to spend any effort to enable that.
(the changing addresses are often mostly there to discourage users from hosting services, those who want that must get a more expensive account)