Skip to main content

Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)
draft-claise-export-application-info-in-ipfix-10

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6759.
Authors Benoît Claise , Paul Aitken, Nir Ben-Dvora
Last updated 2020-01-21 (Latest revision 2012-08-08)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 6759 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ron Bonica
IESG note ** No value found for 'doc.notedoc.note' **
Send notices to n.brownlee@auckland.ac.nz
draft-claise-export-application-info-in-ipfix-10
IPFIX Working Group                                    B. Claise 
     Internet-Draft                                         P. Aitken 
     Intended Status: Informational                      N. Ben-Dvora 
     Expires: February 8, 2013                    Cisco Systems, Inc. 
                                                       August 8, 2012 
                                                                      
      
          Cisco Systems Export of Application Information in IPFIX 
              draft-claise-export-application-info-in-ipfix-10 

     Status of this Memo 

        This document is not an Internet Standards Track 
        specification; it is published for informational purposes.   
         
        This document is a product of the Internet Engineering Task 
        Force (IETF).  It represents the consensus of the IETF 
        community.  It has received public review and has been 
        approved for publication by the Internet Engineering 
        Steering Group (IESG).  Not all documents approved by the 
        IESG are a candidate for any level of Internet Standard; 
        see Section 2 of RFC 5741.  
         
        Information about the current status of this document, any 
        errata, and how to provide feedback on it may be obtained 
        at http://www.rfc-editor.org/info/rfc<rfc-no>. 
         
        EDITOR NOTES: The above text is the consensus from the IESG 
        meeting regarding this document. Note that the <RFC-no> 
        must be updated. The text below has been kept for 
        completeness. 
         
        This Internet-Draft is submitted to IETF in full 
        conformance with the provisions of BCP 78 and BCP 79.  
         
        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."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be 
        accessed at http://www.ietf.org/shadow.html  
         

     <Claise, Aitken, Ben-Dvora>   Expires Feb 8 2013          [Page 1] 

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        This Internet-Draft will expire on January 8, 2013. 
         

         
         
                                                                    
                             

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 2] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

     Copyright Notice 
         
        Copyright (c) 2012 IETF Trust and the persons identified as 
        the document authors.  All rights reserved. 
         
        This document is subject to BCP 78 and the IETF Trust's 
        Legal Provisions Relating to IETF Documents 
        (http://trustee.ietf.org/license-info) in effect on the 
        date of publication of this document.  Please review these 
        documents carefully, as they describe your rights and 
        restrictions with respect to this document.  Code 
        Components extracted from this document must include 
        Simplified BSD License text as described in Section 4.e of 
        the Trust Legal Provisions and are provided without 
        warranty as described in the Simplified BSD License. 
                            
      

     Abstract 

        This document specifies an Cisco Systems extension to the 
        IPFIX information model specified in [RFC5102] to export 
        application information. 
         
         
     Conventions used in this document 

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
        and "OPTIONAL" in this document are to be interpreted as 
        described in RFC 2119 [RFC2119]. 
      

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 3] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

     Table of Contents 

         
        1. Introduction.......................................... 5 
        1.1. Application Information Use Cases................... 7 
        2. IPFIX Documents Overview.............................. 8 
        3. Terminology........................................... 8 
           3.1. New Terminology.................................. 9 
        4. applicationId Information Element Specification....... 9 
           4.1. Existing Classification Engine IDs.............. 10 
           4.2. Selector ID Length per Classification IDs....... 14 
           4.3. Application Name Options Template Record........ 15 
           4.4. Resolving IANA L4 Port Discrepancies............ 16 
        5. Grouping the Applications with the Attributes........ 16 
           5.1. Options Template Record for the Attribute Values 18 
        6. Application Id Examples.............................. 18 
           6.1. Example 1: Layer 2 Protocol..................... 18 
           6.2. Example 2: Standardized IANA Layer 3 Protocol... 20 
           6.3. Example 3: Proprietary Layer 3 Protocol......... 21 
           6.4. Example 4: Standardized IANA Layer 4 Port....... 22 
           6.5. Example 5: Layer 7 Application.................. 23 
           6.6. Example 6: Layer 7 Application with Private 
           Enterprise Number (PEN).............................. 24 
           6.7. Example: port Obfuscation....................... 26 
           6.8. Example: Application Name Mapping Options Template27 
           6.9. Example: Attributes Values Options Template Record28 
        7. IANA Considerations.................................. 29 
           7.1. New Information Elements........................ 29 
           7.1.1. applicationDescription........................ 30 
           7.1.2. applicationId................................. 30 
           7.1.3. applicationName............................... 30 

           7.1.4. classificationEngineId....................... 30 
           7.1.5. applicationCategoryName....................... 33 
           7.1.6. applicationSubCategoryName.................... 33 
           7.1.7. applicationGroupName.......................... 33 
           7.1.8. p2pTechnology................................. 34 
           7.1.9. tunnelTechnology.............................. 34 
           7.1.10. encryptedTechnology.......................... 34 
           7.2. Classification Engine Ids Registry.............. 35 
        8. Security Considerations.............................. 35 
        9. References........................................... 36 
           9.1. Normative References............................ 36 
           9.2. Informative References.......................... 36 
        10. Acknowledgement..................................... 38 
        11. Authors' Addresses.................................. 39 
        Appendix A.  Additions to XML Specification of IPFIX 
        Information Elements (non normative).................... 39 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 4] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        Appendix B.  Port Collisions Tables (non normative)..... 45 
        Appendix C.  Application Registry Example (non normative)49 
         
         

     List of Figures and Tables 

         
        Figure 1: applicationId Information Element ............. 9 
        Table 1: Existing Classification Engine IDs ............ 13 
        Table 2: Selector ID default length per Classification 
           Engine ID ........................................... 14 
        Table 3: Application Id Static Attributes .............. 17 
        Table 4: Different Protocols on UDP and TCP ............ 47 
        Table 5: Different Protocols on SCTP and TCP ........... 49 
         

      
     1. Introduction 

      Today service providers and network administrators are 
      looking for visibility into the packet content rather than 
      just the packet header.  Some network devices Metering 
      Processes inspect the packet content and identify the 
      applications that are utilizing the network traffic.  
      Applications in this context are defined as networking 
      protocols used by networking processes that exchange 
      packets between them (such as web applications, peer to 
      peer applications, file transfer, e-mail applications, 
      etc.).  Applications can be further characterized by other 
      criteria, some of which are application specific. 
      Examples include: web application to a specific domain, per 
      user specific traffic, a video application with a specific 
      codec, etc... 
       
      The application identification is based on several 
      different methods or even a combination of methods:  
      1. L2 (Layer 2) protocols (such as ARP (Address Resolution 
        Protocol), PPP (Point-to-Point Protocol), LLDP (Link 
        Layer Discovery Protocol)) 
      2. IP protocols (such as ICMP (Internet Control Message 
        Protocol), IGMP (Internet Group Management Protocol), 
        GRE (Generic Routing Encapsulation) 
      3. TCP or UDP ports (such as HTTP, Telnet, FTP) 

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 5] 

                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      4. Application layer header (of the application to be 
        identified) 
      5. Packet data content  
      6. Packets and traffic behavior 
       
      The exact application identification methods are part of 
      the Metering Process internals that aim to provide an 
      accurate identification and minimize false identification.  
      This task requires a sophisticated Metering Process since 
      the protocols do not behave in a standard manner. 
       
      1. Applications use port obfuscation where the 
        application runs on different port than the IANA 
        assigned one.  For example an HTTP server might 
        run a TCP port 23 (assigned to telnet in [IANA-
        PORTS]) 
         
      2. IANA port registries do not accurately reflect how 
        certain ports are "commonly" used today.  Some 
        ports are reserved, but the application either 
        never became prevalent or is not in use today. 
           
      3. The application behavior and identification logic 
        become more and more complex 
           
      For that reason, such Metering Processes usually 
      detect applications based on multiple mechanisms in 
      parallel.  Detection based only on port matching 
      might wrongly identify the application.  If the 
      Metering Process is capable of detecting applications 
      more accurately, it is considered to be stronger and 
      more accurate. 
       
      Similarly, a reporting mechanism that uses L4 port based 
      applications only, such as L4:<known port>, would have 
      similar issues.  The reporting system should be capable of 
      reporting the applications classified using all types of 
      mechanisms.  In particular applications that do not have 
      any IANA port definition.  While a mechanism to export 
      application information should be defined, the L4 port 
      being used must be exported using the destination port 
      (destinationTransportPort at [IANA-IPFIX]) in the 
      corresponding IPFIX record. 
       
      This document specifies the Cisco Systems application 
      information encoding (as described in section 4. ) to 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 6] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      export the application information with the IPFIX protocol 
      [RFC5101].  
       
      Applications could be identified at different OSI layers, 
      from layer 2 to layer 7.  For example: Link Layer 
      Distribution Protocol (LLDP) [LLDP] can be identified in 
      layer 2, ICMP can be identified in layer 3 [IANA-PROTO], 
      HTTP can be identified in layer 4 [IANA-PORTS], and Webex 
      can be identified in layer 7. 
       
      While an ideal solution would be an IANA registry for 
      applications above (or inside the payload of) the well-
      known ports [IANA-PORTS], this solution is not always 
      possible. Indeed, the specifications for some applications 
      embedded in the payload are not available. Some reverse 
      engineering as well as a ubiquitous language for 
      application identification, would be required conditions to 
      be able to manage an IANA registry for these types of 
      applications.  Clearly, these are blocking factors.  
       
      This document specifies the Cisco Systems application 
      information encoding. However, the layer 7 application 
      registry values are out of scope of this document.   
      
      
     1.1. Application Information Use Cases 

      There are several use cases for application information: 
       
      1. Application Visibility 
         
        This is one of the main cases for using the application 
        information.  Network administrators are using 
        application visibility to understand the main network 
        consumers, network trends and user behavior. 
         
      2. Security Functions 
         
        Application knowledge is sometimes used in security 
        functions in order to provide comprehensive functions 
        such as Application based firewall, URL filtering, 
        parental control, intrusion detection, etc. 
         
      All of the above use cases require exporting application 
      information to provide the network function itself or to 
      log the network function operation. 
      
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 7] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      

     2. IPFIX Documents Overview 

      The IPFIX Protocol [RFC5101] provides network administrators 
      with access to IP Flow information. 
       
      The architecture for the export of measured IP Flow 
      information out of an IPFIX Exporting Process to a Collecting 
      Process is defined in the IPFIX Architecture [RFC5470], per 
      the requirements defined in RFC 3917 [RFC3917]. 
       
      The IPFIX Architecture [RFC5470] specifies how IPFIX Data 
      Records and Templates are carried via a congestion-aware 
      transport protocol from IPFIX Exporting Processes to IPFIX 
      Collecting Processes. 
       
      IPFIX has a formal description of IPFIX Information Elements, 
      their name, type and additional semantic information, as 
      specified in the IPFIX information model [RFC5102]. 
       
      In order to gain a level of confidence in the IPFIX 
      implementation, probe the conformity and robustness, and 
      allow interoperability, the Guidelines for IPFIX Testing 
      [RFC5471] presents a list of tests for implementers of 
      compliant Exporting Processes and Collecting Processes. 
      
      The Bidirectional Flow Export [RFC5103] specifies a method 
      for exporting bidirectional flow (biflow) information using 
      the IP Flow Information Export (IPFIX) protocol, representing 
      each Biflow using a single Flow Record. 
       
      The "Reducing Redundancy in IP Flow Information Export 
      (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] 
      specifies a bandwidth saving method for exporting Flow or 
      packet information, by separating information common to 
      several Flow Records from information specific to an 
      individual Flow Record: common Flow information is exported 
      only once. 
      
     3. Terminology 

      IPFIX-specific terminology used in this document is defined 
      in Section 2 of the IPFIX protocol specification [RFC5101].  
      As in [RFC5101], these IPFIX-specific terms have the first 
      letter of a word capitalized when used in this document. 
       
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 8] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

       
     3.1. New Terminology 

      Application Id 
       
          A unique identifier for an application.   
         
      When an application is detected, the most granular 
      application is encoded in the Application Id. 
      
      
     4. applicationId Information Element Specification 

        This document specifies the applicationId Information 
        Element, which is a single field composed of two parts: 
         
            1. 8 bits of Classification Engine ID. The 
               Classification Engine can be considered as a 
               specific registry for application assignments. 
            2. m bits of Selector ID. The Selector ID length 
               varies depending on the Classification Engine ID. 
                
         
      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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | Class. Eng. ID|         Selector ID  ...                      | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                             ...                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

               Figure 1: applicationId Information Element 
         
         
        Classification Engine ID 
         
          A unique identifier for the engine which determined the 
          Selector ID.  Thus the Classification Engine ID defines 
          the context for the Selector ID. 
         
        Selector ID 
           
         A unique identifier of the application for a specific 
         Classification Engine ID.  Note that the Selector ID 
         length varies depending on the Classification Engine 
         ID. 
      
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013        [Page 9] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        The Selector ID term is similar in concepts with the 
        selectorId Information Element, specified in the PSAMP 
        Protocol [RFC5476][RFC5477].  
         
         
     4.1. Existing Classification Engine IDs 

         
        The following Classification Engine IDs have been 
        allocated: 
         
           Name            Value  Description 
                                            
                           0      Invalid. 
                                     
           IANA-L3         1      The Assigned Internet Protocol 
                                    Number (layer 3 (L3)) is exported 
                                    in the Selector ID. 
                                    See [IANA-PROTO]. 
                                     
           PANA-L3         2      Proprietary layer 3 definition. 
                                    An enterprise can export its own 
                                    layer 3 protocol numbers. The 
                                    Selector ID has a global 
                                    significance for all devices from 
                                    the same enterprise. 
                                     
           IANA-L4         3      The IANA layer 4 (L4) well-known 
                                    port number is exported in the 
                                    Selector ID. See [IANA-PORTS]. 
                                    Note: as an IPFIX flow is 
                                    unidirectional, it contains the 
                                    destination port in a flow from 
                                    the client to the server.  
                                     
           PANA-L4         4      Proprietary layer 4 definition. 
                                    An enterprise can export its own 
                                    layer 4 port numbers. The 
                                    Selector ID has global 
                                    significance for devices from the 
                                    same enterprise. Example: IPFIX 
                                    had the port 4739 pre-assigned in 
                                    the IETF draft for years. While 
                                    waiting for the RFC and its 
                                    associated IANA registration, the 
                                    Selector ID 4739 was used with 
                                    this PANA-L4. 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 10] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                                     
                           5      Reserved. 
                                     
           USER-           6      The Selector ID represents 
           Defined                 applications defined by the user 
                                    (using CLI, GUI, etc.) based on 
                                    the methods described in section 
                                    1.  The Selector ID has a local 
                                    significance per device. 
                                     
                           7      Reserved. 
                                     
                           8      Reserved. 
                                     
                           9      Reserved. 
                                     
                           10     Reserved. 
                                     
                           11     Reserved. 
                                     
           PANA-L2         12     Proprietary layer 2 (L2) 
                                    definition.  An enterprise can 
                                    export its own layer 2 
                                    identifiers.  The Selector ID 
                                    represents the enterprise's 
                                    unique global layer 2 
                                    applications. The Selector ID has 
                                    a global significance for all 
                                    devices from the same enterprise. 
                                    Examples include Cisco Subnetwork 
                                    Access Protocol (SNAP). 
                                     
           PANA-L7         13     Proprietary layer 7 definition. 
                                    The Selector ID represents the 
                                    enterprise's unique global ID for 
                                    the layer 7 applications. The 
                                    Selector ID has a global 
                                    significance for all devices from 
                                    the same enterprise. This 
                                    Classification Engine Id is used 
                                    when the application registry is 
                                    owned by the Exporter 
                                    manufacturer (referred to as the 
                                    "enterprise" in this document).   
                                     
                           14     Reserved. 
                                     
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 11] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                           15     Reserved. 
                                     
                           16     Reserved. 
                                     
                           17     Reserved. 
                                     
           ETHERTYPE       18     The Selector ID represents the 
                                    well-known Ethertype. See 
                                    [ETHERTYPE]. Note that the 
                                    Ethertype is usually expressed in 
                                    hexadecimal. However, the 
                                    corresponding decimal value is 
                                    used in this Selector ID. 
                                     
           LLC             19     The Selector ID represents the               
                                    well-known IEEE 802.2 Link Layer 
                                    Control (LLC) Destination Service 
                                    Access Point (DSAP). See [LLC]. 
                                    Note that LLC DSAP is usually 
                                    expressed in hexadecimal. 
                                    However, the corresponding 
                                    decimal value is used in this 
                                    Selector ID. 
                                     
           PANA-L7-        20     Proprietary layer 7 definition,              
           PEN                     including a Private Enterprise 
                                    Number (PEN) [PEN] to identify 
                                    that the application registry 
                                    being used is not owned by the 
                                    Exporter manufacturer (referred 
                                    to as the "enterprise" in this 
                                    document, and identified by the 
                                    PEN), or to identify the original 
                                    enterprise in the case of a 
                                    mediator or 3rd party device. The 
                                    Selector ID represents the 
                                    enterprise unique global ID for 
                                    the layer 7 applications. The 
                                    Selector ID has a global 
                                    significance for all devices from 
                                    the same enterprise. 
                                     
                           21 to          
                            255    Available (255 is the maximum 
                                    Engine ID) 
                                       
                                 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 12] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

               Table 1: Existing Classification Engine IDs 
         
        "PANA = Proprietary Assigned Number Authority".  In other 
        words, an enterprise specific version of IANA for 
        internal IDs.   
         
        The PANA-L7 Classification Engine ID SHOULD be used when 
        the application registry is owned by the Exporter 
        manufacturer, referred to as the "enterprise" in this 
        document, and identified by the PEN.  Even if the 
        application registry is owned by the Exporter 
        manufacturer, the PANA-L7-PEN MAY be used, specifying the 
        manufacturer. 
        The mechanism for the Collector to know about Exporter 
        PEN is out of scope of this document.  Possible tracks 
        are: SNMP polling, an Options Template export, hardcoded 
        value, etc.  
         
        An Exporter may classify the application according to 
        another vendor's application registry. E.g., an IPFIX 
        Mediator [RFC6183] may need to re-export applications 
        received from different Exporters using different PANA-L7 
        application registries.  For example, X's IPFIX Mediator 
        aggregates traffic from some Exporters which report 
        enterprise Y applications and other Exporters which 
        report enterprise Z applications. Or, X's device 
        implements enterprise Y's application classifications.  
        In these cases, the PANA-L7-PEN Classification Engine 
        MUST be used, which allows the original enterprise ID to 
        be reported. The ID of the enterprise which defined the 
        application ID is identified by the enterprise's PEN. An 
        example is displayed in section 6.6.  
         
        Note that the the PANA-L7 Classification Engine ID is 
        also used for resolving IANA L4 port Discrepancies (see 
        Section 4.4) 
         
        The list in table 1 is maintained by IANA thanks to the 
        registry within the classificationEngineId Information 
        Element. See the "IANA Considerations" section.  The 
        Classification Engine Id is part of the Application Id 
        encoding, so the classificationEngineId Information 
        Element is currently not required by the specifications 
        in this document.  However, this Information Element was 
        created for completeness, as it was anticipated that this 
        Information Element will be required in the future. 
          
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 13] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

         
     4.2. Selector ID Length per Classification IDs 

        As the Selector Id part of the Application Id is variable 
        based on the Classification Engine ID value, the 
        applicationId SHOULD be encoded in a variable-length 
        Information Element [RFC5101] for the IPFIX export. 
         
        The following table displays the Selector ID default 
        length for the different Classification Engine IDs. 
         
           Classification               Selector ID default 
           Engine ID Name               length (in bytes) 
                                          
           IANA-L3                      1 
                                          
           PANA-L3                      1 
                                          
           IANA-L4                      2 
                                          
           PANA-L4                      2 
                                          
           USER-Defined                 3 
                                          
           PANA-L2                      5 
                                          
           PANA-L7                      3 
                                          
           ETHERTYPE                    2 
                                          
           LLC                          1 
                                          
           PANA-L7-PEN                  3 (*) 
                                     
                    Table 2: Selector ID default length 
                       per Classification Engine ID 
         
        (*) There is an extra 4 bytes for the PEN. However, the PEN 
        is not considered part of the Selector ID. 
         
        If a legacy protocol such as NetFlow version 9 [RFC3954] is 
        used, and this protocol doesn't support variable length 
        Information Elements, then either multiple Template Records 
        (one per applicationId length), or a single Template Record 
        corresponding to the maximum sized applicationId MUST be 
        used.   
         
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 14] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        Application Ids MAY be encoded in a smaller number of 
        bytes, following the same rules as for the IPFIX Reduced 
        Size Encoding [RFC5101].   
         
        Application Ids MAY be encoded with a larger length.  
        For example, a normal IANA L3 protocol encoding would take 
        2 bytes since the Selector ID represents the protocol field 
        from the IP header encoded in one byte.  However, an IANA 
        L3 protocol encoding may be encoded with 3 bytes.  In this 
        case, the Selector ID value MUST always be encoded in the 
        least significant bits as shown in Figure 2. 
         
       
      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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |Class. Eng. ID |zero-valued upper-bits ... Selector ID         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                      Figure 2: Selector ID encoding 
         
         
     4.3. Application Name Options Template Record 

        For Classification Engines which specify locally unique 
        Application Ids (which means unique per engine and per 
        router), an Options Template Record (see [RFC5101]) MUST 
        be used to export the correspondence between the 
        Application Id, the Application Name, and the Application 
        Description.   
         
        For Classification Engines which specify globally unique 
        Application Ids, an Options Template Record MAY be used 
        to export the correspondence between the Application Id, 
        the Application Name and the Application Description, 
        unless the mapping is hardcoded in the Collector, or 
        known out of band (for example, by polling a MIB). 
         
        An example Options Template is shown in section 6.8.   
         
        Enterprises may assign company-wide Application Id values 
        for the PANA-L7 Classification Engine.  In this case, a 
        possible optimization for the Collector is to keep the 
        mappings between the Application Ids and the Application 
        Names per enterprise, as opposed to per Exporter. 
         

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 15] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      
     4.4. Resolving IANA L4 Port Discrepancies 

        Even though the IANA L4 ports usually point to the same 
        protocols for both UDP, TCP or other transport types, there 
        are some exceptions, as mentioned in the Appendix B. 
         
        Instead of imposing the transport protocol 
        (UDP/TCP/SCTP/etc.) in the scope of the "Application Name 
        Options Template Record" (section 6.8. ) for all 
        applications (on top of having the transport protocol as 
        key-field in the Flow Record definition), the convention is 
        that the L4 application is always TCP related.  So, 
        whenever the Collector has a conflict in looking up IANA, 
        it would choose the TCP choice.  As a result, the UDP L4 
        applications from Table 3 and the SCTP L4 applications from 
        Table 4 are assigned in the PANA_L7 Application Id range, 
        i.e. under Classification Engine ID 13. 
       
        Currently, there are no discrepancies between the well 
        known ports for TCP and DCCP. 
         
         
     5. Grouping the Applications with the Attributes 

      Due to the high number of different Application Ids, 
      Application Ids MAY be categorized into groups.  This offers 
      the benefits of easier reporting and action, such as QoS 
      policies.  Indeed, most applications with the same 
      characteristics should be treated the same way; for example, 
      all video traffic.  
       
      Attributes are statically assigned per Application Id and are 
      independent of the traffic. The attributes are listed below: 
           
             Name                   Description 
                                     
             Category               An attribute that provides a first 
                                    level categorization for each 
                                    Application Id. Examples include: 
                                    browsing, email, file-sharing, 
                                    gaming, instant messaging, voice-
                                    and-video, etc... 
                                    The category attribute is encoded by 
                                    the ApplicationCategoryName 
                                    Information Element. 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 16] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                                     
             Sub-Category           An attribute that provides a second 
                                    level categorization for each 
                                    Application Id. Examples include: 
                                    backup-systems, client-server, 
                                    database, routing-protocol, etc... 
                                    The sub-category attribute is 
                                    encoded by the 
                                    ApplicationSubCategoryName 
                                    Information Element. 
                                     
             Application-           An attribute that groups multiple 
             Group                  Application Ids that belong to the 
                                    same networking application. For 
                                    example, the ftp-group contain the 
                                    ftp-data (port 20), ftp (port 20), 
                                    ni-ftp (port 47), sftp (port 115), 
                                    bftp (port 152), ftp-agent(port 
                                    574), ftps-data (port 989). The 
                                    application-group attribute is 
                                    encoded by the ApplicationGroupName 
                                    Information Element. 
                                     
             P2P-Technology         Specifies if the Application Id is 
                                    based on peer-to-peer technology. 
                                    The P2P-technology attribute is 
                                    encoded by the p2pTechnology 
                                    Information Element. 
                                     
             Tunnel-                Specifies if the Application Id is 
             Technology             used as a tunnel technology. The 
                                    tunnel-technology attribute is 
                                    encoded by the tunnelTechnology 
                                    Information Element. 
                                     
             Encrypted              Specifies if the Application Id is 
                                    an encrypted networking protocol. 
                                    The encrypted attribute is encoded 
                                    by the encryptedTechnology 
                                    Information Element. 
      
                 Table 3: Application Id Static Attributes 
           
         
        Every application is assigned to one 
        ApplicationCategoryName, one ApplicationSubCategoryName, 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 17] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        one ApplicationGroupName, has one p2pTechnology, one 
        tunnelTechnology, and one encryptedTechnology.  These new 
        Information Elements are specified in the IANA 
        Consideration Section 7.1. 7.1.  
         
        Maintaining the attribute values in IANA seems impossible 
        to realize.  Therefore the attribute values per application 
        are enterprise specific.   
      
         
     5.1. Options Template Record for the Attribute Values 

        An Options Template Record (see [RFC5101]) SHOULD be used 
        to export the correspondence between each Application Id 
        and its related Attribute values.  An alternative way for 
        the Collecting Process to learn the correspondence is to 
        populate these mappings out of band, for example, by 
        loading a CSV file containing the correspondence table. 
         
        The Attributes Option Template contains the ApplicationId 
        as a scope field, followed by the ApplicationCategoryName, 
        the ApplicationSubCategoryName, the ApplicationGroupName, 
        the p2pTechnology, the tunnelTechnology, and the 
        encryptedTechnology Information Elements. 
      
        A list of attributes may conveniently be exported using a 
        subTemplateList per [RFC6313]. 
         
        An example is given in section 6.9.  
      
         
     6. Application Id Examples 

        The following examples are created solely for the purpose 
        of illustrating how the extensions proposed in this 
        document are encoded. 
      

     6.1. Example 1: Layer 2 Protocol 

        The list of Classification Engine IDs in Table 1 shows that 
        the layer 2 Classification Engine IDs are 12 (PANA-L2), 18, 
        (Ethertype) and 19 (LLC). 
         
        From the Ethertype list, LLDP [LLDP] has the Selector ID 
        value 0x88CC, so 35020 in decimal: 
         
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 18] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        NAME    Selector ID 
        LLDP    35020 
         
        So, in the case of LLDP, the Classification Engine ID is 18 
        (LLC) while the Selector ID has the value 35020. 
         
        Per section 4. , the applicationId Information Element, 
        is a single field composed of 8 bits of Classification 
        Engine ID, followed by m bits of Selector ID. 
         
        Therefore the Application Id is encoded as: 
         
            0                   1                   2 
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
           |       18      |             35020             | 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
        So the Application Id has the decimal value of 1214668.  
        The format '18..35020' is used for simplicity in the 
        examples below, to clearly express that two components of 
        the Application ID. 
         
        The Exporting Process creates a Template Record with a few 
        Information Elements: amongst other things, the Application 
        Id. For example: 
         
        - applicationId (key field) 
        - octetTotalCount (non key field) 
         
        For example, a Flow Record corresponding to the above 
        Template Record may contain: 
         
            { applicationId='18..35020', 
              octetTotalCount=123456 } 
         
        The Collector has all the required information to determine 
        that the application is LLDP, because the Application Id 
        uses a global and well known registry, i.e. the Ethertype.  
        The Collector can determine which application is 
        represented by the Application Id by loading the registry 
        out of band. 

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 19] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      

     6.2. Example 2: Standardized IANA Layer 3 Protocol 

        From the list of Classification Engine IDs in Table 1, the 
        IANA layer 3 Classification Engine ID (IANA-L3) is 1. 
          
        From the list of IANA layer 3 protocols (see [IANA-PROTO]), 
        ICMP has the value 1: 
                                      
        Decimal    Keyword    Protocol                   Reference 
        1          ICMP       Internet Control           [RFC792] 
                               Message 
         
        So in the case of the standardized IANA layer 3 protocol 
        ICMP, the Classification Engine ID is 1, and the Selector 
        ID has the value of 1.  
         
        Therefore the Application Id is encoded as: 
         
            0                   1            
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
           |       1       |       1       | 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
        So the Application Id has the value of 257.  The format 
        '1..1'  is used for simplicity in the examples below. 
         
        The Exporting Process creates a Template Record with a few 
        Information Elements: amongst other things, the Application 
        Id. For example: 
         
        - sourceIPv4Address (key field) 
        - destinationIPv4Address (key field) 
        - ipDiffServCodePoint (key field) 
        - applicationId (key field) 
        - octetTotalCount (non key field) 
         
        For example, a Flow Record corresponding to the above 
        Template Record may contain: 
         
            { sourceIPv4Address=192.0.2.1,  
              destinationIPv4Address=192.0.2.2, 
              ipDiffServCodePoint=0,  
              applicationId='1..1', 

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 20] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

              octetTotalCount=123456 } 
         
        The Collector has all the required information to determine 
        that the application is ICMP, because the Application Id 
        uses a global and well know registry, ie the IANA L3 
        protocol number.  
         
         
     6.3. Example 3: Proprietary Layer 3 Protocol 

        Assume that a enterprise has specified a new layer 3 
        protocol called "foo".  
         
        From the list of Classification Engine IDs in Table 1, the 
        proprietary layer 3 Classification Engine ID (PANA-L3) is 
        2. 
         
        A global registry within the enterprise specifies that the 
        "foo" protocol has the value 90: 
         
        Protocol    Protocol Id 
        foo         90 
         
        So, in the case of the layer 3 protocol foo specified by 
        this enterprise, the Classification Engine ID is 2, and the 
        Selector ID has the value of 90. 
         
         
        Therefore the Application Id is encoded as: 
         
            0                   1            
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
           |       2       |       90      | 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
        So the Application Id has the value of 602.  The format 
        '2..90' is used for simplicity in the examples below.  
         
        The Exporting Process creates a Template Record with a few 
        Information Elements: amongst other things, the Application 
        Id. For example: 
         
        - sourceIPv4Address (key field) 
        - destinationIPv4Address (key field) 
        - ipDiffServCodePoint (key field) 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 21] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        - applicationId (key field) 
        - octetTotalCount (non key field) 
         
        For example, a Flow Record corresponding to the above 
        Template Record may contain: 
         
            { sourceIPv4Address=192.0.2.1,  
              destinationIPv4Address=192.0.2.2, 
              ipDiffServCodePoint=0,  
              applicationId='2..90', 
              octetTotalCount=123456 } 
         
        Along with this Flow Record, a new Options Template Record 
        would be exported, as shown in Section 6.8.  
         
                                      
     6.4. Example 4: Standardized IANA Layer 4 Port 

        From the list of Classification Engine IDs in Table 1, the 
        IANA layer 4 Classification Engine ID (PANA-L3) is 3. 
         
        From the list of IANA layer 4 ports (see [IANA-PORTS]), 
        SNMP has the value 161: 
         
        Keyword    Decimal    Description 
        snmp       161/tcp    SNMP 
        snmp       161/udp    SNMP 
         
        So in the case of the standardized IANA layer 4 SNMP port, 
        the Classification Engine ID is 3, and the Selector ID has 
        the value of 161. 
         
        Therefore the Application Id is encoded as: 
         
            0                   1            
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
           |       3       |              161              | 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
        So the Application Id has the value of 196769.  The format 
        '3..161' is used for simplicity in the examples below.  
         
        The Exporting Process creates a Template Record with a few 
        Information Elements: amongst other things, the Application 
        Id. For example: 

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 22] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

         
        - sourceIPv4Address (key field) 
        - destinationIPv4Address (key field) 
        - protocol (key field) 
        - ipDiffServCodePoint (key field) 
        - applicationId (key field) 
        - octetTotalCount (non key field) 
         
        For example, a Flow Record corresponding to the above 
        Template Record may contain: 
         
            { sourceIPv4Address=192.0.2.1,  
              destinationIPv4Address=192.0.2.2, 
              protocol=17, ipDiffServCodePoint=0, 
              applicationId='3..161',  
              octetTotalCount=123456 } 
      
        The Collector has all the required information to determine 
        that the application is SNMP, because the Application Id 
        uses a global and well know registry, ie the IANA L4 
        protocol number.  
      
                                      
     6.5. Example 5: Layer 7 Application 

        In this example, the Metering Process has observed some 
        Webex traffic. 
         
        From the list of Classification Engine IDs in Table 1, the 
        layer 7 unique Classification Engine ID (PANA-L7) is 13.  
         
        Suppose that the Metering Process returns the ID 10000 for 
        Webex traffic. 
         
        So, in the case of this Webex application, the 
        Classification Engine ID is 13 and the Selector ID has the 
        value of 10000. 
         
        Therefore the Application Id 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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      13       |                     10000                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 23] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        So the Application Id has the value of 218113808.  The 
        format '13..10000' is used for simplicity in the examples 
        below. 
         
        The Exporting Process creates a Template Record with a few 
        Information Elements: amongst other things, the Application 
        Id. For example: 
         
        - sourceIPv4Address (key field) 
        - destinationIPv4Address (key field) 
        - ipDiffServCodePoint (key field) 
        - applicationId (key field) 
        - octetTotalCount (non key field) 
         
        For example, a Flow Record corresponding to the above 
        Template Record may contain: 
         
            { sourceIPv4Address=192.0.2.1,  
              destinationIPv4Address=192.0.2.2, 
              ipDiffServCodePoint=0,  
              applicationId='13..10000', 
              octetTotalCount=123456 } 
         
        The 10000 value is globally unique for the enterprise, so 
        that the Collector can determine which application is 
        represented by the Application Id by loading the registry 
        out of band.   
         
        Along with this Flow Record, a new Options Template Record 
        would be exported, as shown in Section 6.8.  
      
                                      
     6.6. Example 6: Layer 7 Application with Private Enterprise 
        Number (PEN) 

        In this example, the layer 7 Webex traffic from Example 5 
        above have been classified by enterprise X. The exported 
        records have been received by enterprise Y's mediation 
        device, which wishes to forward them to a top level 
        Collector. 
         
        In order for the top level Collector to know that the 
        records were classified by enterprise X, the enterprise Y 
        mediation device must report the records using the 
        PANA-L7-PEN Classification Engine ID with enterprise X's 
        Private Enterprise Number. 
         
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 24] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        The PANA-L7-PEN Classification Engine ID is 20, and 
        enterprise X's Selector ID for Webex traffic has the value 
        of 10000. 
         
        Therefore the Application Id 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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      20       |               enterprise ID = X            ...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |...Ent.ID.contd|                     10000                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
        The format '20..X..10000' is used for simplicity in the 
        examples below.  
         
        The Exporting Process creates a Template Record with a few 
        Information Elements: amongst other things, the Application 
        Id. For example: 
         
        - sourceIPv4Address (key field) 
        - destinationIPv4Address (key field) 
        - ipDiffServCodePoint (key field) 
        - applicationId (key field) 
        - octetTotalCount (non key field) 
         
        For example, a Flow Record corresponding to the above 
        Template Record may contain: 
         
            { sourceIPv4Address=192.0.2.1,  
              destinationIPv4Address=192.0.2.2, 
              ipDiffServCodePoint=0,  
              applicationId='20..X..10000', 
              octetTotalCount=123456 } 
         
        The 10000 value is globally unique for enterprise X, so 
        that the Collector can determine which application is 
        represented by the Application Id by loading the registry 
        out of band. 
          
        Along with this Flow Record, a new Options Template Record 
        would be exported, as shown in Section 6.8.   
         
         

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 25] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

     6.7. Example: port Obfuscation 

        For example, an HTTP server might run on a TCP port 23 
        (assigned to telnet in [IANA-PORTS]). If the Metering 
        Process is capable of detecting HTTP in the same case, the 
        Application Id representation must contain HTTP. However, 
        if the reporting application wants to determine whether the 
        default HTTP port 80 or 8080 was used, the destination port 
        (destinationTransportPort at [IANA-IPFIX]) must also be 
        exported in the corresponding IPFIX record.    
         
        In the case of a standardized IANA layer 4 port, the 
        Classification Engine ID (PANA-L4) is 3, and the Selector 
        ID has the value of 80 for HTTP (see [IANA-PORTS]). 
        Therefore the Application Id is encoded as: 
         
            0                   1                   2                   
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
           |       3       |             80                | 
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
        The Exporting Process creates a Template Record with a few 
        Information Elements: amongst other things, the Application 
        Id. For example: 
         
        - sourceIPv4Address (key field) 
        - destinationIPv4Address (key field) 
        - protocol (key field) 
        - destinationTransportPort (key field) 
        - applicationId (key field) 
        - octetTotalCount (non key field) 
         
        For example, a Flow Record corresponding to the above 
        Template Record may contain: 
         
            { sourceIPv4Address=192.0.2.1,  
              destinationIPv4Address=192.0.2.2, 
              protocol=17,  
              destinationTransportPort=23, 
              applicationId='3..80',  
              octetTotalCount=123456 } 
                     
        The Collector has all the required information to determine 
        that the application is HTTP, but runs on port 23. 
      

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 26] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

     6.8. Example: Application Name Mapping Options Template 

        Along with the Flow Records shown in the above examples, a 
        new Options Template Record should be exported to express 
        the Application Name and Application Description associated 
        with each Application Id. 
         
        The Options Template Record contains the following 
        Information Elements: 
         
        1. Scope = applicationId. 
         
               From RFC 5101: "The scope, which is only available 
               in the Options Template Set, gives the context of 
               the reported Information Elements in the Data 
               Records." 
                
        2. applicationName. 
         
        3. applicationDescription. 
         
         
        The Options Data Record associated with the examples above 
        would contain, for example: 
         
            { scope=applicationId='2..90', 
              applicationName="foo", 
              applicationDescription="The foo protocol", 
         
              scope=applicationId='13..10000', 
              applicationName="webex", 
              applicationDescription="Webex application" } 
         
              scope=applicationId='20..X..10000', 
              applicationName="webex", 
              applicationDescription="Webex application" } 
         
         
        When combined with the example Flow Records above, these 
        Options Template Records tell the Collector: 
         
        1. A flow of 123456 bytes exists from sourceIPv4Address 
        192.0.2.1 to destinationIPv4address 192.0.2.2 with an 
        applicationId of '12..90', which maps to the "foo" 
        application. 
         

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 27] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        2. A flow of 123456 bytes exists from sourceIPv4Address 
        192.0.2.1 to destinationIPv4address 192.0.2.2 with an 
        Application Id of '13..10000', which maps to the "Webex" 
        application. 
         
        3. A flow of 123456 bytes exists from sourceIPv4Address 
        192.0.2.1 to destinationIPv4address 192.0.2.2 with an 
        Application Id of '20..PEN..10000', which maps to the 
        "Webex" application, according to the application registry 
        from the entrerprise X. 
         
         
     6.9. Example: Attributes Values Options Template Record 

        Along with the Flow Records shown in the above examples, a 
        new Options Template Record is exported to express the 
        values of the different attributes related to the 
        Application Ids. 
         
        The Options Template Record would contain the following 
        Information Elements: 
         
          1. Scope = applicationId. 
         
               From RFC 5101: "The scope, which is only available 
               in the Options Template Set, gives the context of 
               the reported Information Elements in the Data 
               Records." 
                
          2. applicationCategoryName. 
              
          3. applicationSubCategoryName. 
           
          4. applicationGroupName 
           
          5. p2pTechnology 
           
          6. tunnelTechnology 
                                   
          7. encryptedTechnology 
         
         
        The Options Data Record associated with the examples above 
        would contain, for example: 
         
            { scope=applicationId='2..90', 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 28] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

              applicationCategoryName="foo-category", 
              applicationSubCategoryName="foo-subcategory", 
              applicationGroupName="foo-group", 
              p2pTechnology=NO 
              tunnelTechnology=YES 
              encryptedTechnology=NO 
      
        When combined with the example Flow Records above, these 
        Options Template Records tell the Collector: 
         
        A flow of 123456 bytes exists from sourceIPv4Address 
        192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP 
        value of 0 and an applicationId of '12..90', which maps to 
        the "foo" application.  This application can be 
        characterized by the relevant attributes values.  
      

     7. IANA Considerations 

     7.1. New Information Elements 

      This document specifies 10 new IPFIX Information Elements: 
      the applicationDescription, applicationId, applicationName, 
      classificationEngineId, applicationCategoryName, 
      applicationSubCategoryName, applicationGroupName, 
      p2pTechnology, tunnelTechnology, and encryptedTechnology. 
       
      New Information Elements to be added to the IPFIX Information 
      Element registry at [IANA-IPFIX] are listed below. 
       
      EDITOR'S NOTE: RFC5102, which explains the IANA 
      considerations for assigning new Information Elements 
      mentions. "The value of these identifiers is in the range of 
      1-32767.  Within this range, Information Element identifier 
      values in the sub-range of 1-127 are compatible with field 
      types used by NetFlow version 9 [RFC3954].". This is the 
      reason why some Information Elements have already an assigned 
      ElementId in the range 1-127, instead of <TBD>. These 
      Information Elements should anyway follow the IANA 
      Considerations from RFC5102, i.e. " New assignments for IPFIX 
      Information Elements will be administered by IANA through 
      Expert Review review". The reviewer is Nevil Brownlee.  
      EDITOR'S NOTE: the XML specification in Appendix A must be 
      updated with the elementID values allocated below. 
       

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 29] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      RFC-EDITOR/IANA-EDITOR: some entries are already present in 
      IPFIX-IANA. However, those must be updated with the current 
      content.  
       
       
     7.1.1. applicationDescription  

      Name: applicationDescription  
      Description:  
        Specifies the description of an application. 
      Abstract Data Type: string 
      Data Type Semantics:  
      ElementId: 94 
      Status: current  
      
      
     7.1.2. applicationId 

      Name: applicationId  
      Description:  
        Specifies an Application Id. 
      Abstract Data Type: octetArray 
      Data Type Semantics: identifier 
      Reference: See section 4. of [EDITORS NOTE: this document] 
      for the applicationId Information Element Specification. 
      ElementId: 95 
      Status: current 
      
      
     7.1.3. applicationName 

      Name: applicationName  
      Description:  
        Specifies the name of an application. 
      Abstract Data Type: string  
      Data Type Semantics: 
      ElementId: 96 
      Status: current 
       
       
     7.1.4. classificationEngineId 

      Name: classificationEngineId 
      Description: 
       A unique identifier for the engine which determined the 
       Selector ID.  Thus the Classification Engine ID defines 
       the context for the Selector ID. The Classification 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 30] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

       Engine can be considered as a specific registry for 
       application assignments. 
        
       Initial values for this field are listed below. Further 
       values may be assigned by IANA in the Classification 
       Engine Ids registry. 
        
            0 Invalid. 
                
            1 IANA-L3: The Assigned Internet Protocol Number 
              (layer 3 (L3)) is exported in the Selector ID. See 
              http://www.iana.org/assignments/protocol-numbers. 
            
            2 PANA-L3: Proprietary layer 3 definition. An 
              enterprise can export its own layer 3 protocol 
              numbers. The Selector ID has a global significance 
              for all devices from the same enterprise. 
            
            3 IANA-L4: The IANA layer 4 (L4) well-known port 
              number is exported in the Selector ID. See [IANA-
              PORTS]. Note: as an IPFIX flow is unidirectional, 
              it contains the destination port in a flow from 
              the client to the server. 
            
            4 PANA-L4: Proprietary layer 4 definition. An 
              enterprise can export its own layer 4 port 
              numbers. The Selector ID has global significance 
              for devices from the same enterprise. Example: 
              IPFIX had the port 4739 pre-assigned in the IETF 
              draft for years. While waiting for the RFC and its 
              associated IANA registration, the Selector ID 4739 
              was used with this PANA-L4. 
            
            5 Reserved 
            
            6 USER-Defined: The Selector ID represents 
              applications defined by the user (using CLI, GUI, 
              etc.) based on the methods described in section 2.  
              The Selector ID has a local significance per 
              device. 
            
            7 Reserved 
            
            8 Reserved 
            
            9 Reserved 
            
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 31] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

           10 Reserved 
            
           11 Reserved 
            
           12 PANA-L2: Proprietary layer 2 (L2) definition.  An 
              enterprise can export its own layer 2 identifiers.  
              The Selector ID represents the enterprise's unique 
              global layer 2 applications. The Selector ID has a 
              global significance for all devices from the same 
              enterprise. Examples include Cisco Subnetwork 
              Access Protocol (SNAP). 
            
           13 PANA-L7: Proprietary layer 7 definition. The 
              Selector ID represents the enterprise's unique 
              global ID for the layer 7 applications. The 
              Selector ID has a global significance for all 
              devices from the same enterprise. This 
              Classification Engine Id is used when the 
              application registry is owned by the Exporter 
              manufacturer (referred to as the "enterprise" in 
              this document).  
            
           14 Reserved 
            
           15 Reserved 
            
           16 Reserved 
            
           17 Reserved 
            
           18 ETHERTYPE: The Selector ID represents the well-
              known Ethertype. See [ETHERTYPE]. Note that the 
              Ethertype is usually expressed in hexadecimal. 
              However, the corresponding decimal value is used 
              in this Selector ID. 
            
           19 LLC: The Selector ID represents the well-known 
              IEEE 802.2 Link Layer Control (LLC) Destination 
              Service Access Point (DSAP). See [LLC]. Note that 
              LLC DSAP is usually expressed in hexadecimal. 
              However, the corresponding decimal value is used 
              in this Selector ID. 
            
           20 PANA-L7-PEN: Proprietary layer 7 definition, 
              including a Private Enterprise Number (PEN) [PEN] 
              to identify that the application registry being 
              used is not owned by the Exporter manufacturer 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 32] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

              (referred to as the "enterprise" in this document, 
              and identified by the PEN), or to identify the 
              original enterprise in the case of a mediator or 
              3rd party device. The Selector ID represents the 
              enterprise unique global ID for the layer 7 
              applications. The Selector ID has a global 
              significance for all devices from the same 
              enterprise. 
            
           Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17), 
           are reserved to be compliant with existing 
           implementations already using the 
           classificationEngineId.  
            
      Abstract Data Type: unsigned8 
      Data Type Semantics: identifier 
      ElementId: 101 
      Status: current 
       
       
     7.1.5. applicationCategoryName 

      Name: applicationCategoryName 
      Description:  
       An attribute that provides a first level categorization for 
       each Application Id. 
      Abstract Data Type: string  
      Data Type Semantics: 
      ElementId: <to be assigned> 
      Status: current  
       
      
     7.1.6. applicationSubCategoryName 

      Name: applicationSubCategoryName 
      Description:  
       An attribute that provides a second level categorization 
       for each Application Id. 
      Abstract Data Type: string  
      Data Type Semantics: 
      ElementId: <to be assigned> 
      Status: current  
       
       
     7.1.7. applicationGroupName 

      Name: applicationGroupName  
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 33] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      Description:  
       An attribute that groups multiple Application Ids that 
       belong to the same networking application. 
      Abstract Data Type: string  
      Data Type Semantics: 
      ElementId: <to be assigned> 
      Status: current  
       
       
     7.1.8. p2pTechnology 

      Name: p2pTechnology  
      Description:  
       Specifies if the Application Id is based on peer-to-peer 
       technology. Possible values are: { "yes", "y", 1 },  
       { "no", "n", 2 } and { "unassigned" , "u", 0 }. 
      Abstract Data Type: string  
      Data Type Semantics: 
      ElementId: 288 
      Status: current 
       
       
     7.1.9. tunnelTechnology 

      Name: tunnelTechnology  
      Description:  
        Specifies if the Application Id is used as a tunnel 
      technology.    
        Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } 
      and  
        { "unassigned" , "u", 0 }. 
      Abstract Data Type: string 
      Data Type Semantics: 
      ElementId: 289 
      Status: current  
       
       
     7.1.10. encryptedTechnology 

      Name: encryptedTechnology 
      Description:  
       Specifies if the Application Id is an encrypted networking 
       protocol. Possible values are: { "yes", "y", 1 },  
       { "no", "n", 2 } and { "unassigned" , "u", 0 }. 
      Abstract Data Type: string 
      Data Type Semantics: 

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 34] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      ElementId: 290 
      Status: current 
      

     7.2. Classification Engine Ids Registry 

      The Information Element #101, named classificationEngineId, 
      carries information about the context for the Selector ID, 
      and can be considered as a specific registry for application 
      assignments. For ensuring extensibility of this information, 
      IANA has created a new registry for Classification Engine Ids 
      and filled it with the initial list from the description 
      Information Element #101, classificationEngineId. 
       
      New assignments for Classification Engine Ids will be 
      administered by IANA through Expert Review [RFC5226], i.e., 
      review by one of a group of experts designated by an IETF 
      Area Director.  The group of experts must double check the 
      new definitions with already defined Classification Engine 
      Ids for completeness, accuracy, and redundancy.  The 
      specification of Classification Engine Ids MUST be published 
      using a well-established and persistent publication medium. 
       
      RFC-EDITOR: this should be assigned similarly to 
      mplsTopLabelType subregistry at 
      http://www.iana.org/assignments/ipfix/ipfix.xml 
      
      
     8. Security Considerations 

      The same security considerations as for the IPFIX Protocol 
      [RFC5101] apply.  The IPFIX extension specified in this memo 
      allows to identify what applications are used on the network.  
      Consequently, it is possible to identify what applications 
      are being used by the users, potentially threatening the 
      privacy of those users, if not handled with great care.  
       
      As mentioned in Section 1.1. , the application knowledge is 
      useful in security based applications.  Security applications 
      may impose supplementary requirements on the export of 
      application information, and these need to be examined on a 
      case by case basis. 
       
      

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 35] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

     9. References 

     9.1. Normative References 

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997. 
      
        [RFC5101] Claise, B., Ed., "Specification of the IP Flow 
                Information Export (IPFIX) Protocol for the 
                Exchange of IP Traffic Flow Information", RFC 5101, 
                January 2008. 
      
        [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., 
                and J. Meyer, "Information Model for IP Flow 
                Information Export", RFC 5102, January 2008. 
         
        [RFC5226] Narten, T., and H. Alverstrand, "Guidelines for 
                Writing an IANA Considerations Section in RFCs", 
                RFC 5226, May 2008 
         
        [ETHERTYPE]  
                http://standards.ieee.org/develop/regauth/ethertype
                /eth.txt 
         
        [IANA-PORTS] http://www.iana.org/assignments/port-numbers 
         
        [IANA-PROTO] http://www.iana.org/assignments/protocol-
                numbers 
         
      
        [LLC] 
                http://standards.ieee.org/develop/regauth/llc/publi
                c.html. 
         
        [PEN]   http://www.iana.org/assignments/enterprise-numbers 
         
         
     9.2. Informative References 

         
        [RFC792] J. Postel, Internet Control Message Protocol, RFC 
                792, September 1981. 
          
        [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. 
                Zander, Requirements for IP Flow Information 
                Export, RFC 3917, October 2004. 
         
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 36] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        [RFC3954] B. Claise, "Cisco Systems NetFlow Services Export 
                Version 9", RFC 3954, October 2004. 
         
         
        [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 
                Export Using IP Flow Information Export (IPFIX)", 
                RFC 5103, January 2008. 
      
        [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 
                Quittek, "Architecture for IP Flow Information 
                Export", RFC 5470, March 2009. 
         
        [RFC5471] Schmoll, C., Aitken, P., and B. Claise, 
                "Guidelines for IP Flow Information Export (IPFIX) 
                Testing", RFC 5471, March 2009. 
         
         
        [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 
                Redundancy in IP Flow Information Export (IPFIX) 
                and Packet Sampling (PSAMP) Reports", RFC 5473, 
                March 2009. 
      
        [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) 
                Protocol Specifications", RFC 5476, March 2009. 
         
        [RFC5477] Dietz, T., Claise, B., Aitken, P., Dresslet F., 
                and G. Carle, "Information Model for Packet 
                Sampling Exports", RFC 5477, March 2009. 
         
         
        [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. 
                Ishibashi, "IP Flow Information Export (IPFIX) 
                Mediation: Framework", RFC6183, April 2011  
         
         
        [RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S. 
                Yates, "Export of Structured Data in IP Flow 
                Information Export (IPFIX)", RFC6313, July 2011  
         
        [LLDP] "IEEE Std 802.1AB-2005, Standard for Local and 
                metropolitan area networks - Station and Media 
                Access Control Connectivity Discovery", IEEE Std 
                802.1AB-2005 IEEE Std, 2005. 
         
        [IANA-IPFIX] 
                http://www.iana.org/assignments/ipfix/ipfix.xml 
      
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 37] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        [CISCO-APPLICATION-REGISTRY] 
                http://www.cisco.com/go/application_registry 
         

     10. Acknowledgement 

      The authors would like to thank their many colleagues across 
      Cisco Systems who made this work possible. Specifically 
      Patrick Wildi for his time and expertise. 
       
       

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 38] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

     11. Authors' Addresses 

       
      Benoit Claise 
      Cisco Systems, Inc. 
      De Kleetlaan 6a b1 
      Diegem 1813 
      Belgium 
          
      Phone: +32 2 704 5622 
      EMail: bclaise@cisco.com 
       
       
       
      Paul Aitken 
      Cisco Systems, Inc. 
      96 Commercial Quay 
      Commercial Street 
      Edinburgh, EH6 6LX, United Kingdom 
          
      Phone: +44 131 561 3616 
      EMail: paitken@cisco.com 
       
       
       
      Nir Ben-Dvora 
      Cisco Systems, Inc. 
      32 HaMelacha St.,  
      P.O.Box 8735, I.Z.Sapir  
      South Netanya, 42504  
      Israel 
       
      Phone: +972 9 892 7187 
      EMail: nirbd@cisco.com 
       
       
      Appendix A.  Additions to XML Specification of IPFIX 
      Information Elements (non normative) 

        This appendix A contains additions to the machine-readable 
        description of the IPFIX information model coded in XML in 
        Appendix A and Appendix B in [RFC5102].  Note that this 
        appendix is of informational nature, while the text in 
        Section 7. (generated from this appendix) is normative. 
         
        The following field definitions are appended to the IPFIX 
        information model in Appendix A of [RFC5102]. 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 39] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

      
          <field name="applicationDescription" 
                 dataType="string" 
                 group="application" 
                 elementId="94" applicability="all" 
        status="current"> 
            <description> 
              <paragraph> 
                 Specifies the description of an application. 
              </paragraph> 
            </description> 
          </field> 
         
          <field name="applicationId" 
                 dataType="octetArray" 
                 group="application" 
                 dataTypeSemantics="identifier" 
                 elementId="95" applicability="all" 
        status="current"> 
            <description> 
              <paragraph> 
                 Specifies an Application Id. 
              </paragraph> 
            </description> 
            <reference> 
              <paragraph> 
                 See section 4. of [EDITORS NOTE: this document] 
                for the applicationId Information Element 
                Specification. 
              </paragraph> 
            </reference> 
          </field> 
         
          <field name="applicationName" 
                 dataType="string" 
                 group="application" 
                 elementId="96" applicability="all" 
        status="current"> 
            <description> 
              <paragraph> 
                 Specifies the name of an application. 
              </paragraph> 
            </description> 
          </field> 
         
          <field name="classificationEngineId" 
                 dataType="unsigned8" 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 40] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                 group="application" 
                 dataTypeSemantics="identifier" 
                 elementId="101" applicability="all" 
        status="current"> 
            <description> 
              <paragraph>  
                0 Invalid. 
                     
                1 IANA-L3: The Assigned Internet Protocol Number 
                  (layer 3 (L3)) is exported in the Selector ID. 
                  See http://www.iana.org/assignments/protocol-
                  numbers. 
                 
                2 PANA-L3: Proprietary layer 3 definition. An 
                  enterprise can export its own layer 3 protocol 
                  numbers. The Selector ID has a global 
                  significance for all devices from the same 
                  enterprise. 
                 
                3 IANA-L4: The IANA layer 4 (L4) well-known port 
                  number is exported in the Selector ID. See 
                  [IANA-PORTS]. Note: as an IPFIX flow is 
                  unidirectional, it contains the destination 
                  port in a flow from the client to the server. 
                 
                4 PANA-L4: Proprietary layer 4 definition. An 
                  enterprise can export its own layer 4 port 
                  numbers. The Selector ID has global 
                  significance for devices from the same 
                  enterprise. Example: IPFIX had the port 4739 
                  pre-assigned in the IETF draft for years. 
                  While waiting for the RFC and its associated 
                  IANA registration, the Selector ID 4739 was 
                  used with this PANA-L4. 
                 
                5 Reserved 
                 
                6 USER-Defined: The Selector ID represents 
                  applications defined by the user (using CLI, 
                  GUI, etc.) based on the methods described in 
                  section 2.  The Selector ID has a local 
                  significance per device. 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 41] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                 
                7 Reserved 
                 
                8 Reserved 
                 
                9 Reserved 
                 
               10 Reserved 
                 
               11 Reserved 
                 
               12 PANA-L2: Proprietary layer 2 (L2) definition.  
                  An enterprise can export its own layer 2 
                  identifiers.  The Selector ID represents the 
                  enterprise's unique global layer 2 
                  applications. The Selector ID has a global 
                  significance for all devices from the same 
                  enterprise. Examples include Cisco Subnetwork 
                  Access Protocol (SNAP). 
                 
               13 PANA-L7: Proprietary layer 7 definition. The 
                  Selector ID represents the enterprise's unique 
                  global ID for the layer 7 applications. The 
                  Selector ID has a global significance for all 
                  devices from the same enterprise. This 
                  Classification Engine Id is used when the 
                  application registry is owned by the Exporter 
                  manufacturer (referred to as the "enterprise" 
                  in this document).  
                 
               14 Reserved 
                 
               15 Reserved 
                 
               16 Reserved 
                 
               17 Reserved 
                 
               18 ETHERTYPE: The Selector ID represents the 
                  well-known Ethertype. See [ETHERTYPE]. Note 
                  that the Ethertype is usually expressed in 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 42] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                  hexadecimal. However, the corresponding 
                  decimal value is used in this Selector ID. 
                 
               19 LLC: The Selector ID represents the well-known 
                  IEEE 802.2 Link Layer Control (LLC) 
                  Destination Service Access Point (DSAP). See 
                  [LLC]. Note that LLC DSAP is usually expressed 
                  in hexadecimal. However, the corresponding 
                  decimal value is used in this Selector ID. 
                 
               20 PANA-L7-PEN: Proprietary layer 7 definition, 
                  including a Private Enterprise Number (PEN) 
                  [PEN] to identify that the application 
                  registry being used is not owned by the 
                  Exporter manufacturer (referred to as the 
                  "enterprise" in this document, and identified 
                  by the PEN), or to identify the original 
                  enterprise in the case of a mediator or 3rd 
                  party device. The Selector ID represents the 
                  enterprise unique global ID for the layer 7 
                  applications. The Selector ID has a global 
                  significance for all devices from the same 
                  enterprise. 
              </paragraph> 
            </description> 
          </field> 
         
          <field name="applicationCategoryName" 
                 dataType="string" 
                 group="application" 
                 elementId="<to be assigned>" 
                 applicability="all" 
                 status="current"> 
            <description> 
              <paragraph> 
                 An attribute that provides a first level 
      categorization  
                 for each Application Id. 
              </paragraph> 
            </description> 
          </field> 
       
          <field name="applicationSubCategoryName" 

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 43] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                 dataType="string" 
                 group="application" 
                 elementId="<to be assigned>" 
                 applicability="all" 
                 status="current"> 
            <description> 
              <paragraph> 
                 An attribute that provides a second level   
                 categorization for each Application Id. 
              </paragraph> 
            </description> 
          </field> 
       
          <field name="applicationGroupName" 
                 dataType="string" 
                 group="application" 
                 elementId="<to be assigned>" 
                 applicability="all" 
                 status="current"> 
            <description> 
              <paragraph> 
                 An attribute that groups multiple Application Ids  
                 that belong to the same networking application. 
              </paragraph> 
            </description> 
          </field> 
       
          <field name="p2pTechnology" 
                 dataType="string" 
                 group="application" 
                 elementId="288" 
                 applicability="all" 
                 status="current"> 
            <description> 
              <paragraph> 
                 Specifies if the Application Id is based on peer- 
                 to-peer technology. Possible values are:  
                 { "yes", "y", 1 }, { "no", "n", 2 } and  
                 { "unassigned" , "u", 0 }. 
              </paragraph> 
            </description> 
          </field> 
       
          <field name="tunnelTechnology" 
                 dataType="string" 
                 group="application" 
                 elementId="289" 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 44] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                 applicability="all" 
                 status="current"> 
            <description> 
              <paragraph> 
                 Specifies if the Application Id is used as a  
                 tunnel technology. Possible values are:  
                 { "yes", "y", 1 }, { "no", "n", 2 } and  
                 { "unassigned" , "u", 0 }. 
              </paragraph> 
            </description> 
          </field> 
         
          <field name="encryptedTechnology" 
                 dataType="string" 
                 group="application" 
                 elementId="290" 
                 applicability="all" 
                 status="current"> 
            <description> 
              <paragraph> 
                 Specifies if the Application Id is an encrypted  
                 networking protocol. Possible values are:  
                 { "yes", "y", 1 }, { "no", "n", 2 } and  
                 { "unassigned" , "u", 0 }. 
              </paragraph> 
            </description> 
          </field> 
         
      
        Appendix B.  Port Collisions Tables (non normative) 
         
        The following table lists the 10 ports that have different 
        protocols assigned for TCP and UDP (at the time of writing 
        this document): 
         
         
            exec            512/tcp    remote process execution; 
                                       authentication performed  
                                       using passwords and UNIX  
                                       login names 
             
            comsat/biff     512/udp    used by mail system to  
                                       notify users of new mail  
                                       received; currently 
                                       receives messages only from  
                                       processes on the same  

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 45] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

                                       machine 
             
            login           513/tcp    remote login a la 
            telnet;                             automatic 
            authentication  
                                       performed based on  
                                       priviledged port numbers 
                                       and distributed data bases  
                                       which identify 
             
                                       "authentication domains" 
            who             513/udp    maintains data bases  
                                       showing who's logged in to  
                                       machines on a local  
                                       net and the load average of  
                                       the machine 
          
            shell           514/tcp    cmd 
                                       like exec, but automatic  
                                       authentication is performed 
                                       as for login server 
             
            syslog          514/udp 
             
            oob-ws-https    664/tcp    DMTF out-of-band secure web  
                                       services management  
                                       protocol 
                                       Jim Davis  
                                       
            <jim.davis&wbemsolutions.com> 
                                       June 2007 
             
            asf-secure-rmcp 664/udp    ASF Secure Remote  
                                       Management and Control  
                                       Protocol 
             
            rfile           750/tcp 
            kerberos-iv     750/udp    kerberos version iv 
             
            submit          773/tcp 
            notify          773/udp 
             
            rpasswd         774/tcp 
            acmaint_dbd     774/udp 
             
            entomb          775/tcp 
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 46] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

            acmaint_transd  775/udp 
             
            busboy          998/tcp 
            puparp          998/udp 
             
            garcon          999/tcp 
            applix          999/udp    Applix ac 
             
         
                Table 4: Different Protocols on UDP and TCP  
         
         
        The following table lists the 19 ports that have different 
        protocols assigned for TCP and SCTP (at the time of writing 
        this document): 
         
         
            #               3097/tcp    Reserved 
          
            itu-bicc-stc    3097/sctp   ITU-T Q.1902.1/Q.2150.3 
                                        Greg Sidebottom   
                                        <gregside&home.com> 
          
            #               5090/tcp    <not assigned> 
          
            car             5090/sctp   Candidate AR 
          
            #               5091/tcp    <not assigned> 
          
            cxtp            5091/sctp   Context Transfer Protocol 
                                        RFC 4065 - July 2005 
             
            #               6704/tcp    Reserved 
          
            frc-hp          6704/sctp   ForCES HP (High Priority)  
                                        channel [RFC5811] 

            #               6705/tcp    Reserved 
          
            frc-mp          6705/sctp   ForCES MP (Medium  
                                        Priority) channel  
                                        [RFC5811] 

            #               6706/tcp    Reserved 
          
      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 47] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

            frc-lp          6706/sctp   ForCES LP (Low priority)  
                                        channel [RFC5811] 
             
            #               9082/tcp    <not assigned> 
          
            lcs-ap          9082/sctp   LCS Application Protocol 
                                        Kimmo Kymalainen   
                                        kimmo.kymalainen&etsi.org> 
                                        04 June 2010 
          
            #               9902/tcp    <not assigned> 
          
            enrp-sctp-tls   9902/sctp   enrp/tls server channel 
                                     [RFC5353] 
          
            #               11997/tcp   <not assigned> 
            #               11998/tcp   <not assigned> 
            #               11999/tcp   <not assigned> 
          
            Wmereceiving    11997/sctp  WorldMailExpress 
            wmedistribution 11998/sctp  WorldMailExpress 
            wmereporting    11999/sctp  WorldMailExpress 
                                     Greg Foutz  
                                        <gregf&adminovation.com> 
                                        March 2006 
          
            #               25471/tcp   <not assigned> 
          
            rna             25471/sctp  RNSAP User Adaptation for  
                                        Iurh 
                                        Dario S. Tonesi 
                                        <dario.tonesi&nsn.com>   
                                        07 February 2011 
          
            #               29118/tcp   Reserved 
          
            sgsap           29118/sctp  SGsAP in 3GPP 
          
            #               29168/tcp   Reserved 
          
            sbcap           29168/sctp  SBcAP in 3GPP 
          
            #               29169/tcp   <not assigned> 
          

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 48] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

            iuhsctpassoc    29169/sctp  HNBAP and RUA Common  
                                        Association 
                                        John Meredith  
                                        <John.Meredith&etsi.org>   
                                        08 September 2009  
          
            #               36412/tcp   <not assigned> 
          
            s1-control      36412/sctp  S1-Control Plane (3GPP) 
                                        KimmoKymalainen   
                                        <kimmo.kymalainen&etsi.org> 
                                        01 September 2009 
          
            #               36422/tcp   <not assigned> 
          
            x2-control      36422/sctp  X2-Control Plane (3GPP) 
                                        Kimmo Kymalainen  
                                       <kimmo.kymalainen&etsi.org> 
                                        01 September 2009 
          
            #               36443/tcp   <not assigned> 
          
            m2ap            36443/sctp  M2 Application Part 
                                        Dario S. Tonesi  
                                        <dario.tonesi&nsn.com>   
                                        07 February 2011 
          
            #               36444/tcp   <not assigned> 
          
            m3ap            36444/sctp  M3 Application Part 
                                        Dario S. Tonesi  
                                        <dario.tonesi&nsn.com>   
                                        07 February 2011 
          
         
               Table 5: Different Protocols on SCTP and TCP 
      
      
        Appendix C.  Application Registry Example (non normative)   
         
        A reference to the Cisco Systems assigned numbers for the 
        Application Id and the different attribute assignments can 
        be found at [CISCO-APPLICATION-REGISTRY]. 
         

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 49] 
                                      

     Internet-Draft  <Export of App. Info. in IPFIX >  Aug 2012 
         

        RFC-EDITOR NOTE: at the time of publication, if [CISCO-
        APPLICATION-REGISTRY] is not available, this appendix, and 
        the [CISCO-APPLICATION-REGISTRY] reference must be removed. 
      

      
      
     <Claise, Aitken, Ben-Dvora>     Expires Feb 8 2013       [Page 50]