[BEHAVE] ICMP extensions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[BEHAVE] ICMP extensions



For the ICMP extension in the draft-ietf-v6v4-xlate document, based on
the comments we received from Marcelo and Dan, we would like to have the
following modifications.

2.3. Translating ICMPv4 Headers into ICMPv6 Headers

ICMP Error Payload

* If the received ICMP packet contains an ICMP Extension [RFC4884], the
translation of the ICMP packet will cause the ICMP packet to change
length. When this occurs, the ICMP Extension length attribute MUST be
adjusted accordingly (e.g., longer due to the translation from IPv4 to
IPv6). If the ICMP Extension exceeds the maximum size of an ICMPv6
message on the outgoing interface, the ICMP extension should be simply
truncated.

* For extensions not defined in [RFC4884], the translator passes the
extensions as opaque bit strings and those containing IPv4 address
literals will not have those addresses translated to IPv6 address
literals; this is likely to cause problems with processing of those ICMP
extensions.

3.2. Translating ICMPv6 Headers into ICMPv4 Headers

ICMPv6 Error Payload

* If the received ICMPv6 packet contains an ICMP Extension [RFC4884],
the translation of the ICMPv6 packet will cause the ICMPv6 packet to
change length. When this occurs, the ICMPv6 Extension length attribute
MUST be adjusted accordingly (e.g., shorter due to the translation from
IPv6 to IPv4).

* For extensions not defined in [RFC4884], the translator passes the
extensions as opaque bit strings and those containing IPv6 address
literals will not have those addresses translated to IPv4 address
literals; this is likely to cause problems with processing of those ICMP
extensions.

Any comments?

xing




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.