archive-gr.com » GR » T » TEIPIR.GR

Total: 878

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

  • Ralph Unknown Host Numbers RFC 305 NIC 9078 BBN 23 February 1972 306 Westheimer Ellen Network Host Status RFC 306 NIC 9257 BBN 15 February 1972 307 Harslem Eric Using Network Remote Job Entry RFC 307 NIC 9258 Rand 24 February 1972 308 Seriff Marc ARPANET Host Availability Data RFC 308 NIC 9259 MIT Project MAC 13 March 1972 Reynolds Postel Page 20 RFC 1012 Bibliography of RFCs 1 999 June 1987 309 Bhushan Abhay Data And File Transfer Workshop Announcement RFC 309 NIC 9260 MIT Project MAC 17 March 1972 310 Bhushan Abhay Another Look at Data and File Transfer Protocols RFC 310 NIC 9261 MIT Project MAC 3 April 1972 311 Bryan Roland F New Console Attachments to the UCSB Host RFC 311 NIC 9341 UCSB 29 February 1972 312 McKenzie Alex Proposed Change in IMP to Host Protocol RFC 312 NIC 9342 BBN 22 March 1972 313 O Sullivan Tom Computer Based Instruction RFC 313 NIC 9343 Raytheon 6 March 1972 314 Cotton Ira Next Network Graphics Working Group Meeting RFC 314 NIC 9344 MITRE 14 March 1972 315 Westheimer Ellen Network Host Status RFC 315 NIC 9345 BBN 8 March 1972 316 McKay Doug and Alvin Mullery ARPA Network Data Management Working Group RFC 316 NIC 9346 IBM 23 24 February 1972 317 Postel Jon Official Host Host Protocol Modification Assigned Link Numbers RFC 317 NIC 9347 UCLA NMC 20 March 1972 318 Postel Jon Ad Hoc Telnet Protocols RFC 318 NIC 9348 References RFCs 139 158 UCLA NMC 3 April 1972 319 Westheimer Ellen Network Host Status RFC 319 NIC 9349 BBN 21 March 1972 320 Reddy Raj Workshop on Hard Copy Line Graphics RFC 320 NIC 9350 CMU 27 March 1972 321 Karp Peggy CBI Networking Activity at MITRE RFC 321 NIC 9608 MITRE 24 March 1972 322 Cerf Vint and Jon Postel Well Known Socket Numbers RFC 322 NIC 9609 UCLA NMC 26 March 1972 323 Cerf Vint Formation of Network Measurement Group NMG RFC 323 NIC 9630 UCLA NMC 23 March 1972 324 Postel Jon RJE Protocol Meeting RFC 324 NIC 9631 UCLA 3 April 1972 Reynolds Postel Page 21 RFC 1012 Bibliography of RFCs 1 999 June 1987 325 Hicks Greg Network Remote Job Entry Program NETRJS RFC 325 NIC 9632 Utah 6 April 1972 326 Westheimer Ellen Network Host Status RFC 326 NIC 9633 BBN 3 April 1972 327 Bhushan Abhay Data and File Transfer Workshop Notes RFC 327 NIC 9261 MIT Project MAC 27 April 1972 328 Postel Jon Suggested Telnet Protocol Changes RFC 328 NIC 9635 UCLA NMC 29 April 1972 329 Network Information Center ARPA Network Mailing Lists RFC 329 NIC 9636 NIC 17 May 1972 330 Westheimer Ellen Network Host Status RFC 330 NIC 9923 BBN 13 April 1972 331 McQuillan John IMP System Change Notification RFC 331 NIC 9924 BBN 19 April 1972 332 Westheimer Ellen Network Host Status RFC 332 NIC 9923 BBN 25 April 1972 333 Bressler Bob Dan Murphy and Dave Walden A Proposed Experiment with a Message Switching Protocol RFC 333 NIC 9926 MIT and BBN 15 May 1972 334 McKenzie Alex Network Use on May 8th RFC 334 NIC 9927 BBN 1 May 1972 335 Bryan Roland F New Interface IMP 360 RFC 335 NIC 9928 UCSB 1 May 1972 336 Cotton Ira Level 0 Graphic Input Protocol RFC 336 NIC 9929 MITRE 5 May 1972 337 Never Issued 338 Braden Bob EBCDIC ASCII Mapping for Network RJE RFC 338 NIC 9931 UCLA CCN 17 May 1972 339 Thomas Bob MLTNET A Multi Telnet Subsystem for TENEX RFC 339 NIC 9932 BBN 5 May 1972 340 O Sullivan Tom Proposed Telnet Changes RFC 340 NIC 9933 Raytheon 15 May 1972 341 Never Issued Reynolds Postel Page 22 RFC 1012 Bibliography of RFCs 1 999 June 1987 342 Westheimer Ellen Network Host Status RFC 342 NIC 10421 BBN 15 May 1972 343 McKenzie Alex IMP System Change Notification RFC 343 NIC 10422 BBN 19 May 1972 344 Westheimer Ellen Network Host Status RFC 344 NIC 10423 BBN 22 May 1972 345 Kelly Karl Interest in Mixed Integer Programming MPSX on 360 91 at CCN RFC 345 NIC 10424 Illinois 26 May 1972 346 Postel Jon Satellite Considerations RFC 346 NIC 10425 UCLA NMC 30 May 1972 347 Postel Jon Echo Process RFC 347 NIC 10426 UCLA NMC 30 May 1972 348 Postel Jon Discard Process RFC 348 NIC 10427 UCLA NMC 30 May 1972 349 Postel Jon Proposed Standard Socket Numbers RFC 349 NIC 10428 UCLA NMC 30 May 1972 350 Stoughton Ron User Accounts for UCSB On line System RFC 350 NIC 10549 UCSB 18 May 1972 351 Crocker Dave Graphics Information form for the ARPANET Graphics Resources Notebook RFC 351 NIC 10593 UCLA NMC 5 June 1972 352 Crocker Dave TIP Site Information Form RFC 352 NIC 10594 UCLA NMC 5 June 1972 353 Westheimer Ellen Network Host Status RFC 353 NIC 10595 BBN 12 June 1972 354 Bhushan Abhay The File Transfer Protocol RFC 354 NIC 10596 MIT Project MAC 8 July 1972 355 Davidson John Response to RFC 346 RFC 355 NIC 10597 University of Hawaii 9 June 1972 356 Alter Ralph ARPA Network Control Center RFC 356 NIC 10598 BBN 21 June 1972 357 Davidson John An Echoing Strategy for Satellite Links RFC 357 NIC 10599 University of Hawaii 26 June 1972 Reynolds Postel Page 23 RFC 1012 Bibliography of RFCs 1 999 June 1987 358 Never Issued 359 Walden Dave The Status of the Release of the New IMP System 2600 RFC 358 NIC 10601 BBN 22 June 1972 360 Holland Chuck Proposed Remote Job Entry Protocol RFC 360 NIC 10602 UCSD 24 June 1972 361 Bressler Bob In Response to RFCs 347 and 348 RFC 361 NIC 10603 MIT DMCG 5 July 1972 362 Westheimer Ellen Network Host Status RFC 362 NIC 10604 BBN 28 June 1972 363 Network Information Center ARPA Network Mailing Lists NIC 8 August 1972 364 Abrams Marshall D Serving Remote Users on the ARPANET RFC 364 NIC 10606 NBS 11 July 1972 365 Walden Dave A Letter to All TIP Users RFC 365 NIC 10607 BBN 11 July 1972 366 Westheimer Ellen Network Host Status RFC 366 NIC 11013 BBN 11 July 1972 367 Westheimer Ellen Network Host Status RFC 367 NIC 11014 BBN 19 June 1972 368 Braden Bob Comments on Proposed Remote Job Entry Protocol RFC 368 NIC 11015 UCLA CCN 21 July 1972 369 Pickens John R Evaluation of ARPANET Services RFC 369 NIC 11016 UCSB 25 July 1972 370 Westheimer Ellen Network Host Status RFC 370 NIC 11017 BBN 31 July 1972 371 Kahn Robert Demonstration at International Computer Communications Conference RFC 371 NIC 11020 BBN 12 July 1972 372 McKenzie Alex Notes on a Conversation with Bob Kahn on the ICCC RFC 372 NIC 11022 BBN 12 July 1972 373 McCarthy John Arbitrary Character Sets RFC 373 NIC 11058 BBN 19 July 1972 Reynolds Postel Page 24 RFC 1012 Bibliography of RFCs 1 999 June 1987 374 McKenzie Alex IMP System Announcement RFC 374 NIC 11099 BBN 19 July 1972 375 Never Issued 376 Westheimer Ellen Network Host Status RFC 376 NIC 11118 BBN 8 August 1972 377 Braden Bob Using TSO via ARPA Network Virtual Terminal RFC 377 NIC 11119 UCLA CCN 10 August 1972 378 McKenzie Alex Traffic Statistics July 1972 RFC 378 NIC 11120 BBN 10 August 1972 379 Braden Bob Using TSO at CCN RFC 379 NIC 11121 UCLA CCN 11 August 1972 380 Never Issued 381 McQuillan John and Dave Walden Three Aids to Improved Network Operation RFC 381 NIC 11151 BBN 26 July 1972 382 McDaniel Lawrence Mathematical Software on the ARPA Network RFC 382 NIC 11122 University of Illinois 3 August 1972 383 Never Issued 384 North Jeanne B Official Site Idents for Organizations in the ARPA Network RFC 384 NIC 11356 NIC 28 August 1972 385 Bhushan Abhay Comments on the File Transfer Protocol RFC 354 RFC 385 NIC 11357 MIT Project MAC 18 August 1972 386 Cosell Bernie and Dave Walden Letter to TIP Users 2 RFC 386 NIC 11358 BBN 16 August 1972 387 Kelley Karl and Jaacov Meir Some Experiences in Implementing Network Graphics Protocol Level 0 RFC 387 NIC 11359 Illinois 10 August 1972 388 Cerf Vint NCP Statistics RFC 388 NIC 11360 UCLA NMC 23 August 1972 389 Noble Barbara UCLA Campus Computing Network Liaison Staff for ARPA Network RFC 389 NIC 11361 UCLA CCN 30 August 1972 Reynolds Postel Page 25 RFC 1012 Bibliography of RFCs 1 999 June 1987 390 Braden Bob TSO Scenario Batch Compilation and Foreground Execution RFC 390 NIC 11582 UCLA CCN 12 September 1972 391 McKenzie Alex Traffic Statistics August 1972 RFC 391 NIC 11583 BBN 15 September 1972 392 Hicks Greg and Barry Wessler Measurement of Host Costs for Transmitting Network Data RFC 392 NIC 11584 Utah 20 September 1972 393 Winett Joel Comments on Telnet Protocol Changes RFC 393 NIC 11585 Lincoln Labs 3 October 1972 394 McQuillan John Two Proposed Changes to the IMP HOST Protocol RFC 394 NIC 11586 BBN 27 September 1972 395 McQuillan John Switch Settings on IMPs and TIPs RFC 395 NIC 11587 BBN 3 October 1972 396 Bunch Steve Network Graphics Working Group Meeting Second Iteration RFC 396 NIC 11796 Illinois 13 November 1973 397 Never Issued 398 Pickens John ICP Sockets RFC 398 NIC 11911 22 September 1972 399 Krilanovich Mark SMFS Login and Logout RFC 399 NIC 11917 UCSB 26 September 1972 400 McKenzie Alex Traffic Statistics September 1972 RFC 400 NIC 11922 BBN 18 October 1972 401 Hanson Jim Conversion of NGP 0 Coordinates to Device Specific Coordinates RFC 401 NIC 11923 Illinois 23 October 1972 402 Network Information Center ARPA Network Mailing Lists RFC 402 NIC 11924 NIC 26 October 1972 403 Hicks Greg Desirability of a Network 1108 RFC 403 NIC 11925 Utah 10 January 1973 404 McKenzie Alex Host Address Changes Involving RAND and ISI RFC 404 NIC 12068 BBN 5 October 1972 405 McKenzie Alex Correction to RFC 404 RFC 405 NIC 12110 BBN 10 October 1972 Reynolds Postel Page 26 RFC 1012 Bibliography of RFCs 1 999 June 1987 406 McQuillan John Scheduled IMP Software Releases RFC 406 NIC 12111 BBN 10 October 1972 407 Bressler Bob Rich Guida and Alex McKenzie Remote Job Entry Protocol RFC 407 NIC 12112 MIT and BBN 16 October 1972 408 Owen Buz and Jon Postel NETBANK RFC 408 NIC 12390 SAAC TIP and UCLA NMC 25 October 1972 409 White Jim TENEX Interface to UCSB s Simple Minded File System RFC 409 NIC 12401 SRI ARC 8 December 1972 410 McQuillan John Removal of the 30 Second Delay When Hosts Come Up RFC 410 NIC 12402 BBN 10 November 1972 411 Padlipsky Mike New Multics Network Software Features RFC 411 NIC 12403 MIT 14 November 1972 412 Hicks Greg User FTP Documentation RFC 412 NIC 12404 Utah 27 November 1972 413 McKenzie Alex Traffic Statistics October 1972 RFC 413 NIC 12405 BBN 13 November 1972 414 Bhushan Abhay File Transfer Protocol FTP Status and Further Comments RFC 414 NIC 12406 MIT Project MAC 20 November 1972 415 Murray Hal TENEX Bandwidth RFC 415 NIC 10428 CCA 29 November 1972 416 Norton James The ARC System Will Be Unavailable For Use During Thanksgiving Week RFC 416 NIC 12542 SRI ARC 7 November 1972 417 Postel Jon and Chuck Kline Link Usage Violation RFC 417 NIC 12574 UCLA NMC 6 November 1972 418 Hathaway Wayne Server File Transfer Under TSS 360 at NASA Ames Research Center RFC 418 NIC 12762 Ames Research Center 27 November 1972 419 Vezza Al Attention Network Liaisons and Station Agents RFC 419 NIC 12763 12 December 1972 420 Murray Hal CCA ICCC Weather Demo RFC 420 NIC 12764 CCA 4 January 1973 Reynolds Postel Page 27 RFC 1012 Bibliography of RFCs 1 999 June 1987 421 McKenzie Alex A Software Consulting Service for Network Users RFC 421 NIC 12897 BBN 27 November 1972 422 McKenzie Alex Traffic Statistics November 1972 RFC 422 NIC 13007 BBN 11 December 1972 423 Noble Barbara UCLA Campus Computing Network Liaison Staff for ARPA Network RFC 423 NIC 13008 UCLA CCN 12 December 1972 424 Never Issued 425 Bressler Bob But my NCP costs 500 a day RFC 425 NIC 13010 BBN 19 December 1972 426 Thomas Bob Reconnection Protocol RFC 426 NIC 13011 BBN 26 January 1973 427 Never Issued 428 Never Issued 429 Postel Jon Character Generator Process RFC 429 NIC 13281 UCLA NMC 12 December 1972 430 Braden Bob Comments on File Transfer Protocol RFC 430 NIC 13299 UCLA CCN 7 February 1973 431 Krilanovich Mark Update on SMFS Login and Logout RFC 431 NIC 13300 UCSB 15 December 1972 432 Neigus Nancy Network Logical Map RFC 432 NIC 13490 BBN 29 December 1972 433 Postel Jon and Nancy Neigus Socket Number List RFC 433 NIC 13491 UCLA NMC and BBN 22 December 1972 434 McKenzie Alex IMP TIP Memory Retrofit Schedule RFC 434 NIC 13658 BBN 4 January 1973 435 Cosell Bernie and Dave Walden Telnet Issues RFC 435 NIC 13675 BBN NET 5 January 1973 436 Krilanovich Mark Announcement of RJS at UCSB RFC 436 NIC 13700 UCSB 10 January 1973 437 Faeh Ed Data Reconfiguration Service at UCSB RFC 437 NIC 13701 UCSB 30 June 1973 Reynolds Postel Page 28 RFC 1012 Bibliography of RFCs 1 999 June 1987 438 Thomas Bob and Bob Clements FTP Server Server Interaction RFC 438 NIC 13770 BBN 15 January 1973 439 Cerf Vint PARRY Encounters the DOCTOR RFC 439 NIC 13771 SU ERL 21 January 1973 440 Walden Dave Scheduled Network Software Maintenance RFC 440 4IC 13772 BBN 29 January 1973 441 Bressler Bob and Bob Thomas Inter Entity Communication An Experiment RFC 441 NIC 13773 BBN 19 January 1973 442 Cerf Vint The Current Flow Control Scheme for IMPSYS RFC 442 NIC 13774 SU ERL 24 January 1973 443 McKenzie Alex Traffic Statistics December 1972 RFC 443 NIC 13899 BBN 18 January 1973 444 Never Issued 445 McKenzie Alex IMP TIP Preventive Maintenance Schedule RFC 445 NIC 14028 BBN 22 January 1973 446 Deutsch L Peter Proposal to Consider a Network Program Resource Notebook RFC 446 NIC 14068 XEROX PARC 25 January 1973 447 McKenzie Alex IMP TIP Memory Retrofit Schedule RFC 447 NIC 14104 BBN 29 January 1973 448 Braden Bob Print Files in FTP RFC 448 NIC 13299 UCLA CCN 27 February 1973 449 Walden Dave The Current Flow Control Scheme for IMPSYS RFC 449 NIC 14133 BBN 6 January 1973 450 Padlipsky Mike Multics Sampling Timeout Change RFC 450 NIC 14134 MIT Multics 8 February 1973 451 Padlipsky Mike Tentative Proposal for a Unified User Level Protocol RFC 451 NIC 14135 MIT Multics 22 February 1973 452 Winett Joel Telnet Command at Host LL RFC 452 NIC 14136 Lincoln Labs 8 February 1973 453 Kudlick Michael Meeting Announcement to Discuss a Network Mail System RFC 453 NIC 14317 SRI ARC 7 February 1973 Reynolds Postel Page 29 RFC 1012 Bibliography of RFCs 1 999 June 1987 454 McKenzie Alex File Transfer Protocol RFC 454 NIC 14333 BBN 16 February 1973 455 McKenzie Alex Traffic Statistics January 1973 RFC 455 NIC 14375 BBN 12 February 1973 456 Network Information Center Memorandum Date Change of Mail Meeting RFC 456 NIC 14376 NIC 13 February 1973 457 Walden Dave TIPUG RFC 457 NIC 14377 BBN NET 15 February 1973 458 Bressler Bob and Bob Thomas Mail Retrieval via FTP RFC 458 NIC 14378 BBN NET and BBN TENEX 20 February 1973 459 Kantrowitz W Network Questionnaires RFC 459 NIC 14379 LL TX 2 26 February 1973 460 Kline Chuck NCP Survey RFC 460 NIC 14415 UCLA NMC 13 February 1973 461 McKenzie Alex Telnet Protocol Meeting Announcement RFC 461 NIC 14416 BBN 14 February 1973 462 Iseli Jean and Dave Crocker Responding to User Needs RFC 462 NIC 14434 MITRE and UCLA NMC 22 February 1973 463 Bhushan Abhay FTP Comments and Response to RFC 430 RFC 463 NIC 14573 MIT DMCG 21 February 1973 464 Kudnick Michael Resource Notebook Framework RFC 464 NIC 14738 SRI ARC 27 February 1973 465 Never Issued 466 Winett Joel Telnet LOGGER SERVER for Host LL 67 RFC 466 NIC 14740 Lincoln Labs 27 February 1973 467 Burchfiel Jerry and Ray Tomlinson Proposed Change to Host Host Protocol Resynchronization of Connection Status RFC 467 NIC 14741 BBN 20 February 1973 468 Braden Bob FTP Data Compression RFC 468 NIC 14742 UCLA CCN 8 March 1973 469 Kudlick Michael Network Mail Meeting Summary RFC 469 NIC 14798 SRI ARC 8 March 1973 Reynolds Postel Page 30 RFC 1012 Bibliography of RFCs 1 999 June 1987 470 Thomas Bob Change in Socket for TIP News Facility RFC 470 NIC 14799 BBN TENEX 13 March 1973 471 Thomas Bob Announcement of a Tentative Workshop on Multi Site Executive Programs RFC 471 NIC 14800 BBN TENEX 13 March 1973 472 Bunch Steve Illinois Reply to Maxwell s Request for Graphics Information RFC 472 NIC 14801 Illinois March 1973 473 Walden Dave MIX and MIXAL RFC 473 NIC 14811 BBN NET 28 February 1973 474 Bunch Steve Announcement of Forthcoming Meeting of the Network Graphics Working Group and Call for RFC s RFC 474 NIC 14905 Illinois March 1973 475 Bhushan Abhay FTP and Network Mail System RFC 475 NIC 14919 MIT DMCG 6 March 1973 476 McKenzie Alex IMP TIP Memory Retrofit Schedule Revision 2 RFC 476 NIC 14920 BBN NET 7 March 1973 477 Krilanovich Mark Remote Job Service at UCSB RFC 477 NIC 14922 UCSB 13 March 1973 478 Bressler Bob and Bob Thomas FTP Server Server Interaction II RFC 478 NIC 14947 BBN NET and BBN TENEX 26 March 1973 479 White Jim Use of FTP by the NIC Journal RFC 479 NIC 14948 SRI ARC 8 March 1973 480 White Jim Host Dependent FTP Parameters RFC 480 NIC 14949 SRI ARC 8 March 1973 481 Never Issued 482 McKenzie Alex Traffic Statistics February 1973 RFC 482 NIC 14966 BBN NET 12 March 1973 483 Kudlick Michael Cancellation of the Resource Notebook Framework Meeting RFC 483 NIC 15061 SRI ARC 14 March 1973 484 Never Issued Reynolds Postel Page 31 RFC 1012 Bibliography of RFCs 1 999 June 1987 485 Pickens John MIX and MIXAL at UCSB RFC 485 NIC 15063 UCSB 19 March 1973 486 Bressler Bob Data Transfer Revisited RFC 486 NIC 15064 BBN 20 March 1973 487 Bressler Bob Free File Transfer RFC 487 NIC 15065 BBN 6 April 1973 488 Auerbach Marilyn et al NLS Classes at Network Sites RFC 488 NIC 15266 NIC 23 March 1973 489 Postel Jon Comment on Resynchronization of Connection Status Proposal RFC 489 NIC 15298 UCLA NMC 26 March 1973 490 Pickens John Surrogate RJS for UCLA CCN RFC 490 NIC 15355 UCSB 6 March 1973 491 Padlipsky Mike What is Free RFC 491 NIC 15356 MIT Multics 12 April 1973 492 Meyer Edwin W Jr Response to RFC 467 RFC 492 NIC 15357 MIT Multics 18 April 1973 493 Michener James C et al Graphics Protocol RFC 493 NIC 15358 MIT Project MAC 26 April 1973 494 Walden Dave Availability of MIX and MIXAL in the Network RFC 494 NIC 15359 BBN NET 20 April 1973 495 McKenzie Alex Telnet Protocol Specification RFC 495 NIC 15371 BBN NET 1 May 1973 496 Auerbach Marilyn A TNLS Quick Reference Card is Available RFC 496 NIC 15496 NIC 5 April 1973 497 McKenzie Alex Traffic Statistics March 1973 RFC 497 NIC 15651 BBN NET 10 April 1973 498 Braden Bob On Mail Service to CCN RFC 498 NIC 15715 UCLA CCN 17 April 1973 499 Reussow Bradley A Harvard s Network RJE RFC 499 NIC 15716 Harvard 1 April 1973 500 Shoshani Arie and I Spiegler The Integration of Data Management Systems on a Computer Network RFC 500 NIC 15717 SDC 16 April 1973 Reynolds Postel Page 32 RFC 1012 Bibliography of RFCs 1 999 June 1987 501 Pogran Ken Un Muddling Free File Transfer RFC 501 NIC 15718 MIT Multics 11 May 1973 502 Never Issued 503 Neigus Nancy and Jon Postel Socket Number List RFC 503 NIC 15747 BBN NET and UCLA NMC 12 April 1973 504 Thomas Bob Workshop Announcement RFC 504 NIC 16155 BBN 30 April 1973 505 Padlipsky Mike Two Solutions to a File Transfer Access Problem RFC 505 NIC 16156 MIT Multics 25 June 1973 506 Padlipsky Mike An FTP Command Naming Problem RFC 506 NIC 16157 MIT Multics 26 June 1973 507 Never Issued 508 Pfeifer Larry Real Time Data Transmission on the ARPANET RFC 508 NIC 16159 UCSB 7 May 1973 509 McKenzie Alex Traffic Statistics April 1973 RFC 509 NIC 16294 BBN NET 7 May 1973 510 White Jim Request for Network Mailbox Addresses RFC 510 NIC 16400 SRI ARC 30 May 1973 511 North Jeanne Enterprise Phone Service to NIC from ARPANET Sites RFC 511 NIC 16442 NIC 23 May 1973 512 Hathaway Wayne More on Lost Message Detection RFC 512 NIC 16443 Ames Research Center 25 May 1973 513 Hathaway Wayne Comments on the New Telnet Specifications RFC 513 NIC 16444 Ames Research Center SRI ARC 30 May 1973 514 Kantrowitz W Network Make Work RFC 514 NIC 16445 Lincoln Labs 5 June 1973 515 Winter R Specifications for Datalanguage Version 0 9 RFC 515 NIC 16446 CCA 6 June 1973 516 Postel Jon Lost Message Detection RFC 516 NIC 16693 UCLA NMC 18 May 1973 517 Never Issued Reynolds Postel Page 33 RFC 1012 Bibliography of RFCs 1 999 June 1987 518 Vaughan Nancy and Elizabeth Feinler ARPANET Accounts RFC 518 NIC 16817 SRI ARC 19 June 1973 519 Pickens John Resource Evaluation RFC 519 NIC 16818 UCSB June 1973 520 Day John Memo to FTP Group Proposal for File Access Protocol RFC 520 NIC 16819 Illinois 25 June 1973 521 McKenzie Alex Restricted Use of IMP DDT RFC 521 NIC 16855 BBN 30 May 1973 522 McKenzie Alex Traffic Statistics May 1973 RFC 522 NIC 17033 BBN 5 June 1973 523 Bhushan Abhay SURVEY is in Operation Again RFC 523 NIC 17048 MIT DMCG 5 June 1973 524 White Jim A Proposed Mail Protocol RFC 524 NIC 17140 SRI ARC 13 June 1973 525 Parrish William and John Pickens MIT MATHLAB Meets UCSB OLS RFC 525 NIC 17161 UCSB 1 June 1973 526 Pratt William Technical Meeting Digital Image Example of Resource Sharing RFC 526 NIC 17162 USC 25 June 1973 527 Merryman Robert ARPAWOCKY RFC 527 NIC 17163 UCSD CC 22 June 1973 528 McQuillian John Software Checksumming in the IMP and Network Reliability RFC 528 NIC 17164 BBN 20 June 1973 529 McKenzie Alex Bob Thomas Ray Tomlinson and Ken Pogran A Note on Protocol Synch Sequences RFC 529 NIC 17165 BBN and MIT 29 June 1973 530 Bhushan Abhay A Report on the Survey Project RFC 530 NIC 17375 MIT DMCG 22 June 1973 531 Padlipsky Mike A Response to Two Recent RFC s About Network Information RFC 531 NIC 17450 MIT Mulitcs 26 June 1973 532 Merryman Robert The UCSD CC Server FTP Facility RFC 532 NIC 17451 UCSD CC 22 June 1973 533 Walden Dave Message ID Numbers RFC 533 NIC 17452 BBN 17 July 1973 Reynolds Postel Page 34 RFC 1012 Bibliography of RFCs 1 999 June 1987 534 Walden Dave Lost Message Detection RFC 534 NIC 17453 BBN 17 July 1973 535 Thomas Bob Comments on File Access Protocol RFC 535 NIC 17454 BBN 25 July 1973 536 Never Issued 537 Bunch Steve Announcement of NGG Meeting July 16 17 RFC 537 NIC 17498 Illinois 27 June 1973 538 McKenzie Alex Traffic Statistics June 1973 RFC 538 NIC 17642 BBN 5 July 1973 539 Crocker Dave and Jon Postel Thoughts on the Mail Protocol Proposed in RFC 524 RFC 539 NIC 17644 UCLA NMC 7 July 1973 540 Never Issued 541 Never Issued 542 Neigus Nancy File Transfer Protocol RFC 542 NIC 17759 BBN 12 July 1973 543 Meyer Dean Network Journal Submission and Delivery RFC 543 NIC 17777 SRI ARC 13 July 1973 544 Meyer Dean and Kirk Kelley Locating On Line Documentation at SRI ARC RFC 544 NIC 17782 SRI ARC 13 July 1973 545 Pickens John Of What Quality Be the UCSB Resource Evaluators RFC 545 NIC 17791 UCSB 23 July 1973 546 Thomas Bob TENEX Load Averages for July 1973 RFC 546 NIC 17792 BBN 10 August 1973 547 Walden Dave Change to the Very Distant Host Specification RFC 547 NIC 17793 BBN 13 August 1973 548 Walden Dave Hosts Using the IMP Going Down Message RFC 548 NIC 17794 BBN 16 August 1973 549 Bunch Steve Minutes of Network Graphics Group RFC 549 NIC 17795 Illinois July 1973 550 Deutsch L Peter NIC NCP Experiment RFC 550 NIC 17796 XEROX PARC 24 August 1973 Reynolds Postel Page 35 RFC 1012 Bibliography of RFCs 1 999 June 1987 551 Feinroth Yeshiah and Robert Fink Implementation of Local Conventions RFC 551 NYU and LBL 27 August 1973 552 Owen Buzz Single Access to Standard Protocols RFC 552 SAAC TIP 13 July 1973 553 Thomas Elaine et al Draft Design for a Text Graphics Protocol RFC 553 NIC 17810 14 July 1973 554 Never Issued 555 White Jim Response to Critiques of the Proposed Mail Protocol RFC 555 NIC 17993 SRI ARC 27 July 1973 556 McKenzie Alex Traffic Statistics July 1973 RFC 556 NIC 18376 13 August 1973 557 Wessler Barry Revelations in Network Host Measurements RFC 557 NIC 18457 30 August 1973 558 Never Issued 559 Bhushan Abhay Comments on the New Telnet Protocol and Its Implementation RFC 559 NIC 18482 15 August 1973 560 Crocker Dave and Jon Postel Remote Controlled Transmission and Echoing Telnet Option RFC 560 NIC 18492 20 August 1973 561 Bhushan Abhay Ken Pogran Ray Tomlinson and Jim White Standardizing Network Mail Headers RFC 561 NIC 18516 MIT BBN and SRI ARC 5 September 1973 562 McKenzie Alex Modifications to the Telnet Specification RFC 562 NIC 18638 BBN 28 August 1973 563 Davidson John Comments on the RCTE Telnet Option RFC 563 NIC 18775 University of Hawaii 28 August 1973 564 Never Issued 565 Cantor Don Storing Network Survey Data at the Datacomputer RFC 565 NIC 18777 CCA 28 August 1973 566 McKenzie Alex Traffic Statistics August 1983 RFC 566 NIC 18801 BBN 4 September 1973 567 Deutsch L Peter Cross Country Network Bandwidth RFC 567 NIC 18970 XEROX PARC 6 September 1973 Reynolds Postel Page 36 RFC 1012 Bibliography of RFCs 1 999 June 1987 568 McQuillan John Response to RFC 567 Cross Country Network Bandwidth RFC 568 NIC 18971 BBN 18 September 1973 569 Padlipsky Mike NETED A Common Editor for the ARPA Network RFC 569 NIC 18972 15 October 1973 570 Pickens John Experimental Input Mapping Between NVT ASCII and UCSB Online System RFC 570 NIC 18973 UCSB 30 October 1973 571 Braden Bob TENEX FTP Problem RFC 571 NIC 18974 UCLA CCN 15 November 1973 572 Never Issued 573 Bhushan Abhay Data and File Transfer Some Measurement Results RFC 573 NIC 19083 MIT DM 14 September 1973 574 Krilanovich Mark Announcement of a Mail Facility at UCSB RFC 574 NIC 19144 UCSB 26 September 1973 575 Never Issued 576 Victor Ken Proposal for Modifying Linking RFC 576 NIC 19324 SRI 26 September 1973 577 Crocker Dave Mail Priority RFC 577 NIC 19356 UCLA NMC 18 October 1973 578 Bhushan Abhay and Neal Ryan Using MIT MATHLAB MACSYMA from MIT DMS MUDDLE An Experiment in Automated Resource Sharing RFC 578 NIC 19501 MIT 8 October 1973 579 McKenzie Alex Traffic Statistics September 1973 RFC 579 NIC 19655 BBN 15 October 1973 580 Postel Jon Note to Protocol Designers and Implementers RFC 580 NIC 19849 MITRE 25 October 1973 581 Crocker Dave and Jon Postel Corrections to RFC 560 Remote Controlled Transmission and Echoing Telnet Option RFC 581 NIC 19860 UCLA and MITRE 2 November 1973 582 Clements Robert C Comments on RFC 580 Machine Readable Protocols RFC 582 NIC 19962 BBN 5 November 1973 583 Never Issued Reynolds Postel Page 37 RFC 1012 Bibliography of RFCs 1 999 June 1987 584 Iseli Jean Dave Crocker and Nancy Neigus Charter for ARPANET Users Interest Working Group RFC 584 NIC 19025 and 20049 MITRE UCLA NMC BBN 6 November 1973 585 Crocker Dave Nancy Neigus Elizabeth Feinler and Jean Iseli ARPANET Users Interest Working Group Meeting RFC 585 NIC 18259 and 20050 UCLA NMC BBN SRI ARC MITRE 6 November 1973 586 McKenzie Alex Traffic Statistics October 1973 RFC 586 NIC 20096 BBN 8 November 1973 587 Postel Jon Announcing New Telnet Options RFC 587 NIC 20198 MITRE 13 November 1973 588 Stokes Adrian V London Node is Now Up RFC 588 NIC 20217 UKICS 29 October 1973 589 Braden Bob CCN NETRJS Server Messages to Remote User RFC 589 NIC 20268 UCLA CCN 26 November 1973 590 Padlipsky Michael Multics Address Change RFC 590 NIC 20326 MIT Multics 19 November 1973 591 Walden Dave Addition to the Very Distant Host Specification RFC 591 NIC 20327 BBN NET 29 November 1973 592 Watson Richard W Some Thoughts on System Design to Facilitate Resource Sharing RFC 592 NIC 20391 SRI ARC 20 November 1973 593 McKenzie Alex and Jon Postel Telnet and FTP Implementation Schedule Change RFC 593 NIC 20615 BBN and MITRE 29 November 1973 594 Burchfiel Jerry Speedup of Host IMP Interface RFC 594 NIC 20616 BBN 10 December 1973 595 Hathaway Wayne Some Thoughts in Defense of the Telnet Go Ahead RFC 595 NIC 20617 AMES Research Center 12 December 1973 596 Taft Edward Second Thoughts on Telnet Go Ahead RFC 596 NIC 20812 XEROX PARC 8 December 1973 597 Neigus Nancy and Elizabeth Feinler Host Status RFC 597 NIC 20826 BBN and SRI ARC 12 December 1973 Reynolds Postel Page 38 RFC 1012 Bibliography of RFCs 1 999 June 1987 598 Network Information Center RFC Index December 5 1973 RFC 598 NIC 20853 NIC 5 December 1973 599 Braden Bob Update on NETRJS RFC 599 NIC 20854 UCLA CCN 13 December 1973 600 Berggreen Arthur Interfacing an Illinois Plasma Terminal to the ARPANET RFC 600 NIC 20884 UCSB 26 November 1973 601 McKenzie Alex Traffic Statistics November 1973 RFC 601 NIC 20905 BBN 14 December 1973 602 Metcalfe Bob The Stockings Were Hung by the Chimney With Care RFC 602 NIC 21021 XEROX PARC 27 December 1973 603 Burchfiel Jerry Response to RFC 597 Host Status RFC 603 NIC 21022 BBN 31 December 1973 604 Postel Jon Assigned Link Numbers RFC 604 NIC 21186 MITRE 26 December 1973 605 Never Issued 606 Deutsch L Peter Host Names On line RFC 606 NIC 21246 XEROX PARC 29 December 1973 607 Krilanovich Mark and George Gregg Comments on the File Transfer Protocol RFC 607 NIC 21255 UCSB 7 January 1974 608 Kudlick Michael Host Names On line RFC 608 NIC 21256 SRI ARC 10 January 1974 609 Ferguson Bill Statement of Upcoming Move of NIC NLS Services RFC 609 NIC 21339 SRI ARC 10 January 1974 610 Winter Richard Jeffrey Hill and Warren Greiff Further Datalanguage Design Concepts RFC 610 NIC 21352 CCA 15 December 1973 611 Walden Dave Two Changes to the IMP Host Protocol to Improve USER Network Communications RFC 611 NIC 21354 BBN 14 February 1974 612 McKenzie Alex Traffic Statistics December 1973 RFC 612 NIC 21404 BBN 16 January 1974 613 McKenzie Alex Network Connectivity A Response to RFC 603 RFC 613 NIC 21525 BBN 21 January 1974 Reynolds Postel Page 39 RFC 1012 Bibliography of RFCs 1 999 June 1987 614 Pogran Ken and Nancy Neigus Response to RFC 607 Comments on the File Transfer Protocol RFC 614 NIC 21530 BBN 28 January 1974 615 Crocker Dave Proposed Network Standard Data Pathname Syntax RFC 615 NIC 21531 UCLA NMC 1 March 1974 616 Walden Dave Latest Network Maps RFC 616 NIC 21532 BBN 11 February 1974 617 Taft Edward A Note on Socket Number Assignment RFC 617 NIC 21771 XEROX PARC 19 February 1974 618 Taft Edward A Few Observations on NCP Statistics RFC 618 NIC 21989 XEROX PARC 19 February 1974 619 Naylor William and Holger Opderbeck Mean Round Trip Times in the ARPANET RFC 619 NIC 21791 UCLA 7 March 1974 620 Ferguson Bill Request for Monitor Host Table Updates RFC 620 NIC 21993 SRI ARC 1 March 1974 621 Kudlick Michael NIC User Directories at SRI ARC RFC 621 NIC 21994 SRI ARC 6 March 1974 622 McKenzie Alex Scheduling IMP TIP Down Time RFC 622 NIC 21995 BBN 13 March 1974 623 Krilanovich Mark Comments on On line Host Name Service RFC 623 NIC 22004 UCSB 22 February 1974 624 Krilanovich Mark George Gregg Wayne Hathaway and Jim White Comments on the File Transfer Protocol RFC 624 NIC 22054 UCSB Ames Research Center SRI ARC 28 February 1974 625 Kudlick Mike and Elizabeth Feinler On Line Hostnames Service RFC 625 NIC 22152 SRI ARC 7 March 1974 626 Kleinrock Leonard and Holger Opderbeck On a Possible Lockup Condition in the IMP Subnet due to Message Sequencing RFC 626 NIC 22161 UCLA 14 March 1974 627 Kudlick Mike and Jake Feinler ASCII Text File of Hostnames RFC 627 NIC 22160 SRI ARC 25 March 1974 628 Keeney Marcia Status of RFC Numbers and a Note on Pre assigned Jourcal Numbers RFC 628 NIC 22161 SRI ARC 27 March 1974 Reynolds Postel Page 40 RFC 1012 Bibliography of RFCs 1 999 June 1987 629 North Jeanne Scenario for Using the Network Journal RF0 629 NIC 22383 SRI ARC 27 March 1974 630 Sussman Julie FTP Error Code Usage for More Reliable Mail Service RFC 630 NIC 30237 BBN 10 April 1974 631 Danthine Andre Call for Papers International Meeting on Minicomputers and Data Communication RFC 631 NIC 30238 20 May 1974 632 Opderbeck Holger Throughput Degradations for Single Packet Messages RFC 632 NIC 30239 UCLA 10 April 1974 633 McKenzie Alex IMP TIP Preventive Maintenance Schedule RFC 633 NIC 30240 BBN 18 March 1974 634 McKenzie Alex Change in Network Address for Haskins Lab RFC 634 NIC 30445 BBN 10 April 1974 635 Cerf Vint An Assessment of ARPANET Protocols RFC 635 NIC 30489 Stanford 22 April 1974 636 Burchfiel Jerry Bernie Cosell Ray Tomlinson and Dave Walden TIP TENEX Reliability Improvements RFC 636 NIC 30490 BBN 10 June 1974 637 McKenzie Alex Change of Network Address for SU DSL RFC 637 NIC 30519 BBN 23 April 1974 638 McKenzie Alex IMP TIP Preventive Maintenance Schedule RFC 638 NIC 30538 BBN 25 April 1974 639 Never Issued 640 Postel Jon Revised FTP Reply Codes RFC 640 NIC 30843 UCLA NMC 5 June 1974 641 Never Issued 642 Burchfiel Jerry Ready Line Philosophy and Implementation RFC 642 NIC 30872 BBN 5 July 1974 643 Mader Eric Network Debugging Protocol RFC 643 NIC 30873 July 1974 644 Thomas Bob On The Problem of Signature Authentication for Network Mail RFC 644 NIC 30874 BBN 22 July 1974 Reynolds Postel Page 41 RFC 1012 Bibliography of RFCs 1 999 June 1987 645 Crocker Dave Network Standard Data Specification Syntax RFC 645 NIC 30899 UCLA NMC 27 June 1974 646 Never Issued 647 Padlipsky Michael A Proposed Protocol for Connecting Host Computers to ARPA Like Networks Via Directly Connected Front End Processors RFC 647 NIC 31117 MITRE 12 November 1974 648 Never Issued 649 Never Issued 650 Never Issued 651 Crocker Dave Revised Telnet Status Option RFC 651 NIC 31154 UCLA NMC 25 October 1974 652 Crocker Dave Telnet Output Carriage Return Disposition Option RFC 652 NIC 31155 UCLA NMC 25 October 1974 653 Crocker Dave Telnet Output Horizontal Tabstops Option RFC 653 NIC 31156 UCLA NMC 25 October 1974 654 Crocker Dave Telnet Output Horizontal Tab Disposition Option RFC 654 NIC 31157 UCLA NMC 25 October 1974 655 Crocker Dave Telnet Output Formfeed Disposition Option RFC 655 NIC 31158 UCLA NMC 25

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1012.txt (2016-02-14)
    Open archived version from archive


  • plans for implementation or use of this protocol with the contact OTHER REFERENCES RFC 741 in DPH DEPENDENCIES Internet Protocol Stream Protocol CONTACT Casner ISI EDU Reynolds Postel Page 14 RFC 1011 Official Internet Protocols May 1987 APPLICATION LEVEL Telnet Protocol TELNET STATUS Recommended SPECIFICATION RFC 854 in DPH COMMENTS The protocol for remote terminal access This has been revised since the IPTW RFC 764 in IPTW is now obsolete OTHER REFERENCES MIL STD 1782 in DPH Telnet Protocol DEPENDENCIES Transmission Control Protocol CONTACT Postel ISI EDU Reynolds Postel Page 15 RFC 1011 Official Internet Protocols May 1987 Telnet Options TELNET OPTIONS STATUS Elective SPECIFICATION General description of options RFC 855 in DPH Number Name RFC NIC DPH USE 0 Binary Transmission 856 yes yes 1 Echo 857 yes yes 2 Reconnection 15391 yes no 3 Suppress Go Ahead 858 yes yes 4 Approx Message Size Negotiation 15393 yes no 5 Status 859 yes yes 6 Timing Mark 860 yes yes 7 Remote Controlled Trans and Echo 726 39237 yes no 8 Output Line Width 20196 yes no 9 Output Page Size 20197 yes no 10 Output Carriage Return Disposition 652 31155 yes no 11 Output Horizontal Tabstops 653 31156 yes no 12 Output Horizontal Tab Disposition 654 31157 yes no 13 Output Formfeed Disposition 655 31158 yes no 14 Output Vertical Tabstops 656 31159 yes no 15 Output Vertical Tab Disposition 657 31160 yes no 16 Output Linefeed Disposition 658 31161 yes no 17 Extended ASCII 698 32964 yes no 18 Logout 727 40025 yes no 19 Byte Macro 735 42083 yes no 20 Data Entry Terminal 732 41762 yes no 21 SUPDUP 734 736 42213 yes no 22 SUPDUP Output 749 45449 yes no 23 Send Location 779 yes no 24 Terminal Type 930 yes no 25 End of Record 885 yes no 26 TACACS User Identification 927 yes no 27 Output Marking 933 yes no 28 Terminal Location Number 946 no no 255 Extended Options List 861 yes yes The DHP column indicates if the specification is included in the DDN Protocol Handbook The USE column of the table above indicates which options are in general use COMMENTS The Binary Transmission Echo Suppress Go Ahead Status Reynolds Postel Page 16 RFC 1011 Official Internet Protocols May 1987 Timing Mark and Extended Options List options have been recently updated and reissued These are the most frequently implemented options The remaining options should be reviewed and the useful ones should be revised and reissued The others should be eliminated The following are recommended Binary Transmission Echo Suppress Go Ahead Status Timing Mark and Extended Options List OTHER REFERENCES DEPENDENCIES Telnet CONTACT Postel ISI EDU SUPDUP Protocol SUPDUP STATUS Elective SPECIFICATION RFC 734 in DPH COMMENTS A special Telnet like protocol for display terminals OTHER REFERENCES DEPENDENCIES Transmission Control Protocol CONTACT Crispin SU SCORE STANFORD EDU File Transfer Protocol FTP STATUS Recommended SPECIFICATION RFC 959 in DPH COMMENTS The protocol for moving files between Internet hosts Provides for access control and negotiation of file parameters The following new optional commands are included in this edition of the specification Change to Parent Directory Reynolds Postel Page 17 RFC 1011 Official Internet Protocols May 1987 CDUP Structure Mount SMNT Store Unique STOU Remove Directory RMD Make Directory MKD Print Directory PWD and System SYST Note that this specification is compatible with the previous edition RFC 765 A discrepancy has been found in the specification in the examples of Appendix II On page 63 a response code of 200 is shown as the response to a CWD command Under the list of Command Reply Sequences cited on page 50 CWD is shown to only accept a 250 response code Therefore if one would interpret a CWD command as being excluded from the File System functional category one may assume that the response code of 200 is correct since CDUP as a special case of CWD does use 200 OTHER REFERENCES RFC 678 in DPH Document File Format Standards MIL STD 1780 in DPH File Transfer Protocol DEPENDENCIES Transmission Control Protocol CONTACT Postel ISI EDU Trivial File Transfer Protocol TFTP STATUS Elective SPECIFICATION RFC 783 in IPTW COMMENTS A very simple file moving protocol no access control is provided This is in use in several local networks Ambiguities in the interpretation of several of the transfer modes should be clarified and additional transfer modes could be defined Additional error codes could be defined to more clearly identify problems Note The DPH contains IEN 133 which is an obsolete version of this protocol OTHER REFERENCES Reynolds Postel Page 18 RFC 1011 Official Internet Protocols May 1987 DEPENDENCIES User Datagram Protocol CONTACT Postel ISI EDU Simple File Transfer Protocol SFTP STATUS Experimental SPECIFICATION RFC 913 in DPH COMMENTS SFTP is a simple file transfer protocol It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement and less powerful than FTP SFTP supports user access control file transfers directory listing directory changing file renaming and deleting SFTP can be implemented with any reliable 8 bit byte stream oriented protocol this document describes its TCP specification SFTP uses only one TCP connection whereas TFTP implements a connection over UDP and FTP uses two TCP connections one using the TELNET protocol Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES DEPENDENCIES Transmission Control Protocol CONTACT MKL SRI NIC ARPA Simple Mail Transfer Protocol SMTP STATUS Recommended SPECIFICATION RFC 821 in DPH COMMENTS The procedure for transmitting computer mail between hosts This has been revised since the IPTW it is in the Internet Mail Protocols volume of November 1982 RFC 788 in IPTW is obsolete Reynolds Postel Page 19 RFC 1011 Official Internet Protocols May 1987 There have been many misunderstandings and errors in the early implementations Some documentation of these problems can be found in the file C ISI EDU MAIL ERRORS Some minor differences between RFC 821 and RFC 822 should be resolved OTHER REFERENCES RFC 822 Mail Header Format Standards This has been revised since the IPTW it is in the Internet Mail Protocols volume of November 1982 RFC 733 in IPTW is obsolete Further revision of RFC 822 is needed to correct some minor errors in the details of the specification Note RFC 822 is not included in the DPH an accident it should have been MIL STD 1781 in DPH Simple Mail Transfer Protocol SMTP DEPENDENCIES Transmission Control Protocol CONTACT Postel ISI EDU Network News Transfer Protocol NNTP STATUS Experimental SPECIFICATION RFC 977 COMMENTS NNTP specifies a protocol for the distribution inquiry retrieval and posting of news articles using a reliable stream based transmission of news among the Internet community NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read Indexing cross referencing and expiration of aged messages are also provided Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES Reynolds Postel Page 20 RFC 1011 Official Internet Protocols May 1987 DEPENDENCIES Internet Protocol CONTACT Brian SDCSVAX UCSD EDU Post Office Protocol Version 2 POP2 STATUS Experimental SPECIFICATION RFC 937 in DPH COMMENTS The intent of the Post Office Protocol Version 2 POP2 is to allow a user s workstation to access mail from a mailbox server It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol SMTP Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES Obsoletes RFC 918 DEPENDENCIES Transmission Control Protocol CONTACT JKReynolds ISI EDU NetBIOS Services Protocol NETBIOS STATUS Recommended SPECIFICATION RFC 1001 1002 COMMENTS These documents define a proposed standard protocol to support NetBIOS services in a TCP IP environment Both local network and internet operation are supported Various node types are defined to accomodate local and internet topologies and to allow operation with or without the use of IP broadcast RFC 1001 describes the NetBIOS over TCP protocols in a general manner with emphasis on the underlying ideas and techniques RFC 1002 gives the detailed specifications of the NetBIOS over TCP packets protocols and defined constants and variables Reynolds Postel Page 21 RFC 1011 Official Internet Protocols May 1987 OTHER REFERENCES DEPENDENCIES Transmission Control Protocol User Datagram Protocol CONTACT Auerbach CSL SRI COM Bootstrap Protocol BOOTP STATUS Experimental SPECIFICATION RFC 951 COMMENTS This proposed protocol provides an IP UDP bootstrap protocol which allows a diskless client machine to discover its own IP address the address of a server host and the name of a file to be loaded into memory and executed Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES DEPENDENCIES Internet Protocol User Datagram Protocol CONTACT Croft SUMEX AIM STANFORD EDU Loader Debugger Protocol LDP STATUS Experimental SPECIFICATION RFC 909 COMMENTS Specifies a protocol for loading dumping and debugging target machines from hosts in a network environment It is also designed to accommodate a variety of target CPU types It provides a powerful set of debugging services while at the same time it is structured so that a simple subset may be implemented in applications like boot loading where efficiency and space are at a premium Please discuss any plans for implementation or use of this protocol with the contact Reynolds Postel Page 22 RFC 1011 Official Internet Protocols May 1987 OTHER REFERENCES DEPENDENCIES Reliable Data Protocol CONTACT Hinden BBN COM Resource Location Protocol RLP STATUS Elective SPECIFICATION RFC 887 in DPH COMMENTS A resource location protocol for use in the Internet This protocol utilizes the User Datagram Protocol UDP which in turn calls on the Internet Protocol to deliver its datagrams OTHER REFERENCES DEPENDENCIES User Datagram Protocol CONTACT Accetta A CS CMU EDU Remote Job Entry RJE STATUS Elective SPECIFICATION RFC 407 in DPH COMMENTS The general protocol for submitting batch jobs and retrieving the results Some changes needed for use with TCP No known active implementations OTHER REFERENCES DEPENDENCIES File Transfer Protocol Transmission Control Protocol CONTACT Postel ISI EDU Reynolds Postel Page 23 RFC 1011 Official Internet Protocols May 1987 Remote Job Service NETRJS STATUS Elective SPECIFICATION RFC 740 in DPH COMMENTS A special protocol for submitting batch jobs and retrieving the results used with the UCLA IBM OS system Please discuss any plans for implementation or use of this protocol with the contact Revision in progress OTHER REFERENCES DEPENDENCIES Transmission Control Protocol CONTACT Braden ISI EDU Remote Telnet Service RTELNET STATUS Elective SPECIFICATION RFC 818 in DPH COMMENTS Provides special access to user Telnet on a remote system OTHER REFERENCES DEPENDENCIES Telnet Transmission Control Protocol CONTACT Postel ISI EDU Reynolds Postel Page 24 RFC 1011 Official Internet Protocols May 1987 Graphics Protocol GRAPHICS STATUS Elective SPECIFICATION NIC 24308 in DPH COMMENTS The protocol for vector graphics Very minor changes needed for use with TCP No known active implementations Note The DPH claims that this is RFC 493 but RFC 493 is actually a different earlier specification OTHER REFERENCES DEPENDENCIES Telnet Transmission Control Protocol CONTACT Postel ISI EDU Echo Protocol ECHO STATUS Recommended SPECIFICATION RFC 862 in DPH COMMENTS Debugging protocol sends back whatever you send it OTHER REFERENCES DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Postel ISI EDU Reynolds Postel Page 25 RFC 1011 Official Internet Protocols May 1987 Discard Protocol DISCARD STATUS Elective SPECIFICATION RFC 863 in DPH COMMENTS Debugging protocol throws away whatever you send it OTHER REFERENCES DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Postel ISI EDU Character Generator Protocol CHARGEN STATUS Elective SPECIFICATION RFC 864 in DPH COMMENTS Debugging protocol sends you ASCII data OTHER REFERENCES DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Postel ISI EDU Reynolds Postel Page 26 RFC 1011 Official Internet Protocols May 1987 Quote of the Day Protocol QUOTE STATUS Elective SPECIFICATION RFC 865 in DPH COMMENTS Debugging protocol sends you a short ASCII message OTHER REFERENCES DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Postel ISI EDU Statistics Server STATSRV STATUS Recommended SPECIFICATION RFC 996 COMMENTS This RFC specifies a standard for the Internet community Hosts and gateways on the Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host OTHER REFERENCES DEPENDENCIES Internet Protocol CONTACT Mills UDEL EDU Reynolds Postel Page 27 RFC 1011 Official Internet Protocols May 1987 Active Users Protocol USERS STATUS Elective SPECIFICATION RFC 866 in DPH COMMENTS Lists the currently active users OTHER REFERENCES DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Postel ISI EDU Finger Protocol FINGER STATUS Elective SPECIFICATION RFC 742 in DPH COMMENTS Provides information on the current or most recent activity of a user Some extensions have been suggested Some changes are are needed for TCP OTHER REFERENCES DEPENDENCIES Transmission Control Protocol CONTACT Postel ISI EDU Reynolds Postel Page 28 RFC 1011 Official Internet Protocols May 1987 WhoIs Protocol NICNAME STATUS Elective SPECIFICATION RFC 954 in DPH COMMENTS Accesses the ARPANET Directory database Provides a way to find out about people their addresses phone numbers organizations and mailboxes OTHER REFERENCES DEPENDENCIES Transmission Control Protocol CONTACT Feinler SRI NIC ARPA CSNET Mailbox Name Server Protocol CSNET NS STATUS Experimental SPECIFICATION CS DN 2 in DPH COMMENTS Provides access to the CSNET data base of users to give information about users names affiliations and mailboxes Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES DEPENDENCIES Transmission Control Protocol CONTACT Solomon WISC EDU Reynolds Postel Page 29 RFC 1011 Official Internet Protocols May 1987 Domain Name Protocol DOMAIN STATUS Recommended SPECIFICATION RFC 881 RFC 882 RFC 883 in DPH COMMENTS OTHER REFERENCES RFC 920 Domain Requirements RFC 921 Domain Name Implementation Schedule Revised RFC 973 Domain System Changes and Observations RFC 974 Mail Routing and the Domain System DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Mockapetris ISI EDU HOSTNAME Protocol HOSTNAME STATUS Elective SPECIFICATION RFC 953 in DPH COMMENTS Accesses the Registered Internet Hosts database HOSTS TXT Provides a way to find out about a host in the Internet its Internet Address and the protocols it implements OTHER REFERENCES RFC 952 Host Table Specification DEPENDENCIES Transmission Control Protocol CONTACT Feinler SRI NIC ARPA Reynolds Postel Page 30 RFC 1011 Official Internet Protocols May 1987 Host Name Server Protocol NAMESERVER STATUS Experimental SPECIFICATION IEN 116 in DPH COMMENTS Provides machine oriented procedure for translating a host name to an Internet Address This specification has significant problems 1 The name syntax is out of date 2 The protocol details are ambiguous in particular the length octet either does or doesn t include itself and the op code 3 The extensions are not supported by any known implementation This protocol is now abandoned in favor of the DOMAIN protocol Further implementations of this protocol are not advised Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES DEPENDENCIES User Datagram Protocol CONTACT Postel ISI EDU Daytime Protocol DAYTIME STATUS Elective SPECIFICATION RFC 867 in DPH COMMENTS Provides the day and time in ASCII character string OTHER REFERENCES DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Postel ISI EDU Reynolds Postel Page 31 RFC 1011 Official Internet Protocols May 1987 Network Time Protocol NTP STATUS Experimental SPECIFICATION RFC 958 COMMENTS A proposed protocol for synchronizing a set of network clocks using a set of distributed clients and servers Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES RFC 778 RFC 891 RFC 956 and RFC 957 DEPENDENCIES User Datagram Protocol CONTACT Mills UDEL EDU Time Server Protocol TIME STATUS Elective SPECIFICATION RFC 868 in DPH COMMENTS Provides the time as the number of seconds from a specified reference time OTHER REFERENCES DEPENDENCIES Transmission Control Protocol or User Datagram Protocol CONTACT Postel ISI EDU Reynolds Postel Page 32 RFC 1011 Official Internet Protocols May 1987 DCNET Time Server Protocol CLOCK STATUS Experimental SPECIFICATION RFC 778 COMMENTS Provides a mechanism for keeping synchronized clocks Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES DEPENDENCIES Internet Control Message Protocol CONTACT Mills UDEL EDU Authentication Service AUTH STATUS Experimental SPECIFICATION RFC 931 COMMENTS This server provides a means to determine the identity of a user of a particular TCP connection Given a TCP port number pair it returns a character string which identifies the owner of that connection on the server s system Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES Supercedes RFC 912 DEPENDENCIES Transmission Control Protocol CONTACT StJohns SRI NIC ARPA Reynolds Postel Page 33 RFC 1011 Official Internet Protocols May 1987 Authentication Scheme COOKIE JAR STATUS Experimental SPECIFICATION RFC 1004 COMMENTS This RFC focuses its discussion on authentication problems in the Internet and possible methods of solution Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES DEPENDENCIES CONTACT Mills UDEL EDU Internet Message Protocol MPM STATUS Experimental SPECIFICATION RFC 759 in DPH COMMENTS This is an experimental multimedia mail transfer protocol The implementation is called a Message Processing Module or MPM Please discuss any plans for implementation or use of this protocol with the contact OTHER REFERENCES RFC 767 Structured Document Formats DEPENDENCIES Transmission Control Protocol CONTACT Postel ISI EDU Reynolds Postel Page 34 RFC 1011 Official Internet Protocols May 1987 Network Standard Text Editor NETED STATUS Elective SPECIFICATION RFC 569 in DPH COMMENTS Describes a simple line editor which could be provided by every Internet host OTHER REFERENCES DEPENDENCIES CONTACT Postel ISI EDU Reynolds Postel Page 35 RFC 1011 Official Internet Protocols May 1987 APPENDICES Internet Numbers STATUS None SPECIFICATION RFC 997 COMMENTS Describes the fields of network numbers and autonomous system numbers that are assigned specific values for actual use and lists the currently assigned values Issued March 1987

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1011.txt (2016-02-14)
    Open archived version from archive


  • Timestamp The ICMP Timestamp message has proven to be useful for diagnosing Internet problems The preferred form for a timestamp value the standard value is in milliseconds since midnight GMT However it may be difficult to provide this value with millisecond resolution For example many systems use clocks which update only at line frequency 50 or 60 times per second Therefore some latitude is allowed in a standard value The value must be updated at a frequency of at least 30 times per second i e at most five low order bits of the value may be undefined The origin of the value must be within a few minutes of midnight i e the accuracy with which operators customarily set CPU clocks To meet the second condition for a stand alone gateway it will be necessary to query some time server host when the gateway is booted or restarted It is recommended that the UDP Time Server Protocol 44 be used for this purpose A more advanced implementation would use NTP Network Time Protocol 45 to achieve nearly millisecond clock synchronization however this is not required Even if a gateway is unable to establish its time origin it ought to provide a non standard timestamp value i e with the non standard bit set as a time in milliseconds from system startup Braden Postel Page 18 RFC 1009 Requirements for Internet Gateways June 1987 New gateways especially those expecting to operate at T1 or higher speeds are expected to have at least millisecond clocks 2 2 8 Information Request Reply The Information Request Reply pair was intended to support self configuring systems such as diskless workstations to allow them to discover their IP network numbers at boot time However the Reverse ARP RARP protocol 15 provides a better mechanism for a host to use to discover its own IP address and RARP is recommended for this purpose Information Request Reply need not be implemented in a gateway 2 2 9 Echo Request Reply A gateway must implement ICMP Echo since it has proven to be an extremely useful diagnostic tool A gateway must be prepared to receive reassemble and echo an ICMP Echo Request datagram at least as large as the maximum of 576 and the MTU s of all of the connected networks See the discussion of IP reassembly in gateways Section 2 1 The following rules resolve the question of the use of IP source routes in Echo Request and Reply datagrams Suppose a gateway D receives an ICMP Echo Request addressed to itself from host S 1 If the Echo Request contained no source route D should send an Echo Reply back to S using its normal routing rules As a result the Echo Reply may take a different path than the Request however in any case the pair will sample the complete round trip path which any other higher level protocol e g TCP would use for its data and ACK segments between S and D 2 If the Echo Request did contain a source route D should send an Echo Reply back to S using as a source route the return route built up in the source routing option of the Echo Request Braden Postel Page 19 RFC 1009 Requirements for Internet Gateways June 1987 2 3 Exterior Gateway Protocol EGP EGP is the protocol used to exchange reachability information between Autonomous Systems of gateways and is defined in RFC 904 11 See also RFC 827 51 RFC 888 46 and RFC 975 27 for background information The most widely used EGP implementation is described in RFC 911 13 When a dynamic routing algorithm is operated in the gateways of an Autonomous System AS the routing data base must be coupled to the EGP implementation This coupling should ensure that when a net is determined to be unreachable by the routing algorithm the net will not be declared reachable to other ASs via EGP This requirement is designed to minimize spurious traffic to black holes and to ensure fair utilization of the resources on other systems The present EGP specification defines a model with serious limitations most importantly a restriction against propagating third party EGP information in order to prevent long lived routing loops 27 This effectively limits EGP to a two level hierarchy the top level is formed by the core AS while the lower level is composed of those ASs which are direct neighbor gateways to the core AS In practice in the current Internet nearly all of the core gateways are connected to the ARPANET while the lower level is composed of those ASs which are directly gatewayed to the ARPANET or MILNET RFC 975 27 suggested one way to generalize EGP to lessen these topology restrictions it has not been adopted as an official specification although its ideas are finding their way into the new EGP developments There are efforts underway in the research community to develop an EGP generalization which will remove these restrictions In EGP there is no standard interpretation i e metric for the distance fields in the update messages so distances are comparable only among gateways of the same AS In using EGP data a gateway should compare the distances among gateways of the same AS and prefer a route to that gateway which has the smallest distance value The values to be announced in the distance fields for particular networks within the local AS should be a gateway configuration parameter by suitable choice of these values it will be possible to arrange primary and backup paths from other AS s There are other EGP parameters such as polling intervals which also need to be set in the gateway configuration Braden Postel Page 20 RFC 1009 Requirements for Internet Gateways June 1987 When routing updates become large they must be transmitted in parts One strategy is to use IP fragmentation another is to explicitly send the routing information in sections The Internet Engineering Task Force is currently preparing a recommendation on this and other EGP engineering issues 2 4 Address Resolution Protocol ARP ARP is an auxiliary protocol used to perform dynamic address translation between LAN hardware addresses and Internet addresses and is described in RFC 826 4 ARP depends upon local network broadcast In normal ARP usage the initiating host broadcasts an ARP Request carrying a target IP address the corresponding target host recognizing its own IP address sends back an ARP Reply containing its own hardware interface address A variation on this procedure called proxy ARP has been used by gateways attached to broadcast LANs 14 The gateway sends an ARP Reply specifying its interface address in response to an ARP Request for a target IP address which is not on the directly connected network but for which the gateway offers an appropriate route By observing ARP and proxy ARP traffic a gateway may accumulate a routing data base 14 Proxy ARP also known in some quarters as promiscuous ARP or the ARP hack is useful for routing datagrams from hosts which do not implement the standard Internet routing rules fully for example host implementations which predate the introduction of subnetting Proxy ARP for subnetting is discussed in detail in RFC 925 14 Reverse ARP RARP allows a host to map an Ethernet interface address into an IP address 15 RARP is intended to allow a self configuring host to learn its own IP address from a server at boot time 2 5 Constituent Network Access Protocols See Section 3 Braden Postel Page 21 RFC 1009 Requirements for Internet Gateways June 1987 2 6 Interior Gateway Protocols Distributed routing algorithms continue to be the subject of research and engineering and it is likely that advances will be made over the next several years A good algorithm needs to respond rapidly to real changes in Internet connectivity yet be stable and insensitive to transients It needs to synchronize the distributed data base across gateways of its Autonomous System rapidly to avoid routing loops while consuming only a small fraction of the available bandwidth Distributed routing algorithms are commonly broken down into the following three components A An algorithm to assign a length to each Internet path The length may be a simple count of hops 1 or infinity if the path is broken or an administratively assigned cost or some dynamically measured cost usually an average delay In order to determine a path length each gateway must at least test whether each of its neighbors is reachable for this purpose there must be a reachability or neighbor up down protocol B An algorithm to compute the shortest path s to a given destination C A gateway gateway protocol used to exchange path length and routing information among gateways The most commonly used IGPs in Internet gateways are as follows 2 6 1 Gateway to Gateway Protocol GGP GGP was designed and implemented by BBN for the first experimental Internet gateways 41 It is still in use in the BBN LSI 11 gateways but is regarded as having serious drawbacks 58 GGP is based upon an algorithm used in the early ARPANET IMPs and later replaced by SPF see below GGP is a min hop algorithm i e its length measure is simply the number of network hops between gateway pairs It implements a distributed shortest path algorithm which requires global convergence of the routing tables after a change in topology or connectivity Each gateway sends a GGP Braden Postel Page 22 RFC 1009 Requirements for Internet Gateways June 1987 routing update only to its neighbors but each update includes an entry for every known network where each entry contains the hop count from the gateway sending the update 2 6 2 Shortest Path First SPF Protocols SPF 40 is the name for a class of routing algorithms based on a shortest path algorithm of Dijkstra The current ARPANET routing algorithm is SPF and the BBN Butterfly gateways also use SPF Its characteristics are considered superior to GGP 58 Under SPF the routing data base is replicated rather than distributed Each gateway will have its own copy of the same data base containing the entire Internet topology and the lengths of every path Since each gateway has all the routing data and runs a shortest path algorithm locally there is no problem of global convergence of a distributed algorithm as in GGP To build this replicated data base a gateway sends SPF routing updates to ALL other gateways these updates only list the distances to each of the gateway s neighbors making them much smaller than GGP updates The algorithm used to distribute SPF routing updates involves reliable flooding 2 6 3 Routing Information RIP RIP is the name often used for a class of routing protocols based upon the Xerox PUP and XNS routing protocols These are relatively simple and are widely available because they are incorporated in the embedded gateway code of Berkeley BSD systems Because of this simplicity RIP protocols have come the closest of any to being an Open IGP i e a protocol which can be used between different vendors gateways Unfortunately there is no standard and in fact not even a good document for RIP As in GGP gateways using RIP periodically broadcast their routing data base to their neighbor gateways and use a hop count as the metric A fixed value of the hop count normally 16 is defined to be infinity i e network unreachable A RIP implementation must include measures to avoid both the slow convergence phenomen called counting to infinity and the formation of routing loops One such measure is a hold down rule This rule establishes a period of time typically 60 seconds during which a gateway will ignore new routing information about a given network once the gateway has learned that network is Braden Postel Page 23 RFC 1009 Requirements for Internet Gateways June 1987 unreachable has hop count infinity The hold down period must be settable in the gateway configuration if gateways with different hold down periods are using RIP in the same Autonomous System routing loops are a distinct possibility In general the hold down period is chosen large enough to allow time for unreachable status to propagate to all gateways in the AS 2 6 4 Hello The Fuzzball software for an LSI 11 developed by Dave Mills incorporated an IGP called the Hello protocol 39 This IGP is mentioned here because the Fuzzballs have been widely used in Internet experimentation and because they have served as a testbed for many new routing ideas 2 7 Monitoring Protocols See Section 5 of this document 2 8 Internet Group Management Protocol IGMP An extension to the IP protocol has been defined to provide Internet wide multicasting i e delivery of copies of the same IP datagram to a set of Internet hosts 47 48 This delivery is to be performed by processes known as multicasting agents which reside either in a host on each net or preferably in the gateways The set of hosts to which a datagram is delivered is called a host group and there is a host agent protocol called IGMP which a host uses to join leave or create a group Each host group is distinguished by a Class D IP address This multicasting mechanism and its IGMP protocol are currently experimental implementation in vendor gateways would be premature at this time A datagram containing a Class D IP address must be dropped with no ICMP error message Braden Postel Page 24 RFC 1009 Requirements for Internet Gateways June 1987 3 Constituent Network Interface This section discusses the rules used for transmission of IP datagrams on the most common types of constituent networks A gateway must be able to send and receive IP datagrams of any size up to the MTU of any constituent network to which it is connected 3 1 Public data networks via X 25 The formats specified for public data networks accessed via X 25 are described in RFC 877 8 Datagrams are transmitted over standard level 3 virtual circuits as complete packet sequences Virtual circuits are usually established dynamically as required and time out after a period of no traffic Link level retransmission resequencing and flow control are performed by the network for each virtual circuit and by the LAPB link level protocol Note that a single X 25 virtual circuit may be used to multiplex all IP traffic between a pair of hosts However multiple parallel virtual circuits may be used in order to improve the utilization of the subscriber access line in spite of small X 25 window sizes this can result in random resequencing The correspondence between Internet and X 121 addresses is usually established by table lookup It is expected that this will be replaced by some sort of directory procedure in the future The table of the hosts on the Public Data Network is in the Assigned Numbers 23 The normal MTU is 576 however the two DTE s hosts or gateways can use X 25 packet size negotiation to increase this value 8 3 2 ARPANET via 1822 LH DH or HDH The formats specified for ARPANET networks using 1822 access are described in BBN Report 1822 3 which includes the procedures for several subscriber access methods The Distant Host DH method is used when the host and IMP the Defense Communication Agency calls it a Packet Switch Node or PSN are separated by not more than about 2000 feet of cable while the HDLC Distant Host HDH is used for greater distances where a modem is required Under HDH retransmission resequencing and flow control are performed by the network and by the HDLC link level protocol The IP encapsulation format is simply to include the IP datagram as the data portion of an 1822 message In addition the high order 8 bits of the Message Id field also known as the link field should be set to 155 23 The MTU is 1007 octets Braden Postel Page 25 RFC 1009 Requirements for Internet Gateways June 1987 While the ARPANET 1822 protocols are widely used at present they are expected to be eventually overtaken by the DDN Standard X 25 protocol see Section 3 3 The original IP address mapping RFC 796 38 is in the process of being replaced by a new interface specification called AHIP E see RFC 1005 61 for the proposal Gateways connected to ARPANET or MILNET IMPs using 1822 access must incorporate features to avoid host port blocking i e RFNM counting and to detect and report as ICMP Unreachable messages the failure of destination hosts or gateways i e convert the 1822 error messages to the appropriate ICMP messages In the development of a network interface it will be useful to review the IMP end to end protocol described in RFC 979 29 3 3 ARPANET via DDN Standard X 25 The formats specified for ARPANET networks via X 25 are described in the Defense Data Network X 25 Host Interface Specification 6 which describes two sets of procedures the DDN Basic X 25 and the DDN Standard X 25 Only DDN Standard X 25 provides the functionality required for interoperability assumptions of the Internet protocol The DDN Standard X 25 procedures are similar to the public data network X 25 procedures except in the address mappings Retransmission resequencing and flow control are performed by the network and by the LAPB link level protocol Multiple parallel virtual circuits may be used in order to improve the utilization of the subscriber access line this can result in random resequencing Gateways connected to ARPANET or MILNET using Standard X 25 access must detect and report as ICMP Unreachable messages the failure of destination hosts or gateways i e convert the X 25 diagnostic codes to the appropriate ICMP messages To achieve compatibility with 1822 interfaces the effective MTU for a Standard X 25 interface is 1007 octets Braden Postel Page 26 RFC 1009 Requirements for Internet Gateways June 1987 3 4 Ethernet and IEEE 802 The formats specified for Ethernet networks are described in RFC 894 10 Datagrams are encapsulated as Ethernet packets with 48 bit source and destination address fields and a 16 bit type field the type field values are listed in the Assigned Numbers 23 Address translation between Ethernet addresses and Internet addresses is managed by the Address Resolution Protocol which is required in all Ethernet implementations There is no explicit link level retransmission resequencing or flow control although most hardware interfaces will retransmit automatically in case of collisions on the cable The IEEE 802 networks use a Link Service Access Point LSAP field in much the same way the ARPANET uses the link field Further there is an extension of the LSAP header called the Sub Network Access Protocol SNAP The 802 2 encapsulation is used on 802 3 802 4 and 802 5 network by using the SNAP with an organization code indicating that the following 16 bits specify the Ether Type code 23 Headers MAC Header Length 802 3 4 5 MAC DSAP K1 SSAP K1 control 802 2 SAP protocol id or org code K2 Ether Type 802 2 SNAP The total length of the SAP Header and the SNAP header is 8 octets making the 802 2 protocol overhead come out on a 64 bit boundary K1 is 170 The IEEE likes to talk about things in bit transmission order and specifies this value as 01010101 In big endian order as used in the Internet specifications this becomes 10101010 binary or AA hex or 170 decimal K2 is 0 zero The use of the IP LSAP K1 6 is reserved for future development Braden Postel Page 27 RFC 1009 Requirements for Internet Gateways June 1987 The assigned values for the Ether Type field are the same for either this IEEE 802 encapsulation or the basic Ethernet encapsulation 10 In either Ethernets or IEEE 802 nets the IP datagram is the data portion of the packet immediately following the Ether Type The MTU for an Ethernet or its IEEE standard equivalent 802 3 is 1500 octets 3 5 Serial Line Protocols In some configurations gateways may be interconnected with each other by means of serial asynchronous or synchronous lines with or without modems When justified by the expected error rate and other factors a link level protocol may be required on the serial line While there is no single Internet standard for this protocol it is suggested that one of the following protocols be used X 25 LAPB Synchronous Lines This is the link level protocol used for X 25 network access It includes HDLC bit stuffing as well as rotating window flow control and reliable delivery A gateway must be configurable to play the role of either the DCE or the DTE HDLC Framing Synchronous Lines This is just the bit stuffing and framing rules of LAPB It is the simplest choice although it provides no flow control or reliable delivery however it does provide error detection Xerox Synchronous Point to Point Synchronous Lines This Xerox protocol is an elaboration upon HDLC framing that includes negotiation of maximum packet sizes dial up or dedicated circuits and half or full duplex operation 12 Serial Line Framing Protocol Asynchronous Lines This protocol is included in the MIT PC IP package for an IBM PC and is defined in Appendix I to the manual for that system 20 Braden Postel Page 28 RFC 1009 Requirements for Internet Gateways June 1987 It will be important to make efficient use of the bandwidth available on a serial line between gateways For example it is desirable to provide some form of data compression One possible standard compression algorithm Thinwire II is described in RFC 914 42 This and similar algorithms are tuned to the particular types of redundancy which occur in IP and TCP headers however more work is necessary to define a standard serial line compression protocol for Internet gateways Until a standard has been adopted each vendor is free to choose a compression algorithm of course the result will only be useful on a serial line between two gateways using the same compression algorithm Another way to ensure maximum use of the bandwidth is to avoid unnecessary retransmissions at the link level For some kinds of IP traffic low delay is more important than reliable delivery The serial line driver could distinguish such datagrams by their IP TOS field and place them on a special high priority no retransmission queue A serial point to point line between two gateways may be considered to be a particularly simple network a null net Considered in this way a serial line requires no special considerations in the routing algorithms of the connected gateways but does need an IP network number To avoid the wholesale consumption of Internet routing data base space by null nets we strongly recommend that subnetting be used for null net numbering whenever possible For example assume that network 128 203 is to be constructed of gateways joined by null nets these nets are given sub net numbers 128 203 1 128 203 2 etc and the two interfaces on each end of null net 128 203 s might have IP addresses 128 203 s 1 and 128 203 s 2 An alternative model of a serial line is that it is not a network but rather an internal communication path joining two half gateways It is possible to design an IGP and routing algorithm that treats a serial line in this manner 39 52 Braden Postel Page 29 RFC 1009 Requirements for Internet Gateways June 1987 4 Gateway Algorithms Gateways are general packet switches that forward packets according to the IP address i e they are IP routers While it is beyond the scope of this document to specify the details of the mechanisms used in any particular perhaps proprietary gateway architecture there are a number of basic algorithms which must be provided by any acceptable design 4 1 Routing Algorithm The routing mechanism is fundamental to Internet operation In all but trivial network topologies robust Internet service requires some degree of routing dynamics whether it be effected by manual or automatic means or by some combination of both In particular if routing changes are made manually it must be possible to make these routing changes from a remote Network Operation Center NOC without taking down the gateway for reconfiguration If static routes are used there must be automatic fallback or rerouting features Handling unpredictable changes in Internet connectivity must be considered the normal case so that systems of gateways will normally be expected to have a routing algorithm with the capability of reacting to link and other gateway failures and changing the routing automatically This document places no restriction on the type of routing algorithm e g node based link based or any other algorithm or on the routing distance metric e g delay or hop count However the following features are considered necessary for a successful gateway routing algorithm 1 The algorithm must sense the failure or restoration of a link or other gateway and switch to appropriate paths A design objective is to switch paths within an interval less than the typical TCP user time out one minute is a safe assumption 2 The algorithm must suppress routing loops between neighbor gateways and must contain provisions to avoid or suppress routing loops that may form between non neighbor gateways A design objective is for no loop to persist for longer than an interval greater than the typical TCP user time out 3 The control traffic necessary to operate the routing algorithm must not significantly degrade or disrupt normal Braden Postel Page 30 RFC 1009 Requirements for Internet Gateways June 1987 network operation Changes in state which might momentarily disrupt normal operation in a local area must not cause disruption in remote areas of the network 4 As the size of the network increases the demand on resources must be controlled in an efficient way Table lookups should be hashed for example and data base updates handled piecemeal with only incremental changes broadcast over a wide area 5 The size of the routing data base must not be allowed to exceed a constant independent of network topology times the number of nodes times the mean connectivity average number of incident links An advanced design might not require that the entire routing data base be kept in any particular gateway so that discovery and caching techniques would be necessary 6 Reachability and delay metrics if used must not depend on direct connectivity to all other gateways or on the use of network specific broadcast mechanisms Polling procedures e g for consistency checking must be used only sparingly and in no case introduce an overhead exceeding a constant independent of network topology times the longest non looping path 7 Default routes generally intended as a means to reduce the size of the routing data base must be used with care because of the many problems with multiple paths loops and mis configurations which routing defaults have caused The most common application of defaults is for routing within an Internet region which is connected in a strictly hierarchical fashion and is a stub from the rest of the Internet system In this case the default is used for routing up the tree Unfortunately such restricted topology seldom lasts very long and defaults cease to work More generally defaults could be used for initial routing guesses with final routes to be discovered and cached from external or internal data bases via the routing algorithm or EGP Braden Postel Page 31 RFC 1009 Requirements for Internet Gateways June 1987 4 2 Subnets and Routing We will call a gateway subnetted if at least one of its interfaces is connected to a subnet the set of gateways directly connected to subnets of the same network will be referred to as a subnet cluster For example in the following diagram network 2 is subnetted with subnets 2 1 and 2 2 but network 1 is not gateways 1 2 and 3 are subnetted and are members of the same subnet cluster Net 1 Gwy 1 Net 2 1 Gwy 2 Net 2 2 Gwy 3 Subnets have the following effects on gateway routing A Non subnetted gateways are not affected at all B The routing data base in a subnetted gateway must consider the address mask for subnet entries C Routing updates among the gateways in the same subnet cluster must include entries for the various subnets The corresponding address mask s may be implicit but for full generality the mask needs to be given explicitly for each entry Note that if the routing data base included a full 32 bit mask for every IP network the gateway could deal with networks and subnets in a natural way This would also handle the case of multiple subnet masks for the same subnetted network D Routing updates from a subnetted gateway to a gateway outside the cluster can contain nets never subnets E If a subnetted gateway e g gateway 2 above is unable to forward a datagram from one subnet to another subnet of the same network then it must return a Host Unreachable not a Net Unreachable as discussed in Section 2 2 1 When considering the choice of routing protocol a gateway builder must consider how that protocol generalizes for subnets For some routing protocols it will be possible to use the same procedures in a regular gateway and a subnetted gateway with only a change of parameters e g address masks A different subnet address mask must be configurable for each Braden Postel Page 32 RFC 1009 Requirements for Internet Gateways June 1987 interface of a given gateway This will allow a subnetted gateway to connect to two different subnetted networks or to connect two subnets of the same network with different masks 4 3 Resource Allocation In order to perform its basic datagram forwarding functions a gateway must allocate resources its packet buffers and CPU time must be allocated to packets it receives from connected networks while the bandwidth to each of the networks must also be allocated for sending packets The choice of allocation strategies will be critical when a particular resource is scarce The most obvious allocation strategy first come first served FCFS may not be appropriate under overload conditions for reasons which we will now explore A first example is buffer allocation It is important for a gateway to allocate buffers fairly among all of its connected networks even if these networks have widely varying bandwidths A high speed interface must not be allowed to starve slower interfaces of buffers For example consider a gateway with a 10 Mbps Ethernet connection and two 56 Kbps serial lines A buggy host on the Ethernet may spray that gateway interface with packets at high speed Without careful algorithm design in the gateway this could tie up all the gateway buffers in such a way that transit traffic between the serial lines would be completely stopped Allocation of output bandwidth may also require non FCFS strategies In an advanced gateway design allocation of output bandwidth may depend upon Type of Service bits in the IP headers A gateway may also want to give priority to datagrams for its own up down and routing protocols Finally Nagle 24 has suggested that gateways implement fair queueing i e sharing output bandwidth equitably among the current traffic sources In his scheme for each network interface there would be a dynamically built set of output queues one per IP source address these queues would be serviced in a round robin fashion to share the bandwidth If subsequent research shows fair queueing to be desirable it will be added to a future version of this document as a universal requirement Braden Postel Page 33 RFC 1009 Requirements for Internet Gateways June 1987 4 4 Special Addresses and Filters Section 2 1 contained a list of the 32 bit IP addresses which have special meanings They do not in general represent unique IP addresses of Internet hosts and there are restrictions on their use in IP headers We can distinguish two classes of these special cases The first class specifically cases a b c g h and i in section 2 1 contains addresses which should never appear in the destination address field of any IP datagram so a gateway should never be asked to route to one of these addresses However in the real world of imperfect implementations and configuration errors such bad destination addresses do occur It is the responsibility of a gateway to avoid propagating such erroneous addresses this is especially important for gateways included in the global interconnect system In particular a gateway which receives a datagram with one of these forbidden addresses should 1 Avoid inserting that address into its routing database and avoid including it in routing updates to any other gateway 2 Avoid forwarding a datagram containing that address as a destination To enforce these restrictions it is suggested that a gateway include a configurable filter for datagrams and routing updates A typical filter entry might consist of a 32 bit mask and value pair If the logical AND of the given address with the mask equals the value a match has been found Since filtering will consume gateway resources it is vital that the gateway configuration be able to control the degree of filtering in use There is a second class of special case addresses cases d e and f in section 2 1 the so called directed broadcasts A directed broadcast is a datagram to be forwarded normally to the specified destination sub net and then broadcast on the final hop An Internet gateway is permitted but not required to filter out directed broadcasts destined for any of its locally connected networks Hence it should be possible to configure the filter to block the delivery of directed broadcasts Finally it will also be useful for Internet O M to have a configurable filter on the IP source address This will allow a network manager to temporarily block traffic from a particular misbehaving host for example Braden Postel Page 34 RFC 1009 Requirements for Internet Gateways June 1987 4 5 Redirects The ICMP Redirect message is specified only for use by a gateway to update the routing table of a host on the same connected net However the Redirect message is sometimes used between gateways due to the following considerations The routing function in a host is very much like that in a dumb gateway i e a gateway having only static routes It is desirable to allow the routing tables of a dumb gateway to be changed under the control of a dynamic gateway i e a gateway with full dynamic routing on the same network By analogy it is natural to let the dynamic gateway send ICMP Redirect messages to dumb gateway The use of ICMP Redirect between gateways in this fashion may be considered to be part of the IGP in fact the totality of the IGP as far as the dumb gateway is concerned in the particular Autonomous System Specification of an IGP is outside the scope of this document so we only note the possibility of using Redirect in this fashion Gateways are not required to receive and act upon redirects and in fact dynamic gateways must ignore them We also note that considerable experience shows that dumb gateways often create problems resulting in black holes a full routing gateway is always preferable Routing table entries established by redirect messages must be removed automatically either by a time out or when a use count goes to zero 4 6 Broadcast and Multicast A host which is connected to a network generally a LAN

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1009.txt (2016-02-14)
    Open archived version from archive


  • separate entities In the absence of NetBIOS name information a NetBIOS datagram distribution server must send a copy to each end node within a NetBIOS scope An implementer may elect to construct NBNS and NBDD nodes which have a private protocol for the exchange of NetBIOS name information Alternatively an NBNS and NBDD may be implemented within the same device NOTE Implementations containing private NBNS NBDD protocols or combined NBNS NBDD functions must be clearly identified 11 4 RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES As defined in this RFC neither NBNS nor NBDD nodes interact with B nodes NetBIOS servers do not listen to broadcast traffic on any broadcast area to which they may be attached Nor are the NetBIOS support servers even aware of B node activities or names claimed or used by B nodes It may be possible to extend both the NBNS and NBDD so that they participate in B node activities and act as a bridge to P and M nodes However such extensions are beyond the scope of this specification 12 TOPOLOGIES B P M NBNS and NBDD nodes may be combined in various ways to form useful NetBIOS environments This section describes some of these combinations There are three classes of operation Class 0 B nodes only Class 1 P nodes only Class 2 P and M nodes together In the drawings which follow any P node may be replaced by an M node The effects of such replacement will be mentioned in conjunction with each example below 12 1 LOCAL A NetBIOS scope is operating locally when all entities are within the same broadcast area NetBIOS Working Group Page 20 RFC 1001 March 1987 12 1 1 B NODES ONLY Local operation with only B nodes is the most basic mode of operation Name registration and discovery procedures use broadcast mechanisms The NetBIOS scope is limited by the extent of the broadcast area This configuration does not require NetBIOS support servers BROADCAST AREA B B B B B 12 1 2 P NODES ONLY This configuration would typically be used when the network administrator desires to eliminate NetBIOS as a source of broadcast activity B CAST AREA P P NBNS P NBDD P This configuration operates the same as if it were in an internet and is cited here only due to its convenience as a means to reduce the use of broadcast Replacement of one or more of the P nodes with M nodes will not affect the operation of the other P and M nodes P and M nodes will be able to interact with one another Because M nodes use broadcast overall broadcast activity will increase 12 1 3 MIXED B AND P NODES B and P nodes do not interact with one another Replacement of P nodes with M nodes will allow B s and M s to interact NOTE B nodes and M nodes may be intermixed only on a local broadcast area B and M nodes should not be intermixed in an internet environment NetBIOS Working Group Page 21 RFC 1001 March 1987 12 2 INTERNET 12 2 1 P NODES ONLY P nodes may be scattered at various locations in an internetwork They require both an NBNS and an NBDD for NetBIOS name and datagram support respectively The NetBIOS scope is determined by the NetBIOS scope identifier domain name used by the various P and M nodes An internet may contain numerous NetBIOS scopes P P P INTERNET G WAY P P NBNS NBDD Any P node may be replaced by an M node with no loss of function to any node However broadcast activity will be increased in the broadcast area to which the M node is attached NetBIOS Working Group Page 22 RFC 1001 March 1987 12 2 2 MIXED M AND P NODES M and P nodes may be mixed When locating NetBIOS names M nodes will tend to find names held by other M nodes on the same common broadcast area in preference to names held by P nodes or M nodes elsewhere in the network P P INTERNET NBDD NBNS G WAY B CAST AREA M P M P M P NOTE B and M nodes should not be intermixed in an internet environment Doing so would allow undetected NetBIOS name conflicts to arise and cause unpredictable behavior 13 GENERAL METHODS Overlying the specific protocols described later are a few general methods of interaction between entities 13 1 REQUEST RESPONSE INTERACTION STYLE Most interactions between entities consist of a request flowing in one direction and a subsequent response flowing in the opposite direction In those situations where interactions occur on unreliable transports i e UDP or when a request is broadcast there may not be a strict interlocking or one to one relationship between requests and responses NetBIOS Working Group Page 23 RFC 1001 March 1987 In no case however is more than one response generated for a received request While a response is pending the responding entity may send one or more wait acknowledgements 13 1 1 RETRANSMISSION OF REQUESTS UDP is an unreliable delivery mechanism where packets can be lost received out of transmit sequence duplicated and delivery can be significantly delayed Since the NetBIOS protocols make heavy use of UDP they have compensated for its unreliability with extra mechanisms Each NetBIOS packet contains all the necessary information to process it None of the protocols use multiple UDP packets to convey a single request or response If more information is required than will fit in a single UDP packet for example when a P type node wants all the owners of a group name from a NetBIOS server a TCP connection is used Consequently the NetBIOS protocols will not fail because of out of sequence delivery of UDP packets To overcome the loss of a request or response packet each request operation will retransmit the request if a response is not received within a specified time limit Protocol operations sensitive to successive response packets such as name conflict detection are protected from duplicated packets because they ignore successive packets with the same NetBIOS information Since no state on the responder s node is associated with a request the responder just sends the appropriate response whenever a request packet arrives Consequently duplicate or delayed request packets have no impact For all requests if a response packet is delayed too long another request packet will be transmitted A second response packet being sent in response to the second request packet is equivalent to a duplicate packet Therefore the protocols will ignore the second packet received If the delivery of a response is delayed until after the request operation has been completed successfully or not the response packet is ignored 13 1 2 REQUESTS WITHOUT RESPONSES DEMANDS Some request types do not have matching responses These requests are known as demands In general a demand is an imperative request the receiving node is expected to obey However because demands are unconfirmed they are used only in situations where at most limited damage would occur if the demand packet should be lost Demand packets are not retransmitted NetBIOS Working Group Page 24 RFC 1001 March 1987 13 2 TRANSACTIONS Interactions between a pair of entities are grouped into transactions These transactions comprise one or more request response pairs 13 2 1 TRANSACTION ID Since multiple simultaneous transactions may be in progress between a pair of entities a transaction id is used The originator of a transaction selects an ID unique to the originator The transaction id is reflected back and forth in each interaction within the transaction The transaction partners must match responses and requests by comparison of the transaction ID and the IP address of the transaction partner If no matching request can be found the response must be discarded A new transaction ID should be used for each transaction A simple 16 bit transaction counter ought to be an adequate id generator It is probably not necessary to search the space of outstanding transaction ID to filter duplicates it is extremely unlikely that any transaction will have a lifetime that is more than a small fraction of the typical counter cycle period Use of the IP addresses in conjunction with the transaction ID further reduces the possibility of damage should transaction IDs be prematurely re used 13 3 TCP AND UDP FOUNDATIONS This version of the NetBIOS over TCP protocols uses UDP for many interactions In the future this RFC may be extended to permit such interactions to occur over TCP connections perhaps to increase efficiency when multiple interactions occur within a short time or when NetBIOS datagram traffic reveals that an application is using NetBIOS datagrams to support connection oriented service 14 REPRESENTATION OF NETBIOS NAMES NetBIOS names as seen across the client interface to NetBIOS are exactly 16 bytes long Within the NetBIOS over TCP protocols a longer representation is used There are two levels of encoding The first level maps a NetBIOS name into a domain system name The second level maps the domain system name into the compressed representation required for interaction with the domain name system Except in one packet the second level representation is the only NetBIOS name representation used in NetBIOS over TCP packet formats The exception is the RDATA field of a NODE STATUS RESPONSE packet NetBIOS Working Group Page 25 RFC 1001 March 1987 14 1 FIRST LEVEL ENCODING The first level representation consists of two parts NetBIOS name NetBIOS scope identifier The 16 byte NetBIOS name is mapped into a 32 byte wide field using a reversible half ASCII biased encoding Each half octet of the NetBIOS name is encoded into one byte of the 32 byte field The first half octet is encoded into the first byte the second half octet into the second byte etc Each 4 bit half octet of the NetBIOS name is treated as an 8 bit right adjusted zero filled binary number This number is added to value of the ASCII character A hexidecimal 41 The resulting 8 bit number is stored in the appropriate byte The following diagram demonstrates this procedure 0 1 2 3 4 5 6 7 a b c d w x y z ORIGINAL BYTE SPLIT THE NIBBLES v v 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 0 0 0 a b c d 0 0 0 0 w x y z ADD A 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 0 0 0 0 0 1 0 1 0 0 0 0 0 1 This encoding results in a NetBIOS name being represented as a sequence of 32 ASCII upper case characters from the set A B C N O P The NetBIOS scope identifier is a valid domain name without a leading dot An ASCII dot 2E hexidecimal and the scope identifier are appended to the encoded form of the NetBIOS name the result forming a valid domain name NetBIOS Working Group Page 26 RFC 1001 March 1987 For example the NetBIOS name The NetBIOS name in the NetBIOS scope SCOPE ID COM would be represented at level one by the ASCII character string FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF SCOPE ID COM 14 2 SECOND LEVEL ENCODING The first level encoding must be reduced to second level encoding This is performed according to the rules defined in on page 31 of RFC 883 12 in the section on Domain name representation and compression Also see the section titled Name Formats in the Detailed Specifications 1 15 NetBIOS NAME SERVICE Before a name may be used the name must be registered by a node Once acquired the name must be defended against inconsistent registration by other nodes Before building a NetBIOS session or sending a NetBIOS datagram the one or more holders of the name must be located The NetBIOS name service is the collection of procedures through which nodes acquire defend and locate the holders of NetBIOS names The name service procedures are different depending whether the end node is of type B P or M 15 1 OVERVIEW OF NetBIOS NAME SERVICE 15 1 1 NAME REGISTRATION CLAIM Each NetBIOS node can own more than one name Names are acquired dynamically through the registration name claim procedures Every node has a permanent unique name This name like any other name must be explicitly registered by all end node types A name can be unique exclusive or group non exclusive A unique name may be owned by a single node a group name may be owned by any number of nodes A name ceases to exist when it is not owned by at least one node There is no intrinsic quality of a name which determines its characteristics these are established at the time of registration Each node maintains state information for each name it has registered This information includes Whether the name is a group or unique name Whether the name is in conflict Whether the name is in the process of being deleted NetBIOS Working Group Page 27 RFC 1001 March 1987 B nodes perform name registration by broadcasting claim requests soliciting a defense from any node already holding the name P nodes perform name registration through the agency of the NBNS M nodes register names through an initial broadcast like B nodes then in the absence of an objection by following the same procedures as a P node In other words the broadcast action may terminate the attempt but is not sufficient to confirm the registration 15 1 2 NAME QUERY DISCOVERY Name query also known as resolution or discovery is the procedure by which the IP address es associated with a NetBIOS name are discovered Name query is required during the following operations During session establishment calling and called names must be specified The calling name must exist on the node that posts the CALL The called name must exist on a node that has previously posted a LISTEN Either name may be a unique or group name When a directed datagram is sent a source and destination name must be specified If the destination name is a group name a datagram is sent to all the members of that group Different end node types perform name resolution using different techniques but using the same packet formats B nodes solicit name information by broadcasting a request P nodes ask the NBNS M nodes broadcast a request If that does not provide the desired information an inquiry is sent to the NBNS 15 1 3 NAME RELEASE NetBIOS names may be released explicitly or silently by an end node Silent release typically occurs when an end node fails or is turned off Most of the mechanisms described below are present to detect silent name release 15 1 3 1 EXPLICIT RELEASE B nodes explicitly release a name by broadcasting a notice P nodes send a notification to their NBNS M nodes both broadcast a notice and inform their supporting NBNS NetBIOS Working Group Page 28 RFC 1001 March 1987 15 1 3 2 NAME LIFETIME AND REFRESH Names held by an NBNS are given a lifetime during name registration The NBNS will consider a name to have been silently released if the end node fails to send a name refresh message to the NBNS before the lifetime expires A refresh restarts the lifetime clock NOTE The implementor should be aware of the tradeoff between accuracy of the database and the internet overhead that the refresh mechanism introduces The lifetime period should be tuned accordingly For group names each end node must send refresh messages A node that fails to do so will be considered to have silently released the name and dropped from the group The lifetime period is established through a simple negotiation mechanism during name registration In the name registration request the end node proposes a lifetime value or requests an infinite lifetime The NBNS places an actual lifetime value into the name registration response The NBNS is always allowed to respond with an infinite actual period If the end node proposed an infinite lifetime the NBNS may respond with any definite period If the end node proposed a definite period the NBNS may respond with any definite period greater than or equal to that proposed This negotiation of refresh times gives the NBNS means to disable or enable refresh activity The end nodes may set a minimum refresh cycle period NBNS implementations which are completely reliable may disable refresh 15 1 3 3 NAME CHALLENGE To detect whether a node has silently released its claim to a name it is necessary on occasion to challenge that node s current ownership If the node defends the name then the node is allowed to continue possession Otherwise it is assumed that the node has released the name A name challenge may be issued by an NBNS or by a P or M node A challenge may be directed towards any end node type B P or M 15 1 3 4 GROUP NAME FADE OUT NetBIOS groups may contain an arbitrarily large number of members The time to challenge all members could be quite large To avoid long delays when names are claimed through an NBNS an NetBIOS Working Group Page 29 RFC 1001 March 1987 optimistic heuristic has been adopted It is assumed that there will always be some node which will defend a group name Consequently it is recommended that the NBNS will immediately reject a claim request for a unique name when there already exists a group with the same name The NBNS will never return an IP address in response to a NAME REGISTRATION REQUEST when a group name exists An NBNS will consider a group to have faded out of existence when the last remaining member fails to send a timely refresh message or explicitly releases the name 15 1 3 5 NAME CONFLICT Name conflict exists when a unique name has been claimed by more than one node on a NetBIOS network B M and NBNS nodes may detect a name conflict The detection mechanism used by B and M nodes is active only during name discovery The NBNS may detect conflict at any time it verifies the consistency of its name database B and M nodes detect conflict by examining the responses received in answer to a broadcast name query request The first response is taken as authoritative Any subsequent inconsistent responses represent conflicts Subsequent responses are inconsistent with the authoritative response when The subsequent response has the same transaction ID as the NAME QUERY REQUEST AND The subsequent response is not a duplicate of the authoritative response AND EITHER The group unique characteristic of the authoritative response is unique OR The group unique characteristic of the subsequent response is unique The period in which B and M nodes examine responses is limited by a conflict timer CONFLICT TIMER The accuracy or duration of this timer is not crucial the NetBIOS system will continue to operate even with persistent name conflicts Conflict conditions are signaled by sending a NAME CONFLICT DEMAND to the node owning the offending name Nothing is sent to the node which originated the authoritative response Any end node that receives NAME CONFLICT DEMAND is required to update its local name table to reflect that the name is in conflict The local name table on each node contains names that have been NetBIOS Working Group Page 30 RFC 1001 March 1987 successfully registered by that node Notice that only those nodes that receive the name conflict message place a conflict mark next to a name Logically a marked name does not exist on that node This means that the node should not defend the name for name claim purposes should not respond to a name discovery requests for that name nor should the node send name refresh messages for that name Furthermore it can no longer be used by that node for any session establishment or sending or receiving datagrams Existing sessions are not affected at the time a name is marked as being in conflict The only valid user function against a marked name is DELETE NAME Any other user NetBIOS function returns immediately with an error code of NAME CONFLICT 15 1 4 ADAPTER STATUS An end node or the NBNS may ask any other end node for a collection of information about the NetBIOS status of that node This status consists of among other things a list of the names which the node believes it owns The returned status is filtered to contain only those names which have the same NetBIOS scope identifier as the requestor s name When requesting node status the requestor identifies the target node by NetBIOS name A name query transaction may be necessary to acquire the IP address for the name Locally cached name information may be used in lieu of a query transaction The requesting node sends a NODE STATUS REQUEST In response the receiving node sends a NODE STATUS RESPONSE containing its local name table and various statistics The amount of status which may be returned is limited by the size of a UDP packet However this is sufficient for the typical NODE STATUS RESPONSE packet 15 1 5 END NODE NBNS INTERACTION There are certain characteristics of end node to NBNS interactions which are in common and are independent of any particular transaction type 15 1 5 1 UDP TCP AND TRUNCATION For all transactions between an end node and an NBNS either UDP or TCP may be used as a transport If the NBNS receives a UDP based request it will respond using UDP If the amount of information exceeds what fits into a UDP packet the response will contain a truncation flag In this situation the end node may open a TCP NetBIOS Working Group Page 31 RFC 1001 March 1987 connection to the NBNS repeat the request and receive a complete untruncated response 15 1 5 2 NBNS WACK While a name service request is in progress the NBNS may issue a WAIT FOR ACKNOWLEDGEMENT RESPONSE WACK to assure the client end node that the NBNS is still operational and is working on the request 15 1 5 3 NBNS REDIRECTION The NBNS because it follows Domain Name system styles of interaction is permitted to redirect a client to another NBNS 15 1 6 SECURED VERSUS NON SECURED NBNS An NBNS may be implemented in either of two general ways The NBNS may monitor and participate in name activity to ensure consistency This would be a secured style NBNS Alternatively an NBNS may be implemented to be essentially a bulletin board on which name information is posted and responsibility for consistency is delegated to the end nodes This would be a non secured style NBNS 15 1 7 CONSISTENCY OF THE NBNS DATA BASE Even in a properly running NetBIOS scope the NBNS and its community of end nodes may occasionally lose synchronization with respect to the true state of name registrations This may occur should the NBNS fail and lose all or part of its database More commonly a P or M node may be turned off thus forgetting the names it has registered and then be subsequently turned back on Finally errors may occur or an implementation may be incorrect Various approaches have been incorporated into the NetBIOS over TCP protocols to minimize the impact of these problems 1 The NBNS or any other node may challenge using a NAME QUERY REQUEST an end node to verify that it actually owns a name Such a challenge may occur at any time Every end node must be prepared to make a timely response Failure to respond causes the NBNS to consider that the end node has released the name in question NetBIOS Working Group Page 32 RFC 1001 March 1987 If UDP is being used as the underlying transport the challenge like all other requests must be retransmitted some number of times in the absence of a response 2 The NBNS or any other node may request using the NODE STATUS REQUEST that an end node deliver its entire name table This may occur at any time Every end node must be prepared to make a timely response Failure to respond permits but does not require the NBNS to consider that the end node has failed and released all names to which it had claims Like the challenge on a UDP transport the request must be retransmitted in the absence of a response 3 The NBNS may revoke a P or M node s use of a name by sending either a NAME CONFLICT DEMAND or a NAME RELEASE REQUEST to the node The receiving end node may continue existing sessions which use that name but must otherwise cease using that name If the NBNS placed the name in conflict the name may be re acquired only by deletion and subsequent reclamation If the NBNS requested that the name be released the node may attempt to re acquire the name without first performing a name release transaction 4 The NBNS may impose a time to live on each name it registers The registering node is made aware of this time value during the name registration procedure Simple or reliable NBNS s may impose an infinite time to live 5 If an end node holds any names that have finite time to live values then that node must periodically send a status report to the NBNS Each name is reported using the NAME REFRESH REQUEST packet These status reports restart the timers of both the NBNS and the reporting node However the only timers which are restarted are those associated with the name found in the status report Timers on other names are not affected The NBNS may consider that a node has released any name which has not been refreshed within some multiple of name s time to live A well behaved NBNS would however issue a challenge to NetBIOS Working Group Page 33 RFC 1001 March 1987 or request a list of names from the non reporting end node before deleting its name s The absence of a response or of the name in a response will confirm the NBNS decision to delete a name 6 The absence of reports may cause the NBNS to infer that the end node has failed Similarly receipt of information widely divergent from what the NBNS believes about the node may cause the NBNS to consider that the end node has been restarted The NBNS may analyze the situation through challenges or requests for a list of names 7 A very cautious NBNS is free to poll nodes by sending NAME QUERY REQUEST or NODE STATUS REQUEST packets to verify that their name status is the same as that registered in the NBNS NOTE Such polling activity if used at all by an implementation should be kept at a very low level or enabled only during periods when the NBNS has some reason to suspect that its information base is inaccurate 8 P and M nodes can detect incorrect name information at session establishment If incorrect information is found NBNS is informed via a NAME RELEASE REQUEST originated by the end node which detects the error 15 1 8 NAME CACHING An end node may keep a local cache of NetBIOS name to IP address translation entries All cache entries should be flushed on a periodic basis In addition a node ought to flush any cache information associated with an IP address if the node receives any information indicating that there may be any possibility of trouble with the node at that IP address For example if a NAME CONFLICT DEMAND is sent to a node all cached information about that node should be cleared within the sending node 15 2 NAME REGISTRATION TRANSACTIONS 15 2 1 NAME REGISTRATION BY B NODES A name claim transaction initiated by a B node is broadcast throughout the broadcast area The NAME REGISTRATION REQUEST will be NetBIOS Working Group Page 34 RFC 1001 March 1987 heard by all B and M nodes in the area Each node examines the claim to see whether it it is consistent with the names it owns If an inconsistency exists a NEGATIVE NAME REGISTRATION RESPONSE is unicast to the requestor The requesting node obtains ownership of the name or membership in the group if and only if no NEGATIVE NAME REGISTRATION RESPONSEs are received within the name claim timeout CONFLICT TIMER See Defined Constants and Variables in the Detailed Specification for the value of this timer A B node proclaims its new ownership by broadcasting a NAME OVERWRITE DEMAND B NODE REGISTRATION PROCESS REQ NODE NODE REQ NODE HOLDING NAME BROADCAST REGISTER BROADCAST REGISTER OVERWRITE NODE DOES NOT HAVE THE NAME NODE HAS THE NAME The NAME REGISTRATION REQUEST like any request must be repeated if no response is received within BCAST REQ RETRY TIMEOUT Transmission of the request is attempted BCAST REQ RETRY COUNT times 15 2 2 NAME REGISTRATION BY P NODES A name registration may proceed in various ways depending whether the name being registered is new to the NBNS If the name is known to the NBNS then challenges may be sent to the prior holder s 15 2 2 1 NEW NAME OR NEW GROUP MEMBER The diagram below shows the sequence of events when an end node registers a name which is new to the NBNS The diagram omits WACKs NBNS redirections and retransmission of requests This same interaction will occur if the name being registered is a group name and the group already exists The NBNS will add the NetBIOS Working Group Page 35 RFC 1001 March 1987 registrant to the set of group members P NODE REGISTRATION PROCESS server has no previous information about the name P NODE NBNS REGISTER POSITIVE RESPONSE REQ NODE NBNS NODE NBNS REQ NODE HOLDING NAME REGISTER REGISTER POSITIVE RESP QUERY NEGATIVE RESPONSE POSITIVE RESPONSE REQ NODE NBNS NODE NBNS REQ NODE HOLDING NAME REGISTER REGISTER QUERY OVERWRITE POSITIVE RESPONSE REQ NODE NODE REQ NODE HOLDING NAME BROADCAST REGISTER BROADCAST REGISTER NODE DOES NOT HAVE THE NAME INITIATE A P NODE REGISTRATION V 15 3 NAME QUERY TRANSACTIONS Name query transactions are initiated by end nodes to obtain the IP address es and other attributes associated with a NetBIOS name 15 3 1 QUERY BY B NODES The following diagram shows how B nodes go about discovering who owns a name The left half of the diagram illustrates what happens if there are no holders of the name In that case no responses are received in answer to the broadcast NAME QUERY REQUEST s The right half shows a POSITIVE NAME QUERY RESPONSE unicast by a name holder in answer to the broadcast request A name holder will make this response to every NAME QUERY REQUEST that it hears And each holder acts this way Thus the node sending the request may receive many responses some duplicates and from many nodes NetBIOS Working Group Page 39 RFC 1001 March 1987 B NODE DISCOVERY PROCESS REQ NODE NODE REQ NODE HOLDING NAME BROADCAST QUERY BROADCAST QUERY Name query is generally but not necessarily a prelude to NetBIOS session establishment or NetBIOS datagram transmission However name query may be used for other purposes A B node may elect to build a group membership list for subsequent use e g for session establishment by collecting and saving the responses 15 3 2 QUERY BY P NODES An NBNS answers queries from a P node with a list of IP address and other information for each owner of the name If there are multiple owners i e if the name is a group name the NBNS loads as many answers into the response as will fit into a UDP packet A truncation flag indicates whether any additional owner information remains All the information may be obtained by repeating the query over a TCP connection The NBNS is not required to impose any order on its answer list The following diagram shows what happens if the NBNS has no information about the name P NODE DISCOVERY PROCESS server has no information about the name P NODE NBNS NAME QUERY REQUEST NEGATIVE RESPONSE OPTIONAL WACK QUERY OPTIONAL WACK POSITIVE RESPONSE REDIRECT NAME QUERY RESPONSE POSITIVE NAME QUERY RESPONSE QUERY QUERY NAME TAKEN OFF THE DATABASE IF NBNS FINDS IT TO BE INCORRECT POSITIVE NEGATIVE RESPONSE REQ NODE NODE REQ NODE HOLDING NAME BROADCAST QUERY BROADCAST QUERY INITIATE A P NODE DISCOVERY PROCESS V 15 3 4 ACQUIRE GROUP MEMBERSHIP LIST The entire membership of a group may be acquired by sending a NAME QUERY REQUEST to the NBNS The NBNS will respond with a POSITIVE NAME QUERY RESPONSE or a NEGATIVE NAME QUERY RESPONSE A negative response completes the procedure and indicates that there are no members in the group If the positive response has the truncation bit clear then the response contains the entire list of group members If the truncation bit is set then this entire procedure must be repeated but using TCP as a foundation rather than UDP NetBIOS Working Group Page 43 RFC 1001 March 1987 15 4 NAME RELEASE TRANSACTIONS 15 4 1 RELEASE BY B NODES A NAME RELEASE DEMAND contains the following information NetBIOS name The scope of the NetBIOS name Name type unique or group IP address of the releasing node Transaction ID REQUESTING OTHER B NODE B NODES NAME RELEASE DEMAND 15 4 2 RELEASE BY P NODES A NAME RELEASE REQUEST contains the following information NetBIOS name The scope of the NetBIOS name Name type unique or group IP address of the releasing node Transaction ID A NAME RELEASE RESPONSE contains the following information NetBIOS name The scope of the NetBIOS name Name type unique or group IP address of the releasing node Transaction ID Result Yes name was released No name was not released a reason code is provided REQUESTING P NODE NBNS NAME RELEASE REQUEST NAME RELEASE RESPONSE REQUESTING NBNS REQUESTING NBNS M NODE M NODE NAME RELEASE REQUEST NAME RELEASE REQUEST NEGATIVE RELEASE RESPONSE POSITIVE RELEASE RESPONSE 15 5 NAME MAINTENANCE TRANSACTIONS 15 5 1 NAME REFRESH Name refresh transactions are used to handle the following situations a An NBNS node needs to detect if a P or M node has silently gone down so that names held by that node can be purged from the data base b If the NBNS goes down it needs to be able to reconstruct the data base when it comes back up c If the network should be partitioned the NBNS needs to be able to able to update its data base when the network reconnects Each P or M node is responsible for sending periodic NAME REFRESH REQUESTs for each name that it has registered Each refresh packet contains a single name that has been successfully registered by that NetBIOS Working Group Page 45 RFC 1001 March 1987 node The interval between such packets is negotiated between the end node and the NBNS server at the time that the name is initially claimed At name claim time an end node will suggest a refresh timeout value The NBNS node can modify this value in the reply packet A NBNS node can also choose to tell the end node to not send any refresh packet by using the infinite timeout value in the response packet The timeout value returned by the NBNS is the actual refresh timeout that the end node must use When a node sends a NAME REFRESH REQUEST it must be prepared to receive a negative response This would happen for example if the the NBNS discovers that the the

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1001.txt (2016-02-14)
    Open archived version from archive


  • QUERY RESPONSE 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NAME TRN ID 1 0x0 1 T 1 0 0 0 0x0 0x0000 0x0001 0x0000 0x0000 RR NAME NB 0x0020 IN 0x0001 TTL RDLENGTH ADDR ENTRY ARRAY The ADDR ENTRY ARRAY a sequence of zero or more ADDR ENTRY records Each ADDR ENTRY record represents an owner of a name For group names there may be multiple entries However the list may be incomplete due to packet size limitations Bit 22 T will be set to indicate truncated data Each ADDR ENTRY has the following format NB FLAGS NB ADDRESS NB ADDRESS continued NetBIOS Working Group Page 22 RFC 1002 March 1987 4 2 14 NEGATIVE NAME QUERY RESPONSE 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NAME TRN ID 1 0x0 1 0 1 0 0 0 RCODE 0x0000 0x0000 0x0000 0x0000 RR NAME NULL 0x000A IN 0x0001 0x00000000 0x0000 RCODE field values Symbol Value Description FMT ERR 0x1 Format Error Request was invalidly formatted SRV ERR 0x2 Server failure Problem with NBNS cannot process name NAM ERR 0x3 Name Error The name requested does not exist IMP ERR 0x4 Unsupported request error Allowable only for challenging NBNS when gets an Update type registration request RFS ERR 0x5 Refused error For policy reasons server will not register this name from this host NetBIOS Working Group Page 23 RFC 1002 March 1987 4 2 15 REDIRECT NAME QUERY RESPONSE 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NAME TRN ID 1 0x0 0 0 1 0 0 0 0 0x0 0x0000 0x0000 0x0001 0x0001 RR NAME NS 0x0002 IN 0x0001 TTL RDLENGTH NSD NAME RR NAME A 0x0001 IN 0x0001 TTL 0x0004 NSD IP ADDR NSD IP ADDR continued An end node responding to a NAME QUERY REQUEST always responds with the AA and RA bits set for both the NEGATIVE and POSITIVE NAME QUERY RESPONSE packets An end node never sends a REDIRECT NAME QUERY RESPONSE packet NetBIOS Working Group Page 24 RFC 1002 March 1987 When the requestor receives the REDIRECT NAME QUERY RESPONSE it must reiterate the NAME QUERY REQUEST to the NBNS specified by the NSD IP ADDR field of the A type RESOURCE RECORD in the ADDITIONAL section of the response packet This is an optional packet for the NBNS The NSD NAME and the RR NAME in the ADDITIONAL section of the response packet are the same name Space can be optimized if label string pointers are used in the RR NAME which point to the labels in the NSD NAME The RR NAME in the AUTHORITY section is the name of the domain the NBNS called by NSD NAME has authority over 4 2 16 WAIT FOR ACKNOWLEDGEMENT WACK RESPONSE 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NAME TRN ID 1 0x7 1 0 0 0 0 0 0 0x0 0x0000 0x0001 0x0000 0x0000 RR NAME NULL 0x0020 IN 0x0001 TTL 0x0002 OPCODE NM FLAGS 0x0 NetBIOS Working Group Page 25 RFC 1002 March 1987 The NAME TRN ID of the WACK RESPONSE packet is the same NAME TRN ID of the request that the NBNS is telling the requestor to wait longer to complete The RR NAME is the name from the request if any If no name is available from the request then it is a null name single byte of zero The TTL field of the ResourceRecord is the new time to wait in seconds for the request to complete The RDATA field contains the OPCODE and NM FLAGS of the request A TTL value of 0 means that the NBNS can not estimate the time it may take to complete a response 4 2 17 NODE STATUS REQUEST 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NAME TRN ID 0 0x0 0 0 0 0 0 0 B 0x0 0x0001 0x0000 0x0000 0x0000 QUESTION NAME NBSTAT 0x0021 IN 0x0001 NetBIOS Working Group Page 26 RFC 1002 March 1987 4 2 18 NODE STATUS RESPONSE 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NAME TRN ID 1 0x0 1 0 0 0 0 0 0 0x0 0x0000 0x0001 0x0000 0x0000 RR NAME NBSTAT 0x0021 IN 0x0001 0x00000000 RDLENGTH NUM NAMES NODE NAME ARRAY STATISTICS The NODE NAME ARRAY is an array of zero or more NUM NAMES entries of NODE NAME records Each NODE NAME entry represents an active name in the same NetBIOS scope as the requesting name in the local name table of the responder RR NAME is the requesting name NetBIOS Working Group Page 27 RFC 1002 March 1987 NODE NAME Entry 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 NETBIOS FORMAT NAME NAME FLAGS The NAME FLAGS field 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 G ONT DRG CNF ACT PRM RESERVED The NAME FLAGS field is defined as Symbol Bit s Description RESERVED 7 15 Reserved for future use Must be zero 0 PRM 6 Permanent Name Flag If one 1 then entry is for the permanent node name Flag is zero 0 for all other names ACT 5 Active Name Flag All entries have this flag set to one 1 CNF 4 Conflict Flag If one 1 then name on this node is in conflict DRG 3 Deregister Flag If one 1 then this name is in the process of being deleted ONT 1 2 Owner Node Type 00 B node 01 P node 10 M node 11 Reserved for future use G 0 Group Name Flag If one 1 then the name is a GROUP NetBIOS name If zero 0 then it is a UNIQUE NetBIOS name NetBIOS Working Group Page 28 RFC 1002 March 1987 STATISTICS Field of the NODE STATUS RESPONSE 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 UNIT ID Unique unit ID UNIT ID continued JUMPERS TEST RESULT VERSION NUMBER PERIOD OF STATISTICS NUMBER OF CRCs NUMBER ALIGNMENT ERRORS NUMBER OF COLLISIONS NUMBER SEND ABORTS NUMBER GOOD SENDS NUMBER GOOD RECEIVES NUMBER RETRANSMITS NUMBER NO RESOURCE CONDITIONS NUMBER FREE COMMAND BLOCKS TOTAL NUMBER COMMAND BLOCKS MAX TOTAL NUMBER COMMAND BLOCKS NUMBER PENDING SESSIONS MAX NUMBER PENDING SESSIONS MAX TOTAL SESSIONS POSSIBLE SESSION DATA PACKET SIZE 4 3 SESSION SERVICE PACKETS 4 3 1 GENERAL FORMAT OF SESSION PACKETS All session service messages are sent over a TCP connection All session packets are of the following general structure 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE FLAGS LENGTH TRAILER Packet Type Dependent The TYPE FLAGS and LENGTH fields are present in every session packet NetBIOS Working Group Page 29 RFC 1002 March 1987 The LENGTH field is the number of bytes following the LENGTH field In other words LENGTH is the combined size of the TRAILER field s For example the POSITIVE SESSION RESPONSE packet always has a LENGTH field value of zero 0000 while the RETARGET SESSION RESPONSE always has a LENGTH field value of six 0006 One of the bits of the FLAGS field acts as an additional high order bit for the LENGTH field Thus the cumulative size of the trailer field s may range from 0 to 128K bytes Session Packet Types in hexidecimal 00 SESSION MESSAGE 81 SESSION REQUEST 82 POSITIVE SESSION RESPONSE 83 NEGATIVE SESSION RESPONSE 84 RETARGET SESSION RESPONSE 85 SESSION KEEP ALIVE Bit definitions of the FLAGS field 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 E Symbol Bit s Description E 7 Length extension used as an additional high order bit on the LENGTH field RESERVED 0 6 Reserved must be zero 0 4 3 2 SESSION REQUEST PACKET 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE FLAGS LENGTH CALLED NAME CALLING NAME NetBIOS Working Group Page 30 RFC 1002 March 1987 4 3 3 POSITIVE SESSION RESPONSE PACKET 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE FLAGS LENGTH 4 3 4 NEGATIVE SESSION RESPONSE PACKET 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE FLAGS LENGTH ERROR CODE NEGATIVE SESSION RESPONSE packet error code values in hexidecimal 80 Not listening on called name 81 Not listening for calling name 82 Called name not present 83 Called name present but insufficient resources 8F Unspecified error 4 3 5 SESSION RETARGET RESPONSE PACKET 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE FLAGS LENGTH RETARGET IP ADDRESS PORT NetBIOS Working Group Page 31 RFC 1002 March 1987 4 3 6 SESSION MESSAGE PACKET 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE FLAGS LENGTH USER DATA 4 3 7 SESSION KEEP ALIVE PACKET 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE FLAGS LENGTH 4 4 DATAGRAM SERVICE PACKETS 4 4 1 NetBIOS DATAGRAM HEADER 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 MSG TYPE FLAGS DGM ID SOURCE IP SOURCE PORT DGM LENGTH PACKET OFFSET MSG TYPE values in hexidecimal 10 DIRECT UNIQUE DATAGRAM 11 DIRECT GROUP DATAGRAM 12 BROADCAST DATAGRAM 13 DATAGRAM ERROR 14 DATAGRAM QUERY REQUEST 15 DATAGRAM POSITIVE QUERY RESPONSE 16 DATAGRAM NEGATIVE QUERY RESPONSE NetBIOS Working Group Page 32 RFC 1002 March 1987 Bit definitions of the FLAGS field 0 1 2 3 4 5 6 7 0 0 0 0 SNT F M Symbol Bit s Description M 7 MORE flag If set then more NetBIOS datagram fragments follow F 6 FIRST packet flag If set then this is first and possibly only fragment of NetBIOS datagram SNT 4 5 Source End Node type 00 B node 01 P node 10 M node 11 NBDD RESERVED 0 3 Reserved must be zero 0 4 4 2 DIRECT UNIQUE DIRECT GROUP BROADCAST DATAGRAM 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 MSG TYPE FLAGS DGM ID SOURCE IP SOURCE PORT DGM LENGTH PACKET OFFSET SOURCE NAME DESTINATION NAME USER DATA NetBIOS Working Group Page 33 RFC 1002 March 1987 4 4 3 DATAGRAM ERROR PACKET 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 MSG TYPE FLAGS DGM ID SOURCE IP SOURCE PORT ERROR CODE ERROR CODE values in hexidecimal 82 DESTINATION NAME NOT PRESENT 83 INVALID SOURCE NAME FORMAT 84 INVALID DESTINATION NAME FORMAT 4 4 4 DATAGRAM QUERY REQUEST 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 MSG TYPE FLAGS DGM ID SOURCE IP SOURCE PORT DESTINATION NAME 4 4 5 DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 MSG TYPE FLAGS DGM ID SOURCE IP SOURCE PORT DESTINATION NAME NetBIOS Working Group Page 34 RFC 1002 March 1987 5 PROTOCOL DESCRIPTIONS 5 1 NAME SERVICE PROTOCOLS A REQUEST packet is always sent to the well known UDP port NAME SERVICE UDP PORT The destination address is normally either the IP broadcast address or the address of the NBNS the address of the NBNS server it set up at initialization time In rare cases a request packet will be sent to an end node e g a NAME QUERY REQUEST sent to challenge a node A RESPONSE packet is always sent to the source UDP port and source IP address of the request packet A DEMAND packet must always be sent to the well known UDP port NAME SERVICE UDP PORT There is no restriction on the target IP address Terms used in this section tid Transaction ID This is a value composed from the requestor s IP address and a unique 16 bit value generated by the originator of the transaction 5 1 1 B NODE ACTIVITY 5 1 1 1 B NODE ADD NAME PROCEDURE add name newname Host initiated processing for a B node BEGIN REPEAT build name service packet ONT B NODE broadcast node G UNIQUE unique name TTL 0 broadcast NAME REGISTRATION REQUEST packet remote node s will send response packet if applicable NetBIOS Working Group Page 35 RFC 1002 March 1987 pause BCAST REQ RETRY TIMEOUT UNTIL response packet is received or retransmit count has been exceeded IF no response packet was received THEN BEGIN no response build packet ONT B NODE broadcast node G UNIQUE unique name TTL 0 Let other nodes known you have the name broadcast NAME UPDATE REQUEST packet name can be added to local name table return success END no response ELSE BEGIN got response Match return transaction id against tid sent in request IF NOT response tid request tid THEN BEGIN ignore response packet END ELSE CASE packet type OF NEGATIVE NAME REGISTRATION RESPONSE return failure name cannot be added POSITIVE NAME REGISTRATION RESPONSE END NODE CHALLENGE NAME REGISTRATION RESPONSE B nodes should normally not get this response ignore packet NetBIOS Working Group Page 36 RFC 1002 March 1987 END case END got response END procedure 5 1 1 2 B NODE ADD GROUP NAME PROCEDURE add group name newname Host initiated processing for a B node BEGIN same as for a unique name with the exception that the group bit G must be set in the request packets G GROUP broadcast request END 5 1 1 3 B NODE FIND NAME PROCEDURE find name name Host initiated processing for a B node BEGIN REPEAT build packet ONT B TTL 0 G DONT CARE broadcast NAME QUERY REQUEST packet NetBIOS Working Group Page 37 RFC 1002 March 1987 a node might send response packet pause BCAST REQ RETRY TIMEOUT UNTIL response packet received OR max transmit threshold exceeded IF no response packet received THEN return failure ELSE IF NOT response tid request tid THEN ignore packet ELSE CASE packet type OF POSITIVE NAME QUERY RESPONSE Start a timer to detect conflict Be prepared to detect conflict if any more response packets are received save response as authoritative response start timer CONFLICT TIMER return success NEGATIVE NAME QUERY RESPONSE REDIRECT NAME QUERY RESPONSE B Node should normally not get either response ignore response packet END case END procedure 5 1 1 4 B NODE NAME RELEASE PROCEDURE delete name name BEGIN REPEAT build packet NetBIOS Working Group Page 38 RFC 1002 March 1987 send request broadcast NAME RELEASE REQUEST packet no response packet expected pause BCAST REQ RETRY TIMEOUT UNTIL retransmit count has been exceeded END procedure 5 1 1 5 B NODE INCOMING PACKET PROCESSING Following processing is done when broadcast or unicast packets are received at the NAME SERVICE UDP PORT PROCEDURE process incoming packet packet Processing initiated by incoming packets for a B node BEGIN Note response packets are always sent to source IP address of request packet source UDP port of request packet CASE packet type OF NAME REGISTRATION REQUEST UNIQUE IF name exists in local name table THEN send NEGATIVE NAME REGISTRATION RESPONSE NAME REGISTRATION REQUEST GROUP IF name exists in local name table THEN BEGIN IF local entry is a unique name THEN send NEGATIVE NAME REGISTRATION RESPONSE END NAME QUERY REQUEST IF name exists in local name table THEN BEGIN build response packet NetBIOS Working Group Page 39 RFC 1002 March 1987 send POSITIVE NAME QUERY RESPONSE POSITIVE NAME QUERY RESPONSE IF name conflict timer is not active THEN BEGIN timer has expired already ignore this packet return END ELSE timer is active IF a response for this name has previously been received THEN BEGIN existing entry we sent out a request packet and have already received at least one response Check if conflict exists If so send out a conflict packet Note detecting conflict does NOT affect any existing sessions Check for name conflict See Name Conflict in Concepts and Methods check saved authoritative response against information in this response packet IF conflict detected THEN BEGIN unicast NAME CONFLICT DEMAND packet IF entry exists in cache THEN BEGIN remove entry from cache END END END existing entry ELSE BEGIN Note If this was the first response to a name query it would have been handled in the find name procedure NetBIOS Working Group Page 40 RFC 1002 March 1987 ignore packet END NAME CONFLICT DEMAND IF name exists in local name table THEN BEGIN mark name as conflict detected a name in the state conflict detected does not logically exist on that node No further session will be accepted on that name No datagrams can be sent against that name Such an entry will not be used for purposes of processing incoming request packets The only valid user NetBIOS operation against such a name is DELETE NAME END NAME RELEASE REQUEST IF caching is being done THEN BEGIN remove entry from cache END NAME UPDATE REQUEST IF caching is being done THEN BEGIN IF entry exists in cache already update cache ELSE IF name is interesting THEN BEGIN add entry to cache END END NODE STATUS REQUEST IF name exists in local name table THEN BEGIN send only those names that are in the same scope as the scope field in the request packet send NODE STATUS RESPONSE END END NetBIOS Working Group Page 41 RFC 1002 March 1987 5 1 2 P NODE ACTIVITY All packets sent or received by P nodes are unicast UDP packets A P node sends name service requests to the NBNS node that is specified in the P node configuration 5 1 2 1 P NODE ADD NAME PROCEDURE add name newname Host initiated processing for a P node BEGIN REPEAT build packet ONT P G UNIQUE send request unicast NAME REGISTRATION REQUEST packet NBNS will send response packet IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL response packet is received OR retransmit count has been exceeded IF no response packet was received THEN BEGIN no response NBNS is down Cannot claim name return failure name cannot be claimed END no response ELSE NetBIOS Working Group Page 42 RFC 1002 March 1987 BEGIN response IF NOT response tid request tid THEN BEGIN Packet may belong to another transaction ignore response packet END ELSE CASE packet type OF POSITIVE NAME REGISTRATION RESPONSE name can be added adjust refresh timeout value TTL for this name return success name can be added NEGATIVE NAME REGISTRATION RESPONSE return failure name cannot be added END NODE CHALLENGE REGISTRATION REQUEST BEGIN end node challenge The response packet has in it the address of the presumed owner of the name Challenge that owner If owner either does not respond or indicates that he no longer owns the name claim the name Otherwise the name cannot be claimed REPEAT build packet unicast NAME QUERY REQUEST packet to the address contained in the END NODE CHALLENGE RESPONSE packet remote node may send response packet pause UCAST REQ RETRY TIMEOUT NetBIOS Working Group Page 43 RFC 1002 March 1987 UNTIL response packet is received or retransmit count has been exceeded IF no response packet is received OR NEGATIVE NAME QUERY RESPONSE packet received THEN BEGIN update name can be claimed REPEAT build packet unicast NAME UPDATE REQUEST to NBNS NBNS node will send response packet IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL response packet is received or retransmit count has been exceeded IF no response packet received THEN BEGIN no response name could not be claimed return failure END no response ELSE CASE packet type OF POSITIVE NAME REGISTRATION RESPONSE add name return success NEGATIVE NAME REGISTRATION RESPONSE you lose NetBIOS Working Group Page 44 RFC 1002 March 1987 return failure END case END update ELSE received a positive response to the challenge Remote node still has name return failure END end node challenge END response END procedure 5 1 2 2 P NODE ADD GROUP NAME PROCEDURE add group name newname Host initiated processing for a P node BEGIN same as for a unique name except that the request packet must indicate that a group name claim is being made G GROUP send packet END 5 1 2 3 P NODE FIND NAME PROCEDURE find name name Host initiated processing for a P node BEGIN NetBIOS Working Group Page 45 RFC 1002 March 1987 REPEAT build packet ONT P G DONT CARE unicast NAME QUERY REQUEST packet a NBNS node might send response packet IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL response packet received OR max transmit threshold exceeded IF no response packet received THEN return failure ELSE IF NOT response tid request tid THEN ignore packet ELSE CASE packet type OF POSITIVE NAME QUERY RESPONSE return success REDIRECT NAME QUERY RESPONSE NBNS node wants this end node to use some other NBNS node to resolve the query repeat query with NBNS address in the response packet NEGATIVE NAME QUERY RESPONSE return failure END case END procedure 5 1 2 4 P NODE DELETE NAME PROCEDURE delete name name NetBIOS Working Group Page 46 RFC 1002 March 1987 Host initiated processing for a P node BEGIN REPEAT build packet send request unicast NAME RELEASE REQUEST packet IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL retransmit count has been exceeded or response been received IF response has been received THEN CASE packet type OF POSITIVE NAME RELEASE RESPONSE return success NEGATIVE NAME RELEASE RESPONSE NBNS does want node to delete this name return failure END case END procedure 5 1 2 5 P NODE INCOMING PACKET PROCESSING Processing initiated by reception of packets at a P node PROCEDURE process incoming packet packet Processing initiated by incoming packets at a P node BEGIN NetBIOS Working Group Page 47 RFC 1002 March 1987 always ignore UDP broadcast packets IF packet was sent as a broadcast THEN BEGIN ignore packet return END CASE packet type of NAME CONFLICT DEMAND IF name exists in local name table THEN mark name as in conflict return NAME QUERY REQUEST IF name exists in local name table THEN BEGIN name exists build packet send response to the IP address and port number from which the request was received send POSITIVE NAME QUERY RESPONSE return END exists ELSE BEGIN does not exist send response to the requestor send NEGATIVE NAME QUERY RESPONSE return END does not exist NODE STATUS REQUEST Name of may be used for force node to divulge status for administrative purposes IF name in local name table OR name THEN BEGIN NetBIOS Working Group Page 48 RFC 1002 March 1987 Build response packet and send to requestor node Send only those names that are in the same scope as the scope in the request packet send NODE STATUS RESPONSE END NAME RELEASE REQUEST This will be received if the NBNS wants to flush the name from the local name table or from the local cache IF name exists in the local name table THEN BEGIN delete name from local name table inform user that name has been deleted END ELSE IF name has been cached locally THEN BEGIN remove entry from cache END END case END procedure 5 1 2 6 P NODE TIMER INITIATED PROCESSING Processing initiated by timer expiration PROCEDURE timer expired Processing initiated by the expiration of a timer on a P node BEGIN Send a NAME REFRESH REQUEST for each name which the TTL which has expired REPEAT build NAME REFRESH REQUEST packet REPEAT send packet to NBNS IF receive a WACK RESPONSE THEN pause time from TTL field of response NetBIOS Working Group Page 49 RFC 1002 March 1987 ELSE pause UCAST REQ RETRY TIMEOUT UNTIL response packet is received or retransmit count has been exceeded CASE packet type OF POSITIVE NAME REGISTRATION RESPONSE successfully refreshed reset TTL timer for this name NEGATIVE NAME REGISTRATION RESPONSE refused can t keep name assume in conflict mark name as in conflict END case UNTIL request sent for all names for which TTL has expired END procedure 5 1 3 M NODE ACTIVITY M nodes behavior is similar to that of P nodes with the addition of some B node like broadcast actions M node name service proceeds in two steps 1 Use broadcast UDP based name service Depending on the operation goto step 2 2 Use directed UDP name service The following code for M nodes is exactly the same as for a P node with the exception that broadcast operations are done before P type operation is attempted 5 1 3 1 M NODE ADD NAME PROCEDURE add name newname Host initiated processing for a M node BEGIN check if name exists on the broadcast area NetBIOS Working Group Page 50 RFC 1002 March 1987 REPEAT build packet broadcast NAME REGISTRATION REQUEST packet pause BCAST REQ RETRY TIMEOUT UNTIL response packet is received or retransmit count has been exceeded IF valid response received THEN BEGIN cannot claim name return failure END No objections received within the broadcast area Send request to name server REPEAT build packet ONT M unicast NAME REGISTRATION REQUEST packet remote NBNS will send response packet IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL response packet is received or retransmit count has been exceeded IF no response packet was received THEN BEGIN no response NBNS is down Cannot claim name NetBIOS Working Group Page 51 RFC 1002 March 1987 return failure name cannot be claimed END no response ELSE BEGIN response IF NOT response tid request tid THEN BEGIN ignore response packet END ELSE CASE packet type OF POSITIVE NAME REGISTRATION RESPONSE name can be added adjust refresh timeout value TTL return success name can be added NEGATIVE NAME REGISTRATION RESPONSE return failure name cannot be added END NODE CHALLENGE REGISTRATION REQUEST BEGIN end node challenge The response packet has in it the address of the presumed owner of the name Challenge that owner If owner either does not respond or indicates that he no longer owns the name claim the name Otherwise the name cannot be claimed REPEAT build packet send packet to address contained in the response packet unicast NAME QUERY REQUEST packet remote node may send response packet NetBIOS Working Group Page 52 RFC 1002 March 1987 pause UCAST REQ RETRY TIMEOUT UNTIL response packet is received or retransmit count has been exceeded IF no response packet is received THEN BEGIN no response name can be claimed REPEAT build packet unicast NAME UPDATE REQUEST to NBNS NBNS node will send response packet IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL response packet is received or retransmit count has been exceeded IF no response packet received THEN BEGIN no response name could not be claimed return failure END no response ELSE CASE packet type OF POSITIVE NAME REGISTRATION RESPONSE add name return success NEGATIVE NAME REGISTRATION RESPONSE NetBIOS Working Group Page 53 RFC 1002 March 1987 you lose return failure END case END no response ELSE IF NOT response tid request tid THEN BEGIN ignore response packet END received a response to the challenge packet CASE packet type OF POSITIVE NAME QUERY remote node still has name return failure NEGATIVE NAME QUERY remote node no longer has name return success END case END end node challenge END case END response END procedure 5 1 3 2 M NODE ADD GROUP NAME PROCEDURE add group name newname Host initiated processing for a P node BEGIN same as for a unique name except that the request packet must indicate that a NetBIOS Working Group Page 54 RFC 1002 March 1987 group name claim is being made G GROUP send packet END 5 1 3 3 M NODE FIND NAME PROCEDURE find name name Host initiated processing for a M node BEGIN check if any node on the broadcast area has the name REPEAT build packet broadcast NAME QUERY REQUEST packet pause BCAST REQ RETRY TIMEOUT UNTIL response packet received OR max transmit threshold exceeded IF valid response received THEN BEGIN save response as authoritative response start timer CONFLICT TIMER return success END no valid response on the b cast segment Try the name server REPEAT NetBIOS Working Group Page 55 RFC 1002 March 1987 build packet ONT M G DONT CARE unicast NAME QUERY REQUEST packet to NBNS a NBNS node might send response packet IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL response packet received OR max transmit threshold exceeded IF no response packet received THEN return failure ELSE IF NOT response tid request tid THEN ignore packet ELSE CASE packet type OF POSITIVE NAME QUERY RESPONSE return success REDIRECT NAME QUERY RESPONSE NBNS node wants this end node to use some other NBNS node to resolve the query repeat query with NBNS address in the response packet NEGATIVE NAME QUERY RESPONSE return failure END case END procedure 5 1 3 4 M NODE DELETE NAME PROCEDURE delete name name NetBIOS Working Group Page 56 RFC 1002 March 1987 Host initiated processing for a P node BEGIN First delete name on NBNS REPEAT build packet send request unicast NAME RELEASE REQUEST packet to NBNS IF receive a WACK RESPONSE THEN pause time from TTL field of response ELSE pause UCAST REQ RETRY TIMEOUT UNTIL retransmit count has been exceeded or response been received IF response has been received THEN CASE packet type OF POSITIVE NAME RELEASE RESPONSE Deletion of name on b cast segment is deferred until after NBNS has deleted the name REPEAT build packet broadcast NAME RELEASE REQUEST pause BCAST REQ RETRY TIMEOUT UNTIL rexmt threshold exceeded return success NEGATIVE NAME RELEASE RESPONSE NBNS does want node to delete this name NetBIOS Working Group Page 57 RFC 1002 March 1987 return failure END case END procedure 5 1 3 5 M NODE INCOMING PACKET PROCESSING Processing initiated by reception of packets at a M node PROCEDURE process incoming packet packet Processing initiated by incoming packets at a M node BEGIN CASE packet type of NAME CONFLICT DEMAND IF name exists in local name table THEN mark name as in conflict return NAME QUERY REQUEST IF name exists in local name table THEN BEGIN name exists build packet send response to the IP address and port number from which the request was received send POSITIVE NAME QUERY RESPONSE return END exists ELSE BEGIN does not exist send response to the requestor IF request NOT broadcast THEN Don t send negative responses to queries sent by B nodes NetBIOS Working Group Page 58 RFC 1002 March 1987 send NEGATIVE NAME

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1002.txt (2016-02-14)
    Open archived version from archive


  • record structure all the end of record markers EOR are explicit including the final one For files transmitted in page structure a last page page type is used NOTE In the rest of this section byte means transfer byte except where explicitly stated otherwise For the purpose of standardized transfer the sending host will translate its internal end of line or end of record denotation into the representation prescribed by the transfer mode and file structure and the receiving host will perform the inverse translation to its internal denotation An IBM Mainframe record count field may not be recognized at another host so the end of record information may be transferred as a two byte control code in Stream mode or as a flagged bit in a Block or Compressed mode descriptor End of line in an ASCII or EBCDIC file with no record structure should be indicated by or respectively Since these transformations imply extra work for some systems identical systems transferring non record structured text files might wish to use a binary representation and stream mode for the transfer Postel Reynolds Page 20 RFC 959 October 1985 File Transfer Protocol The following transmission modes are defined in FTP 3 4 1 STREAM MODE The data is transmitted as a stream of bytes There is no restriction on the representation type used record structures are allowed In a record structured file EOR and EOF will each be indicated by a two byte control code The first byte of the control code will be all ones the escape character The second byte will have the low order bit on and zeros elsewhere for EOR and the second low order bit on for EOF that is the byte will have value 1 for EOR and value 2 for EOF EOR and EOF may be indicated together on the last byte transmitted by turning both low order bits on i e the value 3 If a byte of all ones was intended to be sent as data it should be repeated in the second byte of the control code If the structure is a file structure the EOF is indicated by the sending host closing the data connection and all bytes are data bytes 3 4 2 BLOCK MODE The file is transmitted as a series of data blocks preceded by one or more header bytes The header bytes contain a count field and descriptor code The count field indicates the total length of the data block in bytes thus marking the beginning of the next data block there are no filler bits The descriptor code defines last block in the file EOF last block in the record EOR restart marker see the Section on Error Recovery and Restart or suspect data i e the data being transferred is suspected of errors and is not reliable This last code is NOT intended for error control within FTP It is motivated by the desire of sites exchanging certain types of data e g seismic or weather data to send and receive all the data despite local errors such as magnetic tape read errors but to indicate in the transmission that certain portions are suspect Record structures are allowed in this mode and any representation type may be used The header consists of the three bytes Of the 24 bits of header information the 16 low order bits shall represent byte count and the 8 high order bits shall represent descriptor codes as shown below Postel Reynolds Page 21 RFC 959 October 1985 File Transfer Protocol Block Header Descriptor Byte Count 8 bits 16 bits The descriptor codes are indicated by bit flags in the descriptor byte Four codes have been assigned where each code number is the decimal value of the corresponding bit in the byte Code Meaning 128 End of data block is EOR 64 End of data block is EOF 32 Suspected errors in data block 16 Data block is a restart marker With this encoding more than one descriptor coded condition may exist for a particular block As many bits as necessary may be flagged The restart marker is embedded in the data stream as an integral number of 8 bit bytes representing printable characters in the language being used over the control connection e g default NVT ASCII Space in the appropriate language must not be used WITHIN a restart marker For example to transmit a six character marker the following would be sent Descrptr Byte count code 16 6 Marker Marker Marker 8 bits 8 bits 8 bits Marker Marker Marker 8 bits 8 bits 8 bits Postel Reynolds Page 22 RFC 959 October 1985 File Transfer Protocol 3 4 3 COMPRESSED MODE There are three kinds of information to be sent regular data sent in a byte string compressed data consisting of replications or filler and control information sent in a two byte escape sequence If n 0 bytes up to 127 of regular data are sent these n bytes are preceded by a byte with the left most bit set to 0 and the right most 7 bits containing the number n Byte string 1 7 8 8 0 n d 1 d n n bytes of data String of n data bytes d 1 d n Count n must be positive To compress a string of n replications of the data byte d the following 2 bytes are sent Replicated Byte 2 6 8 1 0 n d A string of n filler bytes can be compressed into a single byte where the filler byte varies with the representation type If the type is ASCII or EBCDIC the filler byte is Space ASCII code 32 EBCDIC code 64 If the type is Image or Local byte the filler is a zero byte Filler String 2 6 1 1 n The escape sequence is a double byte the first of which is the Postel Reynolds Page 23 RFC 959 October 1985 File Transfer Protocol escape byte all zeros and the second of which contains descriptor codes as defined in Block mode The descriptor codes have the same meaning as in Block mode and apply to the succeeding string of bytes Compressed mode is useful for obtaining increased bandwidth on very large network transmissions at a little extra CPU cost It can be most effectively used to reduce the size of printer files such as those generated by RJE hosts 3 5 ERROR RECOVERY AND RESTART There is no provision for detecting bits lost or scrambled in data transfer this level of error control is handled by the TCP However a restart procedure is provided to protect users from gross system failures including failures of a host an FTP process or the underlying network The restart procedure is defined only for the block and compressed modes of data transfer It requires the sender of data to insert a special marker code in the data stream with some marker information The marker information has meaning only to the sender but must consist of printable characters in the default or negotiated language of the control connection ASCII or EBCDIC The marker could represent a bit count a record count or any other information by which a system may identify a data checkpoint The receiver of data if it implements the restart procedure would then mark the corresponding position of this marker in the receiving system and return this information to the user In the event of a system failure the user can restart the data transfer by identifying the marker point with the FTP restart procedure The following example illustrates the use of the restart procedure The sender of the data inserts an appropriate marker block in the data stream at a convenient point The receiving host marks the corresponding data point in its file system and conveys the last known sender and receiver marker information to the user either directly or over the control connection in a 110 reply depending on who is the sender In the event of a system failure the user or controller process restarts the server at the last server marker by sending a restart command with server s marker code as its argument The restart command is transmitted over the control Postel Reynolds Page 24 RFC 959 October 1985 File Transfer Protocol connection and is immediately followed by the command such as RETR STOR or LIST which was being executed when the system failure occurred 4 FILE TRANSFER FUNCTIONS The communication channel from the user PI to the server PI is established as a TCP connection from the user to the standard server port The user protocol interpreter is responsible for sending FTP commands and interpreting the replies received the server PI interprets commands sends replies and directs its DTP to set up the data connection and transfer the data If the second party to the data transfer the passive transfer process is the user DTP then it is governed through the internal protocol of the user FTP host if it is a second server DTP then it is governed by its PI on command from the user PI The FTP replies are discussed in the next section In the description of a few of the commands in this section it is helpful to be explicit about the possible replies 4 1 FTP COMMANDS 4 1 1 ACCESS CONTROL COMMANDS The following commands specify access control identifiers command codes are shown in parentheses USER NAME USER The argument field is a Telnet string identifying the user The user identification is that which is required by the server for access to its file system This command will normally be the first command transmitted by the user after the control connections are made some servers may require this Additional identification information in the form of a password and or an account command may also be required by some servers Servers may allow a new USER command to be entered at any point in order to change the access control and or accounting information This has the effect of flushing any user password and account information already supplied and beginning the login sequence again All transfer parameters are unchanged and any file transfer in progress is completed under the old access control parameters Postel Reynolds Page 25 RFC 959 October 1985 File Transfer Protocol PASSWORD PASS The argument field is a Telnet string specifying the user s password This command must be immediately preceded by the user name command and for some sites completes the user s identification for access control Since password information is quite sensitive it is desirable in general to mask it or suppress typeout It appears that the server has no foolproof way to achieve this It is therefore the responsibility of the user FTP process to hide the sensitive password information ACCOUNT ACCT The argument field is a Telnet string identifying the user s account The command is not necessarily related to the USER command as some sites may require an account for login and others only for specific access such as storing files In the latter case the command may arrive at any time There are reply codes to differentiate these cases for the automation when account information is required for login the response to a successful PASSword command is reply code 332 On the other hand if account information is NOT required for login the reply to a successful PASSword command is 230 and if the account information is needed for a command issued later in the dialogue the server should return a 332 or 532 reply depending on whether it stores pending receipt of the ACCounT command or discards the command respectively CHANGE WORKING DIRECTORY CWD This command allows the user to work with a different directory or dataset for file storage or retrieval without altering his login or accounting information Transfer parameters are similarly unchanged The argument is a pathname specifying a directory or other system dependent file group designator CHANGE TO PARENT DIRECTORY CDUP This command is a special case of CWD and is included to simplify the implementation of programs for transferring directory trees between operating systems having different Postel Reynolds Page 26 RFC 959 October 1985 File Transfer Protocol syntaxes for naming the parent directory The reply codes shall be identical to the reply codes of CWD See Appendix II for further details STRUCTURE MOUNT SMNT This command allows the user to mount a different file system data structure without altering his login or accounting information Transfer parameters are similarly unchanged The argument is a pathname specifying a directory or other system dependent file group designator REINITIALIZE REIN This command terminates a USER flushing all I O and account information except to allow any transfer in progress to be completed All parameters are reset to the default settings and the control connection is left open This is identical to the state in which a user finds himself immediately after the control connection is opened A USER command may be expected to follow LOGOUT QUIT This command terminates a USER and if file transfer is not in progress the server closes the control connection If file transfer is in progress the connection will remain open for result response and the server will then close it If the user process is transferring files for several USERs but does not wish to close and then reopen connections for each then the REIN command should be used instead of QUIT An unexpected close on the control connection will cause the server to take the effective action of an abort ABOR and a logout QUIT 4 1 2 TRANSFER PARAMETER COMMANDS All data transfer parameters have default values and the commands specifying data transfer parameters are required only if the default parameter values are to be changed The default value is the last specified value or if no value has been specified the standard default value is as stated here This implies that the server must remember the applicable default values The commands may be in any order except that they must precede the FTP service request The following commands specify data transfer parameters Postel Reynolds Page 27 RFC 959 October 1985 File Transfer Protocol DATA PORT PORT The argument is a HOST PORT specification for the data port to be used in data connection There are defaults for both the user and server data ports and under normal circumstances this command and its reply are not needed If this command is used the argument is the concatenation of a 32 bit internet host address and a 16 bit TCP port address This address information is broken into 8 bit fields and the value of each field is transmitted as a decimal number in character string representation The fields are separated by commas A port command would be PORT h1 h2 h3 h4 p1 p2 where h1 is the high order 8 bits of the internet host address PASSIVE PASV This command requests the server DTP to listen on a data port which is not its default data port and to wait for a connection rather than initiate one upon receipt of a transfer command The response to this command includes the host and port address this server is listening on REPRESENTATION TYPE TYPE The argument specifies the representation type as described in the Section on Data Representation and Storage Several types take a second parameter The first parameter is denoted by a single Telnet character as is the second Format parameter for ASCII and EBCDIC the second parameter for local byte is a decimal integer to indicate Bytesize The parameters are separated by a Space ASCII code 32 The following codes are assigned for type A ASCII N Non print Local byte Byte size Postel Reynolds Page 28 RFC 959 October 1985 File Transfer Protocol The default representation type is ASCII Non print If the Format parameter is changed and later just the first argument is changed Format then returns to the Non print default FILE STRUCTURE STRU The argument is a single Telnet character code specifying file structure described in the Section on Data Representation and Storage The following codes are assigned for structure F File no record structure R Record structure P Page structure The default structure is File TRANSFER MODE MODE The argument is a single Telnet character code specifying the data transfer modes described in the Section on Transmission Modes The following codes are assigned for transfer modes S Stream B Block C Compressed The default transfer mode is Stream 4 1 3 FTP SERVICE COMMANDS The FTP service commands define the file transfer or the file system function requested by the user The argument of an FTP service command will normally be a pathname The syntax of pathnames must conform to server site conventions with standard defaults applicable and the language conventions of the control connection The suggested default handling is to use the last specified device directory or file name or the standard default defined for local users The commands may be in any order except that a rename from command must be followed by a rename to command and the restart command must be followed by the interrupted service command e g STOR or RETR The data when transferred in response to FTP service Postel Reynolds Page 29 RFC 959 October 1985 File Transfer Protocol commands shall always be sent over the data connection except for certain informative replies The following commands specify FTP service requests RETRIEVE RETR This command causes the server DTP to transfer a copy of the file specified in the pathname to the server or user DTP at the other end of the data connection The status and contents of the file at the server site shall be unaffected STORE STOR This command causes the server DTP to accept the data transferred via the data connection and to store the data as a file at the server site If the file specified in the pathname exists at the server site then its contents shall be replaced by the data being transferred A new file is created at the server site if the file specified in the pathname does not already exist STORE UNIQUE STOU This command behaves like STOR except that the resultant file is to be created in the current directory under a name unique to that directory The 250 Transfer Started response must include the name generated APPEND with create APPE This command causes the server DTP to accept the data transferred via the data connection and to store the data in a file at the server site If the file specified in the pathname exists at the server site then the data shall be appended to that file otherwise the file specified in the pathname shall be created at the server site ALLOCATE ALLO This command may be required by some servers to reserve sufficient storage to accommodate the new file to be transferred The argument shall be a decimal integer representing the number of bytes using the logical byte size of storage to be reserved for the file For files sent with record or page structure a maximum record or page size in logical bytes might also be necessary this is indicated by a decimal integer in a second argument field of Postel Reynolds Page 30 RFC 959 October 1985 File Transfer Protocol the command This second argument is optional but when present should be separated from the first by the three Telnet characters R This command shall be followed by a STORe or APPEnd command The ALLO command should be treated as a NOOP no operation by those servers which do not require that the maximum size of the file be declared beforehand and those servers interested in only the maximum record or page size should accept a dummy value in the first argument and ignore it RESTART REST The argument field represents the server marker at which file transfer is to be restarted This command does not cause file transfer but skips over the file to the specified data checkpoint This command shall be immediately followed by the appropriate FTP service command which shall cause file transfer to resume RENAME FROM RNFR This command specifies the old pathname of the file which is to be renamed This command must be immediately followed by a rename to command specifying the new file pathname RENAME TO RNTO This command specifies the new pathname of the file specified in the immediately preceding rename from command Together the two commands cause a file to be renamed ABORT ABOR This command tells the server to abort the previous FTP service command and any associated transfer of data The abort command may require special action as discussed in the Section on FTP Commands to force recognition by the server No action is to be taken if the previous command has been completed including data transfer The control connection is not to be closed by the server but the data connection must be closed There are two cases for the server upon receipt of this command 1 the FTP service command was already completed or 2 the FTP service command is still in progress Postel Reynolds Page 31 RFC 959 October 1985 File Transfer Protocol In the first case the server closes the data connection if it is open and responds with a 226 reply indicating that the abort command was successfully processed In the second case the server aborts the FTP service in progress and closes the data connection returning a 426 reply to indicate that the service request terminated abnormally The server then sends a 226 reply indicating that the abort command was successfully processed DELETE DELE This command causes the file specified in the pathname to be deleted at the server site If an extra level of protection is desired such as the query Do you really wish to delete it should be provided by the user FTP process REMOVE DIRECTORY RMD This command causes the directory specified in the pathname to be removed as a directory if the pathname is absolute or as a subdirectory of the current working directory if the pathname is relative See Appendix II MAKE DIRECTORY MKD This command causes the directory specified in the pathname to be created as a directory if the pathname is absolute or as a subdirectory of the current working directory if the pathname is relative See Appendix II PRINT WORKING DIRECTORY PWD This command causes the name of the current working directory to be returned in the reply See Appendix II LIST LIST This command causes a list to be sent from the server to the passive DTP If the pathname specifies a directory or other group of files the server should transfer a list of files in the specified directory If the pathname specifies a file then the server should send current information on the file A null argument implies the user s current working or default directory The data transfer is over the data connection in type ASCII or type EBCDIC The user must Postel Reynolds Page 32 RFC 959 October 1985 File Transfer Protocol ensure that the TYPE is appropriately ASCII or EBCDIC Since the information on a file may vary widely from system to system this information may be hard to use automatically in a program but may be quite useful to a human user NAME LIST NLST This command causes a directory listing to be sent from server to user site The pathname should specify a directory or other system specific file group descriptor a null argument implies the current directory The server will return a stream of names of files and no other information The data will be transferred in ASCII or EBCDIC type over the data connection as valid pathname strings separated by or Again the user must ensure that the TYPE is correct This command is intended to return information that can be used by a program to further process the files automatically For example in the implementation of a multiple get function SITE PARAMETERS SITE This command is used by the server to provide services specific to his system that are essential to file transfer but not sufficiently universal to be included as commands in the protocol The nature of these services and the specification of their syntax can be stated in a reply to the HELP SITE command SYSTEM SYST This command is used to find out the type of operating system at the server The reply shall have as its first word one of the system names listed in the current version of the Assigned Numbers document 4 STATUS STAT This command shall cause a status response to be sent over the control connection in the form of a reply The command may be sent during a file transfer along with the Telnet IP and Synch signals see the Section on FTP Commands in which case the server will respond with the status of the operation in progress or it may be sent between file transfers In the latter case the command may have an argument field If the argument is a pathname the command is analogous to the list command except that data shall be Postel Reynolds Page 33 RFC 959 October 1985 File Transfer Protocol transferred over the control connection If a partial pathname is given the server may respond with a list of file names or attributes associated with that specification If no argument is given the server should return general status information about the server FTP process This should include current values of all transfer parameters and the status of connections HELP HELP This command shall cause the server to send helpful information regarding its implementation status over the control connection to the user The command may take an argument e g any command name and return more specific information as a response The reply is type 211 or 214 It is suggested that HELP be allowed before entering a USER command The server may use this reply to specify site dependent parameters e g in response to HELP SITE NOOP NOOP This command does not affect any parameters or previously entered commands It specifies no action other than that the server send an OK reply The File Transfer Protocol follows the specifications of the Telnet protocol for all communications over the control connection Since the language used for Telnet communication may be a negotiated option all references in the next two sections will be to the Telnet language and the corresponding Telnet end of line code Currently one may take these to mean NVT ASCII and No other specifications of the Telnet protocol will be cited FTP commands are Telnet strings terminated by the Telnet end of line code The command codes themselves are alphabetic characters terminated by the character Space if parameters follow and Telnet EOL otherwise The command codes and the semantics of commands are described in this section the detailed syntax of commands is specified in the Section on Commands the reply sequences are discussed in the Section on Sequencing of Commands and Replies and scenarios illustrating the use of commands are provided in the Section on Typical FTP Scenarios FTP commands may be partitioned as those specifying access control identifiers data transfer parameters or FTP service requests Certain commands such as ABOR STAT QUIT may be sent over the control connection while a data transfer is in progress Some Postel Reynolds Page 34 RFC 959 October 1985 File Transfer Protocol servers may not be able to monitor the control and data connections simultaneously in which case some special action will be necessary to get the server s attention The following ordered format is tentatively recommended 1 User system inserts the Telnet Interrupt Process IP signal in the Telnet stream 2 User system sends the Telnet Synch signal 3 User system inserts the command e g ABOR in the Telnet stream 4 Server PI after receiving IP scans the Telnet stream for EXACTLY ONE FTP command For other servers this may not be necessary but the actions listed above should have no unusual effect 4 2 FTP REPLIES Replies to File Transfer Protocol commands are devised to ensure the synchronization of requests and actions in the process of file transfer and to guarantee that the user process always knows the state of the Server Every command must generate at least one reply although there may be more than one in the latter case the multiple replies must be easily distinguished In addition some commands occur in sequential groups such as USER PASS and ACCT or RNFR and RNTO The replies show the existence of an intermediate state if all preceding commands have been successful A failure at any point in the sequence necessitates the repetition of the entire sequence from the beginning The details of the command reply sequence are made explicit in a set of state diagrams below An FTP reply consists of a three digit number transmitted as three alphanumeric characters followed by some text The number is intended for use by automata to determine what state to enter next the text is intended for the human user It is intended that the three digits contain enough encoded information that the user process the User PI will not need to examine the text and may either discard it or pass it on to the user as appropriate In particular the text may be server dependent so there are likely to be varying texts for each reply code A reply is defined to contain the 3 digit code followed by Space Postel Reynolds Page 35 RFC 959 October 1985 File Transfer Protocol followed by one line of text where some maximum line length has been specified and terminated by the Telnet end of line code There will be cases however where the text is longer than a single line In these cases the complete text must be bracketed so the User process knows when it may stop reading the reply i e stop processing input on the control connection and go do other things This requires a special format on the first line to indicate that more than one line is coming and another on the last line to designate it as the last At least one of these must contain the appropriate reply code to indicate the state of the transaction To satisfy all factions it was decided that both the first and last line codes should be the same Thus the format for multi line replies is that the first line will begin with the exact required reply code followed immediately by a Hyphen also known as Minus followed by text The last line will begin with the same code followed immediately by Space optionally some text and the Telnet end of line code For example 123 First line Second line 234 A line beginning with numbers 123 The last line The user process then simply needs to search for the second occurrence of the same reply code followed by Space at the beginning of a line and ignore all intermediary lines If an intermediary line begins with a 3 digit number the Server must pad the front to avoid confusion This scheme allows standard system routines to be used for reply information such as for the STAT reply with artificial first and last lines tacked on In rare cases where these routines are able to generate three digits and a Space at the beginning of any line the beginning of each text line should be offset by some neutral text like Space This scheme assumes that multi line replies may not be nested The three digits of the reply each have a special significance This is intended to allow a range of very simple to very sophisticated responses by the user process The first digit denotes whether the response is good bad or incomplete Referring to the state diagram an unsophisticated user process will be able to determine its next action proceed as planned Postel Reynolds Page 36 RFC 959 October 1985 File Transfer Protocol redo retrench etc by simply examining this first digit A user process that wants to know approximately what kind of error occurred e g file system error command syntax error may examine the second digit reserving the third digit for the finest gradation of information e g RNTO command without a preceding RNFR There are five values for the first digit of the reply code 1yz Positive Preliminary reply The requested action is being initiated expect another reply before proceeding with a new command The user process sending another command before the completion reply would be in violation of protocol but server FTP processes should queue any commands that arrive while a preceding command is in progress This type of reply can be used to indicate that the command was accepted and the user process may now pay attention to the data connections for implementations where simultaneous monitoring is difficult The server FTP process may send at most one 1yz reply per command 2yz Positive Completion reply The requested action has been successfully completed A new request may be initiated 3yz Positive Intermediate reply The command has been accepted but the requested action is being held in abeyance pending receipt of further information The user should send another command specifying this information This reply is used in command sequence groups 4yz Transient Negative Completion reply The command was not accepted and the requested action did not take place but the error condition is temporary and the action may be requested again The user should return to the beginning of the command sequence if any It is difficult to assign a meaning to transient particularly when two distinct sites Server and User processes have to agree on the interpretation Each reply in the 4yz category might have a slightly different time value but the intent is that the Postel Reynolds Page 37 RFC 959 October 1985 File Transfer Protocol user process is encouraged to try again A rule of thumb in determining if a reply fits into the 4yz or the 5yz Permanent Negative category is that replies are 4yz if the commands can be repeated without any change in command form or in properties of the User or Server e g the command is spelled the same with the same arguments used the user does not change his file access or user name the server does not put up a new implementation 5yz Permanent Negative Completion reply The command was not accepted and the requested action did not take place The User process is discouraged from repeating the exact request in the same sequence Even some permanent error conditions can be corrected so the human user may want to direct his User process to reinitiate the command sequence by direct action at some point in the future e g after the spelling has been changed or the user has altered his directory status The following function groupings are encoded in the second digit x0z Syntax These replies refer to syntax errors syntactically correct commands that don t fit any functional category unimplemented or superfluous commands x1z Information These are replies to requests for information such as status or help x2z Connections Replies referring to the control and data connections x3z Authentication and accounting Replies for the login process and accounting procedures x4z Unspecified as yet x5z File system These replies indicate the status of the Server file system vis a vis the requested transfer or other file system action The third digit gives a finer gradation of meaning in each of the function categories specified by the second digit The list of replies below will illustrate this Note that the text Postel Reynolds Page 38 RFC 959 October 1985 File Transfer Protocol associated with each reply

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0959.txt (2016-02-14)
    Open archived version from archive


  • is preferred Mogul Postel Page 3 RFC 950 August 1985 Internet Standard Subnetting Procedure 2 Standards for Subnet Addressing This section first describes a proposal for interpretation of Internet addresses to support subnets Next it discusses changes to host software to support subnets Finally it presents a procedures for discovering what address interpretation is in use on a given network i e what address mask is in use 2 1 Interpretation of Internet Addresses Suppose that an organization has been assigned an Internet network number has further divided that network into a set of subnets and wants to assign host addresses how should this be done Since there are minimal restrictions on the assignment of the local address part of the Internet address several approaches have been proposed for representing the subnet number 1 Variable width field Any number of the bits of the local address part are used for the subnet number the size of this field although constant for a given network varies from network to network If the field width is zero then subnets are not in use 2 Fixed width field A specific number of bits e g eight is used for the subnet number if subnets are in use 3 Self encoding variable width field Just as the width i e class of the network number field is encoded by its high order bits the width of the subnet field is similarly encoded 4 Self encoding fixed width field A specific number of bits is used for the subnet number 5 Masked bits Use a bit mask address mask to identify which bits of the local address field indicate the subnet number What criteria can be used to choose one of these five schemes First should we use a self encoding scheme And should it be possible to tell from examining an Internet address if it refers to a subnetted network without reference to any other information An interesting feature of self encoding is that it allows the Mogul Postel Page 4 RFC 950 August 1985 Internet Standard Subnetting Procedure address space of a network to be divided into subnets of different sizes typically one subnet of half the address space and a set of small subnets For example consider a class C network that uses a self encoding scheme with one bit to indicate if it is the large subnet or not and an additional three bits to identify the small subnet If the first bit is zero then this is the large subnet if the first bit is one then the following bits 3 in this example give the subnet number There is one subnet with 128 host addresses and eight subnets with 16 hosts each To establish a subnetting standard the parameters and interpretation of the self encoding scheme must be fixed and consistent throughout the Internet It could be assumed that all networks are subnetted This would allow addresses to be interpreted without reference to any other information This is a significant advantage that given the Internet address no additional information is needed for an implementation to determine if two addresses are on the same subnet However this can also be viewed as a disadvantage it may cause problems for networks which have existing host numbers that use arbitrary bits in the local address part In other words it is useful to be able to control whether a network is subnetted independently from the assignment of host addresses The alternative is to have the fact that a network is subnetted kept separate from the address If one finds somehow that the network is subnetted then the standard self encoded subnetted network address rules are followed otherwise the non subnetted network addressing rules are followed If a self encoding scheme is not used there is no reason to use a fixed width field scheme since there must in any case be some per network flag to indicate if subnets are in use the additional cost of using an integer a subnet field width or address mask instead of a boolean is negligible The advantage of using the address mask scheme is that it allows each organization to choose the best way to allocate relatively scarce bits of local address to subnet and host numbers Therefore we choose the address mask scheme it is the most flexible scheme yet costs no more to implement than any other Mogul Postel Page 5 RFC 950 August 1985 Internet Standard Subnetting Procedure For example the Internet address might be interpreted as where the field is as defined by IP 3 the field is at least 1 bit wide and the width of the field is constant for a given network No further structure is required for the or fields If the width of the field is zero then the network is not subnetted i e the interpretation of 3 is used For example on a Class B network with a 6 bit wide subnet field an address would be broken down like this 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1 0 NETWORK SUBNET Host Number Since the bits that identify the subnet are specified by a bitmask they need not be adjacent in the address However we recommend that the subnet bits be contiguous and located as the most significant bits of the local address Special Addresses From the Assigned Numbers memo 9 In certain contexts it is useful to have fixed addresses with functional significance rather than as identifiers of specific hosts When such usage is called for the address zero is to be interpreted as meaning this as in this network The address of all ones are to be interpreted as meaning all as in all hosts For example the address 128 9 255 255 could be interpreted as meaning all hosts on the network 128 9 Or the address 0 0 0 37 could be interpreted as meaning host 37 on this network It is useful to preserve and extend the interpretation of these special addresses in subnetted networks This means the values of all zeros and all ones in the subnet field should not be assigned to actual physical subnets In the example above the 6 bit wide subnet field may have any value except 0 and 63 Mogul Postel Page 6 RFC 950 August 1985 Internet Standard Subnetting Procedure Please note that there is no effect or new restriction on the addresses of hosts on non subnetted networks 2 2 Changes to Host Software to Support Subnets In most implementations of IP there is code in the module that handles outgoing datagrams to decide if a datagram can be sent directly to the destination on the local network or if it must be sent to a gateway Generally the code is something like this IF ip net number dg ip dest ip net number my ip addr THEN send dg locally dg dg ip dest ELSE send dg locally dg gateway to ip net number dg ip dest If the code supports multiply connected networks it will be more complicated but this is irrelevant to the current discussion To support subnets it is necessary to store one more 32 bit quantity called my ip mask This is a bit mask with bits set in the fields corresponding to the IP network number and additional bits set corresponding to the subnet number field The code then becomes IF bitwise and dg ip dest my ip mask bitwise and my ip addr my ip mask THEN send dg locally dg dg ip dest ELSE send dg locally dg gateway to bitwise and dg ip dest my ip mask Of course part of the expression in the conditional can be pre computed It may or may not be necessary to modify the gateway to function so that it too takes the subnet field bits into account when performing comparisons To support multiply connected hosts the code can be changed to Mogul Postel Page 7 RFC 950 August 1985 Internet Standard Subnetting Procedure keep the my ip addr and my ip mask quantities on a per interface basis the expression in the conditional must then be evaluated for each interface 2 3 Finding the Address Mask How can a host determine what address mask is in use on a subnet to which it is connected The problem is analogous to several other bootstrapping problems for Internet hosts how a host determines its own address and how it locates a gateway on its local network In all three cases there are two basic solutions hardwired information and broadcast based protocols Hardwired information is that available to a host in isolation from a network It may be compiled in or preferably stored in a disk file However for the increasingly common case of a diskless workstation that is bootloaded over a LAN neither hardwired solution is satisfactory Instead since most LAN technology supports broadcasting a better method is for the newly booted host to broadcast a request for the necessary information For example for the purpose of determining its Internet address a host may use the Reverse Address Resolution Protocol RARP 4 However since a newly booted host usually needs to gather several facts e g its IP address the hardware address of a gateway the IP address of a domain name server the subnet address mask it would be better to acquire all this information in one request if possible rather than doing numerous broadcasts on the network The mechanisms designed to boot diskless workstations can also load per host specific configuration files that contain the required information e g see RFC 951 8 It is possible and desirable to obtain all the facts necessary to operate a host from a boot server using only one broadcast message In the case where it is necessary for a host to find the address mask as a separate operation the following mechanism is provided To provide the address mask information the ICMP protocol 5 is extended by adding a new pair of ICMP message types Address Mask Request and Address Mask Reply analogous to the Information Request and Information Reply ICMP messages These are described in detail in Appendix I The intended use of these new ICMP messages is that a host when booting broadcast an Address Mask Request message A Mogul Postel Page 8 RFC 950 August 1985 Internet Standard Subnetting Procedure gateway or a host acting in lieu of a gateway that receives this message responds with an Address Mask Reply If there is no indication in the request which host sent it i e the IP Source Address is zero the reply is broadcast as well The requesting host will hear the response and from it determine the address mask Since there is only one possible value that can be sent in an Address Mask Reply on any given LAN there is no need for the requesting host to match the responses it hears against the request it sent similarly there is no problem if more than one gateway responds We assume that hosts reboot infrequently so the broadcast load on a network from use of this protocol should be small If a host is connected to more than one LAN it might have to find the address mask for each One potential problem is what a host should do if it can not find out the address mask even after a reasonable number of tries Three interpretations can be placed on the situation 1 The local net exists in permanent isolation from all other nets 2 Subnets are not in use and no host can supply the address mask 3 All gateways on the local net are temporarily down The first and second situations imply that the address mask is identical with the Internet network number mask In the third situation there is no way to determine what the proper value is the safest choice is thus a mask identical with the Internet network number mask Although this might later turn out to be wrong it will not prevent transmissions that would otherwise succeed It is possible for a host to recover from a wrong choice when a gateway comes up it should broadcast an Address Mask Reply when a host receives such a message that disagrees with its guess it should change its mask to conform to the received value No host or gateway should send an Address Mask Reply based on a guessed value Finally note that no host is required to use this ICMP protocol to discover the address mask it is perfectly reasonable for a host with non volatile storage to use stored information including a configuration file from a boot server Mogul Postel Page 9 RFC 950 August 1985 Internet Standard Subnetting Procedure Appendix I Address Mask ICMP Address Mask Request or Address Mask Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type Code Checksum Identifier Sequence Number Address Mask IP Fields Addresses The address of the source in an address mask request message will be the destination of the address mask reply message To form an address mask reply message the source address of the request becomes the destination address of the reply the source address of the reply is set to the replier s address the type code changed to AM2 the address mask value inserted into the Address Mask field and the checksum recomputed However if the source address in the request message is zero then the destination address for the reply message should denote a broadcast ICMP Fields Type AM1 for address mask request message AM2 for address mask reply message Code 0 for address mask request message 0 for address mask reply message Checksum The checksum is the 16 bit one s complement of the one s Mogul Postel Page 10 RFC 950 August 1985 Internet Standard Subnetting Procedure complement sum of the ICMP message starting with the ICMP Type For computing the checksum the checksum field should be zero This checksum may be replaced in the future Identifier An identifier to aid in matching requests and replies may be zero Sequence Number A sequence number to aid in matching requests and replies may be zero Address Mask A 32 bit mask Description A gateway receiving an address mask request should return it with the address mask field set to the 32 bit mask of the bits identifying the subnet and network for the subnet on which the request was received If the requesting host does not know its own IP address it may leave the source field zero the reply should then be broadcast However this approach should be avoided if at all possible since it increases the superfluous broadcast load on the network Even when the replies are broadcast since there is only one possible address mask for a subnet there is no need to match requests with replies The Identifier and Sequence Number fields can be ignored Type AM1 may be received from a gateway or a host Type AM2 may be received from a gateway or a host acting in lieu of a gateway Mogul Postel Page 11 RFC 950 August 1985 Internet Standard Subnetting Procedure Appendix II Examples These examples show how a host can find out the address mask using the ICMP Address Mask Request and Address Mask Reply messages For the following examples assume that address 255 255 255 255 denotes broadcast to this physical medium 6 1 A Class A Network Case For this case assume that the requesting host is on class A network 36 0 0 0 has address 36 40 0 123 that there is a gateway at 36 40 0 62 and that a 8 bit wide subnet field is in use that is the address mask is 255 255 0 0 The most efficient method and the one we recommend is for a host to first discover its own address perhaps using RARP 4 and then to send the ICMP request to 255 255 255 255 Source address 36 40 0 123 Destination address 255 255 255 255 Protocol ICMP 1 Type Address Mask Request AM1 Code 0 Mask 0 The gateway can then respond directly to the requesting host Source address 36 40 0 62 Destination address 36 40 0 123 Protocol ICMP 1 Type Address Mask Reply AM2 Code 0 Mask 255 255 0 0 Suppose that 36 40 0 123 is a diskless workstation and does not know even its own host number It could send the following datagram Source address 0 0 0 0 Destination address 255 255 255 255 Protocol ICMP 1 Type Address Mask Request AM1 Code 0 Mask 0 36 40 0 62 will hear the datagram and should respond with this datagram Mogul Postel Page 12 RFC 950 August 1985 Internet Standard Subnetting Procedure Source address 36 40 0 62 Destination address 255 255 255 255 Protocol ICMP 1 Type Address Mask Reply AM2 Code 0 Mask 255 255 0 0 Note that the gateway uses the narrowest possible broadcast to reply Even so the over use of broadcasts presents an unnecessary load to all hosts on the subnet and so the use of the anonymous 0 0 0 0 source address must be kept to a minimum If broadcasting is not allowed we assume that hosts have wired in information about neighbor gateways thus 36 40 0 123 might send this datagram Source address 36 40 0 123 Destination address 36 40 0 62 Protocol ICMP 1 Type Address Mask Request AM1 Code 0 Mask 0 36 40 0 62 should respond exactly as

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0950.txt (2016-02-14)
    Open archived version from archive


  • it should take steps to discourage others from sending them such as using the TCP Maximum Segment Size option 4 Note Datagrams on the Ethernet may be longer than the general Internet default maximum packet size of 576 octets Hosts connected to an Ethernet should keep this in mind when sending datagrams to hosts not on the same Ethernet It may be appropriate to send smaller datagrams to avoid unnecessary fragmentation at intermediate gateways Please see 4 for further information on this point Hornig Page 1 RFC 894 April 1984 Address Mappings The mapping of 32 bit Internet addresses to 48 bit Ethernet addresses can be done several ways A static table could be used or a dynamic discovery procedure could be used Static Table Each host could be provided with a table of all other hosts on the local network with both their Ethernet and Internet addresses Dynamic Discovery Mappings between 32 bit Internet addresses and 48 bit Ethernet addresses could be accomplished through the Address Resolution Protocol ARP 5 Internet addresses are assigned arbitrarily on some Internet network Each host s implementation must know its own Internet address and respond to Ethernet Address Resolution packets appropriately It should also use ARP to translate Internet addresses to Ethernet addresses when needed Broadcast Address The broadcast Internet address the address on that network with a host part of all binary ones should be mapped to the broadcast Ethernet address of all binary ones FF FF FF FF FF FF hex The use of the ARP dynamic discovery procedure is strongly recommended Trailer Formats Some versions of Unix 4 2bsd use a different encapsulation method in order to get better network performance with the VAX virtual memory architecture Consenting systems on the same Ethernet may use this format between themselves No

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0894.txt (2016-02-14)
    Open archived version from archive



  •