Subject: [Gen-art] Gen-art review of draft-bonica-internet-icmp-14

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 18 Jan 2007 15:26:57 -0500

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>

Please resolve these comments along with any other Last Call comments
you may receive.

Document: Modifying ICMP to Support Multi-part Messages
Summary: This document is on the right track, but there are open issues
that should be resolved before publishing

Comments
---------

1. I don't see why more care wasn't taken to ensure interoperability
with existing ICMP specifications and implementations.

1.1 Section 5 should really define three classes of applications
      - (legacy) support non-extended
      - (legacy  support non-extended and non-compatible extensions
      - (new) support non-extended, non-compatible extensions and
compatible extensions
It should list how a consumer can tell the messages apart and what
implementers can do to maximize interoperability.

1.2 Each of the sections in section 5 should be more clear as to whether
or not backwards compatibility (interoperability) is guaranteed,
possible or not possible. It reads more like the results of a lab
experiment then requirements against implementations. Reading between
the lines it seems like section 5.1 can't guarantee compatibility but it
is likely unless implementers do some of the things noted. Similarly for
5.2. 5.3 seems a bit more promising.

1.3 Section 5.5 should make it mandatory to "include a non-default
operation mode to also interpret non-compliant responses."

Nits
-----

1. Shouldn't the title of the document be more along the lines of
"Extended ICMP to Support Multi-part Messages" or "Modified ICMP to
Support Multi-part Messages"

2. In section 2, last paragraph, last sentence, it says "whenever a
packet is dropped to to TTL expiration."

3. In section 3, it says "The following is a summary of changes to ICMP
that are proposed by this memo:", but that should likely now read
"introduced by this memo".

4. Section 4 lists all the ICMP messages and says that "Many ICMP
messages are extensible as currently defined" but doesn't say which are
which. This information is given in section 4.6. It would seem cleaner
if these were combined into a single section.

5. Section 4, after the bullets, the first paragraph starts with "Many
ICMP messages are extensible as currently defined" while the second
paragraph starts with "Many ICMP messages are not extensible as
currently defined" which is awkward. I would suggest replacing one or
the other with "Some" or "Many other" or something to indicate which is
the more common or be more neutral. They both can't be many.

6. In section 4, on page 7, about half way down, it says "Because the
sixth octet of each of the impacted ICMPv4 messages was reserved for
future use" which explains how we can just start using these bits. This
explanation should come earlier in the document.

7. In section 4.6, last paragraph, it raises a requirement against
future ICMP extensions which seems a bit too buried in the document.

8. In section 5, third paragraph is says "Some ICMP implementations,
produced between 1999 and the present," but the present is a moving
target. Suggest specific date or say "time of publication of this memo".

9. In section 5.1, first paragraph, last sentence it says "To date, only
two applications falling into this category have been identified and the
degree to which they are effected is minimal." Is this saying they
mostly behaved as expected as defined in the ICMP documents? The phrase
is way too loose. Similarly the next paragraph talks about minimal
impact.

10. In section 5.2, fifth paragraph, it says "parse an ICMPv4 message
incorrectly " which is a bit ambiguous. Do we mean tradition ICMPv4
messages or the ones defined in this memo or for this use case do they
look the same?

11. In section 5.2, fifth paragraph, the bullets list three conditions
under which the message won't get parsed properly, two of which don't
seem to apply to the use case of 'Non-compliant Application Receives
ICMP Message With No Extensions'

12. In section 5.2, last paragraph is says "A similar analysis can be
performed for ICMPv6.  However, the numeric
   constants would change as appropriate." This should really read about
the expectation on achieving backwards compatibility (interoperability),
not the expectation on lab results.

13. In section 5.3, second paragraph it says "Provided that the entire
ICMP messages does not exceed." That should be "message"

14. In section 5.3, second paragraph is says "However, each vendor will
decide how many octets to include." That should say "However, each
implementation will decide how many octets to include."

15. Section 5.3 should be written in the context of how to achieve
interoperability/backwards compatibility.

17. In section 5.5, last paragraph it says "will treat the following
octets" but I think that should be "will treat the octets that follow"
to not confuse it with document text indicating that the list will be
outlined below in the RFC.

18. In section 6, first paragraph, last sentence says "by the first 128
octets of the "original datagram" field, ICMP extensions and NAT will
not interact with one another." Interact seems a poor choice of words.
It can be interpreted as either interoperate (good) or interfere (bad).

19. In section 6, second paragraph, is it saying you will get
interaction with NATS unless implementations do something that is not
explicitly forbidden or is it something that is illegal?

20. In section 7, first paragraph, it says "This memo proposes an
optional ICMP Extension Structure that can be appended to the ICMP
messages referenced in Section 4.6 of this document" which makes it
sounds like the messages were originally defined in this document, but
they weren't. An additional reference to the RFC(s) they were defined in
would help.

21. In section 7, second paragraph, it says "MAY process selected
objects while ignoring others." which makes it sound arbitrary. I
believe based on what is in the next sentence that they are only
ignoring stuff they don't understand?

22. In section 7, the version of this stuff is defined to be 2. Do other
ICMP messages have different versions? Is this a way to tell them apart
when they are received?

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Jan 2007 10:42:59 +0100

I take Sharon's points but I haven't quite convinced myself
they add up to a DISCUSS. So I will log this review as a COMMENT
and would be interested to see some conversation about it.

(There is a minor bureaucratic DISCUSS issue, however, which
I will document shortly.)

    Brian

---

From: Ron Bonica <[email-masked]>
Date: Fri, 26 Jan 2007 21:55:38 -0500

Hi Sharon,

Thanks for the thoughtful review. Lots of responses inline, below.

I have attached a new version of the draft which I will post in a bit.

                                  Ron

> with existing ICMP specifications and implementations.

Addressed in the 1.1, 1.2 and 1.3.

> implementers can do to maximize interoperability.

These three classes map cleanly to what the draft calls "classic",
"non-compliant" and "compliant" applications. But I don't think that you
are suggesting that I rename the categories. (That would be too easy!)

I think that you are really asking, "How can an application tell one
class of ICMP message from another?"

There is a very clean way to tell a fully-compliant, extended ICMP
message from any other. That is to look at the length attribute.

But therein lies the problem! Only the fully-compliant application is
smart enough to look for a length attribute. So, we are left with the
problem of figuring out how classic and non-compliant applications will
deal with messages of a different class. This is the goal of sections
5.1 through 5.5.

> 5.2. 5.3 seems a bit more promising.

Backwards compatibility is guaranteed in Section 5.4 only. Sections 5.1,
5.2, 5.3 and 5.5 provide an exhaustive list of conditions under which
backwards compatibility is not achieved. In these sections, we also
point out that for each error condition, either the probability of error
is extremely low or the consequences of error are extremely small.

> operation mode to also interpret non-compliant responses."

Done (by changing the MAY to a MUST)

> Support Multi-part Messages"

done

> packet is dropped to to TTL expiration."

fixed

> "introduced by this memo".

done

> if these were combined into a single section.

done

> the more common or be more neutral. They both can't be many.

done

> explanation should come earlier in the document.

I would like to push back on this one a little bit. In the previous
paragraph I say "Space for the length attribute is claimed from reserved
octets, whose value was previously required to be zero."

I can't introduce the topic much earlier than that, because I have only
introduced the attribute in the previous paragraph.

> future ICMP extensions which seems a bit too buried in the document.

done. I have moved this to section 3.

> target. Suggest specific date or say "time of publication of this memo".

done

> is way too loose. Similarly the next paragraph talks about minimal

The next two paragraphs are dedicated to those two applications. I think
that they address your concern, but maybe I am missing something?

> messages or the ones defined in this memo or for this use case do they

We are talking about a traditional ICMP message. No extensions.

There is never a problem when the original datagram field is less that
144 octets. (This speaks for all of the implementations that we have
seen so far.) However, it is legal to for an implementation to send 500
octets in the Original Datagram field. So, we have to deal with that
possibility.

Since the original datagram payload can be *anything*, there is an
extremely remote possibility that it might look like a valid ICMP
extension structure.

I realize that the odds against this are astronomical, but we need to
consider the possibility.

> ICMP Message With No Extensions'

I think that this is the same issue that we addressed in 10.

> not the expectation on lab results.

I'm not sure what you are saying. Could you try to say it a different way?

> ICMP messages does not exceed." That should be "message"

Fixed

> implementation will decide how many octets to include."

fixed

> interoperability/backwards compatibility.

I'm not sure what you are saying. Could you try to say it a different way?

> outlined below in the RFC.

done

> It can be interpreted as either interoperate (good) or interfere (bad).

done

> explicitly forbidden or is it something that is illegal?

Yes. I am saying the following:

- it would be illegal for NAT to do this
- but even if it did, it wouldn't be so bad. This is because the outcome
would be an extended ICMP message that is missing a length attribute. In
Section 5 we convinced ourself that we could live with that.

> they weren't. An additional reference to the RFC(s) they were defined in

I would like to push back on this a little bit. Section 4.6 defines a
only a small subset of the messages that are defined in RFC 792 and RFC
4443. I am trying to be specific about extending *only* those messages.

> ignoring stuff they don't understand?

That's exactly what I am getting at. An application shouldn't toss the
entire ICMP message if it sees an object that it doesn't understand.

> ICMP messages have different versions? Is this a way to tell them apart

This is an indiscretion of my youth. There was a version 1, but it was
never deployed. The non-compliant legacy stuff all uses version number 2.

                               Ron

> Canada

Internet                                                       R. Bonica
Internet-Draft                                                    D. Gan
Intended status: Standards Track                        Juniper Networks
Expires: July 30, 2007                                       P. Nikander
                                           Ericsson Research Nomadic Lab
                                                               D. Tappan
                                                            C. Pignataro
                                                     Cisco Systems, Inc.
                                                        January 26, 2007

              Extended ICMP to Support Multi-part Messages
                     draft-bonica-internet-icmp-15

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document redefines selected ICMP messages to support multi-part
   operation.  A multi-part ICMP message carries all of the information
   that ICMP messages carried previously, as well as additional

Bonica, et al.            Expires July 30, 2007                 [Page 1]

Internet-Draft          Multi-part ICMP Messages            January 2007

   information that applications may require.

   Multi-part messages are supported by an ICMP extension structure.
   The extension structure is situated at the end of the ICMP message.
   It includes an extension header followed by one or more extension
   objects.  Each extension object contains an object header and object
   payload.  All object headers share a common format.

   This document further redefines the above mentioned ICMP messages by
   specifying a length attribute.  All of the currently defined ICMP
   messages to which an extension structure can be appended include an
   "original datagram" field.  The "original datagram" field contains
   the initial octets of the datagram that elicited the ICMP error
   message.  Although the original datagram field is of variable length,
   the ICMP message does not include a field that specifies its length.
   Therefore, in order to facilitate message parsing, this draft
   allocates eight previously reserved bits to reflect the length of the
   "original datagram" field.

   The proposed modifications change the requirements for ICMP
   compliance.  The impact of these changes on compliant implementations
   is discussed, and new requirements for future implementations are
   presented.

   This memo updates RFC 792 and RFC 4443.

Bonica, et al.            Expires July 30, 2007                 [Page 2]

Internet-Draft          Multi-part ICMP Messages            January 2007

Table of Contents

   1.  Conventions Used In This Document  . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Summary of Changes to ICMP . . . . . . . . . . . . . . . . . .  5
   4.  ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  ICMPv4 Destination Unreachable . . . . . . . . . . . . . .  8
     4.2.  ICMPv4 Time Exceeded . . . . . . . . . . . . . . . . . . .  9
     4.3.  ICMPv4 Parameter Problem . . . . . . . . . . . . . . . . .  9
     4.4.  ICMPv6 Destination Unreachable . . . . . . . . . . . . . . 10
     4.5.  ICMPv6 Time Exceeded . . . . . . . . . . . . . . . . . . . 10
     4.6.  ICMP Messages That Can Be Extended . . . . . . . . . . . . 11
   5.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 11
     5.1.  Classic Application Receives ICMP Message With
           Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  Non-compliant Application Receives ICMP Message With
           No Extensions  . . . . . . . . . . . . . . . . . . . . . . 14
     5.3.  Non-compliant Application Receives ICMP Message With
           Compliant Extensions . . . . . . . . . . . . . . . . . . . 15
     5.4.  Compliant Application Receives ICMP Message with No
           Extensions . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.5.  Compliant Application Receives ICMP Message with
           Non-compliant Extensions . . . . . . . . . . . . . . . . . 15
   6.  Interaction with Network Address Translation . . . . . . . . . 16
   7.  The ICMP Extension Structure . . . . . . . . . . . . . . . . . 16
   8.  ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 17
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   12. Testing  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     13.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

Bonica, et al.            Expires July 30, 2007                 [Page 3]

Internet-Draft          Multi-part ICMP Messages            January 2007

1.   Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   This document redefines selected ICMPv4 [RFC0792] and ICMPv6
   [RFC4443] messages to include an extension structure and a length
   attribute.  The extension structure supports multi-part ICMP
   operation.  Protocol designers can make an ICMP message carry
   additional information by encoding that information in the extension
   structure.

   This document also addresses a fundamental problem in ICMP
   extensibility.  All of the ICMP messages addressed by this memo
   include an "original datagram" field.  The "original datagram" field
   contains the initial octets of the datagram that elicited the ICMP
   error message.  Although the "original datagram" field is of variable
   length, the ICMP message does not include a field that specifies its
   length.

   Application software infers the length of the "original datagram"
   field from the total length of the ICMP message.  If an extension
   structure were appended to the message without adding a length
   attribute for the "original datagram" field, the message would become
   unparsable.  Specifically, application software would not be able to
   determine where the "original datagram" field ends and where the
   extension structure begins.  Therefore, this document proposes a
   length attribute as well as an extension structure that is appended
   to the ICMP message.

   The current memo also addresses backwards compatibility with existing
   ICMP implementations that either do not implement the extensions
   defined herein or implement them without adding the required length
   attributes.  In particular, this draft addresses backwards
   compatibility with certain, widely deployed, MPLS-aware ICMPv4
   implementations that send the extensions defined herein without
   adding the required length attribute.

   The current memo does not define any ICMP extension objects.  It
   defines only the extension header and a common header that all
   extension objects share.  [I-D.atlas-icmp-unnumbered],
   [I-D.shen-icmp-routing-inst] and [I-D.ietf-mpls-icmp] provide sample
   applications of the ICMP Extension Object.

Bonica, et al.            Expires July 30, 2007                 [Page 4]

Internet-Draft          Multi-part ICMP Messages            January 2007

   The above mentioned memos share a common characteristic.  They all
   append information to the ICMP Time Expired message for consumption
   by TRACEROUTE.  In this case, as in many others, appending
   information to the existing ICMP Time Expired Message is preferable
   to defining a new message and emitting two messages whenever a packet
   is dropped due to TTL expiration.

3.  Summary of Changes to ICMP

   The following is a summary of changes to ICMP that are introduced by
   this memo:

      An ICMP Extension Structure MAY be appended to ICMPv4 Destination
      Unreachable, Time Exceeded, and Parameter Problem messages.

      An ICMP Extension Structure MAY be appended to ICMPv6 Destination
      Unreachable, and Time Exceeded messages.

      The above mentioned messages include an "original datagram" field,
      and the message formats are updated to specify a length attribute
      for the "original datagram" field.

      When the ICMP Extension Structure is appended to an ICMP message
      and that ICMP message contains an "original datagram" field, the
      "original datagram" field MUST contain at least 128 octets

      When the ICMP Extension Structure is appended to an ICMPv4 message
      and that ICMPv4 message contains an "original datagram" field, the
      "original datagram" field MUST be zero padded to the nearest 32-
      bit boundary.

      When the ICMP Extension Structure is appended to an ICMPv6 message
      and that ICMPv6 message contains an "original datagram" field, the
      "original datagram" field MUST be zero padded to the nearest 64-
      bit boundary.

      ICMP messages defined in the future SHOULD indicate whether or not
      they support the extension mechanism defined in this
      specification.  It is recommended that all new messages support
      extensions.

4.  ICMP Extensibility

   RFC 792 defines the following ICMPv4 message types:

Bonica, et al.            Expires July 30, 2007                 [Page 5]

Internet-Draft          Multi-part ICMP Messages            January 2007

      - Destination Unreachable

      - Time Exceeded

      - Parameter Problem

      - Source Quench

      - Redirect

      - Echo Request/Reply

      - Timestamp/Timestamp Reply

      - Information Request/Information Reply

   [RFC1191] reserves bits for the "Next-Hop MTU" field in the
   Destination Unreachable message.

   RFC 4443 defines the following ICMPv6 message types:

      - Destination Unreachable

      - Packet Too Big

      - Time Exceeded

      - Parameter Problem

      - Echo Request/Reply

   Many ICMP messages are extensible as currently defined.  Protocol
   designers can extend ICMP messages by simply appending fields or data
   structures to them.

   However, the following ICMP messages are not extensible as currently
   defined:

      - IPv4 Destination Unreachable (type = 3)

      - IPv4 Time Exceeded (type = 11)

      - IPv4 Parameter Problem (type = 12)

      - IPv6 Destination Unreachable (type = 1)

Bonica, et al.            Expires July 30, 2007                 [Page 6]

Internet-Draft          Multi-part ICMP Messages            January 2007

      - IPv6 Packet Too Big (type = 2)

      - IPv6 Time Exceeded (type = 3)

      - IPv6 Parameter Problem (type = 4)

   These messages contain an "original datagram" field which represents
   the leading octets of the datagram to which the ICMP message is a
   response.  RFC 792 defines the "original datagram" field for ICMPv4
   messages.  In RFC 792, the "original datagram" field includes the IP
   header plus the next eight octets of the original datagram.
   [RFC1812] extends the "original datagram" field to contain as many
   octets as possible without causing the ICMP message to exceed the
   minimum IPv4 reassembly buffer size (i.e., 576 octets).  RFC 4443
   defines the "original datagram" field for ICMPv6 messages.  In RFC
   4443, the "original datagram" field always contained as many octets
   as possible without causing the ICMP message to exceed the minimum
   IPv6 reassembly buffer size (i.e., 1280 octets).

   Unfortunately, the "original datagram" field lacks a length
   attribute.  Application software infers the length of this field from
   the total length of the ICMP message.  If an extension structure were
   appended to the message without adding a length attribute for the
   "original datagram" field, the message would become unparsable.
   Specifically, application software would not be able to determine
   where the "original datagram" field ends and where the extension
   structure begins.

   In order to solve this problem, this memo introduces an 8-bit length
   attribute to the following ICMPv4 messages.

      - Destination Unreachable (type = 3)

      - Time Exceeded (type = 11)

      - Parameter Problem (type = 12)

   It also introduces an 8-bit length attribute to the following ICMPv6
   messages.

      - Destination Unreachable (type = 1)

      - Time Exceeded (type = 3)

   The length attribute MUST be specified when the ICMP Extension
   Structure is appended to the above mentioned ICMP messages.

   The length attribute represents the length of the "original datagram"

Bonica, et al.            Expires July 30, 2007                 [Page 7]

Internet-Draft          Multi-part ICMP Messages            January 2007

   field.  Space for the length attribute is claimed from reserved
   octets, whose value was previously required to be zero.

   For ICMPv4 messages, the length attribute represents 32-bit words.
   When the length attribute is specified, the "original datagram" field
   MUST be zero padded to the nearest 32-bit boundary.  Because the
   sixth octet of each of the impacted ICMPv4 messages was reserved for
   future use, this octet was selected as the location of the length
   attribute in ICMPv4.

   For ICMPv6 messages, the length attribute represents 64-bit words.
   When the length attribute is specified, the "original datagram" field
   MUST be zero padded to the nearest 64-bit boundary.  Because the
   fifth octet of each of the impacted ICMPv6 messages was reserved for
   future use, this octet was selected as the location of the length
   attribute in ICMPv6.

   In order the achieve backwards compatibility, when the ICMP Extension
   Structure is appended to an ICMP message and that ICMP message
   contains an "original datagram" field, the "original datagram" field
   MUST contain at least 128 octets.  If the original datagram did not
   contain 128 octets, the "original datagram" field MUST be zero padded
   to 128 octets.  (See Section 5.1 for rationale.)

   The following sub-sections depict length attribute as it has been
   introduced to selected ICMP messages.

4.1.  ICMPv4 Destination Unreachable

   Figure 1 depicts the ICMPv4 Destination Unreachable Message.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     unused    |    Length     |         Next-Hop MTU*         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: ICMPv4 Destination Unreachable

Bonica, et al.            Expires July 30, 2007                 [Page 8]

Internet-Draft          Multi-part ICMP Messages            January 2007

   The syntax and semantics of all fields are unchanged from RFC 792.
   However, a length attribute is added to the second word.  The length
   attribute represents length of the padded "original datagram" field,
   measured in 32-bit words.

   * The Next-Hop MTU field is not required in all cases.  It is
   depicted only to demonstrate that those bits are not available for
   assignment in this memo.

4.2.  ICMPv4 Time Exceeded

   Figure 2 depicts the ICMPv4 Time Exceeded Message.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     unused    |    Length     |          unused               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: ICMPv4 Time Exceeded

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the second word.  The
   length attribute represents length of the padded "original datagram"
   field, measured in 32-bit words.

4.3.  ICMPv4 Parameter Problem

   Figure 3 depicts the ICMPv4 Parameter Problem Message.

Bonica, et al.            Expires July 30, 2007                 [Page 9]

Internet-Draft          Multi-part ICMP Messages            January 2007

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Pointer    |    Length     |          unused               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 3: ICMPv4 Parameter Problem

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the second word.  The
   length attribute represents length of the padded "original datagram"
   field, measured in 32-bit words.

4.4.  ICMPv6 Destination Unreachable

   Figure 4 depicts the ICMPv6 Destination Unreachable Message.

          0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length     |                  Unused                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      +                as possible without the ICMPv6 packet          +
      |                exceeding the minimum IPv6 MTU [RFC4443]       |

                 Figure 4: ICMPv6 Destination Unreachable

   The syntax and semantics of all fields are unchanged from RFC 4443.
   However, a length attribute is added to the second word.  The length
   attribute represents length of the padded "original datagram" field,
   measured in 64-bit words.

4.5.  ICMPv6 Time Exceeded

   Figure 5 depicts the ICMPv6 Time Exceeded Message.

Bonica, et al.            Expires July 30, 2007                [Page 10]

Internet-Draft          Multi-part ICMP Messages            January 2007

          0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length     |                 Unused                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      +                as possible without the ICMPv6 packet          +
      |                exceeding the minimum IPv6 MTU [RFC4443]       |

                      Figure 5: ICMPv6 Time Exceeded

   The syntax and semantics of all fields are unchanged from RFC 4443,
   except for a length attribute which is added to the second word.  The
   length attribute represents length of the padded "original datagram"
   field, measured in 64-bit words.

4.6.  ICMP Messages That Can Be Extended

   The ICMP Extension Structure MAY be appended to messages of the
   following types:

      - ICMPv4 Destination Unreachable

      - ICMPv4 Time Exceeded

      - ICMPv4 Parameter Problem

      - ICMPv6 Destination Unreachable

      - ICMPv6 Time Exceeded

   The ICMP Extension Structure MUST NOT be appended to any of the other
   ICMP messages mentioned in Section 4.  Extensions were not defined
   for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages
   because these messages lack space for a length attribute.

5.  Backwards Compatibility

   ICMP messages can be categorized as follows:

      - Messages that do not include any ICMP extensions

Bonica, et al.            Expires July 30, 2007                [Page 11]

Internet-Draft          Multi-part ICMP Messages            January 2007

      - Messages that include non-compliant ICMP extensions

      - Messages that includes compliant ICMP extensions

   Any ICMP implementation can send a message that does not include
   extensions.  ICMP implementations produced prior to 1999 are not
   known to send ICMP extensions.

   Some ICMP implementations, produced between 1999 and the time of this
   publication, may send a non-compliant version of ICMP extensions
   described in this memo.  Specifically, these implementations may
   append the ICMP Extension Structure to the Time Exceeded and
   Destination Unreachable messages.  When they do this, they send
   exactly 128 octets representing the original datagram, zero padding
   if required.  They also calculate checksums as described in this
   document.  However, they do not specify a length attribute to be
   associated with the "original datagram" field.

   It is assumed that ICMP implementations produced in the future will
   send ICMP extensions that are compliant with this specification.

   Likewise, applications that consume ICMP messages can be categorized
   as follows:

      - Classic applications

      - Non-compliant applications

      - Compliant applications

   Classic applications do not parse extensions defined in this memo.
   They are insensitive to the length attribute that is associated with
   the "original datagram" field.

   Non-compliant implementations parse the extensions defined in this
   memo, but only in conjunction with the Time Expired and Destination
   Unreachable messages.  They require the "original datagram" field to
   contain exactly 128 octets and are insensitive to the length
   attribute that is associated with the "original datagram" field.
   Non-compliant applications were produced between 1999 and the time of
   publication of this memo.

   Compliant applications comply fully with the specifications of this
   document.

   In order to demonstrate backwards compatibility, Table 1 describes
   how members of each application category would parse each category of
   ICMP message.

Bonica, et al.            Expires July 30, 2007                [Page 12]

Internet-Draft          Multi-part ICMP Messages            January 2007

   +----------------+----------------+----------------+----------------+
   |                |  No Extensions |  Non-compliant |    Compliant   |
   |                |                |   Extensions   |   Extensions   |
   +----------------+----------------+----------------+----------------+
   | Classic        |        -       |   Section 5.1  |   Section 5.1  |
   | Application    |                |                |                |
   |                |                |                |                |
   | Non-compliant  |   Section 5.2  |        -       |   Section 5.3  |
   | Application    |                |                |                |
   |                |                |                |                |
   | Compliant      |   Section 5.4  |   Section 5.5  |        -       |
   | Application    |                |                |                |
   +----------------+----------------+----------------+----------------+

                                  Table 1

   In the table above, cells that contain a dash represent the nominal
   case and require no explanation.  In the following sections, we
   assume that the ICMP message type is "Time Exceeded".

5.1.  Classic Application Receives ICMP Message With Extensions

   When a classic application receives an ICMP message that includes
   extensions, it will incorrectly interpret those extensions as being
   part of the "original datagram" field.  Fortunately, the extensions
   are guaranteed to begin at least 128 octets beyond the beginning of
   the "original datagram" field.  So, only those ICMP applications that
   process the 129th octet of the "original datagram" field will be
   adversely effected.  To date, only two applications falling into this
   catagory have been identified and the degree to which they are
   effected is minimal.

   Some TCP stacks, when they receive an ICMP message, verify the
   checksum in the original datagram field [I-D.ietf-tcpm-icmp-attacks].
   If the checksum is incorrect, the TCP stack discards the ICMP message
   for security reasons.  If the trailing octets of the original
   datagram field are overwritten by ICMP extensions, the TCP stack will
   discard an ICMP message that it would not otherwise have discarded.
   The impact of this issue is considered to be minimal because many
   ICMP messages are discarded for other reasons (e.g., ICMP filtering,
   network congestion, checksum was incorrect because original datagram
   field was truncated.)

   Another theoretically possible, but highly improbably scenario occurs
   when ICMP extensions overwrite the portion of the original datagram
   field that represents the TCP header, causing the TCP stack to
   operate upon the wrong TCP connection.  This scenario is highly
   unlikely because it occurs only when the TCP header appears at or

Bonica, et al.            Expires July 30, 2007                [Page 13]

Internet-Draft          Multi-part ICMP Messages            January 2007

   beyond the 128th octet of the original datagram field and then only
   when the extensions approximate a valid TCP header.

5.2.  Non-compliant Application Receives ICMP Message With No Extensions

   When a non-compliant ICMPv4 application receives a message that
   contains no extensions, the application examines the total length of
   the ICMPv4 message.  If the total ICMPv4 message length is less than
   the length of its IP header plus 144 octets, the application
   correctly determines that the message does not contain any
   extensions.

   The 144 octet sum is derived from 8 octets for the first two words of
   the ICMPv4 Time Exceeded message, 128 octets for the "original
   datagram" field, 4 octets for the ICMP Extension Header and 4 octets
   for a single ICMP Object header.  All of these octets would be
   required if extensions were present.

   If the ICMPv4 payload contains 144 octets or more, the application
   must examine the 137th octet to determine whether it represents a
   valid ICMPv4 Extension Header.  In order to represent a valid
   Extension Header, it must contain a valid version number and
   checksum.  If it does not contain a valid version number and
   checksum, the application correctly determines that the message does
   not contain any extensions.

   Non-compliant applications assume that the ICMPv4 Extension Structure
   begins on the 137th octet of the Time Exceeded message, after a 128
   octet field representing the padded "original datagram" message.

   It is possible that a non-compliant application will parse an ICMPv4
   message incorrectly under the following conditions:

      - the message does not contain extensions

      - the original datagram field contains 144 octets or more

      - selected octets of the original datagram field represent the
      correct values for an extension header version number and checksum

   Although this is possible, it is very unlikely.

   A similar analysis can be performed for ICMPv6.  However, the numeric
   constants would change as appropriate.

Bonica, et al.            Expires July 30, 2007                [Page 14]

Internet-Draft          Multi-part ICMP Messages            January 2007

5.3.  Non-compliant Application Receives ICMP Message With Compliant
      Extensions

   When a non-compliant application receives a message that contains
   compliant ICMP extensions, it will parse those extensions correctly
   only if the "original datagram" field contains exactly 128 octets.
   This is because non-compliant applications are insensitive to the
   length attribute that is associated with the "original datagram"
   field.  (They assume its value to be 128.)

   Provided that the entire ICMP message does not exceed the minimum
   reassembly buffer size (576 octets for ICMPv4 or 1280 octets for
   ICMPv6), there is no upper limit upon the length of the "original
   datagram" field.  However, each implementation will decide how many
   octets to include.  Those wishing to be backward compatible with non-
   compliant TRACEROUTE implementations will include exactly 128 octets.
   Those not requiring compatibility with non-compliant TRACEROUTE
   applications may include more octets.

5.4.  Compliant Application Receives ICMP Message with No Extensions

   When a compliant application receives an ICMP message, it examines
   the length attribute that is associated with the "original datagram"
   field.  If the length attribute is zero, the compliant application
   MUST determine that the message contains no extensions.

5.5.  Compliant Application Receives ICMP Message with Non-compliant
      Extensions

   When a compliant application receives an ICMP message, it examines
   the length attribute that is associated with the "original datagram"
   field.  If the length attribute is zero, the compliant application
   MUST determine that the message contains no extensions.  In this
   case, that determination is technically correct, but not backwards
   compatible with the non-compliant implementation that originated the
   ICMP message.

   So, to ease transition yet encourage compliant implementation,
   compliant TRACEROUTE implementations MUST include a non-default
   operation mode to also interpret non-compliant responses.
   Specifically, when a TRACEROUTE application operating in non-
   compliant mode receives a sufficiently long ICMP message that does
   not specify a length attribute, it will parse for a valid extension
   header at a fixed location, assuming a 128 octet "original datagram"
   field.  If the application detects a valid version and checksum, it
   will treat the octets that follow as an extension structure.

Bonica, et al.            Expires July 30, 2007                [Page 15]

Internet-Draft          Multi-part ICMP Messages            January 2007

6.  Interaction with Network Address Translation

   The ICMP extensions defined in this memo do not interfere with
   Network Address Translation.  [RFC3022] permits traditional NAT
   devices to modify selected fields within ICMP messages.  These fields
   include the "original datagram" field mentioned above.  However, if a
   NAT device modifies the "original datagram" field, it should modify
   only the leading octets of that field which represent the outermost
   IP header.  Because the outermost IP header is guaranteed to be
   contained by the first 128 octets of the "original datagram" field,
   ICMP extensions and NAT will not interfere with one another.

   It is conceivable that a NAT implementation might overstep the
   restrictions of RFC 3022 and overwrite the length attribute specified
   by this memo.  If a NAT implementation were to overwrite the length
   attribute with zeros, the resulting packet will be indistinguishable
   from a packet that was generated by a non-compliant ICMP
   implementation.  See Section 5.5 for packet details and a discussion
   of backwards compatibility.

7.  The ICMP Extension Structure

   This memo proposes an optional ICMP Extension Structure that can be
   appended to the ICMP messages referenced in Section 4.6 of this
   document.

   The Extension Structure contains exactly one Extension Header
   followed by one or more objects.  Having received an ICMP message
   with extensions, application software MAY process selected objects
   while ignoring others.  The presence of an unrecognized object does
   not imply that an ICMP message is malformed.

   As stated above, the total length of the ICMP message, including
   extensions, MUST NOT exceed the minimum reassembly buffer size.
   Figure 6 depicts the ICMP Extension Header.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|      (Reserved)       |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 6: ICMP Extension Header

   The fields of the ICMP Extension Header are as follows:

Bonica, et al.            Expires July 30, 2007                [Page 16]

Internet-Draft          Multi-part ICMP Messages            January 2007

   Version: 4 bits

      ICMP extension version number.  This is version 2.

   Reserved: 12 bits

      Must be set to 0.

   Checksum: 16 bits

      The one's complement of the one's complement sum of the data
      structure, with the checksum field replaced by zero for the
      purpose of computing the checksum.  An all-zero value means that
      no checksum was transmitted.  See Section 5.2 for a description of
      how this field is used.

8.  ICMP Extension Objects

   Each extension object contains one or more 32-bit words, representing
   an object header and payload.  All object headers share a common
   format.  Figure 7 depicts the Object Header and payload.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |   Class-Num   |   C-Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   // (Object payload) //                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 7: Object Header and Payload

   An object header has the following fields:

   Length: 16 bits

      Length of the object, measured in octets, including the object
      header and object payload.

   Class-Num: 8 bits

Bonica, et al.            Expires July 30, 2007                [Page 17]

Internet-Draft          Multi-part ICMP Messages            January 2007

      Identifies object class.

   C-Type: 8 bits

      Identifies object sub-type.

9.  Security Considerations

   Upon receipt of an ICMP message, application software must check it
   for syntactic correctness.  The extension checksum must be verified.
   Improperly specified length attributes and other syntax problems may
   result in buffer overruns.

   This memo does not define the conditions under which a router sends
   an ICMP message.  Therefore, it does not expose routers to any new
   denial of service attacks.  Routers may need to limit the rate at
   which ICMP messages are sent.

10.  IANA Considerations

   The ICMP Extension Object header contains two 8-bit fields: The
   Class-Num identifies the object class, and the C-Type identifies the
   class sub-type.  Sub-type values are defined relative to a specific
   object class value, and are defined per-class.

   IANA should establish a registry of ICMP extension objects classes
   and class sub-types.  There are no values assigned within this
   document to maintain.  Object classes 0xF7 - 0xFF are reserved for
   private use.  Object class values are assignable on a first-come-
   first-serve.  The policy for assigning sub-type values should be
   defined in the document defining new class values.

11.  Acknowledgments

   Thanks to Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt and
   Sharon Chrisholm for their comments regarding this draft.

12.  Testing

   [RFC Editor: Please remove this section before publication]

   In order to demonstrate that the ICMP extensions defined herein do
   not adversely impact classic ICMP applications, the authors performed
   the following experiments:

Bonica, et al.            Expires July 30, 2007                [Page 18]

Internet-Draft          Multi-part ICMP Messages            January 2007

      Experiment 1: Ping a device that sends non-compliant ICMP
      extensions.  Also ping through a devices that sends non-compliant
      ICMP extensions.

      Experiment 2: Traceroute to device that sends non-compliant ICMP
      extensions.  Also traceroute through a devices that sends non-
      compliant ICMP extensions.

      Experiment 3: Cause a TCP implementation to receive a non-
      compliant ICMP messages with extensions that is classified as a
      soft error.

      Experiment 4: Cause a TCP implementation to receive a non-
      compliant ICMP messages with extensions that is classified as a
      hard error.

   As defined in Section 5, a non-compliant ICMP extension is identical
   to a fully compliant extension in every way excpet that it lacks a
   length attribute.

   In all cases, the classic application behaved as if the ICMP
   extension was not present.

   Classic applications ran under the following operating systems:

      Windows XP

      Macintosh OS X, OS 9

      Solaris

      Linux

      Cisco IOS XR

      Juniper JUNOS

13.  References

13.1.  Normative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

Bonica, et al.            Expires July 30, 2007                [Page 19]

Internet-Draft          Multi-part ICMP Messages            January 2007

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

13.2.  Informative References

   [I-D.atlas-icmp-unnumbered]
              Atlas, A., "ICMP Extensions for Unnumbered Interfaces",
              draft-atlas-icmp-unnumbered-01 (work in progress),
              March 2006.

   [I-D.ietf-mpls-icmp]
              Bonica, R., "ICMP Extensions for MultiProtocol Label
              Switching", draft-ietf-mpls-icmp-07 (work in progress),
              December 2006.

   [I-D.ietf-tcpm-icmp-attacks]
              Gont, F., "ICMP attacks against TCP",
              draft-ietf-tcpm-icmp-attacks-01 (work in progress),
              October 2006.

   [I-D.shen-icmp-routing-inst]
              Shen, N. and E. Chen, "ICMP Extensions for Routing
              Instances", draft-shen-icmp-routing-inst-00 (work in
              progress), November 2006.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

Authors' Addresses

   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Email: [email-masked]

Bonica, et al.            Expires July 30, 2007                [Page 20]

Internet-Draft          Multi-part ICMP Messages            January 2007

   Der-Hwa Gan
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: [email-masked]

   Pekka Nikander
   Ericsson Research Nomadic Lab
   JORVAS  FIN-02420
   Finland

   Email: [email-masked]

   Daniel C. Tappan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA  01824
   US

   Email: [email-masked]

   Carlos Pignataro
   Cisco Systems, Inc.
   7025 Kit Creek Road
   Research Triangle Park, N.C.  27709
   US

   Email: [email-masked]

Bonica, et al.            Expires July 30, 2007                [Page 21]

Internet-Draft          Multi-part ICMP Messages            January 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Bonica, et al.            Expires July 30, 2007                [Page 22]