Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-26

Thanks to everyone who put in the work to improve the overall mtrace mechanism.
I have a handful of substantive questions and comments, most of which I believe
require clarifying text in the document.

---------------------------------------------------------------------------

§3:

>  All Mtrace2 messages are UDP packets.  For IPv4, Mtrace2 Query and
>  Request messages MUST NOT be fragmented.

Since Query messages can transit intermediate routers on the way to the LHR,
this requirement seems to imply that Mtrace2 clients MUST set the IP
do-not-fragment (DF) bit in Query messages. That should probably be called out
explicitly here.

To be clear, the above text seems to intentionally allow fragmentation of Reply
messages. Was that on purpose?

Finally, the corresponding IPv6 text puts a parallel restriction of 1280 bytes
on "the Mtrace2 messages", which would imply all message types, not ust Query
and Request.  Again: is that the intention?

---------------------------------------------------------------------------

§3.1:

All of the TLVs defined in this document appear to take pains to end on
four-byte boundaries (e.g., inserting "must be zero" bytes as necessary). This
document establishes an IANA registry for TLVs, presumably so new ones can be
defined elsewhere. When new TLVs are defined, is is a requirement that their
lengths are a multiple of four? If so, please indicate as much here, as it
allows implementations to make certain simplifying assumptions.

If this isn't the case, it should also be indicated here so that implementations
don't make such assumptions based on the six TLVs defined in this document.

---------------------------------------------------------------------------

§3.2.4:

>     This field contains a forwarding information/error code.  Values
>     with the high order bit set (0x80-0xff) are intended for use as
>     error or exception codes.

...

>    0x06   WRONG_LAST_HOP  This router is not the proper LHR.

Given that the "WRONG_LAST_HOP" forwarding code appears to be a fatal
condition based on client misconfiguration (per the description in §4.1.1),
I'm a bit confused about what is meant by "error or exception codes." Assuming
the assignment of 0x06 (rather than, say, 0x86) was intentional, I believe the
description of when the high order bit is set needs additional text to explain
more precisely what criteria is used to make such a determination.

---------------------------------------------------------------------------

§3.2.6:

>      The Augmented Response Type is defined as follows:
>
>         Code    Type
>         ====    ===============================================
>         0x01    # of the returned Standard Response Blocks

As this is a 16-byte field, it would be less confusing if this were:

>         Code      Type
>         ======    ===============================================
>         0x0001    # of the returned Standard Response Blocks


---------------------------------------------------------------------------

§8:

I am surprised not to see an IANA registry created for the 16-bit "Augmented
Response Type" field defined in §3.2.6. How are these values intended to be
managed?

1) In Sec 3, the first paragraph says: "If an implementation receives an unknown TLV type
   for a subsequent TLV within a message, it SHOULD ignore and silently
   discard the entire packet."  This appears to me to remove the possibility of incremental
   deployment of new features or TLVs.  A rationale for why future-proofing isn't needed
   would be helpful.  I do see the Augmented Response Block and Augmented Query Block
   have sub-types, which does help with extensibility.

2)End of Sec 3: "Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed.
   For example, if an Mtrace2 Query or Request message arrives in as an
   IPv4 packet, all addresses specified in the Mtrace2 messages MUST be
   IPv4 as well.  Same rule applies to IPv6 Mtrace2 messages." 
I do not understand the rationale for forbidding some addresses being IPv4 and some IPv6.
Presumably, some could even be unnumbered interfaces.  Many networks are dual-stack or 
may have IPv4 in one part of the network and IPv6 in another part.  What is the reason for
ruling this out as a valid situation?  I do see that the encodings are problematic if partly IPv4
and partly IPv6 - but I do not see a reason that IPv4 addresses could not be sent as mapped into IPv6.

3) Sec 3.2.1: "If the actual number of hops is not
   known, an Mtrace2 client could send an initial Query message with a
   large # Hops (e.g., 0xffffffff), in order to try to trace the full
   path." 
   Since the #Hops field is an octet long - the largest value should be 255; specifying for a uint32
   instead of a uint8 is incorrect.

4) Sec 3.2.1: If all the addresses in the Query message must be either IPv4 or all must be IPv6, the
    way of determining which it is from the length should be clearly specified.  I.e. The length field
    MUST be either 8 plus 3*4 (IPv4 addresses) or 8 + 3*16 (IPv6 addresses); if the length is 20, then
    IPv4 addresses MUST be assumed and if the length is 56, then IPv6 addresses MUST be assumed.
    One could - of course, simply force all IPv6 addresses since an IPv4 address can be represented as
    an IPv6 address.  That would allow any of these addresses to be either IPv4 or IPv6 while formatted
    as IPv6.

5) Sec 3.2.2: "The format of an Mtrace2 Request message is similar to an Mtrace2
   Query except the Type field is 0x02."   This should be clearer and more normative.  The Mtrace2
   Request TLV is exactly the same as an Mtrace2 Query except for the identifying Type field of  0x02.
   The same applies to 3.2.3 for Mtrace2 Reply.

Thanks for addressing the Gen-ART review comments.

-3.1. Length: "Length SHOULD NOT exceed the available MTU"
How does that interact with the previous "MUST NOT be fragmented" requirement?

-2: There are lower case versions of the 2119 keywords. Unless those were meant to be capitalized, please consider using the boilerplate from 8174.

Thank you for addressing my DISCUSS

Thanks for 9.2 and 9.3, it is very nice to see a control that can limit traceroute functionality by administrative domain to cut down on reconnaissance and other attack/pre-attack activities.  We normally just add warnings of that possibility in OAM drafts, so thank you!

Thanks for addressing my discuss!

I support Mirja's Discuss ballot point on IANA.

In addition, I have a few comments.


I'm looking in the Introduction for an unambiguous statement as to whether this mechanism can be initiated by a source, and I'm not seeing one. Just based on the Introduction, I'm guessing not, but the Introduction starts by mentioning that it's difficult to trace from the source, so I'm confused.

In section 3, I'm seeing 

   If an
   implementation receives an unknown TLV type for the first TLV in a
   message (i.e., the header TLV), it SHOULD ignore and silently discard
   the entire packet.  If an implementation receives an unknown TLV type
   for a subsequent TLV within a message, it SHOULD ignore and silently
   discard the entire packet.

and trying to understand why these two cases are listed separately. I'm also trying to understand why they're SHOULDs, but please help me understand the differences you have in mind.

I share the question about mixing IPv4 and IPv6.

Is the last sentence in 

   Upstream Router Address: 32 bits
      This field specifies the address of the upstream router from which
      this router expects packets from this source.  This may be a
      multicast group (e.g., ALL-[protocol]-ROUTERS group) if the
      upstream router is not known because of the workings of the
      multicast routing protocol.  However, it should be 0 if the
      incoming interface address is unknown or unnumbered.

normative?