Feature request: Support for RFC 6145 (SIIT - Stateless IP/ICMP Translation)

[toreanderson]

Considering that you've already made a framework that allows for kernel-space translation between IPv4 and IPv6 in the Linux kernel, I would ask you to consider allowing it to operate in fully stateless mode too. You've probably already have most of RFC 6145 implemented, as Stateful NAT64 rely on it a lot, but as far as I can tell, there is no way to configure Jool to disable all the stateful stuff (BIBs and session tables and so on).

In stateless mode, all addresses found in IP/ICMP headers will be translated according to RFC 6052, and everything is done packet by packet, so no session/flow state is being kept. This allows for more flexible routing and better scalability than Stateful NAT64.

If you add an extra feature on top of SIIT, allowing for permanent IPv4:IPv6 mappings, you can allow for stateless translation to arbitrary IPv6 endpoints. I believe this is very useful in IPv6 data centre environments, and I'm working on documenting this use case in I-D.anderson-v6ops-siit-dc which was recently adopted by the v6ops working group. It would be really awesome to be able to use Jool in such deployments. :-)

[ydahhrk]

It's true; Jool only supports stateful (oops, I wrote "stateless" before, sorry) translation at this point.

We once considered adding stateless mode some time ago, but the proposal collapsed on the grounds that everyone seemed happy using Tayga.

Do you consider being a kernel-side component that valuable?

[toreanderson]

I'm thinking that having it in the kernel would be a performance boost. TAYGA is as far as I know a single-threaded process that can't make use of modern multi-core processors. Another thing I'm missing in TAYGA is a dynamic reconfiguration possibility, you have to do a full restart (losing packets in the process), and if there's a syntax error in the new config file it just won't start. It doesn't support RFC6791 or IPv6 Path MTUs above 1280. And finally, TAYGA doesn't seem to be maintained any more. Given that I got a response on this issue after only 10 minutes, the opposite must be true for Jool. :)

[ruben-herold]

From my point of view this could really usefull feature. So as User I must not deploy two different systems for getting the full support for all stuff that is needed for an datacenter solution. So I would appreciate if thsi would be included into jool

[ydahhrk]

Sorry, I'm letting too much time pass without reporting the status, so here it is:

OK, no objections.
Adding to milestone 3.4.0, along with #114 and #115.

[ydahhrk]

Note to ourselves:

The IETF is considering a few updates to Stateless NAT64: http://www.ietf.org/id/draft-gont-6man-deprecate-atomfrag-generation-01.txt

More changes might be underway or already established. We will need to investigate this further.

[toreanderson]

Indeed, Fernando and I are trying to get rid of those «atomic» fragments in that draft. However, I'd like to point out that there's actually nothing new in that draft, all the mechanisms it define are already described in SIIT (RFC6145). The only thing the draft does, really, is to change around the recommended default behaviour.

The key updates from the draft, are:

• Ensuring the translator does not add an IPv6 Fragment Header when translating an IPv4 packet with the DF flag unset (unless the resulting packet needs to be actually fragmented)
• When translating an ICMPv4 Fragmentation Needed to an ICMPv6 Packet Too Big, the resulting MTU is never set to a value lower than 1280, even if the original MTU value in the ICMPv4 FN was lower than 1260.
• When translating an IPv6 packet that are equal to or shorter than 1280 bytes to IPv4, the IPv4 DF flag is unset, regardless of the original IPv6 packet containing an Fragmentation header. (If it does not, the translator must generate a random IPv4 Identification value.)

Also, I work on a separate update to SIIT, that would allow the operator to override the default RFC6052 address translation protocol with a list of static IPv4,IPv6 mappings. This update is currently found in SIIT-DC. I am however planning on separating the normative SIIT update into a separate draft. I'll post an update here when/if I do.

Tore

[ydahhrk]

Thank you 👍

[toreanderson]

As promised, here's the separate draft «Explicit Address Mappings for Stateless IP/ICMP Translation»: draft-anderson-v6ops-siit-eam-00. I'd appreciate feedback on this document, in particular if anything is unclear or confusing. As implementers, you are the target audience for this document! :)

Note that this draft only covers the static mappings. It would probably still be valuable to read through draft-anderson-v6ops-siit-dc, as it describes the use case, and in particular section 5.2 about the possibility of raising the IPv6 Path MTU from its default value from 1280. While the ability to do so is only optional per section 4 of RFC6145, this feature would be most useful in a data centre environment, where an operator can normally be certain that the network will support a Path MTU of 1500 (or even larger).

Another nice thing to have (which TAYGA lacks), is support for the RFC6145 update «Stateless Source Address Mapping for ICMPv6 Packets» (RFC6791).

Do let me know if/when you have any code you'd like me to test, I'd be very happy to. :)

Tore

[ydahhrk]

Interesting.
(Off topic: maybe we should discuss the drafts via e-mail since we might be spamming on people's inboxes - I just updated my profile)

@ruben-herold
@toreanderson
And anyone else reading this:

Would you prefer us to raise the precedence of this? I see a lot of energy in this thread.

Currently, #113 is scheduled for Jool version 3.3.0 and #116 is scheduled for 3.4.0. #113 hasn't seen commits since we're still analyzing the relationship between Keepalived and Jool. Would anyone complain if these issues switch milestones?

Calamitous bugs aside, 3.3.0 is expected to be ready by January 2015 while 3.4.0 does not yet have a due date.

[toreanderson]

Well, I certainly wouldn't mind having support for SIIT to play with by January, quite the opposite. :-) That said, I wouldn't want to be one go «me me me» and "skip the line" either, so to speak. I'm just happy you feel this is a worthwhile addition to Jool, and I don't want to dictate any timeline for when it should be implemented.

Oh, and do feel free to take any comments regarding the drafts off Github and into e-mail. Mine is [email protected].

Tore

[ruben-herold]

I personly have no problem with raising the precedence. Cause from my point of view this feature will be more intrested for the most people.

[ydahhrk]

OK, we're working on this now.
The milestone will be set back a week or so, but I suppose it's worth it.

[ydahhrk]

Thinking out loud:

Stateful NAT64 is transport layer-aware, therefore it requires (some level of) defragmentation.
Stateless NAT64 is not transport layer-aware, therefore it does not require defragmentation.

In fact, it seems to me defragmentation might actually harm the latter, since there seems to be nothing stopping people from having redundant stateless NAT64s at the same time. If there's no defragmentation, different fragments can traverse different stateless NAT64s happily.

Unfortunately, Jool cannot enforce the presence of nf_defrag_ipv4 and nf_defrag_ipv6 in some situations and not in others. Dependencies are resolved at compile time.
Therefore, in order to switch the state-ness of Jool, a recompilation would be required.

Is this annoying?

[toreanderson]

You're quite right, you do not want it to perform reassembly in stateless mode. Incoming fragments should be translated 1:1 (or 1:2, if the output interface MTU or IPv6 Path MTU is too small).

It's not ideal with a compile time switch, as it prevents distributing a single Jool binary kernel module that would work in both modes. So yes, it's slightly annoying, but nothing I couldn't live with. I guess I could always build two modules and distribute both (however I don't know how I could integrate that into automatic kernel module build systems like Akmods or DKMS).

[ydahhrk]

Hmmmm.

Another option is to never enforce defragmentation. Jool would be started by a script. This script would modprobe defrags on stateful mode and remove them on stateless mode.

It's not perfect, because then the dependency would not be explicit, and therefore nothing would prevent careless admins from removing either defrag on the fly. If this happens, stateful Jool would start dropping fragments. But I guess we can warn the admin via the kernel log.

Better?

[toreanderson]

Yes, if you build two sets of modules and then you have the options on which to load then that would work well. But I would suggest calling one "jool_nat64" (or just "jool") for Stateful NAT64 operation (pulling in reassembly code, BIB support, session tables, etc.), and "jool_siit" for SIIT support (pulling in basic RFC6145/6052 translations, EAM support, RFC6791 support, etc.)? That way it's clearer that it's an either/or choice, and the admin is less likely to shoot himself in the foot.

In any case, this is no big deal either way, it's quite possible to live with the recompile flag you originally mentioned too, so don't go jumping through any hoops to make this happen!

[toreanderson]

FYI, I've just uploaded a new version of the SIIT-EAM draft. There is one substantive change in since -01 that you'll probably will want to consider, namely to allow for EAMs where whose IPv4 prefix value has fewer suffix bits than its corresponding IPv6 prefix value. The full diff from -01 can be viewed here.

This change is necessary to support the use case described in RFC6219 (a.k.a. IVI), where the IPv4 address is mapped into bits 41-72 of a /40 translation prefix (this is different from using RFC6052 with a /40 translation prefix, as then the first 24 bits of the IPv4 address will be placed in bits 41-64 and the last 8 bits of the IPv4 address in bits 73-80).

To implement IVI, an operator would configure the EAMT with a single entry such as this one:

+-------------+--------------------+
| IPv4 Prefix |    IPv6 Prefix     |
+-------------+--------------------+
| 0.0.0.0/0   | 2001:db8:ff00::/40 |
+-------------+--------------------+

This will cause the IPv4 address 192.0.2.1 to be translated to 2001:db8:ffc0:2:100:: and vice versa (missing IPv6 suffix bits are zero padded, superfluous IPv4 suffix bits are discarded).

Also, the address translation algorithm specification has been rewritten as a step-by-step procedure with more verbosity (sections 3.3.1 and 3.3.2), based on comments received on the v6ops mailing list. As @ydahhrk and I discussed the previous text at length, I would appreciate it if you would let me know if the new one is as crystal clear as I hope it is (in direct e-mail if you prefer).

Tore

[ydahhrk]

Sorry for the lag again.

In any case, this is no big deal either way, it's quite possible to live with the recompile flag you originally mentioned too, so don't go jumping through any hoops to make this happen!

OK, we're aiming at two separate binaries now, since it looks simple and cleaner.

I've just uploaded a new version of the SIIT-EAM draft.

OK, it's in Jool's scope now.

I would appreciate it if you would let me know if the new one is as crystal clear as I hope it is (in direct e-mail if you prefer).

OK, added to my TODO list (will commit the prototype vanilla SIIT implementation first, since I'm in the middle of it).

---

BTW: Testing so far has taken a while and we're adding stuff on top, so I think the current due date is naive.
We will aim for another week of work, but experience suggests two is more likely. Tentative due date is in the milestone list.

[ydahhrk]

Update.

After a couple weeks of testing, I've concluded it's not viable to support local CLATs or Host-Based Edge Translation modes in this milestone.

The reasoning is that posting a packet for local reception is becoming far more convoluted than we expected:

• Jool needs to link itself to a dummy interface for the translated packet to survive ingress filtering. Because of potential race conditions, the way to do this is still unclear.
  • Ideally maybe, we would call ip_local_deliver() directly (and avoid ingress filtering), but that's not possible because the kernel doesn't export it. It sounds overly reckless anyway.
• Linking Jool to a dummy interface would make --pool4 and --pool6 pointless, since this information could be inferred from the interface's routes instead (and prevent the user from configuring this trivia twice). This is more work.
• Netfilter is just not as versatile as we need. The kernel has two separate pipelines for IPv4 and IPv6 processing; to switch pipelines and remain in the same step (ie. before ingress filtering) we need to call NF_HOOK_THRESH(), but that requires an "OK function", which has to be either ip_rcv_finish() or ip6_rcv_finish(). The kernel also doesn't export either.
  • We can hack this by storing pointers to these functions as they become available in runtime, but this would add a strange dummy packet sending step whenever people modprobes Jool, which is really awkward. It also feels risky since Netfilter is not designed with this kind of setup in mind.
• ip6_input_finish() assumes the control buffers of IPv6 packets survive the Netfilter chain (not cool, Linux...). This means we have to tweak a lot of Jool's code, because we've been assuming we can override that stuff all along. (we can, probably. As long as the packet isn't headed to the local host. I would no longer consider it good practice, though.)

I've been toying with the idea of turning Jool into a device driver instead of a Netfilter module. This would defeat every problem above, but is definitely another-milestone-material.

As it stands, our current plan is to land the last commits to rid Jool from the localCLAT/HBET code and release the resulting Stateful/Stateless NAT64. This, so we can stop stalling the other issues. Jool 3.3 is long overdue.

Sorry.

Discussion welcome.

[ydahhrk]

Oops

When I said "SIIT-DC Host Agent mode" I meant "Host-Based Edge Translator".

Sorry, I just fixed the comment above.

[toreanderson]

Hehe, yes, sorrry about that. I got a suggestion to extend the Host Agent concept so that it would be a network function so that it could support devices that has only an IPv4 stack (or that have an IPv6 stack, but for which no Host Agent implementation is available or easily installed). Since that change made it so that the Host Agent didn't necessarily run on the host, the name didn't really fit any longer.

I intend to rename the "SIIT-DC Gateway" with "Border Translator" too, so that the names correspond better.

That said, from an implementation point of view, there is no difference between a SIIT-DC Gateway and a network-based Edge Translator. They follow exactly the same rules, and do the exact same translations. So Jool would work equally well in both roles.

[ydahhrk]

Hmmm. There might be a misunderstanding here (I'm thinking maybe you read the mail, which didn't get the update). I guess it might not be the case, but just to clarify:

That is correct. We intend to support "most" of

https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-00
https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat-00

What we will not support (in this particular milestone) is the part where the translator is hosted on the same machine that requires dual stack but only has IPv6 connectivity. As it stands, Jool can unfortunately only be used in a forwarding fashion.

(This has actually been a long-standing flaw that didn't catch our attention before because it appears to only be useful on stateless mode.)

[toreanderson]

I understood that, I was just apologising for the name change ("Host Agent" -> "Edge Translator"). It's quite all right that you can't support the host-based stuff at this point, no worries. :-)

Tore

[toreanderson]

On the homepage there's a statement that you're working on switching frameworks, which links to this issue. But this issue is closed...

I assume that framework switching you're referring to is to make Jool operate as a device driver, so you can use it as a 464XLAT CLAT or a SIIT-DC Edge Translator that's providing service for applications running on the local host. So maybe a separate issue should be opened to track the progress of this work?

[ydahhrk]

So maybe a separate issue should be opened to track the progress of this work?

Done; #140.

Will update the homepage later, along with the news of the mailing list.

[hwafiah]

hello, my name fia im from indonesia
i want to ask about SIIT
in my final assignment of SIIT
but the siit method is still not executed properly and correctly.
what did i miss in this step ?
I've followed the step by step in the site https://jool.mx/en/run-vanilla.html
and is there a journal that is the benchmark for my final assignment?
thanks

[ydahhrk]

but the siit method is still not executed properly and correctly.

What do you mean by "siit method"? The modprobe command?

Is there an error message? If so, what is it?

What does dmesg | tail print?

[hwafiah]

modprobe is fine,
what im asking to you is there any chances two pc/client streaming video or data exchanges using SIIT?

[ydahhrk]

For example purposes, I will stream a video from a v6 machine to a v4 machine. I will use VLC as both client and server and through an RTP transport stream.

This is the configuration of the IPv6 server (streaming sender):

sudo ip addr flush dev eth0 scope global
sudo ip addr add 2001:db8:aaaa::8/96 dev eth0
sudo ip route add default via 2001:db8:aaaa::1
sudo ip link set eth0 up

This is the configuration of the IPv4 client (streaming receiver):

sudo ip addr flush dev eth0 scope global
sudo ip addr add 192.0.2.8/24 dev eth0
sudo ip route add default via 192.0.2.1
sudo ip link set eth0 up

And this is the translator:

sudo ip addr flush dev eth0 scope global
sudo ip addr add 2001:db8:aaaa::1/96 dev eth0
sudo ip link set eth0 up

sudo ip addr flush dev eth1 scope global
sudo ip addr add 192.0.2.1/24 dev eth1
sudo ip link set eth1 up

sudo sysctl -w net.ipv4.conf.all.forwarding=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo ethtool --offload eth0 gro off > /dev/null 2>&1
sudo ethtool --offload eth0 lro off > /dev/null 2>&1
sudo ethtool --offload eth1 gro off > /dev/null 2>&1
sudo ethtool --offload eth1 lro off > /dev/null 2>&1

sudo modprobe jool_siit
sudo jool_siit --eamt --add 2001:db8:aaaa::8 203.0.113.8
sudo jool_siit --eamt --add 2001:db8:bbbb::8 192.0.2.8

1. In the v4 machine, open VLC. Then click Media > Open Network Stream...

2. Enter rtp://192.0.2.8 as the network URL, then click Play.

4. The client is now listening:

Now let's create the server.

1. In the v6 machine, open VLC. Then click Media > Stream...

2. Click on the Add... button.

3. Choose a video, then hit Open.

4. Hit Stream.

5. Hit Next.

6. Choose RTP/MGEP Transport Stream, then Add.

7. Enter 2001:db8:bbbb::8 as Address, then hit Next.

8. Turn off transcoding, then hit Next.

9. Hit Stream.

Done:

[hwafiah]

why i can't successed in video streaming? this video don't wanna play in client 2
but if i trry ping in client 1 to client 2 successes.
thank you :)

[ydahhrk]

Sorry, but without access to your environment and also lacking an error message, I can't help you.

Did you attempt to stream a video without a translator in the middle? Removing variables could help you spot the problem.

[hwafiah]

I have successed.
how to save the configuration so it will not lost as i disconnect the lan cable ?
thank you

[ydahhrk]

how to save the configuration so it will not lost as i disconnect the lan cable ?

Jool does not deconfigure itself when you disconnect the LAN cable. It doesn't even interrupt itself; all it happens is that Linux stops sending traffic to it. It should come back on when you reconnect. Are you sure that Jool is what's suffering this problem?

What does happen is that Jool loses its configuration when you turn the machine off or reboot. If this is your problem, then fixing it depends on what your service manager is:

If your distribution uses systemd, try following these instructions. Alternatively, if your distribution uses init.d, try these.

[hwafiah]

okay I understand,
yesterday I've tried streaming video and now I want to try transfer data, can you help me?
I've triend using many applications like samba and direclty using the terminal but stil can not working do you have any suggestions?
thank you

[ydahhrk]

I've triend using many applications like samba and direclty using the terminal but stil can not working do you have any suggestions?

Sorry, I forgot about this.

Listen, we should move this conversation to e-mail, because we're spamming other people by posting here. I know it's late, but if you still need help with that, please let's move this conversation. You can find my e-mail in my Github profile.

[hwafiah]

I wanna ask about journal SIIT, I want to know the results of the performation from siit
thanks