Community discussions

MikroTik App
 
dog
Member Candidate
Member Candidate
Topic Author
Posts: 186
Joined: Wed Aug 12, 2009 3:37 pm
Location: Germany

NPTv6 / RFC 6296 Support?

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
Member Candidate
Member Candidate
Topic Author
Posts: 186
Joined: Wed Aug 12, 2009 3:37 pm
Location: Germany

Re: NPTv6 / RFC 6296 Support?

Wed May 13, 2015 4:41 pm

Any news on this?
Linux kernel 3.13 already seems to have native support for NPTv6.
 
roadracer96
Forum Veteran
Forum Veteran
Posts: 714
Joined: Tue Aug 25, 2009 12:01 am

Re: NPTv6 / RFC 6296 Support?

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
Member Candidate
Member Candidate
Topic Author
Posts: 186
Joined: Wed Aug 12, 2009 3:37 pm
Location: Germany

Re: NPTv6 / RFC 6296 Support?

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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:
  1. Get some PI space from a RIPE member who will register it for you cheaply
  2. use that PI space internally for your network to be independent
  3. and NPTv6 to translate it to the space allocated by the ISP (or the spaces, if we are talking DSL+ UMTS backup).
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8383
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: NPTv6 / RFC 6296 Support?

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?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
roadracer96
Forum Veteran
Forum Veteran
Posts: 714
Joined: Tue Aug 25, 2009 12:01 am

Re: NPTv6 / RFC 6296 Support?

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.
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8383
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: NPTv6 / RFC 6296 Support?

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!"
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: NPTv6 / RFC 6296 Support?

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.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: NPTv6 / RFC 6296 Support?

Fri May 15, 2015 10:51 pm

My proposal is pretty simple:
  1. Get some PI space from a RIPE member who will register it for you cheaply
  2. use that PI space internally for your network to be independent
  3. 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....
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
dog
Member Candidate
Member Candidate
Topic Author
Posts: 186
Joined: Wed Aug 12, 2009 3:37 pm
Location: Germany

Re: NPTv6 / RFC 6296 Support?

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.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: NPTv6 / RFC 6296 Support?

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.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
roadracer96
Forum Veteran
Forum Veteran
Posts: 714
Joined: Tue Aug 25, 2009 12:01 am

Re: NPTv6 / RFC 6296 Support?

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
Forum Veteran
Forum Veteran
Posts: 714
Joined: Tue Aug 25, 2009 12:01 am

Re: NPTv6 / RFC 6296 Support?

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
Member Candidate
Member Candidate
Topic Author
Posts: 186
Joined: Wed Aug 12, 2009 3:37 pm
Location: Germany

Re: NPTv6 / RFC 6296 Support?

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
Forum Guru
Forum Guru
Posts: 5483
Joined: Mon Apr 20, 2009 9:11 pm

Re: NPTv6 / RFC 6296 Support?

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.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: NPTv6 / RFC 6296 Support?

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"?
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: NPTv6 / RFC 6296 Support?

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.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
roadracer96
Forum Veteran
Forum Veteran
Posts: 714
Joined: Tue Aug 25, 2009 12:01 am

Re: NPTv6 / RFC 6296 Support?

Sat May 16, 2015 2:47 am

You lost my attention at "ssl vpns are better". Lol. Really?
 
dog
Member Candidate
Member Candidate
Topic Author
Posts: 186
Joined: Wed Aug 12, 2009 3:37 pm
Location: Germany

Re: NPTv6 / RFC 6296 Support?

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
just joined
Posts: 1
Joined: Tue Sep 05, 2017 3:17 pm

Re: NPTv6 / RFC 6296 Support?

Fri Sep 08, 2017 11:08 pm

Any news from developers about NPTv6 in routeros?
 
Uxorious
just joined
Posts: 4
Joined: Sat Mar 28, 2020 10:48 pm

Re: NPTv6 / RFC 6296 Support?

Sat Mar 28, 2020 10:49 pm

STILL no updates on this?!?
 
mutinsa
just joined
Posts: 24
Joined: Tue Feb 06, 2018 4:55 am
Location: Moscow, Russia
Contact:

Re: NPTv6 / RFC 6296 Support?

Sun Mar 29, 2020 3:36 pm

+1.
Sergey Mutin
Certified Mikrotik Consultant
MikroTik: MTCNA, MTCRE, MTCIPv6E, MTCTCE, MTCUME, MTCINE, MTCWE | Cisco: CCNA R&S | Juniper: JNCIA-Junos | Zabbix: ZCU | Asterisk: dCAA | IPv6 Forum Certified Network Engineer (Silver) | HE.net IPv6: Sage
 
nscheffer
just joined
Posts: 8
Joined: Sun Mar 29, 2020 12:52 am

Re: NPTv6 / RFC 6296 Support?

Sun Mar 29, 2020 3:47 pm

+1 because I got 2x fiber access with IPv4 and IPv6 with different prefix.
 
muetzekoeln
Member Candidate
Member Candidate
Posts: 162
Joined: Fri Jun 29, 2018 2:34 pm

Re: NPTv6 / RFC 6296 Support?

Sun Mar 29, 2020 4:46 pm

+1 ... PLEASE ...

IPv6 really arrived!
 
psannz
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Mon Nov 09, 2015 3:52 pm
Location: Renningen, Germany

Re: NPTv6 / RFC 6296 Support?

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
Forum Guru
Forum Guru
Posts: 6521
Joined: Mon Jun 08, 2015 12:09 pm

Re: NPTv6 / RFC 6296 Support?

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.

Who is online

Users browsing this forum: alexanwar, Shalom, td32 and 170 guests