system/systemd
system/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd synced 2024-10-07 00:30:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

man/systemd.network(5): unify descriptions of MUDURL=

Browse source 
Let's write one good description and refer to it from the other two
spots.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2020-09-29 12:27:19 +02:00
parent 9e7600cfd7
commit 0558f3035f
1 changed files with 18 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
man/systemd.network.xml
View file

@ -1548,11 +1548,16 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<varlistentry>
<term><varname>MUDURL=</varname></term>
<listitem>
<para>When configured, the Manufacturer Usage Descriptions (MUD) URL will be sent to the
DHCPv4 server. Takes an URL of length up to 255 characters. A superficial verification that
the string is a valid URL will be performed. DHCPv4 clients are intended to have at most one
MUD URL associated with them. See
<ulink url="https://tools.ietf.org/html/rfc8520">RFC 8520</ulink>.</para>
<para>When configured, the specified Manufacturer Usage Description (MUD) URL will be sent to the
DHCPv4 server. Takes a URL of length up to 255 characters. A superficial verification that the
string is a valid URL will be performed. DHCPv4 clients are intended to have at most one MUD URL
associated with them. See <ulink url="https://tools.ietf.org/html/rfc8520">RFC 8520</ulink>.
</para>
<para>MUD is an embedded software standard defined by the IETF that allows IoT device makers to
advertise device specifications, including the intended communication patterns for their device
when it connects to the network. The network can then use this to author a context-specific
access policy, so the device functions only within those parameters.</para>
</listitem>
</varlistentry>
@ -1847,10 +1852,9 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<varlistentry>
<term><varname>MUDURL=</varname></term>
<listitem>
<para>When configured, the Manufacturer Usage Descriptions (MUD) URL will be sent to the DHCPV6 server.
Takes an URL of length up to 255 characters. A superficial verification that the string is a valid URL
will be performed. DHCPv6 clients are intended to have at most one MUD URL associated with them. See
<ulink url="https://tools.ietf.org/html/rfc8520">RFC 8520</ulink>.</para>
<para>When configured, the specified Manufacturer Usage Description (MUD) URL will be sent to
the DHCPV6 server. The syntax and semantics are the same as for <varname>MUDURL=</varname> in the
[DHCPv4] section described above.</para>
</listitem>
</varlistentry>
@ -2567,14 +2571,11 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<varlistentry>
<term><varname>MUDURL=</varname></term>
<listitem>
<para>Controls support for Ethernet LLDP packet's Manufacturer Usage Description (MUD). MUD is an embedded software
standard defined by the IETF that allows IoT Device makers to advertise device specifications, including the intended
communication patterns for their device when it connects to the network. The network can then use this intent to author
a context-specific access policy, so the device functions only within those parameters. Takes an URL of length up to 255
characters. A superficial verification that the string is a valid URL
will be performed. See
<ulink url="https://tools.ietf.org/html/rfc8520">RFC 8520</ulink> for details. The MUD URL received
from the LLDP packets will be saved at the state files and can be read via
<para>When configured, the specified Manufacturer Usage Descriptions (MUD) URL will be sent in
LLDP packets. The syntax and semantics are the same as for <varname>MUDURL=</varname> in the
[DHCPv4] section described above.</para>
<para>The MUD URLs received via LLDP packets are saved and can be read using the
<function>sd_lldp_neighbor_get_mud_url()</function> function.</para>
</listitem>
</varlistentry>