NPTv6 / RFC 6296 Support?

dog · Wed Jan 23, 2013 5:28 pm

So as it stands now most bigger ISPs have decided to still give out dynamic prefixes with IPv6.
That again makes the case for NAT.

NPTv6 provides a simple stateless NAT that only translates one prefix to another.
Any chance we are going to see at least sect. 2.1 of the RFC in a future ROS?

dog · Wed May 13, 2015 4:41 pm

Any news on this?
Linux kernel 3.13 already seems to have native support for NPTv6.

roadracer96 · Fri May 15, 2015 5:39 am

I'm personally against anything to do with nat and IPv6. We don't need another bandaid like nat originally was. Use IPv6 the way it was intended to be used.

dog · Fri May 15, 2015 6:00 am

NPTv6 is not "NAT" as you are implying that would mean "stateful Adress/Port Translation".
NPTv6 does nothing of that sort, it simply does stateless prefix translation.
Also, unlike NATv4 which more or less just "happened" with all kinds of implementation incompatibilities, NPTv6 is very clearly specified by the RFC.

To be clear I see absolutely no point in deploying IPv6 without NPTv6:

The idea of "Everyone who needs a static address just has to get PI and have their ISP route it" already failed. No ISP (in Germany at least) will route your PI space unless you are willing to pay a few thousand EUR per month. And even then: Nowadays every BGP peer will drop IPv4 routes smaller than /24. We'll likely see equivalent development for IPv6.
No business will subscribe to the wacky "just have everything autoconfigured" idea. That would mean we would need to have a DNS infrastructure to back that up, and that would mean DNSSEC - which is more or less dead in the water. Also it would mean having switches with RA guard etc. in every corner of the network, which will just not happen for a long time.
Personally I have no interest in all devices in my home network changing their prefix every 24h – because, yes, even
with IPv6 a residential internet access in Germany still will only get you a dynamic prefix, unless you are willing to fork over twice the money for a business contract.
Because PI is a no-go for many SMBs they will have to go with PA space – which means they are bound to stay with a single ISP unless they are willing to change everything in their internal network (or... DNSSEC), which usually is a lot more work and costs a lot more.

My proposal is pretty simple:

Get some PI space from a RIPE member who will register it for you cheaply
use that PI space internally for your network to be independent
and NPTv6 to translate it to the space allocated by the ISP (or the spaces, if we are talking DSL+ UMTS backup).

Chupaka · Fri May 15, 2015 10:53 am

I'm personally against anything to do with nat and IPv6. We don't need another bandaid like nat originally was. Use IPv6 the way it was intended to be used.

any comments on how to balance a few IPv6 uplinks? or just failover for the home Internet?

roadracer96 · Fri May 15, 2015 1:54 pm

I'm personally against anything to do with nat and IPv6. We don't need another bandaid like nat originally was. Use IPv6 the way it was intended to be used.
any comments on how to balance a few IPv6 uplinks? or just failover for the home Internet?

Don't do it. Do it the right way. Not the hack way.

I'm not sure what the real costs are but a few thousand euros per month sounds pretty steep for announcing a prefix. It'd be a couple hundred dollars a month in the states. Cost of doing business. Do it right or don't do it.

Chupaka · Fri May 15, 2015 5:48 pm

Don't do it. Do it the right way. Not the hack way.

I'm not sure what the real costs are but a few thousand euros per month sounds pretty steep for announcing a prefix. It'd be a couple hundred dollars a month in the states. Cost of doing business. Do it right or don't do it.

it's not a business. if I'll say to a friend of mine, "in IPv4 time you was able to do quick failover to 3G modem when your ADSL line fails, and now, with IPv6, you don't need it - IPv6 ADSL is rock stable" - won't it be a bit funny?

the same for multihoming: "don't balance two cheap ADSL lines, pay $5k to your ISP for fiber!"

Fri May 15, 2015 10:31 pm

I, too, am all in favor of the end of NAT (stateless or otherwise).

There are other ways to accomplish the same goals.
IPv6 allows much more seamless use of multiple addresses than V4 hosts did.
If you have 2 providers, put both prefixes on your hosts at the same time, and then they can all use MPTCP to bond the internet connections. Applications which use UDP can do the same type of behavior to achieve the same result.

PCC+Nat load sharing is NOT the same thing as bonding. No single download can exceed the speed of whichever link it's on, whereas MPTP could go at the full speed of all links combined. Seamlessly.

Don't want to deal with dynamic prefixes? Add a unique-local prefix to your network and configure your in-house services to use those addresses in lieu of the global unicast addresses. Let the devices have the globally routable addresses ALSO so that when they go to the Internet (for upgrades, downloads, etc) then it doesn't matter that their global prefix changes.

Have a server that you want the Internet to reach? Pay the extra $ to get a static prefix.
In fact, you'd only need to have one static prefix because the other dynamic prefix(es) would just be added to the TCP sockets by MPTCP after the initial connection.... or you could pay both providers for static prefixes and publish both routable prefixes in DNS.

IPv6 is our chance to fix some of the horrible things we've been living with for decades due to workarounds necessitated by address depletion. Some of the interesting and useful things we've found out we can use NAT for can be done in other ways.

Fri May 15, 2015 10:51 pm

My proposal is pretty simple:

Get some PI space from a RIPE member who will register it for you cheaply

use that PI space internally for your network to be independent

and NPTv6 to translate it to the space allocated by the ISP (or the spaces, if we are talking DSL+ UMTS backup).

You don't even need PI space - just generate a unique local prefix fc00::/7 prefix. Current practice is to use fd00::/8 with a sufficiently randomly generated 40 bits to follow, giving you a random 'unique' /48 prefix.

http://unique-local-ipv6.com/

These prefixes are analogous to the RFC1918 private IPv4 ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, except they're so much more numerous that if you randomly generate one, the chances are extremely remote that you'll ever come across someone else using the same one. (one in a trillion)

As for PI but no BGP - Given the fact that IPv6 allows header stacking, maybe a new header similar to the dreaded source routing will come into use but one which is more secure, and is transparently negotiable - perhaps a new RR could be invented which allows anyone to look up the current address of your router and add a header to the packets which can be used by your router to route the packet internally within your AS. Your firewall could simply discard packets with such headers that weren't for your network....

dog · Fri May 15, 2015 11:51 pm

Given the fact that IPv6 allows header stacking, maybe a new header similar to the dreaded source routing will come into use

It's already there, and just as horrible as one would think – unless they got rid of it in the recent years:
http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
AFAIK there have already been real-world security issues with header stacking overflowing into the next packet (I don't know which drugs they had to take to allow headers to extend over multiple packets) and firewalls therefore not recognizing that stuff anymore.

You don't even need PI space - just generate a unique local prefix fc00::/7 prefix.

That could work in theory. In practice it will probably just 99% fc00::/48 and 1% fc00::dead:beef:/48 – just like 192.168.0.0/16 did allow for 256 /24s but everyone only ever used 192.168.{0,1,2,178}.0/24.

IPv6 allows much more seamless use of multiple addresses than V4 hosts did.

That might be true for "full-featured OSes" but as soon as you start looking at anything beyond that you are again very limited in configuration.

Also I find it unjustifiable to hand out two or more IPs to every device in the network. That just begs for issues like:

User: Hey, I can't access that file share.
IT: (after 3h of debugging) Well, obviously your PC decided to pick the ISP-assigned source address but our firewall only allows our ULA prefix.
...

If you have 2 providers, put both prefixes on your hosts at the same time, and then they can all use MPTCP to bond the internet connections.

MPTCP is far away in the future.
Not even Linux has included it in the mainline kernel yet, so it will probably be like 10+ years until Windows implements it (if at all).
Also it requires both endpoints to support it, so I'm sure many content providers won't allow it for some political reason.

whereas MPTP could go at the full speed of all links combined. Seamlessly.

I've tested it with some DSL links a few weeks ago and it showed the same ~30% loss (compared to the mathematical sum of all links) that other bonding solutions like Viprinet did.

Sat May 16, 2015 12:33 am

Agreed on the previous rendition of the "source route" header - I was just thinking out loud a bit that something a little more structured and perhaps hash-based might be workable in a way that doesn't require a god-awful huge routing table. If it were standard practice for every ISP/NSP to offer "portable IP endpoints" that would work with such a scheme, and the customers' portable prefixes are discoverable through a service like DNS, then that alleviates the global burden of a truly gargantuan routing table. I hadn't read about packet stack overflow, but it doesn't surprise me.... I guess that's why I'm not writing the RFCs myself. (It's not like I work for IETF or anything, right?)

On the PI prefix issue (you find after 3hrs of debugging that the host chose the global vs. the local address and the firewall blocked it) - that is the same whether you use PI -or- fd00:dead:beef::/48 - Configure the firewall right, and it's not an issue. (the global's still dynamic even with nptv6). I'm not against everyone having PI addresses (it'd be nice, actually - and if there is a way to efficiently route them all without a 2TB routing table everywhere - so much the better) but since most folks won't be able to get routing, there's no need to burn real addresses behind NAT (or in parallel to dynamic real ones - see my non-koolaid comment at the end of this admittedly long post)

As for NPTv6, If there were only ever a stateless prefix-swapping NAT, I could be a little more on board, but I feel that this is a case of give a mouse a cookie, and he's going to demand milk. NAT deployments and features will snowball and make v6 every bit as screwy as v4 became, when v6 could be so much simpler.

You'd be surprised how slow NAT was in the uptake - I had to browbeat customers' not-so-networking-savvy IT contractors into believing that an email server and a web server can both share the same public IP when using NAT.
(back then, customers were routinely getting /26 and /25 networks on their ISDN connections, and I was the NAT NAZI.
If they didn't know how to use name virtual hosting - a VERY new thing back then - I'd basically tell them tough luck! Multiple domains is NOT justification for multiple IP addresses!)

While in the earlier days of IPv4 expansion, I was an early NAT enthusiast (nazi), now I'm strongly in favor of doing away with it. I see IPv6 as a chance to get a fresh start and solve our challenges in new ways that don't require breaking end-to-end connectivity.

One thing about IPv6 I'm not in the crowd of Kool-Aid drinkers on is this whole idea that IPv6 is some practically infinite resource. Current allocation practices are - well the word 'wasteful' is just inadequate to describe it. /56 to home users??? I know *I* need 256 network segments at *MY* house! Yessiree! Heck, I feel wasteful just having the /60 I currently use! And then there's, my company's network that has thousands of hosts in multiple sites in multiple states, yet we get away with around 256 segments of IPv4... A single /52 would carry us for quite some time, yet current allocations guidelines would easily justify us for a /40.

roadracer96 · Sat May 16, 2015 12:41 am

Don't do it. Do it the right way. Not the hack way.

I'm not sure what the real costs are but a few thousand euros per month sounds pretty steep for announcing a prefix. It'd be a couple hundred dollars a month in the states. Cost of doing business. Do it right or don't do it.
it's not a business. if I'll say to a friend of mine, "in IPv4 time you was able to do quick failover to 3G modem when your ADSL line fails, and now, with IPv6, you don't need it - IPv6 ADSL is rock stable" - won't it be a bit funny?

the same for multihoming: "don't balance two cheap ADSL lines, pay $5k to your ISP for fiber!"

I pay 50 usd/month for gigabit fiber. It's stable.

Otherwise. What you propose is nat. It's breaking the end to end connectivity rule. It may be an Rfc but I could write an Rfc stating that all packets cant be larger than 200 bytes but that would break another rule and nobody would follow it and things will break when it's implemented.

roadracer96 · Sat May 16, 2015 12:47 am

Good point. Announce 2 prefixes with RA and with a low lifetime. Failover by disabling a prefix announcement.

Any sort of nat outside of 6to4 for IPv6 only hosts should be abolished.

The point of wasteful assignments is really not founded. The address space really is that vast that it doesn't matter.

dog · Sat May 16, 2015 1:35 am

It's breaking the end to end connectivity rule.

There is no "end to end rule".
"End to End" is a theoretical design maxim, much like the OSI model.
NPTv6 would only be a problem for applications that violate the OSI layer model in regards of separation of concerns - those applications we need "firewall helpers" for today already.

IMHO NPTv6 does not violate the end-to-end principle, as (unlike NAT!) it is a strictly reversible operation.

The NPTv6 RFC explicitly states:

o End-to-end reachability is preserved, although the address used
"inside" the edge network differs from the address used "outside"
the edge network. This has implications for application referrals
and other uses of Internet layer addresses.

Also, come to think of it, NAT has actually helped in IPv4: Because of the feared NAT issues many VPN solutions are now based on SSL instead of IPSec. And SSL turns out to be the better protocol in about every aspect.

The point of wasteful assignments is really not founded. The address space really is that vast that it doesn't matter.

It might be. The numbers with IPv6 are difficult to understand for humans.
What can be said easily though: A 32-bit router needs one operation to check for a match in the IPv4 routing table, which, if you were running BGP was around 300-500MB a few years back IIRC.
For IPv6 a router needs 4 operations, and the same routing table would need 1200 MB+ of RAM.
That is a real-world cost and performance impact that could have been avoided once you remember that going from 32-Bit to 33-Bit would already double the address space – and the fact that 64-bit hardware is cheaply available while 128-Bit is not and won't be probably for quite some time.
Then half of IPv6 seems to be centered around the idea of EUI-48 and the /64-Bit prefixes (which IMHO is another violation of the OSI model), when the IEEE is already thinking about increasing MAC-IDs to 64- or even 128-Bit.
It would likely have been more efficient to directly go with a "variable length address" approach, similar to how OIDs work.

Funnily enough, the IETF rides around their EUI-48 horse for over 10 years, but one month(*) after privacy advocates take note of its implications – poof – there we have privacy extensions everywhere, ridiculing the whole idea of "64-Bit must be the smallest subnet".
Btw: The whole "every network must be 64-Bit" thing smells a lot like the reintroduction of CBR...

(*) sarcasm, not to be taken literally

Don't get me wrong, I'm very much against the idea of NAT to "hide" multiple hosts behind a single IP as everyone else. But what I'm also against is
a) Having my ISP dictate how I layout my internal network
b) Being dependent on an ISP (their PA addresses)

Sob · Sat May 16, 2015 2:20 am

Current allocation practices are - well the word 'wasteful' is just inadequate to describe it. /56 to home users???

/56 for home users might be wasteful, but better than very disturbing trend I see more and more often, where they get just one dynamic /64 and that's it. That's not how I imagined enough addresses for everyone that IPv6 was supposed to bring. Sure, you can hide whole IPv4 internet in that many many times, but you can't even make stupid guest LAN, because everything expects /64 minimum.

A little more on topic, last time I tried to use local fd00::/8 addresses, it didn't go very well. Windows 7 got both local and public addresses just fine, but then insisted on using local one for pretty much everything. Can't connect to Google from fd<something>. It can be reconfigured and from the quick look it seems that it may be already done by default since at least Windows 8.1, but given the current OS share, local addresses are currently not exactly plug and play.

Sat May 16, 2015 2:22 am

IMHO NPTv6 does not violate the end-to-end principle, as (unlike NAT!) it is a strictly reversible operation.

But it DOES - as soon as a protocol sends an endpoint address in-band which is not ACTUALLY reachable by that address, something just got broken. VoIP is the big case, and a SIP helper isn't enough to completely fix the issue. The "deceptively private" in-band address might be a 3rd endpoint not directly in-line between the two SIP speakers (say RTP is redirected to some other org's voicemail server, and it happens to have even a stateful nat in front of it - the actual address of the actual HW is not reachable - some NAT address is. (even 1:1 is NAT - port translation actually came later and strictly speaking, was referred to as NAPT for a while at first)

Don't get me wrong, I'm very much against the idea of NAT to "hide" multiple hosts behind a single IP as everyone else. But what I'm also against is
a) Having my ISP dictate how I layout my internal network
b) Being dependent on an ISP (their PA addresses)

I agree 100% on these points, but NPTv6 doesn't address b) at all. It only prevents you from needing to have dynamic addresses all over your network, which can be solved in other means mentioned earlier. There is zero difference logically between org-local addressing that's un-routeable by designation (fc00::/7) or org-local addressing that's un-routeable because nobody will advertise it into BGP for some reason or other. They're both unreachable islands.

Thus even the static-unchanging internal addresses of a PI range cannot be reached directly even with NPTv6 - the termporary provider-assigned prefix must be used instead.

Again - I agree wholeheartedly with your two goals. However, there are non-NAT ways to achieve them, and I believe whole-heartedly that moving forward with a better solution is preferable to using the old ways that just bring along the baggage of the past, and that nobody is going to be motivated to improve much upon once NAT is firmly entrenched in V6.

I think V6 scarcity is going to bite us in the ass a lot sooner than we think it is if we stay the current course. Certainly not in MY career's lifespan.... I'll be lucky to see the end of V4 before I go back into the dirt..... But our current vision of V6 deployment is analogous to the deployment of V4 back in the classful network days. Nobody's on this thing but nerds and scientists and some military institutions, right? If you assume a /60 is going to probably end up being the basic allocation size for a while for most end users, (and that it's recommended to burn a /64 on a freaking LOOPBACK interface!) - we really only added 28 more bits to our address pool. 60 bits worth of networks is a huge amount of networks to play with - but it will burn up faster than people think if we just throw them around like candy.

Regarding how all this "pie-in-the-sky" dynamic configuration stuff is going to meet with big resistance at the enterprise level - this is true, but I think even this is something that it's high time we addressed. In today's world, BYOD is taking over, and edge port security is going to be important no matter what sort of address assignment mechanisms are in place. Edge port security eliminates the "logging and tracking" elements of the argument for DHCP in the v6 world, so I see that beast going away too. If DHCP were the end-all-be-all of network solidarity, why do we have words like "rogue DHCP" and "arp poisoning"?

Sat May 16, 2015 2:32 am

A little more on topic, last time I tried to use local fd00::/8 addresses, it didn't go very well. Windows 7 got both local and public addresses just fine, but then insisted on using local one for pretty much everything. Can't connect to Google from fd<something>. It can be reconfigured and from the quick look it seems that it may be already done by default since at least Windows 8.1, but given the current OS share, local addresses are currently not exactly plug and play.

OH yeah - there's hurdles to cross. For sure. I mean, when I started out, DHCP was a rare beast. I had to walk many office LANs to configure the new public IP range on every computer (and reboot - Windows3.11/Win95 didn't let you just change it) whenever we brought a new T1 or ISDN customer on board.

They'll get there. Heck, ROS doesn't even support stateless DHCP server to hand out information options like DNS servers, domain name, etc. ( Normis! When can we expect this!?!?!?? )

Interesting about the source address selection.

roadracer96 · Sat May 16, 2015 2:47 am

You lost my attention at "ssl vpns are better". Lol. Really?

dog · Sat May 16, 2015 3:05 am

You lost my attention at "ssl vpns are better". Lol. Really?

Yep, for the very simple fact that SSL/TLS is a proven protocol with widespread use and pretty good understanding of the basic workings in the security community.
IPSec on the other hand
* has much too many switches left to the admin to decide
* Usually takes days to get working between two different vendors
* has so many parameters that no one has even bothered doing a comprehensive security study.

No, really, try to find a scientific analysis of the security of IPSec – there is none.
IPSec is like XML: Everyone says Enterprise uses it, so it must be good but once you start to look for a real source there is nothing (a friend and I once spent a couple of days trying to find a reliable source for the common wisdom that "SOAP is everywhere in the enterprise" for a scientific report. We came up with pretty much nothing.)

Even Ciscos Anyconnect client uses OpenSSL. And while OpenSSL has had it's less than bright moments it is a pretty well understood and tried product. Lots of research goes into OpenSSL security (arguably from both black hats as well as white hats) so when a flaw is discovered it usually doesn't take long until it is publicly known and fixed. I've never seen a similar thing with IPSec.

Do a google search for "ssl secure configuration" and already the first result will give you a good list of recommendations.
With IPSec it is so difficult that most people don't even bother after getting it to work somehow (remember we already spent a couple days by now fiddling with parameters).

Also, unlike IPSec which violates the OSI model, which in turn makes it such a headache to deal with, SSL/TLS is highly portable, especially if you come to think of firewalls and http proxies.

My whole statement is about Remote Access VPN though, Site to Site VPN is a different issue.

Also, I acknowledge that IPSec at least is a standard, while with SSL-VPN every vendor right now cooks up their own protocol, but I'm confident we'll see some standardization there in the future.

publict · Fri Sep 08, 2017 11:08 pm

Any news from developers about NPTv6 in routeros?

Uxorious · Sat Mar 28, 2020 10:49 pm

STILL no updates on this?!?

mutinsa · Sun Mar 29, 2020 3:36 pm

nscheffer · Sun Mar 29, 2020 3:47 pm

+1 because I got 2x fiber access with IPv4 and IPv6 with different prefix.

muetzekoeln · Sun Mar 29, 2020 4:46 pm

+1 ... PLEASE ...

IPv6 really arrived!

psannz · Sat May 23, 2020 4:53 pm

Yes, please! Network Prefix Translation (NPT, RFC6296) would make the adoption of IPv6 for the full network so much easier.
At least those of us, whose IPS won't allow us the use of BGP...

Currently have 3 corporate sites, each connected with a primary fiber connection, and a secondary VDSL or Coax ("Cable") line. Getting a different IPv6 /56 (option for /48 exists) networks from each connection.
The fiber ISPs would allow for BGP, while the "smaller" VDSL and Coax ISPs do not. Therefore, BGP is out.

In effect, this puts me at 6 different IPv6 /56 prefixes. Which is ok.
If I want to retain the redundant internet access, I'd have to either go for IPv6 NAT and Link Local addresses. Which I would like to avoid.
Or use NPT and have the routers swap out the Prefix, depending on which "WAN-in" or "WAN-out" the packet moves through.

pe1chl · Sat May 23, 2020 8:57 pm

Yes, it would be good to have.
But without IPv6 policy routing, still not very useful for the use case you present... you need a different default route for each link, selected by source address.
Possible in RouterOS in IPv4, but not in IPv6.

olegandreych · Sun Mar 13, 2022 7:19 pm

Now we have a PBR for IPv6. So it would be nice to have the RFC6296 implemented.

pe1chl · Sun Mar 13, 2022 7:59 pm

It is implemented! However, last time I looked there was a major defect rendering it unusable. Be patient.

daho · Fri May 13, 2022 9:10 am

Any news about NPTv6 in routeros? Is it working now? Is there a documentation how to configure it in routeros?

Uxorious · Sun May 22, 2022 6:36 am

So much time without any action whatsoever on this

solomon777 · Sun May 22, 2022 7:29 am

RouterOS v7 support ipv6 to ipv6 translation, i don't know if it's the same technology as NPTv6, but it works.

un9edsda · Sun Jun 05, 2022 8:45 pm

Yes, please! Network Prefix Translation (NPT, RFC6296) would make the adoption of IPv6 for the full network so much easier.
At least those of us, whose IPS won't allow us the use of BGP...

@Sob in Feature Request: IPv6 NAT66 Support in post #71 wrote a pair of sample firewall rules for NPTv6:

/ipv6 firewall mangle
add chain=postrouting action=snpt src-address=fd00:1234:5678:9a00::/56 src-prefix=fd00:1234:5678:9a00::/56 dst-prefix=publ:icpr:efix:b700::/56
add chain=prerouting action=dnpt dst-address=publ:icpr:efix:b700::/56 src-prefix=publ:icpr:efix:b700::/56 dst-prefix=fd00:1234:5678:9a00::/56

However please read his next (#72) post in that thread for his caveat against it. viewtopic.php?p=934680#p934676
Actually those are the results of RFC6296 section 2.6 Checksum-Neutral Mapping https://datatracker.ietf.org/doc/html/r ... ection-2.6

It is worth keeping in mind when planing to use NPTv6 with Unique Local Addresses (ULA) that:

by default in line with RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) section 2.1. Policy Table ULA address won't be used in case of a dual stack setup https://datatracker.ietf.org/doc/html/r ... ection-2.1
ULA should be allocated from the fd00::/8 subnet in an RFC4193 Unique Local IPv6 Unicast Addresses section 3.2.2 conforming manner https://datatracker.ietf.org/doc/html/r ... tion-3.2.2

There is a useful summary of the pitfalls of using ULA at https://blogs.infoblox.com/ipv6-coe/ula ... k-networks however one should note that the author seems to be focusing on large enterprise( network)s which have the possibility to use Provider Independent (PI) IPv6 addresses.

While we are at it @IPANetEngineer in IPv6 and NAT - how I changed my mind in post #45 provided sample firewall rule for IPv6 masquerade:

/ipv6 firewall nat
add action=masquerade chain=srcnat dst-address=2000::/3 src-address=\
    200:c01d:c01a:beef::7ac0/128 to-address=2603:XXXX:XXXX:XXXX::2/128

buraglio · Tue Jun 07, 2022 6:14 pm

Related to the ULA discussion - ULA is functionally useless in dual stacked networks, as highlighted in the infloblox blog post above. It will almost never be used, so your mileage may vary if there is an expectation of using v6 by default in the presence of any IPv4 at all. There is an IETF draft in process highlighting these issues available here https://datatracker.ietf.org/doc/draft- ... v6ops-ula/

nb

Yes, please! Network Prefix Translation (NPT, RFC6296) would make the adoption of IPv6 for the full network so much easier.
At least those of us, whose IPS won't allow us the use of BGP...

@Sob in Feature Request: IPv6 NAT66 Support in post #71 wrote a pair of sample firewall rules for NPTv6:
Code: Select all
/ipv6 firewall mangle
add chain=postrouting action=snpt src-address=fd00:1234:5678:9a00::/56 src-prefix=fd00:1234:5678:9a00::/56 dst-prefix=publ:icpr:efix:b700::/56
add chain=prerouting action=dnpt dst-address=publ:icpr:efix:b700::/56 src-prefix=publ:icpr:efix:b700::/56 dst-prefix=fd00:1234:5678:9a00::/56
However please read his next (#72) post in that thread for his caveat against it. viewtopic.php?p=934680#p934676
Actually those are the results of RFC6296 section 2.6 Checksum-Neutral Mapping https://datatracker.ietf.org/doc/html/r ... ection-2.6

It is worth keeping in mind when planing to use NPTv6 with Unique Local Addresses (ULA) that:
by default in line with RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) section 2.1. Policy Table ULA address won't be used in case of a dual stack setup https://datatracker.ietf.org/doc/html/r ... ection-2.1

ULA should be allocated from the fd00::/8 subnet in an RFC4193 Unique Local IPv6 Unicast Addresses section 3.2.2 conforming manner https://datatracker.ietf.org/doc/html/r ... tion-3.2.2
There is a useful summary of the pitfalls of using ULA at https://blogs.infoblox.com/ipv6-coe/ula ... k-networks however one should note that the author seems to be focusing on large enterprise( network)s which have the possibility to use Provider Independent (PI) IPv6 addresses.

While we are at it @IPANetEngineer in IPv6 and NAT - how I changed my mind in post #45 provided sample firewall rule for IPv6 masquerade:
Code: Select all
/ipv6 firewall nat
add action=masquerade chain=srcnat dst-address=2000::/3 src-address=\
    200:c01d:c01a:beef::7ac0/128 to-address=2603:XXXX:XXXX:XXXX::2/128

pe1chl · Tue Jun 07, 2022 7:12 pm

Related to the ULA discussion - ULA is functionally useless in dual stacked networks, as highlighted in the infloblox blog post above. It will almost never be used, so your mileage may vary if there is an expectation of using v6 by default in the presence of any IPv4 at all. There is an IETF draft in process highlighting these issues available here https://datatracker.ietf.org/doc/draft- ... v6ops-ula/

What solution do you propose for those that have a dynamic IPv6 address and want static addresses on their LAN, so they use some form of NAT between their
LAN and the public IPv6 prefix valid at that moment?
Just grab some random public IPv6 address that appears not to be in use, but is not considered ULA?

un9edsda · Sat Jun 18, 2022 2:43 am

Related to the ULA discussion - ULA is functionally useless in dual stacked networks, as highlighted in the infloblox blog post above. It will almost never be used, so your mileage may vary if there is an expectation of using v6 by default in the presence of any IPv4 at all. There is an IETF draft in process highlighting these issues available here https://datatracker.ietf.org/doc/draft- ... v6ops-ula/

While the Infoblox blog post makes a compelling case for not using ULA in dual stack environments it can't see the wood for the trees. It seems that the recommendation only considers networks which have provider independent (PI) IPv6 address space as for the rest GUA may be a suboptimal solution for various reasons.
It is not just theoretically possible to change the precedence value of ULA, at least not on computers running GNU/Linux or Microsoft Windows operating systems.
In case of current GNU/Linux systems all it takes is adding the following two lines to /etc/gai.conf

label fd00::/8 1
precedence fd00::/8 41

I got the idea from the following comment on Reddit https://www.reddit.com/r/ipv6/comments/ ... &context=3

In case of recent Microsoft Windows operating systems it takes only one line in Windows PowerShell run with administrator privilege:

netsh interface ipv6 add prefixpolicy fd00::/8 41 1

as explained in this Super User Q&A https://superuser.com/questions/1469774 ... 78#1469778

Two things to keep in mind in case of using NPTv6 and ULA (without GUA on the LAN side) on recent RouterOS (7.3.1 or 7.4beta2). The first one is that

/ipv6 firewall filter
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid

rule included in the Building Advanced Firewall section of the RouterOS documentation https://help.mikrotik.com/docs/display/ ... d+Firewall has to be disabled in the firewall otherwise for example

ping6 -c 5 google.com

would time out.

The second one is that if the

/ipv6 firewall filter
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

rule (which is included both in the default configuration and the Building Advanced Firewall example) is kept enabled than the IPv6 connectivity test on http://test-ipv6.com/ site will fail.

un9edsda · Sat Jun 18, 2022 2:59 am

What solution do you propose for those that have a dynamic IPv6 address and want static addresses on their LAN, so they use some form of NAT between their
LAN and the public IPv6 prefix valid at that moment?
Just grab some random public IPv6 address that appears not to be in use, but is not considered ULA?

Although the question was not for me I do have an answer for it. I went with not distributing the received GUA prefix (neither with Neighbor Disoververy nor with DHCPv6 server) on the LAN side, rather distributing only the ULA prefix with those two methods and added the as of now undocumented NPTv6 rules provided by @Sob to the ipv6 firewall and changed the clients preferences regarding ULA. However this does not solve the issue of not being able to subnet the network as the ISP provides a /64 prefix. Well one step a time.

buraglio · Sat Jul 02, 2022 11:52 pm

I am not proposing a solution - that isn't the point. The point of the IETF draft as well as the InfoBlox article is that there is a problem. At this time it is a problem without a good solution. If you read the IETF draft, it clearly explains that - if it doesn't let me know and I will update it. FWIW, Ed (author of the infoblox article) and myself did the majority of the testing over the last year and wrote that draft.

The TL;DR is that ULA is a broken and useless in a dual stacked environment. It's fine in an IPv6-only deployment, mostly. There is no current workaround outside of editing the getadrinfo() table, which as also pointed out in the draft, is not a viable solution for a number of reasons not the least of which is embedded and IoT devices as well as network hardware. NPTv6 solves some of the issues but it really a different solution space. I am posting this here because use of ULA will never, ever, by default, lead to the expected behavior of preferring IPv6 when v4 is also present.

pe1chl · Sun Jul 03, 2022 11:55 am

Ok then the IETF need to allocate a new local address range for use in such scenarios and not attach such silly strings to it...
(so that addresses on that range are not somehow considered "inferior to IPv4")
I would say that any range normally allocated to routed customers would do.

buraglio · Sun Aug 14, 2022 5:19 pm

IETF can only request such a range from IANA, several of us wrote a draft requesting 200::/7 for lab space, but it was not adopted and has since expired. Given my experience so far, I would not expect that any time soon, as there is a long tail to the process, but we will continue to refine and request. Regardless of what needs to happen, ULA is almost entirely broken in dual stacked networks, and our prior draft has now been adopted as an official WG document. Understanding the history of RFC6724 is important here, ULA was never intended to be an analog to RFC1918 space, in fact, there are specific details that preclude it (such as the source address selection noted above). There is significant pushback on address translation in the IPv6 standard bodies.

nb

Ok then the IETF need to allocate a new local address range for use in such scenarios and not attach such silly strings to it...
(so that addresses on that range are not somehow considered "inferior to IPv4")
I would say that any range normally allocated to routed customers would do.

pe1chl · Sun Aug 14, 2022 8:40 pm

There is significant pushback on address translation in the IPv6 standard bodies.

Maybe they can make it formally forbidden to issue dynamic IPv6 prefixes to fixed line consumers. That would remove a prominent reason for wanting to do address translation.

pawlisko · Mon Aug 15, 2022 7:47 pm

Maybe they can make it formally forbidden to issue dynamic IPv6 prefixes to fixed line consumers. That would remove a prominent reason for wanting to do address translation.

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.

NathanA · Wed Aug 17, 2022 4:06 am

There is significant pushback on address translation in the IPv6 standard bodies.
Maybe they can make it formally forbidden to issue dynamic IPv6 prefixes to fixed line consumers.

`
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.

pawlisko · Wed Aug 17, 2022 6:54 am

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.
(...)
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.

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.

NathanA · Wed Aug 17, 2022 8:10 am

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!!!

[...]

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.

`
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".

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".

Znevna · Wed Aug 17, 2022 9:49 am

And all this because it's hard for him to manage dynamic IPv6 prefixes over Wireguard "for his friends". viewtopic.php?t=188233
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.

NathanA · Wed Aug 17, 2022 11:12 am

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. </sarcasm>

pe1chl · Wed Aug 17, 2022 12:11 pm

Maybe they can make it formally forbidden to issue dynamic IPv6 prefixes to fixed line consumers.
`
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.

(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.

woland · Wed Aug 17, 2022 1:18 pm

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

un9edsda · Fri Feb 17, 2023 4:38 am

... 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.

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.

Ok then the IETF need to allocate a new local address range for use in such scenarios and not attach such silly strings to it...
(so that addresses on that range are not somehow considered "inferior to IPv4")

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.

un9edsda · Fri Feb 17, 2023 5:15 am

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.
(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. ...
Apparently they have been able to get the routing working correctly. These providers have hundreds-of-thousands to millions of customers.

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.

These PPPoE servers (which of course are not MikroTik, but Juniper or Cisco etc) apparently can handle it.

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

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.

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.

pe1chl · Fri Feb 17, 2023 11:47 am

These PPPoE servers (which of course are not MikroTik, but Juniper or Cisco etc) apparently can handle it.
While being so "advanced" those ISPs still use the CPU cycle intensive PPPoE instead of the CPU cycle frugal DHCP for accounting.

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.

DarkNate · Wed Feb 22, 2023 9:07 pm

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.

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.

chewie198 · Tue Aug 22, 2023 8:50 pm

Related to the ULA discussion - ULA is functionally useless in dual stacked networks, as highlighted in the infloblox blog post above. It will almost never be used, so your mileage may vary if there is an expectation of using v6 by default in the presence of any IPv4 at all. There is an IETF draft in process highlighting these issues available here https://datatracker.ietf.org/doc/draft- ... v6ops-ula/

nb

@Sob in Feature Request: IPv6 NAT66 Support in post #71 wrote a pair of sample firewall rules for NPTv6:

However please read his next (#72) post in that thread for his caveat against it. viewtopic.php?p=934680#p934676
Actually those are the results of RFC6296 section 2.6 Checksum-Neutral Mapping https://datatracker.ietf.org/doc/html/r ... ection-2.6

It is worth keeping in mind when planing to use NPTv6 with Unique Local Addresses (ULA) that:
by default in line with RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) section 2.1. Policy Table ULA address won't be used in case of a dual stack setup https://datatracker.ietf.org/doc/html/r ... ection-2.1

ULA should be allocated from the fd00::/8 subnet in an RFC4193 Unique Local IPv6 Unicast Addresses section 3.2.2 conforming manner https://datatracker.ietf.org/doc/html/r ... tion-3.2.2
There is a useful summary of the pitfalls of using ULA at https://blogs.infoblox.com/ipv6-coe/ula ... k-networks however one should note that the author seems to be focusing on large enterprise( network)s which have the possibility to use Provider Independent (PI) IPv6 addresses.

While we are at it @IPANetEngineer in IPv6 and NAT - how I changed my mind in post #45 provided sample firewall rule for IPv6 masquerade:

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.

pe1chl · Tue Aug 22, 2023 9:19 pm

This objection overlooks the case where SMBs or home users are self-hosting public web services.

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)