bgpd: fix community-list error message spelling

* bgp_vty.c: (community_list_perror, show_ip_community_list_arg,
  show_ip_extcommunity_list_arg) fix spelling
(cherry picked from commit b729294c8c5c6f2af8ddf6cfbea2374b6faabe9d)
ospf6d: fix crash in SPF calculation

* ospf6_spf.c: Don't replace a node with another node with a lower
  number of hops, instead get them from the queue in the correct
  order. (Actually, the replacement crashed the ospf6d daemon
  rather than worked.)
(cherry picked from commit 403138e189c24f6867824c4eeb668d11564e1ca0)
bgpd: fix handling of "Unsupported Capability"

* bgp_packet.c: (bgp_notify_receive) justify the difference between
BGP_NOTIFY_OPEN_UNSUP_PARAM and BGP_NOTIFY_OPEN_UNSUP_CAPBL cases, as
it is explained in RFC5492, page 3, paragraph 1.

"Unsupported Capability" error does not mean, that the peer doesn't
support capabilities advertisement -- quite the opposite (if the peer
would not support capabilities advertisement, the code would be
"Unsupported Optional Parameter"). Thus there is no reason to mark
the peer as one non-supporting capabilities advertisement.

Example: suppose the peer is in fact IPv6-only, but we didn't configure
anything address-family specific for it. Then, the peer would refuse
the session with "Unsupported Capability" code. If we internally set
the peer as non-supporting capabilities advertisement after that, we
will not be able to establish the session with it ever, even with a
fixed configuration -- IPv6-only BGP session cannot be established
without capabilities.

In practice an edge case would be seen as the same IPv6 peer working
with its "neighbor" block read from bgpd.conf, but not working, when
slowly input in "conf t" mode.
(cherry picked from commit c7aa8abd8788c3607ad0131f02e892cf92221e40)
bgpd: VTY string fixes for debug commands

* bgpd/bgp_debug.c: fix VTY strings for BGP debug commands to match
  correct syntax
(cherry picked from commit 6e22b9017e1ae2ce61c383b1b2b63973207704ac)
ripd: resolve debug statements issue (bug 442)

...A nasty bug, if you forgot to disable debugging, stored the config
and reboot your machine - if you really depend on ripd, then the machine
will not fully come back on the network, because ripd fails.
(cherry picked from commit 0fa0335316ce14a79ea4bbb0c40e1322c9941dd3)
doc: fix "ipv6 address" interface command syntax (#608)
(cherry picked from commit e6844aa5d23cf56dd1f31afc96e8145ab188953f)
bgpd/security: CVE-2010-1674 Fix crash due to extended-community parser error

* bgp_attr.c: (bgp_attr_ext_communities) Certain extended-community attrs
  can leave attr->flag indicating ext-community is present, even though no
  extended-community object has been attached to the attr structure.  Thus a
  null-pointer dereference can occur later.
  (bgp_attr_community) No bug fixed here, but tidy up flow so it has same
  form as previous.

  Problem and fix thanks to anonymous reporter.
(cherry picked from commit 0c46638122f10019a12ae9668aec91691cf2e017)
bgpd: Remove AS Path limit/TTL functionality

* draft-ietf-idr-as-pathlimit doesn't seem to have gone anywhere, and its
  author does not think it will make progress in IDR. Remove all support
  introduced for it, but leave stubs for the commands to avoid breaking
  any configurations.

  Basically reverts cecab5e9725792e60a5e4b473e238a14cd85815d.
(cherry picked from commit c8f3fe3063cb9ff193b13011cfbda3e605395340)

Conflicts:

	bgpd/bgp_attr.c (caused by c8e7b895, resolved)
version RE-0.99.17.1
ospf6d: copy "mtu-ignore" option from ospfd

"mtu-ignore" is an option ospfd used to mimic from the vendor's
implementation, now ospf6d will also implement it.

* ospf6_interface.h: extend ospf6_interface structure by one flag
* ospf6_interface.c: (ipv6_ospf6_mtu_ignore, no_ipv6_ospf6_mtu_ignore):
  new declarations; (ospf6_interface_create): show initial value for
  consistency; (ospf6_interface_show): print flag status
* ospf6_message.c: (ospf6_dbdesc_recv): consider interface-specific flag
  when checking MTU
ospf6d: check MTU with message header size in mind

* ospf6_message.c: (ospf6_packet_max): new function, return maximum IPv6
  payload on an interface; (ospf6_hello_send, ospf6_dbdesc_send,
  ospf6_dbdesc_send_newone, ospf6_lsreq_send, ospf6_lsupdate_send_neighbor,
  ospf6_lsupdate_send_interface, ospf6_lsack_send_neighbor,
  ospf6_lsack_send_interface): compare message size with the maximum
  payload instead of the MTU.
bgpd: consistent log msg format (BZ#565)
bgpd: fix SAFI for for MPLS labeled VPN-IPv6

* bgpd.h: change value of BGP_SAFI_VPNV6 to 128 (RFC4659, BZ#659)
* bgp_route.c: (bgp_table_stats_vty) fix length argument to strncmp()
bgpd: more SAFI fixes

Two macros resolving to the same integer constant broke a case block and
a more thorough merge of BGP_SAFI_VPNV4 and BGP_SAFI_VPNV6 was
performed.

* bgpd.h: MPLS-labeled VPN SAFI is AFI-independent, switch to single
* macro
* bgp_capability_test.c: update test data
* bgp_mp_attr_test.c: idem
* bgp_route.c: (bgp_maximum_prefix_overflow, bgp_table_stats_vty) update
  macro and check conditions (where appropriate)
* bgp_packet.c: (bgp_route_refresh_send, bgp_capability_send,
  bgp_update_receive, bgp_route_refresh_receive): idem
* bgp_open.c: (bgp_capability_vty_out, bgp_afi_safi_valid_indices,
  bgp_open_capability_orf, bgp_open_capability): idem
* bgp_attr.c: (bgp_mp_reach_parse, bgp_packet_attribute,
  bgp_packet_withdraw): idem
configure: fix FreeBSD header detection (BZ#408)

This change is based on Xavier Beaudouin's patch (which fixes detection
of 3 config.h macros on FreeBSD without any impact to Linux build of
Quagga) and FreeBSD port patch (which fixes 5 config.h macros, but
breaks the Linux build), it fixes 5 macros and works for both FreeBSD 8
and Linux.
configure: fix OpenPAM detection
bgpd: rename SAFI 3 according to RFC4760

- SAFI value 3 is reserved.  It was assigned by RFC 2858 for a use
  that was never fully implemented, so it is deprecated by this
  document.

* zebra.h: rename macro
* bgp_fsm.c: (bgp_graceful_restart_timer_expire,
  bgp_graceful_stale_timer_expire, bgp_stop, bgp_establish): update
* bgpd.c: (peer_nsf_stop): update
* bgp_open.c: (bgp_capability_vty_out): SAFI 3 isn't a recognized case
  any more
bgpd: Fix compile failure if IPv6 build was disabled.

* bgp_route.c: ({no_,}ipv6_bgp_network_ttl_cmd) depends on ipv6_bgp_network
  which is HAVE_IPV6, so these should be too.
  (bgp_route_init) and the installs should be similarly ifdefed
bgpd: Add new configuration cli for eBGP and iBGP multipath.
There is support to configure this for each (AFI,SAFI), but
currently this configuration is only present for IPv4 unicast:

 maximum-paths [ibgp] <1-255>
 no maximum-paths [ibgp] [<1-255>]

* bgpd/Makefile.am
  * Add bgp_mpath.h and bgp_mpath.c to build
* bgpd/bgp_mpath.h
  * New file for bgp multipath declarations
  * define BGP_DEFAULT_MAXPATHS
* bgpd/bgp_mpath.c
  * bgp_maximum_paths_set(): Configure maximum paths for the given
    afi, safi and bgp instance
  * bgp_maximum_paths_unset(): Return maximum paths configuration to
    the default setting for the given afi, safi and bgp instance
* bgpd/bgp_vty.c
  * Define command strings for above CLI
  * bgp_config_write_maxpaths(): Outputs configuration for the given
    afi, safi and bgp instance
  * Install command elements for IPv4 unicast
* bgpd/bgp_zebra.h
  * bgp_config_write_maxpaths(): External declaration
* bgpd/bgpd.c
  * bgp_create(): Initialize bgp instance to default maximum paths setting
  * bgp_config_write_family(): Output maximum paths configuration
    for the given address family
  * bgp_config_write(): Output maximum paths configuration for
    IPv4 unicast address family
* bgpd/bgpd.h
  * struct bgp: Add storage for maximum paths configuration for
    each afi, safi
bgpd: add bgp_mpath_test.c

* tests/bgp_mpath_test.c
  * New file with test framework for testing BGP multipath
  * Add test for CLI support functions
* tests/Makefile.am
  * Add new testbgpmpath target