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