idnits 2.17.1 draft-ietf-6man-flow-update-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 80: '...ue set by the source MUST be delivered...' RFC 2119 keyword, line 82: '... b. "IPv6 nodes MUST NOT assume any m...' RFC 2119 keyword, line 84: '...uter performance SHOULD NOT be depende...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2011) is 4672 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-gont-6man-flowlabel-security-01 == Outdated reference: A later version (-07) exists of draft-ietf-6man-flow-3697bis-05 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN S. Amante 3 Internet-Draft Level 3 4 Intended status: Informational B. Carpenter 5 Expires: January 6, 2012 Univ. of Auckland 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 July 5, 2011 10 Rationale for update to the IPv6 flow label specification 11 draft-ietf-6man-flow-update-07 13 Abstract 15 Various published proposals for use of the IPv6 flow label are 16 incompatible with its original specification in RFC 3697. 17 Furthermore, very little practical use is made of the flow label, 18 partly due to some uncertainties about the correct interpretation of 19 the specification. This document discusses and motivates changes to 20 the specification in order to clarify it, and to introduce some 21 additional flexibility. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 6, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Impact of current specification . . . . . . . . . . . . . . . 3 59 3. Changes to specification . . . . . . . . . . . . . . . . . . . 6 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. Change log [RFC Editor: please remove] . . . . . . . . . . . . 10 65 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 66 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 The flow label field in the IPv6 header was reserved but left 72 experimental by [RFC2460], which mandates only that "Hosts or routers 73 that do not support the functions of the Flow Label field are 74 required to set the field to zero when originating a packet, pass the 75 field on unchanged when forwarding a packet, and ignore the field 76 when receiving a packet." 78 The flow label field was normatively specified by [RFC3697]. In 79 particular, we quote three rules from that RFC: 80 a. "The Flow Label value set by the source MUST be delivered 81 unchanged to the destination node(s)." 82 b. "IPv6 nodes MUST NOT assume any mathematical or other properties 83 of the Flow Label values assigned by source nodes." 84 c. "Router performance SHOULD NOT be dependent on the distribution 85 of the Flow Label values. Especially, the Flow Label bits alone 86 make poor material for a hash key." 88 Additionally, RFC 3697 leaves it undefined what method a host should 89 adopt by default to choose the value of the flow label, if no 90 specific method is in use. It was expected that various signaling 91 methods might be defined for agreeing on values of the flow label, 92 but no such methods have been standardised, except a pre-existing 93 option in RSVP [RFC2205]. 95 The flow label is hardly used in practice in widespread IPv6 96 implementations, although some operating systems do set it 97 [McGann05]. To some extent this is due to the main focus being on 98 basic deployment of IPv6, but the absence of a default method of 99 choosing the flow label value means that most host implementations 100 simply set it to zero. There is also anecdotal evidence that the 101 rules quoted above have led to uncertainty about exactly what is 102 possible. Furthermore, various use cases have been proposed that 103 infringe one or another of the rules. None of these proposals has 104 been accepted as a standard and in practice there is no significant 105 deployment of any mechanism to set the flow label. 107 The intention of this document is to explain this situation in more 108 detail and to motivate changes to RFC 3697 intended to remove the 109 uncertainties and encourage active usage of the flow label. It does 110 not formally update RFC 3697, but it serves as background material 111 for [I-D.ietf-6man-flow-3697bis]. 113 2. Impact of current specification 115 Rule (a) makes it impossible for the routing system to use the flow 116 label as any form of dynamic routing tag. This was a conscious 117 choice in the early design of IPv6 and there appears to be no 118 practical possibility of revisiting this choice at this stage in the 119 deployment of IPv6, which uses conventional routing mechanisms like 120 those used for IPv4. However, this rule also makes it impossible to 121 make any use at all of the flow label unless hosts choose to set it. 122 It also forbids clearing the flow label for security reasons. 124 This last point highlights the security properties, or rather the 125 lack of them, of the flow label. The flow label field is always 126 unprotected as it travels through the network, because there is no 127 IPv6 header checksum, and the flow label is not included in transport 128 pseudo-header checksums, nor in IPsec checksums. As a result, 129 intentional and malicious changes to its value cannot be detected. 130 Also, it could be used as a covert data channel, since apparently 131 pseudo-random flow label values could in fact consist of covert data 132 [NIST]. If the flow label were to carry quality of service 133 semantics, then like the diffserv code point [RFC2474], it would not 134 be intrinsically trustworthy across domain boundaries. As a result, 135 some security specialists believe that flow labels should be cleared 136 for safety [I-D.gont-6man-flowlabel-security], [NSA]. These points 137 must be considered when discussing the immutability of the flow label 138 across domain boundaries. In fact, the adjective "immutable" is 139 confusing, since it implies a property that the flow label field does 140 not actually possess. It has therefore been abandoned as a 141 descriptive term in [I-D.ietf-6man-flow-3697bis]. It is only used in 142 the present document to explain why it has been abandoned. 144 Rule (b) appears to forbid any usage in which the bits of the flow 145 label are encoded with a specific semantic meaning. However, the 146 words "MUST NOT assume" are to be interpreted precisely - if a router 147 knows by configuration or by signaling that the flow label has been 148 assigned in a certain way, it can make use of that knowledge. It is 149 not made clear by the rule that there is an implied distinction 150 between stateless models (in which case no assumption may be made) 151 and stateful models (in which the router has explicit knowledge). 153 If the word "alone" is overlooked, rule (c) has sometimes been 154 interpreted to forbid the use of the flow label as part of a hash 155 used by load distribution mechanisms. In this case too, the word 156 "alone" needs to be taken into account - a router is allowed to 157 combine the flow label value with other data in order to produce a 158 uniformly distributed hash. 160 Both before and after these rules were laid down, a considerable 161 number of proposals for use of the flow label were published that 162 seem incompatible with them. Numerous examples and an analysis are 163 presented in [I-D.hu-flow-label-cases]. Those examples propose use 164 cases in which some or all of the following apply: 165 o The flow label may be changed by intermediate systems. 166 o It doesn't matter if the flow label is changed, because the 167 receiver doesn't use it. 168 o Some or all bits of the flow label are encoded: they have specific 169 meanings understood by routers and switches along the path. 170 o The encoding is related to the required quality of service, as 171 well as identifying a flow. 172 o The flow label is used to control forwarding or switching in some 173 way. 175 These proposals all require either some form of encoding of semantics 176 in the bits of the flow label, or the ability for routers to modify 177 the flow label, or both. Thus they appear to infringe the rules from 178 RFC 3697 quoted above. 180 We can conclude that a considerable number of researchers and 181 designers have been stymied by RFC 3697. On the other hand, some 182 other proposals discussed in [I-D.hu-flow-label-cases] appear to be 183 compatible with RFC 3697. Several are based on the originator of a 184 packet choosing a pseudo-random flow label for each flow, which is 185 one option suggested in RFC 3697. Thus, we can also conclude that 186 there is a useful role for this approach. 188 If our goal is for the flow label to be used in practice, the 189 conflict between the various approaches creates a dilemma. There 190 appear to be two major options: 191 1. Discourage locally defined and/or stateful use of the flow label. 192 Strengthen RFC 3697 to say that hosts should set a label value, 193 without necessarily creating state, which would clarify and limit 194 its possible uses. In particular, its use for load distribution 195 and balancing would be encouraged. 196 2. Relax the rules to encourage locally defined and/or stateful use 197 of the flow label. This approach would make the flow label 198 completely mutable and would exclude use cases depending on 199 strict end-to-end immutability. It would encourage applications 200 of a pseudo-random flow label, such as load distribution, on a 201 local basis, but it would exclude end-to-end applications. 203 During 2010/2011 there was considerable debate about these options 204 and variants of them, with a variety of proposals in previous 205 versions of this document and in mailing list discussions. After 206 these discussions, there appears to be a view that simplicity should 207 prevail, and that complicated proposals such as defining quality of 208 service semantics in the flow label, or sub-dividing the flow label 209 field into smaller sub-fields, will not prove efficient or 210 deployable, especially in high speed routers. There is also a 211 clearly expressed view that using the flow label for various forms of 212 stateless load distribution is the best simple application for it. 213 At the same time, it is necessary to recognize that the strict 214 immutability rule has drawbacks as noted above. 216 Even under the rules of RFC 3697, the flow label is intrinsically 217 untrustworthy, because modifications en route cannot be detected. 218 For this reason, even with the current strict immutability rule, 219 downstream nodes cannot rely mathematically on the value being 220 unchanged. In this sense, any use of the flow label must be viewed 221 as an optimisation on a best effort basis; a packet with a changed 222 (or zero) flow label value should never cause a hard failure. 224 The remainder of this document discusses specific modifications to 225 the standard, which are defined normatively in a companion document 226 [I-D.ietf-6man-flow-3697bis]. 228 3. Changes to specification 230 Although RFC 3697 requires the flow label to be delivered unchanged, 231 as noted above, it is not included in any transport layer pseudo- 232 header checksums nor in IPsec authentication [RFC4302]. Both RFC 233 2460 and RFC 3697 define the default flow label to be zero. At the 234 time of writing, this is the observed value in an overwhelming 235 proportion of IPv6 packets; the most widespread operating systems and 236 applications do not set it, and routers do not rely on it. Thus 237 there is no reason to expect operational difficulties if a careful 238 change is made to the rules of RFC 3697. 240 In particular, the facts that the label is not checksummed and rarely 241 used mean that the "immutability" of the label can be moderated 242 without serious operational consequences. 244 The purposes of the proposed changes are to remove the uncertainties 245 left by RFC 3697, in order to encourage setting of the flow label by 246 default, and to enable its generic use. The proposed generic use is 247 to encourage uniformly distributed flow labels that can be used to 248 assist load distribution or balancing. There should be no impact on 249 existing IETF specifications other than RFC 3697 and no impact on 250 currently operational software and hardware. 252 A secondary purpose is to allow changes to the flow label in a 253 limited way, to allow hosts that do not set the flow label to benefit 254 from it nevertheless. The fact that the flow label may in practice 255 be changed en route is also reflected in the reformulation of the 256 rules. 258 A general description of the changes follows. The normative text is 259 to be found in [I-D.ietf-6man-flow-3697bis]. 261 The definition of a flow is subtly changed from RFC 3697 to allow any 262 node, not just the source node, to set the flow label value. 263 However, it is recommended that sources should set a uniformly 264 distributed flow label value in all flows, replacing the less precise 265 recommendation made in Section 3 of RFC 3697. Both stateful and 266 stateless methods of assigning a uniformly distributed value could be 267 used. 269 Flow label values should be chosen such that their bits exhibit a 270 high degree of variability, thus making them suitable for use as part 271 of the input to a hash function used in a load distribution scheme. 272 At the same time, third parties should be unlikely to be able to 273 guess the next value that a source of flow labels will choose. 275 In statistics, a discrete uniform distribution is defined as a 276 probability distribution in which each value in a given range of 277 equally spaced values (such as a sequence of integers) is equally 278 likely to be chosen as the next value. The values in such a 279 distribution exhibit both variability and unguessability. Thus, an 280 approximation to a discrete uniform distribution is preferable as the 281 source of flow label values. In contrast, an implementation in which 282 flow labels are assigned sequentially is definitely not recommended, 283 to avoid guessability. 285 In practice it is expected that a uniform distribution of flow label 286 values will be approximated by use of a hash function or a pseudo- 287 random number generator. Either approach will produce values which 288 will appear pseudo-random to an external observer. 290 Section 3 of RFC 3697 allows nodes to participate in an unspecified 291 stateful method of flow state establishment. The changes do not 292 remove that option, but it is made clear that stateless models are 293 also possible and are the recommended default. The specific text 294 about requirements for stateful models has been reduced to a bare 295 minimum requirement that they do not interfere with the stateless 296 model. To enable stateless load distribution at any point in the 297 Internet, a node using a stateful model should never send packets 298 whose flow label values do not conform to a uniform distribution. 300 The main novelty is that a forwarding node (typically a first-hop or 301 ingress router) may set the flow label value if the source has not 302 done so, according to the same recommendations that apply to the 303 source. This might place a considerable processing load on ingress 304 routers that choose to do so, even if they adopted a stateless method 305 of flow identification and label assignment. 307 The value of the flow label, once it has been set, must not be 308 changed. However, some qualifications are placed on this rule, to 309 allow for the fact that the flow label is an unprotected field and 310 might be misused. No Internet-wide mechanism can depend 311 mathematically on immutable flow labels. The new rules require that 312 flow labels exported to the Internet should always be either zero or 313 uniformly distributed, but even this cannot be relied on 314 mathematically. Use cases need to be robust against non-conforming 315 flow label values. This will also enhance compatibility with any 316 legacy hosts that set the flow label according to RFC 2460 or RFC 317 3697. 319 A complication that led to much discussion is the possibility that 320 hosts inside a particular network domain might use a stateful method 321 of setting the flow label, and that packets bearing stateful labels 322 might then erroneously escape the domain and be received by nodes 323 performing stateless processing such as load balancing. This might 324 result in undesirable operational implications (e.g., congestion, 325 reordering) for not only the inappropriately flow-labelled packets, 326 but also well-behaved flow-labelled packets, during forwarding at 327 various intermediate devices. It was proposed to suggest that border 328 routers might "correct" this problem by overwriting such labels in 329 packets leaving the domain. However, neither domain border egress 330 routers nor intermediate routers/devices (using a flow label, for 331 example, as a part of an input key for a load-distribution hash) can 332 determine by inspection that a value is not part of a uniform 333 distribution. Thus there is no way that such values can be detected 334 and "corrected". Therefore, the recommendation to choose flow labels 335 from a uniform distribution also applies to stateful schemes. 337 4. Discussion 339 The following are some practical consequences of the above changes: 340 o Sending hosts that are not updated will in practice continue to 341 send all-zero labels. If there is no label-setting router along 342 the path taken by a packet, the label will be delivered as zero. 343 o Sending hosts conforming to the new specification will by default 344 choose uniformly distributed labels between 1 and 0xFFFFF. 345 o Sending hosts may continue to send all-zero labels, in which case 346 an ingress router may set uniformly distributed labels between 1 347 and 0xFFFFF. 348 o The flow label is no longer unrealistically asserted to be 349 strictly immutable; it is recognised that it may, incorrectly, be 350 changed en route. In some circumstances this will break end-to- 351 end usage, e.g. potential detection of third-party spoofing 352 attacks [I-D.gont-6man-flowlabel-security]. 354 o The expected default usage of the flow label is some form of 355 stateless load distribution, such as the ECMP/LAG usage defined in 356 [I-D.carpenter-flow-ecmp]. 357 o If the new rules are followed, all IPv6 traffic flows on the 358 Internet should have zero or uniformly distributed flow label 359 values. 361 From an operational viewpoint, existing IPv6 hosts that set a default 362 (zero) flow label value and ignore the flow label on receipt will be 363 unaffected by implementations of the new specification. In general, 364 it is assumed that hosts will ignore the value of the flow label on 365 receipt; it cannot be relied on as an end-to-end signal. However, 366 this doesn't apply if a cryptographically generated label is being 367 used to detect attackers [I-D.gont-6man-flowlabel-security]. 369 Similarly, routers that ignore the flow label will be unaffected by 370 implementations of the specification. 372 Hosts that set a default (zero) flow label but are in a domain where 373 routers set a label as recommended in Section 3 will benefit from 374 whatever flow label handling is used on the path. 376 Hosts and routers that adopt the recommended mechanism will enhance 377 the performance of any load balancing devices that include the flow 378 label in the hash used to select a particular path or server, even 379 when packets leave the local domain. 381 5. Security Considerations 383 See [I-D.ietf-6man-flow-3697bis] and 384 [I-D.gont-6man-flowlabel-security] for full discussion. Some useful 385 remarks are in [Partridge]. 387 6. IANA Considerations 389 This document requests no action by IANA. 391 7. Acknowledgements 393 The authors are grateful to Qinwen Hu for general discussion about 394 the flow label and for his work in searching the literature. 395 Valuable comments and contributions were made by Ran Atkinson, Fred 396 Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian 397 Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka 398 Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other 399 participants in the 6man working group. 401 This document was produced using the xml2rfc tool [RFC2629]. 403 8. Change log [RFC Editor: please remove] 405 draft-ietf-6man-flow-update-07: minor editorial fix, AD comments, 406 2011-07-05 408 draft-ietf-6man-flow-update-06: updated again to be in step with RFC 409 3697bis, 2011-05-11 411 draft-ietf-6man-flow-update-05: updated again to be in step with RFC 412 3697bis, 2011-05-02 414 draft-ietf-6man-flow-update-04: updated again to be in step with RFC 415 3697bis, 2011-03-13 417 draft-ietf-6man-flow-update-03: updated to be in step with RFC 418 3697bis, 2011-02-26 420 draft-ietf-6man-flow-update-02: repurposed as rationale for update of 421 RFC 3697, 2011-01-31 423 draft-ietf-6man-flow-update-01: clarified that this is not a formal 424 update of RFC 3697, clarified text about domains exporting 425 inappropriate labels, 2011-01-10 427 draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79, 428 mutability rules adjusted according to WG discussion, 2010-12-03 430 draft-carpenter-6man-flow-update-04: even more simplified according 431 to WG discussion, 2010-09-16 433 draft-carpenter-6man-flow-update-03: futher simplified according to 434 WG discussion, 2010-05-07 436 draft-carpenter-6man-flow-update-02: revised and simplified according 437 to WG discussion, 2010-04-13 439 draft-carpenter-6man-flow-update-01: revised according to mail list 440 discussion, 2010-03-05 442 draft-carpenter-6man-flow-update-00: original version, 2010-02-18 444 9. Informative References 446 [I-D.carpenter-flow-ecmp] 447 Carpenter, B. and S. Amante, "Using the IPv6 flow label 448 for equal cost multipath routing and link aggregation in 449 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 450 October 2010. 452 [I-D.gont-6man-flowlabel-security] 453 Gont, F., "Security Assessment of the IPv6 Flow Label", 454 draft-gont-6man-flowlabel-security-01 (work in progress), 455 November 2010. 457 [I-D.hu-flow-label-cases] 458 Hu, Q. and B. Carpenter, "Survey of proposed use cases for 459 the IPv6 flow label", draft-hu-flow-label-cases-03 (work 460 in progress), February 2011. 462 [I-D.ietf-6man-flow-3697bis] 463 Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 464 "IPv6 Flow Label Specification", 465 draft-ietf-6man-flow-3697bis-05 (work in progress), 466 June 2011. 468 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 469 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 470 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 471 (work in progress), March 2007. 473 [McGann05] 474 McGann, O. and D. Malone, "Flow Label Filtering 475 Feasibility", European Conference on Computer Network 476 Defence , 2005. 478 [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, 479 "Guidelines for the Secure Deployment of IPv6", National 480 Institute of Standards and Technology Special Publication 481 800-119, 2010, . 484 [NSA] Potyraj, C., "Firewall Design Considerations for IPv6", 485 National Security Agency I733-041R-2007, 2007, 486 . 488 [Partridge] 489 Partridge, C., Arsenault, A., and S. Kent, "Information 490 Assurance and the Transition to IP Version 6 (IPv6)", 491 Military Communications Conference (MILCOM 2007) , 2007, 492 . 495 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 496 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 497 Functional Specification", RFC 2205, September 1997. 499 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 500 (IPv6) Specification", RFC 2460, December 1998. 502 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 503 "Definition of the Differentiated Services Field (DS 504 Field) in the IPv4 and IPv6 Headers", RFC 2474, 505 December 1998. 507 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 508 June 1999. 510 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 511 "IPv6 Flow Label Specification", RFC 3697, March 2004. 513 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 514 December 2005. 516 Appendix A. Alternative Approaches 518 A model was discussed in an earlier version of this document which 519 defined a notion of 'flow label domain' analogous to a differentiated 520 services domain [RFC2474]. This model would have encouraged local 521 usage of the flow label as an alternative to any form of generic use, 522 but it required complex rules for the behaviour of domain boundary 523 routers, and proved controversial in discussion. 525 Two even more complex alternative approaches were also considered and 526 rejected. 528 The first was to distinguish locally significant flow labels from 529 those conforming to RFC 3697 by setting or clearing the most 530 significant bit (MSB) of the flow label. This led to quite 531 complicated rules, seems impossible to make fully self-consistent, 532 and was not considered practical. 534 The second was to use a specific differentiated services code point 535 (DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the 536 flow label itself, to flag a locally defined behaviour. A more 537 elaborate version of this was proposed in 538 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. There are two 539 issues with this approach. One is that DSCP values are themselves 540 only locally significant, inconsistent with the end-to-end nature of 541 the original flow label definition. Secondly, it seems unwise to 542 meld the semantics of differentiated services, which are currently 543 deployed, with the unknown future semantics of flow label usage. 544 However, this approach, while not recommended, does not appear to 545 violate any basic principles if applied strictly within a single 546 differentiated services domain. 548 Authors' Addresses 550 Shane Amante 551 Level 3 Communications, LLC 552 1025 Eldorado Blvd 553 Broomfield, CO 80021 554 USA 556 Email: shane@level3.net 558 Brian Carpenter 559 Department of Computer Science 560 University of Auckland 561 PB 92019 562 Auckland, 1142 563 New Zealand 565 Email: brian.e.carpenter@gmail.com 567 Sheng Jiang 568 Huawei Technologies Co., Ltd 569 Huawei Building, No.3 Xinxi Rd., 570 Shang-Di Information Industry Base, Hai-Dian District, Beijing 571 P.R. China 573 Email: shengjiang@huawei.com