 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Thomas Narten wrote:
This would seem inconsistent with the following wording in RFC 2460:Nodes MUST always be able to receive fragment headers. However, if it does not implement path MTU discovery it may not need to send fragment headers. However, nodes that do not implement transmission of fragment headers need to impose a limitation to the payload size of layer 4 protocols.
In response to an IPv6 packet that is sent to an IPv4 destination
(i.e., a packet that undergoes translation from IPv6 to IPv4), the
originating IPv6 node may receive an ICMP Packet Too Big message
reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node
is not required to reduce the size of subsequent packets to less than
1280, but must include a Fragment header in those packets so that the
IPv6-to-IPv4 translating router can obtain a suitable Identification
value to use in resulting IPv4 fragments. Note that this means the
payload may have to be reduced to 1232 octets (1280 minus 40 for the
IPv6 header and 8 for the Fragment header), and smaller still if
additional extension headers are used.
Oops, yes.
So, this should be changed to:Nodes MUST always be able to send and receive fragment headers. (rest of the text deleted)how about: Nodes MUST always be able to send and receive fragment headers. Note that even in the case where a sender does not implement or use Path MTU discovery [RFC 1981], the sender must still be prepared to send fragment headers, even for packets that are smaller than the minimal IPv6 link MTU of 1280 octets. See Section 5 of [RFC 2460] for details.
Sounds good. Pekka Savola's slight modification of this is OK, too. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------