Distance Vector Multicast Routing Protocol
draft-ietf-idmr-dvmrp-v3-11

IANA Evaluation Comment:

Upon approval of this document, the IANA will UPDATE the following assignments
in the "IGMP TYPE NUMBERS" registry located at
http://www.iana.org/assignments/igmp-type-numbers

Value Description
----- ----------------
0x13 DVMRP [RFCDVMRP]

[Ballot discuss]
Protocol document:

As I understand this document covers only IPv4. I think that should be stated up front to clarify that in all the places it says "IP address" an IPv4 address is implied.

What about DVMRP for IPv6?

Section 3.1:

-  "DVMRP protocol packets should be sent
  with the Precedence field in the IP header set to Internetwork
  Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]."

I this procedure needs to be updated to take RFC 2474 into consideration.


Section 3.2.1:
Bitorder of the capability flags are depicted as inverse to the others. This makes it unclear if the bit 7 is the left most in field and should go into bit 8 of the second 32 bit word of the common header or the 15th bit.

                      7  6  5    4  3  2  1    0
                      U  U  N    S  M  G  P    L
                    +---+---+---+---+----+---+---+---+
                    |0  |0  |X  | 0 | 1  |1  |1  | 0 |
                    +---+---+---+---+----+---+---+---+


                    Figure 2 - Probe Capability Flags

[Ballot discuss]
Protocol document:

Section 3.1:
- Is DVMRP IPv4 only? It seems that way as it refernces only IPv4 specifications. The spec uses IP address without discussing version or size. Please clarify its relation to IPv6 multicast.

-  "DVMRP protocol packets should be sent
  with the Precedence field in the IP header set to Internetwork
  Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]."

I this procedure needs to be updated to take RFC 2474 into consideration.


Section 3.2.1:
Bitorder of the capability flags are depicted as inverse to the others. This makes it unclear if the bit 7 is the left most in field and should go into bit 8 of the second 32 bit word of the common header or the 15th bit.

                      7  6  5    4  3  2  1    0
                      U  U  N    S  M  G  P    L
                    +---+---+---+---+----+---+---+---+
                    |0  |0  |X  | 0 | 1  |1  |1  | 0 |
                    +---+---+---+---+----+---+---+---+


                    Figure 2 - Probe Capability Flags

-

[Ballot discuss]
Protocol document:

Section 3.1:
- Is DVMRP IPv4 only? It seems that way as it refernces only IPv4 specifications. Please clarify its relation to IPv6 multicast.

-  "DVMRP protocol packets should be sent
  with the Precedence field in the IP header set to Internetwork
  Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]."

I this procedure needs to be updated to take RFC 2474 into consideration.

Section 3.2.1:
Bitorder of the capability flags are depicted as inverse to the others. This makes it unclear if the bit 7 is the left most in field and should go into bit 8 of the second 32 bit word of the common header or the 15th bit.

                      7  6  5    4  3  2  1    0
                      U  U  N    S  M  G  P    L
                    +---+---+---+---+----+---+---+---+
                    |0  |0  |X  | 0 | 1  |1  |1  | 0 |
                    +---+---+---+---+----+---+---+---+


                    Figure 2 - Probe Capability Flags

-

[Ballot discuss]
Protocol document:

Section 3.1:
- Is DVMRP IPv4 only? It seems that way as it refernces only IPv4 specifications. Please clarify its relation to IPv6 multicast.

-  "DVMRP protocol packets should be sent
  with the Precedence field in the IP header set to Internetwork
  Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]."

I this procedure needs to be updated to take RFC 2474 into consideration.

[Ballot discuss]
Protocol document:

Section 3.1:
- Is DVMRP IPv4 only? It seems that way as it refernces only IPv4 specifications. Please clarify its relation to IPv6 multicast.

-  "DVMRP protocol packets should be sent
  with the Precedence field in the IP header set to Internetwork
  Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]."

I think this procedure needs to be updated to take RFC 2474 into consideration.

[Ballot comment]
From Gen-ART review by Joel Halpern:

The following minor comments should be considered if there is other reason to revise the document.

Protocol:
    In section 2.4 on Designated Forwarder, in the event of a metric tie, the rotuer with the lowest IP address is the designated forwarder.  I believe that this is the router whose interface to the mutli-access network has the lowest IP address.  (Not, for example, the lowest loopback address, etc.)  A few extra words here would be a good idea.
  Section 2.5.1 talks about learning local group membership from IGMP.  Shouldn't there be some mention of source specific membership here? (Or am I confused and that has gone away?)
  I am guessing that the 3 octet network mask technique is used here for backwards compatibility, even though a network prefix length would be shorter?  (The protocol goes to significant lengths to save bytes, and the text does not say why that is not used.)
  Section 3.4.5 introduces the term "flash update."  While I have seen this in implementations, it is not a widely used term in our specifications.  An explanation would be a good idea.

Applicability Statement:
    It would have been nice to see a clearer statement of why one would use this rather than either PIM-DM or M-OSPF. (There is probably more, but one piece of the answer is the support for tunnels in DVMRP.)
    Given that restarting routers can, via the generation ID, cause significant amounts of graft, graft-ack, and prune messages, should this applicability statement say something about assuming underlying stability of the network?

[Ballot comment]
These comments apply to draft-ietf-idmr-dvmrp-v3-11 from the
  SecDir review by Juergen Schoenwaelder:

  Section 1.4 should also point to the sections 4 through 6 which
  are a substantial part of the document.

  Should the security considerations discuss the ramifications of
  setting the TTL to 1 when sending to the all-dvmrp-routers
  multicast group?  Changing this to 255 may not work given the fact
  that DVMRP is widely implemented.

  Sometimes the document uses concepts that have not been introduced
  at that point in the document, which makes the document a bit harder
  to read when reading from the beginning to the end.  For example,
  section 3.2.4 talks about hold-down states which are explained later
  (perhaps this concept can be introduced in section 2).

  Section 3.4. recommends that tunnels should be configured to use
  the same metric in both directions. Perhaps this should be
  mentioned again the network management considerations section.

  The document several times talks about flash updates without ever
  defining this term.

  There is a duplicate "the" in the second paragraph of section 3.5.6.

  Some cited RFCs have been updated, especially the IPsec ones:
    RFC 2401 -> RFC 4301, and
    RFC 2402 -> RFC 4302.

  What happened to the DVMRP MIB? There seems to be a bit in the
  protocol which indicates the support of this MIB...

[Ballot discuss]
draft-ietf-idmr-dvmrp-v3-as-01 does not contain a security
  considerations section,  Please add one that summarizes the
  negative impact if the applicability statement is ignored.

  The security considerations of draft-ietf-idmr-dvmrp-v3-11
  suggest the usage of IPsec and then describe the impact of
  multicast addresses.  However, the old version of the IPsec
  Architecture and AH are referenced.  The support for multicast
  is not complete, and it is a work item in the MSEC WG.  I do not
  see how IPsec can be used without this work being finished.

  Since DVMRP can be used without IPsec, it would be valuable
  to spell out the security risks of using DVMRP without IPsec.
  In particular, ithe ramifications of forged messages and the
  impact of making neighbor information accessible via the tracing
  and troubleshooting support ought to be discussed. Perhaps
  some of the security needs could be provided by packet filtering.
  If so, please provide more information and recommendations.

[Ballot discuss]
There is no separation of references in Normative and Informative.

Section 5 in draft-ietf-idmr-dvmrp-v3-11 seems incomplete. It refers to a few MIB documents, but it is not clear if these MIB modules are considered to be sufficent for the management of a DVMPRPv3 device or network, or further work would be needed for a fully managed solution.

The reference [Thal97] has an unknown status.

The reference [McCl00] seems to refer to a IPv4 only solution.

Suggestion: follow e.g. RFC2236 and RFC3376 -
1. Talk about the ramifications of a forged message of each type.
2. Talk about possible IPSEC keying strategies.

The TTL=255 trick would be possible but probably would cause more interoperability problems than it solved.

State Changes to Pre AD Evaluation                                from Token@wg or Author                                by IESG Member