home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / ppp / 729 < prev    next >
Encoding:
Text File  |  1992-08-27  |  2.7 KB  |  59 lines
  1. Newsgroups: comp.protocols.ppp
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!mstar!mstar!bob
  3. From: bob@MorningStar.Com (Bob Sutterfield)
  4. Subject: Re: IP address allocation
  5. In-Reply-To: ccewch@nuscc.nus.sg's message of Thu, 27 Aug 1992 07: 21:54 GMT
  6. Message-ID: <BOB.92Aug27140952@volitans.MorningStar.Com>
  7. Sender: news@MorningStar.Com
  8. Nntp-Posting-Host: volitans.morningstar.com
  9. Organization: Morning Star Technologies
  10. References: <1992Aug27.072154.20745@nuscc.nus.sg>
  11. Date: Thu, 27 Aug 1992 18:10:01 GMT
  12. Lines: 45
  13.  
  14. In article <1992Aug27.072154.20745@nuscc.nus.sg> ccewch@nuscc.nus.sg (Wong Chee Heng) writes:
  15.    I just want to know how IP address is allocated in PPP, does the
  16.    end user has to set it of the host being dialed can actually
  17.    allocate before hand?
  18.  
  19. PPP provides the mechanism, but the implementation and the user must
  20. specify the policy.  
  21.  
  22. Here's the mechanism: Before exchanging IP packets across a PPP link,
  23. the peers must agree on link parameters like packet size, control
  24. character encoding, etc. during the LCP (Link Control Protocol)
  25. negotiation phase.  Then they must agree on IP addresses and TCP
  26. header compression parameters during the IPCP (IP Control Protocol)
  27. negotiation phase.  Then they're finally ready to exchange user data
  28. packets.  (By the way, all this negotiation happens very quickly,
  29. typically requiring only two packet round-trip times, which amounts to
  30. a few tenths of a second over dial-up modems.)
  31.  
  32. Here's the policy: whatever semantics you want to attach to the values
  33. agreed upon during IPCP negotiation.  For example, a calling peer and
  34. an answering peermight tell each other their addresses, but at least
  35. the calling peer already knew the answering peer's address before
  36. calling (how else would it know that it wanted to call?).  Or maybe
  37. the calling peer waits for the answering peer to say what the
  38. answering peer wants the calling peer's address to be, and then the
  39. calling peer configures itself accordingly.  
  40.  
  41. If the PPP package is flexible enough, the user can implement just
  42. about any policy {s}he can imagine.  Consider what you could do with
  43. creative DNS hacquery and a shell (or Perl) script, wrapped around a
  44. PPP invocation...
  45.  
  46.    Also what are the advantage of PPP over slip? 
  47.  
  48. Read the Deficiencies section of RFC 1055, and the Introductions of
  49. RFCs 1331, 1332, and 1333.  You may also find some useful comparisons
  50. in the paper I presented at last December's Sun User Group conference.
  51. Get ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z.
  52.  
  53.    Is there a FAQ somewhere that I can find answers to my questions?
  54.  
  55. Ed Vielmetti was maintaining merit.edu:pub/ppp/emv-ppp-faq-0.1.txt for
  56. a while, but it hasn't been updated recently.  Still, it's fresh
  57. enough that you should be able to find something useful by using its
  58. pointers.
  59.