Re: False positive idnit in draft-ietf-mboned-driad-amt-discovery?

Leonard Giuliano <[email protected]> Tue, 3 Sep 2019 12:58:18 -0700
Newsgroups gmane.ietf.mboned
Message-ID <alpine.DEB.2.02.1909031256150.4074@contrail-ubm-wing.svec1.juniper.net>
Jake- If it's supposed to be an SSM group for the example, you definitely 
want to pick an address in 232/8.

>From RFC 6676, I think you are in good shape:

2.  IPv4 Multicast Documentation Addresses

   For Any-Source Multicast (ASM), the IPv4 multicast addresses
   allocated for documentation purposes are 233.252.0.0 - 233.252.0.255
   (233.252.0.0/24).

   For Source-Specific Multicast (SSM), it is less important which
   multicast addresses are used, since a host/application joins a
   channel identified by both source and group.  Any source addresses
   used in SSM examples should be unicast addresses reserved for
   documentation purposes.  There are three unicast address ranges
   provided for documentation use in [RFC5737].  The ranges are
   192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24.

   Sometimes one wants to give examples where a specific type of address
   is desired.  For example, for text about multicast scoping, one might
   want the examples to use addresses that are to be used for
   administrative scoping.  See below for guidance on how to construct
   specific types of example addresses.



On Sun, 1 Sep 2019, Holland, Jake wrote:

| Hi Mboned,
| 
| I wanted to ask for your expert opinions on one of the warnings that
| idnits reports in draft-ietf-mboned-driad-amt-discovery.  I think
| it's a false positive, but I wanted to check if wg consensus agrees
| with me here regarding the use of 232.x vs. 233.252.0.x:
| 
| In the draft, I'm using 232.252.0.2, which is not the MCAST-TEST-NET
| space of 233.252.0.0/24, which is causing a warning.
| 
| From:
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www6.ietf.org_tools_idnits-3Furl-3Dhttps-3A__www.ietf.org_archive_id_draft-2Dietf-2Dmboned-2Ddriad-2Damt-2Ddiscovery-2D08.txt-26verbose-3Dtrue&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=xsk5PcsYEt_KVg7TP9YF66RP-SQnean6GQq5Ri7mmgo&s=DZ-tcZiA71UT3PNABbEuLfQ1IBPYbEpbEbVMgepu5Sw&e= 
| 
|   /tmp/draft-ietf-mboned-driad-amt-discovery-08.txt(409): Found possible IPv4
|     address '232.252.0.2' in position 24; this doesn't match the suggested
|     documentation address ranges specified in RFC 6890 (or successor): blocks
|     192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
|     (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) example multicast
|     address range specified in RFC 5771.
| 
|   == There are 1 instance of lines with multicast IPv4 addresses in the
|      document.  If these are generic example addresses, they should be changed
|      to use the 233.252.0.x range defined in RFC 5771
| 
| 
| However, I think it’s better here to use the designated SSM space, because
| this is specifically a SSM group, and the S that’s associated is one from
| one of the proper example test nets.
| 
| Section 8.1 of RFC 5771 mentions that there's deliberately no IANA
| assignment policy for 232.x (leaving aside the reserved 232.0.0.x/24
| from section 9 of RFC 4607):
| 
| https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5771-23section-2D8.1&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=xsk5PcsYEt_KVg7TP9YF66RP-SQnean6GQq5Ri7mmgo&s=dDJAgFTDtnN2TskyxRHWgEhdxo0vbsalClLtM-o6zfc&e= 
|    Because the SSM model essentially makes the entire multicast address
|    space local to the host, no IANA assignment policy is required.
|    Note, however, that while no additional IANA assignment is required,
|    addresses in the Source-Specific Multicast Block are explicitly for
|    use by SSM and MUST NOT be used for other purposes.
| 
| In this case, I think using an example SSM group in a (S,G) that uses
| one of the recommended example networks for the S is already a proper
| example.
| 
| I think the problem with using the TEST-MCAST-NET block is that GLOP
| addresses in 233 are globally scoped and statically assigned, so they
| wouldn’t fit inside the default ssm space for things like configuring
| RPF for PIM, so you might actually get different behavior out of the
| network if you tried to use them without special config to support them.
| 
| So my opinion is it’s better to use 232.x in this case.  I'm not sure
| one way or the other whether it perfectly matches the letter of RFC 6890,
| but I think it's a better match for the spirit, as I understand it.
| 
| I'd be very happy to take advice from the WG or the IESG if anyone thinks
| it's better to use the suggested 233.252.0.x destination instead.  I'm
| soliciting opinions on the point, since it's relatively likely to come up
| in review, since idnits flags it.
| 
| Cheers,
| Jake
| 
| 
| PS:
| there is another warning that I think is more obviously a false positive.
| 
| You may of course comment if you like, but I'm not asking about this one,
| I just wanted to mention it also to head off some of the confusion:
| 
|   /tmp/draft-ietf-mboned-driad-amt-discovery-08.txt(374): Found possible IPv4
|     address '15.100.51.198' in position 46; this doesn't match the suggested
|     documentation address ranges specified in RFC 6890 (or successor): blocks
|     192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
|     (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) example multicast
|     address range specified in RFC 5771.
| 
|   == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
|      in the document.  If these are example addresses, they should be changed.
| 
| '15.100.51.198' appears in 3 places, but each of those places is actually part
| of the reverse-ip DNS zone for 198.51.100.15: 15.100.51.198.in-addr.arpa.  So
| this is a false positive because it uses one of the RFC 6890 test net addresses,
| but it’s properly reversed to indicate the corresponding DNS zone.
| 
| 
| _______________________________________________
| MBONED mailing list
| [email protected]
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=xsk5PcsYEt_KVg7TP9YF66RP-SQnean6GQq5Ri7mmgo&s=F4jgoi0FYp9JopiVMqpv2zQ3BU5rLMwDPh-I8qzgltI&e= 
| 

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned