NAME

  tst_dsthop_get - Get Destination Options header which the application specifies


PURPOSE

  To check whether the Destination options header specified by application
  can be get correctly by getsockopt().


SYNOPSIS

  ./tst_dsthop_get [-tooloption ...]
    -tooloption : v6api tool option


TEST PROCEDURE

  1. Create an IPv6 socket
  2. Get Destination options header
  3. Check A: Destination options header has a length of zero
  4. Set Destination options header
  5. Get Destination options header
  6. Check B: Destination options header is the same as set
  7. Get Destination options header with NULL data pointer
  8. Check C: Fail to get destination options header
  9. Get Destination options header with NULL length pointer
  10.Check D: Fail to get destination options header
  11.Get Destination options header with short length
  12.Check E: Destination options header returned with short length


NOTE

  None


REFERENCE

  RFC 3542
  9.2.  Sending Destination Options
    To send a Destination options header, the application specifies it
    either as ancillary data in a call to sendmsg() or using
    setsockopt().
    The application can remove any sticky Destination options header by
    calling setsockopt() for IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS with a zero
    option length.
    This API assumes the ordering about extension headers as described in
    [RFC-2460].  Thus, one set of Destination options can only appear
    before a Routing header, and one set can only appear after a Routing
    header (or in a packet with no Routing header).  Each set can consist
    of one or more options but each set is a single extension header.
    Today all destination options that an application may want to specify
    can be put after (or without) a Routing header.  Thus, applications
    should usually need IPV6_DSTOPTS only and should avoid using
    IPV6_RTHDRDSTOPTS whenever possible.
    When using ancillary data a Destination options header is passed
    between the application and the kernel as follows: The set preceding
    a Routing header are specified with the cmsg_level member set to
    IPPROTO_IPV6 and the cmsg_type member set to IPV6_RTHDRDSTOPTS.  Any
    setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently
    ignored when sending packets unless a Routing header is also
    specified.  Note that the "Routing header" here means the one
    specified by this API.  Even when the kernel inserts a routing header
    in its internal routine (e.g., in a mobile IPv6 stack), the
    Destination options header specified by IPV6_RTHDRDSTOPTS will still
    be ignored unless the application explicitly specifies its own
    Routing header.
    The set of Destination options after a Routing header, which are also
    used when no Routing header is present, are specified with the
    cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is
    set to IPV6_DSTOPTS.
    The Destination options are normally constructed using the
    inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and
    inet6_opt_set_val() functions, described in Section 10.
    Additional errors may be possible from sendmsg() and setsockopt() if
    the specified option is in error.