rfc1671.txt

中、英文RFC文档大全打包下载完全版 .


RFC 1671          IPng White Paper on Transition, etc.       August 1994


   but just that they behave as if they did.  It is compatible with
   encapsulation (i.e., one of the two stacks encapsulates packets for
   the other).

   Obviously, management of dual stack hosts will be simplified by the
   address mapping just mentioned. Only the site prefix has to be
   configured (manually or dynamically) in addition to the IPv4 address.

   In a dual stack host the IPng API and the IPv4 API will be logically
   distinguishable even if they are implemented as a single entity.
   Applications will know from the API whether they are using IPng or
   IPv4.

   F) DNS.

   The dual stack requirement implies that DNS has to reply with both an
   IPv4 and IPng address for IPng hosts, or with a single reply that
   encodes both.

   If a host is attributed an IPng address in DNS, but is not actually
   running IPng yet, it will appear as a black hole in IPng space - see
   the next point.

   G) Smart dual-stack code.

   The dual-stack code may get two addresses back from DNS; which does
   it use?  During the many years of transition the Internet will
   contain black holes. For example, somewhere on the way from IPng host
   A to IPng host B there will sometimes (unpredictably) be IPv4-only
   routers which discard IPng packets.  Also, the state of the DNS does
   not necessarily correspond to reality. A host for which DNS claims to
   know an IPng address may in fact not be running IPng at a particular
   moment; thus an IPng packet to that host will be discarded on
   delivery.  Knowing that a host has both IPv4 and IPng addresses gives
   no information about black holes. A solution to this must be proposed
   and it must not depend on manually maintained information.  (If this
   is not solved, the dual stack approach is no better than the packet
   translation approach.)

   H) Smart management tools.

   A whole set of management tools is going to be needed during the
   transition. Why is my IPng route different from my IPv4 route?  If
   there is translation, where does it happen?  Where are the black
   holes? (Cosmologists would like the same tool :-) Is that host REALLY
   IPng-capable today?...





Carpenter                                                       [Page 5]

RFC 1671          IPng White Paper on Transition, etc.       August 1994


Multicasts high and low

   It is taken for granted that multicast applications must be supported
   by IPng. One obvious architectural rule is that no multicast packet
   should ever travel twice over the same wire, whether it is a LAN or
   WAN wire. Failure to observe this would mean that the maximum number
   of simultaneous multicast transactions would be halved.

   A negative feature of IPv4 on LANs is the cavalier use of physical
   broadcast packets by protcols such as ARP (and various non-IETF
   copycats).  On large LANs this leads to a number of undesirable
   consequences (often caused by poor products or poor users, not by the
   protcol design itself).  The obvious architectural rule is that
   physical broadcast should be replaced by unicast (or at worst,
   multicast) whenever possible.

ATM

   The networking industry is investing heavily in ATM. No IPng proposal
   will be plausible (in the sense of gaining management approval)
   unless it is "ATM compatible", i.e., there is a clear model of how it
   will run over an ATM network. Although a fully detailed document such
   as RFC 1577 is not needed immediately, it must be shown that the
   basic model works.

   Similar remarks could be made about X.25, Frame Relay, SMDS etc. but
   ATM is the case with the highest management hype ratio today.

Policy routing and accounting

   Unfortunately, this cannot be ignored, however much one would like
   to.  Funding agencies want traffic to flow over the lines funded to
   carry it, and they want to know afterwards how much traffic there
   was.  Accounting information can also be used for network planning
   and for back-charging.

   It is therefore necessary that IPng and its routing procedures allow
   traffic to be routed in a way that depends on its source and
   destination in detail. (As an example, traffic from the Physics
   department of MIT might be required to travel a different route to
   CERN than traffic from any other department.)

   A simple approach to this requirement is to insist that IPng must
   support provider-based addressing and routing.

   Accounting of traffic is required at the same level of detail (or
   more, for example how much of the traffic is ftp and how much is
   www?).



Carpenter                                                       [Page 6]

RFC 1671          IPng White Paper on Transition, etc.       August 1994


   Both of these requirements will cost time or money and may impact
   more than just the IP layer, but IPng should not duck them.

Security Considerations

   Corporate network operators, and campus network operators who have
   been hacked a few times, take this more seriously than many protocol
   experts.  Indeed many corporate network operators would see improved
   security as a more compelling argument for transition to IPng than
   anything else.

   Since IPng will presumably be a datagram protocol, limiting what can
   be done in terms of end-to-end security, IPng must allow more
   effective firewalls in routers than IPv4.  In particular efficient
   traffic barring based on source and destination addresses and types
   of transaction is needed.

   It seems likely that the same features needed to allow policy routing
   and detailed accounting would be needed for improved firewall
   security.  It is outside the scope of this document to discuss these
   features in detail, but it seems unlikely that they are limited to
   implementation details in the border routers.  Packets will have to
   carry some authenticated trace of the (source, destination,
   transaction) triplet in order to check for unwanted traffic, to allow
   policy-based source routing, and/or to allow detailed accounting.
   Presumably any IPng will carry source and destination identifiers in
   some format in every packet, but identifying the type of transaction,
   or even the individual transaction, is an extra requirement.

Disclaimer and Acknowledgements

   This is a personal view and does not necessarily represent that of my
   employer.

   CERN has been through three network transitions in recent years (IPv4
   renumbering managed by John Gamble, AppleTalk Phase I to Phase II
   transition managed by Mike Gerard, and DECnet Phase IV to DECnet/OSI
   routing transition managed by Denise Heagerty).  I could not have
   written this document without having learnt from them. I have also
   benefitted greatly from discussions with or the writings of many
   people, especially various members of the IPng Directorate. Several
   Directorate members gave comments that helped clarify this paper, as
   did Bruce L Hutfless of Boeing.  However the opinions are mine and
   are not shared by all Directorate members.







Carpenter                                                       [Page 7]

RFC 1671          IPng White Paper on Transition, etc.       August 1994


Author's Address

   Brian E. Carpenter
   Group Leader, Communications Systems
   Computing and Networks Division
   CERN
   European Laboratory for Particle Physics
   1211 Geneva 23, Switzerland

   Phone:  [phone]
   Fax:    [phone]
   Telex:  419000 cer ch
   EMail: [e-mail]






































Carpenter                                                       [Page 8]