| < 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/ | ||||