New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an IPv6 pool6791 #176

ydahhrk opened this Issue Sep 30, 2015 · 1 comment


None yet
1 participant
Copy link

ydahhrk commented Sep 30, 2015

IPv6 pool6791 = A pool of IPv6 addresses used to source untranslatably-sourced ICMPv4 errors with.

Better explained in this e-mail:

Because all it does is prepend a prefix, the address translation algorithm from RFC 6052 can take any IPv4 address as input and generate an IPv6 address as a result.

Because it depends on an input IPv6 address containing the prefix, the opposite is not true: It cannot generate an IPv4 address out of any IPv6 address.

I think this is the reason why RFC 6791 requires an IPv4 address pool but doesn't even mention an IPv6 pool; assuming RFC 6052 is the only address translation algorithm at play, any IPv4 router will source ICMPv4 errors in translatable ways. It's IPv6 routers that need to be masked with special IPv4 addresses.

If we're defining new address translation algorithms, I think we risk breaking this assumption. In particular, EAM breaks it. It is entirely possible to configure an EAM table where not every IPv4 address is translatable. (ie. pretty much any EAMT that doesn't include

Now, it's true that EAM can be used in concert with RFC 6052 translation (therefore making every IPv4 address translatable), but Tore and I agree that there are use cases where EAM can be used without the 6052 falling back option ( For this reason, it would be asinine for an implementation to force the presence of a 6052 prefix in the configuration as long as there is at least one entry in the EAMT. This could (though in SIIT/DC it doesn't seem to be an issue) lead to a situation where an IPv4 router answers an ICMPv4 error and the translator will have to drop it because its source address doesn't match the EAMT.

I don't know if this is a problem; I'm just theorizing. But it seems to me an "IPv6 RFC 6791 pool" should be defined, if not for the sake of EAM, for the sake of any future address translation algorithms, either IETF-defined or homemade...

@ydahhrk ydahhrk added this to the 4.1.0 milestone Sep 30, 2015

ydahhrk added a commit that referenced this issue Jun 9, 2016

Review of #176, part one
The most significant problems were redundant iterations and
missing some random-needing bytes.

It appears the RFC6791v6 prefix cannot be unset; I need to query
Roberto on this. (ie. there will be a part two)

Also addressed about 10 small TODOs all over the place.

@ydahhrk ydahhrk modified the milestones: 3.5.0, 4.1.0 Jun 15, 2016


This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment