concerning the diffserv field (traffic class) itself, as outlined in   [DSCP-Def], {Diffserv], and [Differv-Tun].   When IPv6 packets are encrypted using ESP Transport or Tunnel Mode   [IPSec-ESP], the port and protocol numbers are hidden, but the flow   label is not. Thus MF classification remains possible even for   encrypted traffic.9. IANA Considerations   The IPv6 flow label format specified in this document, is based on   the Differentiated Services Per Hop Behavior Identification Code (PHB   ID), specified in [PHB ID]. The PHB ID can be a IANA assigned number.   [PHD ID] contains a "IANA Considerations Section", following   guidelines stated in [CONS]. No additional IANA considerations have   to be made.10.Acknowledgments   Some of the ideas in this draft were discussed with Thomas Eklund,   and Walter Weiss. Jochen Metzler reviewed the specification and   provided good feedback. The continued scrutiny of Steve Deering   helped refining the document.11.References   [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6   Specification", RFC 2460, December 1998.   [Intserv] R. Braden, D. Clark, S. Shenker, "Integrated Services inConta & Carpenter         Expires in six months    [Page 21]INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001   the Internet Architecture: an Overview", RFC 1633, June 1994.   [Diffserv] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.   Weiss, "An Architecture for Differentiated Service", RFC 2475,   December 1998.   [DSCP-Def] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of   the Differentiated Services Field (DS Field) in the IPv4 and IPv6   Headers", RFC 2474, December 1998.   [PHB-ID] D. Black, S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop   Behavior Identification Codes", RFC 3140, June 2001.   [Diffserv-Tun] D. Black, "Differentiated Services and Tunnels", RFC   2983, October 2000.   [Diffserv-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,   A. Smith, "Differentiated Services Policy Information Base", Work in   Progress.   [DiffServ-MIB]  F. Baker, K. Chan, A. Smith "Management Information   Base for the Differentiated Services Architecture", Work in Progress.   [Diffserv-Model] Y. Bernet, S. Blake, A. Smith, D. Grossman, "An   Informal Management Model for Diffserv Routers", Work in Progress.   [Diffserv-Flow-Label] A. Conta, B. Carpenter, "A Definition of a IPv6   Flow Label Classifier", Work in Progress.   [RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin.   "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional   Specification", RFC 2205, September 1997.   [MPLS-Arch] Rosen, E., Viswanathan, A., and Callon, R.,   "Multiprotocol Label Switching Architecture",  RFC 3031, January   2001.Conta & Carpenter         Expires in six months    [Page 22]INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001   [MPLS-LDP] L. Anderson, P. Doolan, N. Feldman,  A.  Fredette,  R.   Thomas, "Label Distribution Protocol", RFC 3036, January 2001.   [RSVP-TE]  D. O. Awduche, L. Berger, D. Gan. Tony Li, Vijay   Srinivasan, George Swallow, "RSVP-TE: Extensions to RSVP for LSP   Tunnels", Work in progress.   [IPSec-ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Protocol   (ESP)", RFC 2406, November 1998.   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate   Requirement Levels", BCP 14, RFC 2119, March 1997.   [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA   Considerations Section in RFCs", RFC 2434, October 1998.   [Assign] Postel, J., etc.. "Assigned Numbers", STD 2, RFC 1700,   October 1994.12.Authors' Addresses   Alex Conta   Transwitch Corporation   3 Enterprise Drive   Shelton, CT 06484   USA   Email: aconta@txc.com   Brian Carpenter   IBM   c/o iCAIR   Suite 150   1890 Maple Avenue   Evanston, IL 60201   USA   Email: brian@hursley.ibm.comConta & Carpenter         Expires in six months    [Page 23]INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001Appendix A: Other Possible IPv6 Flow Label Formats   This section enumerates several ideas, each with its positive and   negative aspects.   A possible solution to the issues discussed in section 5.7 is to   compress or encode the host-to-host header information, and the   host-to-host protocol type in the flow label value. This is an   algorithmic mapping of the port numbers and protocol into the flow   label. There are several ways in which this could be achieved, but   only two are suggested in this section.   Another format mentioned further down in this section is one in which   the length of the IPv6 headers helps locating in one step the host-   to-host header for accessing the port information.A.1  Server Port Format - Short Format     A possible solution to the issues discussed in section 5.7 is to     compress or encode the host-to-host header information, and the     host-to-host protocol type in the flow label value. This is an     algorithmic mapping of the port numbers and protocol into the flow     label. There are several ways in which this could be achieved, but     only three are suggested in this section:     The Server Port Format is a format which is based on carrying in     the flow label the server port number of a client/server     application/communication.      0                   1      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |  Server Port Number  | H-to-H protocol|     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   The "Server Port Number" is the port number assigned to the server   side of the client/server application. This provides an   identification of the application, and the type of application, which   is a quite good indication of the type of QoS characteristics needed   for the traffic generated or accepted by that application. Obviously   it does not provide the finer granularity within the use of one   application on the same end-nodes, that the use of both source and   destination ports provide. That is, it cannot differentiate among   multiple instances of the same application running on the same two   communicating end-nodes. But for Differentiated services purposes, it   does not seem to really matter, since it is expected that the several   instances of an application running on the same two end-nodes, wouldConta & Carpenter         Expires in six months    [Page 24]INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001   generate or accept traffic which is of same category, class, or   behavior.   The reduced number of bits (12 bits out of 16) limits the value to   "IANA Well-known ports", that is ports from 1 to 1023, and a subset   of "IANA registered ports" that is, from 1024 to 4095. Registered   ports have values between 1024 and 65535 [Assign].   The "H-to-H protocol" is the host-to-host protocol identifier   [Assign], that is, TCP, UDP, etc....   Advantage   The advantage of this flow label format is that the classification   rule is the typical 5 or 6 tuple format of a Diffserv M-F Classifier   [Diffserv-Model], containing the source, and destination addresses,   the source and destination ports (in which one of the two is   wildcard), the host to host protocol, and the DSCP field. So no new   classification rule format is needed, and further, it is possible to   aggregate parts of the IPv4, and IPv6 classification rules. Note that   for classifying traffic in both directions, two classification rules   must be configured. For instance a classification rule for TCP flows   on port 80, between node A, and node B:   Source Address:A   Destination Address:B   Source Port:*   Destination Port:80   Host-to-Host Protocol   6 (TCP)   would be used for all traffic outgoing, from any port, to port 80.   Source Address:A   Destination Address:B   Source Port:80   Destination Port:*   Host-to-Host Protocol   6 (TCP)   would be used for all traffic outgoing from port 80, to any port.A.2  Server Port Format - Long Format   Observation:  Since TCP, and UDP are the two major host-to-host   protocols that carry port numbers in their protocol headers, the   field occupied by the "host-to-host" protocol could be reduced to 1   bit, indicating TCP or UDP, as it follows:    .spConta & Carpenter         Expires in six months    [Page 25]INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001      0                   1      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |  TCP Server Port Number       | Res |0|     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      0                   1      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |  UDP Server Port Number       | Res |1|     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   The "Res" bits are reserved.   The "TCP Server Port Number" or "UDP Server Port Number is the 16 bit   port number assigned to the server side of the client/server   application.A.3  Header Length Format   Another possible solution to the issues discussed in section 5.7 is   to store the IPv6 headers length, that is the length of the IPv6 main   headers and IPv6 extensions headers preceding the host-to-host, or   transport header. The length of the IPv6 headers in the flow label   value would provide the information which a Diffserv QOS engine   classifier could use to locate and fetch the source and destination   ports, and apply those, along with the source and destination address   and the host-to-host protocol from the flow label, to match the   source and destination address, the source and destination ports and   the protocol identifier elements of a Diffserv M-F classifier   [Diffserv-Model].      0                   1      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |Length of IPv6 Headers |H-to-H protocol|     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   The "Length of the IPv6 Headers" allows also skipping the IPv6   headers to access directly the host-by-host header for other   purposes.   Additionally, this format is useful for classifying packets that are   not TCP or UDP, and have no source and destination ports.   With this 12 bit encoding the maximum length of the IPv6 headers thatConta & Carpenter         Expires in six months    [Page 26]INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001   could be represented is 4Kbytes. However, the restriction on headers   length can be significantly reduced. IPv6 headers are 8byte aligned,   therefore the length could be represented as the number of 8byte   chunks occupied by the headers, in which case the maximum length   would be 32Kbytes.   If all of the above formats would be used, then there are two ways to   separate this last type of encoding from the other two mentioned   above:   (i) always use a signaling mechanism to distribute the flow label   values, and so the type of the format would be stored as part of the   flow state.   (ii) use a bit field to discriminate the formats. For instance, a two   bit field could be used to indicate the first, second, or third type   of format.   Note:   The suggestions described in this section are in fact an exploration   of possible solutions. Each suggestion has advantages and   disadvantages. They are kept in this section at least for recording   purposes.Conta & Carpenter         Expires in six months    [Page 27]1593