projects / mirror_ovs.git / blame
| Commit | Line | Data |
|---|---|---|
| d31f1109 JP |
1 | Design Decisions In Open vSwitch |
| 2 | ================================ | |
| 3 | ||
| 4 | This document describes design decisions that went into implementing | |
| 5 | Open vSwitch. While we believe these to be reasonable decisions, it is | |
| 6 | impossible to predict how Open vSwitch will be used in all environments. | |
| 7 | Understanding assumptions made by Open vSwitch is critical to a | |
| 8 | successful deployment. The end of this document contains contact | |
| 9 | information that can be used to let us know how we can make Open vSwitch | |
| 10 | more generally useful. | |
| 11 | ||
| 12 | ||
| 13 | IPv6 | |
| 14 | ==== | |
| 15 | ||
| 16 | Open vSwitch supports stateless handling of IPv6 packets. Flows can be | |
| 17 | written to support matching TCP, UDP, and ICMPv6 headers within an IPv6 | |
| 18 | packet. | |
| 19 | ||
| 20 | IPv6 was not designed to interact well with middle-boxes. This, | |
| 21 | combined with Open vSwitch's stateless nature, have affected the | |
| 22 | processing of IPv6 traffic, which is detailed below. | |
| 23 | ||
| 24 | Extension Headers | |
| 25 | ----------------- | |
| 26 | ||
| 27 | The base IPv6 header is incredibly simple with the intention of only | |
| 28 | containing information relevant for routing packets between two | |
| 29 | endpoints. IPv6 relies heavily on the use of extension headers to | |
| 30 | provide any other functionality. Unfortunately, the extension headers | |
| 31 | were designed in such a way that it is impossible to move to the next | |
| 32 | header (including the layer-4 payload) unless the current header is | |
| 33 | understood. | |
| 34 | ||
| 35 | Open vSwitch will process the following extension headers and continue | |
| 36 | to the next header: | |
| 37 | ||
| 38 | * Fragment (see the next section) | |
| 39 | * AH (Authentication Header) | |
| 40 | * Hop-by-Hop Options | |
| 41 | * Routing | |
| 42 | * Destination Options | |
| 43 | ||
| 44 | When a header is encountered that is not in that list, it is considered | |
| 45 | "terminal". A terminal header's IPv6 protocol value is stored in | |
| 46 | "nw_proto" for matching purposes. If a terminal header is TCP, UDP, or | |
| 47 | ICMPv6, the packet will be further processed in an attempt to extract | |
| 48 | layer-4 information. | |
| 49 | ||
| 50 | Fragments | |
| 51 | --------- | |
| 52 | ||
| 53 | IPv6 requires that every link in the internet have an MTU of 1280 octets | |
| 54 | or greater (RFC 2460). As such, a terminal header (as described above in | |
| 55 | "Extension Headers") in the first fragment should generally be | |
| 56 | reachable. In this case, the terminal header's IPv6 protocol type is | |
| 57 | stored in the "nw_proto" field for matching purposes. If a terminal | |
| 58 | header cannot be found in the first fragment (one with a fragment offset | |
| 59 | of zero), the "nw_proto" field is set to 0. Subsequent fragments (those | |
| 60 | with a non-zero fragment offset) have the "nw_proto" field set to the | |
| 61 | IPv6 protocol type for fragments (44). | |
| 62 | ||
| 63 | Jumbograms | |
| 64 | ---------- | |
| 65 | ||
| 66 | An IPv6 jumbogram (RFC 2675) is a packet containing a payload longer | |
| 67 | than 65,535 octets. A jumbogram is only relevant in subnets with a link | |
| 68 | MTU greater than 65,575 octets, and are not required to be supported on | |
| 69 | nodes that do not connect to link with such large MTUs. Currently, Open | |
| 70 | vSwitch doesn't process jumbograms. | |
| 71 | ||
| 72 | ||
| 73 | Suggestions | |
| 74 | =========== | |
| 75 | ||
| 76 | Suggestions to improve Open vSwitch are welcome at discuss@openvswitch.org. |