From atanu at ICSI.Berkeley.EDU Wed Jul 23 08:41:21 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 23 Jul 2008 08:41:21 -0700 Subject: [Xorp-announce] Announcing XORP Release 1.5 Message-ID: <80895.1216827681@tigger.icir.org> Today is a big day for XORP. First off, we're announcing the XORP 1.5 Release and would like to extend our sincere thanks to the contributors and other community members who helped make it happen. We hope you'll visit our site (http://xorp.org), download our code, play with it, challenge it, build on it, extend it ... And, most importantly, send us feedback about your experience and what you'd like to see in XORP and do with XORP going forward. We're also announcing today the formation of XORP, Inc. (http://xorp.net), a startup founded by the leaders of the XORP.org project, funded by two top-tier VC's, Onset Ventures and Highland Capital Partners, and led by network industry veteran and seasoned entrepreneur, Vivek Ragavan. XORP, Inc. is committed both to supporting the XORP.org community and code base and to building a successful open source business. XORP 1.5 is the first community release to be made under the auspices of XORP, Inc. and we will continue to release community versions of XORP on a regular basis. You'll hear more about XORP, Inc.'s product plans in the months to come. Finally, we want to thank the International Computer Science Institute (ICSI) in Berkeley, CA which until now has hosted the XORP.org project and housed the core team of developers. ICSI's support, together with that of XORP.org's industrial and government sponsors, has been essential in making this a big day. --The XORP Team P.S. Release notes are included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.5 (2008/07/22) ======================== ALL: - XORP now builds on DragonFlyBSD-1.10.1, DragonFlyBSD-1.12.2, FreeBSD-7.0, Linux Debian-4.0 (etch), Linux Fedora 7, Linux Fedora 8, Linux Fedora 9, Linux Gentoo 2008.0, Linux Ubuntu-7.04, Linux Ubuntu-7.10, Linux Ubuntu-8.04.1, NetBSD-4.0, OpenBSD-4.1, OpenBSD-4.2, OpenBSD-4.3, Mac OS X 10.5.2, Mac OS 10.5.3, and Mac OS X 10.5.4. CONFIGURATION: - Addition of new FEA configuration statements to set the IPv4/IPv6 unicast forwarding table IDs: fea { unicast-forwarding4 { table-id: 254 } unicast-forwarding6 { table-id: 254 } } If the table ID is not configured, the FEA will use the default table ID for the system. Note that not all systems support multiple forwarding tables. Currently, they exist only on Linux (among all systems supported by XORP). - The "DISCARD" network interface flag is printed as appropriate when displaying the list of interfaces in the CLI. - Addition of new FEA configuration statement to support "unreachable" interfaces. Such interfaces are similar to "discard" interfaces, except that instead of silently throwing away packets, the system will respond with "ICMP destination unreachable". interfaces { interface my_unreachable { unreachable: true vif my_unreachable { } } } The default value for the "unreachable" statement is false. - Addition of new FEA configuration statement to flag an interface for "management" purpose. An interface that is flagged as "management" might be used in the future by some of the protocols for protocol-specific purpose. interfaces { interface fxp0 { management: true vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } } } The default value for the "management" statement is false. - Addition of support to configure VLANs on an interface. A VLAN is configured by using a "vlan" block that includes the VLAN ID: interfaces { interface fxp0 { vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } vif vlan1 { vlan { vlan-id: 1 } address 10.10.20.20 { prefix-length: 24 } } } } - Addition of preliminary support to configure firewall rules. Firewall rules are configured by using numbered entries: firewall { rule4 100 { action: "drop" protocol: 6 /* TCP */ source { interface: "fxp0" vif: "fxp0" network: 0.0.0.0/0 port-begin: 0 port-end: 65535 } destination { network: 10.10.0.0/24 port-begin: 0 port-end: 1024 } } } Note that compiling firewall support on Linux systems require patching some of the system header files. See ERRATA for details. - The following PIM-SM configuration statements have been deprecated, because PIM-SM doesn't use Router Alert IP option anymore: protocols { pimsm4 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } protocols { pimsm6 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } LIBXORP: - The local system-independent xorp_random() implemenation is used instead of the random(3) provided by the system. - Improved MAC address support (classes Mac and EtherMac). - More consistent usage of XORP_OK and XORP_ERROR to return error codes. LIBXIPC: - Bug fix in the internal mechanism for obtaining the IPv4 addresses from the system. After the bug fix, a secondary (alias) IP address can be specified with the "-i " command-line option to the xorp_rtrmgr or xorp_finder binaries. LIBFEACLIENT: - No significant changes. XRL: - Critical bug fix that can be triggered by malformatted XRLs. - Addition of support for 64-bit integers: i64 and u64 for signed and unsigned respectively. RTRMGR: - Addition of preliminary mechanism to log events to a file or to a syslog facility. - Addition of support to run XORP in background (in daemon mode). XORPSH: - Bug fix related to assigning the node ID position in case the previous (sibling) node was deleted at the same time a new node was added. This fixes "Found out-of-order term(s) inside policy ..." error inside the policy manager. - The "-c " command line option can be used more than once to run multiple commands. - Fix a long configuration delay when using xorpsh in non-interactive mode (e.g., "cat commands.txt | xorpsh"). - Addition of a new "-e" command line option. It can be used to tell xorpsh to exit immediately if the connection to the Finder fails. POLICY: - No significant changes. FEA/MFEA: - Major refactoring of the FEA/MFEA internals. - Critical bug fix that affects recent NetBSD and OpenBSD releases. - Critical IPv6-related bug fix when adding unicast forwarding entries to the kernel. This bug was exposed only on *BSD systems with 64-bit CPU. - If MFEA is started, it will explicitly enable the multicast forwarding flags that have been added to recent OpenBSD releases: net.inet.ip.mforwarding (for OpenBSD-3.9 and later) and net.inet6.ip6.mforwarding (for OpenBSD-4.0 and later). RIB: - No significant changes. RIP/RIPng: - Addition of support for "show ripng" xorpsh operational commands. - Critical RIPng-related bug fix. Previously the RIPng installed routes had incorrect outgoing interface toward the destination. - Bug fix related to the TTL for RIPng multicast packets: now it is set to 255 as specified in the protocol specification (RFC 2080) instead of 1. OLSR: - Added support for RFC 3626 Optimized Link State Routing Protocol. This is a fully fledged XORP routing process with policy route redistribution capability. The work was generously funded over 2007/2008 by CenGen, Inc. OSPF: - Bug fix related to OSPFv3 link-local scope LSAs. Previously the link-local scope LSAs were incorrectly flooded to links other than the one they belonged to. - Bug fix related to OSPFv3 Inter-Area-Prefix-LSAs. The check for the minimum size of an Inter-Area-Prefix-LSA was incorrect so short prefixes such as the default route would be rejected. - Added a clear database command. - In the OSPFv2 configuration "passive" is no longer a bool but a directive. Previously setting an interface to passive would set the interface to loopback and announce a host route for the interface. Using the passive keyword will still set the interface to loopback but now the network will be announced. If the previous behaviour of of announcing the host route is required the host variable can be set to true. BGP: - Added support for 4-byte AS numbers, as detailed in RFC 4893. From 1st Jan 2009 4-byte AS numbers will be allocated by default by RIPE, so it is desirable that all BGP implementations support four-byte AS numbers by that time. Currently 4-byte support is not enabled in XORP by default, but can be enabled using the "enable-4byte-as-numbers" configuration option. STATIC_ROUTES: - Bug fix that prevented the deletion of interface-specific routes using xorpsh. MLD/IGMP: - No significant changes. MLD/IGMP-Lite: - An implementation of Lightweight IGMP/MLD is available in directory ${XORP}/contrib/mld6igmp_lite. It can be used instead of the existing MLD/IGMP vanilla implementation by using the following command before compiling XORP: ./configure --with-mld6igmp_lite PIM-SM: - No significant changes. FIB2MRIB: - No significant changes. CLI: - No significant changes. SNMP: - No significant changes. From atanu at xorp.org Thu Oct 2 10:53:12 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Thu, 02 Oct 2008 10:53:12 -0700 Subject: [Xorp-announce] XORP License change Message-ID: <3717.1222969992@xorps.icir.org> As of Thursday, October 2, 2008, we will be licensing XORP.org code under the GNU General Public License, Version 2 (GPL v2), with selected libraries made available under the GNU Lesser General Public License, Version 2.1 (LGPL v2.1). The license changes will apply to all code currently in the XORP.org CVS tree and to all future XORP.org releases, with the exception of code derived from other sources. Our goals in moving to the GPLv2 and LGPLv2.1 licenses are threefold: - First, we want to ensure that improvements and extensions to the XORP.org code base are made freely available to the XORP.org community. The copyleft provision of the GPLv2 maximizes the likelihood that this will be the case. - At the same time, we believe that the best way to encourage innovation in the broader networking arena is to make it easy for network application developers to take advantage of XORP's open APIs and extensible architecture. We aim to build an ecosystem of developers who adopt XORP as their network operating system of choice, regardless of whether their own code is open or proprietary. The LGPLv2.1 provides a straightforward way for them to do so. - Finally, we don't want to proliferate open source licenses. Moving from the customized wording of our original XORP license to the broadly used OSI-approved GPLv2 and LGPLv2.1 licenses is a step toward that end. Commercial users of XORP who believe they may be impacted or limited by the XORP.org license changes are encouraged to contact us at info at xorp.net. --The XORP Team