1. 14 7月, 2015 1 次提交
    • T
      net: Build IPv6 into kernel by default · de551f2e
      Tom Herbert 提交于
      This patch makes the default to build IPv6 into the kernel. IPv6
      now has significant traction and any remaining vestiges of IPv6
      not being provided parity with IPv4 should be swept away. IPv6 is now
      core to the Internet and kernel.
      
      Points on IPv6 adoption:
      
      - Per Google statistics, IPv6 usage has reached 7% on the Internet
        and continues to exhibit an exponential growth rate
        https://www.google.com/intl/en/ipv6/statistics.html
      - Just a few days ago ARIN officially depleted its IPv4 pool
      - IPv6 only data centers are being successfully built
        (e.g. at Facebook)
      
      This patch changes the IPv6 Kconfig for IPV6. Default for CONFIG_IPV6
      is set to "y" and the text has been updated to reflect the maturity of
      IPv6.
      
      Impact:
      
      Under some circumstances building modules in to kernel might have a
      performance advantage. In my testing, I did notice a very slight
      improvement.
      
      This will obviously increase the size of the kernel image. In my
      configuration I see:
      
      IPv6 as module:
      
         text    data     bss     dec     hex filename
      9703666 1899288  933888 12536842         bf4c0a vmlinux
      
      IPv6 built into kernel
      
        text     data     bss     dec     hex filename
      9436490 1879600  913408 12229498         ba9b7a vmlinux
      
      Which increases text size by ~270K (2.8% increase in size for me). If
      image size is an issue, presumably for a device which does not do IP
      networking (IMO we should be discouraging IPv4-only devices), IPV6 can
      be disabled or still built as a module.
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de551f2e
  2. 20 2月, 2014 1 次提交
  3. 29 10月, 2013 1 次提交
  4. 10 10月, 2013 1 次提交
  5. 27 3月, 2013 1 次提交
  6. 22 2月, 2013 1 次提交
  7. 12 1月, 2013 1 次提交
    • K
      net/ipv6: remove depends on CONFIG_EXPERIMENTAL · f9ceb16e
      Kees Cook 提交于
      The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
      while now and is almost always enabled by default. As agreed during the
      Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
      
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      CC: James Morris <jmorris@namei.org>
      CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      CC: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      f9ceb16e
  8. 15 8月, 2012 1 次提交
  9. 16 5月, 2012 1 次提交
  10. 11 5月, 2010 1 次提交
    • P
      ipv6: ip6mr: support multiple tables · d1db275d
      Patrick McHardy 提交于
      This patch adds support for multiple independant multicast routing instances,
      named "tables".
      
      Userspace multicast routing daemons can bind to a specific table instance by
      issuing a setsockopt call using a new option MRT6_TABLE. The table number is
      stored in the raw socket data and affects all following ip6mr setsockopt(),
      getsockopt() and ioctl() calls. By default, a single table (RT6_TABLE_DFLT)
      is created with a default routing rule pointing to it. Newly created pim6reg
      devices have the table number appended ("pim6regX"), with the exception of
      devices created in the default table, which are named just "pim6reg" for
      compatibility reasons.
      
      Packets are directed to a specific table instance using routing rules,
      similar to how regular routing rules work. Currently iif, oif and mark
      are supported as keys, source and destination addresses could be supported
      additionally.
      
      Example usage:
      
      - bind pimd/xorp/... to a specific table:
      
      uint32_t table = 123;
      setsockopt(fd, SOL_IPV6, MRT6_TABLE, &table, sizeof(table));
      
      - create routing rules directing packets to the new table:
      
      # ip -6 mrule add iif eth0 lookup 123
      # ip -6 mrule add oif eth0 lookup 123
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d1db275d
  11. 08 10月, 2009 1 次提交
  12. 07 10月, 2009 1 次提交
    • Y
      ipv6 sit: 6rd (IPv6 Rapid Deployment) Support. · fa857afc
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      IPv6 Rapid Deployment (6rd; draft-ietf-softwire-ipv6-6rd) builds upon
      mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly
      deploy IPv6 unicast service to IPv4 sites to which it provides
      customer premise equipment.  Like 6to4, it utilizes stateless IPv6 in
      IPv4 encapsulation in order to transit IPv4-only network
      infrastructure.  Unlike 6to4, a 6rd service provider uses an IPv6
      prefix of its own in place of the fixed 6to4 prefix.
      
      With this option enabled, the SIT driver offers 6rd functionality by
      providing additional ioctl API to configure the IPv6 Prefix for in
      stead of static 2002::/16 for 6to4.
      
      Original patch was done by Alexandre Cassen <acassen@freebox.fr>
      based on old Internet-Draft.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa857afc
  13. 13 6月, 2009 1 次提交
  14. 30 3月, 2009 1 次提交
  15. 25 7月, 2008 1 次提交
  16. 28 4月, 2008 1 次提交
  17. 25 4月, 2008 1 次提交
  18. 14 4月, 2008 1 次提交
  19. 05 4月, 2008 2 次提交
  20. 03 4月, 2008 1 次提交
  21. 21 3月, 2008 1 次提交
  22. 05 3月, 2008 1 次提交
  23. 01 2月, 2008 1 次提交
  24. 11 7月, 2007 1 次提交
    • M
      [IPV6] MIP6: Loadable module support for MIPv6. · 59fbb3a6
      Masahide NAKAMURA 提交于
      This patch makes MIPv6 loadable module named "mip6".
      
      Here is a modprobe.conf(5) example to load it automatically
      when user application uses XFRM state for MIPv6:
      
      alias xfrm-type-10-43 mip6
      alias xfrm-type-10-60 mip6
      
      Some MIPv6 feature is not included by this modular, however,
      it should not be affected to other features like either IPsec
      or IPv6 with and without the patch.
      We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
      separately for future work.
      
      Loadable features:
      * MH receiving check (to send ICMP error back)
      * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
      * XFRM policy/state database handling for RO
      
      These are NOT covered as loadable:
      * Home Address flags and its rule on source address selection
      * XFRM sub policy (depends on its own kernel option)
      * XFRM functions to receive RO as IPv6 extension header
      * MH sending/receiving through raw socket if user application
        opens it (since raw socket allows to do so)
      * RH2 sending as ancillary data
      * RH2 operation with setsockopt(2)
      Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59fbb3a6
  25. 26 4月, 2007 1 次提交
  26. 14 2月, 2007 1 次提交
  27. 03 12月, 2006 1 次提交
    • T
      [NET]: Rethink mark field in struct flowi · 47dcf0cb
      Thomas Graf 提交于
      Now that all protocols have been made aware of the mark
      field it can be moved out of the union thus simplyfing
      its usage.
      
      The config options in the IPv4/IPv6/DECnet subsystems
      to enable respectively disable mark based routing only
      obfuscate the code with ifdefs, the cost for the
      additional comparison in the flow key is insignificant,
      and most distributions have all these options enabled
      by default anyway. Therefore it makes sense to remove
      the config options and enable mark based routing by
      default.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      47dcf0cb
  28. 19 10月, 2006 1 次提交
  29. 12 10月, 2006 1 次提交
  30. 04 10月, 2006 1 次提交
  31. 23 9月, 2006 6 次提交
  32. 21 9月, 2006 1 次提交
  33. 18 6月, 2006 1 次提交
  34. 29 3月, 2006 1 次提交
    • H
      [INET]: Introduce tunnel4/tunnel6 · d2acc347
      Herbert Xu 提交于
      Basically this patch moves the generic tunnel protocol stuff out of
      xfrm4_tunnel/xfrm6_tunnel and moves it into the new files of tunnel4.c
      and tunnel6 respectively.
      
      The reason for this is that the problem that Hugo uncovered is only
      the tip of the iceberg.  The real problem is that when we removed the
      dependency of ipip on xfrm4_tunnel we didn't really consider the module
      case at all.
      
      For instance, as it is it's possible to build both ipip and xfrm4_tunnel
      as modules and if the latter is loaded then ipip simply won't load.
      
      After considering the alternatives I've decided that the best way out of
      this is to restore the dependency of ipip on the non-xfrm-specific part
      of xfrm4_tunnel.  This is acceptable IMHO because the intention of the
      removal was really to be able to use ipip without the xfrm subsystem.
      This is still preserved by this patch.
      
      So now both ipip/xfrm4_tunnel depend on the new tunnel4.c which handles
      the arbitration between the two.  The order of processing is determined
      by a simple integer which ensures that ipip gets processed before
      xfrm4_tunnel.
      
      The situation for ICMP handling is a little bit more complicated since
      we may not have enough information to determine who it's for.  It's not
      a big deal at the moment since the xfrm ICMP handlers are basically
      no-ops.  In future we can deal with this when we look at ICMP caching
      in general.
      
      The user-visible change to this is the removal of the TUNNEL Kconfig
      prompts.  This makes sense because it can only be used through IPCOMP
      as it stands.
      
      The addition of the new modules shouldn't introduce any problems since
      module dependency will cause them to be loaded.
      
      Oh and I also turned some unnecessary pskb's in IPv6 related to this
      patch to skb's.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2acc347