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

[Xing Li <[e-mail]>]

Hi,

Sujay M (sujm) 写道:
> 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?

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.

> 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"

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.
> Should the translator just ignore the information in extension and not 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>