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?
Any news on this?
Linux kernel 3.13 already seems to have native support for NPTv6.
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.
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:
My proposal is pretty simple:
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.
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, 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.
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.
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ā¦
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.
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.
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.
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.
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)
/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. 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.
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)
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ā?
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.
You lost my attention at āssl vpns are betterā. Lol. Really?
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
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.
Any news from developers about NPTv6 in routeros?