1.\"- 2.\" Copyright (c) 2001 Charles Mott <cm@linktel.net> 3.\" All rights reserved. 4.\" 5.\" Redistribution and use in source and binary forms, with or without 6.\" modification, are permitted provided that the following conditions 7.\" are met: 8.\" 1. Redistributions of source code must retain the above copyright 9.\" notice, this list of conditions and the following disclaimer. 10.\" 2. Redistributions in binary form must reproduce the above copyright 11.\" notice, this list of conditions and the following disclaimer in the 12.\" documentation and/or other materials provided with the distribution. 13.\" 14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 17.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 24.\" SUCH DAMAGE. 25.\" 26.\" $FreeBSD$ 27.\" 28.Dd December 25, 2013 29.Dt LIBALIAS 3 30.Os 31.Sh NAME 32.Nm libalias 33.Nd packet aliasing library for masquerading and network address translation 34.Sh SYNOPSIS 35.In sys/types.h 36.In netinet/in.h 37.In alias.h 38.Pp 39Function prototypes are given in the main body of the text. 40.Sh DESCRIPTION 41The 42.Nm 43library is a collection of functions for aliasing and de-aliasing of IP 44packets, intended for masquerading and network address translation (NAT). 45.Sh INTRODUCTION 46This library is a moderately portable set of functions designed to assist 47in the process of IP masquerading and network address translation. 48Outgoing packets from a local network with unregistered IP addresses can 49be aliased to appear as if they came from an accessible IP address. 50Incoming packets are then de-aliased so that they are sent to the correct 51machine on the local network. 52.Pp 53A certain amount of flexibility is built into the packet aliasing engine. 54In the simplest mode of operation, a many-to-one address mapping takes 55place between the local network and the packet aliasing host. 56This is known as IP masquerading. 57In addition, one-to-one mappings between local and public addresses can 58also be implemented, which is known as static NAT. 59In between these extremes, different groups of private addresses can be 60linked to different public addresses, comprising several distinct 61many-to-one mappings. 62Also, a given public address and port can be statically redirected to a 63private address/port. 64.Sh INITIALIZATION AND CONTROL 65One special function, 66.Fn LibAliasInit , 67must always be called before any packet handling may be performed, and 68the returned instance pointer must be passed to all the other functions. 69Normally, the 70.Fn LibAliasSetAddress 71function is called afterwards, to set the default aliasing address. 72In addition, the operating mode of the packet aliasing engine can be 73customized by calling 74.Fn LibAliasSetMode . 75.Pp 76.Ft "struct libalias *" 77.Fn LibAliasInit "struct libalias *" 78.Bd -ragged -offset indent 79This function is used to initialize 80internal data structures. 81When called the first time, a 82.Dv NULL 83pointer should be passed as an argument. 84The following mode bits are always set after calling 85.Fn LibAliasInit . 86See the description of 87.Fn LibAliasSetMode 88below for the meaning of these mode bits. 89.Pp 90.Bl -item -offset indent -compact 91.It 92.Dv PKT_ALIAS_SAME_PORTS 93.It 94.Dv PKT_ALIAS_USE_SOCKETS 95.It 96.Dv PKT_ALIAS_RESET_ON_ADDR_CHANGE 97.El 98.Pp 99This function will always return the packet aliasing engine to the same 100initial state. 101The 102.Fn LibAliasSetAddress 103function is normally called afterwards, and any desired changes from the 104default mode bits listed above require a call to 105.Fn LibAliasSetMode . 106.Pp 107It is mandatory that this function be called at the beginning of a program 108prior to any packet handling. 109.Ed 110.Pp 111.Ft void 112.Fn LibAliasUninit "struct libalias *" 113.Bd -ragged -offset indent 114This function has no return value and is used to clear any 115resources attached to internal data structures. 116.Pp 117This function should be called when a program stops using the aliasing 118engine; amongst other things, it clears out any firewall holes. 119To provide backwards compatibility and extra security, it is added to 120the 121.Xr atexit 3 122chain by 123.Fn LibAliasInit . 124.Ed 125.Pp 126.Ft void 127.Fn LibAliasSetAddress "struct libalias *" "struct in_addr addr" 128.Bd -ragged -offset indent 129This function sets the source address to which outgoing packets from the 130local area network are aliased. 131All outgoing packets are re-mapped to this address unless overridden by a 132static address mapping established by 133.Fn LibAliasRedirectAddr . 134If this function has not been called, and no static rules match, an outgoing 135packet retains its source address. 136.Pp 137If the 138.Dv PKT_ALIAS_RESET_ON_ADDR_CHANGE 139mode bit is set (the default mode of operation), then the internal aliasing 140link tables will be reset any time the aliasing address changes. 141This is useful for interfaces such as 142.Xr ppp 8 , 143where the IP 144address may or may not change on successive dial-up attempts. 145.Pp 146If the 147.Dv PKT_ALIAS_RESET_ON_ADDR_CHANGE 148mode bit is set to zero, this function can also be used to dynamically change 149the aliasing address on a packet-to-packet basis (it is a low overhead call). 150.Pp 151It is mandatory that this function be called prior to any packet handling. 152.Ed 153.Pp 154.Ft unsigned int 155.Fn LibAliasSetMode "struct libalias *" "unsigned int flags" "unsigned int mask" 156.Bd -ragged -offset indent 157This function sets or clears mode bits 158according to the value of 159.Fa flags . 160Only bits marked in 161.Fa mask 162are affected. 163The following mode bits are defined in 164.In alias.h : 165.Bl -tag -width indent 166.It Dv PKT_ALIAS_LOG 167Enables logging into 168.Pa /var/log/alias.log . 169Each time an aliasing link is created or deleted, the log file is appended to 170with the current number of ICMP, TCP and UDP links. 171Mainly useful for debugging when the log file is viewed continuously with 172.Xr tail 1 . 173.It Dv PKT_ALIAS_DENY_INCOMING 174If this mode bit is set, all incoming packets associated with new TCP 175connections or new UDP transactions will be marked for being ignored 176.Po 177.Fn LibAliasIn 178returns 179.Dv PKT_ALIAS_IGNORED 180code 181.Pc 182by the calling program. 183Response packets to connections or transactions initiated from the packet 184aliasing host or local network will be unaffected. 185This mode bit is useful for implementing a one-way firewall. 186.It Dv PKT_ALIAS_SAME_PORTS 187If this mode bit is set, the packet-aliasing engine will attempt to leave 188the alias port numbers unchanged from the actual local port numbers. 189This can be done as long as the quintuple (proto, alias addr, alias port, 190remote addr, remote port) is unique. 191If a conflict exists, a new aliasing port number is chosen even if this 192mode bit is set. 193.It Dv PKT_ALIAS_USE_SOCKETS 194This bit should be set when the packet aliasing host originates network 195traffic as well as forwards it. 196When the packet aliasing host is waiting for a connection from an unknown 197host address or unknown port number (e.g.\& an FTP data connection), this 198mode bit specifies that a socket be allocated as a place holder to prevent 199port conflicts. 200Once a connection is established, usually within a minute or so, the socket 201is closed. 202.It Dv PKT_ALIAS_UNREGISTERED_ONLY 203If this mode bit is set, traffic on the local network which does not 204originate from unregistered address spaces will be ignored. 205Standard Class A, B and C unregistered addresses are: 206.Pp 20710.0.0.0 -> 10.255.255.255 (Class A subnet) 208172.16.0.0 -> 172.31.255.255 (Class B subnets) 209192.168.0.0 -> 192.168.255.255 (Class C subnets) 210.Pp 211This option is useful in the case that the packet aliasing host has both 212registered and unregistered subnets on different interfaces. 213The registered subnet is fully accessible to the outside world, so traffic 214from it does not need to be passed through the packet aliasing engine. 215.It Dv PKT_ALIAS_UNREGISTERED_CGN 216Like PKT_ALIAS_UNREGISTERED_ONLY, but includes the RFC 6598 (Carrier Grade 217NAT) subnet as follows: 218.Pp 219100.64.0.0 -> 100.127.255.255 (RFC 6598 subnet) 220.It Dv PKT_ALIAS_RESET_ON_ADDR_CHANGE 221When this mode bit is set and 222.Fn LibAliasSetAddress 223is called to change the aliasing address, the internal link table of the 224packet aliasing engine will be cleared. 225This operating mode is useful for 226.Xr ppp 8 227links where the interface address can sometimes change or remain the same 228between dial-up attempts. 229If this mode bit is not set, the link table will never be reset in the event 230of an address change. 231.It Dv PKT_ALIAS_PUNCH_FW 232This option makes 233.Nm 234.Dq punch holes 235in an 236.Xr ipfirewall 4 - 237based firewall for FTP/IRC DCC connections. 238The holes punched are bound by from/to IP address and port; it will not be 239possible to use a hole for another connection. 240A hole is removed when the connection that uses it dies. 241To cater to unexpected death of a program using 242.Nm 243(e.g.\& kill -9), 244changing the state of the flag will clear the entire firewall range 245allocated for holes. 246This clearing will also happen on the initial call to 247.Fn LibAliasSetFWBase , 248which must happen prior to setting this flag. 249.It Dv PKT_ALIAS_REVERSE 250This option makes 251.Nm 252reverse the way it handles incoming and outgoing packets, allowing it 253to be fed with data that passes through the internal interface rather 254than the external one. 255.It Dv PKT_ALIAS_PROXY_ONLY 256This option tells 257.Nm 258to obey transparent proxy rules only. 259Normal packet aliasing is not performed. 260See 261.Fn LibAliasProxyRule 262below for details. 263.It Dv PKT_ALIAS_SKIP_GLOBAL 264This option is used by 265.Pa ipfw_nat 266only. 267Specifying it as a flag to 268.Fn LibAliasSetMode 269has no effect. 270See section 271.Sx NETWORK ADDRESS TRANSLATION 272in 273.Xr ipfw 8 274for more details. 275.El 276.Ed 277.Pp 278.Ft void 279.Fn LibAliasSetFWBase "struct libalias *" "unsigned int base" "unsigned int num" 280.Bd -ragged -offset indent 281Set the firewall range allocated for punching firewall holes (with the 282.Dv PKT_ALIAS_PUNCH_FW 283flag). 284The range is cleared for all rules on initialization. 285.Ed 286.Pp 287.Ft void 288.Fn LibAliasSkinnyPort "struct libalias *" "unsigned int port" 289.Bd -ragged -offset indent 290Set the TCP port used by the Skinny Station protocol. 291Skinny is used by Cisco IP phones to communicate with 292Cisco Call Managers to set up voice over IP calls. 293If this is not set, Skinny aliasing will not be done. 294The typical port used by Skinny is 2000. 295.Ed 296.Sh PACKET HANDLING 297The packet handling functions are used to modify incoming (remote to local) 298and outgoing (local to remote) packets. 299The calling program is responsible for receiving and sending packets via 300network interfaces. 301.Pp 302Along with 303.Fn LibAliasInit 304and 305.Fn LibAliasSetAddress , 306the two packet handling functions, 307.Fn LibAliasIn 308and 309.Fn LibAliasOut , 310comprise the minimal set of functions needed for a basic IP masquerading 311implementation. 312.Pp 313.Ft int 314.Fn LibAliasIn "struct libalias *" "char *buffer" "int maxpacketsize" 315.Bd -ragged -offset indent 316An incoming packet coming from a remote machine to the local network is 317de-aliased by this function. 318The IP packet is pointed to by 319.Fa buffer , 320and 321.Fa maxpacketsize 322indicates the size of the data structure containing the packet and should 323be at least as large as the actual packet size. 324.Pp 325Return codes: 326.Bl -tag -width indent 327.It Dv PKT_ALIAS_OK 328The packet aliasing process was successful. 329.It Dv PKT_ALIAS_IGNORED 330The packet was ignored and not de-aliased. 331This can happen if the protocol is unrecognized, as for an ICMP message 332type that is not handled, or if incoming packets for new connections are being 333ignored (if the 334.Dv PKT_ALIAS_DENY_INCOMING 335mode bit was set using 336.Fn LibAliasSetMode ) . 337.It Dv PKT_ALIAS_UNRESOLVED_FRAGMENT 338This is returned when a fragment cannot be resolved because the header 339fragment has not been sent yet. 340In this situation, fragments must be saved with 341.Fn LibAliasSaveFragment 342until a header fragment is found. 343.It Dv PKT_ALIAS_FOUND_HEADER_FRAGMENT 344The packet aliasing process was successful, and a header fragment was found. 345This is a signal to retrieve any unresolved fragments with 346.Fn LibAliasGetFragment 347and de-alias them with 348.Fn LibAliasFragmentIn . 349.It Dv PKT_ALIAS_ERROR 350An internal error within the packet aliasing engine occurred. 351.El 352.Ed 353.Pp 354.Ft int 355.Fn LibAliasOut "struct libalias *" "char *buffer" "int maxpacketsize" 356.Bd -ragged -offset indent 357An outgoing packet coming from the local network to a remote machine is 358aliased by this function. 359The IP packet is pointed to by 360.Fa buffer , 361and 362.Fa maxpacketsize 363indicates the maximum packet size permissible should the packet length be 364changed. 365IP encoding protocols place address and port information in the encapsulated 366data stream which has to be modified and can account for changes in packet 367length. 368Well known examples of such protocols are FTP and IRC DCC. 369.Pp 370Return codes: 371.Bl -tag -width indent 372.It Dv PKT_ALIAS_OK 373The packet aliasing process was successful. 374.It Dv PKT_ALIAS_IGNORED 375The packet was ignored and not aliased. 376This can happen if the protocol is unrecognized, or possibly an ICMP message 377type is not handled. 378.It Dv PKT_ALIAS_ERROR 379An internal error within the packet aliasing engine occurred. 380.El 381.Ed 382.Sh PORT AND ADDRESS REDIRECTION 383The functions described in this section allow machines on the local network 384to be accessible in some degree to new incoming connections from the external 385network. 386Individual ports can be re-mapped or static network address translations can 387be designated. 388.Pp 389.Ft struct alias_link * 390.Fo LibAliasRedirectPort 391.Fa "struct libalias *" 392.Fa "struct in_addr local_addr" 393.Fa "u_short local_port" 394.Fa "struct in_addr remote_addr" 395.Fa "u_short remote_port" 396.Fa "struct in_addr alias_addr" 397.Fa "u_short alias_port" 398.Fa "u_char proto" 399.Fc 400.Bd -ragged -offset indent 401This function specifies that traffic from a given remote address/port to 402an alias address/port be redirected to a specified local address/port. 403The parameter 404.Fa proto 405can be either 406.Dv IPPROTO_TCP 407or 408.Dv IPPROTO_UDP , 409as defined in 410.In netinet/in.h . 411.Pp 412If 413.Fa local_addr 414or 415.Fa alias_addr 416is zero, this indicates that the packet aliasing address as established 417by 418.Fn LibAliasSetAddress 419is to be used. 420Even if 421.Fn LibAliasSetAddress 422is called to change the address after 423.Fn LibAliasRedirectPort 424is called, a zero reference will track this change. 425.Pp 426If the link is further set up to operate with load sharing, then 427.Fa local_addr 428and 429.Fa local_port 430are ignored, and are selected dynamically from the server pool, as described in 431.Fn LibAliasAddServer 432below. 433.Pp 434If 435.Fa remote_addr 436is zero, this indicates to redirect packets from any remote address. 437Likewise, if 438.Fa remote_port 439is zero, this indicates to redirect packets originating from any remote 440port number. 441The remote port specification will almost always be zero, but non-zero 442remote addresses can sometimes be useful for firewalling. 443If two calls to 444.Fn LibAliasRedirectPort 445overlap in their address/port specifications, then the most recent call 446will have precedence. 447.Pp 448This function returns a pointer which can subsequently be used by 449.Fn LibAliasRedirectDelete . 450If 451.Dv NULL 452is returned, then the function call did not complete successfully. 453.Pp 454All port numbers should be in network address byte order, so it is necessary 455to use 456.Xr htons 3 457to convert these parameters from internally readable numbers to network byte 458order. 459Addresses are also in network byte order, which is implicit in the use of the 460.Fa struct in_addr 461data type. 462.Ed 463.Pp 464.Ft struct alias_link * 465.Fo LibAliasRedirectAddr 466.Fa "struct libalias *" 467.Fa "struct in_addr local_addr" 468.Fa "struct in_addr alias_addr" 469.Fc 470.Bd -ragged -offset indent 471This function designates that all incoming traffic to 472.Fa alias_addr 473be redirected to 474.Fa local_addr . 475Similarly, all outgoing traffic from 476.Fa local_addr 477is aliased to 478.Fa alias_addr . 479.Pp 480If 481.Fa local_addr 482or 483.Fa alias_addr 484is zero, this indicates that the packet aliasing address as established by 485.Fn LibAliasSetAddress 486is to be used. 487Even if 488.Fn LibAliasSetAddress 489is called to change the address after 490.Fn LibAliasRedirectAddr 491is called, a zero reference will track this change. 492.Pp 493If the link is further set up to operate with load sharing, then the 494.Fa local_addr 495argument is ignored, and is selected dynamically from the server pool, 496as described in 497.Fn LibAliasAddServer 498below. 499.Pp 500If subsequent calls to 501.Fn LibAliasRedirectAddr 502use the same aliasing address, all new incoming traffic to this aliasing 503address will be redirected to the local address made in the last function 504call. 505New traffic generated by any of the local machines, designated in the 506several function calls, will be aliased to the same address. 507Consider the following example: 508.Pp 509LibAliasRedirectAddr(la, inet_aton("192.168.0.2"), 510 inet_aton("141.221.254.101")); 511LibAliasRedirectAddr(la, inet_aton("192.168.0.3"), 512 inet_aton("141.221.254.101")); 513LibAliasRedirectAddr(la, inet_aton("192.168.0.4"), 514 inet_aton("141.221.254.101")); 515.Pp 516Any outgoing connections such as 517.Xr telnet 1 518or 519.Xr ftp 1 520from 192.168.0.2, 192.168.0.3 and 192.168.0.4 will appear to come from 521141.221.254.101. 522Any incoming connections to 141.221.254.101 will be directed to 192.168.0.4. 523.Pp 524Any calls to 525.Fn LibAliasRedirectPort 526will have precedence over address mappings designated by 527.Fn LibAliasRedirectAddr . 528.Pp 529This function returns a pointer which can subsequently be used by 530.Fn LibAliasRedirectDelete . 531If 532.Dv NULL 533is returned, then the function call did not complete successfully. 534.Ed 535.Pp 536.Ft int 537.Fo LibAliasAddServer 538.Fa "struct libalias *" 539.Fa "struct alias_link *link" 540.Fa "struct in_addr addr" 541.Fa "u_short port" 542.Fc 543.Bd -ragged -offset indent 544This function sets the 545.Fa link 546up for Load Sharing using IP Network Address Translation (RFC 2391, LSNAT). 547LSNAT operates as follows. 548A client attempts to access a server by using the server virtual address. 549The LSNAT router transparently redirects the request to one of the hosts 550in the server pool, using a real-time load sharing algorithm. 551Multiple sessions may be initiated from the same client, and each session 552could be directed to a different host based on the load balance across server 553pool hosts when the sessions are initiated. 554If load sharing is desired for just a few specific services, the configuration 555on LSNAT could be defined to restrict load sharing to just the services 556desired. 557.Pp 558Currently, only the simplest selection algorithm is implemented, where a 559host is selected on a round-robin basis only, without regard to load on 560the host. 561.Pp 562First, the 563.Fa link 564is created by either 565.Fn LibAliasRedirectPort 566or 567.Fn LibAliasRedirectAddr . 568Then, 569.Fn LibAliasAddServer 570is called multiple times to add entries to the 571.Fa link Ns 's 572server pool. 573.Pp 574For links created with 575.Fn LibAliasRedirectAddr , 576the 577.Fa port 578argument is ignored and could have any value, e.g.\& htons(~0). 579.Pp 580This function returns 0 on success, \-1 otherwise. 581.Ed 582.Pp 583.Ft int 584.Fn LibAliasRedirectDynamic "struct libalias *" "struct alias_link *link" 585.Bd -ragged -offset indent 586This function marks the specified static redirect rule entered by 587.Fn LibAliasRedirectPort 588as dynamic. 589This can be used to e.g.\& dynamically redirect a single TCP connection, 590after which the rule is removed. 591Only fully specified links can be made dynamic. 592(See the 593.Sx STATIC AND DYNAMIC LINKS 594and 595.Sx PARTIALLY SPECIFIED ALIASING LINKS 596sections below for a definition of static vs.\& dynamic, 597and partially vs.\& fully specified links.) 598.Pp 599This function returns 0 on success, \-1 otherwise. 600.Ed 601.Pp 602.Ft void 603.Fn LibAliasRedirectDelete "struct libalias *" "struct alias_link *link" 604.Bd -ragged -offset indent 605This function will delete a specific static redirect rule entered by 606.Fn LibAliasRedirectPort 607or 608.Fn LibAliasRedirectAddr . 609The parameter 610.Fa link 611is the pointer returned by either of the redirection functions. 612If an invalid pointer is passed to 613.Fn LibAliasRedirectDelete , 614then a program crash or unpredictable operation could result, so 615care is needed when using this function. 616.Ed 617.Pp 618.Ft int 619.Fn LibAliasProxyRule "struct libalias *" "const char *cmd" 620.Bd -ragged -offset indent 621The passed 622.Fa cmd 623string consists of one or more pairs of words. 624The first word in each pair is a token and the second is the value that 625should be applied for that token. 626Tokens and their argument types are as follows: 627.Bl -tag -width indent 628.It Cm type encode_ip_hdr | encode_tcp_stream | no_encode 629In order to support transparent proxying, it is necessary to somehow 630pass the original address and port information into the new destination 631server. 632If 633.Cm encode_ip_hdr 634is specified, the original destination address and port are passed 635as an extra IP option. 636If 637.Cm encode_tcp_stream 638is specified, the original destination address and port are passed 639as the first piece of data in the TCP stream in the format 640.Dq Li DEST Ar IP port . 641.It Cm port Ar portnum 642Only packets with the destination port 643.Ar portnum 644are proxied. 645.It Cm server Ar host Ns Op : Ns Ar portnum 646This specifies the 647.Ar host 648and 649.Ar portnum 650that the data is to be redirected to. 651.Ar host 652must be an IP address rather than a DNS host name. 653If 654.Ar portnum 655is not specified, the destination port number is not changed. 656.Pp 657The 658.Ar server 659specification is mandatory unless the 660.Cm delete 661command is being used. 662.It Cm rule Ar index 663Normally, each call to 664.Fn LibAliasProxyRule 665inserts the next rule at the start of a linear list of rules. 666If an 667.Ar index 668is specified, the new rule will be checked after all rules with lower 669indices. 670Calls to 671.Fn LibAliasProxyRule 672that do not specify a rule are assigned rule 0. 673.It Cm delete Ar index 674This token and its argument MUST NOT be used with any other tokens. 675When used, all existing rules with the given 676.Ar index 677are deleted. 678.It Cm proto tcp | udp 679If specified, only packets of the given protocol type are matched. 680.It Cm src Ar IP Ns Op / Ns Ar bits 681If specified, only packets with a source address matching the given 682.Ar IP 683are matched. 684If 685.Ar bits 686is also specified, then the first 687.Ar bits 688bits of 689.Ar IP 690are taken as a network specification, and all IP addresses from that 691network will be matched. 692.It Cm dst Ar IP Ns Op / Ns Ar bits 693If specified, only packets with a destination address matching the given 694.Ar IP 695are matched. 696If 697.Ar bits 698is also specified, then the first 699.Ar bits 700bits of 701.Ar IP 702are taken as a network specification, and all IP addresses from that 703network will be matched. 704.El 705.Pp 706This function is usually used to redirect outgoing connections for 707internal machines that are not permitted certain types of internet 708access, or to restrict access to certain external machines. 709.Ed 710.Pp 711.Ft struct alias_link * 712.Fo LibAliasRedirectProto 713.Fa "struct libalias *" 714.Fa "struct in_addr local_addr" 715.Fa "struct in_addr remote_addr" 716.Fa "struct in_addr alias_addr" 717.Fa "u_char proto" 718.Fc 719.Bd -ragged -offset indent 720This function specifies that any IP packet with protocol number of 721.Fa proto 722from a given remote address to an alias address will be 723redirected to a specified local address. 724.Pp 725If 726.Fa local_addr 727or 728.Fa alias_addr 729is zero, this indicates that the packet aliasing address as established 730by 731.Fn LibAliasSetAddress 732is to be used. 733Even if 734.Fn LibAliasSetAddress 735is called to change the address after 736.Fn LibAliasRedirectProto 737is called, a zero reference will track this change. 738.Pp 739If 740.Fa remote_addr 741is zero, this indicates to redirect packets from any remote address. 742Non-zero remote addresses can sometimes be useful for firewalling. 743.Pp 744If two calls to 745.Fn LibAliasRedirectProto 746overlap in their address specifications, then the most recent call 747will have precedence. 748.Pp 749This function returns a pointer which can subsequently be used by 750.Fn LibAliasRedirectDelete . 751If 752.Dv NULL 753is returned, then the function call did not complete successfully. 754.Ed 755.Sh FRAGMENT HANDLING 756The functions in this section are used to deal with incoming fragments. 757.Pp 758Outgoing fragments are handled within 759.Fn LibAliasOut 760by changing the address according to any applicable mapping set by 761.Fn LibAliasRedirectAddr , 762or the default aliasing address set by 763.Fn LibAliasSetAddress . 764.Pp 765Incoming fragments are handled in one of two ways. 766If the header of a fragmented IP packet has already been seen, then all 767subsequent fragments will be re-mapped in the same manner the header 768fragment was. 769Fragments which arrive before the header are saved and then retrieved 770once the header fragment has been resolved. 771.Pp 772.Ft int 773.Fn LibAliasSaveFragment "struct libalias *" "char *ptr" 774.Bd -ragged -offset indent 775When 776.Fn LibAliasIn 777returns 778.Dv PKT_ALIAS_UNRESOLVED_FRAGMENT , 779this function can be used to save the pointer to the unresolved fragment. 780.Pp 781It is implicitly assumed that 782.Fa ptr 783points to a block of memory allocated by 784.Xr malloc 3 . 785If the fragment is never resolved, the packet aliasing engine will 786automatically free the memory after a timeout period. 787[Eventually this function should be modified so that a callback function 788for freeing memory is passed as an argument.] 789.Pp 790This function returns 791.Dv PKT_ALIAS_OK 792if it was successful and 793.Dv PKT_ALIAS_ERROR 794if there was an error. 795.Ed 796.Pp 797.Ft char * 798.Fn LibAliasGetFragment "struct libalias *" "char *buffer" 799.Bd -ragged -offset indent 800This function can be used to retrieve fragment pointers saved by 801.Fn LibAliasSaveFragment . 802The IP header fragment pointed to by 803.Fa buffer 804is the header fragment indicated when 805.Fn LibAliasIn 806returns 807.Dv PKT_ALIAS_FOUND_HEADER_FRAGMENT . 808Once a fragment pointer is retrieved, it becomes the calling program's 809responsibility to free the dynamically allocated memory for the fragment. 810.Pp 811The 812.Fn LibAliasGetFragment 813function can be called sequentially until there are no more fragments 814available, at which time it returns 815.Dv NULL . 816.Ed 817.Pp 818.Ft void 819.Fn LibAliasFragmentIn "struct libalias *" "char *header" "char *fragment" 820.Bd -ragged -offset indent 821When a fragment is retrieved with 822.Fn LibAliasGetFragment , 823it can then be de-aliased with a call to 824.Fn LibAliasFragmentIn . 825The 826.Fa header 827argument is the pointer to a header fragment used as a template, and 828.Fa fragment 829is the pointer to the packet to be de-aliased. 830.Ed 831.Sh MISCELLANEOUS FUNCTIONS 832.Ft struct alias_link * 833.Fn AddLink "struct libalias *" "struct in_addr src_addr" "struct in_addr dst_addr" \ 834"struct in_addr alias_addr" "u_short src_port" "u_short dst_port" \ 835"int alias_param" "int link_type" 836.Bd -ragged -offset indent 837This function adds new state to the instance hash table. 838The dst_address and/or dst_port may be given as zero, which 839introduces some dynamic character into the link, since 840LibAliasSetAddress can change the address that is used. 841However, in the current implementation, such links can only be used 842for inbound (ext -> int) traffic. 843.Ed 844.Pp 845.Ft void 846.Fn LibAliasSetTarget "struct libalias *" "struct in_addr addr" 847.Bd -ragged -offset indent 848When an incoming packet not associated with any pre-existing aliasing link 849arrives at the host machine, it will be sent to the address indicated by a 850call to 851.Fn LibAliasSetTarget . 852.Pp 853If this function is called with an 854.Dv INADDR_NONE 855address argument, then all new incoming packets go to the address set by 856.Fn LibAliasSetAddress . 857.Pp 858If this function is not called, or is called with an 859.Dv INADDR_ANY 860address argument, then all new incoming packets go to the address specified 861in the packet. 862This allows external machines to talk directly to internal machines if they 863can route packets to the machine in question. 864.Ed 865.Pp 866.Ft int 867.Fn LibAliasCheckNewLink "struct libalias *" 868.Bd -ragged -offset indent 869This function returns a non-zero value when a new aliasing link is created. 870In circumstances where incoming traffic is being sequentially sent to 871different local servers, this function can be used to trigger when 872.Fn LibAliasSetTarget 873is called to change the default target address. 874.Ed 875.Pp 876.Ft u_short 877.Fn LibAliasInternetChecksum "struct libalias *" "u_short *buffer" "int nbytes" 878.Bd -ragged -offset indent 879This is a utility function that does not seem to be available elsewhere and 880is included as a convenience. 881It computes the internet checksum, which is used in both IP and 882protocol-specific headers (TCP, UDP, ICMP). 883.Pp 884The 885.Fa buffer 886argument points to the data block to be checksummed, and 887.Fa nbytes 888is the number of bytes. 889The 16-bit checksum field should be zeroed before computing the checksum. 890.Pp 891Checksums can also be verified by operating on a block of data including 892its checksum. 893If the checksum is valid, 894.Fn LibAliasInternetChecksum 895will return zero. 896.Ed 897.Pp 898.Ft int 899.Fn LibAliasUnaliasOut "struct libalias *" "char *buffer" "int maxpacketsize" 900.Bd -ragged -offset indent 901An outgoing packet, which has already been aliased, 902has its private address/port information restored by this function. 903The IP packet is pointed to by 904.Fa buffer , 905and 906.Fa maxpacketsize 907is provided for error checking purposes. 908This function can be used if an already-aliased packet needs to have its 909original IP header restored for further processing (e.g.\& logging). 910.Ed 911.Sh CONCEPTUAL BACKGROUND 912This section is intended for those who are planning to modify the source 913code or want to create somewhat esoteric applications using the packet 914aliasing functions. 915.Pp 916The conceptual framework under which the packet aliasing engine operates 917is described here. 918Central to the discussion is the idea of an 919.Em aliasing link 920which describes the relationship for a given packet transaction between 921the local machine, aliased identity and remote machine. 922It is discussed how such links come into existence and are destroyed. 923.Ss ALIASING LINKS 924There is a notion of an 925.Em aliasing link , 926which is a 7-tuple describing a specific translation: 927.Bd -literal -offset indent 928(local addr, local port, alias addr, alias port, 929 remote addr, remote port, protocol) 930.Ed 931.Pp 932Outgoing packets have the local address and port number replaced with the 933alias address and port number. 934Incoming packets undergo the reverse process. 935The packet aliasing engine attempts to match packets against an internal 936table of aliasing links to determine how to modify a given IP packet. 937Both the IP header and protocol dependent headers are modified as necessary. 938Aliasing links are created and deleted as necessary according to network 939traffic. 940.Pp 941Protocols can be TCP, UDP or even ICMP in certain circumstances. 942(Some types of ICMP packets can be aliased according to sequence or ID 943number which acts as an equivalent port number for identifying how 944individual packets should be handled.) 945.Pp 946Each aliasing link must have a unique combination of the following five 947quantities: alias address/port, remote address/port and protocol. 948This ensures that several machines on a local network can share the 949same aliasing IP address. 950In cases where conflicts might arise, the aliasing port is chosen so that 951uniqueness is maintained. 952.Ss STATIC AND DYNAMIC LINKS 953Aliasing links can either be static or dynamic. 954Static links persist indefinitely and represent fixed rules for translating 955IP packets. 956Dynamic links come into existence for a specific TCP connection or UDP 957transaction or ICMP ECHO sequence. 958For the case of TCP, the connection can be monitored to see when the 959associated aliasing link should be deleted. 960Aliasing links for UDP transactions (and ICMP ECHO and TIMESTAMP requests) 961work on a simple timeout rule. 962When no activity is observed on a dynamic link for a certain amount of time 963it is automatically deleted. 964Timeout rules also apply to TCP connections which do not open or close 965properly. 966.Ss PARTIALLY SPECIFIED ALIASING LINKS 967Aliasing links can be partially specified, meaning that the remote address 968and/or remote port are unknown. 969In this case, when a packet matching the incomplete specification is found, 970a fully specified dynamic link is created. 971If the original partially specified link is dynamic, it will be deleted 972after the fully specified link is created, otherwise it will persist. 973.Pp 974For instance, a partially specified link might be 975.Bd -literal -offset indent 976(192.168.0.4, 23, 204.228.203.215, 8066, 0, 0, tcp) 977.Ed 978.Pp 979The zeros denote unspecified components for the remote address and port. 980If this link were static it would have the effect of redirecting all 981incoming traffic from port 8066 of 204.228.203.215 to port 23 (telnet) 982of machine 192.168.0.4 on the local network. 983Each individual telnet connection would initiate the creation of a distinct 984dynamic link. 985.Ss DYNAMIC LINK CREATION 986In addition to aliasing links, there are also address mappings that can be 987stored within the internal data table of the packet aliasing mechanism. 988.Bd -literal -offset indent 989(local addr, alias addr) 990.Ed 991.Pp 992Address mappings are searched when creating new dynamic links. 993.Pp 994All outgoing packets from the local network automatically create a dynamic 995link if they do not match an already existing fully specified link. 996If an address mapping exists for the outgoing packet, this determines 997the alias address to be used. 998If no mapping exists, then a default address, usually the address of the 999packet aliasing host, is used. 1000If necessary, this default address can be changed as often as each individual 1001packet arrives. 1002.Pp 1003The aliasing port number is determined such that the new dynamic link does 1004not conflict with any existing links. 1005In the default operating mode, the packet aliasing engine attempts to set 1006the aliasing port equal to the local port number. 1007If this results in a conflict, then port numbers are randomly chosen until 1008a unique aliasing link can be established. 1009In an alternate operating mode, the first choice of an aliasing port is also 1010random and unrelated to the local port number. 1011.Sh MODULAR ARCHITECTURE Po AND Xr ipfw 4 SUPPORT Pc 1012One of the latest improvements to 1013.Nm 1014was to make its support 1015for new protocols independent from the rest of the library, giving it 1016the ability to load/unload support for new protocols at run-time. 1017To achieve this feature, all the code for protocol handling was moved 1018to a series of modules outside of the main library. 1019These modules are compiled from the same sources but work in 1020different ways, depending on whether they are compiled to work inside a kernel 1021or as part of the userland library. 1022.Ss LIBALIAS MODULES IN KERNEL LAND 1023When compiled for the kernel, 1024.Nm 1025modules are plain KLDs recognizable with the 1026.Pa alias_ 1027prefix. 1028.Pp 1029To add support for a new protocol, load the corresponding module. 1030For example: 1031.Pp 1032.Dl "kldload alias_ftp" 1033.Pp 1034When support for a protocol is no longer needed, its module can be unloaded: 1035.Pp 1036.Dl "kldunload alias_ftp" 1037.Ss LIBALIAS MODULES IN USERLAND 1038Due to the differences between kernel and userland (no KLD mechanism, 1039many different address spaces, etc.), we had to change a bit how to 1040handle module loading/tracking/unloading in userland. 1041.Pp 1042While compiled for a userland 1043.Nm , 1044all the modules are plain libraries, residing in 1045.Pa /usr/lib , 1046and recognizable with the 1047.Pa libalias_ 1048prefix. 1049.Pp 1050There is a configuration file, 1051.Pa /etc/libalias.conf , 1052with the following contents (by default): 1053.Bd -literal -offset indent 1054/usr/lib/libalias_ftp.so 1055/usr/lib/libalias_irc.so 1056/usr/lib/libalias_nbt.so 1057/usr/lib/libalias_pptp.so 1058/usr/lib/libalias_skinny.so 1059/usr/lib/libalias_smedia.so 1060.Ed 1061.Pp 1062This file contains the paths to the modules that 1063.Nm 1064will load. 1065To load/unload a new module, just add its path to 1066.Pa libalias.conf 1067and call 1068.Fn LibAliasRefreshModules 1069from the program. 1070In case the application provides a 1071.Dv SIGHUP 1072signal handler, add a call to 1073.Fn LibAliasRefreshModules 1074inside the handler, and every time you want to refresh the loaded modules, 1075send it the 1076.Dv SIGHUP 1077signal: 1078.Pp 1079.Dl "kill -HUP <process_pid>" 1080.Ss MODULAR ARCHITECURE: HOW IT WORKS 1081The modular architecture of 1082.Nm 1083works similar whether it is running inside the 1084kernel or in userland. 1085From 1086.Pa alias_mod.c : 1087.Bd -literal 1088/* Protocol and userland module handlers chains. */ 1089LIST_HEAD(handler_chain, proto_handler) handler_chain ... 1090\&... 1091SLIST_HEAD(dll_chain, dll) dll_chain ... 1092.Ed 1093.Pp 1094.Va handler_chain 1095keeps track of all the protocol handlers loaded, while 1096.Va ddl_chain 1097tracks which userland modules are loaded. 1098.Pp 1099.Va handler_chain 1100is composed of 1101.Vt "struct proto_handler" 1102entries: 1103.Bd -literal 1104struct proto_handler { 1105 u_int pri; 1106 int16_t dir; 1107 uint8_t proto; 1108 int (*fingerprint)(struct libalias *la, 1109 struct ip *pip, struct alias_data *ah); 1110 int (*protohandler)(struct libalias *la, 1111 struct ip *pip, struct alias_data *ah); 1112 TAILQ_ENTRY(proto_handler) link; 1113}; 1114.Ed 1115.Pp 1116where: 1117.Bl -inset 1118.It Va pri 1119is the priority assigned to a protocol handler; lower priority 1120is better. 1121.It Va dir 1122is the direction of packets: ingoing or outgoing. 1123.It Va proto 1124indicates to which protocol this packet belongs: IP, TCP or UDP. 1125.It Va fingerprint 1126points to the fingerprint function while protohandler points 1127to the protocol handler function. 1128.El 1129.Pp 1130The 1131.Va fingerprint 1132function has the dual role of checking if the 1133incoming packet is found, and if it belongs to any categories that this 1134module can handle. 1135.Pp 1136The 1137.Va protohandler 1138function actually manipulates 1139the packet to make 1140.Nm 1141correctly NAT it. 1142.Pp 1143When a packet enters 1144.Nm , 1145if it meets a module hook, 1146.Va handler_chain 1147is searched to see if there is an handler that matches 1148this type of a packet (it checks protocol and direction of packet). 1149Then, if more than one handler is found, it starts with the module with 1150the lowest priority number: it calls the 1151.Va fingerprint 1152function and interprets the result. 1153.Pp 1154If the result value is equal to 0 then it calls the protocol handler 1155of this handler and returns. 1156Otherwise, it proceeds to the next eligible module until the 1157.Va handler_chain 1158is exhausted. 1159.Pp 1160Inside 1161.Nm , 1162the module hook looks like this: 1163.Bd -literal -offset indent 1164struct alias_data ad = { 1165 lnk, 1166 &original_address, 1167 &alias_address, 1168 &alias_port, 1169 &ud->uh_sport, /* original source port */ 1170 &ud->uh_dport, /* original dest port */ 1171 256 /* maxpacketsize */ 1172}; 1173 1174\&... 1175 1176/* walk out chain */ 1177err = find_handler(IN, UDP, la, pip, &ad); 1178.Ed 1179.Pp 1180All data useful to a module are gathered together in an 1181.Vt alias_data 1182structure, then 1183.Fn find_handler 1184is called. 1185The 1186.Fn find_handler 1187function is responsible for walking the handler 1188chain; it receives as input parameters: 1189.Bl -tag -width indent 1190.It Fa IN 1191direction 1192.It Fa UDP 1193working protocol 1194.It Fa la 1195pointer to this instance of libalias 1196.It Fa pip 1197pointer to a 1198.Vt "struct ip" 1199.It Fa ad 1200pointer to 1201.Vt "struct alias_data" 1202(see above) 1203.El 1204.Pp 1205In this case, 1206.Fn find_handler 1207will search only for modules registered for 1208supporting INcoming UDP packets. 1209.Pp 1210As was mentioned earlier, 1211.Nm 1212in userland is a bit different, as 1213care must be taken in module handling as well (avoiding duplicate load of 1214modules, avoiding modules with same name, etc.) so 1215.Va dll_chain 1216was introduced. 1217.Pp 1218.Va dll_chain 1219contains a list of all userland 1220.Nm 1221modules loaded. 1222.Pp 1223When an application calls 1224.Fn LibAliasRefreshModules , 1225.Nm 1226first unloads all the loaded modules, then reloads all the modules listed in 1227.Pa /etc/libalias.conf : 1228for every module loaded, a new entry is added to 1229.Va dll_chain . 1230.Pp 1231.Va dll_chain 1232is composed of 1233.Vt "struct dll" 1234entries: 1235.Bd -literal 1236struct dll { 1237 /* name of module */ 1238 char name[DLL_LEN]; 1239 /* 1240 * ptr to shared obj obtained through 1241 * dlopen() - use this ptr to get access 1242 * to any symbols from a loaded module 1243 * via dlsym() 1244 */ 1245 void *handle; 1246 struct dll *next; 1247}; 1248.Ed 1249.Bl -inset 1250.It Va name 1251is the name of the module. 1252.It Va handle 1253is a pointer to the module obtained through 1254.Xr dlopen 3 . 1255.El 1256Whenever a module is loaded in userland, an entry is added to 1257.Va dll_chain , 1258then every protocol handler present in that module 1259is resolved and registered in 1260.Va handler_chain . 1261.Ss HOW TO WRITE A MODULE FOR LIBALIAS 1262There is a module (called 1263.Pa alias_dummy.[ch] ) 1264in 1265.Nm 1266that can be used as a skeleton for future work. 1267Here we analyse some parts of that module. 1268From 1269.Pa alias_dummy.c : 1270.Bd -literal 1271struct proto_handler handlers[] = { 1272 { 1273 .pri = 666, 1274 .dir = IN|OUT, 1275 .proto = UDP|TCP, 1276 .fingerprint = fingerprint, 1277 .protohandler= protohandler, 1278 }, 1279 { EOH } 1280}; 1281.Ed 1282.Pp 1283The variable 1284.Va handlers 1285is the 1286.Dq "most important thing" 1287in a module 1288since it describes the handlers present and lets the outside world use 1289it in an opaque way. 1290.Pp 1291It must ALWAYS be present in every module, and it MUST retain 1292the name 1293.Va handlers , 1294otherwise attempting to load a module in userland will fail and 1295complain about missing symbols: for more information about module 1296load/unload, please refer to 1297.Fn LibAliasRefreshModules , 1298.Fn LibAliasLoadModule 1299and 1300.Fn LibAliasUnloadModule 1301in 1302.Pa alias.c . 1303.Pp 1304.Va handlers 1305contains all the 1306.Vt proto_handler 1307structures present in a module. 1308.Bd -literal 1309static int 1310mod_handler(module_t mod, int type, void *data) 1311{ 1312 int error; 1313 1314 switch (type) { 1315 case MOD_LOAD: 1316 error = LibAliasAttachHandlers(handlers); 1317 break; 1318 case MOD_UNLOAD: 1319 error = LibAliasDetachHandlers(handlers); 1320 break; 1321 default: 1322 error = EINVAL; 1323 } 1324 return (error); 1325} 1326.Ed 1327When running as KLD, 1328.Fn mod_handler 1329registers/deregisters the module using 1330.Fn LibAliasAttachHandlers 1331and 1332.Fn LibAliasDetachHandlers , 1333respectively. 1334.Pp 1335Every module must contain at least 2 functions: one fingerprint 1336function and a protocol handler function. 1337.Bd -literal 1338#ifdef _KERNEL 1339static 1340#endif 1341int 1342fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) 1343{ 1344 1345\&... 1346} 1347 1348#ifdef _KERNEL 1349static 1350#endif 1351int 1352protohandler(struct libalias *la, struct ip *pip, 1353 struct alias_data *ah) 1354{ 1355 1356\&... 1357} 1358.Ed 1359and they must accept exactly these input parameters. 1360.Ss PATCHING AN APPLICATION FOR USERLAND LIBALIAS MODULES 1361To add module support into an application that uses 1362.Nm , 1363the following simple steps can be followed. 1364.Bl -enum 1365.It 1366Find the main file of an application 1367(let us call it 1368.Pa main.c ) . 1369.It 1370Add this to the header section of 1371.Pa main.c , 1372if not already present: 1373.Pp 1374.Dl "#include <signal.h>" 1375.Pp 1376and this just after the header section: 1377.Pp 1378.Dl "static void signal_handler(int);" 1379.It 1380Add the following line to the init function of an application or, 1381if it does not have any init function, put it in 1382.Fn main : 1383.Pp 1384.Dl "signal(SIGHUP, signal_handler);" 1385.Pp 1386and place the 1387.Fn signal_handler 1388function somewhere in 1389.Pa main.c : 1390.Bd -literal -offset indent 1391static void 1392signal_handler(int sig) 1393{ 1394 1395 LibAliasRefreshModules(); 1396} 1397.Ed 1398.Pp 1399Otherwise, if an application already traps the 1400.Dv SIGHUP 1401signal, just add a call to 1402.Fn LibAliasRefreshModules 1403in the signal handler function. 1404.El 1405For example, to patch 1406.Xr natd 8 1407to use 1408.Nm 1409modules, just add the following line to 1410.Fn RefreshAddr "int sig __unused" : 1411.Pp 1412.Dl "LibAliasRefreshModules()" 1413.Pp 1414recompile and you are done. 1415.Ss LOGGING SUPPORT IN KERNEL LAND 1416When working as KLD, 1417.Nm 1418now has log support that 1419happens on a buffer allocated inside 1420.Vt "struct libalias" 1421(from 1422.Pa alias_local.h ) : 1423.Bd -literal 1424struct libalias { 1425 ... 1426 1427 /* log descriptor */ 1428#ifdef KERNEL_LOG 1429 char *logDesc; /* 1430 * ptr to an auto-malloced 1431 * memory buffer when libalias 1432 * works as kld 1433 */ 1434#else 1435 FILE *logDesc; /* 1436 * ptr to /var/log/alias.log 1437 * when libalias runs as a 1438 * userland lib 1439 */ 1440#endif 1441 1442 ... 1443} 1444.Ed 1445so all applications using 1446.Nm 1447will be able to handle their 1448own logs, if they want, accessing 1449.Va logDesc . 1450Moreover, every change to a log buffer is automatically added to 1451.Xr syslog 3 1452with the 1453.Dv LOG_SECURITY 1454facility and the 1455.Dv LOG_INFO 1456level. 1457.Sh AUTHORS 1458.An Charles Mott Aq cm@linktel.net , 1459versions 1.0 - 1.8, 2.0 - 2.4. 1460.An Eivind Eklund Aq eivind@FreeBSD.org , 1461versions 1.8b, 1.9 and 2.5. 1462Added IRC DCC support as well as contributing a number of architectural 1463improvements; added the firewall bypass for FTP/IRC DCC. 1464.An Erik Salander Aq erik@whistle.com 1465added support for PPTP and RTSP. 1466.An Junichi Satoh Aq junichi@junichi.org 1467added support for RTSP/PNA. 1468.An Ruslan Ermilov Aq ru@FreeBSD.org 1469added support for PPTP and LSNAT as well as general hacking. 1470.An Gleb Smirnoff Aq glebius@FreeBSD.org 1471ported the library to kernel space. 1472.An Paolo Pisati Aq piso@FreeBSD.org 1473made the library modular, moving support for all 1474protocols (except for IP, TCP and UDP) to external modules. 1475.Sh ACKNOWLEDGEMENTS 1476Listed below, in approximate chronological order, are individuals who 1477have provided valuable comments and/or debugging assistance. 1478.Bd -ragged -offset indent 1479.An -split 1480.An Gary Roberts 1481.An Tom Torrance 1482.An Reto Burkhalter 1483.An Martin Renters 1484.An Brian Somers 1485.An Paul Traina 1486.An Ari Suutari 1487.An Dave Remien 1488.An J. Fortes 1489.An Andrzej Bialecki 1490.An Gordon Burditt 1491.Ed 1492