]>
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 | |
685a51a5 JP |
18 | packet. Deeper matching of some Neighbor Discovery messages is also |
19 | supported. | |
d31f1109 JP |
20 | |
21 | IPv6 was not designed to interact well with middle-boxes. This, | |
22 | combined with Open vSwitch's stateless nature, have affected the | |
23 | processing of IPv6 traffic, which is detailed below. | |
24 | ||
25 | Extension Headers | |
26 | ----------------- | |
27 | ||
28 | The base IPv6 header is incredibly simple with the intention of only | |
29 | containing information relevant for routing packets between two | |
30 | endpoints. IPv6 relies heavily on the use of extension headers to | |
31 | provide any other functionality. Unfortunately, the extension headers | |
32 | were designed in such a way that it is impossible to move to the next | |
33 | header (including the layer-4 payload) unless the current header is | |
34 | understood. | |
35 | ||
36 | Open vSwitch will process the following extension headers and continue | |
37 | to the next header: | |
38 | ||
39 | * Fragment (see the next section) | |
40 | * AH (Authentication Header) | |
41 | * Hop-by-Hop Options | |
42 | * Routing | |
43 | * Destination Options | |
44 | ||
45 | When a header is encountered that is not in that list, it is considered | |
46 | "terminal". A terminal header's IPv6 protocol value is stored in | |
47 | "nw_proto" for matching purposes. If a terminal header is TCP, UDP, or | |
48 | ICMPv6, the packet will be further processed in an attempt to extract | |
49 | layer-4 information. | |
50 | ||
51 | Fragments | |
52 | --------- | |
53 | ||
54 | IPv6 requires that every link in the internet have an MTU of 1280 octets | |
55 | or greater (RFC 2460). As such, a terminal header (as described above in | |
56 | "Extension Headers") in the first fragment should generally be | |
57 | reachable. In this case, the terminal header's IPv6 protocol type is | |
58 | stored in the "nw_proto" field for matching purposes. If a terminal | |
59 | header cannot be found in the first fragment (one with a fragment offset | |
60 | of zero), the "nw_proto" field is set to 0. Subsequent fragments (those | |
61 | with a non-zero fragment offset) have the "nw_proto" field set to the | |
62 | IPv6 protocol type for fragments (44). | |
63 | ||
64 | Jumbograms | |
65 | ---------- | |
66 | ||
67 | An IPv6 jumbogram (RFC 2675) is a packet containing a payload longer | |
68 | than 65,535 octets. A jumbogram is only relevant in subnets with a link | |
69 | MTU greater than 65,575 octets, and are not required to be supported on | |
70 | nodes that do not connect to link with such large MTUs. Currently, Open | |
71 | vSwitch doesn't process jumbograms. | |
72 | ||
73 | ||
74 | Suggestions | |
75 | =========== | |
76 | ||
77 | Suggestions to improve Open vSwitch are welcome at discuss@openvswitch.org. |