As per Relevance of the word broadcast, we have this rfc below:
Network Working Group A.
Request for Comments: 3021 R.
Category: Standards Track Cisco
V.
GTE
D.
Amber
December 2000
Using 31-Bit Prefixes on IPv4 Point-to-Point
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
With ever-increasing pressure to conserve IP address space on
Internet, it makes sense to consider where relatively minor
can be made to fielded practice to improve numbering efficiency.
such change, proposed by this document, is to halve the amount
address space assigned to point-to-point links (common throughout
Internet infrastructure) by allowing the use of 31-bit subnet
in a very limited way
1. Introduction and
The perceived problem of a lack of Internet addresses has driven
number of changes in address space usage and a number of
approaches to solving the problem
- More stringent address space allocation guidelines, enforced by
IANA and the regional address assignment authorities [RFC2050].
- Use of Network Address Translators (NATs), where a small number
IANA-compliant addresses are shared by a larger pool of private
non-globally routed addresses topologically behind a NAT
[RFC1631].
Retana, et al. Standards Track [Page 1]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
- Deployment of a new Internet Protocol to increase the size of
address space. One such protocol, IPv6 [RFC2460], has been
the IETF process but has yet to see production deployment.
it be, deployed, it will still face a many year transition period
Prior to the availability of a larger address space, it seems
to consider opportunities for making more efficient use of
existing address space
One such (small) opportunity is to change the way that point-to-
links are numbered. One option, which is used today on some parts
the Internet, is to simply not number point-to-point links
routers. While this practice may seem, at first, to handily
the problem, it causes a number of problems of its own, including
inability to consistently manage the unnumbered link or reach
router through it, difficulty in management and debugging of
links, and the lack of standardization [RFC1812].
In current practice, numbered Internet subnets do not use longer
a 30-bit subnet mask (in most cases), which requires four
per link - two host addresses, one all-zeros network, and one all
ones broadcast. This is unfortunate for point-to-point links,
they can only possibly have two identifying endpoints and don'
support the notion of broadcast - any packet which is transmitted
one end of a link is always received by the other
A third option is to use host addresses on both ends of a point-to
point link. This option provides the same address space savings
using a 31-bit subnet mask, but may only be used in links using
encapsulation [RFC1332]. The use of host addresses allows for
assignment of IP addresses belonging to different networks at
side of the link, causing link and network management not to
straight forward
This document is based on the idea that conserving IP addresses
point-to-point links (using longer than a 30-bit subnet mask)
maintaining manageability and standard interaction is possible
Existing documentation [RFC950] has already hinted at the
use of a 1-bit wide host-number field
The savings in address space resulting from this change is
seen--each point-to-point link in a large network would consume
addresses instead of four. In a network with 500 point-to-
links, for example, this practice would amount to a savings of 1000
addresses (the equivalent of four class C address spaces).
Retana, et al. Standards Track [Page 2]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
2. Considerations of 31-Bit
This section discusses the possible effects, on Internet routing
operations, of using 31-bit prefixes on point-to-point links.
considerations made here are also reflected in Section 3.
For the length of this document, an IP address will be
as
where the represents the unmasked portion of
address and it SHOULD be at least 1 bit wide. The "-1" notation
used to mean that the field has all 1 bits. For purposes of
discussion, the routing system is considered capable of classless,
CIDR [RFC1519], routing
2.1.
If a 31-bit subnet mask is assigned to a point-to-point link,
leaves the with only 1 bit. Consequently, only
possible addresses may result
{, 0} and {, -1}
These addresses have historically been associated with network
broadcast addresses (see Section 2.2). In a point-to-point link
a 31-bit subnet mask, the two addresses above MUST be interpreted
host addresses
2.2. Broadcast and Network
There are several historically recognized broadcast
[RFC1812] on IP segments
(a) the directed
{, -1}
{, 0}
The network address itself {, 0} is
obsolete form of directed broadcast, but it may still be
by older hosts
Retana, et al. Standards Track [Page 3]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
(b) the link local (or limited)
{-1, -1}
{0, 0}
The {0, 0} form of a limited broadcast is obsolete, but
still be present in a network
Using a 31-bit prefix length leaves only two numbering
(see Section 2.1), eliminating the use of a directed broadcast to
link (see Section 2.2.1). The limited broadcast MUST be used for
broadcast traffic on a point-to-point link with a 31-bit subnet
assigned to it
The is assigned by the network administrator
unique to the local routing domain. The decision as to whether
destination IP address should be a directed broadcast or not is
by the router directly connected to the destination segment.
forwarding schemes and algorithms are not affected in remote routers
The intent of this document is to discuss the applicability
operation of 31-bit prefixes on point-to-point links. The
(if any) on other types of interfaces are not considered
2.2.1. Directed
When a device wants to reach all the hosts on a given (remote,
than directly connected) subnet, it may set the packet's
address to the link's subnet broadcast address. This operation
not possible for point-to-point links with a 31-bit prefix
As discussed in Section 6, the loss of functionality of a
broadcast may actually be seen as a beneficial side effect, as
slightly enhances the network's resistance to a certain class of
Attacks [RFC2644, SMURF].
2.3. Impact on Current Routing
Networks with 31-bit prefixes have no impact on current
protocols. Most of the currently deployed routing protocols
been designed to provide classless routing. Furthermore,
communication between peers is done using multicast,
broadcast or unicast addresses (all on the local network), none
which are affected with the use of 31-bit subnet masks
Retana, et al. Standards Track [Page 4]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
3.
The considerations presented in Section 2 affect other
work. This section details the updates made to other documents
3.1. "Requirements for Internet Hosts -- Communication Layers" [RFC1122]
Section 3.2.1.3 (e) is replaced with
(e) { , , -1 }
Directed broadcast to the specified subnet. It MUST NOT
used as a source address, except when the originator is one
the endpoints of a point-to-point link with a 31-bit mask
A new section (numbered 3.2.1.3 (h)) is added
(h) { , , 0 }
Subnetwork number. SHOULD NOT be used as a source address
except when the originator is one of the endpoints of a point
to-point link with a 31-bit mask. For other types of links,
packet with such a destination SHOULD be silently discarded
If these packets are not silently discarded, they MUST
as IP broadcasts [RFC1812].
3.2. "Assigned Numbers" [RFC1700]
Sub-section (e) of the "Special Addresses" section in
"Introduction" is replaced with
(e) {, , -1}
Directed broadcast to specified subnet. Can only be used as
destination address. However, in the case where the
is one of the endpoints of a point-to-point link with a 31-
mask, it can also be used as a source address
3.3. "Requirements for IP Version 4 Routers" [RFC1812]
Section 4.2.2.11 (d) is replaced with
(d) { , -1 }
Directed Broadcast - a broadcast directed to the
network prefix. It MUST NOT be used as a source address
except when the originator is one of the endpoints of a point
Retana, et al. Standards Track [Page 5]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
to-point link with a 31-bit mask. A router MAY
Network Directed Broadcast packets. A router MAY have
configuration option to allow it to receive directed
packets, however this option MUST be disabled by default,
thus the router MUST NOT receive Network Directed
packets unless specifically configured by the end user
The text above includes the update made by [RFC2644].
A new section (numbered 4.2.2.11 (f)) is added
(f) { , , 0 }
Subnetwork number. SHOULD NOT be used as a source address
except when the originator is one of the endpoints of a point
to-point link with a 31-bit mask. For other types of links,
packet with such a destination SHOULD be silently discarded
If these packets are not silently discarded, they MUST
treated as IP broadcasts
Sections 4.2.3.1 (1), (2) and (4) are replaced with
(1) MUST treat as IP broadcasts packets addressed
255.255.255.255 or { , -1 }.
In a point-to-point link with a 31-bit mask, a packet addressed
{ , -1 } corresponds to one of the endpoints
such link, it MUST be treated as directed to the router on
the address is applied
(2) SHOULD silently discard on receipt (i.e., do not even
to applications in the router) any packet addressed to 0.0.0.0
{ , 0 }. If these packets are not
discarded, they MUST be treated as IP broadcasts (see
[5.3.5]). There MAY be a configuration option to allow receipt
these packets. This option SHOULD default to discarding them
In a point-to-point link with a 31-bit mask, a packet addressed
{ , 0 } corresponds to one of the endpoints
such link, it MUST be treated as directed to the router on
the address is applied
(4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or {
, 0 }. There MAY be a configuration option
allow generation of these packets (instead of using the
1s format broadcast). This option SHOULD default to
generating them
Retana, et al. Standards Track [Page 6]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
In a point-to-point link with a 31-bit mask, the configuration
such a mask SHOULD allow for the generation of datagrams
to { , 0 }.
The following text is added to section 4.3.3.9:
The 255.255.255.255 IP broadcast address MUST be used
broadcast Address Mask Replies in point-to-point links with 31-
subnet
4. Operational
The recommendations presented in this document have been
by several router vendors in beta code. The implementation has
tested by at least three ISPs with positive results (i.e.,
problems have been found). Among the routing protocols
successfully are OSPF, IS-IS, BGP and EIGRP
It is expected that the implementation will be officially
within the next few months and that other vendors will adopt it
5. Deployment
The intent of this document is to discuss the applicability
operation of 31-bit prefixes on point-to-point links. The
(if any) on other types of interfaces are not considered. Note
a point-to-point link in which only one end supports the use of 31-
bit prefixes may not operate correctly
6. Security
In the light of various denial of service (DoS) attacks on
networks within the Internet, security has become a major concern
The use of 31-bit subnet masks within the core of the Internet
reduce the number of physical links against which a DoS
relying on packet replication through the use of directed
can be launched [RFC2644, SMURF].
Overall, implementation of this document recommendation will
the Internet's resilience to these types of DoS attacks
7.
The authors of this document do not make any claims on
originality of the ideas described. Among other people, we
like to acknowledge Alex Zinin for his comments, and the many
who have tested 31 bit subnet masks in their labs and networks
Retana, et al. Standards Track [Page 7]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
8.
[RFC950] Mogul, J. and J. Postel, "Internet Standard
Procedure", STD 5, RFC 950, August 1985.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control
(IPCP)", RFC 1332, May 1992.
[RFC1519] Fuller, V., Li, T., Yu, J. and K. Varadhan, "
Inter-Domain Routing (CIDR): an Address Assignment
Aggregation Strategy", RFC 1519, September 1993.
[RFC1631] Egevang, K. and P. Francis, "The IP Network
Translator (NAT)", RFC 1631, May 1994.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
1700, October 1994.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
1812, June 1995.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J
Postel, "Internet Registry IP Allocation Guidelines",
12, RFC 2050, November 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
Routers", BCP 34, RFC 2644, August 1999.
[SMURF] Huegen, C., "The Latest in Denial of Service Attacks
'Smurfing': Description and Information to
Effects", URL
http://users.quadrunner.com/chuegen/smurf.
Retana, et al. Standards Track [Page 8]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
9. Authors'
Alvaro
Cisco Systems, Inc
7025 Kit Creek Rd
Research Triangle Park, NC 27709
EMail: aretana@cisco.
Russ
Cisco Systems, Inc
7025 Kit Creek Rd
Research Triangle Park, NC 27709
EMail: riw@cisco.
Vince
GTE
3801 E. Bayshore Rd
Palo Alto, CA, 94303
EMail: vaf@valinor.barrnet.
Danny
Amber
2465 Augustine
Santa Clara, CA 95054
EMail: danny@ambernetworks.
Retana, et al. Standards Track [Page 9]
RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Retana, et al. Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
