Is the inclusion of NAT64 and DNS64 support in the Roadmap for RouterOS v5? I think this would be a great help for ISPs wishing to do a rapid deployment of pure IPv6 without breaking access to IPv4 resources.
NAT64 is for scenarioes where you do not allocate a v4 address to the customer, and instead use a gateway to fetch v4 resources on the internet that is then translated back into v6.
Yes, I know that RouterOS works with IPv6 accessing IPv6 resources, and IPv4 accessing IPv4 resources, and dual-stack.
But DNS64 is a helper for NAT64.
NAT64 essentially takes IPv6 requests for IPv4 resources, and maps the IPv4 resources into IPv6 space. Then DNS64 assists in this process by taking A records, and coverting them to AAAA responses in the "mapped" IPv6 space.
This allows Pure IPv6 clients access to IPv4 resources.
Joined: Wed Dec 17, 2008 3:27 am Posts: 130
Karma: 0
NAT64 and DNS64 is something thats going to be needed on a large scale when the last v4 ranges are handed out, Currently the only applications floating around are not production ready.
We do really need a way of running pure v6 inside our entire network and only touching v4 on the edge for net connection, RIR's are tightening up their policies on handing out v4 whilst handing out v6 space like its candy. Today if we had to deploy a pure v6 network we couldnt, Basic things like v6 PPPoE are only just coming into a BETA release that wont be stable for a while, We would have to use v4 space and 6to4 tunnels to provide v6 connections which ties up v4 space
NAT64 is in use via Cisco with T-Mobiles mobile v6 trials and is fast becoming the primary transition method, MT's going to have to polish it's v6 stack quite a bit and perhaps even backport some of the critical v6 features like v6 PPPoE and Dhcp6 back to 4.x
Well, since I do think that eventually we will completely run out of IPv4 Resources and will have to go IPv6 only, any means to let IPv6-only users access the rest of the internet would be very much appreciated
I don't vote for NAT64 for one simple reason. We don't actually need it, at least not yet, I think there are higher priorities. I would like to see Mikrotik complete the IPv6 stack for things such as Hotspot_v6, DHCPv6, Winbox, ssh etc.
NAT64 / DNS 64 allows clients to be setup in a single stack IPv6 only implementation. I don't see any real reason why you would want to be so fast to switch form IPv4 to IPv6 overnight without running dual stack as an intermediate step.
I am in favour of IPv6 + NAT44 or IPv6 + NAT444 depending on then network size.
Clients can be allocated a Private IPv4 address (such as is done on corporate networks) + a public IPv6 address. Servers would need to be allocated Public IPv4 + IPv6 native or IPv4 + 6to4 IPv6 addresses. Since there is a lot more clients than servers the client problem needs to be addressed first.
NAT64 / DNS64 is a way to get rid of the IPv4 stack on the client side; and it's not the only way of acheiving this. DS Lite AP and NAT IVI are alternate methods and of the three I actual prefer the IVI method used for the last few years by CERTNET in China.
Also, I would like to see a stable implementation of NAT64 on Linux Netfilter that Mikrotik can base their work on. Does anyone know if this is available or has tested this?
_________________ regards, dave use my lookup tools
I don't vote for NAT64 for one simple reason. We don't actually need it, at least not yet, I think there are higher priorities.
I agree with you, NAT64/DSN64 will not be indispensable until the address space is exhausted, in the meantime it it more important to have full support for dual-stack features (DHCPv6, prefix delegation, prefix labels, services over IPv6, etc..).
However it has to be ready (and tested) by the time the address space is exhausted otherwise we are in deep s....
Joined: Wed Dec 17, 2008 3:27 am Posts: 130
Karma: 0
Dual stacking only works when you have v4 space to dual stack with, If you dual stack with private v4 space you run into double nat issues, NAT64 is a way around this for some but not all applications
Dual stacking only works when you have v4 space to dual stack with, If you dual stack with private v4 space you run into double nat issues, NAT64 is a way around this for some but not all applications
What problems does it solve? I don't see how it's any better, and considering it's not well tested I expect it would in fact be worse!
_________________ regards, dave use my lookup tools
I don't see how it solves that problem. It's not like there is a NAT46 and DNS46 as well.
We are already an ISP doing Double NAT and we want to get an IPv6 Stack to allow customers to support incoming connections more easily. I don't see how NAT64 can help us. Currently customers have to use UPNP to get an incoming connection. Some applications support UDP hole punching (eg skype) and that seems to work just as well through double NAT as through single NAT.
Whether hole punching works or not has more to do with how many users there are than how many layers of NAT.
_________________ regards, dave use my lookup tools
I see DNS64/NAT64 as a way of getting rid of Dual Stack. It means that a client can have a single IPv6 Stack and connect to IPv6 directly and IPv4 through NAT. Incoming connections must be made to IPv6 address. Outbound connections (to IPv4 anyway) must use the provided DNS.
If you have dual stack Public IPv6 and Private IPv4 you end up acheiving exactly the same result. Difference is 1. That the NAT44 or NAT444 is tried and tested 2. That there are two stacks to contend with.
As I see it, the only real benefit is NAT64/DNS64 is the saving of having a single IP stack.
_________________ regards, dave use my lookup tools
Joined: Wed Dec 17, 2008 3:27 am Posts: 130
Karma: 0
bevhost wrote:
vihai wrote:
double NAT is neither acceptable nor legal here in Italy for ISPs.
You can legislate all you like, but once there is no more IPv4 space to go around thats the end of the game.
I still don't see how NAT64 solves this problem especially if the ISP is not allowed to use NAT.
Because there is no port NAT only address NAT, Its not like what your used to, v6 address port 1000 maps to v4 address port 1000 but then the next connection on port 2000 can map to another v4 address, Its not port natting where you have a couple of hundred users behind a single v4 address and once someone takes port 1000 nobody else can use it, with NAT64 if another user wants to use port 1000 it will map to another v4 address
double NAT is neither acceptable nor legal here in Italy for ISPs.
You can legislate all you like, but once there is no more IPv4 space to go around thats the end of the game.
I still don't see how NAT64 solves this problem especially if the ISP is not allowed to use NAT.
Because there is no port NAT only address NAT, Its not like what your used to, v6 address port 1000 maps to v4 address port 1000 but then the next connection on port 2000 can map to another v4 address, Its not port natting where you have a couple of hundred users behind a single v4 address and once someone takes port 1000 nobody else can use it, with NAT64 if another user wants to use port 1000 it will map to another v4 address
What a load on nonsense. If NAT64 worked like that it would be a huge waste of IPv4 address space and besides, if you wanted NAT44 to work like that then it's pretty easy to do in iptables or ROS.
The IPv4 address pool is a set of IPv4 addresses, normally a prefix assigned by the local administrator. Since IPv4 address space is a scarce resource, the IPv4 address pool is small and typically not sufficient to establish permanent one-to-one mappings with IPv6 addresses. So, except for the static/manually created ones, mappings using the IPv4 address pool will be created and released dynamically. Moreover, because of the IPv4 address scarcity, the usual practice for NAT64 is likely to be the binding of IPv6 transport addresses into IPv4 transport addresses, instead of IPv6 addresses into IPv4 addresses directly, enabling a higher utilization of the limited IPv4 address pool. This implies that NAT64 performs both address and port translation.
_________________ regards, dave use my lookup tools
Joined: Wed Dec 17, 2008 3:27 am Posts: 130
Karma: 0
bevhost wrote:
What a load on nonsense. If NAT64 worked like that it would be a huge waste of IPv4 address space and besides, if you wanted NAT44 to work like that then it's pretty easy to do in iptables or ROS.
The IPv4 address pool is a set of IPv4 addresses, normally a prefix assigned by the local administrator. Since IPv4 address space is a scarce resource, the IPv4 address pool is small and typically not sufficient to establish permanent one-to-one mappings with IPv6 addresses. So, except for the static/manually created ones, mappings using the IPv4 address pool will be created and released dynamically. Moreover, because of the IPv4 address scarcity, the usual practice for NAT64 is likely to be the binding of IPv6 transport addresses into IPv4 transport addresses, instead of IPv6 addresses into IPv4 addresses directly, enabling a higher utilization of the limited IPv4 address pool. This implies that NAT64 performs both address and port translation.
I suggest you gain access to NAT64 devices a v6 client accessing v4 space will use the same port on v4 that the v6 address is attempting to use thus its normal mode is only to address translate and will port translate only when the v4 pool assigned to the NAT64 box is exhausted for the v6 side port
I suggest you gain access to NAT64 devices a v6 client accessing v4 space will use the same port on v4 that the v6 address is attempting to use thus its normal mode is only to address translate and will port translate only when the v4 pool assigned to the NAT64 box is exhausted for the v6 side port
NAT44 will also keep the port the same if it can. However it will always change the port in preference to changing the address. The reason for this is to do with the RELATED state. Firewall hole punching requires the IP Addresses to match to work, If you start changing the address while keeping the port the same, then hole punching will cease to work and it will break heaps of applications.
Joined: Wed Dec 17, 2008 3:27 am Posts: 130
Karma: 0
You dont need hole punching unless the application your attempting to use sends the IP contact info within the packet i.e SIP/RTP/FTP etc
NAT44 is not a solution that helps us, NAT64 does it and much more like allowing pure v6 CPE users to access the v4 world, But perhaps this is a tech that should be kept in the big boys league of Cisco/Juniper as those that will actually run into the NAT44 issues will have the money to buy them
allowing pure v6 CPE users to access the v4 world, But perhaps this is a tech that should be kept in the big boys league of Cisco/Juniper as those that will actually run into the NAT44 issues will have the money to buy them
Finally we actually agree on something. Although I was not aware that Juniper had a NAT64 offering!
_________________ regards, dave use my lookup tools
Last edited by bevhost on Fri Oct 01, 2010 11:34 am, edited 1 time in total.
AFTR (Address Family Transition Router) is the latest product in ISC's family of open source Internet infrastructure products. Developed in concert with Comcast, AFTR 1.0 is intended to ease the transition from IPv4 to IPv6 by allowing legacy IPv4 end sites such as home PCs to interact with IPv4 content providers and services over an IPv6 carrier infrastructure. As with ISC's other products, as the Dual Stack Lite protocol evolves, AFTR will strive to remain an up to date reference implementation as well as a robust enterprise grade router technology.
_________________ regards, dave use my lookup tools
Users browsing this forum: Google Feedfetcher and 4 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Login |
HOME
