ION Working Group                                            Lou Berger
INTERNET DRAFT                                             FORE Systems
<draft-ietf-ion-nhrp-flowext-00.txt>                           Rob Enns
                                                      Berkeley Networks
                                                 Expires: December 1998


                          NHRP Flow Extension

                             June 22, 1998


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   This document presents an extension to NHRP [RFC2332] that enables
   resolution of NBMA next hop addresses based on destination flow
   information.  This extension also enables NHSs to relay simple
   forwarding policy to source stations (NHCs).

1. Introduction

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

   The NBMA Next Hop Resolution Protocol provides a mechanism for a
   station to resolve a destination internetworking layer address into
   the corresponding NBMA subnetwork addresses of the "NBMA next hop."
   As defined in [RFC2332], NBMA next hop subnetwork addresses are



Berger, Enns             Expires: December 1998                 [Page 1]


Internet Draft            NHRP Flow Extension                  June 1998


   resolved based on an internetworking layer address and, possibly, an
   address prefix.

   Resolution based on destination addresses may not be adequate for all
   cases.  This document is motivated by one such case.  The case
   addressed by this document is when the NBMA next hop is dependent on
   the contents of a data packet, i.e. its type of traffic.  The
   extension presented in this document provides the ability to resolve
   NBMA next hops based on destination and additional data packet
   information.  We refer to the presented extension as the "Flow
   Extension."

   There are multiple possible reasons why an NBMA next hop may depend
   on the contents of a data packet.  One example is configured
   administrative policy at serving or transit NHSs.  The choice of
   selecting next hop based on just destination address, or selecting
   next hop based on additional data packet information is considered to
   be a local policy decision.  The presented extension will
   interoperate with NHSs and NHCs that don't support the Flow Extension
   as well as those that implement disparate selection policies.

2. Discussion

   The Flow Extension enables the communication of a limited amount of
   policy information to the source NHC from NHSs along the routed path.
   NHRP currently supports a very limited amount of policy communication
   via a resolution NAK.  With the resolution NAK, a source NHS can be
   informed that a resolution request is administratively prohibited.
   The Flow Extension allows the communication of additional policy
   information.  This additional policy information indicates which
   types of data traffic, or flows, can be directed to which NBMA next
   hops.

   The Flow Extension supports the communication of one final piece of
   policy information.  With the Flow Extension, the source NHC can be
   informed that matching data packets should be silently discarded.
   When a source NHC drops such traffic, network resource usage is
   reduced since such traffic would be discarded further along the
   routed path.  Source NHCs are not required to discard any data
   traffic and may forward any data packets along the routed path.
   Currently, source NHCs that cannot resolve an NBMA next hop are
   expected to forward data packets along the routed path.

   The rest of this section covers general issues related to Flow
   Extension creation and processing.  Specific format requirements and
   Resolution Request and Reply message processing impact are covered in
   sections 3 and 4 respectively.




Berger, Enns             Expires: December 1998                 [Page 2]


Internet Draft            NHRP Flow Extension                  June 1998


2.1 Policy Communication

   The objective of the Flow Extension is twofold.  The first is to
   enable the resolution of a single destination address to more than
   one NBMA next hop address based on flow information.  The second is
   to allow selected traffic to a particular destination address to be
   resolved to one or more NBMA next hop addresses while other traffic
   to the same destination address is not resolved.  When traffic is
   unresolved, the extension allows the source NHC to be informed that
   such traffic should be dropped.  NHCs are permitted to continue
   handling unresolved traffic in the same fashion as described
   [RFC2332].

   To achieve the two objectives of the Flow Extension, the extension is
   included in NHRP Resolution Request and Reply messages.  In Request
   messages, the Flow Extension contains a description of the specific
   flow associated with the request, the flow matching capabilities of
   the requester, and the policy information from the NHSs that have
   already processed the Request message.  Reply messages are handled in
   the traditional manner per [RFC2332] and also include the policy
   information from the serving NHS.

   When a source NHC creates a Resolution Request with a Flow Extension,
   it describes its capabilities and the flow associated with the
   request.  The requesting NHC also initializes the policy information
   fields that will be updated by downstream NHSs to indicate an
   unrestrictive policy.  NHSs add information based on their local
   administrative policy.  This information can indicate that the flow
   is administratively prohibited and should be dropped at the source
   NHC, that the specific flow is acceptable or, lastly, that the flow
   falls within a set of acceptable flows.  NHSs processing Request
   messages may indicate that their policy is more restrictive than the
   policy described in the received message and are not allowed to
   indicate a less restrictive policy.  Serving NHSs add their policy
   information when generating a Resolution Reply message.

   Once the Reply message reaches the requester, the requester is
   expected to follow the policy information contained in the Reply.
   This includes only sending data packets matching the described flow
   to the listed NBMA next hop addresses, and following the drop
   indication in NAK messages.  The requester is permitted to handle NAK
   Reply messages and associated data packets in the traditional, pre
   Flow Extension, fashion.  The requester is also permitted to forward
   data packets matching the described flow via the routed path rather
   than following the information in a non-NAK Reply message.






Berger, Enns             Expires: December 1998                 [Page 3]


Internet Draft            NHRP Flow Extension                  June 1998


2.2 Compatibility

   There are no compatibility issues with implementations that do not
   support the Flow Extension.  [RFC2332] requires that the extension be
   transported even when a processing station does not support the
   extension.  Flow Extension aware stations may generate and handle
   multiple resolution requests for the same destination each with a
   different flow descriptions.  NHSs that do not support the extension
   will see such flow specific requests as revalidation requests all for
   the same destination.

   From the policy standpoint, NHSs that do not support the extension
   are able to verify that a request is administratively acceptable, but
   do so just on a destination rather than flow basis.  When a
   particular Resolution Request message containing a Flow Extension is
   processed by a combination of extension supporting and non-supporting
   NHSs, the corresponding Reply message will reflect flow based policy
   from extension supporting NHSs and the coarser grained destination
   based policy from non-supporting NHSs.

2.3 NHS Handling of Non-Served NHC Resolution Requests

   The NHRP specification [RFC2332] requires that NHCs only send
   Resolution Request messages to their serving NHS, but it places no
   corresponding requirement on NHSs.  In order to ensure that a
   Resolution Request message follows the routed path, NHSs that support
   the Flow Extension MUST respond to Request messages which contain the
   Flow Extension from non-served NHCs with an Error Indication.

2.4 Security Considerations

   The Flow Extension is used to communicate a limited amount of policy
   information.  Consequently there are a number of security related
   issues.  The issues have to do with both the communication of the
   policy information and with the use of the policy information.

2.4.1 Trust of NHRP Stations

   The Flow Extension is used to relay policy information between NHCs
   and NHSs.  For the extension to be useful NHSs and NHCs must rely
   upon each other to relay policy information correctly, to properly
   update the information and to act appropriately based on the
   information.  Potential threats include downstream and reverse path
   NHSs overriding communicated policy information, and NHCs that send
   NBMA Next Hops traffic not included in the communicated policy
   information.

   In environments where reliance (and trust) between NHSs and NHCs



Berger, Enns             Expires: December 1998                 [Page 4]


Internet Draft            NHRP Flow Extension                  June 1998


   posses an unacceptable risk, the NHRP Authentication Extension SHOULD
   be used to identify trusted NHRP speakers and the Flow Extension
   SHOULD only be supported (processed from and sent to) between
   authenticated speakers.  In environments where this approach is
   unacceptable or unavailable support for the Flow Extension SHOULD be
   disabled.  With Extension processing disabled, the threat becomes the
   same as that posed by standard NHRP.

2.4.2  Dissemination of Policy Information

   With the Flow Extension, an NHS' forwarding policy is communicated to
   other NHSs and the requesting NHC.  In some cases the communication
   of this policy information will be acceptable, in others the
   dissemination of such information may be undesirable.  In the later
   case, the communicated policy can be limited to a minimum.  If it is
   unacceptable to communicate any policy information, again, support
   for the Flow Extension SHOULD be disabled.

   It should be noted that the Resolution Reply messages containing Flow
   Extensions may be carried along a different routed path from the
   serving NHS to the requesting NHC.  Forcing symmetric routing was
   considered in order to limit the dissemination of policy information,
   but was found to result in incompatibility with existing NHRP
   implementations.

2.4.3  Policy Information Updates

   An NHS' local policy information may be updated at anytime.  Such an
   update may relate to previously requested resolution information.
   The new policy information will eventually be communicated once the
   source NHC refreshes the resolution information.  Between the time
   the information is changed and the resolution is refreshed, the
   source NHS may handle data packets based on the out of date policy
   information.

   The handling of data packets based on old policy information may be
   an issue for some environments.  In cases where this is an issue,
   NHSs can force the removal of the related resolution information.  To
   do this, an NHS SHOULD cache information related to Resolution
   Requests that contain a Flow Extension, and then issue Purge Request
   messages for destinations that are affected by local policy updates.

3. NHRP Flow Extension Format

   Compulsory = 0
   Type = To Be Assigned
   Length = variable, see format definitions




Berger, Enns             Expires: December 1998                 [Page 5]


Internet Draft            NHRP Flow Extension                  June 1998


   The NHRP Flow Extension is carried in NHRP Resolution Request and
   Reply messages to convey flow related information.  A source NHC
   includes the extension to indicate that the extension is supported.
   Within the extension, the source NHC identifies the flow associated
   with the resolution request, indicates its flow matching
   capabilities, and initializes the policy information related fields.
   Transit NHSs update the policy related fields based on their local
   policies.  The NHS responding to the Request message, the
   "responder", copies a received Flow Extension to the corresponding
   Resolution Reply message and updates the policy related fields based
   on its local policies.

   The format of the extension varies based on the traffic being
   described.  In all formats, the extension has request and policy
   information related fields.  The request related fields describe the
   flow from the source NHC's perspective.  The policy information
   related fields are used to relay the policy found along the routed
   path to the destination, and may be set by transit and serving NHSs.
   The first byte of the extension indicates the type of flow
   information associated with the request.  The source NHS selects the
   type based on its capabilities.  The traffic type values defined in
   this document are:

       Value     Label                 Description
       ========================================================
       0x00      Reserved              Illegal Value
       0x01      IPv4                  Generic IPv4 Header
       0x02      IPv6                  Generic IPv6 Header
       0x03      IPv4-TCP/UDP          IPv4 Header with TCP/UDP like ports
       0x04      IPv6-TCP/UDP          IPv6 Header with TCP/UDP like ports
       0x05      IPv4-IPSEC            IPv4 Header with IPSEC SPI
       0x06      IPv6-IPSEC            IPv6 Header with IPSEC SPI
       0x07-0x7F Reserved              To be assigned by IANA
       0x80-0xFF Reserved              Allocated to the ATM forum

   A Flow Extension containing an unrecognized traffic type values SHALL
   be treated as an unrecognized extension.

3.1 NHRP Flow Extension Format: IPv4

   This format is used to describe any type of IPv4 data packet.  It is
   expected to be used when a more specific description is not defined
   or supported.








Berger, Enns             Expires: December 1998                 [Page 6]


Internet Draft            NHRP Flow Extension                  June 1998


       Extension Length = 16

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Flow Type=0x01 |D|   Flags     |Type of Service|    Protocol   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Source IP Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Destination IP Address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    ToS Mask   |  Src Prefix   |  Dst Prefix   |     Unused    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flow Type
     Indicates type of flow information carried in the extension.

   D bit
     When set, the "D" bit indicates that data packets matching the flow
     information SHOULD be silently discarded by the source NHC.  If the
     source NHC forwards matching data packets, such packets MUST be
     forwarded via the routed path.

     This bit is set to zero (0) in Resolution Request messages and may
     be set by NHSs.  If a Flow Extension is received with a set value
     (1), an NHS MUST forward the extension with the "D" bit set.

   Flags
     The following flags are defined IPv4 flows:
      0  1  2  3  4  5  6
     +--+--+--+--+--+--+--+
     | unused |Da|Sa|P |T |
     +--+--+--+--+--+--+--+

     Da
       When set, this bit indicates that flows may be identified using
       prefix matching on the Destination IP Address field of the IP
       Header.  Prefix matching uses a specified number of bits from the
       address field rather than the whole field.  This bit is set by
       the source NHC and MAY NOT be modified by transit or serving
       NHSs.

     Sa
       When set, this bit indicates that flows may be identified using
       prefix matching on the Source IP Address field of the IP Header.
       This bit is set by the source NHC and MAY NOT be modified by
       transit or serving NHSs.




Berger, Enns             Expires: December 1998                 [Page 7]


Internet Draft            NHRP Flow Extension                  June 1998


     P
       When set, this bit indicates that flows MUST be identified using
       the value in the Protocol field.  This bit is only meaningfull if
       the Protocol field is non-zero.  This bit MUST be cleared by the
       source NHC and MAY be set transit or serving NHSs.  When a Flow
       Extension is received with this bit set, an NHS MUST NOT clear
       this bit.

     T
       When set, this bit indicates that flows may be identified based
       on the Type of Service field of the IP Header.  This bit is set
       by the source NHC and MAY NOT be modified by transit or serving
       NHSs.

   Unused bits and fields MUST be set to zero (0) by the source NHC and
   not modified by transit or serving NHSs.

   Type of Service
     Value of the IP Type of Service field for the associated flow.
     This value is set by the source NHC and MAY NOT be modified by
     transit or serving NHSs.  This field is only meaningful when the
     "T" bit is set.

   Protocol
     Value of the next level protocol field for the associated flow.  A
     value of zero (0) indicates that the source NHC will not include
     this field in identification of the associated flow.  This field is
     set by the source NHC and MAY NOT be modified by transit or serving
     NHSs.

   Source IP Address
     The source IP address for the associated flow.  A value of zero (0)
     indicates that the source NHC will not include this field in flow
     identification.  This field is set by the source NHC and MAY NOT be
     modified by transit or serving NHSs.

   Destination IP Address
     The destination IP address of the associated flow.  A value of zero
     (0) indicates that the source NHC will not include this field in
     flow identification.  This field is set by the source NHC and MAY
     NOT be modified by transit or serving NHSs.

   ToS Mask
     This field indicates the bits that must be set in a data packet's
     Type of Service field in order to be associated with the flow.  A
     value of zero (0) indicates that the field SHALL NOT be included in
     flow identification.  This field is only meaningful when the "T"
     bit is set.



Berger, Enns             Expires: December 1998                 [Page 8]


Internet Draft            NHRP Flow Extension                  June 1998


     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs add their policy information by setting cleared bits in
     the field.  NHSs MUST NOT clear bits in the field.

   Src Prefix
     This field carries the number of bits of the Source IP Address
     field to be used in identifying data packets associated with the
     flow.  A value of zero (0) indicates that the field SHALL NOT be
     included in flow identification.  A value of 32 indicates a host
     address, i.e. all bits should be used.  Values greater than 32 are
     illegal.  This field is only meaningful when the Source IP Address
     field is non-zero and when the "Sa" bit is set.

     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs MAY increase the value based on their policy
     information.  NHSs MUST NOT decrease the value.

   Dst Prefix
     This field carries the number of bits of the Destination IP Address
     field to be used in identifying data packets associated with the
     flow.  A value of 0 or 32 indicates a host address, i.e. all bits
     should be used.  Values greater than 32 are illegal.  This field is
     only meaningful when the Destination IP Address field is non-zero
     and when the the "Da" bit is set.

     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs MAY increase the value based on their policy
     information.  NHSs MUST set the value to 32 to indicate a host
     address policy.  NHSs MUST NOT decrease the value.

3.2 NHRP Flow Extension Format: IPv6

   This format is used to describe any type of IPv6 data packet.  It is
   expected to be used when a more specific description is not defined
   or supported.
















Berger, Enns             Expires: December 1998                 [Page 9]


Internet Draft            NHRP Flow Extension                  June 1998


       Extension Length = 48

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Flow Type=0x02 |D|        IPv6 Flags           |  Next Header  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |PT Len |      Prio./Traffic Class/Flow Label (PT)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |              Source IPv6 Address (16 bytes)                   |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |           Destination IPv6 Address (16 bytes)                 |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |DPT Len|     Desired Prio./Traffic Class/Flow Label  (DPT)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |IPv6 Src Prefix|IPv6 Dst Prefix|            Unused             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Flags
     The following flags are defined IPv6 flows:

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                unused                 |Da |Sa |DPT|PT |NH |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

     DPT
       When set, this bit indicates that flows MUST be identified based
       on the Prio./Traffic Class and Flow Label fields of the IP
       Header.  This bit MUST be zero when the PT bit is zero.  This bit
       MUST be cleared by the source NHC and MAY be set transit or
       serving NHSs.  When a Flow Extension is received with this bit
       set, an NHS MUST NOT clear this bit.

     PT
       When set, this bit indicates that flows may be identified based
       on the Prio./Traffic Class and Flow Label fields of the IP
       Header.  This bit is set by the source NHC and MAY NOT be
       modified by transit or serving NHSs.





Berger, Enns             Expires: December 1998                [Page 10]


Internet Draft            NHRP Flow Extension                  June 1998


     NH
       When set, this bit indicates that flows MUST be identified using
       the value in the Next Header field.  This bit is only meaning
       full if the Next Header field is non-zero.  This bit MUST be
       cleared by the source NHC and MAY be set transit or serving NHSs.
       When a Flow Extension is received with this bit set, an NHS MUST
       NOT clear this bit.

   Next Header
     Value of the IPv6 Next Header field for the associated flow.  A
     value of zero (0) indicates that the source NHC will not include
     this field in identification of the associated flow.  This field is
     set by the source NHC and MAY NOT be modified by transit or serving
     NHSs.

   PT Len
     Indicates the number of bits in the Prio./Traffic Class (first)
     portion of the PT field.  This field is set by the source NHC and
     is not modified by transit or serving NHSs.  The source NHS MAY set
     this value to zero (0).  This field is only meaningful when the
     "PT" bit is set.

   Prio./Traffic Class and Flow Label (PT)
     The 28-bit PT field for the associated flow.  The PT field is
     composed of two parts. The first part carries either the IPv6
     priority value or the the proposed IPv6 Traffic Class field.  The
     second part is the IPv6 Flow Label.  This field is set by the
     source NHC and MAY NOT be modified by transit or serving NHSs.
     This field is only meaningful when the "PT" bit is set.

   Source IPv6 Address
     The source IPv6 address for the associated flow.  A value of zero
     (0) indicates that the source NHC will not include this field in
     flow identification.  This field is set by the source NHC and MAY
     NOT be modified by transit or serving NHSs.

   Destination IPv6 Address
     The destination IPv6 address of the associated flow.  A value of
     zero (0) indicates that the source NHC will not include this field
     in flow identification.  This field is set by the source NHC and
     MAY NOT be modified by transit or serving NHSs.

   DPT Len
     This field indicates the number of bits in the Prio./Traffic Class
     (first) portion of the DPT field.  This field is only meaningful
     when the "DPT" bit is set.  Legal values are between 0 and 28.
     This field may contain a different value than the PT Len field.




Berger, Enns             Expires: December 1998                [Page 11]


Internet Draft            NHRP Flow Extension                  June 1998


     This field MUST be initialized by the source NHC to a value of zero
     (0).  Transit and serving NHSs MAY set this field only when the
     received Flow Extension has the DPT bit cleared and the PT bit set.
     If an NHS sets this field, it MUST also set the DPT bit.

   Desired Prio./Traffic Class and Flow Label (DPT)
     This field carries the Prio./Traffic Class and Flow Label fields
     associated with the flow.  The Prio./Traffic Class portion of the
     DPT field indicates the bits that must be set in a data packet's
     Prio./Traffic Class field in order to be associated with the flow.
     The Flow Label portion of the DPT field contains the value that
     must be in a data packet's Flow Label field in order to be
     associated with the flow.

     The division of of the Prio./Traffic Class field is indicated by
     the DPT Len field.  The Prio./Traffic Class field is contained in
     the first (leftmost) DPT Len bits of the DPT field.  The Flow Label
     portion is in the last (rightmost) 28 minus DPT Len bits of the DPT
     field.  This field is only meaningful when the "DPT" bit is set.

     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs add their Prio./Traffic Class related policy information
     by setting cleared bits in the Prio./Traffic Class portion of the
     DPT field.  NHSs MUST NOT clear bits in the Prio./Traffic Class
     field.  NHSs MAY set the Flow Label portion of the field when the
     received Flow Extension has the DPT bit cleared and the PT bit set.
     If an NHS sets the Flow Label portion of the field, it MUST also
     set the DPT bit.

   IPv6 Src Prefix
     This field carries the number of bits of the Source IPv6 Address
     field to be used in identifying data packets associated with the
     flow.  A value of zero (0) indicates that the field SHALL NOT be
     included in flow identification.  A value of 128 indicates a host
     address, i.e. all bits should be used.  Values greater than 128 are
     illegal.  This field is only meaningful when the Source IPv6
     Address field is non-zero and when the "Sa" bit is set.

     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs MAY increase the value based on their policy
     information.  NHSs MUST NOT decrease the value.

   IPv6 Dst Prefix
     This field carries the number of bits of the Destination IPv6
     Address field to be used in identifying data packets associated
     with the flow.  A value of 0 or 128 indicates a host address, i.e.
     all bits should be used.  Values greater than 128 are illegal.
     This field is only meaningful when the Destination IPv6 Address



Berger, Enns             Expires: December 1998                [Page 12]


Internet Draft            NHRP Flow Extension                  June 1998


     field is non-zero and when the the "Da" bit is set.

     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs MAY increase the value based on their policy
     information.  NHSs MUST set the value to 128 to indicate a host
     address policy.  NHSs MUST NOT decrease the value.

3.3 NHRP Flow Extension Format: IPv4-TCP/UDP

   This format is used to describe IPv4 data packets carrying a protocol
   that supports TCP/UDP-like ports.  Specifically protocols that carry
   a 16-bit source port field at the start of the transport header and
   16-bit destination port field starting at bit 16 of the transport
   header.

   Fields and flags not listed have the same meaning as defined in
   previous sections.

       Extension Length = 28

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Flow Type=0x03 |D|   Flags     |Type of Service|    Protocol   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Source IP Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Destination IP Address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    ToS Mask   |  Src Prefix   |  Dst Prefix   |     Unused    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Source Port          |       Destination Port        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Src Range Start       |         Src Range End         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Dst Range Start       |         Dst Range End         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags
      0  1  2  3  4  5  6
     +--+--+--+--+--+--+--+
     |0 |Dr|Sr|Da|Sa|P |T |
     +--+--+--+--+--+--+--+

     Dr
       When set, this bit indicates that flows may be identified using a
       range of acceptable values in the Destination Port field of the
       transport header.  This bit is set by the source NHC and MAY NOT



Berger, Enns             Expires: December 1998                [Page 13]


Internet Draft            NHRP Flow Extension                  June 1998


       be modified by transit or serving NHSs.

     Sr
       When set, this bit indicates that flows may be identified using a
       range of acceptable values in the Source Port field of the
       transport header.  This bit is set by the source NHC and MAY NOT
       be modified by transit or serving NHSs.

   Source Port
     Value of the Source Port field of the transport header for the
     associated flow.  A value of zero (0) indicates that the source NHC
     has not include this field in flow identification.  This field is
     set by the source NHC and MAY NOT be modified by transit or serving
     NHSs.

   Destination Port
     Value of the Destination Port field of the transport header for the
     associated flow.  A value of zero (0) indicates that the source NHC
     has not include this field in flow identification.  This field is
     set by the source NHC and MAY NOT be modified by transit or serving
     NHSs.

   Src Range Start
     This field carries the lower bound on Source Port field values that
     will be considered to be associated with the flow.  A zero (0)
     value indicates that the Source Port field of the transport header
     is not included in flow identification.  This field is only
     meaningful when the Source Port field is non-zero.  When the "Sr"
     bit is cleared (0), an NHS setting this field MUST set the Src
     Range Start and Src Range End fields to the same value.  This field
     MUST NOT be set to a value greater than the Source Port field.

     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs MAY increase the value based on their policy
     information.  NHSs MUST NOT decrease the value.

   Src Range End
     This field carries the upper bound on Source Port field values that
     will be considered to be associated with the flow.  This field is
     only meaningful when the Source Port and Src Range Start fields are
     non-zero.  When the "Sr" bit is cleared (0), an NHS setting this
     field MUST set the Src Range Start and Src Range End fields to the
     same value.  This field MUST NOT be set to a value less than the
     Source Port field.

     This field MUST be initialized by the source NHC to a value of all
     ones (0xffff).  NHSs MAY decrease the value based on their policy
     information.  NHSs MUST NOT increase the value.



Berger, Enns             Expires: December 1998                [Page 14]


Internet Draft            NHRP Flow Extension                  June 1998


   Dst Range Start
     This field carries the lower bound on Destination Port field values
     that will be considered to be associated with the flow.  A zero (0)
     value indicates that the Destination Port field of the transport
     header is not included in flow identification.  This field is only
     meaningful when the Destination Port field is non-zero.  When the
     "Dr" bit is cleared (0), an NHS setting this field MUST set the Dst
     Range Start and Dst Range End fields to the same value.  This field
     MUST NOT be set to a value greater than the Destination Port field.

     This field MUST be initialized by the source NHC to a value of zero
     (0).  NHSs MAY increase the value based on their policy
     information.  NHSs MUST NOT decrease the value.

   Dst Range End
     This field carries the upper bound on Destination Port field values
     that will be considered to be associated with the flow.  This field
     is only meaningful when the Destination Port and Dst Range Start
     fields are non-zero.  When the "Dr" bit is cleared (0), an NHS
     setting this field MUST set the Dst Range Start and Dst Range End
     fields to the same value.  This field MUST NOT be set to a value
     less than the Destination Port field.

     This field MUST be initialized by the source NHC to a value of all
     ones (0xffff).  NHSs MAY decrease the value based on their policy
     information.  NHSs MUST NOT increase the value.

3.4 NHRP Flow Extension Format: IPv6-TCP/UDP

   This format is used to describe IPv6 data packets carrying a protocol
   that supports TCP/UDP-like ports.

   Fields and flags not listed have the same meaning as defined in
   previous sections.

















Berger, Enns             Expires: December 1998                [Page 15]


Internet Draft            NHRP Flow Extension                  June 1998


       Extension Length = 60

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Flow Type=0x04 |D|        IPv6 Flags           |  Next Header  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |PT Len |      Prio./Traffic Class/Flow Label (PT)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |              Source IPv6 Address (16 bytes)                   |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |           Destination IPv6 Address (16 bytes)                 |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |DPT Len|     Desired Prio./Traffic Class/Flow Label  (DPT)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |IPv6 Src Prefix|IPv6 Dst Prefix|            Unused             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Source Port          |       Destination Port        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Src Range Start       |         Src Range End         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Dst Range Start       |         Dst Range End         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Flags
       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                unused         |Dr |Sr |Da |Sa |DPT|PT |NH |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

3.5 NHRP Flow Extension Format: IPv4-IPSEC

   This format is used to describe IPv4 data packets carrying an IPSEC
   transport protocol.  There are currently two such protocols defined:
   Authentication Header (AH), for authentication[RFC1826]; and
   Encapsulating Security Payload (ESP), for integrity and
   confidentiality[RFC1827].  Flows are identified for both protocols
   using the protocol's IPSEC Security Parameter Index, or SPI, field.

   Fields and flags not listed have the same meaning as defined in
   previous sections.



Berger, Enns             Expires: December 1998                [Page 16]


Internet Draft            NHRP Flow Extension                  June 1998


       Extension Length = 20

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Flow Type=0x05 |D|   Flags     |Type of Service|    Protocol   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Source IP Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Destination IP Address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    ToS Mask   |  Src Prefix   |  Dst Prefix   |     Unused    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Security Parameter Index (SPI)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags
      0  1  2  3  4  5  6
     +--+--+--+--+--+--+--+
     | unused |Da|Sa|P |T |
     +--+--+--+--+--+--+--+

   Security Parameter Index
     The Security Parameter Index (SPI) field value associated with the
     flow.  The SPI field is 32-bits long and located at the start of
     the transport header for ESP, and at bit 32 of the transport header
     for AH.  This value is set by the source NHC and MAY NOT be
     modified by transit or serving NHSs.

3.6 NHRP Flow Extension Format: IPv6-IPSEC

   This format is used to describe IPv6 data packets carrying an IPSEC
   transport protocol.

   Fields and flags not listed have the same meaning as defined in
   previous sections.















Berger, Enns             Expires: December 1998                [Page 17]


Internet Draft            NHRP Flow Extension                  June 1998


       Extension Length = 56

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Flow Type=0x06 |D|        IPv6 Flags           |  Next Header  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |PT Len |      Prio./Traffic Class/Flow Label (PT)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |              Source IPv6 Address (16 bytes)                   |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |            Destination IPv6 Address (16 bytes)                |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |DPT Len|     Desired Prio./Traffic Class/Flow Label  (DPT)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |IPv6 Src Prefix|IPv6 Dst Prefix|            Unused             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Security Parameter Index (SPI)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Flags
       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                unused                 |Da |Sa |DPT|PT |NH |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

4. Message Processing

   If a requester wishes to obtain flow information, it SHALL include
   the Flow Extension in the NHRP Resolution Request.  The requester
   SHOULD include the most specific flow type that it supports.  The
   requester MAY specify a particular flow or subset of flows by setting
   some or all of the fields in the flow detail to non-zero values.

   When processing NHRP Resolution Request messages, NHSs that support
   the Flow Extension MUST verify that the Request is following the
   routed path.  The NHS checks if the sender of the message is an NHC.
   When the sender is an NHC, the NHS verifies that the NHC is one of
   its served NHCs.  If the sending NHC is not a served NHC, then the
   NHS MUST generate an NHRP Error Indication with an Error Code of
   Protocol Error.



Berger, Enns             Expires: December 1998                [Page 18]


Internet Draft            NHRP Flow Extension                  June 1998


   If the protocol check passes, NHSs processing Request messages
   containing a Flow Extension MUST examine the described flow to verify
   that it is acceptable.  Both the request and policy information
   related fields MUST be examined.  The request portion of the
   extension is unacceptable if data packets matching the flow would not
   be forwarded.  The policy information is unacceptable if the Flow
   Extension cannot be updated to reflect an NHS' policy information.
   If both portions are acceptable, the NHS MUST update the policy
   information related fields as needed to reflect its policy and then
   handle the Request message per [RFC2332].  Note that an NHS MAY NOT
   change any policy information field to be less restrictive.

   If either the request or policy information portions of the Flow
   Extension is unacceptable, the NHS MUST issue a NAK Resolution Reply
   of type Administratively Prohibited.  The NHS MUST update the Flow
   Extension to reflect the matching policy and SHOULD set the "D" bit.
   When updating the policy information portion of the Flow Extension,
   an NHS SHOULD describe the matching (failed or acceptable) policy in
   the broadest possible terms rather than simply replaying the
   requested flow.  An NHS responder MAY choose to reply with limited
   information for security reasons.

   On receipt of a Resolution Reply message that contains a Flow
   Extension, a requester that supports the Flow Extension SHOULD follow
   the policy information relayed in the extension.  If the requester
   does not follow the policy, the requester MUST NOT forward data
   packets based on the information contained in the reply message.  A
   requester may chose not to follow a relayed policy because the policy
   is unacceptable or due to resource limitations.

   In the expected normal case, the requester will follow the policy
   information relayed in the extension.  When the message is a NAK
   Resolution Reply of type Administratively Prohibited the requester
   SHOULD check the "D" bit in the Flow Extension.  If the bit is set,
   data packets matching the flow information SHOULD be silently
   discarded.  If the requester forwards matching data packets, such
   packets MUST be forwarded via the routed path.

   When the received Resolution Reply message does not contain a NAK,
   the requester SHOULD forward data packets that match the flow
   specified in the Flow Extension using the information contained in
   the Resolution Reply.  The requester MUST NOT forward data packets
   that do not match specified flow using the information contained in
   the Resolution Reply.







Berger, Enns             Expires: December 1998                [Page 19]


Internet Draft            NHRP Flow Extension                  June 1998


5. IANA Considerations

   IANA is requested to manage and assign the range of Flow Type field
   values from 0x07 to 0x7F.  New assignments should be made with the
   guidance of the relevant IESG Area Director or their designee.
   Additionally, all requests for assignments should be honored when the
   usage of the requested value is documented in a publicly available
   and unrestricted (including time) form.  Preferably the document will
   be available via a standards organization's web site.

6. References

   [RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
             August 1995.

   [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC
             1827, NRL, August 1995.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels," RFC 2119.

   [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., Doraswamy, N.,
             "NBMA Next Hop Resolution Protocol (NHRP)," RFC 2332.


7. Acknowledgments

   The authors thank Rajesh Varadarajan, Ravi Shekhar and Jim Luciani
   for their valuable comments and corrections.

8. Authors'  Addresses

   Lou Berger                           Rob Enns
   FORE Systems                         Berkeley Networks
   1595 Spring Hill Road                1805 McCandless Drive
   Vienna, VA 22182 USA                 Milpitas, CA 95035
   Phone:  +1 703-245-4544              Phone:  408-719-3059
   Email:  lberger@fore.com             Email:  rpe@berkeleynet.com













Berger, Enns             Expires: December 1998                [Page 20]