Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2661

Layer Two Tunneling Protocol "L2TP"

Pages: 80
Proposed Standard
Errata
Updated by:  9601
Part 2 of 4 – Pages 12 to 40
First   Prev   Next

Top   ToC   RFC2661 - Page 12   prevText

4.0 Control Message Attribute Value Pairs

To maximize extensibility while still permitting interoperability, a uniform method for encoding message types and bodies is used throughout L2TP. This encoding will be termed AVP (Attribute-Value Pair) in the remainder of this document.
Top   ToC   RFC2661 - Page 13

4.1 AVP Format

Each AVP is encoded as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Attribute Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [until Length is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first six bits are a bit mask, describing the general attributes of the AVP. Two bits are defined in this document, the remaining are reserved for future extensions. Reserved bits MUST be set to 0. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP. Mandatory (M) bit: Controls the behavior required of an implementation which receives an AVP which it does not recognize. If the M bit is set on an unrecognized AVP within a message associated with a particular session, the session associated with this message MUST be terminated. If the M bit is set on an unrecognized AVP within a message associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If the M bit is not set, an unrecognized AVP MUST be ignored. The control message must then continue to be processed as if the AVP had not been present. Hidden (H) bit: Identifies the hiding of data in the Attribute Value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP. Section 4.3 describes the procedure for performing AVP hiding. Length: Encodes the number of octets (including the Overall Length and bitmask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets. The field itself is 10 bits, permitting a maximum of 1023 octets of data in a single AVP. The minimum Length of an AVP is 6. If the length is 6, then the Attribute Value field is absent. Vendor ID: The IANA assigned "SMI Network Management Private Enterprise Codes" [RFC1700] value. The value 0, corresponding to IETF adopted attribute values, is used for all AVPs defined within this document. Any vendor wishing to implement their own L2TP extensions can use their own Vendor ID along with private Attribute
Top   ToC   RFC2661 - Page 14
   values, guaranteeing that they will not collide with any other
   vendor's extensions, nor with future IETF extensions. Note that there
   are 16 bits allocated for the Vendor ID, thus limiting this feature
   to the first 65,535 enterprises.

   Attribute Type: A 2 octet value with a unique interpretation across
   all AVPs defined under a given Vendor ID.

   Attribute Value: This is the actual value as indicated by the Vendor
   ID and Attribute Type. It follows immediately after the Attribute
   Type field, and runs for the remaining octets indicated in the Length
   (i.e., Length minus 6 octets of header). This field is absent if the
   Length is 6.

4.2 Mandatory AVPs

Receipt of an unknown AVP that has the M-bit set is catastrophic to the session or tunnel it is associated with. Thus, the M bit should only be defined for AVPs which are absolutely crucial to proper operation of the session or tunnel. Further, in the case where the LAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel accordingly, it is the full responsibility of the peer sending the Mandatory AVP to accept fault for causing an non-interoperable situation. Before defining an AVP with the M-bit set, particularly a vendor-specific AVP, be sure that this is the intended consequence. When an adequate alternative exists to use of the M-bit, it should be utilized. For example, rather than simply sending an AVP with the M- bit set to determine if a specific extension exists, availability may be identified by sending an AVP in a request message and expecting a corresponding AVP in a reply message. Use of the M-bit with new AVPs (those not defined in this document) MUST provide the ability to configure the associated feature off, such that the AVP is either not sent, or sent with the M-bit not set.

4.3 Hiding of AVP Attribute Values

The H bit in the header of each AVP provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden or present in cleartext. This feature can be used to hide sensitive control message data such as user passwords or user IDs. The H bit MUST only be set if a shared secret exists between the LAC and LNS. The shared secret is the same secret that is used for tunnel authentication (see Section 5.1.1). If the H bit is set in any
Top   ToC   RFC2661 - Page 15
   AVP(s) in a given control message, a Random Vector AVP must also be
   present in the message and MUST precede the first AVP having an H bit
   of 1.

   Hiding an AVP value is done in several steps. The first step is to
   take the length and value fields of the original (cleartext) AVP and
   encode them into a Hidden AVP Subformat as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length of Original Value    |   Original Attribute Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...                          |             Padding ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length of Original Attribute Value:  This is length of the Original
   Attribute Value to be obscured in octets. This is necessary to
   determine the original length of the Attribute Value which is lost
   when the additional Padding is added.

   Original Attribute Value:  Attribute Value that is to be obscured.

   Padding:  Random additional octets used to obscure length of the
   Attribute Value that is being hidden.

   To mask the size of the data being hidden, the resulting subformat
   MAY be padded as shown above. Padding does NOT alter the value placed
   in the Length of Original Attribute Value field, but does alter the
   length of the resultant AVP that is being created. For example, If an
   Attribute Value to be hidden is 4 octets in length, the unhidden AVP
   length would be 10 octets (6 + Attribute Value length). After hiding,
   the length of the AVP will become 6 + Attribute Value length + size
   of the Length of Original Attribute Value field + Padding. Thus, if
   Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24
   octets.

   Next, An MD5 hash is performed on the concatenation of:

   + the 2 octet Attribute number of the AVP
   + the shared secret
   + an arbitrary length random vector

   The value of the random vector used in this hash is passed in the
   value field of a Random Vector AVP. This Random Vector AVP must be
   placed in the message by the sender before any hidden AVPs. The same
   random vector may be used for more than one hidden AVP in the same
Top   ToC   RFC2661 - Page 16
   message. If a different random vector is used for the hiding of
   subsequent AVPs then a new Random Vector AVP must be placed in the
   command message before the first AVP to which it applies.

   The MD5 hash value is then XORed with the first 16 octet (or less)
   segment of the Hidden AVP Subformat and placed in the Attribute Value
   field of the Hidden AVP.  If the Hidden AVP Subformat is less than 16
   octets, the Subformat is transformed as if the Attribute Value field
   had been padded to 16 octets before the XOR, but only the actual
   octets present in the Subformat are modified, and the length of the
   AVP is not altered.

   If the Subformat is longer than 16 octets, a second one-way MD5 hash
   is calculated over a stream of octets consisting of the shared secret
   followed by the result of the first XOR.  That hash is XORed with the
   second 16 octet (or less) segment of the Subformat and placed in the
   corresponding octets of the Value field of the Hidden AVP.

   If necessary, this operation is repeated, with the shared secret used
   along with each XOR result to generate the next hash to XOR the next
   segment of the value with.

   The hiding method was adapted from RFC 2138 [RFC2138] which was taken
   from the "Mixing in the Plaintext" section in the book "Network
   Security" by Kaufman, Perlman and Speciner [KPS].  A detailed
   explanation of the method follows:

   Call the shared secret S, the Random Vector RV, and the Attribute
   Value AV. Break the value field into 16-octet chunks p1, p2, etc.
   with the last one padded at the end with random data to a 16-octet
   boundary.  Call the ciphertext blocks c(1), c(2), etc.  We will also
   define intermediate values b1, b2, etc.

          b1 = MD5(AV + S + RV)   c(1) = p1 xor b1
          b2 = MD5(S  + c(1))     c(2) = p2 xor b2
                      .                       .
                      .                       .
                      .                       .
          bi = MD5(S  + c(i-1))   c(i) = pi xor bi

   The String will contain c(1)+c(2)+...+c(i) where + denotes
   concatenation.

   On receipt, the random vector is taken from the last Random Vector
   AVP encountered in the message prior to the AVP to be unhidden.  The
   above process is then reversed to yield the original value.
Top   ToC   RFC2661 - Page 17

4.4 AVP Summary

The following sections contain a list of all L2TP AVPs defined in this document. Following the name of the AVP is a list indicating the message types that utilize each AVP. After each AVP title follows a short description of the purpose of the AVP, a detail (including a graphic) of the format for the Attribute Value, and any additional information needed for proper use of the avp.

4.4.1 AVPs Applicable To All Control Messages

Message Type (All Messages) The Message Type AVP, Attribute Type 0, identifies the control message herein and defines the context in which the exact meaning of the following AVPs will be determined. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type is a 2 octet unsigned integer. The Message Type AVP MUST be the first AVP in a message, immediately following the control message header (defined in section 3.1). See Section 3.2 for the list of defined control message types and their identifiers. The Mandatory (M) bit within the Message Type AVP has special meaning. Rather than an indication as to whether the AVP itself should be ignored if not recognized, it is an indication as to whether the control message itself should be ignored. Thus, if the M-bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the tunnel MUST be cleared. If the M-bit is not set, then the implementation may ignore an unknown message type. The M-bit MUST be set to 1 for all message types defined in this document. This AVP may not be hidden (the H-bit MUST be 0). The Length of this AVP is 8.
Top   ToC   RFC2661 - Page 18
   Random Vector (All Messages)

      The Random Vector AVP, Attribute Type 36, is used to enable the
      hiding of the Attribute Value of arbitrary AVPs.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random Octet String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Random Octet String may be of arbitrary length, although a
      random vector of at least 16 octets is recommended.  The string
      contains the random vector for use in computing the MD5 hash to
      retrieve or hide the Attribute Value of a hidden AVP (see Section
      4.2).

      More than one Random Vector AVP may appear in a message, in which
      case a hidden AVP uses the Random Vector AVP most closely
      preceding it.  This AVP MUST precede the first AVP with the H bit
      set.

      The M-bit for this AVP MUST be set to 1.  This AVP MUST NOT be
      hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the
      length of the Random Octet String.

4.4.2 Result and Error Codes

Result Code (CDN, StopCCN) The Result Code AVP, Attribute Type 1, indicates the reason for terminating the control channel or session. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Error Code (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (opt) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code is a 2 octet unsigned integer. The optional Error Code is a 2 octet unsigned integer. An optional Error Message can follow the Error Code field. Presence of the Error Code and
Top   ToC   RFC2661 - Page 19
      Message are indicated by the AVP Length field. The Error Message
      contains an arbitrary string providing further (human readable)
      text associated with the condition. Human readable text in all
      error messages MUST be provided in the UTF-8 charset using the
      Default Language [RFC2277].

      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
      this AVP MUST be set to 1.  The Length is 8 if there is no Error
      Code or Message, 10 if there is an Error Code and no Error Message
      or 10 + the length of the Error Message if there is an Error Code
      and Message.

      Defined Result Code values for the StopCCN message are:

         0 - Reserved
         1 - General request to clear control connection
         2 - General error--Error Code indicates the problem
         3 - Control channel already exists
         4 - Requester is not authorized to establish a control
             channel
         5 - The protocol version of the requester is not
             supported
              Error Code indicates highest version supported
         6 - Requester is being shut down
         7 - Finite State Machine error

      Defined Result Code values for the CDN message are:

         0 - Reserved
         1 - Call disconnected due to loss of carrier
         2 - Call disconnected for the reason indicated
             in error code
         3 - Call disconnected for administrative reasons
         4 - Call failed due to lack of appropriate facilities
             being available (temporary condition)
         5 - Call failed due to lack of appropriate facilities being
             available (permanent condition)
         6 - Invalid destination
         7 - Call failed due to no carrier detected
         8 - Call failed due to detection of a busy signal
         9 - Call failed due to lack of a dial tone
         10 - Call was not established within time allotted by LAC
         11 - Call was connected but no appropriate framing was
              detected

      The Error Codes defined below pertain to types of errors that are
      not specific to any particular L2TP request, but rather to
      protocol or message format errors. If an L2TP reply indicates in
Top   ToC   RFC2661 - Page 20
      its Result Code that a general error occurred, the General Error
      value should be examined to determine what the error was. The
      currently defined General Error codes and their meanings are:

         0 - No general error
         1 - No control connection exists yet for this LAC-LNS pair
         2 - Length is wrong
         3 - One of the field values was out of range or
             reserved field was non-zero
         4 - Insufficient resources to handle this operation now
         5 - The Session ID is invalid in this context
         6 - A generic vendor-specific error occurred in the LAC
         7 - Try another.  If LAC is aware of other possible LNS
             destinations, it should try one of them.  This can be
             used to guide an LAC based on LNS policy, for instance,
             the existence of multilink PPP bundles.
         8 - Session or tunnel was shutdown due to receipt of an unknown
             AVP with the M-bit set (see section 4.2). The Error Message
             SHOULD contain the attribute of the offending AVP in (human
             readable) text form.

      When a General Error Code of 6 is used, additional information
      about the error SHOULD be included in the Error Message field.

4.4.3 Control Connection Management AVPs

Protocol Version (SCCRP, SCCRQ) The Protocol Version AVP, Attribute Type 2, indicates the L2TP protocol version of the sender. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Rev | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Ver field is a 1 octet unsigned integer containing the value 1. Rev field is a 1 octet unsigned integer containing 0. This pertains to L2TP protocol version 1, revision 0. Note this is not the same version number that is included in the header of each message. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 8.
Top   ToC   RFC2661 - Page 21
   Framing Capabilities (SCCRP, SCCRQ)

      The Framing Capabilities AVP, Attribute Type 3, provides the peer
      with an indication of the types of framing that will be accepted
      or requested by the sender.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Reserved for future framing type definitions          |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute Value field is a 32-bit mask, with two bits defined.
      If bit A is set, asynchronous framing is supported. If bit S is
      set, synchronous framing is supported.

      A peer MUST NOT request an incoming or outgoing call with a
      Framing Type AVP specifying a value not advertised in the Framing
      Capabilities AVP it received during control connection
      establishment.  Attempts to do so will result in the call being
      rejected.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) is 10.

   Bearer Capabilities (SCCRP, SCCRQ)

      The Bearer Capabilities AVP, Attribute Type 4, provides the peer
      with an indication of the bearer device types supported by the
      hardware interfaces of the sender for outgoing calls.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Reserved for future bearer type definitions           |A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This is a 32-bit mask, with two bits defined. If bit A is set,
      analog access is supported. If bit D is set, digital access is
      supported.
Top   ToC   RFC2661 - Page 22
      An LNS should not request an outgoing call specifying a value in
      the Bearer Type AVP for a device type not advertised in the Bearer
      Capabilities AVP it received from the LAC during control
      connection establishment. Attempts to do so will result in the
      call being rejected.

      This AVP MUST be present if the sender can place outgoing calls
      when requested.

      Note that an LNS that cannot act as an LAC as well will not
      support hardware devices for handling incoming and outgoing calls
      and should therefore set the A and D bits of this AVP to 0, or
      should not send the AVP at all. An LNS that can also act as an LAC
      and place outgoing calls should set A or D as appropriate.
      Presence of this message is not a guarantee that a given outgoing
      call will be placed by the sender if requested, just that the
      physical capability exists.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) is 10.

   Tie Breaker (SCCRQ)

      The Tie Breaker AVP, Attribute Type 5, indicates that the sender
      wishes a single tunnel to exist between the given LAC-LNS pair.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tie Break Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                 ...(64 bits)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Tie Breaker Value is an 8 octet value that is used to choose a
      single tunnel where both LAC and LNS request a tunnel
      concurrently. The recipient of a SCCRQ must check to see if a
      SCCRQ has been sent to the peer, and if so, must compare its Tie
      Breaker value with the received one. The lower value "wins", and
      the "loser" MUST silently discard its tunnel. In the case where a
      tie breaker is present on both sides, and the value is equal, both
      sides MUST discard their tunnels.
Top   ToC   RFC2661 - Page 23
      If a tie breaker is received, and an outstanding SCCRQ had no tie
      breaker value, the initiator which included the Tie Breaker AVP
      "wins". If neither side issues a tie breaker, then two separate
      tunnels are opened.

      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
      this AVP MUST be set to 0.  The Length of this AVP is 14.

   Firmware Revision (SCCRP, SCCRQ)

      The Firmware Revision AVP, Attribute Type 6, indicates the
      firmware revision of the issuing device.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Firmware Revision is a 2 octet unsigned integer encoded in a
      vendor specific format.

      For devices which do not have a firmware revision (general purpose
      computers running L2TP software modules, for instance), the
      revision of the L2TP software module may be reported instead.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) is 8.

   Host Name (SCCRP, SCCRQ)

      The Host Name AVP, Attribute Type 7, indicates the name of the
      issuing LAC or LNS.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Host Name ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Host Name is of arbitrary length, but MUST be at least 1
      octet.
Top   ToC   RFC2661 - Page 24
      This name should be as broadly unique as possible; for hosts
      participating in DNS [RFC1034], a hostname with fully qualified
      domain would be appropriate.

      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
      this AVP MUST be set to 1.  The Length of this AVP is 6 plus the
      length of the Host Name.

   Vendor Name (SCCRP, SCCRQ)

      The Vendor Name AVP, Attribute Type 8, contains a vendor specific
      (possibly human readable) string describing the type of LAC or LNS
      being used.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Vendor Name ...(arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Vendor Name is the indicated number of octets representing the
      vendor string. Human readable text for this AVP MUST be provided
      in the UTF-8 charset using the Default Language [RFC2277].

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6 plus the length of the Vendor Name.

   Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)

      The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being
      assigned to this tunnel by the sender.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Assigned Tunnel ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Assigned Tunnel ID is a 2 octet non-zero unsigned integer.

      The Assigned Tunnel ID AVP establishes a value used to multiplex
      and demultiplex multiple tunnels between the LNS and LAC. The L2TP
      peer MUST place this value in the Tunnel ID header field of all
Top   ToC   RFC2661 - Page 25
      control and data messages that it subsequently transmits over the
      associated tunnel.  Before the Assigned Tunnel ID AVP is received
      from a peer, messages MUST be sent to that peer with a Tunnel ID
      value of 0 in the header of all control messages.

      In the StopCCN control message, the Assigned Tunnel ID AVP MUST be
      the same as the Assigned Tunnel ID AVP first sent to the receiving
      peer, permitting the peer to identify the appropriate tunnel even
      if a StopCCN is sent before an Assigned Tunnel ID AVP is received.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 8.

   Receive Window Size (SCCRQ, SCCRP)

      The Receive Window Size AVP, Attribute Type 10, specifies the
      receive window size being offered to the remote peer.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Window Size           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Window Size is a 2 octet unsigned integer.

      If absent, the peer must assume a Window Size of 4 for its
      transmit window. The remote peer may send the specified number of
      control messages before it must wait for an acknowledgment.

      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
      this AVP MUST be set to 1.  The Length of this AVP is 8.

   Challenge (SCCRP, SCCRQ)

      The Challenge AVP, Attribute Type 11, indicates that the issuing
      peer wishes to authenticate the tunnel endpoints using a CHAP-
      style authentication mechanism.
Top   ToC   RFC2661 - Page 26
      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Challenge ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge is one or more octets of random data.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 6 plus the length of the Challenge.

   Challenge Response (SCCCN, SCCRP)

      The Response AVP, Attribute Type 13, provides a response to a
      challenge received.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Response ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                              ... (16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Response is a 16 octet value reflecting the CHAP-style
      [RFC1994] response to the challenge.

      This AVP MUST be present in an SCCRP or SCCCN if a challenge was
      received in the preceding SCCRQ or SCCRP. For purposes of the ID
      value in the CHAP response calculation, the value of the Message
      Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for
      an SCCCN).

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 22.
Top   ToC   RFC2661 - Page 27

4.4.4 Call Management AVPs

Q.931 Cause Code (CDN) The Q.931 Cause Code AVP, Attribute Type 12, is used to give additional information in case of unsolicited call disconnection. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Msg | Advisory Msg... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cause Code is the returned Q.931 Cause code, and Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) associated with the Cause Code. Both values are returned in their native ITU encodings [DSS1]. An additional ASCII text Advisory Message may also be included (presence indicated by the AVP Length) to further explain the reason for disconnecting. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 9, plus the size of the Advisory Message. Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) The Assigned Session ID AVP, Attribute Type 14, encodes the ID being assigned to this session by the sender. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Session ID is a 2 octet non-zero unsigned integer. The Assigned Session ID AVP is establishes a value used to multiplex and demultiplex data sent over a tunnel between the LNS and LAC. The L2TP peer MUST place this value in the Session ID header field of all control and data messages that it subsequently transmits over the tunnel that belong to this session. Before the
Top   ToC   RFC2661 - Page 28
      Assigned Session ID AVP is received from a peer, messages MUST be
      sent to that peer with a Session ID of 0 in the header of all
      control messages.

      In the CDN control message, the same Assigned Session ID AVP first
      sent to the receiving peer is used, permitting the peer to
      identify the appropriate tunnel even if CDN is sent before an
      Assigned Session ID is received.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 8.

   Call Serial Number (ICRQ, OCRQ)

      The Call Serial Number AVP, Attribute Type 15, encodes an
      identifier assigned by the LAC or LNS to this call.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Call Serial Number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Call Serial Number is a 32 bit value.

      The Call Serial Number is intended to be an easy reference for
      administrators on both ends of a tunnel to use when investigating
      call failure problems. Call Serial Numbers should be set to
      progressively increasing values, which are likely to be unique for
      a significant period of time across all interconnected LNSs and
      LACs.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.

   Minimum BPS (OCRQ)

      The Minimum BPS AVP, Attribute Type 16, encodes the lowest
      acceptable line speed for this call.
Top   ToC   RFC2661 - Page 29
      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Minimum BPS                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The  Minimum BPS is a 32 bit value indicates the speed in bits per
      second.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.

   Maximum BPS (OCRQ)

      The Maximum BPS AVP, Attribute Type 17, encodes the highest
      acceptable line speed for this call.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Maximum BPS                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Maximum BPS is a 32 bit value indicates the speed in bits per
      second.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.

   Bearer Type (ICRQ, OCRQ)

      The Bearer Type AVP, Attribute Type 18,  encodes the bearer type
      for the incoming or outgoing call.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for future Bearer Types                |A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC2661 - Page 30
      The Bearer Type is a 32-bit bit mask, which indicates the bearer
      capability of the call (ICRQ) or required for the call (OCRQ). If
      set, bit A indicates that the call refers to an analog channel. If
      set, bit D indicates that the call refers to a digital channel.
      Both may be set, indicating that the call was either
      indistinguishable, or can be placed on either type of channel.

      Bits in the Value field of this AVP MUST only be set by the LNS
      for an OCRQ if it was set in the Bearer Capabilities AVP received
      from the LAC during control connection establishment.

      It is valid to set neither the A nor D bits in an ICRQ. Such a
      setting may indicate that the call was not received over a
      physical link (e.g if the LAC and PPP are located in the same
      subsystem).

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.

   Framing Type (ICCN, OCCN, OCRQ)

      The Framing Type AVP, Attribute Type 19, encodes the framing type
      for the incoming or outgoing call.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for future Framing Types               |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Type is a 32-bit mask, which indicates the type of PPP
      framing requested for an OCRQ, or the type of PPP framing
      negotiated for an OCCN or ICCN. The framing type MAY be used as an
      indication to PPP on the LNS as to what link options to use for
      LCP negotiation [RFC1662].

      Bit A indicates asynchronous framing. Bit S indicates synchronous
      framing. For an OCRQ, both may be set, indicating that either type
      of framing may be used.

      Bits in the Value field of this AVP MUST only be set by the LNS
      for an OCRQ if it was set in the Framing Capabilities AVP received
      from the LAC during control connection establishment.
Top   ToC   RFC2661 - Page 31
      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.

   Called Number (ICRQ, OCRQ)

      The Called Number AVP, Attribute Type 21, encodes the telephone
      number to be called for an OCRQ, and the Called number for an
      ICRQ.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Called Number... (arbitrary number of octets)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Called Number is an ASCII string. Contact between the
      administrator of the LAC and the LNS may be necessary to
      coordinate interpretation of the value needed in this AVP.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 6 plus the length of the Called Number.

   Calling Number (ICRQ)

      The Calling Number AVP, Attribute Type 22, encodes the originating
      number for the incoming call.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Calling Number... (arbitrary number of octets)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Calling Number is an ASCII string. Contact between the
      administrator of the LAC and the LNS may be necessary to
      coordinate interpretation of the value in this AVP.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 6 plus the length of the Calling Number.
Top   ToC   RFC2661 - Page 32
   Sub-Address (ICRQ, OCRQ)

      The Sub-Address AVP, Attribute Type 23, encodes additional dialing
      information.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-Address ... (arbitrary number of octets)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Sub-Address is an ASCII string. Contact between the
      administrator of the LAC and the LNS may be necessary to
      coordinate interpretation of the value in this AVP.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 6 plus the length of the Sub-Address.

   (Tx) Connect Speed (ICCN, OCCN)

      The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the
      speed of the facility chosen for the connection attempt.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             BPS                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The (Tx) Connect Speed BPS is a 4 octet value indicating the speed
      in bits per second.

      When the optional Rx Connect Speed AVP is present, the value in
      this AVP represents the transmit connect speed, from the
      perspective of the LAC (e.g. data flowing from the LAC to the
      remote system). When the optional Rx Connect Speed AVP is NOT
      present, the connection speed between the remote system and LAC is
      assumed to be symmetric and is represented by the single value in
      this AVP.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.
Top   ToC   RFC2661 - Page 33
   Rx Connect Speed (ICCN, OCCN)

      The Rx Connect Speed AVP, Attribute Type 38, represents the speed
      of the connection from the perspective of the LAC (e.g. data
      flowing from the remote system to the LAC).

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           BPS (H)             |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      BPS is a 4 octet value indicating the speed in bits per second.

      Presence of this AVP implies that the connection speed may be
      asymmetric with respect to the transmit connect speed given in the
      (Tx) Connect Speed AVP.

      This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 10.

   Physical Channel ID (ICRQ, OCRP)

      The Physical Channel ID AVP, Attribute Type 25, encodes the vendor
      specific physical channel number used for a call.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Physical Channel ID is a 4 octet value intended to be used for
      logging purposes only.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 10.
Top   ToC   RFC2661 - Page 34
   Private Group ID (ICCN)

      The Private Group ID AVP, Attribute Type 37, is used by the LAC to
      indicate that this call is to be associated with a particular
      customer group.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Private Group ID ... (arbitrary number of octets)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Private Group ID is a string of octets of arbitrary length.

      The LNS MAY treat the PPP session as well as network traffic
      through this session in a special manner determined by the peer.
      For example, if the LNS is individually connected to several
      private networks using unregistered addresses, this AVP may be
      included by the LAC to indicate that a given call should be
      associated with one of the private networks.

      The Private Group ID is a string corresponding to a table in the
      LNS that defines the particular characteristics of the selected
      group.  A LAC MAY determine the Private Group ID from a RADIUS
      response, local configuration, or some other source.

      This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6 plus the length of the Private Group ID.

   Sequencing Required (ICCN, OCCN)

      The Sequencing Required AVP, Attribute Type 39, indicates to the
      LNS that Sequence Numbers MUST always be present on the data
      channel.

      This AVP has no Attribute Value field.

      This AVP MUST NOT be hidden (the H-bit MUST be 0).  The M-bit for
      this AVP MUST be set to 1.  The Length of this AVP is 6.

4.4.5 Proxy LCP and Authentication AVPs

The LAC may have answered the call and negotiated LCP with the remote system, perhaps in order to establish the system's apparent identity. In this case, these AVPs may be included to indicate the
Top   ToC   RFC2661 - Page 35
      link properties the remote system initially requested, properties
      the remote system and LAC ultimately negotiated, as well as PPP
      authentication information sent and received by the LAC. This
      information may be used to initiate the PPP LCP and authentication
      systems on the LNS, allowing PPP to continue without renegotiation
      of LCP. Note that the LNS policy may be to enter an additional
      round of LCP negotiation and/or authentication if the LAC is not
      trusted.

   Initial Received LCP CONFREQ (ICCN)

      In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
      provides the LNS with the Initial CONFREQ received by the LAC from
      the PPP Peer.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCP CONFREQ... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      LCP CONFREQ is a copy of the body of the initial CONFREQ received,
      starting at the first option within the body of the LCP message.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6 plus the length of the CONFREQ.

   Last Sent LCP CONFREQ (ICCN)

      In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the
      LNS with the Last CONFREQ sent by the LAC to the PPP Peer.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCP CONFREQ... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The LCP CONFREQ is a copy of the body of the final CONFREQ sent to
      the client to complete LCP negotiation, starting at the first
      option within the body of the LCP message.
Top   ToC   RFC2661 - Page 36
      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6 plus the length of the CONFREQ.

   Last Received LCP CONFREQ (ICCN)

      The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the
      LNS with the Last CONFREQ received by the LAC from the PPP Peer.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCP CONFREQ... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The LCP CONFREQ is a copy of the body of the final CONFREQ
      received from the client to complete LCP negotiation, starting at
      the first option within the body of the LCP message.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6 plus the length of the CONFREQ.

   Proxy Authen Type (ICCN)

      The Proxy Authen Type AVP, Attribute Type 29, determines if proxy
      authentication should be used.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Authen Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Authen Type is a 2 octet unsigned integer, holding:

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 8.
Top   ToC   RFC2661 - Page 37
      Defined Authen Type values are:
         0 - Reserved
         1 - Textual username/password exchange
         2 - PPP CHAP
         3 - PPP PAP
         4 - No Authentication
         5 - Microsoft CHAP Version 1 (MSCHAPv1)

         This AVP MUST be present if proxy authentication is to be
         utilized. If it is not present, then it is assumed that this
         peer cannot perform proxy authentication, requiring
         a restart of the authentication phase at the LNS if the client
         has already entered this phase with the
         LAC (which may be determined by the Proxy LCP AVP if present).

      Associated AVPs for each type of authentication follow.

   Proxy Authen Name (ICCN)

      The Proxy Authen Name AVP, Attribute Type 30, specifies the name
      of the authenticating client when using proxy authentication.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Authen Name... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Authen Name is a string of octets of arbitrary length.  It
      contains the name specified in the client's authentication
      response.

      This AVP MUST be present in messages containing a Proxy Authen
      Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable
      to employ AVP hiding for obscuring the cleartext name.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) is 6 plus
      the length of the cleartext name.

   Proxy Authen Challenge (ICCN)

      The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
      challenge sent by the LAC to the PPP Peer, when using proxy
      authentication.
Top   ToC   RFC2661 - Page 38
      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Challenge... (arbitrary number of octets)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge is a string of one or more octets.

      This AVP MUST be present for Proxy Authen Types 2 and 5. The
      Challenge field contains the CHAP challenge presented to the
      client by the LAC.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6, plus the length of the Challenge.

   Proxy Authen ID (ICCN)

      The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value
      of the PPP Authentication that was started between the LAC and the
      PPP Peer, when proxy authentication is being used.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved    |      ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ID is a 2 octet unsigned integer, the most significant octet MUST
      be 0.

      The Proxy Authen ID AVP MUST be present for Proxy authen types 2,
      3 and 5. For 2 and 5, the ID field contains the byte ID value
      presented to the client by the LAC in its Challenge. For 3, it is
      the Identifier value of the Authenticate-Request.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.

   Proxy Authen Response (ICCN)

      The Proxy Authen Response AVP, Attribute Type 33, specifies the
      PPP Authentication response received by the LAC from the PPP Peer,
      when proxy authentication is used.
Top   ToC   RFC2661 - Page 39
      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Response... (arbitrary number of octets)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Response is a string of octets.

      This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The
      Response field contains the client's response to the challenge.
      For Proxy authen types 2 and 5, this field contains the response
      value received by the LAC. For types 1 or 3, it contains the clear
      text password received from the client by the LAC.  In the case of
      cleartext passwords, AVP hiding is recommended.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6 plus the length of the Response.

4.4.6 Call Status AVPs

Call Errors (WEN) The Call Errors AVP, Attribute Type 34, is used by the LAC to send error information to the LNS. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | CRC Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC Errors (L) | Framing Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Errors (L) | Hardware Overruns (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Overruns (L) | Buffer Overruns (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Overruns (L) | Time-out Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-out Errors (L) | Alignment Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alignment Errors (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC2661 - Page 40
      The following fields are defined:

         Reserved - Not used, MUST be 0
         CRC Errors - Number of PPP frames received with CRC errors
            since call was established
         Framing Errors - Number of improperly framed PPP packets
            received
         Hardware Overruns - Number of receive buffer over-runs since
            call was established
         Buffer Overruns - Number of buffer over-runs detected since
            call was established
         Time-out Errors - Number of time-outs since call was
            established
         Alignment Errors - Number of alignment errors since call was
            established

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 32.

   ACCM (SLI)

      The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC
      of the ACCM negotiated with the PPP Peer by the LNS.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Reserved             |    Send ACCM (H)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Send ACCM   (L)      |    Receive ACCM (H)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Receive ACCM  (L)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Send ACCM and Receive ACCM are each 4 octet values preceded by a 2
      octet reserved quantity. The send ACCM value should be used by the
      LAC to process packets it sends on the connection. The receive
      ACCM value should be used by the LAC to process incoming packets
      on the connection. The default values used by the LAC for both
      these fields are 0xFFFFFFFF. The LAC should honor these fields
      unless it has specific configuration information to indicate that
      the requested mask must be modified to permit operation.

      This AVP may be hidden (the H-bit MAY be 1 or 0).  The M-bit for
      this AVP MUST be set to 1.  The Length of this AVP is 16.


(next page on part 3)

Next Section