Connected: An Internet Encyclopedia
RFC 1812 - 4.2.2.11 Addressing: RFC 791 Section 3.2

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1812
Up: 4. INTERNET LAYER - PROTOCOLS
Up: 4.2 INTERNET PROTOCOL - IP
Up: 4.2.2 PROTOCOL WALK-THROUGH
Prev: 4.2.2.10 Multi-subnet Broadcasts: RFC 922
Next: 4.2.3 SPECIFIC ISSUES

### 4.2.2.11 Addressing: RFC 791 Section 3.2

As noted in 2.2.5.1, there are now five classes of IP addresses: Class A through Class E. Class D addresses are used for IP multicasting [INTERNET:4], while Class E addresses are reserved for experimental use. The distinction between Class A, B, and C addresses is no longer important; they are used as generalized unicast network prefixes with only historical interest in their class.

An IP multicast address is a 28-bit logical address that stands for a group of hosts, and may be either permanent or transient. Permanent multicast addresses are allocated by the Internet Assigned Number Authority [INTRO:7], while transient addresses may be allocated dynamically to transient groups. Group membership is determined dynamically using IGMP [INTERNET:4].

We now summarize the important special cases for general purpose unicast IP addresses, using the following notation for an IP address:

        { <Network-prefix>, <Host-number> }

and the notation -1 for a field that contains all 1 bits and the notation 0 for a field that contains all 0 bits.

1. { 0, 0 }

   This host on this network. It MUST NOT be used as a source address by routers, except the router MAY use this as a source address as part of an initialization procedure (e.g., if the router is using BOOTP to load its configuration information).

   Incoming datagrams with a source address of { 0, 0 } which are received for local delivery (see Section [5.2.3]), MUST be accepted if the router implements the associated protocol and that protocol clearly defines appropriate action to be taken. Otherwise, a router MUST silently discard any locally-delivered datagram whose source address is { 0, 0 }.

   DISCUSSION

     Some protocols define specific actions to take in response to a received datagram whose source address is { 0, 0 }. Two examples are BOOTP and ICMP Mask Request. The proper operation of these protocols often depends on the ability to receive datagrams whose source address is { 0, 0 }. For most protocols, however, it is best to ignore datagrams having a source address of { 0, 0 } since they were probably generated by a misconfigured host or router. Thus, if a router knows how to deal with a given datagram having a { 0, 0 } source address, the router MUST accept it. Otherwise, the router MUST discard it.

   See also Section [4.2.3.1] for a non-standard use of { 0, 0 }.

2. { 0, <Host-number> }

   Specified host on this network. It MUST NOT be sent by routers except that the router MAY use this as a source address as part of an initialization procedure by which the it learns its own IP address.

3. { -1, -1 }

   Limited broadcast. It MUST NOT be used as a source address.

   A datagram with this destination address will be received by every host and router on the connected physical network, but will not be forwarded outside that network.

4. { <Network-prefix>, -1 }

   Directed Broadcast - a broadcast directed to the specified network prefix. It MUST NOT be used as a source address. A router MAY originate Network Directed Broadcast packets. A router MUST receive Network Directed Broadcast packets; however a router MAY have a configuration option to prevent reception of these packets. Such an option MUST default to allowing reception.

5. { 127, <any> }

   Internal host loopback address. Addresses of this form MUST NOT appear outside a host.

The <Network-prefix> is administratively assigned so that its value will be unique in the routing domain to which the device is connected.

IP addresses are not permitted to have the value 0 or -1 for the <Host-number> or <Network-prefix> fields except in the special cases listed above. This implies that each of these fields will be at least two bits long.

DISCUSSION

  Previous versions of this document also noted that subnet numbers must be neither 0 nor -1, and must be at least two bits in length. In a CIDR world, the subnet number is clearly an extension of the network prefix and cannot be interpreted without the remainder of the prefix. This restriction of subnet numbers is therefore meaningless in view of CIDR and may be safely ignored.

For further discussion of broadcast addresses, see Section [4.2.3.1].

When a router originates any datagram, the IP source address MUST be one of its own IP addresses (but not a broadcast or multicast address). The only exception is during initialization.

For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the router's IP addresses; that is to say:

- A router MUST receive and process normally any packets with a broadcast destination address.

- A router MUST receive and process normally any packets sent to a multicast destination address that the router has asked to receive.

The term specific-destination address means the equivalent local IP address of the host. The specific-destination address is defined to be the destination address in the IP header unless the header contains a broadcast or multicast address, in which case the specific-destination is an IP address assigned to the physical interface on which the datagram arrived.

A router MUST silently discard any received datagram containing an IP source address that is invalid by the rules of this section. This validation could be done either by the IP layer or (when appropriate) by each protocol in the transport layer. As with any datagram a router discards, the datagram discard SHOULD be counted.

DISCUSSION

  A misaddressed datagram might be caused by a Link Layer broadcast of a unicast datagram or by another router or host that is confused or misconfigured.

Next: 4.2.3 SPECIFIC ISSUES

Connected: An Internet Encyclopedia
RFC 1812 - 4.2.2.11 Addressing: RFC 791 Section 3.2