Re: [v6ops] New Version Notification for draft-bao-v6ops-rfc6145bis-01.txt

</chair>

In both cases, I think the logic was to carry as much of the IP datagram and payload as possible with a good probability of delivery to the destination of the ICMP message. I the last 1980's (when most of RFC 1812 was actually written), 576 was a very real number. A number of things converged, the most important one being, perhaps, CIDR (which meant that a host couldn't necessarily determine whether the address of a remote destination was or was not within its own network) that made people move away from the magic in the number. In IPv6, there have been multiple attempts to pick a magic number that "all" networks can support, winding up in the 1240/1280 range. But the point of this exercise was never, I think, to pick a number. It was to get the ICMP message along with whatever it could return back to the host that sent the message it was responding to.

I think I would conclude that if the translator sends as much as it can, it is within sight of the intent.
________________________________________
From: v6ops [v6ops-bounces@ietf.org] on behalf of Alberto Leiva [ydahhrk@gmail.com]
Sent: Wednesday, August 26, 2015 9:54 AM
To: Xing Li
Cc: v6ops@ietf.org
Subject: Re: [v6ops] New Version Notification for draft-bao-v6ops-rfc6145bis-01.txt

Say

Something about 6145 has been bothering me for a while. Regarding ICMP
error length:

RFC 1812 section 4.3.2.3 says "the ICMP [error] datagram SHOULD
contain as much of the original datagram as possible without the
length of the ICMP datagram exceeding 576 bytes."

RFC 4443 says "[The ICMP payload should measure] as much of invoking
packet as possible without the ICMPv6 packet exceeding the minimum
IPv6 MTU."

I don't know how current or realistic these constraints are. I
apologize if I've been living under a rock.

Regardless:

Since the minimum IPv6 MTU is not the same as the IPv4 MTU, a
translator can end up with an "illegal" ICMP error. Following the
numbers above, after removing both IPv6 headers and attaching both
IPv4 headers, a resulting IPv4 packet can be an ICMPv4 error and span
1240 bytes.

For the sake of correctness, shouldn't the translator truncate it?
(And update the outer ICMP checksum accordingly)

On Tue, Aug 11, 2015 at 7:47 PM, Xing Li <xing@cernet.edu.cn> wrote:
> Hi, All,
>
> According to the conclusion made in v6ops meeting of IETF93, (removing
> the EAM part and refer to EAM draft), we have updated the
> draft-bao-v6ops-rfc6145bis, please review. Thanks.
>
> Regards,
>
> xing
>
>> Name:         draft-bao-v6ops-rfc6145bis
>> Revision:     01
>> Title:                IP/ICMP Translation Algorithm (rfc6145bis)
>> Document date:        2015-08-07
>> Group:                Individual Submission
>> Pages:                38
>> URL:            https://www.ietf.org/internet-drafts/draft-bao-v6ops-rfc6145bis-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/
>> Htmlized:       https://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-bao-v6ops-rfc6145bis-01
>>
>> Abstract:
>>    This document describes the Stateless IP/ICMP Translation Algorithm
>>    (SIIT), which translates between IPv4 and IPv6 packet headers
>>    (including ICMP headers).  This document updates RFC 6145.
>>
>>
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops