home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipngwg-ipv6-over-ppp-02.txt < prev    next >
Text File  |  1997-07-02  |  29KB  |  825 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.      Internet Engineering Task Force
  7.      INTERNET-DRAFT                                  Dimitry Haskin
  8.      Expires January 1998                            Ed Allen
  9.      <draft-ietf-ipngwg-ipv6-over-ppp-02.txt>        Bay Networks, Inc.
  10.                                                      July 1997
  11.  
  12.  
  13.                              IP Version 6 over PPP
  14.  
  15.  
  16.      Status of this Memo
  17.  
  18.      This document  is  an  Internet-Draft.   Internet-Drafts  are  working
  19.      documents  of  the  Internet Engineering Task Force (IETF), its areas,
  20.      and its working groups. Note that other  groups  may  also  distribute
  21.      working documents as Internet-Drafts.
  22.  
  23.      Internet-Drafts are draft documents valid for a maximum of six months.
  24.      Internet-Drafts  may  be  updated,  replaced,  or  obsoleted  by other
  25.      documents at any time.  It is not appropriate to  use  Internet-Drafts
  26.      as  reference  material  or  to  cite  them  other than as a ``working
  27.      draft'' or ``work in progress.''
  28.  
  29.      To learn the current status of any Internet-Draft,  please  check  the
  30.      ``1id-abstracts.txt''  listing contained in the Internet-Drafts Shadow
  31.      Directories  on   ftp.is.co.za   (Africa),   nic.nordu.net   (Europe),
  32.      munnari.oz.au  (Pacific  Rim),  ds.internic.net  (US  East  Coast), or
  33.      ftp.isi.edu (US West Coast).
  34.  
  35.  
  36.      Abstract
  37.  
  38.      The Point-to-Point Protocol (PPP) [1] provides a  standard  method  of
  39.      encapsulating  Network  Layer protocol information over point-to-point
  40.      links.  PPP also defines an  extensible  Link  Control  Protocol,  and
  41.      proposes a family of Network Control Protocols (NCPs) for establishing
  42.      and configuring different network-layer protocols.
  43.  
  44.      This document defines the method for transmission of IP Version 6  [2]
  45.      packets  over  PPP links as well as the Network Control Protocol (NCP)
  46.      for establishing and configuring the IPv6 over PPP. It also  specifies
  47.      the method of forming IPv6 link-local addresses on PPP links.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.      Expires January 1998                                          [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.  
  62.      Internet-Draft          IP Version 6 over PPP                July 1997
  63.  
  64.  
  65.      Table of Contents
  66.  
  67.  
  68.         1.     Introduction ..........................................    3
  69.              1.1.  Specification of Requirements ......................   3
  70.         2.     Sending IPv6 Datagrams ................................    4
  71.         3.     A PPP Network Control Protocol for IPv6 ...............    4
  72.         4.     IPV6CP Configuration Options ..........................    5
  73.              4.1.  Interface-Token ...................................    5
  74.              4.2.  IPv6-Compression-Protocol..........................   11
  75.         5.     Stateless Autoconfiguration and Link-Local Addresses ..   12
  76.         6.     IPV6CP Recommended Options .............................  13
  77.         Security Considerations .......................................  13
  78.         References ....................................................  13
  79.         Acknowledgments ...............................................  14
  80.         Authors' Addresses ............................................  14
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.      Expires January 1998                                          [Page 2]
  116.  
  117.  
  118.  
  119.  
  120.  
  121.      Internet-Draft          IP Version 6 over PPP                July 1997
  122.  
  123.  
  124.      1.  Introduction
  125.  
  126.      PPP has three main components:
  127.  
  128.      1.   A method for encapsulating datagrams over serial links.
  129.  
  130.      2.   A Link Control Protocol (LCP) for establishing, configuring,  and
  131.           testing the data-link connection.
  132.  
  133.      3.   A family of Network Control Protocols (NCPs) for establishing and
  134.           configuring different network-layer protocols.
  135.  
  136.      In order to establish communications over a point-to-point link,  each
  137.      end  of the PPP link must first send LCP packets to configure and test
  138.      the data link.  After the  link  has  been  established  and  optional
  139.      facilities  have  been  negotiated as needed by the LCP, PPP must send
  140.      NCP  packets  to  choose  and  configure  one  or  more  network-layer
  141.      protocols.   Once  each of the chosen network-layer protocols has been
  142.      configured,  datagrams from each network-layer protocol  can  be  sent
  143.      over the link.
  144.  
  145.      In this document, the NCP for establishing and  configuring  the  IPv6
  146.      over PPP is referred as the IPv6 Control Protocol (IPV6CP).
  147.  
  148.      The link will remain configured for communications until explicit  LCP
  149.      or  NCP  packets  close  the  link down,  or until some external event
  150.      occurs (power failure at the other end, carrier drop, etc.).
  151.  
  152.  
  153.      1.1.  Specification of Requirements
  154.  
  155.      In this document, several words are used to signify  the  requirements
  156.      of the specification.  These words are often capitalized.
  157.  
  158.  
  159.      MUST       This word, or the adjective "required", means that the 
  160.                 definition is an absolute requirement of the specification.
  161.  
  162.      MUST NOT   This phrase means that the definition is an absolute   
  163.                 prohibition of the specification.          
  164.  
  165.      SHOULD     This word, or the adjective "recommended", means that there
  166.                 may exist  valid  reasons  in particular circumstances to
  167.                 ignore this item, but the full implications must be
  168.                 understood and  carefully weighed before choosing 
  169.                 a different course.
  170.  
  171.  
  172.  
  173.  
  174.      Expires January 1998                                          [Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180.      Internet-Draft          IP Version 6 over PPP                July 1997
  181.  
  182.  
  183.      MAY        This word, or the adjective "optional", means that this
  184.                 item  is one  of  an allowed set of alternatives.  An 
  185.                 implementation which does not include this option MUST be  
  186.                 prepared  to  inter-operate with another implementation 
  187.                 which does include the option.
  188.  
  189.  
  190.      2.  Sending IPv6 Datagrams
  191.  
  192.      Before any IPv6 packets  may  be  communicated,  PPP  MUST  reach  the
  193.      Network-Layer Protocol phase, and the IPv6 Control Protocol MUST reach
  194.      the Opened state.
  195.  
  196.      Exactly one IPv6 packet is encapsulated in the  Information  field  of
  197.      PPP Data Link Layer frames where the Protocol field indicates type hex
  198.      0057 (Internet Protocol Version 6).
  199.  
  200.      The maximum length of an IPv6 packet transmitted over a  PPP  link  is
  201.      the  same as the maximum length of the Information field of a PPP data
  202.      link layer frame.  PPP links supporting IPv6 MUST allow at  least  576
  203.      octets in the information field of a data link layer frame.
  204.  
  205.  
  206.      3.  A PPP Network Control Protocol for IPv6
  207.  
  208.      The IPv6 Control Protocol (IPV6CP)  is  responsible  for  configuring,
  209.      enabling,  and disabling the IPv6 protocol modules on both ends of the
  210.      point-to-point link.  IPV6CP uses the same packet  exchange  mechanism
  211.      as  the  Link  Control  Protocol  (LCP).   IPV6CP  packets  may not be
  212.      exchanged until PPP has  reached  the  Network-Layer  Protocol  phase.
  213.      IPV6CP  packets  received  before  this  phase  is  reached  should be
  214.      silently discarded.
  215.  
  216.      The IPv6 Control Protocol is exactly the  same  as  the  Link  Control
  217.      Protocol [1] with the following exceptions:
  218.  
  219.        Data Link Layer Protocol Field
  220.  
  221.             Exactly one IPV6CP packet is encapsulated  in  the  Information
  222.             field  of  PPP  Data Link Layer frames where the Protocol field
  223.             indicates type hex 8057 (IPv6 Control Protocol).
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.      Expires January 1998                                          [Page 4]
  234.  
  235.  
  236.  
  237.  
  238.  
  239.      Internet-Draft          IP Version 6 over PPP                July 1997
  240.  
  241.  
  242.        Code field
  243.  
  244.             Only  Codes  1  through  7  (Configure-Request,  Configure-Ack,
  245.             Configure-Nak,  Configure-Reject, Terminate-Request, Terminate-
  246.             Ack and Code-Reject) are used.  Other Codes should  be  treated
  247.             as unrecognized and should result in Code-Rejects.
  248.  
  249.        Timeouts
  250.  
  251.             IPV6CP packets may not be exchanged until PPP has  reached  the
  252.             Network-Layer  Protocol  phase.   An  implementation  should be
  253.             prepared  to  wait  for   Authentication   and   Link   Quality
  254.             Determination  to  finish  before  timing  out  waiting  for  a
  255.             Configure-Ack or other  response.   It  is  suggested  that  an
  256.             implementation  give  up  only  after  user  intervention  or a
  257.             configurable amount of time.
  258.  
  259.        Configuration Option Types
  260.  
  261.             IPV6CP has a distinct set of Configuration Options,  which  are
  262.             defined below.
  263.  
  264.  
  265.      4.  IPV6CP Configuration Options
  266.  
  267.      IPV6CP Configuration  Options  allow  negotiation  of  desirable  IPv6
  268.      parameters.   IPV6CP uses the same Configuration Option format defined
  269.      for LCP [1], with a separate  set  of  Options.   If  a  Configuration
  270.      Option  is  not  included  in a Configure-Request packet,  the default
  271.      value for that Configuration Option is assumed.
  272.  
  273.      Up-to-date values of the IPV6CP Option Type field are specified in the
  274.      most  recent  "Assigned Numbers" RFC [4].  Current values are assigned
  275.      as follows:
  276.  
  277.          1       Interface-Token
  278.          2       IPv6-Compression-Protocol
  279.  
  280.  
  281.      4.1.  Interface-Token
  282.  
  283.      Description
  284.  
  285.        This Configuration Option provides a way to negotiate a  unique  64-
  286.        bit interface token to be used for the address autoconfiguration [3]
  287.  
  288.  
  289.  
  290.  
  291.  
  292.      Expires January 1998                                          [Page 5]
  293.  
  294.  
  295.  
  296.  
  297.  
  298.      Internet-Draft          IP Version 6 over PPP                July 1997
  299.  
  300.  
  301.        at the local end of the link (see section 5).  The  interface  token
  302.        MUST  be  unique  within  the PPP link; i.e.  upon completion of the
  303.        negotiation different Interface-Token values are to be selected  for
  304.        the  ends  of  the PPP link.  The interface token MAY also be unique
  305.        over a broader scope.
  306.  
  307.        Before this Configuration Option  is  requested,  an  implementation
  308.        chooses  its  tentative  Interface-Token.  The non-zero value of the
  309.        tentative Interface-Token SHOULD be chosen such that  the  value  is
  310.        both  unique to the link and, if possible, consistently reproducible
  311.        across  initializations  of  the   IPV6CP   finite   state   machine
  312.        (administrative  Close  and reOpen, reboots, etc). The rationale for
  313.        preferring a consistently reproducible unique token to a  completely
  314.        random  token is to provide stability to global scope addresses that
  315.        can be formed from the interface token.
  316.  
  317.        Assuming that interface token bits are numbered from 0 to  63  where
  318.        the  most  significant  bit is the bit number 0, the bit number 6 is
  319.        the "u" bit (universal/local bit in  IEEE  EUI-64  [5]  terminology)
  320.        which  indicates  whether  or  not the interface token is based on a
  321.        globally unique IEEE identifier (EUI-48 or EUI-64 [5]) (see the case
  322.        1  below). It is set to one (1) if a globally unique IEEE identifier
  323.        is used to derive the interface token, and it is  set  to  zero  (0)
  324.        otherwise.
  325.  
  326.        The following are methods for choosing the tentative Interface Token
  327.        in the preference order:
  328.  
  329.  
  330.        1) If an IEEE global identifier  (EUI-48  or  EUI-64)  is  available
  331.           anywhere  on  the  node,  it  should  be  used  to  construct the
  332.           tentative Interface-Token due to its uniqueness properties.
  333.  
  334.           The only transformation from an EUI-64 identifier  is  to  invert
  335.           the  "u"  bit  (universal/local  bit in IEEE EUI-64 terminology).
  336.           For example, for a globally unique EUI-64 identifier of the form:
  337.  
  338.      most-significant                                    least-significant
  339.      bit                                                               bit
  340.      |0              1|1              3|3              4|4              6|
  341.      |0              5|6              1|2              7|8              3|
  342.      +----------------+----------------+----------------+----------------+
  343.      |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
  344.      +----------------+----------------+----------------+----------------+
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.      Expires January 1998                                          [Page 6]
  352.  
  353.  
  354.  
  355.  
  356.  
  357.      Internet-Draft          IP Version 6 over PPP                July 1997
  358.  
  359.  
  360.           where "c" are the bits of the assigned  company_id,  "0"  is  the
  361.           value of the universal/local bit to indicate global scope, "g" is
  362.           group/individual bit, and "e"  are  the  bits  of  the  extension
  363.           identifier, the IPv6 interface token would be of the form:
  364.  
  365.      most-significant                                    least-significant
  366.      bit                                                               bit
  367.      |0              1|1              3|3              4|4              6|
  368.      |0              5|6              1|2              7|8              3|
  369.      +----------------+----------------+----------------+----------------+
  370.      |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
  371.      +----------------+----------------+----------------+----------------+
  372.  
  373.           The only change is inverting the  value  of  the  universal/local
  374.           bit.
  375.  
  376.           In the case of a EUI-48 identifier, it is first converted to  the
  377.           EUI-64  format by inserting two bytes, with hexadecimal values of
  378.           0xFF and 0xFE, in the middle of  the  48  bit  MAC  (between  the
  379.           company_id   and  extension-identifier  portions  of  the  EUI-48
  380.           value).  For  example,  for  a  globally  unique  48  bit  EUI-48
  381.           identifier of the form:
  382.  
  383.      most-significant                   least-significant
  384.      bit                                              bit
  385.      |0              1|1              3|3              4|
  386.      |0              5|6              1|2              7|
  387.      +----------------+----------------+----------------+
  388.      |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
  389.      +----------------+----------------+----------------+
  390.  
  391.           where "c" are the bits of the assigned  company_id,  "0"  is  the
  392.           value of the universal/local bit to indicate global scope, "g" is
  393.           group/individual bit, and "e"  are  the  bits  of  the  extension
  394.           identifier, the IPv6 interface token would be of the form:
  395.  
  396.      most-significant                                    least-significant
  397.      bit                                                               bit
  398.      |0              1|1              3|3              4|4              6|
  399.      |0              5|6              1|2              7|8              3|
  400.      +----------------+----------------+----------------+----------------+
  401.      |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
  402.      +----------------+----------------+----------------+----------------+
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.      Expires January 1998                                          [Page 7]
  411.  
  412.  
  413.  
  414.  
  415.  
  416.      Internet-Draft          IP Version 6 over PPP                July 1997
  417.  
  418.  
  419.        2) If an IEEE global identifier is not available a different  source
  420.           of  uniqueness  should  be used.  Suggested sources of uniqueness
  421.           include link-layer addresses, machine serial numbers, et cetera.
  422.  
  423.           In this case the "u" bit of the interface token MUST  be  set  to
  424.           zero (0).
  425.  
  426.  
  427.        3) If a good source of uniqueness cannot be found, it is recommended
  428.           that  a  random number be generated.  In this case the "u" bit of
  429.           the interface token MUST be set to zero (0).
  430.  
  431.        Good sources [1] of uniqueness or randomness are  required  for  the
  432.        Interface-Token  negotiation to succeed.  If neither a unique number
  433.        or a random number can be generated it is recommended  that  a  zero
  434.        value  be used for the Interface-Token transmitted in the Configure-
  435.        Request.  In this case the PPP peer may  provide  a  valid  non-zero
  436.        Interface-Token in its response as described below.  Note that if at
  437.        least one of the PPP peers is able  to  generate  separate  non-zero
  438.        numbers for itself and its peer, the token negotiation will succeed.
  439.  
  440.        When  a  Configure-Request  is  received  with  the  Interface-Token
  441.        Configuration  Option and the receiving peer implements this option,
  442.        the received Interface-Token is compared with the Interface-Token of
  443.        the  last  Configure-Request  sent  to  the  peer.  Depending on the
  444.        result of the comparison an implementation MUST respond  in  one  of
  445.        the following ways:
  446.  
  447.        If  the  two  Interface-Tokens  are  different  but   the   received
  448.        Interface-Token  is  zero,  a  Configure-Nak is sent with a non-zero
  449.        Interface-Token value suggested for use by the remote peer.  Such  a
  450.        suggested  Interface-Token  MUST  be  different  from the Interface-
  451.        Token of  the  last  Configure-Request  sent  to  the  peer.  It  is
  452.        recommended  that  the  value suggested be consistently reproducible
  453.        across  initializations  of  the   IPV6CP   finite   state   machine
  454.        (administrative   Close   and   reOpen,   reboots,   etc).  The  "u"
  455.        universal/local) bit of the suggested token MUST be set to zero  (0)
  456.        regardless  of  its  source unless the globally unique EUI-48/EUI-64
  457.        derived token is provided for the exclusive use by the remote peer.
  458.  
  459.        If  the  two  Interface-Tokens  are  different  and   the   received
  460.        Interface-Token   is   not   zero,   the   Interface-Token  MUST  be
  461.        acknowledged, i.e.  a  Configure-Ack  is  sent  with  the  requested
  462.        Interface-Token,  meaning  that  the responding peer agrees with the
  463.        Interface-Token requested.
  464.  
  465.  
  466.  
  467.  
  468.  
  469.      Expires January 1998                                          [Page 8]
  470.  
  471.  
  472.  
  473.  
  474.  
  475.      Internet-Draft          IP Version 6 over PPP                July 1997
  476.  
  477.  
  478.        If  the  two  Interface-Tokens  are  equal  and  are  not  zero,   a
  479.        Configure-Nak   MUST   be   sent  specifying  a  different  non-zero
  480.        Interface-Token value suggested for use by the remote  peer.  It  is
  481.        recommended  that  the  value suggested be consistently reproducible
  482.        across  initializations  of  the   IPV6CP   finite   state   machine
  483.        (administrative   Close   and   reOpen,   reboots,   etc).  The  "u"
  484.        universal/local) bit of the suggested token MUST be set to zero  (0)
  485.        regardless  of  its  source unless the globally unique EUI-48/EUI-64
  486.        derived token is provided for the exclusive use by the remote peer.
  487.  
  488.        If the two Interface-Tokens  are  equal  to  zero,   the  Interface-
  489.        Tokens   negotiation   MUST   be   terminated  by  transmitting  the
  490.        Configure-Reject with the Interface-Token value set to zero. In this
  491.        case a unique Interface-Token can not be negotiated.
  492.  
  493.        If  a  Configure-Request  is  received  with   the   Interface-Token
  494.        Configuration  Option and the receiving peer does not implement this
  495.        option, Configure-Rej is sent.
  496.  
  497.        A new Configure-Request SHOULD NOT be sent to the peer until  normal
  498.        processing would cause it to be sent (that is, until a Configure-Nak
  499.        is received or the Restart timer runs out).
  500.  
  501.        A new Configure-Request MUST NOT contain the Interface-Token  option
  502.        if a valid Interface-Token Configure-Reject is received.
  503.  
  504.        Reception  of  a  Configure-Nak  with  a  suggested  Interface-Token
  505.        different  from  that  of  the  last  Configure-Nak sent to the peer
  506.        indicates a unique Interface-Token.  In this case a  new  Configure-
  507.        Request  MUST  be  sent  with  the token value suggested in the last
  508.        Configure-Nak from the peer.  But if the received Interface-Token is
  509.        equal  to  the one sent in the last Configure- Nak, a new Interface-
  510.        Token MUST be chosen.  In this case, a new Configure-Request  SHOULD
  511.        be  sent  with  the  new  tentative  Interface-Token.  This sequence
  512.        (transmit  Configure-Request,  receive  Configure-Request,  transmit
  513.        Configure-Nak,  receive  Configure-Nak) might occur a few times, but
  514.        it is extremely unlikely to  occur  repeatedly.   More  likely,  the
  515.        Interface-Tokens   chosen   at  either  end  will  quickly  diverge,
  516.        terminating the sequence.
  517.  
  518.        If negotiation of the Interface-Token is required, and the peer  did
  519.        not  provide  the option in its Configure-Request, the option SHOULD
  520.        be  appended  to  a  Configure-Nak.   The  tentative  value  of  the
  521.        Interface-Token  given  must  be acceptable as the remote Interface-
  522.        Token; i.e. it should be different from the token value selected for
  523.  
  524.  
  525.  
  526.  
  527.  
  528.      Expires January 1998                                          [Page 9]
  529.  
  530.  
  531.  
  532.  
  533.  
  534.      Internet-Draft          IP Version 6 over PPP                July 1997
  535.  
  536.  
  537.        the  local end of the PPP link.  The next Configure-Request from the
  538.        peer may include this option.  If the  next  Configure-Request  does
  539.        not include this option the peer MUST NOT send another Configure-Nak
  540.        with  this  option  included.  It  should  assume  that  the  peer's
  541.        implementation does not support this option.
  542.  
  543.        By default,  an  implementation  SHOULD  attempt  to  negotiate  the
  544.        Interface-Token for its end of the PPP connection.
  545.  
  546.      A summary of the Interface-Token Configuration Option format is  shown
  547.      below.  The fields are transmitted from left to right.
  548.  
  549.      0                   1                   2                   3
  550.      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
  551.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  552.      |     Type      |    Length     |    Interface-Token (MS Bytes)
  553.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  554.                           Interface-Token (cont)
  555.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  556.           Interface-Token (LS Bytes) |
  557.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  558.  
  559.        Type
  560.  
  561.          1
  562.  
  563.        Length
  564.  
  565.          10
  566.  
  567.        Interface-Token
  568.  
  569.          The 64-bit Interface-Token which is very likely to  be  unique  on
  570.          the link or zero if a good source of uniqueness can not be found.
  571.  
  572.        Default Token Value
  573.  
  574.          If no valid interface token can  be  successfully  negotiated,  no
  575.          default  Interface-Token  value  should be assumed. The procedures
  576.          for recovering from such a case are unspecified. One  approach  is
  577.          to manually configure the interface token of the interface.
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.      Expires January 1998                                         [Page 10]
  588.  
  589.  
  590.  
  591.  
  592.  
  593.      Internet-Draft          IP Version 6 over PPP                July 1997
  594.  
  595.  
  596.      4.2.  IPv6-Compression-Protocol
  597.  
  598.      Description
  599.  
  600.        This Configuration Option provides a way to negotiate the use  of  a
  601.        specific  IPv6  packet  compression protocol.  The IPv6-Compression-
  602.        Protocol Configuration Option is used to  indicate  the  ability  to
  603.        receive  compressed  packets.   Each end of the link must separately
  604.        request this option if bi-directional compression  is  desired.   By
  605.        default, compression is not enabled.
  606.  
  607.        IPv6 compression negotiated with this option  is  specific  to  IPv6
  608.        datagrams  and is not to be confused with compression resulting from
  609.        negotiations  via  Compression   Control   Protocol   (CCP),   which
  610.        potentially effect all datagrams.
  611.  
  612.      A summary of the IPv6-Compression-Protocol Configuration Option format
  613.      is shown below.  The fields are transmitted from left to right.
  614.  
  615.      0                   1                   2                   3
  616.      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
  617.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  618.      |     Type      |    Length     |   IPv6-Compression-Protocol   |
  619.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  620.      |    Data ...
  621.      +-+-+-+-+
  622.  
  623.        Type
  624.  
  625.          2
  626.  
  627.        Length
  628.  
  629.          >= 4
  630.  
  631.        IPv6-Compression-Protocol
  632.  
  633.          The IPv6-Compression-Protocol field is two  octets  and  indicates
  634.          the  compression  protocol  desired.   Values  for  this field are
  635.          always the same as the PPP Data Link Layer Protocol  field  values
  636.          for that same compression protocol.
  637.  
  638.          Up-to-date  values  of  the  IPv6-Compression-Protocol  field  are
  639.          specified in the most recent "Assigned Numbers" RFC [4].
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.      Expires January 1998                                         [Page 11]
  647.  
  648.  
  649.  
  650.  
  651.  
  652.      Internet-Draft          IP Version 6 over PPP                July 1997
  653.  
  654.  
  655.          Current values are assigned as follows:
  656.  
  657.            Value (in hex)          Protocol
  658.  
  659.            004f                    IPv6 Header Compression
  660.  
  661.        Data
  662.  
  663.          The Data field is zero or more octets and contains additional data
  664.          as determined by the particular compression protocol.
  665.  
  666.        Default
  667.  
  668.          No IPv6 compression protocol enabled.
  669.  
  670.  
  671.  
  672.      5.  Stateless Autoconfiguration and Link-Local Addresses
  673.  
  674.      The interface token, which is used as the Interface ID of IPv6 unicast
  675.      addresses  [6]  of a PPP interface, SHOULD be negotiated in the IPV6CP
  676.      phase of the PPP connection setup  (see  section  4.1).  If  no  valid
  677.      interface  token  has  been  successfully  negotiated,  procedures for
  678.      recovering from such a case  are  unspecified.   One  approach  is  to
  679.      manually configure the interface token of the interface.
  680.  
  681.      As long as the interface token is negotiated in the  IPV6CP  phase  of
  682.      the  PPP  connection  setup,   it  is  redundant  to perform duplicate
  683.      address detection as a part of the  IPv6  Stateless  Autoconfiguration
  684.      protocol [3].  Therefore it is recommended that for PPP links with the
  685.      IPV6CP  Interface-Token  option  enabled  the  default  value  of  the
  686.      DupAddrDetectTransmits autoconfiguration variable [3] be zero.
  687.  
  688.      Link-local addresses of PPP interfaces have the following format:
  689.  
  690.      | 10 bits  |        54 bits         |          64 bits            |
  691.      +----------+------------------------+-----------------------------+
  692.      |1111111010|           0            |      Interface Token        |
  693.      +----------+------------------------+-----------------------------+
  694.  
  695.      The most significant 10 bits of the address is the  Link-Local  prefix
  696.      FE80::.   54  zero  bits  pad  out  the address between the Link-Local
  697.      prefix and the Interface Token fields.
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.      Expires January 1998                                         [Page 12]
  706.  
  707.  
  708.  
  709.  
  710.  
  711.      Internet-Draft          IP Version 6 over PPP                July 1997
  712.  
  713.  
  714.      6.  IPV6CP Recommended Options
  715.  
  716.      The following Configurations Options are recommended:
  717.  
  718.        Interface-Token
  719.  
  720.        IPv6-Compression-Protocol
  721.  
  722.  
  723.      7.  Security Considerations
  724.  
  725.      The IPv6 Control Protocol extension  to  PPP  can  be  used  with  all
  726.      defined PPP authentication and encryption mechanisms.
  727.  
  728.  
  729.      8.  References
  730.  
  731.      [1]  Simpson, W., "The Point-to-Point Protocol",  STD  51,  RFC  1661,
  732.           July 1994.
  733.  
  734.      [2]  Deering, S., and R. Hinden, Editors, "Internet Protocol,  Version
  735.           6 (IPv6) Specification", RFC 1883, December 1995.
  736.  
  737.      [3]  Thomson,   S.,   and   T.   Narten,   "IPv6   Stateless   Address
  738.           Autoconfiguration", RFC 1971, August 1996.
  739.  
  740.      [4]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  741.           October 1994.
  742.  
  743.      [5]  IEEE,  "Guidelines  for   64-bit   Global   Identifier   (EUI-64)
  744.           Registration Authority",
  745.           http://standards.ieee.org/db/oui/tutorials/EUI64.html,
  746.           March 1997.
  747.  
  748.      [6]  Hinden,  R.,  and  S.   Deering,   "IP   Version   6   Addressing
  749.           Architecture", Work in progress
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.      Expires January 1998                                         [Page 13]
  765.  
  766.  
  767.  
  768.  
  769.  
  770.      Internet-Draft          IP Version 6 over PPP                July 1997
  771.  
  772.  
  773.      9.  Acknowledgements
  774.  
  775.      This document borrows from the Magic-Number LCP option and as such  is
  776.      partially based on previous work done by the PPP working group.
  777.  
  778.  
  779.  
  780.      10.  Authors' Addresses
  781.  
  782.         Dimitry Haskin
  783.         Bay Networks, Inc.
  784.         2 Federal Street
  785.         Billerica, MA 01821
  786.         email: dhaskin@baynetworks.com
  787.  
  788.         Ed Allen
  789.         Bay Networks, Inc.
  790.         2 Federal Street
  791.         Billerica, MA 01821
  792.         email: eallen@baynetworks.com
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.      Expires January 1998                                         [Page 14]
  824.  
  825.