This is a text version of the presentation made by Scott Bradner and Allison Mankin at the IETF meeting in Toronto on July 25 1994. Additional text put in brackets. IP Next Generation (IPng) IETF July 1994 Scott Bradner Allison Mankin History July 1993 ipdecide BOF & IESG plenary result in IETF taking on responsibility for IPng (not let the market decide) August 1993 temporary IETF area formed to consolidate IPng activity area directors from other areas on temporary assignment in addition to regular duties existing IPng working groups moved into area area given charge by the IETF chair Charge From the IETF Chair establish directorate keep process public understand the available timeframe recommend policy changes if warranted make a recommendation regarding the scope of IPng 'just' fix addresses or do more develop a clear and concise set of technical requirements develop a recommendation on which, if any, of the current proposals should be the next IP Directorate J. Allard - Microsoft Steve Bellovin - AT&T Jim Bound - Digital Ross Callon - Wellfleet Brian Carpenter - CERN Dave Clark - MIT John Curran - NEARNET Steve Deering - Xerox Dino Farinacci - Cisco Paul Francis - NTT Eric Fleischmann - Boeing Mark Knopper - Ameritech Greg Minshall - Novell Rob Ullmann - Lotus Lixia Zhang - Xerox [ Daniel Karrenberg was also on the directorate but his day job got full enough that he had to withdaw.] Open Public Process big-internet mailing list used (or abused) (big-internet-request@munnari.oz.au) internal directorate mailing list archive made public public reports at IETF & other conferences open directorate meetings archive site hsdndev.harvard.edu anonymous ftp & gopher as always, open working group meetings and mailing lists IPng Proposal Working Groups multiple working groups open meetings and mailing lists different approaches to solve addressing and routing problems different views on problems optimize different aspects of problems not right or wrong learned from all efforts CATNIP Common Architecture for Next-generation Internet Protocol chair: Vladimir Sukonnik developed from TP/IX working group The objective is to provide common ground between the Internet, OSI, and the Novell protocols, as well as to advance the Internet technology to the scale and performance of the next generation of internetwork technology. document authors: Michael McGovern, Robert Ullmann [All document authors listed in alphabetical order.] SIPP Simple Internet Protocol Plus chairs: Robert Hinden, Steve Deering, Paul Francis developed from merger of IPIP into IPAE which then merged with SIP then finally with PIP past WG chairs: D. Crocker, C. Huitema SIPP is a new version of IP which is designed to be an evolutionary step from IPv4. It is a natural increment to IPv4. 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. document authors: R. Atkinson, J. Bound, D. Crocker, S. Deering, P. Francis, P. Ford, R. E. Gilligan, R. Govindan, R. Hinden, C. Huitema, T. Li, E. Nordmark, Y. Rekhter, W. A. Simpson, S. Thomson TUBA TCP/UDP Over CLNP-Addressed Networks chairs: Mark Knopper, Peter Ford The TUBA effort will expand the ability to route Internet packets by using addresses which support more hierarchy than the current Internet Protocol (IP) address space. TUBA specifies the continued use of Internet transport protocols, in particular TCP and UDP, but specifies their encapsulation in ISO 8473 (CLNP) packets. TUBA seeks to upgrade the current system by a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the corresponding large Network Service Access Point address space. document authors: R. Callon, P. Ford, K. R. Glenn, D. Katz, M. Knopper, D. Marlow, D. Piscitello, Y. Rekhter, J. West (and a fleet of ISO docs) Available Timeframe Address Lifetime Expectations (ALE) working group Frank Solensky, FTP Software Tony Li, Cisco Systems made prediction at Seattle IETF meeting 2005 - 2011 ( new projection shorter ~2000) assumes no paradigm shifts mixed view of confidence level routing tables are still going to be a problem ADs endorse current address assignment policies ADs do not currently recommend address reclamation efforts may be warranted only if very large address request(s) received and sub-Class A nets can be assigned Scope of IPng development, testing & deployment will take time still we seem to have adequate time in IPv4 address space but not excessive (excluding paradigm shifts) can do more than 'just' fix addresses use requirements process to determine actual scope IPng Technical Requirements IPng requirements process (ngreq) Frank Kastenholz, FTP Software Jon Crowcroft, UCL used big-internet mailing list RFC1550 white papers BOF in Seattle requirements document based on Kastenholz/Partridge draft (draft-kastenholz-ipng-criteria-02.txt) criteria, discussion & time frame Informational RFC very soon White Papers draft-adamson-ipng-radio-req-00.txt draft-bellovin-ipng-addr-per-host-00.txt draft-bellovin-ipng-sec-concerns-00.txt draft-bound-ipng-bsdhost-implement-00.txt draft-brazdziunas-ipng-atm-00.txt draft-britton-ipng-req-corp-netwrk-00.txt draft-brownlee-ipng-acct-req-00.txt draft-carpenter-ipng-whitepaper-00.txt draft-chiappa-ipng-nimrod-arch-00.txt draft-clark-ipng-multipro-interop-00.txt draft-curran-ipng-viability-00.txt draft-estrin-ipng-unified-routing-00.txt draft-fleischman-ipng-corp-view-00.txt draft-ghiselli-ipng-whitepaper-req-00.txt draft-green-ipng-navy-hpn-00.txt draft-heagerty-ipng-input-00.txt draft-simpson-ipng-mobility-00.txt draft-skelton-ipng-epri-00.txt draft-symington-ipng-model-00.txt draft-taylor-ipng-cdpd-viewpt-00.txt draft-vecchi-ipng-tvcable-viewpt-00.txt to become Informational RFCs Proposal Whitepapers catnip draft-mcgovern-ipng-catnip-wpaper-00.txt sipp draft-ietf-sipp-whitepaper-00.txt tuba draft-ford-ipng-tuba-whitepaper-00.txt to become Informational RFCs IPng Criteria at least 10**9 networks, 10**12 end-systems safer goal 10**12 nets, 10**15 end-systems conservative routing schemes topologically flexible high performance straightforward transition plan from IPv4 robust service media independent datagram service autoconfiguration secure operation globally unique names access to standards support multicasting extensible support service classes support mobility include control protocol (ping etc.) support for private networks (tunneling) Nostradamus mode predicting the future is hard from "A Proposal for a Next Generation Internet Protocol" Ross Callon - December, 1987 Internet doubling every year (720 assigned nets in '87) requirements as seen for 1997 change should last for at least 10-15 years very high speed nets (microsecond forwarding time) plan for at least 100,000 nets, 10,000 ASs administrative diversity - addressing complexity effective general congestion control efficient source routing [ Ross came close for 1997 but he was projecting for 10-15 years *after* 1997 ] Assumptions we see consensus on the following points: specific recommendation required now basic requirements agreed to it has to work proceed with single IPng effort Reviews of IPng Proposals directorate did continuous reviews of proposals during its teleconferences and on its mailing list aspects of proposals discussed on big-internet mailing list directorate asked to do formal reviews of the IPng proposals before the retreat on May 19 & 20 reviews received will be reformatted and released as informational rfcs following are summaries of these reviews Reviews of IPng Proposals [ Note that these are summaries of the reviews received and not specifically the opinion of the IPng ADs. Yes means that the consensus was that the proposal met the requirement. No means that the consensus was that the proposal did not meet the requirement. Mixed means that there was no consensus in the reviews. Unknown means that the issue was not addresses in enough detail in the proposal documentation to evaluate the requirement. The evaluations in the last column are those of the IPng area directors about the IPng proposal.] summarized against protocol requirements catnip sipp tuba IPng complete spec no yes mostly mostly simplicity no no no mostly scale yes yes yes yes topological flex yes yes yes yes performance mixed mixed mixed yes robust service mixed mixed yes yes transition mixed no mixed yes media indepdnt yes yes yes yes datagram yes yes yes yes config. ease unknown mixed mixed mostly security unknown mixed mixed yes unique names mixed mixed mixed mixed access to stds yes yes mixed yes multicast unknown yes mixed yes extensibility unknown mixed mixed yes service classes unknown yes yes yes mobility unknown mixed mixed mixed control proto unknown yes mixed yes tunneling unknown yes mixed yes CATNIP common feeling in the Directorate that catnip proposal is incomplete [ These quotes are selected from the reviews received and some do represent some of the more extreme statements but are also representative of the feelings expressed.] 'best vision but rather complex' 'limited scope, not a full proposal' 'lack of maturity, lack of widespread support' 'straightforward bidirectional translation' 'you may as well just be running the native protocol[s]' SIPP common view in and out of the Directorate that IPAE has severe operational flaws general approval of clean, simple SIPP header design extended addressing is too complex to explain easily 64 bit address assignment is inadequate 'I am very unhappy...with the support SIPP gives to autoconfiguration' 'SIPP source route reversal is a security problem' 'The IPAE proposal is a very large solution to an ill-specified problem' 'SIPP has left it to others to solve important problems, such as a scalable addressing structure' 'SIPP has not dealt with the issue of mobility' 'SIPP addresses are inadequately hierarchical' TUBA deeply divided views on whether IETF could fix CLNP the CLNP bugs are significant, e.g. source route bugs mixed views on value of using NSAP address space 'TUBA is good because of CLNP. If not CLNP, it is a new proposal' 'If TUBA becomes the IPng, then the IETF must own TUBA' 'Using CLNP error responses is a transition problem' 'Variable length addresses increase the cost of development and worsen performance on the host' 'TUBA dual stack only transition is problematic, both dual stack and translation are needed' 'CLNP multicast is complex' 'Addresses are not 8-byte aligned' Result of Reviews significant flaws seen in all proposals revised proposal components offered since retreat answer most of the perceived problems routing and addressing transition autoconfiguration some still unresolved issues source routing support mobility synthesis of multiple efforts basis of IPng recommendation Kudos huge amount of work has gone into the IPng effort over the last few years multiple working groups, mailing list participants (thanks kre) IPng directorate, white paper authors, IESG, IAB ... (cast of thousands) remarkable degree of cooperation between efforts the IETF way! Recommendations form new IPng working group all base documents to be ready for proposed standard consideration by December 1994 minimal required IPng functionality must include address autoconfiguration & support for authentication IPng description expanded from IPv4 addressing capability simple header support for extension headers and options support for authentication and privacy support for autoconfiguration support for source routes simple and flexible transition from IPv4 flow ID Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension Headers [ examples ] +---------------+------------------------ | IPng header | TCP header + data | | | Next Header = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | IPng header | Routing header | TCP header + data | | | | Next Header = | Next Header = | | Routing | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPng header | Routing header | Fragment header | fragment of TCP | | | | header + data | Next Header = | Next Header = | Next Header = | | Routing | Fragment | TCP | +---------------+----------------+-----------------+----------------- Extension Header Types Hop-by-Hop Options End-to-End Options Routing Fragment Authentication Privacy IPng Working Group, charter outline chairs: Ross Callon, Steve Deering document editor: Bob Hinden Goal is to resolve any remaining issues (source route, payload size, etc),complete unfinished work (security, ICMP, IGMP, DNS, etc),develop/finalize addressing/routing plans and move IPng to proposed standard. Cooperate with work in other areas impacted by IPng, routing for example. IPng BOF meeting in Toronto short-term milestones for the proposed standards for IPng revise existing IDs to produce IPng base documents in August IDs submitted as proposed standards in December IPng Working Group, starting documents [ partial list ] S. Deering - Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver) P. Francis et al - SIPP Addressing Architecture Y. Rekhter - An Archecture for SIPP-16 Address Allocation R. Gilligan - Simple SIPP Transition (SST) Overview R. Atkinson - SIPP Security Architecture R. Atkinson - SIPP Authentication Header P. Ford et al - SDRP Routing Header for SIPP-16 Existing IPng Proposal Working Groups at start of process we said that the existing working groups would not be required to shutdown when the IPng recommendation was made after this week current IPng proposal working groups will be returned to the Internet area they can continue to work, but the work will not be on IPng or be expected to have influence on IPng must revise charter if they wish to continue IPng Area IPng area will conclude after documents enter standards track working groups will then move to logical IETF areas directorate maintained while area active IPng Addresses 16 byte fixed length Internet address address formats determined by IPng working group assignment coordinated by the IANA IPng Addresses, contd. propose mapping algorithms from and to other environments where addresses are globally unique and assigned with regard to network topology IETF should work with other organizations for development of such mappings permits unified management of address space among multiple protocol families common addresses facilitate transition to IPng goal to provide a 1:1 mapping between address types IPX, NSAP, E164 Autoconfiguration address autoconfiguration a required feature of IPng an IPng autoconfiguration working group to be formed short lived working group focus on documents for server-less & server-full modes of autoconfiguration coordinate with other IETF activities affected by autoconfiguration such as DNS (for autoregistration) and CAT (for authentication) starting document from Sue Thomson & Dave Katz Transition two IPng transition efforts short term refine IPng-specific documents for proposed standard long term transition, coexistence & testing work together Transition, Short Term - ngtrans chairs: TBA short lived working group focus on IPv4 to IPng transition and coexistence work with TACIT WG finalize IPng transition overview develop documents relating directly to the IPv4 to IPng transition define each transition function in detail guidance for network designers guidance for operators Sep. 1994 documents published as Internet Drafts Dec. 1994 documents submitted as proposed standards Transition, long term Transition and Coexistence Including Testing (tacit) WG Atul Bansal, Digital Geoff Huston, AARNet facets of issue transition from the currently deployed protocol to a new protocol heterogeneity and decentralization will need to be accommodated long period of coexistence between a new protocol and the existing protocol the Internet must now be considered a utility rigorous architectural and interoperability testing needed as part of predeployment phase not just IPv4 to IPng TACIT WG, contd. goals learn from other transition and deployment efforts detail problem areas in transition and coexistence facilitate transition plans from other network technologies e.g. IPX, CLNP recommendation of specific testing procedures recommendation of coexistence operations procedures with IPv4 recommendations for the smoothing of decentralized transition planning Nov. 1994 documents published as Internet Drafts Dec. 1994 documents submitted to standards track IPng Reviewer appoint an IPng reviewer to be specifically responsible for ensuring that a consistent view of IPng is maintained across the related working groups needed since IPng related work will be going on in a number of IETF areas job description time scale - long term offering the broadest perspective, question connect all the points spotting gaps but not making architectural decisions that is the work of the working groups and the IETF Dave Clark Security there is a recognition that the Internet needs strong security IPng and other protocols are evolving toward incorporation of capabilities for authentication, integrity and confidentiality the goal is to provide strong protection as a matter of course throughout the Internet It is likely that the different communities on the Internet will need different suites of algorithms one common mandatory set of algorithms, others optional the use of multiple suites of algorithms will pose some interoperability issues; they will be dealt with over time. Security, contd. separate use of encryption from use of authentication support of authentication header is required in IPng support of encrypted payload is encouraged use and export restrictions can limit ability to support function a key management infrastructure is required but outside of IPng effort inclusion of cryptography for authentication and/or privacy may add to the cost and impact the performance of an implementation, but it is worth the cost IETF work underway to embed signed keys in DNS each IPng node should have a key need framework for firewalls under IPng EIDs there has been much discussion with little resolution EIDs appear to be too much a research topic at this time ADs sanctioned EID BOF in Toronto any follow-on WG likely will not be in IPng area transport possible Other Needed Work changing the size of the internetwork layer address and other IPng changes affects many IETF standards new working groups must be formed in many IETF areas to examine and resolve changes required, some work can be done by IPng WG TCP, UDP, ICMP ... FTP, SNMP, DNS, BOOTP, DHCP ... IDRP, ISIS, OSPF, RIPv2 ... host & router requirements APIs - may or may not be IETF issue but needs to be addressed (Informational RFC?) Time Line July 1994 - IPng announcement August 1994 - 1st test implementations September 1994 - documents as Internet-Drafts December 1994 - documents submitted as proposed standards July 1995 - 1st beta versions of release software December 1995 - initial scaling tests complete December 1995 - 1st production software releases Time Line, Recommendation July 1994 - IPng recommendation August 1994 - recommendation released as Internet Draft August 1994 - IETF chair issues 'last call' on recommendation September 1994 - IESG approves recommendation IPng Schedule This Week Mon 1330 Open Directorate Meeting 1600 Endpoint EID BOF Transition, Coexistence & Testing Tue 0930 IPng BOF 1330 TCP/UDP over CLNP-Addressed nets Wed 0930 TCP/UDP over CLNP-Addressed nets 1330 Common Architecture for Next-Generation IP 1600 Simple Internet Protocol Plus 1930 Address Lifetime Expectations Thu 0930 Simple Internet Protocol Plus 1330 Transition, Coexistence & Testing In Closing In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. Antoine de Saint-Exupery Everything should be made as simple as possible, but not simpler. A. Einstein [ IETF work is trying to find the right understanding of the balance between these two goals. We think we have done that in IPng. ]