Overall, this draft specifies a useful function and I believe it should move forward.
There are a number of details that need a bit of adjustment before the draft is ready, however. Please see details further down in this e-mail. There is one big question as well. There has been some discussion about the usefulness of next hop information and whether draft-watkins-icmptype11code0 should also move forward, or if the drafts should merge. Having read the two drafts together now, my opinion is that adding a flag and 2nd IP address for the next hop for an outgoing interface object seems like a good approach. This would allow reporting an outgoing interface AND its next hop information (where available). Another interesting issue is treatment by NATs. Given that the information is primarily for debugging and that any modification or removal of this information by a NAT could interfere with that, my suggestion is that NAT devices SHOULD merely pass this extension along. Technical: > Extending ICMP to Identify the Receiving Interface > Abstract > > This memo defines ICMP extensions, using ICMP multi-part messages, > through which a router or host can explicitly identify the interface > upon which an undeliverable datagram anrrived. > > ... > > Using the extension defined herein, an IP device can explicitly > identify the incoming interface by any or all of the following: > > o IPv4 address > o IPv6 address > o name > o ifIndex > > Using the extension defined herein, an IP device can explicitly > identify by the above the outgoing interface and next-hop over which > a datagram would have been forwarded if that datagram had been > deliverable. > > ... > > 3.2. Policy and MTU Detection > > A general application would be to identify which outgoing interface > triggered a given function for the original packet. > ... > 0 : This object describes the incoming interface. > 1 : This object describes the outgoing interface. > First, the title is misleading, and the abstract does not mention the ability to identify outgoing interfaces. Second, how does the identification of the outgoing interface follow from the identification of the incoming interface, given things like ECMP? Since the draft does, after all, support identifying outgoing interfaces as well that fact should be better reflected in title, abstract, etc. > 3 : When set, this bit indicates the ifIndex of the interface is > included. When clear, the ifIndex is not included. Encoded how? How many bytes? > Another issue is when a device inside a private region generates an > ICMP message with some of these extensions and that ICMP message will > transit a NAT to reach its destination. A NAT may choose to remove or > overwrite the extensions. First, please clarify whether leaving the extension alone is also legal. This is obviously what a legacy NAT would do, of course, so I don't feel good about outlawing it. Second, I think we need a stronger recommendation on what the NATs should do about this, so that the NAT vendors can do the right thing. However, its not entirely clear to me what the right thing is. In particular, even if this extension passes a NAT the optional addresses included in it may or may not still be valid on the other side of the NAT. And this has nothing to do with the type of the addresses (private or public), it has to do with the topology of the network -- and this may not be something that the NAT device understands. One approach would be to say that this information is for debugging only, and therefore SHOULD be left alone. Thoughts? > Interface Name Sub-Object Shouldn't there be some discussion about truncation in case the real name does not fit this object? Editorial: > upon which an undeliverable datagram anrrived. The incoming Typo > Bit 7 6 | 5 4 3 2 1 0 > +-------+-------+-------+-------+-------+-------+-------+-------+ > | Interface Role| Rsvd | Rsvd | index | IP | Rsvd | descr | > +-------+-------+-------+-------+-------+-------+-------+-------+ > For what it is worth, I found this figure illustrative, but the text that accompanied it was confusing. For one thing, the text discusses two fields "Interface Role" and "Included Information" which are not shown here. For another, the bits are later referred to by their numbers, not names. I would suggest sticking to the names in the figure and removing the concept of the "Included Information" field. > The information/sub-objects MUST be sent and received inside the > Interface Information Object in the order that they are listed in the > final 6-bits included-information field. Just say: "The ifIndex, address, and name follow the C-type octet, in this order, if present." or something to that effect. Avoid referring to the confusing included-information field. Also, the ifIndex and address were by my understanding not proper objects, it was just bytes following the C field. > 4.3. Interface Information Object Description Wouldn't this be better as "Examples"? > Figure 4 depicts the Interface Information Object, with two of the > valid permutations. Three, but who's counting :-) > o Bit 3: ifIndex include included Jari _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
