Subject: [v6ops] Regarding 6145bis

From: Alberto Leiva <[email-masked]>
Date: Wed, 30 Sep 2015 16:32:09 -0500

> Fragmented ICMP/ICMPv6 packets will not be translated by the IP/ICMP
> translator.

Is this due to some security concern?

I can see why fragmented pings can't be handled by a stateless translator,
due to the need to add or remove the ambiguous layer 4 length to/from the
ICMP checksum's pseudoheader, but a Stateful NAT64 that collects fragments
does have access to this information (and is not difficult or slow to
handle).

I suggest:

    Fragmented ICMP/ICMPv6 packets will not be translated by stateless
    IP/ICMP translators. Such packets MAY be translated by stateful IP/ICMP
    translators.

> An IP/ICMP translator has two possible modes of operation: stateless
> and stateful [RFC6144].  In both cases, we assume that a system (a
> node or an application) that has an IPv4 address but not an IPv6
> address is communicating with a system that has an IPv6 address but
> no IPv4 address, or that the two systems do not have contiguous
> routing connectivity and hence are forced to have their
> communications translated.

Take this with a grain of salt (I'm aware it makes it less elegant).

"OR they might have contiguous routing connectivity but are interacting via
masking addresses (ie. hairpinning)."

Right?

> the translator MAY provide a configuration function for the network
> administrator to adjust the threshold of the minimum IPv6 MTU to a
> value that reflects the real value of the minimum IPv6 MTU in the
> network (greater than 1280 bytes).

> The translator MUST provide a configuration
> function for the network administrator to adjust the threshold of the
> minimum IPv6 MTU to a value greater than 1280-byte if the real value
> of the minimum IPv6 MTU in the network is known to the administrator.

This is a MAY, then a MUST. What's happening?

> If the DF flag is not set and the IPv4 packet will result in an IPv6
> packet larger than 1280 bytes, the packet SHOULD be fragmented so the
> resulting IPv6 packet (with Fragment Header added to each fragment)
> will be less than or equal to 1280 bytes.  For example, if the packet
> is fragmented prior to the translation, the IPv4 packets should be
> fragmented so that their length, excluding the IPv4 header, is at
> most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the
> Fragment Header).  The translator MUST provide a configuration
> function for the network administrator to adjust the threshold of the
> minimum IPv6 MTU to a value greater than 1280-byte if the real value
> of the minimum IPv6 MTU in the network is known to the administrator.
> The resulting fragments are then translated independently using the
> logic described below.

Especially if you decide to MUST the requirement above, why not declare it
as a variable from the start?

Something like

    If the DF flag is not set and the IPv4 packet will result in an IPv6
    packet larger than a user-defined length (hereinafter referred to as
    "lowest-ipv6-mtu", and which defaults to 1280 bytes), the packet SHOULD
    be fragmented so the resulting IPv6 packet (with Fragment Header added
    to each fragment) will be less than or equal to lowest-ipv6-mtu.
    (...)

> If the DF bit is set and the packet is not a fragment (i.e., the More
> Fragments (MF) flag is not set and the Fragment Offset is equal to
> zero), then the translator SHOULD NOT add a Fragment Header to the
> resulting packet.  The IPv6 header fields are set as follows:

Why is this worth mentioning? You already said "an IPv6 Fragment Header is
only included if the IPv4 packet is already fragmented."

I also recommend separating the last sentence into another paragraph.

> If the IPv4 packet is discarded, then the translator SHOULD be able
> to send back an ICMPv4 error message to the original sender of the
> packet, unless the discarded packet is itself an ICMPv4 message.

s/is itself an ICMPv4 message/is itself an ICMPv4 error message

I've always seen pings generating ICMP errors no problem.

> The translator MUST support stateless address mapping algorithm
> defined in [RFC6052],

> The stateless translator MUST support explicit address mapping
> algorithm defined in [I-D.ietf-v6ops-siit-eam].

> [stateless/stateful] IP/ICMP translators that are built specifically to
> implement such a protocol, MAY forego implementing the above address
> mapping algorithms.

Is this not a contradiction? MUST MUST then MAY.

Even in the stateless case, why are both mandatory?

Traditional SIIT became an RFC without EAM and nobody complained. In
addition, the EAMT can hold 0.0.0.0/0 as an entry, which will match any
IPv4 packets, thereby removing the need for 6052 translation. In fact,
0.0.0.0/0 can behave just like a /96 6052 prefix. (If the user doesn't need
the other prefix lengths, why force the implementation to support 6052?)

> Thanks to Tore Anderson and Alberto Leiva Popper for the proposal of
> the explicit address mapping (EAM) algorithm.

Can you please remove my second last name there :-)? I'm the only one with
two.

Thanks