< draft-eastlake-6man-hide-options-01.txt   draft-eastlake-6man-hide-options-02.txt >
INTERNET-DRAFT D. Eastlake INTERNET-DRAFT D. Eastlake
Intended status: Proposed Standard Futurewei Technologies Intended status: Proposed Standard Futurewei Technologies
Expires: April 18, 2022 October 19, 2021 Expires: October 10, 2022 April 11, 2022
Transient Hiding of Hop-by-Hop Options Transient Hiding of Hop-by-Hop Options
<draft-eastlake-6man-hide-options-01.txt> <draft-eastlake-6man-hide-options-02.txt>
Abstract Abstract
There are increasing requests for a variety IPv6 hop-by-hop options There are increasing requests for a variety IPv6 hop-by-hop options
but such IPv6 options and all IPv4 options, are poorly handled, but such IPv6 options are poorly handled, particularly by high-speed
particularly by high-speed routers in the core Internet where packets routers in the core Internet where packets having options are
having options are commonly discarded. This document proposes a commonly discarded. This document proposes a simple method of
simple method of transiently hiding such options for part of a transiently hiding such options for part of a packet's path to
packet's path to protect the packet from discard. protect the packet from discard.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the IPv6 Maintenance Working Group mailing list <6man@ietf.org> or to the IPv6 Maintenance Working Group mailing list <6man@ietf.org> or
to the authors. to the authors.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at Shadow Directories can be accessed at
https://www.ietf.org/shadow.html. https://www.ietf.org/shadow.html.
Table of Contents Table of Contents
1. Introduction............................................3 1. Introduction............................................3
1.1 Conventions Used in This Document......................3 1.1 Conventions Used in This Document......................3
2. IP Options and Option Handling Problems.................4 2. IP Options and Option Handling Problems.................4
2.1 IPv6 Options...........................................4
2.1 IPv6 Options...........................................5 3. Overview of a Solution..................................7
2.2 IPv4 Options...........................................6 3.1 Transiently Hiding IPv6 Options........................8
3.2 Evolution to Greater Option Support....................8
3. Overview of a Solution..................................8 4. IANA Considerations....................................10
3.1 Transiently Hiding IPv6 Options........................9 5. Security Considerations................................10
3.2 Transiently Hiding IPv4 Options........................9 6. Acknowledgements.......................................10
3.3 Evolution to Greater Option Support...................10
4. IANA Considerations....................................11 Normative References......................................11
5. Security Considerations................................11 Informative References....................................11
6. Acknowledgements.......................................11
Normative References......................................12 Authors' Address..........................................12
Informative References....................................12
Authors' Address..........................................14 Appendix: Revision History................................13
-00 to -01................................................13
-01 to -02................................................13
1. Introduction 1. Introduction
As discussed in [Options3] there are increasing requests for a As discussed in [Options3] there are increasing requests for a
variety IPv6 hop-by-hop options but such IPv6 options and all IPv4 variety IPv6 hop-by-hop options but such IPv6 options, are poorly
options, are poorly handled, particularly by high-speed routers in handled, particularly by high-speed routers in the core Internet
the core Internet where packets having options are commonly where packets having options are commonly discarded. This document
discarded. This document proposes a simple method of transiently proposes a simple method of transiently hiding such options for part
hiding such options for part of a packet's path to protect the packet of a packet's path to protect the packet from discard.
from discard.
1.1 Conventions Used in This Document 1.1 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Terms: Terms:
skipping to change at page 4, line 11 skipping to change at page 4, line 11
field - an area of one or more contiguous bits within a larger field - an area of one or more contiguous bits within a larger
structure. structure.
2. IP Options and Option Handling Problems 2. IP Options and Option Handling Problems
This Section 2 is informational and intended to provide background This Section 2 is informational and intended to provide background
information. information.
In the early days of the Internet, much of the traffic was text, In the early days of the Internet, much of the traffic was text,
transmission speeds were slow and IP routers were commonly small transmission speeds were slow, and IP routers were commonly small
general-purpose computers. Under these conditions, parsing IP headers general-purpose computers. Under these conditions, parsing IP headers
with various options or combinations of options, handling variable with various options or combinations of options, handling variable
length options, etc., was relatively easy. length options, etc., was relatively easy.
However, as the Internet increased in size, bandwidth grew including However, as the Internet increased in size bandwidth grew including
more voluminous media such as video, transmission speeds increased more voluminous media such as video, transmission speeds increased
enormously, and latency/responsiveness requirements became much more enormously, and latency/responsiveness requirements became much more
stringent. This leads to IP routers, especially in the core of the stringent. This leads to IP routers, especially in the core of the
Internet, becoming less flexible and more specialized. To be able to Internet, becoming less flexible and more specialized. To be able to
handle data faster and more efficiently, such core IP routers are handle data faster and more efficiently, such core IP routers are
divided into a forwarding plane and a control plane where the divided into a forwarding plane and a control plane where the
forwarding plan handles the usual data forwarding while the control forwarding plan handles the usual data forwarding while the control
plan handles routing control messages and other packets that the data plan handles routing control messages and other packets that the data
plane cannot handle. In some IP routers, the forwarding plane is plane cannot handle. In some IP routers, the forwarding plane is
implemented with Application Specific Integrated Circuits (ASICs) implemented with Application Specific Integrated Circuits (ASICs)
that are inflexible and may need fields they examine in an IP packet that are inflexible and may need fields they examine in an IP packet
header to be at a fixed offset from the beginning of the packet. header to be at a fixed offset from the beginning of the packet.
Meanwhile, the control plane may be implemented through a relatively Meanwhile, the control plane may be implemented through a general
low power general purpose computer which can only handle a small purpose computer which can only handle a limited number of packets
number of packets per unit time. per unit time.
For these reasons, many IP routers do not implement many or any types For these reasons, many IP routers do not implement many or any types
of IPv6 Hop-by-Hop options or IPv4 header options except through the of IPv6 Hop-by-Hop options (or IPv4 header options) except through
control plane which is relatively slow. Sending packets with such the control plane which has limited capacity. Sending packets with
options to the control plane can overwhelm the control plane and such options to the control plane can overwhelm the control plane and
interfere with routing control messages or other critical functions. interfere with routing control messages or other critical functions.
Very often, particularly for IP routers handling a large volume of Very often, particularly for IP routers handling a large volume of
traffic, a strategy is adopted of dropping IP packets with such traffic, a strategy is adopted of dropping IP packets with such
header options or ignoring IPv4 header options and IPv6 Hop-by-Hop header options or ignoring the header options.
header options.
See [Options3] for a further discussion of these option handling See [Options3] for a further discussion of these option handling
problems. problems.
Further details concerning IPv6 and IPv4 options are given in the
subsections below.
2.1 IPv6 Options 2.1 IPv6 Options
Figure 1 shows the IPv6 header [RFC8200]. The value of the initial Figure 1 shows the IPv6 header [RFC8200]. The value of the initial
4-bit Version field indicates the IP version number and has the value 4-bit Version field indicates the IP version number and has the value
6. 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label | |Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit | | Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
skipping to change at page 6, line 37 skipping to change at page 7, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Options . . Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Option Extension Header Figure 2: IPv6 Option Extension Header
2.2 IPv4 Options
Figure 3 shows the IPv4 header [RFC791]. The value of the initial
4-bit Version field indicates the IP version number and has value 4.
The IPv4 header has many similarities to the iPv6 header. For
example, the IPv4 header 8-bit field called "Protocol" is like the
"Next Header" field in the IPv6 header and the IPv4 header 8-bit
"Type of Service" field, as amended by RFCs issued after [RFC791], is
the same as the IPv6 header "Traffic Class" field. But options that
are integrated into the more complex IPv4 header are handled by
separate header extensions in IPv6. For example consider
fragmentation, where an Internet Protocol packet is split into
pieces, because the packet might be too big to traverse part of its
path, and these pieces are later recombined. Fragmentation is
indicated through an extension header for IPv6 but through fields in
the main IPv4 header for IPv4. IPv4 options are considered part of
the IPv4 header and the size of the options can be determined from
the value of the IHL (Internet Header Length) field which gives the
size of the IPv4 header in units of 4-octet words.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Header
3. Overview of a Solution 3. Overview of a Solution
Figure 4 shows a very high-level view of a network path between two Figure 3 shows a very high-level view of a network path between two
hosts within local networks through the Internet core. (In reality hosts within local networks through the Internet core. (In reality
there will be more levels with a local network, whether a home, there will be more levels with a local network, whether a home,
office, data center, or whatever, usually connected through one or office, data center, or whatever, usually connected through one or
more levels of lower tier service provider before connecting to a more levels of lower tier service provider before connecting to a
Tier 1 provider that connects to the Internet core also known as the Tier 1 provider that connects to the Internet core also known as the
defalt free zone.) defalt free zone.)
- - - - - - - - - - - - - - - - . . - - - - - - - - - - - - - - - - - - - - - - - - - - . . - - - - - - - - - -
. Network 1 . . Core Internet . . Network 1 . . Core Internet .
. . . . . . . .
skipping to change at page 8, line 35 skipping to change at page 7, line 35
. ....... . .......
- - - - - - - - - - - - - - - - . . ..... - - - - - - - - - - - - - - - - . . .....
. Network 2 . . ... . Network 2 . . ...
. . . | | . . . . | | .
. +------+ +---+ +---+ . . +---+ . . +------+ +---+ +---+ . . +---+ .
. |Host B|---|R20|-...-|R29|------------------|R99| . . |Host B|---|R20|-...-|R29|------------------|R99| .
. +------+ +---+ +---+ . . +---+ . . +------+ +---+ +---+ . . +---+ .
. . . . . . . .
. - - - - - - - - - - - - - - - - - - - - - - - - - - . . - - - - - - - - - - - - - - - - - - - - - - - - - - .
Figure 4: High Level View of an Internet Path Figure 3: High Level View of an Internet Path
There are efforts to improve and streamline handling of IPv6 Hop-by- There are efforts to improve and streamline handling of IPv6 Hop-by-
Hop options such as the methods in [Options1] and [Options2]. Hop options such as the methods in [Options1] and [Options2].
However, even if such a method were popular and fully deployed in However, even if such a method were popular and fully deployed in
some network areas, there is likely to be substantial delay before it some network areas, there is likely to be substantial delay before it
would be deployed in most of the Internet core. While some Internet would be deployed in most of the Internet core. While some Internet
core routers may ignore options, others discard all packets with core routers may ignore options, others discard all packets with
options and, as long as there is a significant chance of such options and, as long as there is a significant chance of such
discard, options are rendered essentially useless on paths through discard, options are rendered essentially useless on paths through
the core. the core.
A solution is to hide options before IP packets arrive at the core. A solution is to hide options before IP packets arrive at the core.
This hiding is done in an easily detectable and reversible fashion so This hiding is done in an easily detectable and reversible fashion so
that options can be unhidden after leaving the core. IPv6 Hop-by-Hop that options can be unhidden after leaving the core. IPv6 Hop-by-Hop
options or IPv4 options so hidden might not be effective in the core options so hidden might not be effective in the core but the
but the situation is an improvement over the traffic using such situation is an improvement over the traffic using such options being
options being discarded. discarded.
This solution requires destination support but that should be This solution requires destination support but that should be
knowable in many cases such as traffic between branches of the same knowable in many cases such as traffic between branches of the same
company or between a customer and a data center. company or between a customer and a data center.
To obtain more uniform handling of packets in a flow, it may be To obtain more uniform handling of packets in a flow, it may be
desireable to treat all packet in the flow as if they had such desireable to treat all packet in the flow as if they had such
options in that the packet would be transformed to hide and unhide options in that the packet would be transformed to hide and unhide
options even if there were none. This transformation could also be options even if there were none. This transformation could also be
applied to all packets starting with the first hsving a problematic applied to all packets starting with the first having a problematic
option. option.
3.1 Transiently Hiding IPv6 Options 3.1 Transiently Hiding IPv6 Options
IPv6 Hop-by-Hop options are hidden by replacing the zero Next Header IPv6 Hop-by-Hop options are hidden by replacing the zero Next Header
field in the IPv6 Header by the opaque IP protocol number TBD. This field in the IPv6 Header by the opaque IP protocol number TBD. This
is a very simple modification of one 8-bit field in a fixed location is a very simple modification of one 8-bit field in a fixed location
that has no effect of the size of the packet. They are unhidden by that has no effect of the size of the packet. They are unhidden by
changing this opaque IP protocol number in the IPv6 header back to changing this opaque IP protocol number in the IPv6 header back to
zero. The points of hiding and unhiding in the packet's path (or zero. The points of hiding and unhiding in the packet's path (or
paths if multicast) should be chosen to maximize the routers at the paths if multicast) should be chosen to maximize the routers at the
beginning and end of the path (Figure 4) that implement the options beginning and end of the path (Figure 3) that implement the options
seeing the options while minimizing he chance of unwanted packet seeing the options while minimizing he chance of unwanted packet
discard. discard.
The use of the opaque IP protocol number can defeat deeper IPv6 The use of the opaque IP protocol number can defeat deeper IPv6
packet analysis that is intended to identify flows. It is therefore packet analysis that is intended to identify flows. It is therefore
RECOMMENDED that, when this hiding technique is used, the IPv6 header RECOMMENDED that, when this hiding technique is used, the IPv6 header
Flow Label field be set [RFC6437] and used to identify flows Flow Label field be set [RFC6437] and used to identify flows
[RFC6438] [RFC7098]. Using the Flow Label is a good idea anyway since [RFC6438] [RFC7098]. Using the Flow Label is a good idea anyway since
IPv6 extension headers may move some fields on which flow identity IPv6 extension headers can move some fields on which flow identity
might be based, such as port numbers, so deep into a packet that they might be based, such as port numbers, deeper into a packet so that
are hard to use by routers. they are harder to use by routers.
3.2 Transiently Hiding IPv4 Options
A similar technique can be used for hiding IPv4 options but
significantly more complex manipulations of the packet are required.
As shown in Figure 5, the IPv4 header is made to appear to have no
options by setting the IHL (Internet Header Length) field to its
minimum value of 5, the Protocol field is changed to the opaque IP
protocol number TBD, and the Header Checksum is adjusted to be
correct for the optionless header. To be able to restore the IPv4
header, the old IHL, Protocol, and Header Checksum fields are saved
in a 4-octet word inserted after the Destination Address and before
any Options. The placement of the saved fields is such that their
alignment within a 4-octet word is the same as in the unmodified IPv4
header. The field labeled MBZ MUST be sent as zero and ignored on
receipt.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL=5 |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |Protocol=Opaque| Adjusted Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |SavdIHL| Saved Protocol| Saved Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Modified IPv4 Header
These modifications increase the size of the IPv4 packet, increasing
the chance that fragmentation or MTU problems could occur. For any
node ignorant of the opaque IP protocol number, these modifications
will interfere with flow determination based on the traditional
5-tuple (source and destination address, source and destination port,
and IP protocol) or deep packet inspection.
3.3 Evolution to Greater Option Support 3.2 Evolution to Greater Option Support
This solution supports the evolution of the Internet toward more This solution supports the evolution of the Internet toward more
widespread support of options as follows: widespread support of options as follows:
o As acceptable option support is more widely implemented, probably o As acceptable option support is more widely implemented, probably
starting at lower bandwidth routers nearer the edge, the starting at lower bandwidth routers nearer the edge, the
boundaries at which options are hidden and unhidden can migrate boundaries at which options are hidden and unhidden can migrate
closer to the core. closer to the core.
o If scattered core routers improve to provide acceptable option o If scattered core routers improve to provide acceptable option
skipping to change at page 11, line 29 skipping to change at page 10, line 29
analysis, and the like less effective. On the other hand, firewalls analysis, and the like less effective. On the other hand, firewalls
tend to only admit packets with known permissable values in protocol tend to only admit packets with known permissable values in protocol
header fields such as the IP protocol field. The rejection by a header fields such as the IP protocol field. The rejection by a
firewall of a packet with the opaque IP protocol value will protect firewall of a packet with the opaque IP protocol value will protect
the nodes behind that firewall from possible damage due to the the nodes behind that firewall from possible damage due to the
receipt of a packet modified as specified in this document. If the receipt of a packet modified as specified in this document. If the
firewall does know the opaque IP Protocol value, it should be firewall does know the opaque IP Protocol value, it should be
configured to treat packets with that value safely, possibly by configured to treat packets with that value safely, possibly by
reversing the option hiding transformation. reversing the option hiding transformation.
Should an IPv6 or IPv4 packet modified to hide options get through to Should an IPv6 packet modified to hide options get through to a host
a host, it would likely be discarded due to having an unknown IP that does not understand this modification, it would almost certainly
Protocol. be discarded due to having an unknown IP Protocol.
More TBD [More to be added]
6. Acknowledgements 6. Acknowledgements
The helpful comments of the following are gratefully acknowledged: The helpful comments of the following are gratefully acknowledged:
Peng Shuping Peng Shuping
Normative References Normative References
[RFC791] - Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
10.17487/RFC0791, September 1981, https://www.rfc-
editor.org/info/rfc791
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
March 1997, <http://www.rfc-editor.org/info/rfc2119>. March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC6437] - Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] - Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, DOI "IPv6 Flow Label Specification", RFC 6437, DOI
10.17487/RFC6437, November 2011, 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] - Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] - Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
skipping to change at page 14, line 8 skipping to change at page 12, line 8
https://datatracker.ietf.org/doc/draft-ietf-v6ops-hbh/ https://datatracker.ietf.org/doc/draft-ietf-v6ops-hbh/
[RFC7098] - Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 [RFC7098] - Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
Flow Label for Load Balancing in Server Farms", RFC 7098, DOI Flow Label for Load Balancing in Server Farms", RFC 7098, DOI
10.17487/RFC7098, January 2014, 10.17487/RFC7098, January 2014,
<https://www.rfc-editor.org/info/rfc7098>. <https://www.rfc-editor.org/info/rfc7098>.
Authors' Address Authors' Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Futurewei Technologies Futurewei Technologies, Inc.
2386 Panoramic Circle 2386 Panoramic Circle
Apopka, FL 32703 USA Apopka, FL 32703 USA
Tel: +1-508-333-2270 Tel: +1-508-333-2270
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
Appendix: Revision History
RFC Editor: Please delete this appendix before publication.
-00 to -01
Minor editorial changes. Add more Security Considerations. Add
Acknowledgements section.
-01 to -02
Delete IPv4 material. It was a bit complex and no one really cares
about IPv4 options. Also minor editorial changes.
Copyright and IPR Provisions Copyright and IPR Provisions
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. The definitive version of in the Revised BSD License.
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
 End of changes. 32 change blocks. 
141 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/