Subject: [Int-area] AD evaluation of draft-bonica-internet-icmp

From: Jari Arkko <[email-masked]>
Date: Sun, 04 Jun 2006 18:37:53 +0300

Ron, all,

I have reviewed this specification. I have a few technical issues
and one question to the community about IPv6 support in this
space.

Technical issues:

>       - An ICMP Extension Structure MAY be appended to any ICMP message
>       except for those excluded below.

Given the nature the extensions we can do at this stage,
and the goals of this draft, I think it would be much better
if the draft explicitly restricted itself to a known subset of ICMP
messages (as opposed to "any").

> 5.  Backwards Compatibility

I have some unease about this section, mainly due
to the central role that the interoperability with
the currently deployed extension scheme that is
not compatible with what this spec says. It is
indeed important that we document how to
stay interoperable to the old extension scheme.
However, Section 5.5 almost recommends
making a non-compliant implementation due to
the backwards compatibility reasons. I would
suggest requiring compliant behaviour and
then allowing backwards compatibility mode
to be enabled through configuration or traceroute
option. Perhaps also some editorial changes.

This issue was also raised by the two reviewers
that I asked to look at this spec (Joe Touch and
Pekka Savola; thanks for your reviews! The detais
have been forwarded to Ron.).

The question:

In the discussion on the int-area list it was brought up that
that we need to "accept reality" in the IPv4 world but for IPv6
we should design something better. Now, as it turns out, one
of reasons for doing this, MPLS traceroute, *has* already
been implemented for IPv6, by at least one large vendor.
I'd like to get input from this list whether this fact changes
any of the conclusions we've had on this topic so far.
Including, for instance, that the draft should be silent on
IPv6.

--Jari

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 05 Jun 2006 17:10:46 -0400

> messages (as opposed to "any").

Jari,

In the interest of getting the draft published, I am willing to make
this change, but before doing so, I would like to push back a little bit.

Why would we want to restrict the applicability of the extension
structure more than we need to? I agree that it makes no sense to ever
extend some ICMP messages (e.g., Source Quench). But if someone,
someday, finds that he needs to add information to the Parameter Problem
message, why should he not use the extension structure defined in this
draft?

> option. Perhaps also some editorial changes.

Agreed. I will replace the last two paragraphs of section 5.5 with the
following:

To ease transition yet encourage compliant implementation, compliant
TRACETOUE implementations MAY include a non-default operation mode
to also interpret non-compliant responses. Specifically, when a
TRACEROUTE application operating in non-compliant mode receives an ICMP
message that contains 144 octets or more in its payload and does not
specify a length attribute, it will parse for a valid extension header
beginning at octet 137.  If the application detects a valid version and
checksum, it will treat the following octets as an extension structure.

                                          Ron

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Jun 2006 14:22:32 -0700

> message, why should he not use the extension structure defined in this

FWIW, it might be cleaner to state the specific current subset, and
state 'and future messages'; that avoids any ambiguity.

> checksum, it will treat the following octets as an extension structure.

The doc ought to state that if the checksum fails, the implementation
MUST NOT interpret the message as containing an extension - again, for
clarity.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Mon, 05 Jun 2006 18:11:16 -0400

I agree on both points.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Jun 2006 15:20:36 +0300

Ron Bonica wrote:

>...
I do not worry about the extension to Destination Unreachable,
Parameter Problem, Source Quench, or Time Exceeded messages.

My issue was the statement in the draft that indicated you
can use this extension mechanism on any ICMP message except
those explicitly listed. As you note in the draft, the extension
mechanism is unsuitable for some types of messages. For instance,
Echo Request/Reply cannot be extended due to lack of a suitable
reserved field, and RFC 4065 messages already have their own
option structure. The current IANA registry lists
~ 40 ICMP Type values -- and there could be more in the
future. We should not say anything about existing messages
without analysis of the suitability of this mechanism for them,
and obviously its hard to say what future ICMP messages might
look like. And if it turns out that people are going to do this
this also for IPv6, it has many ICMP messages where
this style of extension would be inappropriate
since another option mechanism already exists.

I would suggest that we limit this draft to extend
the messages that we know can and should be
extended. This may be the four messages that
you already cover in Section 4. Or if you can see
some other message that need this, lets list them
too, explicitly.

>checksum, it will treat the following octets as an extension structure.
This text looks good to me.

--Jari

---

From: Ron Bonica <[email-masked]>
Date: Thu, 08 Jun 2006 10:56:46 -0400

OK. I'm convinced.

I will update the draft and resubmit it in a few hours.

                   -ron

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 08 Jun 2006 12:29:02 -0400

Ron, Jari,

Maybe adding a small note that future ICMPs may make use of this
extension structure if/when defined?

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Jun 2006 19:43:21 +0300

>extension structure if/when defined?
Sure, as long as its clear that by default nothing uses this
unless it is explicitly specified to do so.

--Jari

---

From: Joe Touch <[email-masked]>
Date: Thu, 08 Jun 2006 10:17:29 -0700

> extension structure if/when defined?

I thought what was being asked was:

- define use only for an explicit subset of existing ICMP messages,
i.e., for all existing, state whether MUST, MAY, SHOULD, SHOULD NOT,
MUST NOT.

- require its support for new messages (that seems reasonable - or at
least that new messages MUST describe whether this extension is
supported, and SHOULD support it unless obviously interfering).

Joe

---

From: Ron Bonica <[email-masked]>
Date: Thu, 08 Jun 2006 13:54:40 -0400

Joe,

This sounds reasonable. Do we have consensus on that?

                 Ron

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Jun 2006 21:47:48 +0300 (EEST)

...
> supported, and SHOULD support it unless obviously interfering).

I'm not sure if an Experimental RFC could mandate the former, but I'm 
pretty sure folks agree that if someone from IETF defines new ICMP 
extensions, at some point it's valid to ask whether the proposer has 
read this document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Touch <[email-masked]>
Date: Thu, 08 Jun 2006 13:15:38 -0700

> extensions, at some point it's valid to ask whether the proposer has

Good point; in that case, new messages SHOULD describe...

If this gets revisited to go standards track, the wording would be
revised. I wouldn't drop it to MAY or drop it out; the implications of
standardizing this doc should be retained.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Thu, 08 Jun 2006 17:52:41 -0400

Folks,

I have just posted an updated draft version. For those of you who won't
sleep until you have seen it, you can download it from:

http://www.bonica.org/draft-bonica-internet-icmp-05.txt

Sections 4.5 and 5.5 have been changed.

                                        Ron

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Jun 2006 13:50:07 +0300

On the topic of what this extension means for future
ICMP messages:

Its obvious that whoever designs new ICMP messages
should consider this work and decide whether it
applies to those new messages or not. We should
add words to this effect to the document. I would
rather not use keywords or a strict must requirement,
however, because whether this or some other way to
extend a new message is appropriate probably depends
on the nature and format of that message.

By the way, Section 3 contains still some text
that talks about "any ICMP messages".

Here's some suggested text:

To replace the item list from Section 3:

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

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

     The "original datagram" field MUST include at least 128
     octets. If the original datagram did not contain 128 octets,
     the "original datagram" field MUST be zero padded to 128
     octets.

     The "original datagram" field MUST be zero padded to
     the nearest 32-bit boundary.

To replace the current statement from Section 4.5:

   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
   employ some mechanism that allows later extensions.

--Jari

---

From: Joe Touch <[email-masked]>
Date: Fri, 09 Jun 2006 08:26:33 -0700

> on the nature and format of that message.

The problem is that anything short of having this be standards-track
means that future standards-track docs _need_ not consider this work at
all. If that's not the goal, than this needs to go a different track.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 09 Jun 2006 11:51:52 -0400

Jari,

I have copied this text verbatim into the draft and posted it as version
6. You can get a sneak preview of the text at
http://www.bonica.org/draft-bonica-internet-icmp-06.txt.

                                   Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 09 Jun 2006 11:55:00 -0400

Jari,

Is there some requirement for PS that this document does not meet?

                                 Ron

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Jun 2006 08:39:31 -0700

> Is there some requirement for PS that this document does not meet?

IMO, PS would require a much more complete description of the specific
changes to RFCs 792 and 1122. I'm not sure there's a motivation for this
to go PS either - extending ICMP in general isn't sufficient. Changes to
these core docs that aren't absolutely necessary to support immediate
critical needs of _Internet_ protocols are also insufficient.

Right now, the primary motivation is to support MPLS use of ICMP. That
doesn't warrant an upheaval of Internet specs. The other motiviations
(Alia's doc) seem at best experimental at this point.

I'd suggest this go experimental until there is further standards-track
need to support Internet protocols.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Jun 2006 12:07:53 -0400

Joe Touch wrote:
> changes to RFCs 792 and 1122. 

Could you describe those changes? Maybe we can make them.

                                  Ron

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Jun 2006 09:27:08 -0700

> Could you describe those changes? Maybe we can make them.

It's hard to say in each specific case; a good example of what *I*
expect (at least) of a mod to a spec is in
draft-touch-tcpm-tcp-simple-auth-00.txt (which mods only RFCs 793 and 2385).

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Jun 2006 12:47:18 -0400

Joe,

I am afraid that your response doesn't help me very much. Maybe I am
just being obtuse, but by looking at draft-touch-tcpm-simple-auth, I am
not able to identify a requirement for publication as PS that
draft-bonica-internet-icmp does not meet.

Maybe somebody else can formulate a response to my initial question? Jari?

                              Ron

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Jun 2006 09:53:06 -0700

> draft-bonica-internet-icmp does not meet.

Sorry, but my involvement in providing text for this document exceeds
what I consider the 'author' bound. Since there isn't room for that, a
corollary description is the best I can do.

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Jun 2006 13:00:42 -0400

>>Maybe somebody else can formulate a response to my initial question? Jari?

Understood, and I appreciate all of the help that you have provided so far!

                         Ron

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 Jun 2006 08:07:57 +0300 (EEST)

> Is there some requirement for PS that this document does not meet?

FWIW, IMHO any PS protocol must support v6 unless there is strong 
justification not to.

---

From: Ron Bonica <[email-masked]>
Date: Wed, 14 Jun 2006 10:08:30 -0400

Fair enough. Could we progress this document if I committed to producing
another for v6? I do think that they should probably be separate documents.

                       Ron

Pekka Savola wrote:
>     autolearn=ham version=3.1.2
> X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 08:23:49 -0700

That's a question we can guess the answer to; right now, most of our
concerns about PS requirements are in anticipation of cross-area and
IESG review, at least from my perspective.

I'd guess that an integrated response to extended ICMP messages is more
appropriate than separate ones, but it's just a guess.

Joe