RFC 1770

RFC 1770 🎀 IPv4 Option for Sender Directed Multi-Destination Delivery

okay bestie, this is RFC 1770 💅 It's from the Network Working Group, it's written by C. Graff of the US Army CECOM, it's Category: Informational, and it's dated March 1995 🗓️ It doesn't say it obsoletes or updates anything, so it's doing its own thing 🦋

---

Status of this Memo 📝

this memo is just giving info to the Internet community 🌸 It does not specify an Internet standard of any kind 🙈 Distribution of this memo is unlimited 🌈

Abstract 💖

so this memo defines an IPv4 option for sender directed multi-destination delivery, called Selective Directed Broadcast Mode (SDBM) 🦋 SDBM gives you unreliable UDP delivery to a set of IP addresses listed in the option field of an IPv4 datagram. If you need reliability, the application layer handles it 🫶 It was built for sparsely populated groups with no extra control traffic 🧚 It's going to be a whole thing in the super bandwidth-constrained tactical military environment, plus some commercial apps where the sender wants control over who gets the data 👑

Background 🌷

SDBM is an integral part of the U.S. Army standard for tactical data communication networks, defined in MIL-STD-188-220() (Reference 1) 💕 MIL-STD-188-220() defines a protocol architecture for the lower four layers of the ISO-OSI Reference model. It's currently being reformatted to match other DoD standards about IP networking ✨ These efforts provide tactical IP internetting of tactical Army broadcast radio networks, and they support fully IP compliant internetworking with other types of IP networks through commercial IP routers 🛰️ The U.S. Army's goal is a fully IP compliant internetwork architecture for all tactical battlefield data communications 🫡

The Army does, however, have a critical need for a reliable, sender directed multi-destination data transfer capability that the existing or emerging internet standards don't currently support 😭 SDBM IP option was developed to meet that need. The required data reliability comes from an acknowledgement strategy at the application layer 🤝 The hope is that this IP option, which provides multi-destination capability that current and emerging internet standards don't yet have, gets embraced by the internet community, becomes an integral part of the IP family of protocols, and gets built into commercial IP software products 🍓

SDBM Format 🧩

the SDBM lets an application explicitly list a set of intended IP destinations 🎯 This is an option in the IP layer, as shown in Figure 1. The option field is variable in length, up to a maximum of 40 octets because of the limitation of the HLEN field, as specified in STD 5, RFC 791 (Reference 2) 📏 Under this option, 38 of the 40 octets would be used for the 2 octet control field and a maximum of 9 IP addresses 💅

       1            8           16                      31

       ***************************************************
       |            |            |                       |
       |            |            |                       |
       |  TYPE      |   LENGTH   |     IP ADDRESS 1      |
       |            |            |                       |
       |            |            |                       |
       |*************************************************|
       |                         |                       |
       |  IP ADDRESS 1(Cont)     |     IP ADDRESS 2      |
       |                         |                       |
       |                         |                       |
       |*************************************************|
       |                         |                       |
       |  IP ADDRESS 2(Cont)     |     ..........        |
       |                         |                       |
       |                         |                       |
       |*************************************************|
       |                         |                       |
       |                         |                       |
       |      ..........         |     IP ADDRESS N      |
       |                         |                       |
       |                         |                       |
       |*************************************************|
       |                         |                       |
       |    IP ADDRESS N(Cont)   |        UNUSED         |
       |                         |                       |
       |                         |                       |
       ***************************************************

Figure 1: IP Option Field Layout 🧁

The TYPE field specifies the copy flag, class, and option number 🎀 The copy field says whether this option field gets copied into each fragment if the IP datagram is fragmented. The class field and option number field are set to 0 and 21 respectively. The format of the TYPE field is in Figure 2 ✨

          1                                                8
          **************************************************
          |      |           |                             |
          | COPY |   CLASS   |    OPTION NUMBER            |  =  149
          |      |           |                             |
          **************************************************

Figure 2: Type Field Layout 🌈

since the IP multi-address list shall always be copied to all IP headers during fragmentation, the COPY bit should be set to 1 🫶

Back to Figure 1: the LENGTH octet tells you how many octets are in the option field 📐 It's calculated like this:

LENGTH = 2 + 4*(number of IP addresses)

The remaining octets hold the IP addresses of the specified destination hosts. Each IP address takes up 4 octets 🍓

Transmission of SDBM datagrams 🚀

the procedures for a source host, transit router, and destination router are below 👀 When a source host has a message for multiple destination hosts, it shall:

a. Group the destination host internet addresses by their network identifiers (Net IDs). If there are N distinct Net IDs, there will be at least N distinct directed broadcast packets. If there are more that 9 destination hosts on a single net, multiple directed broadcast datagrams must be sent to that net 🧺

b. For each Net ID, form the directed broadcast address as defined in STD 3, RFC 1122 (Reference 3) for that network. The directed broadcast address is the destination address in the IP datagram, and the source address is the address of the host sending the message 📬

c. Place the entire IP address for up to 9 destination hosts on the same net in the option field defined above. The total length of all IP options in a given datagram is limited to 40 octets, as determined by the HLEN (Header Length) field, which defines the number of 32 bit words in the header. If other options are included in addition to the SDBM option, the number of addresses in the option field must be reduced accordingly 🔢

d. The formed datagram shall be transmitted and processed according to normal datagram handling procedures. 💌

When an IP SDBM datagram hits a transit router (a router not connected to the destination network), the datagram shall be processed under normal IP datagram handling procedures 🛣️ When it reaches the destination router (the destination network is directly attached to the router), the destination router shall do a, b, or c below:

a. If the local subnet has a broadcast capability, broadcast to all hosts in the network and let the hosts do the address filtering 📡

b. If the local subnet doesn't support broadcast, form a local subnet packet for each destination host in the SDBM datagram and transmit it into the network 📦

c. If the local subnet supports reliable layer 2 multi-address capability, as provided by MIL-STD-188-220() networks, use a layer 2 multi-address frame to deliver the datagram to the addresses found in the IP option field 🎉

Reception of SDBM datagrams 👂

when processing received SDBM datagrams, receiving hosts shall look inside the IP option field for their address. Processing shall continue only if the host's IP address is found inside this option field. So the source host has explicit control over which hosts process its datagrams 👑 Since SDBM uses a broadcast address in its destination field, SDBM can only be used with UDP (Reference 4) and not TCP (Reference 5). That's because TCP supports only point-to-point connections, not point-to-multi-point 🙅‍♀️

Source for MIL-STD-188-220() 📚

the MIL-STD-188-220() can be obtained by contacting:

US Army Communications Electronics Command
AMSEL-RD-SE-AIN-E (ATTN: Mr. Ted Dzik)
Fort Monmouth, NJ 07703

Comm: (908) 532-1780
Fax:  (908) 532-3398
EMail: DZIK@ain3.monmouth.army.mil

Acknowledgements 🫶

the author would like to shout out the major contributions made by Mr. Dave Macauley of ATT and Ms. Barbara Denny of SRI International. Other contributions came from members of the 188-220() committee 🌟

References 📖

(1) "MIL-STD-188-220() For Task Force XXI, Interoperability Standard
    for Digital Message Transfer Device Subsystems, 23 December 1994.

(2) Postel, J., "Internet Protocol - DARPA Internet Program Protocol
    Specification", STD 5, RFC 791, DARPA, September 1981.

(3) Braden, R., Editor, "Requirements for Internet Hosts --
    Communication Layers" STD 3, RFC 1122, IETF, October 1989.

(4) Postel, J., "User Datagram Protocol", STD 6, RFC 768,
    USC/Information Sciences Institute, August 1980.

(5) Postel, J., "Transmission Control Protocol - DARPA Internet
    Program Protocol Specification", STD 7, RFC 793, September 1981.

Security Considerations 🚨

Security issues are not discussed in this memo. 😭 Nothing about security in here, so keep that in mind as you read.

Author's Address 💌

US Army Communications Electronics Command
AMSEL-RD-ST-LA-L ( ATTN: Charles Graff )
Ft. Monmouth, NJ 07703

Phone: (908) 544 3264
Fax:   (908) 544 2150
EMail: bud@fotlan5.fotlan.army.mil

that's the whole RFC, bestie 🌈💖✨