idnits 2.17.1 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03.txt: -(43): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(44): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(46): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(91): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(92): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(119): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(124): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(129): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(164): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(167): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(171): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(181): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(184): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(186): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(200): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(201): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(204): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(205): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(256): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(268): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(307): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(355): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(380): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(491): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(492): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(516): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(527): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(535): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(540): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(554): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(570): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(598): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(600): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(604): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(608): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(609): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 629. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching', is 51 characters long, but may be at most 50 characters == There are 54 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 194 instances of too long lines in the document, the longest one being 410 characters in excess of 72. ** There are 404 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.1 boilerplate, a section with a similar start was also found: By submitting this Internet-Draft, each author represents that any applicable Patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- The document date (22 February 2007) is 6273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '7' on line 118 == Unused Reference: 'RFC 2460' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC 3697' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC 3595' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC 3168' is defined on line 612, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Beckman 2 Internet Draft: 03 U.S. Department of Defense 3 Category: Standards Track 22 February 2007 5 IPv6 Dynamic Flow Label Switching (FLS) 6 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet-Drafts as reference material or to cite 22 them other than as "work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on February 22, 2007. 31 Copyright Notice 33 Copyright (C) The IETF Trust (2007). 35 Abstract 37 This document seeks to establish a standard for the utilization of the 38 Class of Service Field and the us of the Flow Label Field within the IPv6 39 Header and establish a methodology of switching packets through routers 40 using the first 32-bits of the IPv6 header using Flow Label Switching on 41 packets rather than full routing of packets. Within the first 32-bits 42 of an IPv6 header exists the requisite information to allow for the 43 immediate �switching� on an ingress packet of a router, allowing for 44 �Label Switching� of a native IPv6 packet. This allows the establishment 45 of VPN circuits in a dynamic manner across transit networks. The 46 establishment of �Flows� based upon the 20-bit �Flow Label� value can be 47 done dynamically with minimal effort and configuration of the end-point 48 routers of the flow. The flows can be managed or open, encrypted or in the 49 clear, and will allow for greater scalability, security, and agility in 50 the management and operation of networks. 52 Comments are solicited and should be addressed to martin.beckman@disa.mil 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The Flow Label Switching Traffic Class . . . . . . . . . . . . . . 3 58 4. Flow Label Switching Setup and Management . . . . . . . . . . . . . 4 59 5. Managed Flow Label Switching . . . . . . . . . . . . . . . . . . . 5 60 6. Encrypted Flow Label Switching . . . . . . . . . . . . . . . . . . 6 61 7. Flow Sets and Queuing . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Contextual Uses of Flow Label Switching . . . . . . . . . . . . . . 9 63 9. Intellectual Property Statement . . . . . . . . . . . . . . . . . . 10 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction and Abstract 70 To traverse the Internet or any large enterprise network, each router hop 71 represents a decision point about the life cycle of each datagram. A major 72 latency inducing function is the look-up of the destination of the packet 73 in the routing table of each router along the way. This is for simplistic 74 routing. If there are additional considerations, such as queuing or 75 filtering, the process can become more laborious. Additionally, two or 76 more networks requiring secure communications require the establishment of 77 a VPN tunnel to assure security of the traffic as it traverses the 78 backbone or in most cases,a carriers internetworking autonomous system. In 79 all cases, the entire IPv6 header of 320 bits must be read, cached, and 80 processed at each router along the path etween the networks. What is 81 proposed is a methodology of determining the destination port for a packet 82 at is enters a router within the first 32-bits of information. This can be 83 done using a hierarchical methodology of applying values to the Traffic 84 Class Field (8-bits) and switching the packet based upon he value of the 85 Flow Label Field (20-bits) based upon a flow label switching table within 86 the router. The only requirement is that all routers along the paths 87 available can read the Traffic Class Field and are capable of Flow Label 88 Switching. 90 The Flow Switch Path is dynamically established by the two end-point 91 routers with simple recognition of the flow by the intervening �Next-Hop- 92 Routers� along the paths between the two End Point Routers. The flows are 93 capable of being controlled either manually or through a �Flow Label 94 Server� within an autonomous system. This is essential for the secure 95 functioning of a network or conflicting Flow Labels will result. Finally, 96 the Flow establishment and operation is encrypt-able, allowing for secure 97 establishment and operation between the two end point routers of the flow. 99 Succinctly put, packets can be switched based upon Flow Label Value 100 allowing for a myriad of possibilities in both topologies and secure 101 network operations across carriers across the globe. The end result is a 102 limiting of the need for VPN servers, IPv6 tunnels, and greater mobility 103 of entire networks within an enterprise if proper planning and 104 considerations are understood. Since the packet remains "IPv6 native" the 105 ability to monitor and secure traffic becomes less problematic compared to 106 label switching" within the MPLS context. Instead of converting and non- 107 native IPv6 packet in MPLS form for read and analysis, the packet is 108 handled as any other packet on the network. This is critical when networks 109 use IP/IPv6 packet encryption since an MPLS packet is neither IP or IPv6 110 and cannot be handled by the encryption device with removing the MPLS shim 111 and thereby wrecking the overall end-to-end secure transmission process. 113 2. Definitions and Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [7]. 119 Flow Initiating Router (FIR) � The FIR is the router that initiates a flow 120 label switch path. The FIR sets the Traffic Class Field and Flow Label 121 Values to the required value to set the flow up across the routing fabric 122 between the two end points. 124 Flow Destination Router (FDR) � The FDR is the router the FIR seeks to 125 establish a flow with. The FDR resets the Traffic Class Field and Flow 126 Label Values to the required value to send the packet to its final 127 destination based upon the path determined by the local routing table. 129 Next-Hop-Router (NHR) � The NHR established and maintains the Flow Switch 130 Path using a Flow Switch Table that is maintained based upon instructions 131 from the FIR and its own local routing table. 133 Switched Flow Path (SFP) is the switched path taken by packet across a 134 Routed fabric based upon the value of the Flow Label and, if used, flow 135 set. 137 Flow Set (FS) a group of flows through a router identified by the FS value 138 in the Traffic Class. 140 Flow Path Server (FPS) is a physical or virtual host on the network the 141 FIR, FDR, and NHRs use to validate Flow Path setup requests. 143 3. The Flow Label Switching Traffic Class. 145 The first requirement is to establish a flow path across a routed fabric 146 based upon a traffic class value within the defined parameters of RFC 147 2474. RFC 2474 currently defines three pools for traffic class use within 148 IPv6: 150 Pool Codepoint space Assignment Policy 151 ---- --------------- ----------------- 152 1 xxxxx0 Standards Action 153 2 xxxx11 EXP/LU 154 3 xxxx01 EXP/LU (*) 156 The codepoint space uses the first six bits of the 8 bits in the traffic 157 class field. Flow Label Switching uses the "top half" of the Traffic Class 158 field by setting the first bit to "1". Pool "128" would use codepoint 159 space of 1abcxxyy, where a,b, and c have values as list below. When "c" is 160 set to "0" and DF codepoint space is in use within a routed domain, "xx" 161 are direct mappings of pools 1, 2, and 3 into the traffic class field. The 162 values for "yy" are reserved. 164 The second requirement is to identify a packet as being �flow switched� 165 versus routed. To accomplish this, the Traffic Class Field is used. 167 In any event the packet is either �routed� of �flow switched�. Therefore, 168 the differentiation is set in the first bit of the Traffic Class Field, 169 which is set to 1 for flow switched. This leaves the lower half values of 170 the Traffic class (0-127) available of use in routing. The remaining 171 values of the Traffic class Field of a �Flow Switched� packet are as 172 follows: 174 | version | Traffic Class | Flow Label | 175 | 1 2 3 4 | 1 2 3 4 5 6 7 8 | 20 bits | 176 | 0 1 1 0 | 1 a b c d e f g | 1 - 1,048,574 | 178 Value �a� � 0 = Open / 1 = Managed 179 Value �b� � 0 = Clear / 1 = Encrypted 180 Value �c� � 0 = Data Traffic / 1 = Flow Management Message 181 Values �d� through �f� are dependant upon the value of �c�. 182 Note: When "c" is set to "0" and RFC 2474 is in use, pools 1, 2, or 3 183 are manipulated per RFC 2474 and RFC 3168; therefore, the FIR and 184 FDR map �d� through �g� directly into the Traffic Class field. 186 Pool 128 has a �codepoint� value of" 1dddxx with an assignment policy of 187 Flow Label Switching where "d" is the defined value per this document and 188 "x" is the value defined in RFC 2474. Pool 128 has a range of 128 to 255. 189 When the fourth bit (c) is set to "0" the packet is user traffic moving 190 across the flow. The balance of 4 bits is used for priority, 191 differentiating between inter-AS or intra AS Flows, or a combination of 192 both when RFC 2474 Differentiated Service (DS) and RFC 3168, Explicit 193 Congestion Notification (ECN) is not in use. This allows for 16 194 priorities, sixteen different set of flows, or a combination of differing 195 flow sets with internal priority queues. 197 When it is a combination of both, priority is set first, and the flow set 198 is set second. As an example, two flow sets (�blue� and �red�) are set in 199 field �g� with blue or red being a value of �0� and the other a value of �1�. 200 Each flow set then has 3 bits for setting priority using �d � f�. As a 201 cautionary note; by not following RFC 2474 and RFC 3168, �Explicit Congestion 202 Notification� cannot be used. 204 When �c� = 1, the packet is a �Flow Management Packet� between the two end 205 point routers (the FIR and FDR) as well as for the intervening NHR�s along 206 the flow path. The follow are the Values of �d� though �g� in this 207 circumstance and are covered in the mechanics of setting of a Flow Switch 208 Path: 210 | d e f g | Decimal | Purpose 211 | 0 0 0 0 | 0 |Set up an Asymmetric Flow 212 | 0 0 0 1 | 1 |Set up a Symmetric Flow 213 | 0 0 1 0 | 2 |NHR Acknowledgment 214 | 0 0 1 1 | 3 |NHR Failed 215 | 0 1 0 0 | 4 |Restart Flow 216 | 0 1 0 1 | 5 |Keep Alive from FIR 217 | 0 1 1 0 | 6 |Keep Alive from FDR 218 | 0 1 1 1 | 7 |Flow Tear Down 219 | 1 n n 0 | 8-14 |FPS Management 220 | 1 1 1 1 | 15 |Reserved 222 4. Flow Label Switching Setup and Management 224 Across a routed fabric, a switched flow is initiated by a Flow Initiation 225 Router (FIR). To accomplish this, the router has a virtual interface 226 established with a routable 128-bit Unicast address. The Flow Destination 227 Router has the same setup with a different routable 128-bit Unicast 228 address. The initiating packet from the FIR to the FDR is as follows: 230 |version| Traffic Class | Flow Label | 231 |1 2 3 4| 1 2 3 4 5 6 7 8 | 20 bits | 232 |0 1 1 0| 1 0 0 1 0 0 0 0 | 0-FE | 233 ____________________________________________ 234 |Payload Length | Next Hdr 59| Hop Limit | 235 ____________________________________________ 236 | | 237 | FIR 128-bit Address | 238 | | 239 ____________________________________________ 240 | | 241 | FDR 128-bit Address | 242 | | 243 ____________________________________________ 244 | Next Header 59 and Padding | 245 This establishes a simple, asymmetric Flow Path. The FIR send the packet 246 via the destination port of the FDR based upon the route listed in the 247 routing table. 249 The FIR then sets the flow label value with the end-points into a flow 250 switch table and marks the label as the router being an end-point for the 251 flow. The Next Hop Router (NHR) receives the packet and established an 252 entry in the flow switch table based upon the routing table as port to the 253 FIR and FDR associated with the flow label. Since this flow in asymmetric, 254 the ports used by the flow path could be dissimilar is the best paths per 255 the routing table have an asymmetric pattern. This is possible for Flows 256 over ASN�s where BGP parameters may make ingress and egress to another AS 257 asymmetric. For Symmetric flows, bit 5 is set to one, and the NHR simply 258 duplicates the Flow Switch Table Entry reversing the ingress/egress ports 259 for the flow label association. Once the flow switch table is updated by 260 the NHR, the packet is sent to the next NHR on the routed path, each 261 updating its own Flow Switch Table. The NHR then sends an acknowledgement 262 to the sending router with a TC field of: 264 1 n n 1 0 0 1 0, where �n� is the value of the TC filed received. 266 This is of importance later when flows are setup as managed, with or 267 without encryption. The receiving this acknowledgement then marks the Flow 268 Switch Table entries as active. This process through the NHR�s continues 269 until the packet is received by the FDR. Since the destination address is 270 local to the router, the FDR then sets the flow label value with the end- 271 points into a flow switch table and marks the label as the router being an 272 end-point for the flow. The FDR then sends a �keep-alive� to the FIR with 273 a TC value of 1 n n 1 0 1 1 0 via the flow path established. 275 The FIR will send a keep-alive with a TC value of 1 n n 1 0 1 0 1. Both 276 the FIR and FDR will send their respective keep-alive packets over the 277 flow path on a varying interval of 1-180 seconds. If the end point routers 278 do not receive a keep-alive from their respective end-point, the FIR 279 and/or FDR will send a �restart� message using a TC Value of: 280 1 n n 1 0 1 0 0. 282 This initiates the Flow over the NHR path. The purpose of the restart 283 message is to force the NHRs on the path to revalidate the Flow Switch 284 table entry for that particular flow. During the startup phase of the 285 flow. If there is a duplicate flow label entry in an NHR along the path 286 (Example: The Network Administrator attempts to use the same flow label 287 values for two different sets of end points, that NHR sends back a NHR 288 Fail message with a TC value of 1 n n 1 0 0 1 1. Any Reviving NHR then 289 drops that entry from the flow switch table and forwards the messages back 290 to the FIR. The FIR then logs to console and drops the flow setup. The 291 Flow Switch Table entries for Next Hop Routers (NHRs) remains valid for 1 292 to 30 minutes if there are no packets matching the entry. The purpose for 293 this control is to purge unused flow paths from the routed path 294 automatically; however, care should be taken to ensure the FIR/FDR Keep- 295 Alive messages transpire within the purge time set. 297 5. Managed Flow Label Switching 299 In the proceeding section, the flows are openly established from one FIR 300 to and FDR with automatic processing by the intervening NHRs along the 301 routed path. While convenient and possibly applicable within a large 302 enterprise network, the management of possibly over 1 million flows will 303 become problematic. Further, while Flow Label Switching is generally for 304 routers, flows could conceivably be established between hosts on the 305 network for a variety of purposes such as server-to-server updating and 306 archiving, true peer-to-peer networking where latency of service is 307 problematic; however, the openness of �open� flow label switching allows 308 for greater risks to the routed infrastructure. To mitigate these risks 309 and allow for more centralized management, the second bit of the TC filed 310 can be set to one making the establishment of Flow Switch Paths centrally 311 controlled. 312 As a methodology, Managed Flow Switching is simple. The second bit of the 313 TC field is set to 1. Caching the packet, the receiving router then and 314 requests a validation of the Flow Path from a flow path server (FPS) on 315 the network. Multiple Flow Path Servers (FPS) are required for redundancy. 316 The recommended methodology would to imbed the server as an internal 317 service on a set of routers within the infrastructure with a common 128- 318 bit Anycast address for the server. 320 The transaction for setup should be simplistic and allow for secure means 321 of authentication between the routers and the FPS devices on the network. 322 The conceptual transaction methodology is as follows: 324 - A Flow Path Server is established on the network with a predetermined 325 Anycast Address available to only the routers or specified devices on 326 the network. 328 - Each router in the fabric has the Anycast address loaded in the 329 configuration to request a Flow Path Lookup. Additionally, each router 330 should be configurable to globally deny non-managed Flow Path Switching 331 request, yet have the option of permitting individual 333 - A Flow Path is loaded into the server with the Flow Label, Flow Set, 334 Priority, FIR Unicast Address, and the FDR Unicast Address. 336 - The Flow Label with Flow Set, Priority, and FDR Address are setup in 337 the FIR. 339 - The FIR requests validation of the Flow Path from the FPS. 341 - Once the FPS validates the Flow requested by the FIR and responds with 342 an acknowledgement, the NHR sends the set packet to the next NHR on 343 the Flow Path per the routing table. 345 - Caching the packet, the first NHR then and requests a validation of the 346 Flow Path from a flow path server (FPS) on the network. When the Flow is 347 validated, the request is forwarded to the next NHR on the path per the 348 local route table. Each NHR responds with an acknowledgement to the 349 requesting router as in the unmanaged flow operation. 351 - The process repeats through the chain of NHRs until the request is 352 received by the FDR. Caching the packet, the FDR then and requests a 353 validation of the Flow Path from a flow path server (FPS) on the 354 network. 355 Once acknowledged, the FDR has acknowledgement, it sends a �Keep-Alive 356 to the FIR as in the unmanaged flow. 358 Once the Flow Switching Path is established, the FPS is no longer used. 359 The validity on the Flow Switch Path continues to be maintained via keep- 360 alive packets between the endpoint routers and timers on the NHRs along 361 the path. 363 Inter-FPS updating for multiple FPS on a routed fabric is essential when 364 using Anycasting. Each FPS will belong to a hierarchy of servers, with one 365 being designated as the root server in a fashion similar to DNS; however, 366 the exchange need to take place via TCP in a point-to-point fashion. If a 367 flow is configured into a secondary server, the root server is notified. 368 In the event of a root server failure, the next server will assume the 369 role as root server. The recommended approach is to prioritize based upon 370 lowest MAC address or unicast end-station address or the servers. 371 Since updates are not immediate, A Flow Path Validation request will query 372 the closest FPS per Anycasting methodologies. If the Flow is not found, 373 the FPS queries the root server for an update. If not found the validation 374 fails, yet if the root FPS has the entry, is sends a validation to the 375 secondary server. The secondary server then updates its Flow Path 376 Database. 377 The root FPS will send an initial full database update to the secondary 378 FPS and will only send adds and drop on a periodic basis after that. If a 379 new secondary FPS is placed into the service, the root server must be 380 manually configured with the address on the secondary server�s unicast 381 address. The root FPS will then send the full database to the secondary 382 FPS. A secondary FPS will not request and update. This precludes a rouge 383 FPS from hijacking the FPS database. 385 The FPS database will identify the following: 386 - Current Root FPS by Unicast Address 387 - All Secondary FPS by Unicast Address 388 - All Flow Path Entries including FIR by Unicast Address, FDR by 389 Unicast Address, Flow Label Value, Flow Set Value (If used), 390 Flow Priority (If Used), Encryption TC bit setting, Flow Symmetry 391 Value, Time Last Keep-Alive received from FIR, keep alive interval. 393 The root FPS sends a Keep-Alive Query to the FIR and FDR for each flow. 394 The FIR and FDR each respond to their respective Anycast FPS. If an FPS 395 has not received an Acknowledgement from the End-Points within three 396 attempts, the FPS updates is local database and sends a Flow Failure 397 message to the root FPS. The root server takes three actions: Updates the 398 local database by suspending the Flow Path Information, Sends an FPS 399 Database Update to each secondary FPS, Sends a Flow Halt Message to the 400 End-points, The FIR in turn issues a Flow Tear Down Packet to the NHRs to 401 clear the entry from the FIR, FDR, and NHR local Flow Switch Table. The 402 ollowing is a summary of the second half of the TC field binary settings 403 sed with the �11n1 set� first half of the TC. 405 Table Summary of the second half of the TC field binary settings 406 used with the �11n1 set� first half of the TC. 408 | d e f g | Decimal | Purpose 409 | 1 0 0 0 | 8 |End Point Keep-Alive Query to FIR/FDR 410 | 1 0 0 1 | 9 |End Point Keep-Alive Acknowledgement from FIR/FDR 411 | 1 0 1 0 | 10 |Flow Halt, Issue Flow Teardown Message 412 | 1 0 1 1 | 11 |FPS Full Database Update (from root FPS to secondary FPS) 413 | 1 1 0 0 | 12 |FPS Full Database Ack (from secondary FPS to root FPS) 414 | 1 1 0 1 | 13 |FPS Database Update (from root FPS to secondary FPS) 415 | 1 1 1 0 | 14 |FPS Database Ack (from secondary FPS to root FPS) 416 | 1 1 1 1 | 15 |Flow Failure from secondary FPS to root FPS 418 6. Encrypted Flow Label Switching 420 The envisioned use of Flow Label Switching is to allow communities of 421 interest connected to a common infrastructure to connect internally to 422 each other without the overhead associated with tunneling or VPN 423 arrangements; however, the Flows need to be secure from monitoring in some 424 cases, as the packets traverse a common backbone or carrier level 425 Autonomous System. This section deals with purpose and use of the third 426 (3rd) bit of the TC Field for encrypting the Flows between Endpoints via 427 either locally agreeable encryption between the endpoint routers (or hosts 428 of the Flows are between Servers, or via a PPKI infrastructure setup. 430 To encrypt a Flow Path, the FIR sets the third bit of the TC field to a 431 value of one (1). There are two possible methodologies: In the Clear Setup 432 and Management with Encrypted Traffic or Complete Encryption. There are 433 also two levels of Encryption: First 32-bit in the clear and the Entire 434 IPv6 Header in the Clear. In all cases, this is not to be confused with 435 IPv6 security and authentication headers! That is a separate function 436 performed by the end station hosts traversing the network and is 437 functionally performed after the actual IPv6 header is read. In this 438 context, only the first 32-bits of the header are being read to determine 439 a switching decision. 441 6.a. Encryption Methodologies 443 In the Clear Setup and Management with Traffic Encryption, while less 444 scure, has logically less overhead for the intervening NHRs along the Flow 445 Switch Path. 446 In this case, all Flow Setup and management is (fourth bit of the TC filed 447 is set to one) done as previously described, except that the third bit of 448 the TC field is set to one. Once the Flow Switch path is established 449 between the two endpoints, the FIR and FDR exchange keys or perform 450 another authentication and encryption algorithm. The FIR and FDR then 451 encrypt all Traffic traversing the Flow Switch Path at either a high level 452 or a low level. Simplistically, the transmitter encrypts and the receiver 453 decrypts. 455 Complete Encryption is far more extensive in that all participating 456 routers and, in the case of Managed Flow Label Switching, the Flow Path 457 Servers (FPS)Encrypt all traffic, after the first 32-bits of the header. 458 In this case the unicast addresses of the end-points of the Flow Switch 459 Path are hidden from view by traffic monitoring. Problematic to this is 460 having all of the routers (as well as possibly hosts) and participating 461 FPS devices encrypting and decrypting all Flow Label Management Packets. 462 This will increase processor overhead as well as add to the complexity 463 of what is meant to be a simplistic, yet dynamic switching protocol; 464 however, the actual traffic traversing the flow switch path only 465 encrypted and decrypted by the end-point routers of the Flow Switch 466 Path. 468 6.b. Encryption Levels 470 In this context, the level of encryption corresponds depth within the 471 packet that the encryption takes place and the type of encryption (IE: 472 Strong or Weak). The Encryption Algorithm determines the strength, the 473 level determines how much of the header and packet is encrypted. The 474 level is determined as part of the exchange between the end-point 475 routers on the Flow Switch Path. 477 The difference between High level and Low level is that High level 478 encryption scrambles all information after the Hop-Limit Field in the 479 IPv6 packet, making the destination and source addresses as well as the 480 type and content of the datagram unreadable as it passes through the NHR 481 fabric. Low level Encryption scrambles all data after the source and 482 destination address. This allows the destination and source addresses as 483 well as the next header field to be monitored as the packet traverses 484 the NHRs on the Flow Switch path. 486 7. Flow Sets and Queuing 488 Once a Flow Switching path is established, the end-points of the flow will 489 have a TC value of: 1 m n 0 a b c d, where m = managed/open, n = 490 encrypted/clear, and the fourth bit is set to 1. The remaining four bits 491 (0-F) can be parsed for two uses: �Flow Set Identification� or �Flow 492 Priority.� This feature is to allow equal flow values to be shared on a 493 set of NHRs by differentiating them through a Flow Setvalue similar to 494 concept of an ATM Virtual Path Identifier differentiating equal value for 495 Virtual Circuit Identifiers (VCIs). Alternatively, the 16-bits can be used 496 to prioritize which flow has priority on the routers switching based upon 497 Flow Value. Conceivably, a Next Hop Router in a large Transit Network with 498 multiple flows may receive Flow Switched packets on several ports over a 499 brief interval of time. This allows the switching function of the router 500 to queue the traffic based upon the value set in the 16 bits as the 501 priority level. In this case, each flow has 16 priority levels of traffic, 502 allowing a differentiation of latency sensitive traffic versus generic 503 best effort traffic. Finally, the combination of the two methodologies. 504 Flow Sets can be determine in the first one to three bits leaving the 505 remainder for Priority queuing of traffic. Alternatively, the first 1 to 3 506 bits can determine priority allowing for equal priority flow sets to be 507 established. 509 8. Contextual Uses and Security Considerations of Flow Label Switching 511 There exist two functional advantages for Flow Label Switching versus 512 continuing with MPLS. 514 First, it affords an alternative to MPLS by establishing VPN circuits between 515 to remote routers. This alternative, unlike MPLS, is dynamic and sets up 516 �flows� across a routed fabric without having to reconfigure the intervening 517 routers. Second, it allows for faster determination of a packets destiny as 518 it ingresses into a router without resorting to mutating the IPv6 packet by 519 adding a shim. Rather than read the entire 320-bit packet header and 520 executing a closest match route lookup, only the first 32 bits are read and 521 the packet is switched to an egress port, sending the packet on its way with 522 90% less effort in what to read to determine what to do. 524 Both these facets allow for some interesting capabilities for aggregation of 525 geographically separate locations behind a single DMZ structure. Since each 526 end-point sends and receives packets based upon Flow Label Value, forming an 527 adjacency is formed between the two �virtual Flow Label Interfaces, allowing 528 the flow to act similar to a tunnel across a Wide Area Network. Router A sees 529 Router B directly through their respective Flow Interfaces, allowing either A 530 or B to act as the overall gateway for the other network. 532 This can extremely effective for large organizations such as the Government 533 or Corporations who have internal organizations that each operate on 534 differing security policies. In this context, each internal organization can 535 be �wrapped� into a single security domain with a simplifying restructuring 536 of the DMZ. This mitigates the need for VPN servers in numerous cases, and 537 due to the dynamic setup nature of both Clear and Managed Flow Switching 538 Paths, the mobility of entire networks can be readily achieved. 540 Unlike MPLS, Flow Label Switching operates within the IPv6 protocol�s defined 541 header specification. More succinctly put, the IPv6 packet may have the 542 values of the Traffic Class and Flow Label fields manipulated, but it stills 543 remains a native IPv6 packet, unlike MPLS which as a 32-bit shim. This is 544 critical for government use when the data flow must traverse the newer 545 generation of �High Assurance IP Encryptor� (HAIPE) devices used within US 546 Department of Defense and elsewhere in the US Government. As stated in the 547 name of the device; it is an IP Encryptor and not an MPLS Encryptor! MPLS 548 poses difficult problems for this family of encryption devices currently 549 being deployed as a replacement for link layer encryption devices. 551 Returning to the concept of non-encapsulated tunneling, FLS paths are 552 established using the routing tables of the routers along the path. This 553 allows for a far more rapid fielding of flows across a routed infrastructure 554 when compared to the implementation of MPLS. Since the �flow� is established 555 between two virtual interfaces (similar to tunnel interfaces) the virtual 556 interfaces establish link local address connectivity at layer 3 (via the 557 FEC0::/16) routing between these two virtual interfaces is as easily achieved 558 as it is using standard tunneling. As a practical matter, the implementation 559 of this protocol within a routing OS should be as a subset of tunneling 560 protocols, where the tunnel interface number may be equal to the flow label 561 value. The ramifications of this enhancement go directly to the 562 simplification of network operations for service providers and the reduction 563 of costs for connectivity between geographically diverse locations within an 564 enterprise. The following are two uses for this capacity: 566 Military/Government: Within the Defense Community, the major services (Army, 567 Nay, Air Force, and Marine Corps) as well as the Joint Unified Commands and 568 the various Defense Agencies are widely dispersed throughout the globe. Each 569 of these various entities maintain unclassified interconnectivity via the DoD 570 ISP �NIPRNet�. Since each one of these entities maintains their own security 571 policies, each entity insists that their external traffic all originate from 572 behind a consolidated DMZ structure. FLS simplifies this critical issue by 573 providing secured flows between the sites to a specific DMZ. Additionally, 574 each flow may be encrypted to where only the first 64 bits of the header are 575 in the clear. This permits the destination and source addresses within the 576 flow as well as the data to be hidden while the packet is switched through a 577 common routed infrastructure to somewhere else within the enterprise�s 578 security domain. Finally, the military moves and deploys routinely. FLS 579 permits for additional flows to be established on the fly for those deploying 580 units permitting simplified and continuous connectivity to all domains 581 required. This has considerable tactical, operational, and strategic value! 583 Commercial/Corporate: As an example, a large manufacturing corporation 584 has numerous production facilities throughout the globe and providing secure 585 and monitored access becomes both costly and problematic. Each site need only 586 achieve IPv6 network access with FLS provided as a service. Each site then 587 can be folded logically and virtually behind a single DMZ and have secure 588 capability between sites. The sites no longer need numerous circuits 589 enmeshing them with each other for a substantial reduction in recurring 590 operational costs. 592 9. References 594 [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 595 (IPv6) Specification", RFC 2460, December 1998. 597 [RFC 3697] J. Rajahalme, Nokia; A. Conta, Transwitch; B. Carpenter, IBM 598 S. Deering, Cisco; �IPv6 Flow Label Specification�, RFC 3697, March 2004. 600 [RFC 3595] B. Wijnen, Lucent Technologies;��Textual Conventions for IPv6 Flow 601 Label�, RFC 3595, September 2003. 603 [RFC 3168] K. Ramakrishnan, TeraOptic Networks; S. Floyd, ACIRI; D. Black, EMC 604 �The Addition of Explicit Congestion Notification (ECN) to IP�, RFC 3168 605 September 2001. 607 [RFC 2774 K. Nichols, Cisco Systems; S. Blake, Torrent Networking Technologies; 608 F. Baker, Cisco Systems; D. Black, EMC Corporation, �Definition of the 609 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers�, 610 December 1998. 612 [RFC 3168] K. Ramakrishnan, TeraOptic Networks; S. Floyd, ACIRI; D. Black, EMC; 613 �The Addition of Explicit Congestion Notification (ECN) to IP�, 614 September 2001. 616 10. Acknowledgments 618 My thanks to Brian Carpenter (brc@zurich.ibm.com) for redirecting my efforts to 619 ensure that inclusion of DS Field definition per RFC 2474 was properly addressed 620 and patiently reviewing the details. 622 11. Intellectual Property Statement 624 Copyright (C) The IETF Trust (2007). 626 This document is subject to the rights, licenses and restrictions contained in 627 BCP 78, and except as set forth therein, the authors retain all their rights. 629 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 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. 632 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." 633 Individual Property Rights 635 By submitting this Internet-Draft, each author represents that any applicable 636 Patent or other IPR claims of which he or she is aware have been or will be 637 disclosed, and any of which he or she becomes aware will be disclosed, in 638 accordance with Section 6 of BCP 79. 640 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. 642 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." 644 12. Author's Address 646 Martin Beckman 647 Defense Information Systems Agency 648 5275 Leesburg Pike, 7 Skyline Place 649 Falls Church, VA 22041 650 United States of America 652 Phone: 703-861-6865 // 703-882-0225 653 EMail: martin.beckman@disa.mil