Internet DRAFT - draft-karstens-pim-ipv6-zeroconf-assignment
draft-karstens-pim-ipv6-zeroconf-assignment
Network Working Group N. Karstens
Internet-Draft Garmin International
Intended status: Informational D. Farinacci
Expires: 27 September 2023 lispers.net
M. McBride
Futurewei
26 March 2023
Zero-Configuration Assignment of IPv6 Multicast Addresses
draft-karstens-pim-ipv6-zeroconf-assignment-01
Abstract
Marine networks contain a combination of sensors, controls, and
displays. The latest marine industry standards require IPv6. The
most optimal way to distribute sensor data to all displays on the
network is multicast. However, use of traditional switches can be
problematic (overwhelm links) when both high-bandwidth and low-
bandwidth devices are installed. To solve this problem, the network
requires switches with multicast snooping. However, source-specific
multicast (SSM) is not supported on marine switches so the
destination address is the only way to differentiate multicast
streams. This limitation creates several challenges including with
the pre-allocation of multicast group addresses. The solution,
described in this draft, provides a decentralized, zero-configuration
method for dynamically assigning multicast group addresses through
defining an extension to the multicast portion of the IPv6 addressing
architecture along with a new table in the IPv6 Multicast Address
Space Registry.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 September 2023.
Karstens, et al. Expires 27 September 2023 [Page 1]
Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs March 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Technical Background . . . . . . . . . . . . . . . . . . . . 4
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Marine networks contain a combination of sensors, controls, and
displays. Installations vary widely depending on the design and
intended purpose of the boat and the amount of redundancy required.
Sensors on these networks can be a mix of low-cost, low-bandwidth
devices, like temperature or fluid sensors, and high-bandwidth
devices, like radar, sonar, and video cameras. In most cases these
networks use a single subnet and therefore require layer-2 switches
to be deployed. The latest marine industry standards require IPv6.
Karstens, et al. Expires 27 September 2023 [Page 2]
Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs March 2023
The most optimal way to distribute sensor data to all displays on the
network is multicast. However, use of traditional switches can be
problematic when both high-bandwidth and low-bandwidth devices are
installed. Low-bandwidth devices are commonly designed with a low-
speed link to reduce cost, and the multicast stream from the high-
bandwidth device can overwhelm this link. To solve this problem, the
network requires switches with multicast snooping [RFC4541], which
directs multicast streams only to the ports leading to devices that
request the data.
Low-end switch hardware at low price points do not support source-
specific multicast, so the destination address is the only way to
differentiate multicast streams. This presents several challenges.
First, defining an industry standard set of pre-allocated addresses
is not practical due to the wide variety of network designs. Users
in the marine industry would not find static assignment to be
acceptable. MADCAP [RFC2730] could be used to dynamically assign
addresses, but its reliance on a dedicated server results in a single
point of failure for the system, which is not acceptable in the
marine environment.
The solution, proposed in this draft, is a decentralized, zero-
configuration method for dynamically assigning multicast addresses.
This document defines an extension to the multicast portion of the
IPv6 addressing architecture [RFC4291]. The current architecture
does not account for potential address collisions when IPv6 multicast
packets are transmitted on the data link layer. This extension
defines a collision detection mechanism that utilizes
Multicast DNS [RFC6762] to distribute a database of dynamically
assigned multicast Ethernet addresses.
It also proposes a new table in the IANA IPv6 Multicast Address Space
Registry based on amendments to Section 4.3 of [RFC3307]. This will
allow for different methods of dynamically allocating IPv6 multicast
addresses to coexist on the same network.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Karstens, et al. Expires 27 September 2023 [Page 3]
Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs March 2023
2. Technical Background
Link-scoped IPv6 multicast addresses [RFC4489] are an effective way
to dynamically allocate multicast addresses on the local link.
Because this method utilizes SLAAC it is also a zero-configuration
technology.
However, according to [RFC4541], Section 4, most switch vendors
forward multicast traffic based only on the MAC address (see the
results for Q2 and Q3). There is a problem when transmitting link-
scoped IPv6 multicast addresses on Ethernet. According to [RFC2464],
Section 7, the destination multicast Ethernet address is generated by
combining the hexadecimal value 3333 with the last four octets of the
destination multicast IPv6 address. These last four octets
correspond with the group ID in the link-scoped IPv6 multicast
address, meaning that any two applications that happen to choose the
same group ID will transmit using the same destination multicast
Ethernet address. This prevents multicast snooping switches from
directing traffic only to devices interested in the data, and may
result in a low-bandwidth link being saturated by a high-bandwidth
stream.
3. Design Goals
The primary goal is to define a zero-configuration method for
dynamically assigning IPv6 multicast addresses and preventing
collisions at the Ethernet layer. This method must allow for
multiple streams to be transmitted from the same host by different
applications that are not communicating through another channel.
A secondary goal is to allow several methods for dynamically
assigning IPv6 multicast addresses to coexist on the same network
without user configuration.
Advertising the data contained in each multicast stream is discussed
in [I-D.karstens-dnssd-dns-msd].
4. Method
When an application is preparing to transmit a multicast stream it
generates a link-scoped IPv6 multicast address [RFC4489]. The
Interface Identifier (IID) part of this address is taken from the
intended source address for the multicast stream. The group ID is a
random value in the range reserved for mDNS-based dynamic IPv6
multicast address allocation algorithms (see below). The application
then calculates the multicast Ethernet address that will be used to
transmit the data [RFC2464], Section 7 and generates a string akin to
a reverse mapping domain using a new "eth-addr.arpa" special-use
Karstens, et al. Expires 27 September 2023 [Page 4]
Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs March 2023
domain.
For example, given a source address of FE80::A12:34FF:FE56:7890, the
IPv6 multicast address may be FF32:00FF:A12:34FF:FE56:7890:CFED:2468,
the multicast Ethernet address 33:33:CF:ED:24:68, and the string
"8.6.4.2.d.e.f.c.3.3.3.3.eth-addr.arpa".
The application then uses the mDNS probing algorithm described in
[RFC6762], Section 8.1 to continuously query for a PTR record with
the generated string for the name. If the probing algorithm
completes without any conflict, then the application begins
advertising its own PTR record using that name. The PTRDNAME field
consists of a unique application identifier, in the form of a DNS
label, followed by the device's host name (for example,
"application.example.local.". Integrating a unique identifier in
this manner allows for multiple applications to be on the same host.
Once the PTR record is advertised, the host may then begin
transmitting multicast data using the generated address.
The application shall retain the group ID value and use it the next
time the multicast stream is transmitted. This allows the network to
quickly settle on a configuration that will never have another
collision as long as the network is unchanged.
If at any point the query returns a result from a different host,
then the application stops transmitting that multicast stream and
start the process over using a different group ID.
The host should monitor the bus for traffic that uses the same
destination multicast Ethernet address, but a different destination
multicast IPv6 address. If this is detected then the application
acts as if the collision had been detected from the mDNS query.
While intended primarily for allocating IPv6 multicast addresses on
the same subnet (link-local scope), the same technique could also
apply to a larger network as long as mDNS traffic is routed between
subnets (for any scope excluding global scope).
5. IANA Considerations
The special-use domain "eth-addr.arpa" should be registered in the
.arpa registry (https://www.iana.org/domains/arpa) and the "Special-
Use Domain Names" registry (https://www.iana.org/assignments/special-
use-domain-names).
Karstens, et al. Expires 27 September 2023 [Page 5]
Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs March 2023
IANA should create a new table in the IPv6 Multicast Address Space
Registry that contains ranges for dynamic multicast group IDs and is
based on the description in [RFC3307], Section 4.3. The registry
should initially contain the following entries:
+-----------------------+------------------------------------+
| 0x80000000-0xBFFFFFFF | MADCAP [RFC2730] |
+-----------------------+------------------------------------+
| 0xC0000000-0xCFFFFFFF | mDNS-based zero-configuration |
| | algorithm described above |
+-----------------------+------------------------------------+
| 0xD0000000-0xFEFFFFFF | Reserved for future zero- |
| | configuration algorithms |
+-----------------------+------------------------------------+
| 0xFF000000-0xFFFFFFFF | Solicited-node multicast addresses |
| | [RFC4291], Section 2.7.1 |
+-----------------------+------------------------------------+
Table 1
6. Security Considerations
This algorithm only works in environments where all hosts are
cooperating. Malicious hosts could deny service by either repeatedly
responding to queries for a given address or by flooding the network
with traffic.
7. Acknowledgement
Special thanks to the National Marine Electronics Association for
their contributions in developing marine industry standards and their
support for this research.
Thanks also to the members of the PIM working group for their early
brainstorming sessions and review of this draft.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
Karstens, et al. Expires 27 September 2023 [Page 6]
Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs March 2023
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<https://www.rfc-editor.org/info/rfc3307>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4489] Park, J., Shin, M., and H. Kim, "A Method for Generating
Link-Scoped IPv6 Multicast Addresses", RFC 4489,
DOI 10.17487/RFC4489, April 2006,
<https://www.rfc-editor.org/info/rfc4489>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[I-D.karstens-dnssd-dns-msd]
Karstens, N., Farinacci, D., and M. McBride, "DNS-Based
Multicast Stream Discovery", Work in Progress, Internet-
Draft, draft-karstens-dnssd-dns-msd-00, 12 January 2023,
<https://datatracker.ietf.org/doc/html/draft-karstens-
dnssd-dns-msd-00>.
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
DOI 10.17487/RFC2730, December 1999,
<https://www.rfc-editor.org/info/rfc2730>.
Authors' Addresses
Nate Karstens
Garmin International
Email: nate.karstens@gmail.com
Karstens, et al. Expires 27 September 2023 [Page 7]
Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs March 2023
Dino Farinacci
lispers.net
Email: farinacci@gmail.com
Mike McBride
Futurewei
Email: michael.mcbride@futurewei.com
Karstens, et al. Expires 27 September 2023 [Page 8]
