Subject: [BEHAVE] ICMP Extension xlat - draft-ietf-behave-v6v4-xlate-12

From: "Sujay M (sujm)" <[email-masked]>
Date: Tue, 30 Mar 2010 09:55:54 +0530

HI Folks,
 
   I have question on handling of ICMP extension during stateless
translation. 

For ICMPv4 extension messages, the length attribute represents 32-bit
words.
For ICMPv6 extension messages, the length attribute represents 64-bit
words.
When the ICMP extension messages are formed, care is taken that the
original datagram is zero padded to nearest 32-bit boundary for ICMPv4
case (64-bit boundary for ICMPv6)
 
When translation from v4 to v6 happens, the change in length is
generally 20B (The difference in IPv6 and IPv4 header). 
With this change, the ICMP length need not be in 64-bit boundary. 
Eg: ICMPv4 extension length value is 16 => 16 * 4 = 64B
      After translation the "original datagram" length is 64 + 20 = 84B
(This cannot be represented as 64-bit words). 
 
What should be done in this case ?  Should translator do some sort of
padding between end of ICMP packet and start of extension to align the
extension to 64-bit boundary?

Also in the draft (ICMP Error payload section), it is mentioned 
" 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 may cause  problems with processing of those ICMP
extensions."
 
What are the IPv6/IPv4 address literals ?  Is it necessary to dig into
individual cases of extensions to examine this.
Eg : "Extending ICMP for Interface and Next-hop Identification" &  "ICMP
with IP routing instance information"
 
Should the translator just ignore the information in extension and not
take any action on that ? 
(This is what is mentioned in Section 5 of
draft-atlas-icmp-unnumbered-09)
 
Thanks
Regards
Sujay .m

---

From: Xing Li <[email-masked]>
Date: Tue, 30 Mar 2010 13:51:51 +0800

Hi,

> extension to 64-bit boundary?

Yes, padding is required.

In section 3.2. Translating ICMPv4 Headers into ICMPv6 Headers
......

ICMP Error Payload: If the received ICMPv4 packet contains an
ICMPv4 Extension [RFC4884], the translation of the ICMPv4
packet will cause the ICMPv6 packet to change length. When
this occurs, the ICMPv6 Extension length attribute MUST be
adjusted accordingly (e.g., longer due to the translation
from IPv4 to IPv6). If the ICMPv4 Extension exceeds the
maximum size of an ICMPv6 message on the outgoing interface,
the ICMPv4 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 may cause problems
with processing of those ICMP extensions.

Note that the wording reads "the ICMPv6 Extension length attribute MUST 
be adjusted accordingly". Should the document say padding explicitly?

Similar words in section 4.2 Translating ICMPv6 Headers into ICMPv4 Headers
......

ICMP Error Payload: If the received ICMPv6 packet contains an
ICMPv6 Extension [RFC4884], the translation of the ICMPv6
packet will cause the ICMPv4 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 may cause
problems with processing of those ICMP extensions.

> Eg : "Extending ICMP for Interface and Next-hop Identification" & 
> "ICMP with IP routing instance information"

IPv6 address literals is the IPv6 address embedded in the payload, which 
has the IPv6 form, for example 2001:db8:1:2:3::4. Only the ICMP defined 
in RFC4884 requires digging.
> take any action on that ?

Yes, except the ones defined in RFC4884.

> (This is what is mentioned in Section 5 of draft-atlas-icmp-unnumbered-09)
> Thanks
> Regards
> Sujay .m
>
>

Regards,

xing, congxiao

> ------------------------------------------------------------------------
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>