idnits 2.17.1 draft-baker-flow-label-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Fred Baker 3 Internet Draft Cisco Systems 4 Expiration Date: April 1997 Yakov Rekhter 5 Cisco Systems 7 Use of Flow Label for Tag Switching 9 draft-baker-flow-label-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 2. Abstract 31 An overview of a tag switching architecture is provided in [tag- 32 arch]. This document proposes to extend the syntax and semantics of 33 the Flow Label field in the IPv6 header to facilitate IPv6 forwarding 34 by allowing the Flow Label field to carry tag information. 36 3. Description 38 A tag switching architecture is described in [tag-arch]. This 39 document proposes to use the Flow Label field in the IPv6 header 40 [RFC1883] as a mechanism for tag switching with IPv6. With this 41 proposal the Flow Label field is used to carry the tag information 42 (tag). 44 This document doesn't constrain the forwarding granularity associated 45 with a tag that could be carried in the Flow Label field. For 46 example, it is expected that a tag could be associated either with a 47 group of routes (group of address prefixes), or with a multicast tree 48 (either shared or source-based), or with an individual flow. 50 A router determines whether the Flow Label field carries a tag by 51 examining the high-order bit of the Flow Label field. If the most 52 significant bit is zero and the lower order 23 bits are not, it is 53 presumed to be a flow label (as defined in [RFC1883]). If the high- 54 order bit is 1, it is assumed to be a tag. 56 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 57 |Version| Prio. |G| Flow Label | 58 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 Prio. 4-bit priority value. 62 G G=0 indicates global end-to-end flow label definition, 63 G=1 indicates hop-by-hop flow label definition (tag). 65 Flow Label 23-bit flow label. 67 A router could place a tag into the Flow Label field of a packet only 68 if the Flow Label field is all zeros (this restriction doesn't apply 69 to the case where a router just replaces one tag with another). 71 If a router is not capable of using a tag, and the router receives an 72 IPv6 packet that carries a tag, the router forwards the packet 73 following the normal IPv6 procedures. 75 4. Differences with the current definition of Flow Labels 77 With this proposal the Flow Label field could be modified at every 78 hop. This is in contrast with the current definition of Flow Label 79 [RFC1883], where the value of this field is set up by the source of a 80 packet, and is not modified by the routers that forward the packet. 81 Moreover, the semantics of tag is different from the semantics of the 82 Flow Label, as packets carrying the same tag may come from more than 83 one source. 85 We propose to reserve the value of the high-order bit of the Flow 86 Label field to 1 (binary) to identify the cases where the field 87 carries a tag. 89 Use of the Flow Label field to carry a tag would require changes to 90 the Authentication Header as used by IPv6, as it currently requires 91 inclusion of the Flow Label field in the data certified by the 92 digest. 94 5. Security Considerations 96 Security issues are not discussed in this document. 98 6. Acknowledgements 100 To be supplied. 102 7. References 104 [RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6 105 (IPv6) Specification", RFC1883, December 1995 107 [tag-arch] Rekhter, Y., Davie, B., Katz, D., Rosen, E., Swallow, G., 108 "Tag Switching Architecture", draft-rfced-info-rekhter-00.txt, 109 8. Author Information 111 Fred Baker 112 cisco Systems, Inc. 113 170 Tasman Dr. 114 San Jose, CA 95134 115 Phone: (408) 526-4257 116 email: fred@cisco.com 118 Yakov Rekhter 119 cisco Systems, Inc. 120 170 Tasman Dr. 121 San Jose, CA 95134 122 Phone: (914) 528-0090 123 email: yakov@cisco.com