Как включить ipv6 на роутере cisco

An aggregatable global address is an IPv6 address from the aggregatable global unicast prefix. The structure of aggregatable
global unicast addresses enables strict aggregation of routing prefixes that limits the number of routing table entries in
the global routing table. Aggregatable global addresses are used on links that are aggregated upward through organizations,
and eventually to the Internet service providers (ISPs).

Aggregatable global IPv6 addresses are defined by a global routing prefix, a subnet ID, and an interface ID. Except for addresses
that start with binary 000, all global unicast addresses have a 64-bit interface ID. The IPv6 global unicast address allocation
uses the range of addresses that start with binary value 001 (2000::/3). The figure below shows the structure of an aggregatable
global address.

Addresses with a prefix of 2000::/3 (001) through E000::/3 (111) are required to have 64-bit interface identifiers in the
extended universal identifier (EUI)-64 format. The Internet Assigned Numbers Authority (IANA) allocates the IPv6 address space
in the range of 2000::/16 to regional registries.

The aggregatable global address typically consists of a 48-bit global routing prefix and a 16-bit subnet ID or Site-Level
Aggregator (SLA). In the IPv6 aggregatable global unicast address format document (RFC 2374), the global routing prefix included
two other hierarchically structured fields named Top-Level Aggregator (TLA) and Next-Level Aggregator (NLA). The IETF decided
to remove the TLS and NLA fields from the RFCs because these fields are policy-based. Some existing IPv6 networks deployed
before the change might still be using networks based on the older architecture.

A 16-bit subnet field called the subnet ID could be used by individual organizations to create their own local addressing
hierarchy and to identify subnets. A subnet ID is similar to a subnet in IPv4, except that an organization with an IPv6 subnet
ID can support up to 65,535 individual subnets.

An interface ID is used to identify interfaces on a link. The interface ID must be unique to the link. It may also be unique
over a broader scope. In many cases, an interface ID will be the same as or based on the link-layer address of an interface.
Interface IDs used in aggregatable global unicast and other IPv6 address types must be 64 bits long and constructed in the
modified EUI-64 format.

Interface IDs are constructed in the modified EUI-64 format in one of the following ways:

• For all IEEE 802 interface types (for example, FDDI interfaces), the first three octets (24 bits) are taken from the Organizationally
  Unique Identifier (OUI) of the 48-bit link-layer address (the Media Access Control [MAC] address) of the interface, the fourth
  and fifth octets (16 bits) are a fixed hexadecimal value of FFFE, and the last three octets (24 bits) are taken from the last
  three octets of the MAC address. The construction of the interface ID is completed by setting the Universal/Local (U/L) bit—the
  seventh bit of the first octet—to a value of 0 or 1. A value of 0 indicates a locally administered identifier; a value of
  1 indicates a globally unique IPv6 interface identifier.

• For all other interface types (for example, serial, loopback, ATM, Frame Relay, and tunnel interface types—except tunnel
  interfaces used with IPv6 overlay tunnels), the interface ID is constructed in the same way as the interface ID for IEEE 802
  interface types; however, the first MAC address from the pool of MAC addresses in the router is used to construct the identifier
  (because the interface does not have a MAC address).

• For tunnel interface types that are used with IPv6 overlay tunnels, the interface ID is the IPv4 address assigned to the
  tunnel interface with all zeros in the high-order 32 bits of the identifier.

Note

For interfaces using Point-to-Point Protocol (PPP), given that the interfaces at both ends of the connection might have the same MAC address, the interface identifiers used at both ends of the connection are negotiated (picked randomly and, if necessary, reconstructed) until both identifiers are unique. The first MAC address in the router is used to construct the identifier for interfaces using PPP.

If no IEEE 802 interface types are in the router, link-local IPv6 addresses are generated on the interfaces in the router
in the following sequence:

1. The router is queried for MAC addresses (from the pool of MAC addresses in the router).

2. If no MAC addresses are available in the router, the serial number of the router is used to form the link-local addresses.

3. If the serial number of the router cannot be used to form the link-local addresses, the router uses a message digest algorithm
   5 (MD5) hash to determine the MAC address of the router from the hostname of the router.

A link-local address is an IPv6 unicast address that can be automatically configured on any interface using the link-local
prefix FE80::/10 (1111 1110 10) and the interface identifier in the modified EUI-64 format. Link-local addresses are used
in the neighbor discovery protocol and the stateless autoconfiguration process. Nodes on a local link can use link-local addresses
to communicate; the nodes do not need globally unique addresses to communicate. The figure below shows the structure of a
link-local address.

IPv6 devices must not forward packets that have link-local source or destination addresses to other links.

An IPv4-compatible IPv6 address is an IPv6 unicast address that has zeros in the high-order 96 bits of the address and an
IPv4 address in the low-order 32 bits of the address. The format of an IPv4-compatible IPv6 address is 0:0:0:0:0:0:A.B.C.D
or ::A.B.C.D. The entire 128-bit IPv4-compatible IPv6 address is used as the IPv6 address of a node and the IPv4 address embedded
in the low-order 32 bits is used as the IPv4 address of the node. IPv4-compatible IPv6 addresses are assigned to nodes that
support both the IPv4 and IPv6 protocol stacks and are used in automatic tunnels. The figure below shows the structure of
an IPv4-compatible IPv6 address and a few acceptable formats for the address.

Use the Unicast
Reverse Path Forwarding for IPv6 feature to mitigate problems caused by
malformed or spoofed IPv6 source addresses that pass through an IPv6 device.
Malformed or forged source addresses can indicate denial-of-service (DoS)
attacks based on source IPv6 address spoofing.

When uRPF is enabled
on an interface, the device examines all packets received on that interface.
The device verifies that the source address appears in the routing table and
matches the interface on which the packet was received. This «look backward»
ability is available only when Cisco Express Forwarding is enabled on the
device; this is because the lookup relies on the presence of the Forwarding
Information Bases (FIBs). Cisco Express Forwarding generates the FIB as part of
its operation.

Note	uRPF is an input function and is applied only on the input interface of a device at the upstream end of a connection.

Note	With uRPF, all equal-cost «best» return paths are considered valid. uRPF works in cases where multiple return paths exist, provided that each path is equal to the others in terms of the routing cost (number of hops, weights, and so on) and as long as the route is in the FIB.

The IPv6 ICMP rate limiting feature implements a token bucket algorithm for limiting the rate at which IPv6 ICMP error messages
are sent out on the network. The initial implementation of IPv6 ICMP rate limiting defined a fixed interval between error
messages, but some applications such as traceroute often require replies to a group of requests sent in rapid succession.
The fixed interval between error messages is not flexible enough to work with applications such as traceroute and can cause
the application to fail.

Implementing a token bucket scheme allows a number of tokens—representing the ability to send one error message each—to
be stored in a virtual bucket. The maximum number of tokens allowed in the bucket can be specified, and for every error message
to be sent, one token is removed from the bucket. If a series of error messages is generated, error messages can be sent until
the bucket is empty. When the bucket is empty of tokens, no IPv6 ICMP error messages are sent until a new token is placed
in the bucket. The token bucket algorithm does not increase the average rate limiting time interval, and it is more flexible
than the fixed time interval scheme.

IPv6 neighbor discovery supports stateful switchover (SSO) using Cisco Express Forwarding. When switchover occurs, the Cisco
Express Forwarding adjacency state, which is checkpointed, is used to reconstruct the neighbor discovery cache.

A value of 135 in the Type field of the ICMP packet header identifies a neighbor solicitation message. Neighbor solicitation
messages are sent on the local link when a node wants to determine the link-layer address of another node on the same local
link (see the figure below). When a node wants to determine the link-layer address of another node, the source address in
a neighbor solicitation message is the IPv6 address of the node sending the neighbor solicitation message. The destination
address in the neighbor solicitation message is the solicited-node multicast address that corresponds to the IPv6 address
of the destination node. The neighbor solicitation message also includes the link-layer address of the source node.

After receiving the neighbor solicitation message, the destination node replies by sending a neighbor advertisement message,
which has a value of 136 in the Type field of the ICMP packet header, on the local link. The source address in the neighbor
advertisement message is the IPv6 address of the node (more specifically, the IPv6 address of the node interface) sending
the neighbor advertisement message. The destination address in the neighbor advertisement message is the IPv6 address of the
node that sent the neighbor solicitation message. The data portion of the neighbor advertisement message includes the link-layer
address of the node sending the neighbor advertisement message.

After the source node receives the neighbor advertisement, the source node and destination node can communicate.

Neighbor solicitation messages are also used to verify the reachability of a neighbor after the link-layer address of a neighbor
is identified. When a node wants to verify the reachability of a neighbor, the destination address in a neighbor solicitation
message is the unicast address of the neighbor.

Neighbor advertisement messages are also sent when there is a change in the link-layer address of a node on a local link.
When there is such a change, the destination address for the neighbor advertisement is the all-nodes multicast address.

Neighbor solicitation messages are also used to verify the reachability of a neighbor after the link-layer address of a neighbor
is identified. Neighbor unreachability detection identifies the failure of a neighbor or the failure of the forward path to
the neighbor, and is used for all paths between hosts and neighboring nodes (hosts or devices). Neighbor unreachability detection
is performed for neighbors to which only unicast packets are being sent and is not performed for neighbors to which multicast
packets are being sent.

A neighbor is considered reachable when a positive acknowledgment is returned from the neighbor (indicating that packets
previously sent to the neighbor have been received and processed). A positive acknowledgment from an upper-layer protocol
(such as TCP) indicates that a connection is making forward progress (reaching its destination) or the receipt of a neighbor
advertisement message in response to a neighbor solicitation message. If packets are reaching the peer, they are also reaching
the next-hop neighbor of the source. Therefore, forward progress is also a confirmation that the next-hop neighbor is reachable.

For destinations that are not on the local link, forward progress implies that the first-hop device is reachable. When acknowledgments
from an upper-layer protocol are not available, a node probes the neighbor using unicast neighbor solicitation messages to
verify that the forward path is still working.

The return of a solicited neighbor advertisement message from the neighbor is a positive acknowledgment that the forward
path is still working (neighbor advertisement messages that have the solicited flag set to a value of 1 are sent only in response
to a neighbor solicitation message). Unsolicited messages confirm only the one-way path from the source to the destination
node; solicited neighbor advertisement messages indicate that a path is working in both directions.

Note	A neighbor advertisement message that has the solicited flag set to a value of 0 must not be considered as a positive acknowledgment that the forward path is still working.

Neighbor solicitation messages are also used in the stateless autoconfiguration process to verify the uniqueness of unicast
IPv6 addresses before the addresses are assigned to an interface. Duplicate address detection is performed first on a new,
link-local IPv6 address before the address is assigned to an interface (the new address remains in a tentative state while
duplicate address detection is performed). Specifically, a node sends a neighbor solicitation message with an unspecified
source address and a tentative link-local address in the body of the message. If another node is already using that address,
the node returns a neighbor advertisement message that contains the tentative link-local address. If another node is simultaneously
verifying the uniqueness of the same address, that node also returns a neighbor solicitation message. If no neighbor advertisement
messages are received in response to the neighbor solicitation message and no neighbor solicitation messages are received
from other nodes that are attempting to verify the same tentative address, the node that sent the original neighbor solicitation
message considers the tentative link-local address to be unique and assigns the address to the interface.

Every IPv6 unicast address (global or link-local) must be verified for uniqueness on the link; however, until the uniqueness
of the link-local address is verified, duplicate address detection is not performed on any other IPv6 addresses associated
with the link-local address. The Cisco implementation of duplicate address detection in the Cisco software does not verify
the uniqueness of anycast or global addresses that are generated from 64-bit interface identifiers.

Router advertisement
(RA) messages, which have a value of 134 in the Type field of the ICMP packet
header, are periodically sent out each configured interface of an IPv6 router.
For stateless autoconfiguration to work properly, the advertised prefix length
in RA messages must always be 64 bits.

The RA messages are
sent to the all-nodes multicast address (see the figure below).

RA messages typically
include the following information:

• One or more
  onlink IPv6 prefixes that nodes on the local link can use to automatically
  configure their IPv6 addresses

• Lifetime
  information for each prefix included in the advertisement

• Sets of flags
  that indicate the type of autoconfiguration (stateless or stateful) that can be
  completed

• Default router
  information (whether the router sending the advertisement should be used as a
  default router and, if so, the amount of time (in seconds) the router should be
  used as a default router)

• Additional
  information for hosts, such as the hop limit and MTU a host should use in
  packets that it originates

RAs are also sent in
response to router solicitation messages.

The following RA
message parameters can be configured:

• The time interval
  between periodic RA messages

• The «router
  lifetime» value, which indicates the usefulness of a router as the default
  router (for use by all nodes on a given link)

• The network
  prefixes in use on a given link

• The time interval
  between neighbor solicitation message retransmissions (on a given link)

• The amount of
  time a node considers a neighbor reachable (for use by all nodes on a given
  link)

The configured
parameters are specific to an interface. The sending of RA messages (with
default values) is automatically enabled on FDDI interfaces when the
ipv6
unicast-routing command is configured. For other
interface types, the sending of RA messages must be manually configured by
using the
no
ipv6
nd
ra
suppress command. The sending of RA messages can be
disabled on individual interfaces by using the
ipv6
nd
ra suppress command.

A value of 137 in the type field of the ICMP packet header identifies an IPv6 neighbor redirect message. Devices send neighbor
redirect messages to inform hosts of better first-hop nodes on the path to a destination (see the figure below).

Note

A device must be able to determine the link-local address for each of its neighboring devices in order to ensure that the target address (the final destination) in a redirect message identifies the neighbor device by its link-local address. For static routing, the address of the next-hop device should be specified using the link-local address of the device; for dynamic routing, all IPv6 routing protocols must exchange the link-local addresses of neighboring devices.

After forwarding a packet, a device should send a redirect message to the source of the packet under the following circumstances:

• The destination address of the packet is not a multicast address.

• The packet was not addressed to the device.

• The packet is about to be sent out the interface on which it was received.

• The device determines that a better first-hop node for the packet resides on the same link as the source of the packet.

• The source address of the packet is a global IPv6 address of a neighbor on the same link, or a link-local address.

Use the
ipv6
icmp
error-interval command to limit the rate at which the device generates all IPv6 ICMP error messages, including neighbor redirect messages,
which ultimately reduces link-layer congestion.

Note	A device must not update its routing tables after receiving a neighbor redirect message, and hosts must not originate neighbor redirect messages.

The number of entries in the Neighbor Discovery cache can be limited by interface. Once the limit is reached, no new entries
are allowed. The per-interface Neighbor Discovery cache limit function can be used to prevent any particular customer attached
to an interface from overloading the Neighbor Discovery cache, whether intentionally or unintentionally.

When this feature is enabled globally, a common per-interface cache size limit is configured on all interfaces on the device.
When this feature is enabled per interface, a cache size limit is configured on the associated interface. The per-interface
limit overrides any globally configured limit.

All interfaces on IPv6 nodes must have a link-local address, which is usually automatically configured from the identifier
for an interface and the link-local prefix FE80::/10. A link-local address enables a node to communicate with other nodes
on the link and can be used to further configure the node.

Nodes can connect to a network and automatically generate global IPv6 addresses without the need for manual configuration
or help of a server, such as a Dynamic Host Configuration Protocol (DHCP) server. With IPv6, a device on the link advertises
any global prefixes in Router Advertisement (RA) messages, as well as its willingness to function as a default device for
the link. RA messages are sent periodically and in response to device solicitation messages, which are sent by hosts at system
startup.

A node on the link can automatically configure global IPv6 addresses by appending its interface identifier (64 bits) to the
prefixes (64 bits) included in the RA messages. The resulting 128-bit IPv6 addresses configured by the node are then subjected
to duplicate address detection to ensure their uniqueness on the link. If the prefixes advertised in the RA messages are globally
unique, then the IPv6 addresses configured by the node are also guaranteed to be globally unique. Device solicitation messages,
which have a value of 133 in the Type field of the ICMP packet header, are sent by hosts at system startup so that the host
can immediately autoconfigure without needing to wait for the next scheduled RA message.

The strict aggregation of the global routing table requires that networks be renumbered when the service provider for the
network is changed. When the stateless autoconfiguration functionality in IPv6 is used to renumber a network, the prefix from
a new service provider is added to RA messages that are sent on the link. (The RA messages contain both the prefix from the
old service provider and the prefix from the new service provider.) Nodes on the link automatically configure additional addresses
by using the prefix from the new service provider. The nodes can then use the addresses created from the new prefix and the
existing addresses created from the old prefix on the link. Configuration of the lifetime parameters associated with the old
and new prefixes means that nodes on the link can make the transition to using only addresses created from the new prefix.
During a transition period, the old prefix is removed from RA messages and only addresses that contain the new prefix are
used on the link (the renumbering is complete) (see the figure below).

The upper 64 bits of an IPv6 address are composed from a global routing prefix plus a subnet ID, as defined in RFC 3513.
A general prefix (for example, /48) holds a short prefix, based on which a number of longer, more-specific prefixes (for example,
/64) can be defined. When the general prefix is changed, all of the more-specific prefixes based on it will change, too. This
function greatly simplifies network renumbering and allows for automated prefix definition.

For example, a general prefix might be 48 bits long (“/48”) and the more specific prefixes generated from it might be 64
bits long (“/64”). In the following example, the leftmost 48 bits of all the specific prefixes will be the same, and they
are the same as the general prefix itself. The next 16 bits are all different.

 General prefix: 2001:DB8:2222::/48
Specific prefix: 2001:DB8:2222:0000::/64
Specific prefix: 2001:DB8:2222:0001::/64
Specific prefix: 2001:DB8:2222:4321::/64
Specific prefix: 2001:DB8:2222:7744::/64

General prefixes can be defined in several ways:

• Manually

• Based on a 6to4 interface

• Dynamically, from a prefix received by a Dynamic Host Configuration Protocol (DHCP) for IPv6 prefix delegation client

More specific prefixes, based on a general prefix, can be used when configuring IPv6 on an interface.

DHCP for IPv6 can be used in environments to deliver stateful and stateless information. For further information about this
feature, see Implementing DHCP for IPv6.

SUMMARY STEPS

1. 
   enable
   

2. 
   configure
   
   
   terminal
   

3. 
   ipv6
   general-prefix
   
   
   
   
   prefix-name
   {ipv6-prefix/prefix-length |
   6to4
   interface-type
   interface-number}

DETAILED STEPS

Device> enable

Device# configure terminal

Device(config)# ipv6 general-prefix my-prefix 2001:DB8:2222::/48

SUMMARY STEPS

1. 
   enable
   

2. 
   configure
   
   
   terminal
   

3. 
   ipv6
   general-prefix
   
   
   
   
   prefix-name
   
   {ipv6-prefix / prefix-length | 6to4 interface-type interface-number

DETAILED STEPS

Router> enable

Router# configure terminal

Router(config)# ipv6 general-prefix my-prefix 6to4 gigabitethernet 0/0/0

You can define a general prefix dynamically using the DHCP for IPv6 prefix delegation client function. For information on
how to perform this task, see the Implementing DHCP for IPv6 module.

SUMMARY STEPS

1. 
   enable
   

2. 
   configure
   
   
   terminal
   

3. 
   interface
   
   
   type
   
   
   number
   

4. 
   ipv6
   address
   {ipv6-address / prefix-length | prefix-name sub-bits /prefix-length

DETAILED STEPS

Router> enable

Router# configure terminal

Router(config)# interface gigabitethernet 0/0/0

Router(config-if) ipv6 address my-prefix 2001:DB8:0:7272::/64

SUMMARY STEPS

1. 
   enable
   

2. 
   clear
   ipv6
   mtu
   

DETAILED STEPS

Device> enable

Device# clear ipv6 mtu

SUMMARY STEPS

1. 
   enable

2. 
   configure
   
   
   terminal
   

3. Do
   the following:

• 
  ipv6

  cef
  

4. 
   ipv6
   cef
   accounting
   [non-recursive |

   per-prefix |
   prefix-length ]

DETAILED STEPS

Device> enable

Device# configure terminal

Device(config)# ipv6 cef

Device(config)# ipv6 cef accounting 

Before you begin

To use uRPF, enable Cisco Express Forwarding switching or distributed Cisco Express Forwarding switching in the device. There
is no need to configure the input interface for Cisco Express Forwarding switching. As long as Cisco Express Forwarding is
running on the device, individual interfaces can be configured with other switching modes.

Note	Cisco Express Forwarding must be configured globally in the device. uRPF will not work without Cisco Express Forwarding.

Note

uRPF should not be used on interfaces that are internal to the network. Internal interfaces are likely to have routing asymmetry, meaning that there are multiple routes to the source of a packet. uRPF should be applied only where there is natural or configured symmetry. For example, devices at the edge of the network of an ISP are more likely to have symmetrical reverse paths than devices that are in the core of the ISP network. Devices that are in the core of the ISP network have no guarantee that the best forwarding path out of the device will be the path selected for packets returning to the device. Therefore, we do not recommend that you apply uRPF where there is a chance of asymmetric routing. It is simplest to place uRPF only at the edge of a network or, for an ISP, at the customer edge of the network.

SUMMARY STEPS

1. 
   enable
   

2. 
   configure
   
   
   terminal
   

3. 
   interface
   
   
   type
   
   
   number
   

4. 
   ipv6
   verify
   unicast
   source
   reachable-via
   {rx |
   any } [allow-default ] [allow-self-ping ] [access-list-name

DETAILED STEPS

Device> enable

Device# configure terminal

Device(config)# interface gigabitethernet 0/0/0

Device(config-if)# ipv6 verify unicast source reachable-via any

SUMMARY STEPS

1. 
   enable

2. 
   configure
   
   
   terminal
   

3. Do one of the
   following:

• 
  ip domain
  name
  [vrf
  vrf-name ]
  name

• 
  ip domain
  list
  [vrf
  vrf-name ]
  name

4. 
   ip
   name-server
   [vrf
   vrf-name ]
   server-address1 [server-address2…server-address6 ]

5. 
   ip
   domain-lookup
   

DETAILED STEPS

Device> enable

Device# configure terminal

Device(config)# ip domain-name cisco.com

Device(config)# ip domain list cisco1.com

Device(config)# ip name-server 2001:DB8::250:8bff:fee8:f800 2001:DB8:0:f004::1

Device(config)# ip domain-lookup

IPv6 for Cisco IOS XE software supports wide-area networking technologies such as Cisco HDLC, PPP over Packet over SONET (PoS),
ISDN, and serial (synchronous and asynchronous) interface types, and Frame Relay PVCs. These technologies function the same
in IPv6 as they do in IPv4—IPv6 does not enhance the technologies in any way.

Broadcast and multicast are used in LANs to map protocol (network-layer) addresses to the hardware addresses of remote nodes
(hosts and routers). Because using broadcast and multicast to map network-layer addresses to hardware addresses in circuit-based
WANs such as Frame Relay networks is difficult to implement, these networks utilize implicit, explicit, and dynamic mappings
for the network-layer addresses of remote nodes and the PVCs used to reach the addresses.

Assigning an IPv6 address to an interface by using the ipv6 address command defines the IPv6 addresses for the interface and the network that is directly connected to the interface. If only
one PVC is terminated on the interface (the interface is a point-to-point interface), there is an implicit mapping between
all of the IPv6 addresses on the network and the PVC used to reach the addresses (no additional address mappings are needed).
If several PVCs are terminated on the interface (the interface is a point-to-multipoint interface), the frame-relay map ipv6
command is used to configure explicit mappings between the IPv6 addresses of the remote nodes and the PVCs used to reach the
addresses.

Note

Given that IPv6 supports multiple address types, and depending on which applications or protocols are configured on a point-to-multipoint interface, you may need to configure multiple explicit mappings between the IPv6 addresses of the interface and the PVC used to reach the addresses. For example, explicitly mapping both the link-local and global IPv6 address of a point-to-multipoint interface to the PVC that the interface terminates ensures that the Interior Gateway Protocol (IGP) configured on the interface forwards traffic to and from the PVC correctly.

SUMMARY STEPS

1. 
   enable
   

2. 
   configure
   
   
   terminal
   

3. 
   interface
   
   
   type
   
   
   number
   

4. 
   protocol
   ipv6
   
   
   ipv6-address
   [[no ] broadcast ]
5. 
   frame-relay
   map
   ipv6
   
   
   ipv6-address
   dlci
   
   [broadcast ] [cisco ] [ietf ]
   [payload-compression packet-by-packet | frf9 stac
   [hardware-options ] | data-stream stac
   [hardware-options ]}]

6. 
   ipv6
   address
   
   
   ipv6-address
   
   
   /
   
   
   prefix-length
   
   
   link-local
   

DETAILED STEPS

Router> enable

Router# configure terminal

Router(config)# interface serial 3

Router(config-if-atm-vc)# protocol ipv6 2001:DB8:2222:1003::45

Router(config-if)# frame-relay map ipv6 FE80::E0:F727:E400:A 17 broadcast

Router(config-if)# ipv6 address 2001:DB8:2222:1044::46/64 link-local