Subject: [Int-area] draft-bonica-internet-icmp-12 -- length field for ICMPv6

From: Mark Doll <[email-masked]>
Date: Tue, 14 Nov 2006 12:02:52 +0100

Hi!

I wonder, why you choose to use, for ICMPv6, a 9 bit "original datagram"
length field measured in 32-bit words instead of an 8 bit length field
measured in units of 8 octets. Other IPv6 headers (Routing, Options, Fragment)
also measure in units of 8 octets. The 9 bit length of the length field seems
a bit odd. Or is compatibility with the ICMPv4 spec that important?

Regards, Mark.

P.S.: BTW, although most of your design decisions are deducible after a little
bit of thinking, it would make things easier for the reader if you could
explicitly state:

1. No extensions were defined for ICMPv6 "Packet Too Big" and "Parameter
Problem" due to missing space for an "original datagram" length field (and
not, because the extension does not make sense for these message types).

2. Giving the exact length of "original datagram" in octets to differentiate
the origianl datagram from a possibly added padding is unnecessary, since the
length of the original datagram can be deduced from its own length field,
carried in the IP header of the original datagram itself.

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Nov 2006 12:46:48 -0800

Mark Doll wrote:
...
> carried in the IP header of the original datagram itself.

This is true only if the original IP datagram is included in its
entirety. That's not the case for MTU-sized original datagrams, or any
datagram which is otherwise truncated (e.g., for performance).

Joe

---

From: Christian Vogt <[email-masked]>
Date: Wed, 15 Nov 2006 08:47:48 +0100

Joe Touch wrote:
>> 2. Giving the exact length of "original datagram" in octets to 
>> differentiate the origianl datagram from a possibly added padding
>> is unnecessary, since the length of the original datagram can be
>> deduced from its own length field, carried in the IP header of
>> the original datagram itself.
> 
> entirety. That's not the case for MTU-sized original datagrams, or 
> any datagram which is otherwise truncated (e.g., for performance).

Joe,

FWIW, what Mark suggested was not that the proposed new length field for
the Original Datagram field would be unnecessary, but rather to add some
explanatory text to the draft on why that length field does not need to
require a higher resolution than the current 4-octett resolution.

Specifically, a 1-octett resolution could be used to more easily
separate the non-padding bytes from the padding bytes in the Original
Datagram field.  But again, the existence and actual number of padding
bytes can also be derived using the length field of the encapsulated IP
header.  (If the IP datagram is not fully included, then there is no
padding.  Otherwise, the padding bytes can be calculated by subtracting
the length specified in the encapsulated datagrams IP header from the
length of the Original Datagram field.)

It was just a suggestion to explain this a bit more in the draft to help
the reader understand it more quickly.

Kind regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Nov 2006 06:46:38 -0800

> require a higher resolution than the current 4-octett resolution.

Ahh - agreed, as per below.

Thanks,

Joe