Missing IP literals from the documentation. #111

Closed
ydahhrk opened this Issue Oct 17, 2014 · 2 comments

Projects

None yet

3 participants

@ydahhrk
Member
ydahhrk commented Oct 17, 2014

Our documentation is completely silent on the topic of IP literals, one of the major drawbacks of NAT64 and something every user should know.

In the meantime, here's a little rushed introduction, slightly edited from my mail to our troubled user:

Some protocols on top of UDP and TCP have a bad habit of including IP addresses ("IP literals") along their conversations. This is a problem, because NAT64 only mangles certain network headers (IPv4, IPv6, ICMPv4, ICMPv6) and certain transport headers (UDP & TCP).
If a IPv4 server sends your IPv6 client a IPv4 address, your client will find itself in trouble because it doesn't technically know it's talking via a NAT64, so it doesn't know it has to append the IPv6 prefix to the IPv4 address it just received.
NFS seems to follow this bad habit. Whenever NFS uses IP literals, it renders itself incompatible with NAT64.

BTW: we should try to compile a list of common protocols which suffer from this quirk, and include whether IP literals render these protocols completely useless or just somewhat limited.

As for solutions:

  1. The most straightforward way to solve your problem would be to use some other file-sharing protocol. Hopefully, your second candidate will not use IP literals.
  2. If you'd like to insist on using NFS, notice that Juan Francisco seems to have ended up with a working setup: http://www.atm.tut.fi/list-archive/snap-users/msg01891.html. Because I'm not familiar with either NFS nor FreeBSD, I don't really know what he did.
  3. Some protocols might provide IP literals as a fallback option when domain names are not available. If you have a DNS64 working and you can feed the domain name to your NFS server, then your NFS server might send the domain name instead of the IP literal. This would be great, because then your IPv6 client would query your DNS64 server and the latter would transparently append the NAT64 prefix to the IPv4 address it returns to the client. I don't really know if NFS features this option, though.
@ydahhrk ydahhrk self-assigned this Oct 17, 2014
@toreanderson
Contributor

464XLAT (RFC6877) solves this (see http://github.com/toreanderson/clatd for an example implementation)

Tore

@ydahhrk ydahhrk assigned dhfelix and unassigned ydahhrk Nov 14, 2014
@ydahhrk ydahhrk added this to the 3.3.0 milestone Nov 14, 2014
@ydahhrk ydahhrk added a commit that referenced this issue Dec 11, 2014
@ydahhrk ydahhrk Moving Jool from Prerouting to Local In, Local Out and Forwarding.
This is necessary so NAT64 happens after iptables does filtering.
It's also needed so Jool catches local traffic, which is needed by local CLATs.
As an added bonus, it invalidates issue #90. Woot!

Progress so far, summary:
- Issue #33: Done.
- Issue #41: Done.
- Issue #107: Done.
- Issue #111: dhfelix is done, but haven't even started to review.
- Issue #116: EAM done, moved from prerouting done, dummy interface done. Missing (off the top of my head):
	- Adapting the global packet processing pipeline for stateless mode.
	- Configuration options.
	- Review RFC 6145 and updaters.
- Issue #120: Done.
- Issue #121: Not done.

Everything needs testing. There are known bugs with fragmentation.
fa8b0c2
@ydahhrk ydahhrk closed this Mar 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment