Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Technical Criteria for Choosing IP The Next Generation (IPng) (RFC1726)

IP.com Disclosure Number: IPCOM000003974D
Original Publication Date: 1994-Dec-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 26 page(s) / 69K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Partridge: AUTHOR [+2]

Abstract

This document was submitted to the IPng Area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 4% of the total text.

Network Working Group C. Partridge

Request for Comments: 1726 BBN Systems and Technologies

Category: Informational F. Kastenholz

FTP Software

December 1994

Technical Criteria for Choosing

IP The Next Generation (IPng)

Status of this Memo

This memo provides information for the Internet community. This memo

does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

Abstract

This document was submitted to the IPng Area in response to RFC 1550.

Publication of this document does not imply acceptance by the IPng

Area of any ideas expressed within. Comments should be submitted to

the big-internet@munnari.oz.au mailing list. This RFC specifies

criteria related to mobility for consideration in design and

selection of the Next Generation of IP.

Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2

2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Note on Terminology . . . . . . . . . . . . . . . . . . . 4

4. General Principles. . . . . . . . . . . . . . . . . . . . 4

4.1 Architectural Simplicity. . . . . . . . . . . . . . . . . 4

4.2 One Protocol to Bind Them All . . . . . . . . . . . . . . 4

4.3 Live Long . . . . . . . . . . . . . . . . . . . . . . . . 5

4.4 Live Long AND Prosper . . . . . . . . . . . . . . . . . . 5

4.5 Co-operative Anarchy. . . . . . . . . . . . . . . . . . . 5

5. Criteria. . . . . . . . . . . . . . . . . . . . . . . . . 6

5.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.2 Topological Flexibility . . . . . . . . . . . . . . . . . 8

5.3 Performance . . . . . . . . . . . . . . . . . . . . . . . 9

5.4 Robust Service. . . . . . . . . . . . . . . . . . . . . . 10

5.5 Transition. . . . . . . . . . . . . . . . . . . . . . . . 12

5.6 Media Independence. . . . . . . . . . . . . . . . . . . . 13

5.7 Unreliable Datagram Service . . . . . . . . . . . . . . . 15

5.8 Configuration, Administration, and Operation. . . . . . . 16

5.9 Secure Operation. . . . . . . . . . . . . . . . . . . . . 17

5.10 Unique Naming . . . . . . . . . . . . . . . . . . . . . . 18

5.11 Access. . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.12 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20

5.13 Extensibility . . . ...