rfc1710.txt

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

5. SIPP Transition Mechanisms

   The two key motivations in the SIPP transition mechanisms are to
   provide direct interoperability between IPv4 and SIPP hosts and to
   allow the user population to adopt SIPP in an a highly diffuse
   fashion.  The transition must be incremental, with few or no critical
   interdependencies, if it is to succeed.  The SIPP transition allows
   the users to upgrade their hosts to SIPP, and the network operators
   to deploy SIPP in routers, with very little coordination between the
   two.

   The mechanisms and policies of the SIPP transition are called "IPAE".
   Having a separate term serves to highlight those features designed
   specifically for transition.  Once an acronym for an encapsulation
   technique to facilitate transition, the term "IPAE" now is mostly
   historical.

   The IPAE transition is based on five key elements:

    1) A 64-bit SIPP addressing plan that encompasses the existing
       32-bit IPv4 addressing plan.  The 64-bit plan will be used to
       assign addresses for both SIPP and IPv4 nodes at the beginning
       of the transition.  Existing IPv4 nodes will not need to change
       their addresses, and IPv4 hosts being upgraded to SIPP keep their
       existing IPv4 addresses as the low-order 32 bits of their SIPP
       addresses.  Since the SIPP addressing plan is a superset of the
       existing IPv4 plan, SIPP hosts are assigned only a single 64-bit
       address, which can be used to communicate with both SIPP and IPv4
       hosts.

    2) A mechanism for encapsulating SIPP traffic within IPv4 packets so
       that the IPv4 infrastructure can be leveraged early in the
       transition.  Most of the "SIPP within IPv4 tunnels" can be
       automatically configured.






Hinden                                                         [Page 18]

RFC 1710                 SIPP IPng White Paper              October 1994


    3) Algorithms in SIPP hosts that allow them to directly interoperate
       with IPv4 hosts located on the same subnet and elsewhere in the
       Internet.

    4) A mechanism for translating between IPv4 and SIPP headers to
       allow SIPP-only hosts to communicate with IPv4-only hosts and to
       facilitate IPv4 hosts communicating over over a SIPP-only
       backbone.

    5) An optional mechanism for mapping IPv4 addresses to SIPP address
       to allow improved scaling of IPv4 routing.  At the present time
       given the success of CIDR, this does not look like it will be
       needed in a transition to SIPP.  If Internet growth should
       continue beyond what CIDR can handle, it is available as an
       optional mechanism.

   IPAE ensures that SIPP hosts can interoperate with IPv4 hosts
   anywhere in the Internet up until the time when IPv4 addresses run
   out, and afterward allows SIPP and IPv4 hosts within a limited scope
   to interoperate indefinitely.  This feature protects for a very long
   time the huge investment users have made in IPv4.  Hosts that need
   only a limited connectivity range (e.g., printers) need never be
   upgraded to SIPP.  This feature also allows SIPP-only hosts to
   interoperate with IPv4-only hosts.

   The incremental upgrade features of IPAE allow the host and router
   vendors to integrate SIPP into their product lines at their own pace,
   and allows the end users and network operators to deploy SIPP on
   their own schedules.

   The interoperability between SIPP and IPv4 provided by IPAE also has
   the benefit of extending the lifetime of IPv4 hosts.  Given the large
   installed base of IPv4, changes to IPv4 in hosts are nearly
   impossible.  Once an IPng is chosen, most of the new feature
   development will be done on IPng.  New features in IPng will increase
   the incentives to adopt and deploy it.

6. Why SIPP?

   There are a number of reasons why SIPP should be selected as the
   IETF's IPng.  It solves the Internet scaling problem, provides a
   flexible transition mechanism for the current Internet, and was
   designed to meet the needs of new markets such as nomadic personal
   computing devices, networked entertainment, and device control.  It
   does this in a evolutionary way which reduces the risk of
   architectural problems.





Hinden                                                         [Page 19]

RFC 1710                 SIPP IPng White Paper              October 1994


   Ease of transition is a key point in the design of SIPP.  It is not
   something was was added in at the end.  SIPP is designed to
   interoperate with IPv4.  Specific mechanisms (C-bit, embedded IPv4
   addresses, etc.) were built into SIPP to support transition and
   compatability with IPv4.  It was designed to permit a gradual and
   piecemeal deployment without any dependencies.

   SIPP supports large hierarchical addresses which will allow the
   Internet to continue to grow and provide new routing capabilities not
   built into IPv4.  It has cluster addresses which can be used for
   policy route selection and has scoped multicast addresses which
   provide improved scaleability over IPv4 multicast.  It also has local
   use addresses which provide the ability for "plug and play"
   installation.

   SIPP is designed to have performance better than IPv4 and work well
   in low bandwidth applications like wireless.  Its headers are less
   expensive to process than IPv4 and its 64-bit addresses are chosen to
   be well matched to the new generation of 64bit processors.  Its
   compact header minimizes bandwidth overhead which makes it ideal for
   wireless use.

   SIPP provides a platform for new Internet functionality.  This
   includes support for real-time flows, provider selection, host
   mobility, end-to- end security, auto-configuration, and auto-
   reconfiguration.

   In summary, SIPP is a new version of IP.  It can be installed as a
   normal software upgrade in internet devices.  It is interoperable
   with the current IPv4.  Its deployment strategy was designed to not
   have any "flag" days.  SIPP is designed to run well on high
   performance networks (e.g., ATM) and at the same time is still
   efficient for low bandwidth networks (e.g., wireless).  In addition,
   it provides a platform for new internet functionality that will be
   required in the near future.
















Hinden                                                         [Page 20]

RFC 1710                 SIPP IPng White Paper              October 1994


7. Status of SIPP Effort

   There are many active participants in the SIPP working group.  Groups
   making active contributions include:

   Group                   Activity
   ---------------------   ----------------------------------------
   Beame & Whiteside       Implementation (PC)
   Bellcore                Implementation (SunOS), DNS and ICMP specs.
   Digital Equipment Corp. Implementation (Alpha/OSF, Open VMS)
   INRIA                   Implementation (BSD, BIND), DNS & OSPF specs.
   INESC                   Implementation (BSD/Mach/x-kernel)
   Intercon                Implementation (MAC)
   MCI                     Phone Conferences
   Merit                   IDRP for SIPP Specification
   Naval Research Lab.     Implementation (BSD) Security Design
   Network General         Implementation (Sniffer)
   SGI                     Implementation (IRIX, NetVisulizer)
   Sun                     Implementation (Solaris 2.x, Snoop)
   TGV                     Implementation (Open VMS)
   Xerox PARC              Protocol Design
   Bill Simpson            Implementation (KA9Q)

   As of the time this paper was written there were a number of SIPP and
   IPAE implementations.  These include:

   Implementation          Status
   --------------          ------------------------------------
   BSD/Mach                Completed (telnet, NFS, AFS, UDP)
   BSD/Net/2               In Progress
   Bind                    Code done
   DOS &Windows            Completed (telnet, ftp, tftp, ping)
   IRIX                    In progress (ping)
   KA9Q                    In progress (ping, TCP)
   Mac OS                  Completed (telnet, ftp, finger, ping)
   NetVisualizer           Completed (SIP & IPAE)
   Open VMS                Completed (telnet, ftp), In Progress
   OSF/1                   In Progress (ping, ICMP)
   Sniffer                 Completed (SIP & IPAE)
   Snoop                   Completed (SIP & IPAE)
   Solaris                 Completed (telnet, ftp, tftp, ping)
   Sun OS                  In Progress









Hinden                                                         [Page 21]

RFC 1710                 SIPP IPng White Paper              October 1994


8. Where to Get Additional Information

   The documentation listed in the reference sections can be found in
   one of the IETF internet draft directories or in the archive site for
   the SIPP working group.  This is located at:

           ftp.parc.xerox.com      in the /pub/sipp        directory.

   In addition other material relating to SIPP (such as postscript
   versions of presentations on SIPP) can also be found in the SIPP
   working group archive.

   To join the SIPP working group, send electronic mail to

           [e-mail]

   An archive of mail sent to this mailing list can be found in the IETF
   directories at cnri.reston.va.us.

9. Security Considerations

   Security issues are discussed in section 4.6.

10. Author's Address

   Robert M. Hinden
   Manager, Internet Engineering
   Sun Microsystems, Inc.
   MS MTV5-44
   2550 Garcia Ave.
   Mt. View, CA 94303

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

11. References

   [ADDR]  Francis, P., "Simple Internet Protocol Plus (SIPP): Unicast
           Hierarchical Address Assignment", Work in Progress, January
           1994.

   [AUTH]  Atkinson, R., "SIPP Authentication Payload",
           Work in Progress, January, 1994.

   [CIDR]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:
           an Address Assignment and Aggregation Strategy", RFC 1338,
           BARRNet, cisco, Merit, OARnet, June 1992.



Hinden                                                         [Page 22]

RFC 1710                 SIPP IPng White Paper              October 1994


   [DISC]  Simpson, W., "SIPP Neighbor Discovery", Work in Progress,
           March 1994.

   [DIS2]  Simpson, W., "SIPP Neighbor Discovery -- ICMP Message
           Formats", Work in Progress, March 1994.

   [DHCP]  Thomson, S., "Simple Internet Protocol Plus (SIPP): Automatic
           Host Address Assignment", Work in Progress, March 1994.

   [DNS]   Thomson, S., and C. Huitema, "DNS Extensions to Support
           Simple Internet Protocol Plus (SIPP)", Work in Progress,
           March 1994.

   [ICMP]  Govindan, R., and S. Deering, "ICMP and IGMP for the Simple
           Internet Protocol Plus (SIPP)", Work in Progress, March 1994.

   [IDRP]  Hares, S., "IDRP for SIP", Work in Progress, November 1993.

   [IPAE]  Gilligan, R., et al, "IPAE: The SIPP Interoperability and
           Transition Mechanism", Work in Progress, March 1994.

   [IPV4]  Postel, J., "Internet Protocol- DARPA Internet Program
           Protocol Specification", STD 5, RFC 791, DARPA,
           September 1981.

   [OSPF]  Francis, P., "OSPF for SIPP", Work in Progress, February
           1994.

   [RIP2]  Malkin, G., and C. Huitema, "SIP-RIP", Work in Progress,
           March 1993.

   [ROUT]  Deering, S., et al, "Simple Internet Protocol Plus (SIPP):
           Routing and Addressing", Work in Progress, February 1994.

   [SARC]  Atkinson, R., "SIPP Security Architecture", Work in Progress,
           January 1994.

   [SECR]  Atkinson, R., "SIPP Encapsulating Security Payload (ESP)",
           Work in Progress, January 1994.

   [SIPP]  Deering, S., "Simple Internet Protocol Plus (SIPP)
           Specification", Work in Progress, February 1994.









Hinden                                                         [Page 23]