-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all,
I agree with Jari's suggestion about merging the mechanisms described. Regarding NATs, they already don't listen to MUSTs, so I don't see the point in issuing SHOULDs they're going to ignore as well ;-) Joe Jari Arkko wrote: > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjGsqEACgkQE5f5cImnZrupZwCfQhEWjfscQ/VmTS+AIQHYzdFq oB4AoPLxD6ko6+m+oD5OkS8KSEkBOFhN =DQxj -----END PGP SIGNATURE----- _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
