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

["Sujay M (sujm)" <[e-mail]>]

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