Aprial 30th Monday (四月 三十日 月曜日)

  ARP - Although this is a protocol that lies underneath IPv4, and not a user application, ARP broadcasts
a request on the local subnet that says, "Will the system with an IP address of a.b.c.d please identify
yourself and tell me your hardware address?" ARP uses link-layer broadcast, not IP-layer, but is an example
of a use of broadcasting.

  DHCP - The client assumes a server or relay is on the local subnet and sends its request to the broadcast
address (often 255.255.255.255 since the client doesn't yet know its IP address, its subnet mask, or the
limited broadcast address of the subnet).

Broadcast Addresses

  If we denote an IPv4 address as {subnetid, hostid}, where subnetid represents the bits that are covered
by the network mask (or the CIDR prefix) and hostid represents the bits that are not, then we have two types
of broadcast addresses. We denote a field containing all one bits as -1.

  1. Subnet-directed broadcast address: {subnetid, -1} - This addresses all the interfaces on the specified subnet.
For example, if we have the subnet 192.168.42/24, then 192.168.42.255 would be the subnet-directed broadcast
address for all interfaces on the 192.168.42/24 subnet.

  Normally, routers do not forward these broadcasts.  The router receives a unicast IP datagram on the 192.168.123/24
subnet with a destination address of 192.168.42.255 (the subnet-directed broadcast address of another interface).
The router normally does not forward the datagram on to the 192.168.42/24 subnet. Some systems have a configuration
option that allows subnet-directed broadcasts to be forwarded.

  Note:  Forwarding subnet-directed broadcasts enables a class of denial-of-service attacks called "amplification"
attacks; for instance, sending an ICMP echo request to a subnet-directed broadcast address can cause multiple replies
to be sent for a single request. Combined with a forged IP source address, this results in a bandwidth utilization
attack against the victim system, so it's advisable to leave this configuration option off.

  2.  Limited broadcast address: {-1, -1, -1} or 255.255.255.255 - Datagrams destined to this address must never be
forwarded by a router.

  255.255.255.255 is to be used as the destination address during the bootstrap process by applications such as BOOTP
and DHCP, which do not yet know the node's IP address.  Most hosts allow this (assuming the process has set the SO_BROADCAST
socket option) and convert the destination address to the subnet-directed broadcast address of the outgoing interface.
It is often necessary to access the datalink directly to send a packet to 255.255.255.255.

  What does a multihomed host do when the application sends a UDP datagram to 255.255.255.255? Some systems send
a single broadcast on the primary interface (the first interface that was configured) with the destination IP address
set to the subnet-directed broadcast address of that interface.  Other systems send one copy of the datagram out
from each broadcast-capable interface.

  The subnet address of the Ethernet is 192.168.42/24 with 24 bits in the network mask, leaving 8 bits for the host ID.
The application on the left host calls sendto on a UDP socket, sending a datagram to 192.168.42.3, port 7433. The UDP
layer prepends a UDP header and passes the UDP datagram to the IP layer. IP prepends an IPv4 header, determines
the outgoing interface, and in the case of an Ethernet, ARP is invoked to map the destination IP address to
the corresponding Ethernet address: 00:0a:95:79:bc:b4. The packet is then sent as an Ethernet frame with that
48-bit address as the destination Ethernet address. The frame type field of the Ethernet frame will be 0x0800,
specifying an IPv4 packet. The frame type for an IPv6 packet is 0x86dd.

  The Ethernet interface on the host in the middle sees the frame pass by and compares the destination Ethernet
address to its own Ethernet address 00:04:ac:17:bf:38). Since they are not equal, the interface ignores the frame.
With a unicast frame, there is no overhead whatsoever to this host. The interface ignores the frame.

  The Ethernet interface on the host on the right also sees the frame pass by, and when it compares the destination
Ethernet address with its own Ethernet address, they are equal. This interface reads in the entire frame, probably
generates a hardware interrupt when the frame is complete, and the device driver reads the frame from the interface
memory. Since the frame type is 0x0800, the packet is placed on the IP input queue.

  When the IP layer processes the packet, it first compares the destination IP address (192.168.42.3) with all
of its own IP addresses. Since the destination address is one of the host's own IP addresses, the packet is accepted.

  The IP layer then looks at the protocol field in the IPv4 header, and its value will be 17 for UDP. The IP datagram
is passed to UDP.

  The UDP layer looks at the destination port (and possibly the source port, too, if the UDP socket is connected),
and in our example, places the datagram onto the appropriate socket receive queue. The process is awakened, if necessary,
to read the newly received datagram.

  The key point in this example is that a unicast IP datagram is received by only the one host specified by the destination
IP address. No other hosts on the subnet are affected.

  When the host on the left sends the datagram, it notices that the destination IP address is the subnet-directed broadcast
address and maps this into the Ethernet address of 48 one bits: ff:ff:ff:ff:ff:ff. This causes every Ethernet interface on
the subnet to receive the frame. The two hosts on the right of this figure that are running IPv4 will both receive the frame.
Since the Ethernet frame type is 0x0800, both hosts pass the packet to the IP layer. Since the destination IP address matches
the broadcast address for each of the two hosts, and since the protocol field is 17 (UDP), both hosts pass the packet up to UDP.

  The host on the right passes the UDP datagram to the application that has bound UDP port 520. Nothing special needs to be
done by an application to receive a broadcast UDP datagram: It just creates a UDP socket and binds the application's port number
to the socket. (We assume the IP address bound is INADDR_ANY, which is typical.)

  On the host in the middle, no application has bound UDP port 520. The host's UDP code then discards the received datagram.
This host must not send an ICMP "port unreachable," as doing so could generate a broadcast storm: a condition where lots of
hosts on the subnet generate a response at about the same time, leading to the network being unusable for a period of time.
In addition, it's not clear what the sending host would do with an ICMP error: What if some receivers report errors and others
don't?

  a unicast address identifies a single IP interface, a broadcast address identifies all IP interfaces on the subnet, and
a multicast address identifies a set of IP interfaces. Unicasting and broadcasting are the extremes of the addressing spectrum
(one or all) and the intent of multicasting is to allow addressing something in between. A multicast datagram should be received
only by those interfaces interested in the datagram, that is, by the interfaces on the hosts running applications wishing to
participate in the multicast group. Also, broadcasting is normally limited to a LAN, whereas multicasting can be used on
a LAN or across a WAN.

IPv4 Class D Addresses

  The low-order 28 bits of a class D address form the multicast group ID and the 32-bit address is called the group address.
Considering just the IPv4 mapping, the high-order 24 bits of the Ethernet address are always 01:00:5e. The next bit is always 0,
and the low-order 23 bits are copied from the low-order 23 bits of the multicast group address. The high-order 5 bits of the
group address are ignored in the mapping. This means that 32 multicast addresses map to a single Ethernet address: The mapping
is not one-to-one.

  The low-order 2 bits of the first byte of the Ethernet address identify the address as a universally administered group address.
Universally administered means the high-order 24 bits have been assigned by the IEEE and group addresses are recognized and handled
specially by receiving interfaces.

  There are a few special IPv4 multicast addresses:

  1. 224.0.0.1 is the all-hosts group. All multicast-capable nodes (hosts, routers, printers, etc.) on a subnet must join this
group on all multicast-capable interfaces. (We will talk about what it means to join a multicast group shortly.)

  2. 224.0.0.2 is the all-routers group. All multicast-capable routers on a subnet must join this group on all multicast-capable
interfaces.

  The range 224.0.0.0 through 224.0.0.255 (which we can also write as 224.0.0.0/24) is called link local. These addresses are
reserved for low-level topology discovery or maintenance protocols, and datagrams destined to any of these addresses are never
forwarded by a multicast router.

IPv6 Multicast Addresses

  The high-order byte of an IPv6 multicast address has the value ff. The low-order 32 bits of the group address are copied into
the low-order 32 bits of the Ethernet address. The high-order 2 bytes of the Ethernet address are 33:33. The low-order two bits
of the first byte of the Ethernet address specify the address as a locally administered group address. Locally administered means
there is no guarantee that the address is unique to IPv6.  Locally administered means there is no guarantee that the address is
unique to IPv6. There could be other protocol suites besides IPv6 sharing the network and using the same high-order two bytes of
the Ethernet address.

  The low-order two bits of the first byte of the Ethernet address specify the address as a locally administered group address.
Locally administered means there is no guarantee that the address is unique to IPv6. There could be other protocol suites besides
IPv6 sharing the network and using the same high-order two bytes of the Ethernet address. As we mentioned earlier, group addresses
are recognized and handled specially by receiving interfaces.

  There are a few special IPv6 multicast addresses:

  1. ff01::1 and ff02::1 are the all-nodes groups at interface-local and link-local scope. All nodes (hosts, routers, printers,
etc.) on a subnet must join these groups on all multicast-capable interfaces. This is similar to the IPv4 224.0.0.1 multicast
address. However, since multicast is an integral part of IPv6, unlike IPv4, this is not optional.

  Although the IPv4 group is called the all-hosts group and the IPv6 group is called the all-nodes group, they serve the same
purpose. The group was renamed in IPv6 to make it clear that it is intended to address routers, printers, and any other IP
devices on the subnet as well as hosts.

  2. ff01::2, ff02::2 and ff05::2 are the all-routers groups at interface-local, link-local, and site-local scopes. All routers
on a subnet must join these groups on all multicast-capable interfaces. This is similar to the IPv4 224.0.0.2 multicast address.

  IPv6 multicast addresses have an explicit 4-bit scope field that specifies how "far" the multicast packet will travel. IPv6
packets also have a hop limit field that limits the number of times the packet is forwarded by a router. The following values
have been assigned to the scope field:

  1: interface-local
 
  2: link-local
 
  4: admin-local
 
  5: site-local
 
  8: organization-local
 
  14: global
 
  The remaining values are unassigned or reserved. An interface-local datagram must not be output by an interface and a link-local
datagram must never be forwarded by a router. What defines an admin region, a site, or an organization is up to the administrators
of the multicast routers at that site or organization. IPv6 multicast addresses that differ only in scope represent different groups.