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_cuseeme.so 1055/usr/lib/libalias_ftp.so 1056/usr/lib/libalias_irc.so 1057/usr/lib/libalias_nbt.so 1058/usr/lib/libalias_pptp.so 1059/usr/lib/libalias_skinny.so 1060/usr/lib/libalias_smedia.so 1061.Ed 1062.Pp 1063This file contains the paths to the modules that 1064.Nm 1065will load. 1066To load/unload a new module, just add its path to 1067.Pa libalias.conf 1068and call 1069.Fn LibAliasRefreshModules 1070from the program. 1071In case the application provides a 1072.Dv SIGHUP 1073signal handler, add a call to 1074.Fn LibAliasRefreshModules 1075inside the handler, and every time you want to refresh the loaded modules, 1076send it the 1077.Dv SIGHUP 1078signal: 1079.Pp 1080.Dl "kill -HUP <process_pid>" 1081.Ss MODULAR ARCHITECURE: HOW IT WORKS 1082The modular architecture of 1083.Nm 1084works similar whether it is running inside the 1085kernel or in userland. 1086From 1087.Pa alias_mod.c : 1088.Bd -literal 1089/* Protocol and userland module handlers chains. */ 1090LIST_HEAD(handler_chain, proto_handler) handler_chain ... 1091\&... 1092SLIST_HEAD(dll_chain, dll) dll_chain ... 1093.Ed 1094.Pp 1095.Va handler_chain 1096keeps track of all the protocol handlers loaded, while 1097.Va ddl_chain 1098tracks which userland modules are loaded. 1099.Pp 1100.Va handler_chain 1101is composed of 1102.Vt "struct proto_handler" 1103entries: 1104.Bd -literal 1105struct proto_handler { 1106 u_int pri; 1107 int16_t dir; 1108 uint8_t proto; 1109 int (*fingerprint)(struct libalias *la, 1110 struct ip *pip, struct alias_data *ah); 1111 int (*protohandler)(struct libalias *la, 1112 struct ip *pip, struct alias_data *ah); 1113 TAILQ_ENTRY(proto_handler) link; 1114}; 1115.Ed 1116.Pp 1117where: 1118.Bl -inset 1119.It Va pri 1120is the priority assigned to a protocol handler; lower priority 1121is better. 1122.It Va dir 1123is the direction of packets: ingoing or outgoing. 1124.It Va proto 1125indicates to which protocol this packet belongs: IP, TCP or UDP. 1126.It Va fingerprint 1127points to the fingerprint function while protohandler points 1128to the protocol handler function. 1129.El 1130.Pp 1131The 1132.Va fingerprint 1133function has the dual role of checking if the 1134incoming packet is found, and if it belongs to any categories that this 1135module can handle. 1136.Pp 1137The 1138.Va protohandler 1139function actually manipulates 1140the packet to make 1141.Nm 1142correctly NAT it. 1143.Pp 1144When a packet enters 1145.Nm , 1146if it meets a module hook, 1147.Va handler_chain 1148is searched to see if there is an handler that matches 1149this type of a packet (it checks protocol and direction of packet). 1150Then, if more than one handler is found, it starts with the module with 1151the lowest priority number: it calls the 1152.Va fingerprint 1153function and interprets the result. 1154.Pp 1155If the result value is equal to 0 then it calls the protocol handler 1156of this handler and returns. 1157Otherwise, it proceeds to the next eligible module until the 1158.Va handler_chain 1159is exhausted. 1160.Pp 1161Inside 1162.Nm , 1163the module hook looks like this: 1164.Bd -literal -offset indent 1165struct alias_data ad = { 1166 lnk, 1167 &original_address, 1168 &alias_address, 1169 &alias_port, 1170 &ud->uh_sport, /* original source port */ 1171 &ud->uh_dport, /* original dest port */ 1172 256 /* maxpacketsize */ 1173}; 1174 1175\&... 1176 1177/* walk out chain */ 1178err = find_handler(IN, UDP, la, pip, &ad); 1179.Ed 1180.Pp 1181All data useful to a module are gathered together in an 1182.Vt alias_data 1183structure, then 1184.Fn find_handler 1185is called. 1186The 1187.Fn find_handler 1188function is responsible for walking the handler 1189chain; it receives as input parameters: 1190.Bl -tag -width indent 1191.It Fa IN 1192direction 1193.It Fa UDP 1194working protocol 1195.It Fa la 1196pointer to this instance of libalias 1197.It Fa pip 1198pointer to a 1199.Vt "struct ip" 1200.It Fa ad 1201pointer to 1202.Vt "struct alias_data" 1203(see above) 1204.El 1205.Pp 1206In this case, 1207.Fn find_handler 1208will search only for modules registered for 1209supporting INcoming UDP packets. 1210.Pp 1211As was mentioned earlier, 1212.Nm 1213in userland is a bit different, as 1214care must be taken in module handling as well (avoiding duplicate load of 1215modules, avoiding modules with same name, etc.) so 1216.Va dll_chain 1217was introduced. 1218.Pp 1219.Va dll_chain 1220contains a list of all userland 1221.Nm 1222modules loaded. 1223.Pp 1224When an application calls 1225.Fn LibAliasRefreshModules , 1226.Nm 1227first unloads all the loaded modules, then reloads all the modules listed in 1228.Pa /etc/libalias.conf : 1229for every module loaded, a new entry is added to 1230.Va dll_chain . 1231.Pp 1232.Va dll_chain 1233is composed of 1234.Vt "struct dll" 1235entries: 1236.Bd -literal 1237struct dll { 1238 /* name of module */ 1239 char name[DLL_LEN]; 1240 /* 1241 * ptr to shared obj obtained through 1242 * dlopen() - use this ptr to get access 1243 * to any symbols from a loaded module 1244 * via dlsym() 1245 */ 1246 void *handle; 1247 struct dll *next; 1248}; 1249.Ed 1250.Bl -inset 1251.It Va name 1252is the name of the module. 1253.It Va handle 1254is a pointer to the module obtained through 1255.Xr dlopen 3 . 1256.El 1257Whenever a module is loaded in userland, an entry is added to 1258.Va dll_chain , 1259then every protocol handler present in that module 1260is resolved and registered in 1261.Va handler_chain . 1262.Ss HOW TO WRITE A MODULE FOR LIBALIAS 1263There is a module (called 1264.Pa alias_dummy.[ch] ) 1265in 1266.Nm 1267that can be used as a skeleton for future work. 1268Here we analyse some parts of that module. 1269From 1270.Pa alias_dummy.c : 1271.Bd -literal 1272struct proto_handler handlers[] = { 1273 { 1274 .pri = 666, 1275 .dir = IN|OUT, 1276 .proto = UDP|TCP, 1277 .fingerprint = fingerprint, 1278 .protohandler= protohandler, 1279 }, 1280 { EOH } 1281}; 1282.Ed 1283.Pp 1284The variable 1285.Va handlers 1286is the 1287.Dq "most important thing" 1288in a module 1289since it describes the handlers present and lets the outside world use 1290it in an opaque way. 1291.Pp 1292It must ALWAYS be present in every module, and it MUST retain 1293the name 1294.Va handlers , 1295otherwise attempting to load a module in userland will fail and 1296complain about missing symbols: for more information about module 1297load/unload, please refer to 1298.Fn LibAliasRefreshModules , 1299.Fn LibAliasLoadModule 1300and 1301.Fn LibAliasUnloadModule 1302in 1303.Pa alias.c . 1304.Pp 1305.Va handlers 1306contains all the 1307.Vt proto_handler 1308structures present in a module. 1309.Bd -literal 1310static int 1311mod_handler(module_t mod, int type, void *data) 1312{ 1313 int error; 1314 1315 switch (type) { 1316 case MOD_LOAD: 1317 error = LibAliasAttachHandlers(handlers); 1318 break; 1319 case MOD_UNLOAD: 1320 error = LibAliasDetachHandlers(handlers); 1321 break; 1322 default: 1323 error = EINVAL; 1324 } 1325 return (error); 1326} 1327.Ed 1328When running as KLD, 1329.Fn mod_handler 1330registers/deregisters the module using 1331.Fn LibAliasAttachHandlers 1332and 1333.Fn LibAliasDetachHandlers , 1334respectively. 1335.Pp 1336Every module must contain at least 2 functions: one fingerprint 1337function and a protocol handler function. 1338.Bd -literal 1339#ifdef _KERNEL 1340static 1341#endif 1342int 1343fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) 1344{ 1345 1346\&... 1347} 1348 1349#ifdef _KERNEL 1350static 1351#endif 1352int 1353protohandler(struct libalias *la, struct ip *pip, 1354 struct alias_data *ah) 1355{ 1356 1357\&... 1358} 1359.Ed 1360and they must accept exactly these input parameters. 1361.Ss PATCHING AN APPLICATION FOR USERLAND LIBALIAS MODULES 1362To add module support into an application that uses 1363.Nm , 1364the following simple steps can be followed. 1365.Bl -enum 1366.It 1367Find the main file of an application 1368(let us call it 1369.Pa main.c ) . 1370.It 1371Add this to the header section of 1372.Pa main.c , 1373if not already present: 1374.Pp 1375.Dl "#include <signal.h>" 1376.Pp 1377and this just after the header section: 1378.Pp 1379.Dl "static void signal_handler(int);" 1380.It 1381Add the following line to the init function of an application or, 1382if it does not have any init function, put it in 1383.Fn main : 1384.Pp 1385.Dl "signal(SIGHUP, signal_handler);" 1386.Pp 1387and place the 1388.Fn signal_handler 1389function somewhere in 1390.Pa main.c : 1391.Bd -literal -offset indent 1392static void 1393signal_handler(int sig) 1394{ 1395 1396 LibAliasRefreshModules(); 1397} 1398.Ed 1399.Pp 1400Otherwise, if an application already traps the 1401.Dv SIGHUP 1402signal, just add a call to 1403.Fn LibAliasRefreshModules 1404in the signal handler function. 1405.El 1406For example, to patch 1407.Xr natd 8 1408to use 1409.Nm 1410modules, just add the following line to 1411.Fn RefreshAddr "int sig __unused" : 1412.Pp 1413.Dl "LibAliasRefreshModules()" 1414.Pp 1415recompile and you are done. 1416.Ss LOGGING SUPPORT IN KERNEL LAND 1417When working as KLD, 1418.Nm 1419now has log support that 1420happens on a buffer allocated inside 1421.Vt "struct libalias" 1422(from 1423.Pa alias_local.h ) : 1424.Bd -literal 1425struct libalias { 1426 ... 1427 1428 /* log descriptor */ 1429#ifdef KERNEL_LOG 1430 char *logDesc; /* 1431 * ptr to an auto-malloced 1432 * memory buffer when libalias 1433 * works as kld 1434 */ 1435#else 1436 FILE *logDesc; /* 1437 * ptr to /var/log/alias.log 1438 * when libalias runs as a 1439 * userland lib 1440 */ 1441#endif 1442 1443 ... 1444} 1445.Ed 1446so all applications using 1447.Nm 1448will be able to handle their 1449own logs, if they want, accessing 1450.Va logDesc . 1451Moreover, every change to a log buffer is automatically added to 1452.Xr syslog 3 1453with the 1454.Dv LOG_SECURITY 1455facility and the 1456.Dv LOG_INFO 1457level. 1458.Sh AUTHORS 1459.An Charles Mott Aq cm@linktel.net , 1460versions 1.0 - 1.8, 2.0 - 2.4. 1461.An Eivind Eklund Aq eivind@FreeBSD.org , 1462versions 1.8b, 1.9 and 2.5. 1463Added IRC DCC support as well as contributing a number of architectural 1464improvements; added the firewall bypass for FTP/IRC DCC. 1465.An Erik Salander Aq erik@whistle.com 1466added support for PPTP and RTSP. 1467.An Junichi Satoh Aq junichi@junichi.org 1468added support for RTSP/PNA. 1469.An Ruslan Ermilov Aq ru@FreeBSD.org 1470added support for PPTP and LSNAT as well as general hacking. 1471.An Gleb Smirnoff Aq glebius@FreeBSD.org 1472ported the library to kernel space. 1473.An Paolo Pisati Aq piso@FreeBSD.org 1474made the library modular, moving support for all 1475protocols (except for IP, TCP and UDP) to external modules. 1476.Sh ACKNOWLEDGEMENTS 1477Listed below, in approximate chronological order, are individuals who 1478have provided valuable comments and/or debugging assistance. 1479.Bd -ragged -offset indent 1480.An -split 1481.An Gary Roberts 1482.An Tom Torrance 1483.An Reto Burkhalter 1484.An Martin Renters 1485.An Brian Somers 1486.An Paul Traina 1487.An Ari Suutari 1488.An Dave Remien 1489.An J. Fortes 1490.An Andrzej Bialecki 1491.An Gordon Burditt 1492.Ed 1493