DESIGN

   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.  Deeper matching of some Neighbor Discovery messages is also
  19 supported.
  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.