1 '\" te
   2 .\" Copyright (C) 2012, Darren Reed. All rights reserved 
   3 .\" Copyright (C) 2009, Sun Microsystems, Inc. All Rights Reserved
   4 .\" Copyright 1989 AT&T
   5 .\" Copyright (c) 1983 Regents of the University of California. All rights reserved. The Berkeley software License Agreement specifies the terms and conditions for redistribution.
   6 .TH IFCONFIG 1M "July 23, 2012"
   7 .SH NAME
   8 ifconfig \- configure network interface parameters
   9 .SH SYNOPSIS
  10 .LP
  11 .nf
  12 \fBifconfig\fR \fIinterface\fR [\fIaddress_family\fR] [\fIaddress\fR [\fI/prefix_length\fR]
  13  [\fIdest_address\fR]] [\fBaddif\fR \fIaddress\fR [\fI/prefix_length\fR]]
  14  [\fBremoveif\fR \fIaddress\fR [\fI/prefix_length\fR]] [\fBarp\fR | \fB-arp\fR]
  15  [\fBauth_algs\fR \fIauthentication algorithm\fR] [\fBencr_algs\fR \fIencryption algorithm\fR]
  16  [\fBencr_auth_algs\fR \fIauthentication algorithm\fR] [\fBauto-revarp\fR]
  17  [\fBbroadcast\fR \fIaddress\fR] [\fBdeprecated\fR | \fB-deprecated\fR]
  18  [\fBpreferred\fR | \fB-preferred\fR] [\fBdestination\fR \fIdest_address\fR]
  19  [ether [\fIaddress\fR]] [\fBfailover\fR | \fB-failover\fR] [\fBgroup\fR
  20  [\fIname\fR | ""\fB\fR]] [\fBindex\fR \fIif_index\fR] [ipmp] [\fBmetric\fR \fIn\fR] [modlist]
  21  [modinsert \fImod_name@pos\fR] [modremove \fImod_name@pos\fR]
  22  [\fBmtu\fR \fIn\fR] [\fBnetmask\fR \fImask\fR] [\fBplumb\fR] [\fBunplumb\fR] [\fBprivate\fR
  23  | \fB-private\fR] [\fBnud\fR | \fB-nud\fR] [\fBset\fR [\fIaddress\fR] [\fI/netmask\fR]]
  24  [\fBstandby\fR | \fB-standby\fR] [\fBsubnet\fR \fIsubnet_address\fR] [\fBtdst\fR
  25  \fItunnel_dest_address\fR] [\fBtoken\fR \fIaddress\fR/\fIprefix_length\fR]
  26  [\fBtsrc\fR \fItunnel_src_address\fR] [\fBtrailers\fR | \fB-trailers\fR]
  27  [\fBup\fR] [\fBdown\fR] [\fBusesrc\fR [\fIname\fR | none]] [\fBxmit\fR | \fB-xmit\fR]
  28  [\fBencaplimit\fR \fIn\fR | \fB-encaplimit\fR] [\fBthoplimit\fR \fIn\fR] [\fBrouter\fR
  29  | \fB-router\fR] [zone \fIzonename\fR | \fB-zone\fR | \fB-all-zones\fR]
  30 .fi
  31 
  32 .LP
  33 .nf
  34 \fBifconfig\fR [\fIaddress_family\fR] \fIinterface\fR {\fBauto-dhcp\fR | \fBdhcp\fR} [\fBprimary\fR]
  35  [\fBwait\fR \fIseconds\fR] \fBdrop\fR | \fBextend\fR | \fBinform\fR | \fBping\fR
  36  | \fBrelease\fR | \fBstart\fR | \fBstatus\fR
  37 .fi
  38 
  39 .SH DESCRIPTION
  40 .sp
  41 .LP
  42 The command \fBifconfig\fR is used to assign an address to a network interface
  43 and to configure network interface parameters. The \fBifconfig\fR command must
  44 be used at boot time to define the network address of each interface present on
  45 a machine; it may also be used at a later time to redefine an interface's
  46 address or other operating parameters. If no option is specified,
  47 \fBifconfig\fR displays the current configuration for a network interface. If
  48 an address family is specified, \fBifconfig\fR reports only the details
  49 specific to that address family. Only privileged users may modify the
  50 configuration of a network interface. Options appearing within braces
  51 (\fB{\|}\fR) indicate that one of the options must be specified.
  52 .SS Network Interface Observability
  53 .sp
  54 .LP
  55 Network interface observability with \fBifconfig\fR is limited to those
  56 network interfaces that have been prepared for use with the IP
  57 protocol suite. The preferred method for configuring a network
  58 interface for use with TCP/IP is with \fBipadm\fR and alternatively
  59 with the use of the \fBplumb\fR option as documented below. Network
  60 interfaces that have not been configured for use with the IP
  61 protocol suite can only be observed by using the \fBdladm\fR command.
  62 .SS DHCP Configuration
  63 .sp
  64 .LP
  65 The forms of \fBifconfig\fR that use the \fBauto-dhcp\fR or \fBdhcp\fR
  66 arguments are used to control the Dynamic Host Configuration Protocol
  67 ("\fBDHCP\fR") configuration of the interface. In this mode, \fBifconfig\fR is
  68 used to control operation of \fBdhcpagent\fR(1M), the \fBDHCP\fR client daemon.
  69 Once an interface is placed under \fBDHCP\fR control by using the \fBstart\fR
  70 operand, \fBifconfig\fR should not, in normal operation, be used to modify the
  71 address or characteristics of the interface. If the address of an interface
  72 under \fBDHCP\fR is changed, \fBdhcpagent\fR will remove the interface from its
  73 control.
  74 .SH OPTIONS
  75 .sp
  76 .LP
  77 When the \fBifconfig\fR command is executed without any options
  78 its behavior is the same as when the \fB\-a\fR option is supplied
  79 with no other options or arguments.
  80 .LP
  81 The following options are supported:
  82 .sp
  83 .ne 2
  84 .na
  85 \fB\fBaddif\fR \fIaddress\fR\fR
  86 .ad
  87 .sp .6
  88 .RS 4n
  89 Create the next unused logical interface on the specified physical interface.
  90 .RE
  91 
  92 .sp
  93 .ne 2
  94 .na
  95 \fB\fBall-zones\fR\fR
  96 .ad
  97 .sp .6
  98 .RS 4n
  99 Make the interface available to every shared-IP zone on the system. The
 100 appropriate zone to which to deliver data is determined using the
 101 \fBtnzonecfg\fR database. This option is available only if the system is
 102 configured with the Solaris Trusted Extensions feature.
 103 .sp
 104 The \fBtnzonecfg\fR database is described in the \fBtnzonecfg(4)\fR man page,
 105 which is part of the \fISolaris Trusted Extensions Reference Manual\fR.
 106 .RE
 107 
 108 .sp
 109 .ne 2
 110 .na
 111 \fB\fBanycast\fR\fR
 112 .ad
 113 .sp .6
 114 .RS 4n
 115 Marks the logical interface as an anycast address by setting the \fBANYCAST\fR
 116 flag. See "INTERFACE FLAGS," below, for more information on anycast.
 117 .RE
 118 
 119 .sp
 120 .ne 2
 121 .na
 122 \fB\fB-anycast\fR\fR
 123 .ad
 124 .sp .6
 125 .RS 4n
 126 Marks the logical interface as not an anycast address by clearing the
 127 \fBANYCAST\fR flag.
 128 .RE
 129 
 130 .sp
 131 .ne 2
 132 .na
 133 \fB\fBarp\fR\fR
 134 .ad
 135 .sp .6
 136 .RS 4n
 137 Enable the use of the Address Resolution Protocol ("\fBARP\fR") in mapping
 138 between network level addresses and link level addresses (default). This is
 139 currently implemented for mapping between IPv4 addresses and MAC addresses.
 140 .RE
 141 
 142 .sp
 143 .ne 2
 144 .na
 145 \fB\fB-arp\fR\fR
 146 .ad
 147 .sp .6
 148 .RS 4n
 149 Disable the use of the \fBARP\fR on a physical interface. ARP cannot be
 150 disabled on an IPMP IP interface.
 151 .RE
 152 
 153 .sp
 154 .ne 2
 155 .na
 156 \fB\fBauth_algs\fR \fIauthentication algorithm\fR\fR
 157 .ad
 158 .sp .6
 159 .RS 4n
 160 For a tunnel, enable IPsec \fBAH\fR with the authentication algorithm
 161 specified. The algorithm can be either a number or an algorithm name, including
 162 \fIany\fR to express no preference in algorithm. All IPsec tunnel properties
 163 must be specified on the same command line. To disable tunnel security, specify
 164 an \fBauth_alg\fR of \fBnone\fR.
 165 .sp
 166 It is now preferable to use the \fBipsecconf\fR(1M) command when configuring a
 167 tunnel's security properties. If \fBipsecconf\fR was used to set a tunnel's
 168 security properties, this keyword will not affect the tunnel.
 169 .RE
 170 
 171 .sp
 172 .ne 2
 173 .na
 174 \fB\fBauto-dhcp\fR\fR
 175 .ad
 176 .sp .6
 177 .RS 4n
 178 Use DHCP to automatically acquire an address for this interface. This option
 179 has a completely equivalent alias called \fBdhcp\fR.
 180 .sp
 181 For IPv6, the interface specified must be the zeroth logical interface (the
 182 physical interface name), which has the link-local address.
 183 .sp
 184 .ne 2
 185 .na
 186 \fBprimary\fR
 187 .ad
 188 .sp .6
 189 .RS 4n
 190 Defines the interface as the \fBprimary\fR. The interface is defined as the
 191 preferred one for the delivery of client-wide configuration data. Only one
 192 interface can be the primary at any given time. If another interface is
 193 subsequently selected as the primary, it replaces the previous one. Nominating
 194 an interface as the primary one will not have much significance once the client
 195 work station has booted, as many applications will already have started and
 196 been configured with data read from the previous primary interface.
 197 .RE
 198 
 199 .sp
 200 .ne 2
 201 .na
 202 \fBwait \fIseconds\fR\fR
 203 .ad
 204 .sp .6
 205 .RS 4n
 206 The \fBifconfig\fR command will wait until the operation either completes or
 207 for the interval specified, whichever is the sooner. If no wait interval is
 208 given, and the operation is one that cannot complete immediately,
 209 \fBifconfig\fR will wait 30 seconds for the requested operation to complete.
 210 The symbolic value \fBforever\fR may be used as well, with obvious meaning.
 211 .RE
 212 
 213 .sp
 214 .ne 2
 215 .na
 216 \fBdrop\fR
 217 .ad
 218 .sp .6
 219 .RS 4n
 220 Remove the specified interface from \fBDHCP\fR control without notifying the
 221 DHCP server, and record the current lease for later use. Additionally, for
 222 IPv4, set the IP address to zero. For IPv6, unplumb all logical interfaces
 223 plumbed by \fBdhcpagent\fR.
 224 .RE
 225 
 226 .sp
 227 .ne 2
 228 .na
 229 \fBextend\fR
 230 .ad
 231 .sp .6
 232 .RS 4n
 233 Attempt to extend the lease on the interface's IP address. This is not
 234 required, as the agent will automatically extend the lease well before it
 235 expires.
 236 .RE
 237 
 238 .sp
 239 .ne 2
 240 .na
 241 \fBinform\fR
 242 .ad
 243 .sp .6
 244 .RS 4n
 245 Obtain network configuration parameters from \fBDHCP\fR without obtaining a
 246 lease on \fBIP\fR addresses. This is useful in situations where an \fBIP\fR
 247 address is obtained through mechanisms other than \fBDHCP\fR.
 248 .RE
 249 
 250 .sp
 251 .ne 2
 252 .na
 253 \fBping\fR
 254 .ad
 255 .sp .6
 256 .RS 4n
 257 Check whether the interface given is under \fBDHCP\fR control, which means that
 258 the interface is managed by the \fBDHCP\fR agent and is working properly. An
 259 exit status of \fB0\fR means success.
 260 .RE
 261 
 262 .sp
 263 .ne 2
 264 .na
 265 \fBrelease\fR
 266 .ad
 267 .sp .6
 268 .RS 4n
 269 Relinquish the IP addresses on the interface by notifying the server and
 270 discard the current lease. For IPv4, set the IP address to zero. For IPv6, all
 271 logical interfaces plumbed by \fBdhcpagent\fR are unplumbed.
 272 .RE
 273 
 274 .sp
 275 .ne 2
 276 .na
 277 \fBstart\fR
 278 .ad
 279 .sp .6
 280 .RS 4n
 281 Start \fBDHCP\fR on the interface.
 282 .RE
 283 
 284 .sp
 285 .ne 2
 286 .na
 287 \fBstatus\fR
 288 .ad
 289 .sp .6
 290 .RS 4n
 291 Display the \fBDHCP\fR configuration status of the interface.
 292 .RE
 293 
 294 .RE
 295 
 296 .sp
 297 .ne 2
 298 .na
 299 \fB\fBauto-revarp\fR\fR
 300 .ad
 301 .sp .6
 302 .RS 4n
 303 Use the Reverse Address Resolution Protocol (RARP) to automatically acquire an
 304 address for this interface. This will fail if the interface does not support
 305 RARP; for example, IPoIB (IP over InfiniBand), and on IPv6 interfaces.
 306 .RE
 307 
 308 .sp
 309 .ne 2
 310 .na
 311 \fB\fBbroadcast\fR \fIaddress\fR\fR
 312 .ad
 313 .sp .6
 314 .RS 4n
 315 For IPv4 only. Specify the address to use to represent broadcasts to the
 316 network. The default broadcast address is the address with a host part of all
 317 \fB1\fR's. A "\fB+\fR" (plus sign) given for the broadcast value causes the
 318 broadcast address to be reset to a default appropriate for the (possibly new)
 319 address and netmask. The arguments of \fBifconfig\fR are interpreted left to
 320 right. Therefore
 321 .sp
 322 .in +2
 323 .nf
 324 example% ifconfig -a netmask + broadcast +
 325 .fi
 326 .in -2
 327 .sp
 328 
 329 and
 330 .sp
 331 .in +2
 332 .nf
 333 example% ifconfig -a broadcast + netmask +
 334 .fi
 335 .in -2
 336 .sp
 337 
 338 may result in different values being assigned for the broadcast addresses of
 339 the interfaces.
 340 .RE
 341 
 342 .sp
 343 .ne 2
 344 .na
 345 \fB\fBdeprecated\fR\fR
 346 .ad
 347 .sp .6
 348 .RS 4n
 349 Marks the logical interface as deprecated. An address associated with a
 350 deprecated interface will not be used as source address for outbound packets
 351 unless either there are no other addresses available on the interface or the
 352 application has bound to this address explicitly. The status display shows
 353 \fBDEPRECATED\fR as part of flags. See  for information on the flags supported
 354 by \fBifconfig\fR.
 355 .RE
 356 
 357 .sp
 358 .ne 2
 359 .na
 360 \fB\fB-deprecated\fR\fR
 361 .ad
 362 .sp .6
 363 .RS 4n
 364 Marks a logical interface as not deprecated. An address associated with such an
 365 interface could be used as a source address for outbound packets.
 366 .RE
 367 
 368 .sp
 369 .ne 2
 370 .na
 371 \fB\fBpreferred\fR\fR
 372 .ad
 373 .sp .6
 374 .RS 4n
 375 Marks the logical interface as preferred. This option is only valid for IPv6
 376 addresses. Addresses assigned to preferred logical interfaces are preferred as
 377 source addresses over all other addresses configured on the system, unless the
 378 address is of an inappropriate scope relative to the destination address.
 379 Preferred addresses are used as source addresses regardless of which physical
 380 interface they are assigned to. For example, you can configure a preferred
 381 source address on the loopback interface and advertise reachability of this
 382 address by using a routing protocol.
 383 .RE
 384 
 385 .sp
 386 .ne 2
 387 .na
 388 \fB\fB-preferred\fR\fR
 389 .ad
 390 .sp .6
 391 .RS 4n
 392 Marks the logical interface as not preferred.
 393 .RE
 394 
 395 .sp
 396 .ne 2
 397 .na
 398 \fB\fBdestination\fR \fIdest_address\fR\fR
 399 .ad
 400 .sp .6
 401 .RS 4n
 402 Set the destination address for a point-to point interface.
 403 .RE
 404 
 405 .sp
 406 .ne 2
 407 .na
 408 \fB\fBdhcp\fR\fR
 409 .ad
 410 .sp .6
 411 .RS 4n
 412 This option is an alias for option \fBauto-dhcp\fR
 413 .RE
 414 
 415 .sp
 416 .ne 2
 417 .na
 418 \fB\fBdown\fR\fR
 419 .ad
 420 .sp .6
 421 .RS 4n
 422 Mark a logical interface as "down". (That is, turn off the \fBIFF_UP\fR bit.)
 423 When a logical interface is marked "down," the system does not attempt to use
 424 the address assigned to that interface as a source address for outbound packets
 425 and will not recognize inbound packets destined to that address as being
 426 addressed to this host. Additionally, when all logical interfaces on a given
 427 physical interface are "down," the physical interface itself is disabled.
 428 .sp
 429 When a logical interface is down, all routes that specify that interface as the
 430 output (using the \fB-ifp\fR option in the \fBroute\fR(1M) command or
 431 \fBRTA_IFP\fR in a \fBroute\fR(7P) socket) are removed from the forwarding
 432 table. Routes marked with \fBRTF_STATIC\fR are returned to the table if the
 433 interface is brought back up, while routes not marked with \fBRTF_STATIC\fR are
 434 simply deleted.
 435 .sp
 436 When all logical interfaces that could possibly be used to reach a particular
 437 gateway address are brought down (specified without the interface option as in
 438 the previous paragraph), the affected gateway routes are treated as though they
 439 had the \fBRTF_BLACKHOLE\fR flag set. All matching packets are discarded
 440 because the gateway is unreachable.
 441 .RE
 442 
 443 .sp
 444 .ne 2
 445 .na
 446 \fB\fBencaplimit\fR \fIn\fR\fR
 447 .ad
 448 .sp .6
 449 .RS 4n
 450 Set the tunnel encapsulation limit for the interface to n. This option applies
 451 to IPv4-in-IPv6 and IPv6-in-IPv6 tunnels only, and it simply modifies the
 452 \fBencaplimit\fR link property of the underlying IPv6 tunnel link (see
 453 \fBdladm\fR(1M)). The tunnel encapsulation limit controls how many more tunnels
 454 a packet can enter before it leaves any tunnel, that is, the tunnel nesting
 455 level.
 456 .sp
 457 This option is obsolete, superseded by the \fBdladm\fR(1M) \fBencaplimit\fR
 458 link property.
 459 .RE
 460 
 461 .sp
 462 .ne 2
 463 .na
 464 \fB\fB-encaplimit\fR\fR
 465 .ad
 466 .sp .6
 467 .RS 4n
 468 Disable generation of the tunnel encapsulation limit. This option applies only
 469 to IPv4-in-IPv6 and IPv6-in-IPv6 tunnels. This simply sets the \fBencaplimit\fR
 470 link property of the underlying IPv6 tunnel link to 0 (see \fBdladm\fR(1M)
 471 \fBencaplimit\fR).
 472 .sp
 473 This option is obsolete, superseded by the \fBdladm\fR(1M) \fBencaplimit\fR
 474 link property.
 475 .RE
 476 
 477 .sp
 478 .ne 2
 479 .na
 480 \fB\fBencr_auth_algs\fR \fIauthentication algorithm\fR\fR
 481 .ad
 482 .sp .6
 483 .RS 4n
 484 For a tunnel, enable IPsec \fBESP\fR with the authentication algorithm
 485 specified. It can be either a number or an algorithm name, including \fBany\fR
 486 or \fBnone\fR, to indicate no algorithm preference. If an \fBESP\fR encryption
 487 algorithm is specified but the authentication algorithm is not, the default
 488 value for the \fBESP\fR authentication algorithm will be \fBany\fR.
 489 .sp
 490 It is now preferable to use the \fBipsecconf\fR(1M) command when configuring a
 491 tunnel's security properties. If \fBipsecconf\fR was used to set a tunnel's
 492 security properties, this keyword will not affect the tunnel.
 493 .RE
 494 
 495 .sp
 496 .ne 2
 497 .na
 498 \fB\fBencr_algs\fR \fIencryption algorithm\fR\fR
 499 .ad
 500 .sp .6
 501 .RS 4n
 502 For a tunnel, enable IPsec \fBESP\fR with the encryption algorithm specified.
 503 It can be either a number or an algorithm name. Note that all IPsec tunnel
 504 properties must be specified on the same command line. To disable tunnel
 505 security, specify the value of \fBencr_alg\fR as \fBnone\fR. If an \fBESP\fR
 506 authentication algorithm is specified, but the encryption algorithm is not, the
 507 default value for the \fBESP\fR encryption will be \fBnull\fR.
 508 .sp
 509 It is now preferable to use the \fBipsecconf\fR(1M) command when configuring a
 510 tunnel's security properties. If \fBipsecconf\fR was used to set a tunnel's
 511 security properties, this keyword will not affect the tunnel.
 512 .RE
 513 
 514 .sp
 515 .ne 2
 516 .na
 517 \fB\fBether\fR [ \fIaddress\fR ]\fR
 518 .ad
 519 .sp .6
 520 .RS 4n
 521 If no address is given and the user is root or has sufficient privileges to
 522 open the underlying datalink, then display the current Ethernet address
 523 information.
 524 .sp
 525 Otherwise, if the user is root or has sufficient privileges, set the Ethernet
 526 address of the interfaces to \fIaddress\fR. The address is an Ethernet address
 527 represented as \fIx:x:x:x:x:x\fR where \fIx\fR is a hexadecimal number between
 528 0 and FF. Similarly, for the IPoIB (IP over InfiniBand) interfaces, the address
 529 will be 20 bytes of colon-separated hex numbers between \fB0\fR and \fBFF\fR.
 530 .sp
 531 Some, though not all, Ethernet interface cards have their own addresses. To use
 532 cards that do not have their own addresses, refer to section 3.2.3(4) of the
 533 IEEE 802.3 specification for a definition of the locally administered address
 534 space. Note that all IP interfaces in an IPMP group must have unique hardware
 535 addresses; see \fBin.mpathd\fR(1M).
 536 .RE
 537 
 538 .sp
 539 .ne 2
 540 .na
 541 \fB\fB-failover\fR\fR
 542 .ad
 543 .sp .6
 544 .RS 4n
 545 Set \fBNOFAILOVER\fR on the logical interface. This makes the associated
 546 address available for use by \fBin.mpathd\fR to perform probe-based failure
 547 detection for the associated physical IP interface. As a side effect,
 548 \fBDEPRECATED\fR will also be set on the logical interface. This operation is
 549 not permitted on an IPMP IP interface.
 550 .RE
 551 
 552 .sp
 553 .ne 2
 554 .na
 555 \fB\fBfailover\fR\fR
 556 .ad
 557 .sp .6
 558 .RS 4n
 559 Clear \fBNOFAILOVER\fR on the logical interface. This is the default. These
 560 logical interfaces are subject to migration when brought up (see \fBIP
 561 MULTIPATHING GROUPS\fR).
 562 .RE
 563 
 564 .sp
 565 .ne 2
 566 .na
 567 \fB\fBgroup\fR [ \fIname\fR |\fB""\fR]\fR
 568 .ad
 569 .sp .6
 570 .RS 4n
 571 When applied to a physical interface, it places the interface into the named
 572 group. If the group does not exist, it will be created, along with one or more
 573 IPMP IP interfaces (for IPv4, IPv6, or both). Any \fBUP\fR addresses that are
 574 not also marked \fBNOFAILOVER\fR are subject to migration to the IPMP IP
 575 interface (see \fBIP MULTIPATHING GROUPS\fR). Specifying a group name of
 576 \fB""\fR removes the physical IP interface from the group.
 577 .sp
 578 When applied to a physical IPMP IP interface, it renames the IPMP group to have
 579 the new name. If the name already exists, or a name of \fB""\fR is specified,
 580 it fails. Renaming IPMP groups is discouraged. Instead, the IPMP IP interface
 581 should be given a meaningful name when it is created by means of the \fBipmp\fR
 582 subcommand, which the system will also use as the IPMP group name.
 583 .RE
 584 
 585 .sp
 586 .ne 2
 587 .na
 588 \fB\fBindex\fR \fIn\fR\fR
 589 .ad
 590 .sp .6
 591 .RS 4n
 592 Change the interface index for the interface. The value of \fIn\fR must be an
 593 interface index (\fIif_index\fR) that is not used on another interface.
 594 \fIif_index\fR will be a non-zero positive number that uniquely identifies the
 595 network interface on the system.
 596 .RE
 597 
 598 .sp
 599 .ne 2
 600 .na
 601 \fB\fBipmp\fR\fR
 602 .ad
 603 .sp .6
 604 .RS 4n
 605 Create an IPMP IP interface with the specified name. An interface must be
 606 separately created for use by IPv4 and IPv6. The \fIaddress_family\fR parameter
 607 controls whether the command applies to IPv4 or IPv6 (IPv4 if unspecified). All
 608 IPMP IP interfaces have the \fBIPMP\fR flag set.
 609 .RE
 610 
 611 .sp
 612 .ne 2
 613 .na
 614 \fB\fBmetric\fR \fIn\fR\fR
 615 .ad
 616 .sp .6
 617 .RS 4n
 618 Set the routing metric of the interface to \fIn\fR; if no value is specified,
 619 the default is \fB0\fR. The routing metric is used by the routing protocol.
 620 Higher metrics have the effect of making a route less favorable. Metrics are
 621 counted as addition hops to the destination network or host.
 622 .RE
 623 
 624 .sp
 625 .ne 2
 626 .na
 627 \fB\fBmodinsert\fR \fImod_name@pos\fR\fR
 628 .ad
 629 .sp .6
 630 .RS 4n
 631 Insert a module with name \fImod_name\fR to the stream of the device at
 632 position \fIpos\fR. The position is relative to the stream head. Position
 633 \fB0\fR means directly under stream head.
 634 .sp
 635 Based upon the example in the \fBmodlist\fR option, use the following command
 636 to insert a module with name \fBipqos\fR under the \fBip\fR module and above
 637 the firewall module:
 638 .sp
 639 .in +2
 640 .nf
 641 example% ifconfig eri0 modinsert ipqos@2
 642 .fi
 643 .in -2
 644 .sp
 645 
 646 A subsequent listing of all the modules in the stream of the device follows:
 647 .sp
 648 .in +2
 649 .nf
 650 example% ifconfig eri0 modlist
 651 0 arp
 652 1 ip
 653 2 ipqos
 654 3 firewall
 655 4 eri
 656 .fi
 657 .in -2
 658 .sp
 659 
 660 .RE
 661 
 662 .sp
 663 .ne 2
 664 .na
 665 \fB\fBmodlist\fR\fR
 666 .ad
 667 .sp .6
 668 .RS 4n
 669 List all the modules in the stream of the device.
 670 .sp
 671 The following example lists all the modules in the stream of the device:
 672 .sp
 673 .in +2
 674 .nf
 675 example% ifconfig eri0 modlist
 676 0 arp
 677 1 ip
 678 2 firewall
 679 4 eri
 680 .fi
 681 .in -2
 682 .sp
 683 
 684 .RE
 685 
 686 .sp
 687 .ne 2
 688 .na
 689 \fB\fBmodremove\fR \fImod_name@pos\fR\fR
 690 .ad
 691 .sp .6
 692 .RS 4n
 693 Remove a module with name \fImod_name\fR from the stream of the device at
 694 position \fIpos\fR. The position is relative to the stream head.
 695 .sp
 696 Based upon the example in the \fBmodinsert\fR option, use the following command
 697 to remove the firewall module from the stream after inserting the \fBipqos\fR
 698 module:
 699 .sp
 700 .in +2
 701 .nf
 702 example% ifconfig eri0 modremove firewall@3
 703 .fi
 704 .in -2
 705 .sp
 706 
 707 A subsequent listing of all the modules in the stream of the device follows:
 708 .sp
 709 .in +2
 710 .nf
 711 example% ifconfig eri0 modlist
 712 0 arp
 713 1 ip
 714 2 ipqos
 715 3 eri
 716 .fi
 717 .in -2
 718 .sp
 719 
 720 Note that the core IP stack modules, for example, \fBip\fR and \fBtun\fR
 721 modules, cannot be removed.
 722 .RE
 723 
 724 .sp
 725 .ne 2
 726 .na
 727 \fB\fBmtu\fR \fIn\fR\fR
 728 .ad
 729 .sp .6
 730 .RS 4n
 731 Set the maximum transmission unit of the interface to \fIn\fR. For many types
 732 of networks, the \fBmtu\fR has an upper limit, for example, \fB1500\fR for
 733 Ethernet. This option sets the \fBFIXEDMTU\fR flag on the affected interface.
 734 .RE
 735 
 736 .sp
 737 .ne 2
 738 .na
 739 \fB\fBnetmask\fR \fImask\fR\fR
 740 .ad
 741 .sp .6
 742 .RS 4n
 743 For IPv4 only. Specify how much of the address to reserve for subdividing
 744 networks into subnetworks. The mask includes the network part of the local
 745 address and the subnet part, which is taken from the host field of the address.
 746 The mask contains 1's for the bit positions in the 32-bit address which are to
 747 be used for the network and subnet parts, and 0's for the host part. The mask
 748 should contain at least the standard network portion, and the subnet field
 749 should be contiguous with the network portion. The mask can be specified in one
 750 of four ways:
 751 .RS +4
 752 .TP
 753 1.
 754 with a single hexadecimal number with a leading 0x,
 755 .RE
 756 .RS +4
 757 .TP
 758 2.
 759 with a dot-notation address,
 760 .RE
 761 .RS +4
 762 .TP
 763 3.
 764 with a "\fB+\fR" (plus sign) address, or
 765 .RE
 766 .RS +4
 767 .TP
 768 4.
 769 with a pseudo host name/pseudo network name found in the network database
 770 \fBnetworks\fR(4).
 771 .RE
 772 If a "\fB+\fR" (plus sign) is given for the netmask value, the mask is looked
 773 up in the \fBnetmasks\fR(4) database. This lookup finds the longest matching
 774 netmask in the database by starting with the interface's IPv4 address as the
 775 key and iteratively masking off more and more low order bits of the address.
 776 This iterative lookup ensures that the \fBnetmasks\fR(4) database can be used
 777 to specify the netmasks when variable length subnetmasks are used within a
 778 network number.
 779 .sp
 780 If a pseudo host name/pseudo network name is supplied as the netmask value,
 781 netmask data may be located in the \fBhosts\fR or \fBnetworks\fR database.
 782 Names are looked up by first using \fBgethostbyname\fR(3NSL). If not found
 783 there, the names are looked up in \fBgetnetbyname\fR(3SOCKET). These interfaces
 784 may in turn use \fBnsswitch.conf\fR(4) to determine what data store(s) to use
 785 to fetch the actual value.
 786 .sp
 787 For both \fBinet\fR and \fBinet6\fR, the same information conveyed by
 788 \fImask\fR can be specified as a \fIprefix_length\fR attached to the
 789 \fIaddress\fR parameter.
 790 .RE
 791 
 792 .sp
 793 .ne 2
 794 .na
 795 \fB\fBnud\fR\fR
 796 .ad
 797 .sp .6
 798 .RS 4n
 799 Enables the neighbor unreachability detection mechanism on a point-to-point
 800 physical interface.
 801 .RE
 802 
 803 .sp
 804 .ne 2
 805 .na
 806 \fB\fB-nud\fR\fR
 807 .ad
 808 .sp .6
 809 .RS 4n
 810 Disables the neighbor unreachability detection mechanism on a point-to-point
 811 physical interface.
 812 .RE
 813 
 814 .sp
 815 .ne 2
 816 .na
 817 \fB\fBplumb\fR\fR
 818 .ad
 819 .sp .6
 820 .RS 4n
 821 For a physical IP interface, open the datalink associated with the physical
 822 interface name and set up the plumbing needed for IP to use the datalink. When
 823 used with a logical interface name, this command is used to create a specific
 824 named logical interface on an existing physical IP interface.
 825 .sp
 826 An interface must be separately plumbed for IPv4 and IPv6 according to the
 827 \fIaddress_family\fR parameter (IPv4 if unspecified). Before an interface has
 828 been plumbed, it will not be shown by \fBifconfig\fR \fB-a\fR.
 829 .sp
 830 Note that IPMP IP interfaces are not tied to a specific datalink and are
 831 instead created with the \fBipmp\fR subcommand.
 832 .RE
 833 
 834 .sp
 835 .ne 2
 836 .na
 837 \fB\fBprivate\fR\fR
 838 .ad
 839 .sp .6
 840 .RS 4n
 841 Tells the \fBin.routed\fR routing daemon that a specified logical interface
 842 should not be advertised.
 843 .RE
 844 
 845 .sp
 846 .ne 2
 847 .na
 848 \fB\fB-private\fR\fR
 849 .ad
 850 .sp .6
 851 .RS 4n
 852 Specify unadvertised interfaces.
 853 .RE
 854 
 855 .sp
 856 .ne 2
 857 .na
 858 \fB\fBremoveif\fR \fIaddress\fR\fR
 859 .ad
 860 .sp .6
 861 .RS 4n
 862 Remove the logical interface on the physical interface specified that matches
 863 the \fIaddress\fR specified.
 864 .RE
 865 
 866 .sp
 867 .ne 2
 868 .na
 869 \fB\fBrouter\fR\fR
 870 .ad
 871 .sp .6
 872 .RS 4n
 873 Enable IP forwarding on the interface. When enabled, the interface is marked
 874 \fBROUTER\fR, and IP packets can be forwarded to and from the interface.
 875 Enabling \fBROUTER\fR on any IP interface in an IPMP group enables it on all IP
 876 interfaces in that IPMP group.
 877 .RE
 878 
 879 .sp
 880 .ne 2
 881 .na
 882 \fB\fB-router\fR\fR
 883 .ad
 884 .sp .6
 885 .RS 4n
 886 Disable IP forwarding on the interface. IP packets are not forwarded to and
 887 from the interface. Disabling \fBROUTER\fR on any IP interface in an IPMP group
 888 disables it on all IP interfaces in that IPMP group.
 889 .RE
 890 
 891 .sp
 892 .ne 2
 893 .na
 894 \fB\fBset\fR\fR
 895 .ad
 896 .sp .6
 897 .RS 4n
 898 Set the \fIaddress\fR, \fIprefix_length\fR or both, for a logical interface.
 899 .RE
 900 
 901 .sp
 902 .ne 2
 903 .na
 904 \fB\fBstandby\fR\fR
 905 .ad
 906 .sp .6
 907 .RS 4n
 908 Mark the physical IP interface as a \fBSTANDBY\fR interface. If an interface is
 909 marked \fBSTANDBY\fR and is part of an IPMP group, the interface will not be
 910 used for data traffic unless another interface in the IPMP group becomes
 911 unusable. When a \fBSTANDBY\fR interface is functional but not being used for
 912 data traffic, it will also be marked \fBINACTIVE\fR. This operation is not
 913 permitted on an IPMP IP interface.
 914 .RE
 915 
 916 .sp
 917 .ne 2
 918 .na
 919 \fB\fB-standby\fR\fR
 920 .ad
 921 .sp .6
 922 .RS 4n
 923 Clear \fBSTANDBY\fR on the interface. This is the default.
 924 .RE
 925 
 926 .sp
 927 .ne 2
 928 .na
 929 \fB\fBsubnet\fR\fR
 930 .ad
 931 .sp .6
 932 .RS 4n
 933 Set the subnet \fIaddress\fR for an interface.
 934 .RE
 935 
 936 .sp
 937 .ne 2
 938 .na
 939 \fB\fBtdst\fR \fItunnel_dest_address\fR\fR
 940 .ad
 941 .sp .6
 942 .RS 4n
 943 Set the destination address of a tunnel. The address should not be the same as
 944 the \fBdest_address\fR of the tunnel, because no packets leave the system over
 945 such a tunnel.
 946 .sp
 947 This option is obsolete, superseded by the \fBdladm\fR(1M) \fBcreate-iptun\fR
 948 and \fBmodify-iptun\fR subcommands.
 949 .RE
 950 
 951 .sp
 952 .ne 2
 953 .na
 954 \fB\fBthoplimit\fR \fIn\fR\fR
 955 .ad
 956 .sp .6
 957 .RS 4n
 958 Set the hop limit for a tunnel interface. The hop limit value is used as the
 959 \fBTTL\fR in the IPv4 header for the IPv6-in-IPv4 and IPv4-in-IPv4 tunnels. For
 960 IPv6-in-IPv6 and IPv4-in-IPv6 tunnels, the hop limit value is used as the hop
 961 limit in the IPv6 header. This option simply modifies the \fBhoplimit\fR link
 962 property of the underlying IP tunnel link (see \fBdladm\fR(1M)).
 963 .sp
 964 This option is obsolete, superseded by the \fBdladm\fR(1M) \fBhoplimit\fR link
 965 property.
 966 .RE
 967 
 968 .sp
 969 .ne 2
 970 .na
 971 \fB\fBtoken\fR \fIaddress\fR/\fIprefix_length\fR\fR
 972 .ad
 973 .sp .6
 974 .RS 4n
 975 Set the IPv6 token of an interface to be used for address autoconfiguration.
 976 .sp
 977 .in +2
 978 .nf
 979 example% \fBifconfig eri0 inet6 token ::1/64\fR
 980 .fi
 981 .in -2
 982 .sp
 983 
 984 .RE
 985 
 986 .sp
 987 .ne 2
 988 .na
 989 \fB\fBtrailers\fR\fR
 990 .ad
 991 .sp .6
 992 .RS 4n
 993 This flag previously caused a nonstandard encapsulation of IPv4 packets on
 994 certain link levels. Drivers supplied with this release no longer use this
 995 flag. It is provided for compatibility, but is ignored.
 996 .RE
 997 
 998 .sp
 999 .ne 2
1000 .na
1001 \fB\fB-trailers\fR\fR
1002 .ad
1003 .sp .6
1004 .RS 4n
1005 Disable the use of a "trailer" link level encapsulation.
1006 .RE
1007 
1008 .sp
1009 .ne 2
1010 .na
1011 \fB\fBtsrc\fR \fItunnel_src_address\fR\fR
1012 .ad
1013 .sp .6
1014 .RS 4n
1015 Set the source address of a tunnel. This is the source address on an outer
1016 encapsulating \fBIP\fR header. It must be an address of another interface
1017 already configured using \fBifconfig\fR.
1018 .sp
1019 This option is obsolete, superseded by the \fBdladm\fR(1M) \fBcreate-iptun\fR
1020 and \fBmodify-iptun\fR subcommands.
1021 .RE
1022 
1023 .sp
1024 .ne 2
1025 .na
1026 \fB\fBunplumb\fR\fR
1027 .ad
1028 .sp .6
1029 .RS 4n
1030 For a physical or IPMP interface, remove all associated logical IP interfaces
1031 and tear down any plumbing needed for IP to use the interface. For an IPMP IP
1032 interface, this command will fail if the group is not empty. For a logical
1033 interface, the logical interface is removed.
1034 .sp
1035 An interface must be separately unplumbed for IPv4 and IPv6 according to the
1036 \fIaddress_family\fR parameter (IPv4 if unspecified). Upon success, the
1037 interface name will no longer appear in the output of \fBifconfig\fR \fB-a\fR.
1038 .RE
1039 
1040 .sp
1041 .ne 2
1042 .na
1043 \fB\fBup\fR\fR
1044 .ad
1045 .sp .6
1046 .RS 4n
1047 Mark a logical interface \fBUP\fR. As a result, the IP module will accept
1048 packets destined to the associated address (unless the address is zero), along
1049 with any associated multicast and broadcast IP addresses. Similarly, the IP
1050 module will allow packets to be sent with the associated address as a source
1051 address. At least one logical interface must be \fBUP\fR for the associated
1052 physical interface to send or receive packets
1053 .RE
1054 
1055 .sp
1056 .ne 2
1057 .na
1058 \fB\fBusesrc\fR [ \fIname\fR | \fBnone\fR ]\fR
1059 .ad
1060 .sp .6
1061 .RS 4n
1062 Specify a physical interface to be used for source address selection. If the
1063 keyword \fBnone\fR is used, then any previous selection is cleared.
1064 .sp
1065 When an application does not choose a non-zero source address using
1066 \fBbind\fR(3SOCKET), the system will select an appropriate source address based
1067 on the outbound interface and the address selection rules (see
1068 \fBipaddrsel\fR(1M)).
1069 .sp
1070 When \fBusesrc\fR is specified and the specified interface is selected in the
1071 forwarding table for output, the system looks first to the specified physical
1072 interface and its associated logical interfaces when selecting a source
1073 address. If no usable address is listed in the forwarding table, the ordinary
1074 selection rules apply. For example, if you enter:
1075 .sp
1076 .in +2
1077 .nf
1078 # \fBifconfig eri0 usesrc vni0\fR
1079 .fi
1080 .in -2
1081 .sp
1082 
1083 \&...and \fBvni0\fR has address 10.0.0.1 assigned to it, the system will prefer
1084 10.0.0.1 as the source address for any packets originated by local connections
1085 that are sent through \fBeri0\fR. Further examples are provided in the
1086 \fBEXAMPLES\fR section.
1087 .sp
1088 While you can specify any physical interface (or even loopback), be aware that
1089 you can also specify the virtual IP interface (see \fBvni\fR(7D)). The virtual
1090 IP interface is not associated with any physical hardware and is thus immune to
1091 hardware failures. You can specify any number of physical interfaces to use the
1092 source address hosted on a single virtual interface. This simplifies the
1093 configuration of routing-based multipathing. If one of the physical interfaces
1094 were to fail, communication would continue through one of the remaining,
1095 functioning physical interfaces. This scenario assumes that the reachability of
1096 the address hosted on the virtual interface is advertised in some manner, for
1097 example, through a routing protocol.
1098 .sp
1099 Because the \fBifconfig\fR \fBpreferred\fR option is applied to all interfaces,
1100 it is coarser-grained than the \fBusesrc\fR option. It will be overridden by
1101 \fBusesrc\fR and \fBsetsrc\fR (route subcommand), in that order.
1102 .sp
1103 IPMP and the \fBusesrc\fR option are mutually exclusive. That is, if an
1104 interface is part of an IPMP group or marked \fBSTANDBY\fR, then it cannot be
1105 specified by means of \fBusesrc\fR, and vice-versa.
1106 .RE
1107 
1108 .sp
1109 .ne 2
1110 .na
1111 \fB\fBxmit\fR\fR
1112 .ad
1113 .sp .6
1114 .RS 4n
1115 Enable a logical interface to transmit packets. This is the default behavior
1116 when the logical interface is up.
1117 .RE
1118 
1119 .sp
1120 .ne 2
1121 .na
1122 \fB\fB-xmit\fR\fR
1123 .ad
1124 .sp .6
1125 .RS 4n
1126 Disable transmission of packets on an interface. The interface will continue to
1127 receive packets.
1128 .RE
1129 
1130 .sp
1131 .ne 2
1132 .na
1133 \fB\fBzone\fR \fIzonename\fR\fR
1134 .ad
1135 .sp .6
1136 .RS 4n
1137 Place the logical interface in zone \fIzonename\fR. The named zone must be
1138 active in the kernel in the ready or running state. The interface is unplumbed
1139 when the zone is halted or rebooted. The zone must be configure to be an
1140 shared-IP zone. \fBzonecfg\fR(1M) is used to assign network interface names to
1141 exclusive-IP zones.
1142 .RE
1143 
1144 .sp
1145 .ne 2
1146 .na
1147 \fB\fB-zone\fR\fR
1148 .ad
1149 .sp .6
1150 .RS 4n
1151 Place IP interface in the global zone. This is the default.
1152 .RE
1153 
1154 .SH OPERANDS
1155 .sp
1156 .LP
1157 The \fIinterface\fR operand, as well as address parameters that affect it, are
1158 described below.
1159 .sp
1160 .ne 2
1161 .na
1162 \fB\fIinterface\fR\fR
1163 .ad
1164 .sp .6
1165 .RS 4n
1166 A string of one of the following forms:
1167 .RS +4
1168 .TP
1169 .ie t \(bu
1170 .el o
1171 \fIname physical-unit\fR, for example, \fBeri0\fR or \fBce1\fR
1172 .RE
1173 .RS +4
1174 .TP
1175 .ie t \(bu
1176 .el o
1177 \fIname physical-unit\fR\fB:\fR\fIlogical-unit\fR, for example, \fBeri0:1\fR
1178 .RE
1179 .RS +4
1180 .TP
1181 .ie t \(bu
1182 .el o
1183 \fBip.tun\fR\fIN\fR, \fBip6.tun\fR\fIN\fR, or \fBip6to4.tun\fR\fIN\fR for
1184 implicit IP tunnel links
1185 .RE
1186 If the interface name starts with a dash (-), it is interpreted as a set of
1187 options which specify a set of interfaces. In such a case, \fB-a\fR must be
1188 part of the options and any of the additional options below can be added in any
1189 order. If one of these interface names is given, the commands following it are
1190 applied to all of the interfaces that match.
1191 .sp
1192 .ne 2
1193 .na
1194 \fB\fB-a\fR\fR
1195 .ad
1196 .sp .6
1197 .RS 4n
1198 Apply the command to all interfaces of the specified address family. If no
1199 address family is supplied, either on the command line or by means of
1200 \fB/etc/default/inet_type\fR, then all address families will be selected.
1201 .RE
1202 
1203 .sp
1204 .ne 2
1205 .na
1206 \fB\fB-d\fR\fR
1207 .ad
1208 .sp .6
1209 .RS 4n
1210 Apply the commands to all "down" interfaces in the system.
1211 .RE
1212 
1213 .sp
1214 .ne 2
1215 .na
1216 \fB\fB-D\fR\fR
1217 .ad
1218 .sp .6
1219 .RS 4n
1220 Apply the commands to all interfaces not under \fBDHCP\fR (Dynamic Host
1221 Configuration Protocol) control.
1222 .RE
1223 
1224 .sp
1225 .ne 2
1226 .na
1227 \fB\fB-u\fR\fR
1228 .ad
1229 .sp .6
1230 .RS 4n
1231 Apply the commands to all "up" interfaces in the system.
1232 .RE
1233 
1234 .sp
1235 .ne 2
1236 .na
1237 \fB\fB-Z\fR\fR
1238 .ad
1239 .sp .6
1240 .RS 4n
1241 Apply the commands to all interfaces in the user's zone.
1242 .RE
1243 
1244 .sp
1245 .ne 2
1246 .na
1247 \fB\fB-4\fR\fR
1248 .ad
1249 .sp .6
1250 .RS 4n
1251 Apply the commands to all IPv4 interfaces.
1252 .RE
1253 
1254 .sp
1255 .ne 2
1256 .na
1257 \fB\fB-6\fR\fR
1258 .ad
1259 .sp .6
1260 .RS 4n
1261 Apply the commands to all IPv6 interfaces.
1262 .RE
1263 
1264 .RE
1265 
1266 .sp
1267 .ne 2
1268 .na
1269 \fB\fIaddress_family\fR\fR
1270 .ad
1271 .sp .6
1272 .RS 4n
1273 The address family is specified by the \fIaddress_family\fR parameter. The
1274 \fBifconfig\fR command currently supports the following families: \fBinet\fR
1275 and \fBinet6\fR. If no address family is specified, the default is \fBinet\fR.
1276 .sp
1277 \fBifconfig\fR honors the \fBDEFAULT_IP\fR setting in the
1278 \fB/etc/default/inet_type\fR file when it displays interface information . If
1279 \fBDEFAULT_IP\fR is set to \fBIP_VERSION4\fR, then \fBifconfig\fR will omit
1280 information that relates to IPv6 interfaces. However, when you explicitly
1281 specify an address family (\fBinet\fR or \fBinet6\fR) on the \fBifconfig\fR
1282 command line, the command line overrides the \fBDEFAULT_IP\fR settings.
1283 .RE
1284 
1285 .sp
1286 .ne 2
1287 .na
1288 \fB\fIaddress\fR\fR
1289 .ad
1290 .sp .6
1291 .RS 4n
1292 For the IPv4 family (\fBinet\fR), the \fIaddress\fR is either a host name
1293 present in the host name data base (see \fBhosts\fR(4)) or in the Network
1294 Information Service (NIS) map \fBhosts\fR, or an IPv4 address expressed in the
1295 Internet standard "dot notation".
1296 .sp
1297 For the IPv6 family (\fBinet6\fR), the \fIaddress\fR is either a host name
1298 present in the host name data base (see \fBhosts\fR(4)) or in the Network
1299 Information Service (\fBNIS\fR) map \fBipnode\fR, or an IPv6 address expressed
1300 in the Internet standard colon-separated hexadecimal format represented as
1301 \fIx:x:x:x:x:x:x:x\fR where \fIx\fR is a hexadecimal number between \fB0\fR and
1302 \fBFFFF\fR.
1303 .RE
1304 
1305 .sp
1306 .ne 2
1307 .na
1308 \fB\fIprefix_length\fR\fR
1309 .ad
1310 .sp .6
1311 .RS 4n
1312 For the IPv4 and IPv6 families (\fBinet\fR and \fBinet6\fR), the
1313 \fIprefix_length\fR is a number between 0 and the number of bits in the
1314 address. For \fBinet\fR, the number of bits in the address is 32; for
1315 \fBinet6\fR, the number of bits in the address is 128. The \fIprefix_length\fR
1316 denotes the number of leading set bits in the netmask.
1317 .RE
1318 
1319 .sp
1320 .ne 2
1321 .na
1322 \fB\fIdest_address\fR\fR
1323 .ad
1324 .sp .6
1325 .RS 4n
1326 If the \fIdest_address\fR parameter is supplied in addition to the
1327 \fIaddress\fR parameter, it specifies the address of the correspondent on the
1328 other end of a point-to-point link.
1329 .RE
1330 
1331 .sp
1332 .ne 2
1333 .na
1334 \fB\fItunnel_dest_address\fR\fR
1335 .ad
1336 .sp .6
1337 .RS 4n
1338 An address that is or will be reachable through an interface other than the
1339 tunnel being configured. This tells the tunnel where to send the tunneled
1340 packets. This address must not be the same as the interface destination address
1341 being configured.
1342 .RE
1343 
1344 .sp
1345 .ne 2
1346 .na
1347 \fB\fItunnel_src_address\fR\fR
1348 .ad
1349 .sp .6
1350 .RS 4n
1351 An address that is attached to an already configured interface that has been
1352 configured "up" with \fBifconfig\fR.
1353 .RE
1354 
1355 .SH INTERFACE FLAGS
1356 .sp
1357 .LP
1358 The \fBifconfig\fR command supports the following interface flags. The term
1359 "address" in this context refers to a logical interface, for example,
1360 \fBeri0:0\fR, while "interface" refers to the physical interface, for example,
1361 \fBeri0\fR.
1362 .sp
1363 .ne 2
1364 .na
1365 \fB\fBADDRCONF\fR\fR
1366 .ad
1367 .sp .6
1368 .RS 4n
1369 The address is from stateless \fBaddrconf\fR. The stateless mechanism allows a
1370 host to generate its own address using a combination of information advertised
1371 by routers and locally available information. Routers advertise prefixes that
1372 identify the subnet associated with the link, while the host generates an
1373 "interface identifier" that uniquely identifies an interface in a subnet. In
1374 the absence of information from routers, a host can generate link-local
1375 addresses. This flag is specific to IPv6.
1376 .RE
1377 
1378 .sp
1379 .ne 2
1380 .na
1381 \fB\fBANYCAST\fR\fR
1382 .ad
1383 .sp .6
1384 .RS 4n
1385 Indicates an \fBanycast\fR address. An \fBanycast\fR address identifies the
1386 nearest member of a group of systems that provides a particular type of
1387 service. An \fBanycast\fR address is assigned to a group of systems. Packets
1388 are delivered to the nearest group member identified by the \fBanycast\fR
1389 address instead of being delivered to all members of the group.
1390 .RE
1391 
1392 .sp
1393 .ne 2
1394 .na
1395 \fB\fBBROADCAST\fR\fR
1396 .ad
1397 .sp .6
1398 .RS 4n
1399 This \fBbroadcast\fR address is valid. This flag and \fBPOINTTOPOINT\fR are
1400 mutually exclusive
1401 .RE
1402 
1403 .sp
1404 .ne 2
1405 .na
1406 \fB\fBCoS\fR\fR
1407 .ad
1408 .sp .6
1409 .RS 4n
1410 This interface supports some form of Class of Service (CoS) marking. An example
1411 is the 802.1D user priority marking supported on \fBVLAN\fR interfaces. For
1412 IPMP IP interfaces, this will only be set if all interfaces in the group have
1413 CoS set.
1414 .sp
1415 Note that this flag is only set on interfaces over VLAN links and over Ethernet
1416 links that have their \fBdladm\fR(1M) \fBtagmode\fR link property set to
1417 \fBnormal\fR.
1418 .RE
1419 
1420 .sp
1421 .ne 2
1422 .na
1423 \fB\fBDEPRECATED\fR\fR
1424 .ad
1425 .sp .6
1426 .RS 4n
1427 This address is deprecated. This address will not be used as a source address
1428 for outbound packets unless there are no other addresses on this interface or
1429 an application has explicitly bound to this address. An IPv6 deprecated address
1430 is part of the standard mechanism for renumbering in IPv6 and will eventually
1431 be deleted when not used. For both IPv4 and IPv6, \fBDEPRECATED\fR is also set
1432 on all \fBNOFAILOVER\fR addresses, though this may change in a future release.
1433 .RE
1434 
1435 .sp
1436 .ne 2
1437 .na
1438 \fB\fBDHCPRUNNING\fR\fR
1439 .ad
1440 .sp .6
1441 .RS 4n
1442 The logical interface is managed by \fBdhcpagent\fR(1M).
1443 .RE
1444 
1445 .sp
1446 .ne 2
1447 .na
1448 \fB\fBDUPLICATE\fR\fR
1449 .ad
1450 .sp .6
1451 .RS 4n
1452 The logical interface has been disabled because the IP address configured on
1453 the interface is a duplicate. Some other node on the network is using this
1454 address. If the address was configured by DHCP or is temporary, the system will
1455 choose another automatically, if possible. Otherwise, the system will attempt
1456 to recover this address periodically and the interface will recover when the
1457 conflict has been removed from the network. Changing the address or netmask, or
1458 setting the logical interface to \fBup\fR will restart duplicate detection.
1459 Setting the interface to \fBdown\fR terminates recovery and removes the
1460 \fBDUPLICATE\fR flag.
1461 .RE
1462 
1463 .sp
1464 .ne 2
1465 .na
1466 \fB\fBFAILED\fR\fR
1467 .ad
1468 .sp .6
1469 .RS 4n
1470 The \fBin.mpathd\fR daemon has determined that the interface has failed.
1471 \fBFAILED\fR interfaces will not be used to send or receive IP data traffic. If
1472 this is set on a physical IP interface in an IPMP group, IP data traffic will
1473 continue to flow over other usable IP interfaces in the IPMP group. If this is
1474 set on an IPMP IP interface, the entire group has failed and no data traffic
1475 can be sent or received over any interfaces in that group.
1476 .RE
1477 
1478 .sp
1479 .ne 2
1480 .na
1481 \fB\fBFIXEDMTU\fR\fR
1482 .ad
1483 .sp .6
1484 .RS 4n
1485 The MTU has been set using the \fB-mtu\fR option. This flag is read-only.
1486 Interfaces that have this flag set have a fixed MTU value that is unaffected by
1487 dynamic MTU changes that can occur when drivers notify IP of link MTU changes.
1488 .RE
1489 
1490 .sp
1491 .ne 2
1492 .na
1493 \fB\fBINACTIVE\fR\fR
1494 .ad
1495 .sp .6
1496 .RS 4n
1497 The physical interface is functioning but is not used to send or receive data
1498 traffic according to administrative policy. This flag is initially set by the
1499 \fBstandby\fR subcommand and is subsequently controlled by \fBin.mpathd\fR. It
1500 also set when \fBFAILBACK=no\fR mode is enabled (see \fBin.mpathd\fR(1M)) to
1501 indicate that the IP interface has repaired but is not being used.
1502 .RE
1503 
1504 .sp
1505 .ne 2
1506 .na
1507 \fB\fBIPMP\fR\fR
1508 .ad
1509 .sp .6
1510 .RS 4n
1511 Indicates that this is an IPMP IP interface.
1512 .RE
1513 
1514 .sp
1515 .ne 2
1516 .na
1517 \fB\fBLOOPBACK\fR\fR
1518 .ad
1519 .sp .6
1520 .RS 4n
1521 Indicates that this is the loopback interface.
1522 .RE
1523 
1524 .sp
1525 .ne 2
1526 .na
1527 \fB\fBMULTI_BCAST\fR\fR
1528 .ad
1529 .sp .6
1530 .RS 4n
1531 Indicates that the broadcast address is used for multicast on this interface.
1532 .RE
1533 
1534 .sp
1535 .ne 2
1536 .na
1537 \fB\fBMULTICAST\fR\fR
1538 .ad
1539 .sp .6
1540 .RS 4n
1541 The interface supports multicast. \fBIP\fR assumes that any interface that
1542 supports hardware broadcast, or that is a point-to-point link, will support
1543 multicast.
1544 .RE
1545 
1546 .sp
1547 .ne 2
1548 .na
1549 \fB\fBNOARP\fR\fR
1550 .ad
1551 .sp .6
1552 .RS 4n
1553 There is no address resolution protocol (\fBARP\fR) for this interface that
1554 corresponds to all interfaces for a device without a broadcast address. This
1555 flag is specific to IPv4.
1556 .RE
1557 
1558 .sp
1559 .ne 2
1560 .na
1561 \fB\fBNOFAILOVER\fR\fR
1562 .ad
1563 .sp .6
1564 .RS 4n
1565 The address associated with this logical interface is available to
1566 \fBin.mpathd\fR for probe-based failure detection of the associated physical IP
1567 interface.
1568 .RE
1569 
1570 .sp
1571 .ne 2
1572 .na
1573 \fB\fBNOLOCAL\fR\fR
1574 .ad
1575 .sp .6
1576 .RS 4n
1577 The interface has no address , just an on-link subnet.
1578 .RE
1579 
1580 .sp
1581 .ne 2
1582 .na
1583 \fB\fBNONUD\fR\fR
1584 .ad
1585 .sp .6
1586 .RS 4n
1587 \fBNUD\fR is disabled on this interface. \fBNUD\fR (neighbor unreachability
1588 detection) is used by a node to track the reachability state of its neighbors,
1589 to which the node actively sends packets, and to perform any recovery if a
1590 neighbor is detected to be unreachable. This flag is specific to IPv6.
1591 .RE
1592 
1593 .sp
1594 .ne 2
1595 .na
1596 \fB\fBNORTEXCH\fR\fR
1597 .ad
1598 .sp .6
1599 .RS 4n
1600 The interface does not exchange routing information. For RIP-2, routing packets
1601 are not sent over this interface. Additionally, messages that appear to come
1602 over this interface receive no response. The subnet or address of this
1603 interface is not included in advertisements over other interfaces to other
1604 routers.
1605 .RE
1606 
1607 .sp
1608 .ne 2
1609 .na
1610 \fB\fBNOXMIT\fR\fR
1611 .ad
1612 .sp .6
1613 .RS 4n
1614 Indicates that the address does not transmit packets. RIP-2 also does not
1615 advertise this address.
1616 .RE
1617 
1618 .sp
1619 .ne 2
1620 .na
1621 \fB\fBOFFLINE\fR\fR
1622 .ad
1623 .sp .6
1624 .RS 4n
1625 The interface is offline and thus cannot send or receive IP data traffic. This
1626 is only set on IP interfaces in an IPMP group. See \fBif_mpadm\fR(1M) and
1627 \fBcfgadm\fR(1M).
1628 .RE
1629 
1630 .sp
1631 .ne 2
1632 .na
1633 \fB\fBPOINTOPOINT\fR\fR
1634 .ad
1635 .sp .6
1636 .RS 4n
1637 Indicates that the address is a point-to-point link. This flag and
1638 \fBBROADCAST\fR are mutually exclusive
1639 .RE
1640 
1641 .sp
1642 .ne 2
1643 .na
1644 \fB\fBPREFERRED\fR\fR
1645 .ad
1646 .sp .6
1647 .RS 4n
1648 This address is a preferred IPv6 source address. This address will be used as a
1649 source address for IPv6 communication with all IPv6 destinations, unless
1650 another address on the system is of more appropriate scope. The
1651 \fBDEPRECATED\fR flag takes precedence over the \fBPREFERRED\fR flag.
1652 .RE
1653 
1654 .sp
1655 .ne 2
1656 .na
1657 \fB\fBPRIVATE\fR\fR
1658 .ad
1659 .sp .6
1660 .RS 4n
1661 Indicates that this address is not advertised. For RIP-2, this interface is
1662 used to send advertisements. However, neither the subnet nor this address are
1663 included in advertisements to other routers.
1664 .RE
1665 
1666 .sp
1667 .ne 2
1668 .na
1669 \fB\fBPROMISC\fR\fR
1670 .ad
1671 .sp .6
1672 .RS 4n
1673 A read-only flag indicating that an interface is in promiscuous mode. All
1674 addresses associated with an interface in promiscuous mode will display (in
1675 response to \fBifconfig\fR \fB-a\fR, for example) the \fBPROMISC\fR flag.
1676 .RE
1677 
1678 .sp
1679 .ne 2
1680 .na
1681 \fB\fBROUTER\fR\fR
1682 .ad
1683 .sp .6
1684 .RS 4n
1685 Indicates that IP packets can be forwarded to and from the interface.
1686 .RE
1687 
1688 .sp
1689 .ne 2
1690 .na
1691 \fB\fBRUNNING\fR\fR
1692 .ad
1693 .sp .6
1694 .RS 4n
1695 Indicates that the required resources for an interface are allocated. For some
1696 interfaces this also indicates that the link is up. For IPMP IP interfaces,
1697 \fBRUNNING\fR is set as long as one IP interface in the group is active.
1698 .RE
1699 
1700 .sp
1701 .ne 2
1702 .na
1703 \fB\fBSTANDBY\fR\fR
1704 .ad
1705 .sp .6
1706 .RS 4n
1707 Indicates that this physical interface will not be used for data traffic unless
1708 another interface in the IPMP group becomes unusable. The \fBINACTIVE\fR and
1709 \fBFAILED\fR flags indicate whether it is actively being used.
1710 .RE
1711 
1712 .sp
1713 .ne 2
1714 .na
1715 \fB\fBTEMPORARY\fR\fR
1716 .ad
1717 .sp .6
1718 .RS 4n
1719 Indicates that this is a temporary IPv6 address as defined in RFC 3041.
1720 .RE
1721 
1722 .sp
1723 .ne 2
1724 .na
1725 \fB\fBUNNUMBERED\fR\fR
1726 .ad
1727 .sp .6
1728 .RS 4n
1729 This flag is set when the local IP address on the link matches the local
1730 address of some other link in the system
1731 .RE
1732 
1733 .sp
1734 .ne 2
1735 .na
1736 \fB\fBUP\fR\fR
1737 .ad
1738 .sp .6
1739 .RS 4n
1740 Indicates that the logical interface (and the associated physical interface) is
1741 up. The IP module will accept packets destined to \fBUP\fR addresses (unless
1742 the address is zero), along with any associated multicast and broadcast IP
1743 addresses. Similarly, the IP module will allow packets to be sent with an
1744 \fBUP\fR address as a source address.
1745 .RE
1746 
1747 .sp
1748 .ne 2
1749 .na
1750 \fB\fBVIRTUAL\fR\fR
1751 .ad
1752 .sp .6
1753 .RS 4n
1754 Indicates that the physical interface has no underlying hardware. It is not
1755 possible to transmit or receive packets through a virtual interface. These
1756 interfaces are useful for configuring local addresses that can be used on
1757 multiple interfaces. (See also the \fBusesrc\fR option.)
1758 .RE
1759 
1760 .sp
1761 .ne 2
1762 .na
1763 \fB\fBXRESOLV\fR\fR
1764 .ad
1765 .sp .6
1766 .RS 4n
1767 Indicates that the interface uses an IPv6 external resolver.
1768 .RE
1769 
1770 .SH LOGICAL INTERFACES
1771 .sp
1772 .LP
1773 Solaris \fBTCP/IP\fR allows multiple logical interfaces to be associated with a
1774 physical network interface. This allows a single machine to be assigned
1775 multiple \fBIP\fR addresses, even though it may have only one network
1776 interface. Physical network interfaces have names of the form \fIdriver-name
1777 physical-unit-number\fR, while logical interfaces have names of the form
1778 \fIdriver-name physical-unit-number\fR\fB:\fR\fIlogical-unit-number\fR. A
1779 physical interface is configured into the system using the \fBplumb\fR command.
1780 For example:
1781 .sp
1782 .in +2
1783 .nf
1784 example% \fBifconfig eri0 plumb\fR
1785 .fi
1786 .in -2
1787 .sp
1788 
1789 .sp
1790 .LP
1791 Once a physical interface has been "plumbed", logical interfaces associated
1792 with the physical interface can be configured by separate \fB-plumb\fR or
1793 \fB-addif\fR options to the \fBifconfig\fR command.
1794 .sp
1795 .in +2
1796 .nf
1797 example% \fBifconfig eri0:1 plumb\fR
1798 .fi
1799 .in -2
1800 .sp
1801 
1802 .sp
1803 .LP
1804 allocates a specific logical interface associated with the physical interface
1805 \fBeri0\fR. The command
1806 .sp
1807 .in +2
1808 .nf
1809 example% \fBifconfig eri0 addif 192.168.200.1/24 up\fR
1810 .fi
1811 .in -2
1812 .sp
1813 
1814 .sp
1815 .LP
1816 allocates the next available logical unit number on the \fBeri0\fR physical
1817 interface and assigns an \fIaddress\fR and \fIprefix_length\fR.
1818 .sp
1819 .LP
1820 A logical interface can be configured with parameters (
1821 \fIaddress\fR,\fIprefix_length\fR, and so on) different from the physical
1822 interface with which it is associated. Logical interfaces that are associated
1823 with the same physical interface can be given different parameters as well.
1824 Each logical interface must be associated with an existing and "up" physical
1825 interface. So, for example, the logical interface \fBeri0:1\fR can only be
1826 configured after the physical interface \fBeri0\fR has been plumbed.
1827 .sp
1828 .LP
1829 To delete a logical interface, use the \fBunplumb\fR or \fBremoveif\fR options.
1830 For example,
1831 .sp
1832 .in +2
1833 .nf
1834 example% \fBifconfig eri0:1 down unplumb\fR
1835 .fi
1836 .in -2
1837 .sp
1838 
1839 .sp
1840 .LP
1841 will delete the logical interface \fBeri0:1\fR.
1842 .SH IP MULTIPATHING GROUPS
1843 .sp
1844 .LP
1845 Physical interfaces that share the same link-layer broadcast domain \fBmust\fR
1846 be collected into a single IP Multipathing (IPMP) group using the \fBgroup\fR
1847 subcommand. Each IPMP group has an associated IPMP IP interface, which can
1848 either be explicitly created (the preferred method) by using the \fBipmp\fR
1849 subcommand or implicitly created by \fBifconfig\fR in response to placing an IP
1850 interface into a new IPMP group. Implicitly-created IPMP interfaces will be
1851 named \fBipmp\fR\fIN\fR where \fIN\fR is the lowest integer that does not
1852 conflict with an existing IP interface name or IPMP group name.
1853 .sp
1854 .LP
1855 Each IPMP IP interface is created with a matching IPMP group name, though it
1856 can be changed using the \fBgroup\fR subcommand. Each IPMP IP interface hosts a
1857 set of highly-available IP addresses. These addresses will remain reachable so
1858 long as at least one interface in the group is active, where "active" is
1859 defined as having at least one \fBUP\fR address and having \fBINACTIVE\fR,
1860 \fBFAILED\fR, and \fBOFFLINE\fR clear. IP addresses hosted on the IPMP IP
1861 interface may either be configured statically or configured through DHCP by
1862 means of the \fBdhcp\fR subcommand.
1863 .sp
1864 .LP
1865 Interfaces assigned to the same IPMP group are treated as equivalent and
1866 monitored for failure by \fBin.mpathd\fR. Provided that active interfaces in
1867 the group remain, IP interface failures (and any subsequent repairs) are
1868 handled transparently to sockets-based applications. IPMP is also integrated
1869 with the Dynamic Reconfiguration framework (see \fBcfgadm\fR(1M)), which
1870 enables network adapters to be replaced in a way that is invisible to
1871 sockets-based applications.
1872 .sp
1873 .LP
1874 The IP module automatically load-spreads all outbound traffic across all active
1875 interfaces in an IPMP group. Similarly, all \fBUP\fR addresses hosted on the
1876 IPMP IP interface will be distributed across the active interfaces to promote
1877 inbound load-spreading. The \fBipmpstat\fR(1M) utility allows many aspects of
1878 the IPMP subsystem to be observed, including the current binding of IP data
1879 addresses to IP interfaces.
1880 .sp
1881 .LP
1882 When an interface is placed into an IPMP group, any \fBUP\fR logical interfaces
1883 are "migrated" to the IPMP IP interface for use by the group, unless:
1884 .RS +4
1885 .TP
1886 .ie t \(bu
1887 .el o
1888 the logical interface is marked \fBNOFAILOVER\fR;
1889 .RE
1890 .RS +4
1891 .TP
1892 .ie t \(bu
1893 .el o
1894 the logical interface hosts an IPv6 link-local address;
1895 .RE
1896 .RS +4
1897 .TP
1898 .ie t \(bu
1899 .el o
1900 the logical interface hosts an IPv4 0.0.0.0 address.
1901 .RE
1902 .sp
1903 .LP
1904 Likewise, once an interface is in a group, if changes are made to a logical
1905 interface such that it is \fBUP\fR and not exempted by one of the conditions
1906 above, it will also migrate to the associated IPMP IP interface. Logical
1907 interfaces never migrate back, even if the physical interface that contributed
1908 the address is removed from the group.
1909 .sp
1910 .LP
1911 Each interface placed into an IPMP group may be optionally configured with a
1912 "test" address that \fBin.mpathd\fR will use for probe-based failure detection;
1913 see \fBin.mpathd\fR(1M). These addresses must be marked \fBNOFAILOVER\fR (using
1914 the \fB-failover\fR subcommand) prior to being marked \fBUP\fR. Test addresses
1915 may also be acquired through DHCP by means of the \fBdhcp\fR subcommand.
1916 .sp
1917 .LP
1918 For more background on IPMP, please see the IPMP-related chapters of the
1919 \fISystem Administration Guide: Network Interfaces and Network
1920 Virtualization\fR.
1921 .SH CONFIGURING IPV6 INTERFACES
1922 .sp
1923 .LP
1924 When an IPv6 physical interface is plumbed and configured "up" with
1925 \fBifconfig\fR, it is automatically assigned an IPv6 link-local address for
1926 which the last 64 bits are calculated from the \fBMAC\fR address of the
1927 interface.
1928 .sp
1929 .in +2
1930 .nf
1931 example% \fBifconfig eri0 inet6 plumb up\fR
1932 .fi
1933 .in -2
1934 .sp
1935 
1936 .sp
1937 .LP
1938 The following example shows that the link-local address has a prefix of
1939 \fBfe80::/10\fR.
1940 .sp
1941 .in +2
1942 .nf
1943 example% \fBifconfig eri0 inet6\fR
1944 ce0: flags=2000841<UP,RUNNING,MULTICAST,IPv6>
1945            mtu 1500 index 2 \
1946         inet6 fe80::a00:20ff:fe8e:f3ad/10
1947 .fi
1948 .in -2
1949 .sp
1950 
1951 .sp
1952 .LP
1953 Link-local addresses are only used for communication on the local subnet and
1954 are not visible to other subnets.
1955 .sp
1956 .LP
1957 If an advertising IPv6 router exists on the link advertising prefixes, then the
1958 newly plumbed IPv6 interface will autoconfigure logical interface(s) depending
1959 on the prefix advertisements. For example, for the prefix advertisement
1960 \fB2001:0db8:3c4d:0:55::/64\fR, the autoconfigured interface will look like:
1961 .sp
1962 .in +2
1963 .nf
1964 eri0:2: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6>
1965           mtu 1500 index 2
1966         inet6 2001:0db8:3c4d:55:a00:20ff:fe8e:f3ad/64
1967 .fi
1968 .in -2
1969 .sp
1970 
1971 .sp
1972 .LP
1973 Even if there are no prefix advertisements on the link, you can still assign
1974 global addresses manually, for example:
1975 .sp
1976 .in +2
1977 .nf
1978 example% \fBifconfig eri0 inet6 addif \e
1979 2001:0db8:3c4d:55:a00:20ff:fe8e:f3ad/64 up\fR
1980 .fi
1981 .in -2
1982 .sp
1983 
1984 .sp
1985 .LP
1986 To configure boot-time defaults for the interface \fBeri0\fR, place the
1987 following entry in the \fB/etc/hostname6.eri0\fR file:
1988 .sp
1989 .in +2
1990 .nf
1991 addif 2001:0db8:3c4d:55:a00:20ff:fe8e:f3ad/64 up
1992 .fi
1993 .in -2
1994 
1995 .SS "Configuring IP-over-IP Tunnel Interfaces"
1996 .sp
1997 .LP
1998 An IP tunnel is conceptually comprised of two parts: a virtual link between two
1999 or more IP nodes, and an IP interface above this link which allows the system
2000 to transmit and receive IP packets encapsulated by the underlying link.
2001 .sp
2002 .LP
2003 The \fBdladm\fR(1M) command is used to configure tunnel links, and
2004 \fBifconfig\fR is used to configure IP interfaces over those tunnel links.  An
2005 IPv4-over-IPv4 tunnel is created by plumbing an IPv4 interface over an IPv4
2006 tunnel link.  An IPv6-over-IPv4 tunnel is created by plumbing an IPv6 interface
2007 over an IPv6 tunnel link, and so forth.
2008 .sp
2009 .LP
2010 When IPv6 interfaces are plumbed over IP tunnel links, their IPv6 addresses are
2011 automatically set. For IPv4 and IPv6 tunnels, source and destination link-local
2012 addresses of the form \fBfe80::\fR\fIinterface-id\fR are configured. For IPv4
2013 tunnels, the \fIinterface-id\fR is the IPv4 tunnel source or destination
2014 address. For IPv6 tunnels, the \fIinterface-id\fR is the last 64 bits of the
2015 IPv6 tunnel source or destination address. For example, for an IPv4 tunnel
2016 between 10.1.2.3 and 10.4.5.6, the IPv6 link-local source and destination
2017 addresses of the IPv6 interface would be \fBfe80::a01:203\fR and
2018 \fBfe80::a04:506\fR. For an IPv6 tunnel between \fB2000::1234:abcd\fR and
2019 \fB3000::5678:abcd\fR, the IPv6 link-local source and destination addresses of
2020 the interface would be \fBfe80::1234:abcd\fR and \fBfe80::5678:abcd\fR. These
2021 default link-local addresses can be overridden by specifying the addresses
2022 explicitly, as with any other point-to-point interface.
2023 .sp
2024 .LP
2025 For 6to4 tunnels, a 6to4 global address of the form \fB2002:\fItsrc\fR::1/16\fR
2026 is configured. The \fItsrc\fR portion is the tunnel source IPv4 address. The
2027 prefix length of the 6to4 interface is automatically set to 16, as all 6to4
2028 packets (destinations in the \fB2002::/16\fR range) are forwarded to the 6to4
2029 tunnel interface. For example, for a 6to4 link with a tunnel source of
2030 75.1.2.3, the IPv6 interface would have an address of
2031 \fB2002:4b01:203::1/16\fR.
2032 .sp
2033 .LP
2034 Additional IPv6 addresses can be added using the \fBaddif\fR option or by
2035 plumbing additional logical interfaces.
2036 .sp
2037 .LP
2038 For backward compatibility, the plumbing of tunnel IP interfaces with special
2039 names will implicitly result in the creation of tunnel links without invoking
2040 \fBdladm create-iptun\fR. These tunnel names are:
2041 .sp
2042 .ne 2
2043 .na
2044 \fB\fBip.tun\fR\fIN\fR\fR
2045 .ad
2046 .RS 15n
2047 An IPv4 tunnel
2048 .RE
2049 
2050 .sp
2051 .ne 2
2052 .na
2053 \fB\fBip6.tun\fR\fIN\fR\fR
2054 .ad
2055 .RS 15n
2056 An IPv6 tunnel
2057 .RE
2058 
2059 .sp
2060 .ne 2
2061 .na
2062 \fB\fBip.6to4tun\fR\fIN\fR\fR
2063 .ad
2064 .RS 15n
2065 A 6to4 tunnel
2066 .RE
2067 
2068 .sp
2069 .LP
2070 These tunnels are "implicit tunnels", denoted with the \fBi\fR flag in \fBdladm
2071 show-iptun\fR output. The tunnel links over which these special IP interfaces
2072 are plumbed are automatically created, and they are automatically deleted when
2073 the last reference is released (that is, when the last IP interface is
2074 unplumbed).
2075 .sp
2076 .LP
2077 The \fBtsrc\fR, \fBtdst\fR, \fBencaplim\fR, and \fBhoplimit\fR options to
2078 \fBifconfig\fR are obsolete and maintained only for backward compatibility.
2079 They are equivalent to their \fBdladm\fR(1M) counterparts.
2080 .SS "Display of Tunnel Security Settings"
2081 .sp
2082 .LP
2083 The \fBifconfig\fR output for IP tunnel interfaces indicates whether IPsec
2084 policy is configured for the underlying IP tunnel link. For example, a line of
2085 the following form will be displayed if IPsec policy is present:
2086 .sp
2087 .in +2
2088 .nf
2089 tunnel security settings  -->  use 'ipsecconf -ln -i ip.tun1'
2090 .fi
2091 .in -2
2092 .sp
2093 
2094 .sp
2095 .LP
2096 If you do net set security policy, using either \fBifconfig\fR or
2097 \fBipsecconf\fR(1M), there is no tunnel security setting displayed.
2098 .SH EXAMPLES
2099 .LP
2100 \fBExample 1 \fRUsing the \fBifconfig\fR Command
2101 .sp
2102 .LP
2103 If your workstation is not attached to an Ethernet, the network interface, for
2104 example, \fBeri0\fR, should be marked "down" as follows:
2105 
2106 .sp
2107 .in +2
2108 .nf
2109 example% \fBifconfig eri0 down\fR
2110 .fi
2111 .in -2
2112 .sp
2113 
2114 .LP
2115 \fBExample 2 \fRPrinting Addressing Information
2116 .sp
2117 .LP
2118 To print out the addressing information for each interface, use the following
2119 command:
2120 
2121 .sp
2122 .in +2
2123 .nf
2124 example% \fBifconfig -a\fR
2125 .fi
2126 .in -2
2127 .sp
2128 
2129 .LP
2130 \fBExample 3 \fRResetting the Broadcast Address
2131 .sp
2132 .LP
2133 To reset each interface's broadcast address after the netmasks have been
2134 correctly set, use the next command:
2135 
2136 .sp
2137 .in +2
2138 .nf
2139 example% \fBifconfig -a broadcast +\fR
2140 .fi
2141 .in -2
2142 .sp
2143 
2144 .LP
2145 \fBExample 4 \fRChanging the Ethernet Address
2146 .sp
2147 .LP
2148 To change the Ethernet address for interface \fBce0\fR, use the following
2149 command:
2150 
2151 .sp
2152 .in +2
2153 .nf
2154 example% \fBifconfig ce0 ether aa:1:2:3:4:5\fR
2155 .fi
2156 .in -2
2157 .sp
2158 
2159 .LP
2160 \fBExample 5 \fRConfiguring an IP-in-IP Tunnel
2161 .sp
2162 .LP
2163 To configure an IP-in-IP tunnel, first create an IP tunnel link (\fBtunsrc\fR
2164 and \fBtundst\fR are hostnames with corresponding IPv4 entries in
2165 \fB/etc/hosts\fR):
2166 
2167 .sp
2168 .in +2
2169 .nf
2170 example% \fBdladm create-iptun -T ipv4 -s tunsrc -d tundst tun0\fR
2171 .fi
2172 .in -2
2173 .sp
2174 
2175 .sp
2176 .LP
2177 Then plumb a point-to-point interface, supplying the source and destination
2178 addresses (\fBmysrc\fR and \fBthedst\fR are hostnames with corresponding IPv4
2179 entries in \fB/etc/hosts\fR):
2180 
2181 .sp
2182 .in +2
2183 .nf
2184 example% \fBifconfig tun0 plumb mysrc thedst up\fR
2185 .fi
2186 .in -2
2187 .sp
2188 
2189 .sp
2190 .LP
2191 Use \fBipsecconf\fR(1M), as described above, to configure tunnel security
2192 properties.
2193 
2194 .sp
2195 .LP
2196 Configuring IPv6 tunnels is done by using a tunnel type of \fBipv6\fR with
2197 \fBcreate-iptun\fR. IPv6 interfaces can also be plumbed over either type of
2198 tunnel.
2199 
2200 .LP
2201 \fBExample 6 \fRConfiguring 6to4 Tunnels
2202 .sp
2203 .LP
2204 To configure 6to4 tunnels, first create a 6to4 tunnel link (\fBmyv4addr\fR is a
2205 hostname with a corresponding IPv4 entry in \fB/etc/hosts\fR):
2206 
2207 .sp
2208 .in +2
2209 .nf
2210 example% \fBdladm create-iptun -T 6to4 -s myv4addr my6to4tun0\fR
2211 .fi
2212 .in -2
2213 .sp
2214 
2215 .sp
2216 .LP
2217 Then an IPv6 interface is plumbed over this link:
2218 
2219 .sp
2220 .in +2
2221 .nf
2222 example% \fBifconfig my6to4tun0 inet6 plumb up\fR
2223 .fi
2224 .in -2
2225 .sp
2226 
2227 .sp
2228 .LP
2229 The IPv6 address of the interface is automatically set as described above.
2230 
2231 .LP
2232 \fBExample 7 \fRConfiguring IP Forwarding on an Interface
2233 .sp
2234 .LP
2235 To enable IP forwarding on a single interface, use the following command:
2236 
2237 .sp
2238 .in +2
2239 .nf
2240 example% \fBifconfig eri0 router\fR
2241 .fi
2242 .in -2
2243 .sp
2244 
2245 .sp
2246 .LP
2247 To disable IP forwarding on a single interface, use the following command:
2248 
2249 .sp
2250 .in +2
2251 .nf
2252 example% \fBifconfig eri0 -router\fR
2253 .fi
2254 .in -2
2255 .sp
2256 
2257 .LP
2258 \fBExample 8 \fRConfiguring Source Address Selection Using a Virtual Interface
2259 .sp
2260 .LP
2261 The following command configures source address selection such that every
2262 packet that is locally generated with no bound source address and going out on
2263 \fBqfe2\fR prefers a source address hosted on \fBvni0\fR.
2264 
2265 .sp
2266 .in +2
2267 .nf
2268 example% \fBifconfig qfe2 usesrc vni0\fR
2269 .fi
2270 .in -2
2271 .sp
2272 
2273 .sp
2274 .LP
2275 The \fBifconfig\fR \fB-a\fR output for the \fBqfe2\fR and \fBvni0\fR interfaces
2276 displays as follows:
2277 
2278 .sp
2279 .in +2
2280 .nf
2281 qfe2: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu
2282   1500 index 4
2283   usesrc vni0
2284   inet 1.2.3.4 netmask ffffff00 broadcast 1.2.3.255
2285   ether 0:3:ba:17:4b:e1
2286 vni0: flags=20011100c1<UP,RUNNING,NOARP,NOXMIT,ROUTER,IPv4,VIRTUAL>
2287   mtu 0 index 5
2288   srcof qfe2
2289   inet 3.4.5.6 netmask ffffffff
2290 .fi
2291 .in -2
2292 
2293 .sp
2294 .LP
2295 Observe, above, the \fBusesrc\fR and \fBsrcof\fR keywords in the \fBifconfig\fR
2296 output. These keywords also appear on the logical instances of the physical
2297 interface, even though this is a per-physical interface parameter. There is no
2298 \fBsrcof\fR keyword in \fBifconfig\fR for configuring interfaces. This
2299 information is determined automatically from the set of interfaces that have
2300 \fBusesrc\fR set on them.
2301 
2302 .sp
2303 .LP
2304 The following command, using the \fBnone\fR keyword, undoes the effect of the
2305 preceding \fBifconfig\fR \fBusesrc\fR command.
2306 
2307 .sp
2308 .in +2
2309 .nf
2310 example% \fBifconfig qfe2 usesrc none\fR
2311 .fi
2312 .in -2
2313 .sp
2314 
2315 .sp
2316 .LP
2317 Following this command, \fBifconfig\fR \fB-a\fR output displays as follows:
2318 
2319 .sp
2320 .in +2
2321 .nf
2322 qfe2: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu
2323   1500 index 4
2324   inet 1.2.3.4 netmask ffffff00 broadcast 1.2.3.255
2325   ether 0:3:ba:17:4b:e1
2326 vni0: flags=20011100c1<UP,RUNNING,NOARP,NOXMIT,ROUTER,IPv4,VIRTUAL>
2327   mtu 0 index 5
2328   inet 3.4.5.6 netmask ffffffff
2329 .fi
2330 .in -2
2331 
2332 .sp
2333 .LP
2334 Note the absence of the \fBusesrc\fR and \fBsrcof\fR keywords in the output
2335 above.
2336 
2337 .LP
2338 \fBExample 9 \fRConfiguring Source Address Selection for an IPv6 Address
2339 .sp
2340 .LP
2341 The following command configures source address selection for an IPv6 address,
2342 selecting a source address hosted on \fBvni0\fR.
2343 
2344 .sp
2345 .in +2
2346 .nf
2347 example% \fBifconfig qfe1 inet6 usesrc vni0\fR
2348 .fi
2349 .in -2
2350 .sp
2351 
2352 .sp
2353 .LP
2354 Following this command, \fBifconfig\fR \fB-a\fR output displays as follows:
2355 
2356 .sp
2357 .in +2
2358 .nf
2359 qfe1: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3
2360   usesrc vni0
2361   inet6 fe80::203:baff:fe17:4be0/10
2362   ether 0:3:ba:17:4b:e0
2363 vni0: flags=2002210041<UP,RUNNING,NOXMIT,NONUD,IPv6,VIRTUAL> mtu 0
2364   index 5
2365   srcof qfe1
2366   inet6 fe80::203:baff:fe17:4444/128
2367 vni0:1: flags=2002210040<RUNNING,NOXMIT,NONUD,IPv6,VIRTUAL> mtu 0
2368   index 5
2369   srcof qfe1
2370   inet6 fec0::203:baff:fe17:4444/128
2371 vni0:2: flags=2002210040<RUNNING,NOXMIT,NONUD,IPv6,VIRTUAL> mtu 0
2372   index 5
2373   srcof qfe1
2374   inet6 2000::203:baff:fe17:4444/128
2375 .fi
2376 .in -2
2377 
2378 .sp
2379 .LP
2380 Depending on the scope of the destination of the packet going out on
2381 \fBqfe1\fR, the appropriately scoped source address is selected from \fBvni0\fR
2382 and its aliases.
2383 
2384 .LP
2385 \fBExample 10 \fRUsing Source Address Selection with Shared-IP Zones
2386 .sp
2387 .LP
2388 The following is an example of how the \fBusesrc\fR feature can be used with
2389 the \fBzones\fR(5) facility in Solaris. The following commands are invoked in
2390 the global zone:
2391 
2392 .sp
2393 .in +2
2394 .nf
2395 example% \fBifconfig hme0 usesrc vni0\fR
2396 example% \fBifconfig eri0 usesrc vni0\fR
2397 example% i\fBfconfig qfe0 usesrc vni0\fR
2398 .fi
2399 .in -2
2400 .sp
2401 
2402 .sp
2403 .LP
2404 Following the preceding commands, the \fBifconfig\fR \fB-a\fR output for the
2405 virtual interfaces would display as:
2406 
2407 .sp
2408 .in +2
2409 .nf
2410 vni0: flags=20011100c1<UP,RUNNING,NOARP,NOXMIT,ROUTER,IPv4,VIRTUAL>
2411    mtu 0 index 23
2412    srcof hme0 eri0 qfe0
2413    inet 10.0.0.1 netmask ffffffff
2414 vni0:1:
2415    flags=20011100c1<UP,RUNNING,NOARP,NOXMIT,ROUTER,IPv4,VIRTUAL> mtu 0
2416    index 23
2417    zone test1
2418    srcof hme0 eri0 qfe0
2419    inet 10.0.0.2 netmask ffffffff
2420 vni0:2:
2421    flags=20011100c1<UP,RUNNING,NOARP,NOXMIT,ROUTER,IPv4,VIRTUAL> mtu 0
2422    index 23
2423    zone test2
2424    srcof hme0 eri0 qfe0
2425    inet 10.0.0.3 netmask ffffffff
2426 vni0:3:
2427    flags=20011100c1<UP,RUNNING,NOARP,NOXMIT,ROUTER,IPv4,VIRTUAL> mtu 0
2428    index 23
2429    zone test3
2430    srcof hme0 eri0 qfe0
2431    inet 10.0.0.4 netmask ffffffff
2432 .fi
2433 .in -2
2434 
2435 .sp
2436 .LP
2437 There is one virtual interface alias per zone (\fBtest1\fR, \fBtest2\fR, and
2438 \fBtest3\fR). A source address from the virtual interface alias in the same
2439 zone is selected. The virtual interface aliases were created using
2440 \fBzonecfg\fR(1M) as follows:
2441 
2442 .sp
2443 .in +2
2444 .nf
2445 example% \fBzonecfg -z test1\fR
2446 zonecfg:test1> \fBadd net\fR
2447 zonecfg:test1:net> \fBset physical=vni0\fR
2448 zonecfg:test1:net> \fBset address=10.0.0.2\fR
2449 .fi
2450 .in -2
2451 .sp
2452 
2453 .sp
2454 .LP
2455 The \fBtest2\fR and \fBtest3\fR zone interfaces and addresses are created in
2456 the same way.
2457 
2458 .LP
2459 \fBExample 11 \fRTurning Off DHCPv6
2460 .sp
2461 .LP
2462 The following example shows how to disable automatic use of DHCPv6 on all
2463 interfaces, and immediately shut down DHCPv6 on the interface named \fBhme0\fR.
2464 See \fBin.ndpd\fR(1M) and \fBndpd.conf\fR(4) for more information on the
2465 automatic DHCPv6 configuration mechanism.
2466 
2467 .sp
2468 .in +2
2469 .nf
2470 example% \fBecho ifdefault StatefulAddrConf false >> /etc/inet/ndpd.conf\fR
2471 example% \fBpkill -HUP -x in.ndpd\fR
2472 example% \fBifconfig hme0 dhcp release\fR
2473 .fi
2474 .in -2
2475 .sp
2476 
2477 .SH FILES
2478 .sp
2479 .ne 2
2480 .na
2481 \fB\fB/etc/netmasks\fR\fR
2482 .ad
2483 .sp .6
2484 .RS 4n
2485 Netmask data.
2486 .RE
2487 
2488 .sp
2489 .ne 2
2490 .na
2491 \fB\fB/etc/default/inet_type\fR\fR
2492 .ad
2493 .sp .6
2494 .RS 4n
2495 Default Internet protocol type.
2496 .RE
2497 
2498 .SH ATTRIBUTES
2499 .sp
2500 .LP
2501 See \fBattributes\fR(5) for descriptions of the following attributes:
2502 .sp
2503 
2504 .sp
2505 .TS
2506 box;
2507 c | c
2508 l | l .
2509 ATTRIBUTE TYPE  ATTRIBUTE VALUE
2510 _
2511 T{
2512 Interface Stability for command-line options
2513 T}      Committed
2514 _
2515 Interface Stability for command output  Uncommitted
2516 .TE
2517 
2518 .SH SEE ALSO
2519 .sp
2520 .LP
2521 \fBdhcpinfo\fR(1), \fBcfgadm\fR(1M), \fBdhcpagent\fR(1M), \fBdladm\fR(1M),
2522 \fBif_mpadm\fR(1M), \fBin.mpathd\fR(1M), \fBin.ndpd\fR(1M),
2523 \fBin.routed\fR(1M), \fBipmpstat\fR(1M), \fBipsecconf\fR(1M), \fBndd\fR(1M),
2524 \fBnetstat\fR(1M), \fBzoneadm\fR(1M), \fBzonecfg\fR(1M), \fBethers\fR(3SOCKET),
2525 \fBgethostbyname\fR(3NSL), \fBgetnetbyname\fR(3SOCKET), \fBhosts\fR(4),
2526 \fBinet_type\fR(4), \fBndpd.conf\fR(4), \fBnetmasks\fR(4), \fBnetworks\fR(4),
2527 \fBnsswitch.conf\fR(4), \fBattributes\fR(5), \fBprivileges\fR(5),
2528 \fBzones\fR(5), \fBarp\fR(7P), \fBipsecah\fR(7P), \fBipsecesp\fR(7P)
2529 .sp
2530 .LP
2531 \fISystem Administration Guide: IP Services\fR
2532 .SH DIAGNOSTICS
2533 .sp
2534 .LP
2535 \fBifconfig\fR sends messages that indicate if:
2536 .RS +4
2537 .TP
2538 .ie t \(bu
2539 .el o
2540 the specified interface does not exist
2541 .RE
2542 .RS +4
2543 .TP
2544 .ie t \(bu
2545 .el o
2546 the requested address is unknown
2547 .RE
2548 .RS +4
2549 .TP
2550 .ie t \(bu
2551 .el o
2552 the user is not privileged and tried to alter an interface's configuration
2553 .RE
2554 .SH NOTES
2555 .sp
2556 .LP
2557 Do not select the names \fBbroadcast\fR, \fBdown\fR, \fBprivate\fR,
2558 \fBtrailers\fR, \fBup\fR or other possible option names when you choose host
2559 names. If you choose any one of these names as host names, it can cause unusual
2560 problems that are extremely difficult to diagnose.