Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses

[Michael McBride <[e-mail]>]

Hi Nate,

And thank you for your very thorough presentation in Philly and the follow up. This information is very helpful. And thanks to Dino for his creative solutions.

We really need a draft especially since you are proposing updating an RFC. I'll ping you offline about how to do this and perhaps we can have something ready to go for the upcoming meeting in London.

mike

-----Original Message-----
From: pim <[e-mail]> On Behalf Of Karstens, Nate
Sent: Thursday, October 6, 2022 12:28 AM
To: [e-mail]
Subject: Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses

Good morning,

I would like to first thank everyone for their hospitality at the Philadelphia IETF conference, it was a really great experience meeting everyone and getting to collaborate on this problem.

It's been a while since discussing this issue, so I wanted to summarize it again and include some new information we figured out during the conference that has not been posted to the mailing list. I apologize for the delay in this and for the long email.

Marine networks can be a mix of low-bandwidth embedded sensors and high-bandwidth streams for radar and video data, and most of this data is sent using IPv6 multicast on the local network. In order to prevent high-bandwidth streams from overwhelming low-bandwidth links, we assign traffic to different multicast addresses and then use multicast snooping to direct those streams only to hosts that request them.

The switch hardware common to price points in this market only supports configuring multicast snooping based on the destination MAC address, the hardware does not support source-specific multicast. Because of this we need to be able to dynamically assign destination multicast addresses and configure the switch to forward traffic accordingly.

RFC 4489 describes a method to do this: the link-scoped IPv6 multicast address. This assigns known values to the most significant 32 bits of the IPv6 multicast address, sets the middle 64 bits to the IID (from the IPv6LL address), and dynamically assigns the least significant 32 bits according to RFC 3307. However, the switch hardware only supports configuration based on the destination IPv6 address (which lines up with Q2 and Q3 in RFC 4541 section 4).

When IPv6 multicast packets are transmitted on Ethernet, they use a destination MAC address of 33:33:XX:XX:XX:XX, where the 32 bits of X are replaced with the least-significant 32 bits of the destination IPv6 multicast address. The means that even different IPv6 multicast addresses can be transmitted using the same Ethernet multicast address and result in duplicates.

There are two characteristics of our market that are different than most Internet systems and that make existing solutions infeasible. First, because marine networks facilitate the operational safety of the vessel, the network cannot contain any central points of failure. This requirement prevents the use of a MADCAP server (see RFC 2730) to dynamically assign multicast addresses.

The second characteristic is that our typical user does not understand networking and cannot be expected to manually configure this functionality. This precludes statically-assigning multicast addresses.

Finally, one additional characteristic of the network is that multicast streams can originate both from applications on different hosts and different applications on the same host. Any protocol used to dynamically assign multicast addresses must support both scenarios on the same network.

In summary, here are our requirements:

  1) Dynamically assign IPv6 multicast addresses
  2) Ensure corresponding Ethernet multicast addresses are unique
  3) Support applications running both on the same host and on different hosts
  4) Cannot rely on a central point of failure
  5) Cannot use source-specific multicast
  6) Cannot require user configuration

Also, we can assume that discovering the multicast address used for a given stream is outside the scope of this discussion (it is application-dependent).

During the meeting, Dino suggested combining several unique elements of each stream and using a hashing algorithm to reduce them to 32 bits. Relying on other sources of uniqueness is a good idea, but there is still a possibility of collisions and so this would have to be supported by a mechanism to detect this and make adjustments. Once you have to add a detection algorithm, then in practice it is easier (and probably more universal) to use a random 32 bit value instead of performing a hash. Dino then suggested collision detection could take the form of publishing the address using mDNS, which I think is a really promising idea.

Here we can draw inspiration from the DNS reverse lookup. Network hosts publish PTR records where the name is a string representation of the IP address and the RDATA is the host name. RFC 8501 contains some examples:

  1) A host with IPv4 address 192.0.2.1 would publish a PTR record with name 1.2.0.192.in-addr.arpa.
  2) A host with IPv6 address 2001:0db8:0f00:0000:0012:34ff:fe56:789a would publish a PTR record with name a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.

We could use a similar technique and publish the IPv6 multicast address, but this does not help detect collisions. New applications wanting to transmit would use mDNS to query for a PTR record using the randomly-generated IPv6 multicast address. However, we also know that only the least significant 32 bits of this address matter when determining uniqueness on Ethernet. We could mask off everything but those 32 bits, but at that point it probably makes as much sense to publish the Ethernet multicast address. So, here is our current proposed solution:

  1) The application generates a link-scoped IPv6 multicast address (see RFC 4489) using a random value in the dynamic range 0x80000000-0xFFFFFFFF (see RFC 3307).
  2) Before transmitting, the application uses mDNS to query the network for a PTR record of the format z.y.w.x.v.u.t.s.3.3.3.3.eth-addr.arpa where the letters s-z are replaced with the least significant 32 bits of the IPv6 multicast address, as is done with ip6.arpa PTR records.
  3) If a record is found, then the above steps are repeated using a different random number. (Note that this can find records on the same host and on different hosts).
  4) If the query times out without receiving any replies, then the application publishes its own PTR record and begins transmitting. The TTL value of the record should be 60 minutes.
  5) The application continues to query for the PTR record and actively monitors for any IPv6 multicast traffic that does not originate from the applicaton. If a collision is detected then the process starts over.

There are a few standards-related updates that I would suggest to support this:

  1) Update the dynamic allocations in RFC 3307 to split the dynamic IPv6 multicast address block in three:
      a) 0x80000000-0xBFFFFFFF for centralized dynamic configuration protocols like MADCAP
      b) 0xC0000000-0xCFFFFFFF for the mDNS-based zero-configuration algorithm described above
      c) 0xD0000000-0xFFFFFFFF reserved for future zero-configuration algorithms
2) Reserve the eth-addr.arpa zone with IANA (see https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fdomains%2Farpa&amp;data=05%7C01%7Cmichael.mcbride%40futurewei.com%7C2dd88e57ea7045d4ed8308daa76c4461%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638006380704887995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&amp;sdata=bNZrI%2F%2F7%2B4KHg%2F0pShXzKr8fdKvDyOwZMgY0omqgsKU%3D&amp;reserved=0) and designate it for use with this protocol

Thanks again for your help with this. Please let me know if you have any questions or thoughts.

Nate

-----Original Message-----
From: pim <[e-mail]> On Behalf Of Karstens, Nate
Sent: Monday, June 27, 2022 11:56
To: Brian Haberman <[e-mail]>; Michael McBride <[e-mail]>; Stig Venaas <[e-mail]>; Gyan Mishra <[e-mail]>
Cc: [e-mail]
Subject: Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses

Brian,

Yes, the "Nodes supplying multicast services in a zeroconf environment generate multicast addresses without the need of centralized control" use case described in that section fits our application exactly. Section 4.3, dynamic IPv6 multicast addresses and how these are mapped to Ethernet group addresses, is also applicable. The host-based allocation described in 4.3.2 is what we are looking for, but with ZMAAP being in a draft state we were hesitant to use it. We also thought it would be useful to take another look in light of our requirement to use multicast snooping to optimize traffic delivery.

Thanks,

Nate

-----Original Message-----
From: Brian Haberman <[e-mail]>
Sent: Saturday, June 25, 2022 15:47
To: Karstens, Nate <[e-mail]>; Michael McBride <[e-mail]>; Stig Venaas <[e-mail]>; Gyan Mishra <[e-mail]>
Cc: [e-mail]
Subject: Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses

Hi Nate,
      I should have mentioned this earlier, please look at RFC 3307 and see if section 3 captures your use case.

Brian

On 6/25/22 9:21 AM, Karstens, Nate wrote:
> Michael McBride on 9 June:
>> I'd recommend presenting in pim and then, depending upon how much time we have to discuss during the meeting, we can always grab a room with those interested and hash it out in more detail.
> Mike - That would be great, thanks!
> 
> Brian Haberman on 8 June:
>> Have you read RFC 3306?
> Brian - Yes, I have read that. RFC 4489 is related and relevant to this - it describes how a block of link-scoped ("scop MUST be <= 2") multicast addresses are allocated with each IPv6LL address. This is really useful, but there is a problem when this is transmitted on Ethernet. RFC 2464 section 7 describes how multicast IPv6 addresses are mapped to Ethernet; the multicast Ethernet address consists of 33:33:XX:XX:XX:XX, where the last four octets are set to the last four octets of the IPv6LL address (the group ID from RFC 3306 section 4). This mapping completely removes the interface identifier from the Ethernet address. Using a naïve algorithm for assigning group IDs, where each host starts at zero and increments for each new multicast address transmitted by the device, results in colliding Ethernet multicast addresses. Most (or all) switches only look at the Ethernet address when switching packets, so traffic will be directed to ports with hosts that did not join the IPv6 multicast group, but joined a different group that happens to share the same multicast Ethernet address.
> 
> Gyan Mishra on 9 June:
>> I believe what you are looking for is a RFC 2907 & RFC 2730 MADCAP style method of dynamically allocating multicast address to clients.
> Gyan - That is something we considered. With our market we try to avoid single points of failure on the network. MADCAP uses a pre-defined server to allocate multicast addresses. Adapting this to our use case would require an election algorithm to determine which device would assume the role of MADCAP server. Also, to protect against that server failing, we would need another algorithm to synchronize the allocation database across all capable hosts so that the state can be preserved in the event that the elected server becomes unavailable. These problems seemed more difficult than a protocol designed for peer-to-peer-based address allocation (both in specifying the algorithm and ensuring that vendors implemented compatible solutions).
> 
> (cont.)
>> For IPv6 address based IGMP snooping the same issue exists with the multicast mac mapping and bits lost and subject to overlap.
> Gyan - Exactly, there is an issue with address overlap.
> 
> (cont.)
>> Maybe a draft needs to be developed IPv6 address based IGMP snooping  and I think it would be beneficial to operators and avoid the overlap issue.
> That would solve the problem, but it would take a long time for that solution to be available commercially.
> 
> Cheers,
> 
> Nate
> 
> -----Original Message-----
> From: Michael McBride <[e-mail]>
> Sent: Thursday, June 9, 2022 13:56
> To: Karstens, Nate <[e-mail]>; Stig Venaas 
> <[e-mail]>; [e-mail]
> Subject: RE: [pim] Zero-Configuration Assignment of IPv6 Multicast 
> Addresses
> 
> Hi Nate,
> 
>> Hopefully that provides a good overview, but it would be great if I could come to Philadelphia to discuss further. Are there specific days you had in mind to discuss this topic?
> 
> It does, thank you. And perhaps RFC 3306 could be leveraged as Brian suggests. We won't know which day/time we will meet in Philly until the end of June. I'd recommend presenting in pim and then, depending upon how much time we have to discuss during the meeting, we can always grab a room with those interested and hash it out in more detail. If it's determined that something new (or perhaps modified) needs development then we can help you with draft designing.
> 
> mike
> 
> -----Original Message-----
> From: Karstens, Nate <[e-mail]>
> Sent: Monday, June 6, 2022 1:06 PM
> To: Stig Venaas <[e-mail]>; Michael McBride 
> <[e-mail]>; [e-mail]
> Subject: RE: [pim] Zero-Configuration Assignment of IPv6 Multicast 
> Addresses
> 
> Mike and Stig,
> 
> Sorry for the delay, it took me a while to track down some answers to your questions.
> 
> There is an abbreviated version of the standard that we can make available to anyone, though this contains very little technical detail. We can also assign full copies of the standard to individuals for non-commercial review purposes. Each copy will need to be requested and watermarked. Please let me know if you are interested and I can help facilitate this.
> 
> That being said, some of the details that would help explain the full problem were delayed to a later version of the standard so that we could publish somewhat on-time. However, I can provide a little more of the relevant information beyond what I shared below. OneNet networks are currently only link-local. Each OneNet device on the network contains one or more PGN Virtual Devices. The application layer of each PGN Virtual Device uses Parameter Groups to transmit data. Parameter Groups are basically packed data structures and are a concept used in industry-standard CAN networks running protocols like ISO 11783, J1939, or NMEA 2000. The PGN Virtual Devices hosted by a device depends on the type of sensor data that device can provide. Consider a hypothetical OneNet device that contains the following PGN Virtual Devices:
> 
> 1) Radar
> 2) Heading (to better align the radar image with the chart)
> 3) Air temperature
> 4) Humidity
> 5) Barometric pressure
> 
> The high-bandwidth Radar stream (possibly several hundred Mbps, or greater for some shore-based systems) could overwhelm the low-bandwidth links of other sensors on the network. To prevent this, each PGN Virtual Device transmits its data using a separate multicast address (though in practice, this would probably just be split between the high-bandwidth Radar and low-bandwidth heading, temperature, humidity, and pressure sensors). Network switches use multicast snooping to ensure that high-bandwidth multicast streams are kept off of the low-bandwidth links; devices with low-bandwidth links will simply not request that data.
> 
> Using interface local for this is not ideal because the PGN Virtual Devices on a OneNet device may be part of different applications installed on the same device, without any collaboration ahead of time (consider a PC with different applications from different manufacturers installed as-needed for a given vessel). This means that a PGN Virtual Device needs to negotiate an address both with other PGN Virtual Devices on the network and with PGN Virtual Devices running on the same host.
> 
> Hopefully that provides a good overview, but it would be great if I could come to Philadelphia to discuss further. Are there specific days you had in mind to discuss this topic?
> 
> Nate
> 
> -----Original Message-----
> From: Stig Venaas <[e-mail]>
> Sent: Friday, June 3, 2022 12:33
> To: Michael McBride <[e-mail]>
> Cc: Karstens, Nate <[e-mail]>; [e-mail]
> Subject: Re: [pim] Zero-Configuration Assignment of IPv6 Multicast 
> Addresses
> 
> CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> 
> 
> Hi Nate and Mike
> 
> We had some discussions about a fairly similar problem for IPv4 10-15 years ago, but it didn't go anywhere. But this is an interesting problem and I think we should look into it. At least I am interested.
> 
> Regarding multiple applications on the same host. I wonder if interface-local, scope 1, could be used for that. If the application doesn't need to use the same group on multiple interfaces, that should work. Of course if the protocol uses link-local, then that could also work for multiple applications in the same host.
> 
> Regards,
> Stig
> 
> On Wed, Jun 1, 2022 at 1:53 PM Michael McBride <[e-mail]> wrote:
>>
>> Hi Nate,
>>
>>
>>
>> Thank you for bringing this up on the list. Very interesting application of multicast. It appears we would need to purchase the OneNet standard to review it. Is there anything available we can read to delve further into the multicast aspects of the OneNet architecture? It would also be great if you could present an overview at our upcoming meeting in Philadelphia (in person or remote) the week of July 24th.
>>
>>
>>
>> This pim group is the correct group to help determine if modifying existing protocols will work or if a new one should be developed. We will likely need to also reach out to some of the individuals who worked on zeroconf (including ZMAAP). Perhaps we can revive that work in pim.
>>
>>
>>
>> mike
>>
>>
>>
>> From: pim <[e-mail]> On Behalf Of Karstens, Nate
>> Sent: Thursday, May 26, 2022 10:17 AM
>> To: [e-mail]
>> Subject: [pim] Zero-Configuration Assignment of IPv6 Multicast 
>> Addresses
>>
>>
>>
>> Greetings,
>>
>>
>>
>> I am the chair of a standards committee at the National Marine Electronics Association (NMEA). We are in the final stages of developing NMEA OneNet, a standard for Ethernet/IPv6-based communication and control of marine systems (a little background: NMEA has existing standards, NMEA 0183 and NMEA 2000, that provide similar functionality over serial and CAN).
>>
>>
>>
>> Marine networks can be a mix of low-bandwidth embedded sensors and high-bandwidth streams for radar and video data, and most of this data is sent multicast on the local network. In order to prevent high-bandwidth streams from overwhelming low-bandwidth links, we assign traffic to different multicast addresses and then use multicast snooping to direct those streams only to hosts that request them.
>>
>>
>>
>> Source-specific multicast is not feasible due to the available switch hardware. As such, we believe we have identified a need for zero-configuration assignment of IPv6 multicast addresses on the local network.
>>
>>
>>
>> We investigated MADCAP, but this is not ideal because maritime systems try to avoid single points of failure. We also found ZMAAP, which seemed promising, but it was only a draft standard that expired in 2003. Link-scoped multicast addresses also seemed promising, but when you transmit these addresses on Ethernet you get 33:33 followed by 32 bits of the group ID, so even devices that assign their own IPv6 multicast addresses using a unique IID can still collide at the Ethernet layer due to the colliding group IDs.
>>
>>
>>
>> Another related complication is that multicast streams can originate from different applications on the same host, and there is no mechanism for those applications collaborating to avoid collisions at the IPv6 layer.
>>
>>
>>
>> Instead of developing our own method, we decided it may be preferable to work with IETF to develop an Internet standard that we could then use in our work. (Or, if there is something that will work for us but we're not aware of, to learn about that). Alvaro recommended that we email this group to start the conversation and see where that leads us.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Nate Karstens
>>
>> Garmin International, Inc.
>>
>> Chair, NMEA OneNet TSC
>>
>>
>>
>> ________________________________
>>
>>
>> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
>>
>> _______________________________________________
>> pim mailing list
>> [e-mail]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
>> defense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outloo&
>> amp;data=05%7C01%7Cmichael.mcbride%40futurewei.com%7C2dd88e57ea7045d4
>> ed8308daa76c4461%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C6380063
>> 80704887995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&amp;sdata=YU0E74Bkw
>> 0HmZDDjNW%2BZD18oK9jdb43Fw3dSOtYgkAs%3D&amp;reserved=0
>> k
>> .com/?url=https*3A*2F*2Furld__;JSUl!!EJc4YC3iFmQ!RYqML25C0VPjD1Z2Ji3x
>> m
>> yLz_4RnS25ggHNMG6AaoRp31Je_grD3PzbDomzcw6RqHijLG_4DRaZd2ZK8811k9w2SxI
>> N
>> O3Ls$
>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2
>> F
>> pim_&amp;data=05%7C01%7Cmichael.mcbride%40futurewei.com%7Cecd54eb787e
>> b
>> 4bf6afa408da47f7f11e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
>> 9
>> 01427485047318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>> l
>> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TDl1rfQ
>> S
>> CTQ7MSFbvd%2BPax0uMHzfsNfCWJSSSktYh9g%3D&amp;reserved=0
>> _;!!EJc4YC3iFmQ!VWcPzFC4cjG_LQmNSJB-A6sSm6AmWHu4oMI_OdY6E5xOa_ZIjTM7d
>> m
>> MEif2-iruW_QU86IeKVUqZQg$
_______________________________________________
pim mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!EJc4YC3iFmQ!WcUIlMUpBRDvfG7AXe6YPgdO82S0vSdSa2cGA4CkWFn6d6J2c99pg5kEYLxq3-Mfd57wxPLrp2CUVtVEHCJ_AyFiesaMD94CYg%24&amp;data=05%7C01%7Cmichael.mcbride%40futurewei.com%7C2dd88e57ea7045d4ed8308daa76c4461%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638006380704887995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&amp;sdata=mBbLzjq67knmPBlhjOwN9QCpMH2C4Y23Wzu1T4Kpzx8%3D&amp;reserved=0
_______________________________________________
pim mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=05%7C01%7Cmichael.mcbride%40futurewei.com%7C2dd88e57ea7045d4ed8308daa76c4461%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638006380704887995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&amp;sdata=iDJ9bSu2I2w4uIoCgopVOD6x6S2ntIjn4bv8rpZCX6U%3D&amp;reserved=0