rfc1627.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页


RFC 1627             Network 10 Considered Harmful             July 1994


Problems with Examples

   RFC 1597 gives several examples of IP networks that need not have
   globally unique address spaces.  Each of those cases is plausible,
   but that does not make it legitimate to ENCOURAGE non-uniqueness of
   the addresses.  In fact, it is equally plausible that globally unique
   IP addresses will be required, for every one of the scenarios
   described in RFC 1597:

   - Airport displays are public information and multicasting beyond the
     airport might be useful.

   - An organization's machines which, today, do not need global
     connectivity might need it tomorrow.  Further, merging
     organizations creates havoc when the addresses collide.

   - Current use of firewalls is an artifact of limitations in the
     technology.  Let's fix the problem, not the symptom.

   - Inter-organization private links do not generate benefit from being
     any more correct in guessing which machines want to interact than
     is true for general Internet access.

   This is another point that warrants repetition: the belief that
   administrators can predict which machines will need Internet access
   is quite simply wrong.  We need to reduce or eliminate the penalties
   associated with that error, in order to encourage as much Internet
   connectivity as operational policies and technical security permit.
   RFC 1597 works very much against this goal.

Problems With "Advantages" And More Disadvantages

   RFC 1597 claims that Classless Inter-Domain Routing (CIDR) will
   require enterprises to renumber their networks.  In the general case,
   this will only involve those networks that are routed outside of
   enterprises.  Since RFC 1597 addresses private enterprise networks,
   this argument does not apply.

   The authors mention that DCHP-based tools [2] might help network
   number transition.  However, it is observed that by and large such
   tools are currently only "potential" in nature.

   Additionally, with the onslaught of ISDN, slip, and PPP in host
   implementations, the potential for a workstation to become a router
   inadvertently has never been greater.  Use of a common set of
   addresses for private networks virtually assures administrators of
   having their networks partitioned, if they do not take care to
   carefully control modem connections.



Lear, Fair, Crocker & Kessler                                   [Page 5]

RFC 1627             Network 10 Considered Harmful             July 1994


   Finally, RFC 1597 implies that it may be simple to change a host's IP
   address.  For a variety of reasons this may not be the case, and it
   is not the norm today.  For example, a host may be well known within
   a network.  It may have long standing services such as NFS, which
   would cause problems for clients were its address changed.  A host
   may have software licenses locked by IP address.  Thus, migrating a
   host from private to global addressing may prove difficult.  At the
   very least, one should be careful about addressing well known hosts.

POLICY ISSUES

IANA Has Overstepped Their Mandate

   For many years, IANA has followed an assignment policy based on the
   expectation of Internet connectivity for ALL assignees.  As such it
   serves to encourage interconnectivity.  IANA assignment of the
   network numbers listed in RFC 1597 serves to formally authorize
   behavior contrary to this accepted practice.  Further, this change
   was effected without benefit of community review and approval.

   RFC 1597 specifies a new operational requirement explicitly: network
   service providers must filter the IANA assigned network numbers
   listed in RFC 1597 from their routing tables.  This address space
   allocation is permanently removed from being used on the Internet.

   As we read RFC 1601 [3], this action is not within the purview of
   IANA, which should only be assigning numbers within the current
   standards and axioms that underlie the Internet.  IP network numbers
   are assigned uniquely under the assumption that they will be used on
   the Internet at some future date.  Such assignments violate that
   axiom, and constitute an architectural change to the Internet.  RFC
   1602 [4] and RFC 1310 [5] also contain identical wording to this
   effect in the section that describes IANA.

   While RFC 1597 contains a view worthy of public debate, it is not
   ready for formal authorization.  Hence, we strongly encourage IANA to
   withdraw its IP address assignments documented by RFC 1597 forthwith.

   The IAB should review the address assignment policies and procedures
   that compose IANA's mandate, and reaffirm the commitment to a
   globally unique IP address space.

COMMENTS AND CONCLUSIONS

   The Internet technology and service is predicated on a global address
   space.  Members of the Internet community have already experienced
   and understood the problems and pains associated with uncoordinated
   private network number assignments.  In effect the proposal attempts



Lear, Fair, Crocker & Kessler                                   [Page 6]

RFC 1627             Network 10 Considered Harmful             July 1994


   to codify uncoordinated behavior and alter the accepted Internet
   addressing model.  Hence, it needs to be considered much more
   thoroughly.

   RFC 1597 gives the illusion of remedying a problem, by creating
   formal structure to a long-standing informal practice.  In fact, the
   structure distracts us from the need to solve these very real
   problems and does not even provide substantive aid in the near-term.

   In the past we have all dreaded the idea of having any part of the
   address space re-used.  Numerous luminaries have both written and
   spoke at length, explaining why it is we want direct connections from
   one host to another.  Before straying from the current architectural
   path, we as a community should revisit the reasoning behind the
   preaching of unique addressing.  While RFC 1597 attempts to change
   this model, its costs and limitations for enterprises can be
   enormous, both in the short and long term.

REFERENCES

   [1]  Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot,
        "Address Allocation for Private Internets", T.J. Watson Research
        Center, IBM Corp., Chrysler Corp., RIPE NCC, RFC 1597, March
        1994.

   [2]  Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
        Bucknell University, October 1993.

   [3]  Huitema, C., "Charter of the Internet Architecture Board (IAB)",
        RFC 1601, IAB, March 1994.

   [4]  Internet Architecture Board, Internet Engineering Steering
        Group, "The Internet Standards Process -- Revision 2", IAB,
        IESG, RFC 1602, March 1994.

   [5]  Internet Activities Board, "The Internet Standards Process", RFC
        1310, IAB, March 1992.

   [6]  Internet Activities Board, "Summary of Internet Architecture
        Discussion", Notes available from ISI, [ftp.isi.edu:
        pub/IAB/IABmins.jan91Arch.txt], IAB, January 1991.

SECURITY CONSIDERATIONS

   See the section, "Security Issues".






Lear, Fair, Crocker & Kessler                                   [Page 7]

RFC 1627             Network 10 Considered Harmful             July 1994


AUTHORS' ADDRESSES

   Eliot Lear
   Silicon Graphics, Inc.
   2011 N. Shoreline Blvd.
   Mountain View, CA
   94043-1389

   Phone: [phone]
   EMail: [e-mail]


   Erik Fair
   Apple Computer, Inc.
   1 Infinite Loop
   Cupertino, CA 95014

   Phone: [phone]
   EMail: [e-mail]


   Dave Crocker
   Silicon Graphics, Inc.
   2011 N. Shoreline Blvd.
   Mountain View, CA
   94043-1389

   Phone: [phone]
   EMail: [e-mail]


   Thomas Kessler
   Sun Microsystems Inc.
   Mail Stop MTV05-44
   2550 Garcia Ave.
   Mountain View, CA 94043

   Phone: [phone]
   EMail: [e-mail]












Lear, Fair, Crocker & Kessler                                   [Page 8]