16 May, 2012

1 commit

  • By making this a standalone config option (auto-selected as needed),
    selecting CRYPTO from here rather than from XFRM (which is boolean)
    allows the core crypto code to become a module again even when XFRM=y.

    Signed-off-by: Jan Beulich
    Signed-off-by: David S. Miller

    Jan Beulich
     

11 May, 2010

1 commit

  • 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: Patrick McHardy

    Patrick McHardy
     

08 Oct, 2009

1 commit


07 Oct, 2009

1 commit

  • 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
    based on old Internet-Draft.

    Signed-off-by: YOSHIFUJI Hideaki
    Signed-off-by: David S. Miller

    YOSHIFUJI Hideaki / 吉藤英明
     

13 Jun, 2009

1 commit


30 Mar, 2009

1 commit


25 Jul, 2008

1 commit


28 Apr, 2008

1 commit


25 Apr, 2008

1 commit


14 Apr, 2008

1 commit


08 Apr, 2008

1 commit


05 Apr, 2008

2 commits


03 Apr, 2008

1 commit


21 Mar, 2008

1 commit


05 Mar, 2008

1 commit

  • Now the ESP uses the AEAD interface even for algorithms which are
    not combined mode, we need to select CONFIG_CRYPTO_AUTHENC as
    otherwise only combined mode algorithms will work.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

01 Feb, 2008

1 commit


11 Jul, 2007

1 commit

  • 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: Masahide NAKAMURA
    Signed-off-by: David S. Miller

    Masahide NAKAMURA
     

26 Apr, 2007

1 commit

  • Nominally an autoconfigured IPv6 address is added to an interface in the
    Tentative state (as per RFC 2462). Addresses in this state remain in this
    state while the Duplicate Address Detection process operates on them to
    determine their uniqueness on the network. During this period, these
    tentative addresses may not be used for communication, increasing the time
    before a node may be able to communicate on a network. Using Optimistic
    Duplicate Address Detection, autoconfigured addresses may be used
    immediately for communication on the network, as long as certain rules are
    followed to avoid conflicts with other nodes during the Duplicate Address
    Detection process.

    Signed-off-by: Neil Horman
    Signed-off-by: YOSHIFUJI Hideaki
    Signed-off-by: David S. Miller

    Neil Horman
     

14 Feb, 2007

1 commit


03 Dec, 2006

1 commit

  • 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: Thomas Graf
    Signed-off-by: David S. Miller

    Thomas Graf
     

19 Oct, 2006

1 commit


12 Oct, 2006

1 commit


04 Oct, 2006

1 commit

  • This patch introduces the BEET mode (Bound End-to-End Tunnel) with as
    specified by the ietf draft at the following link:

    http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-06.txt

    The patch provides only single family support (i.e. inner family =
    outer family).

    Signed-off-by: Diego Beltrami
    Signed-off-by: Miika Komu
    Signed-off-by: Herbert Xu
    Signed-off-by: Abhinav Pathak
    Signed-off-by: Jeff Ahrenholz
    Signed-off-by: David S. Miller

    Diego Beltrami
     

23 Sep, 2006

6 commits


21 Sep, 2006

1 commit


18 Jun, 2006

1 commit

  • This patch adds the structure xfrm_mode. It is meant to represent
    the operations carried out by transport/tunnel modes.

    By doing this we allow additional encapsulation modes to be added
    without clogging up the xfrm_input/xfrm_output paths.

    Candidate modes include 4-to-6 tunnel mode, 6-to-4 tunnel mode, and
    BEET modes.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

29 Mar, 2006

1 commit

  • 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: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

21 Mar, 2006

3 commits


20 Jul, 2005

1 commit


12 Jul, 2005

1 commit

  • Move the protocol specific config options out to the specific protocols.
    With this change net/Kconfig now starts to become readable and serve as a
    good basis for further re-structuring.

    The menu structure is left almost intact, except that indention is
    fixed in most cases. Most visible are the INET changes where several
    "depends on INET" are replaced with a single ifdef INET / endif pair.

    Several new files were created to accomplish this change - they are
    small but serve the purpose that config options are now distributed
    out where they belongs.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds