| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
All the IP addresses discussed so far are of the IPv4 type. The IP address standard IPv6 is designed as a successor to IPv4 with the principal advantage of providing a much larger 128 bit address space. Among many other advantages, the large number of available global IPv6 addresses means that NAT is no longer required to share a limited number of public IPv4 addresses.
This section discusses how IPv6 usage is enabled, how IPv6 objects are created, how stateless auto-configuration by clients is enabled and how to create IP rule set and routing table entries that use IPv6 address objects.
![[Note]](images/note.png) |
Note: The prefix 2001:DB8::/32 is reserved for documentation |
|---|---|
|
As described in RFC-3849, the IPv6 prefix 2001:DB8::/32 is specifically reserved for documentation purposes. All IPv6 examples in this manual therefore use this network or addresses from it. |
cOS Core Configuration Objects Supporting IPv6
The following objects of cOS Core provide IPv6 support:The address book.
Routing tables (except switch routes).
Routing rules.
IP rule sets (excluding some actions).
The HTTP and LW-HTTP ALGs.
Remote management. For this, a new remote management object must be defined that permits access from a given IPv6 network or host. This can be done for HTTP/HTTPS access.
IPv6 Must be Enabled on an Ethernet Interface
IPv6 must be explicitly enabled on each cOS Core Ethernet interface for it to function on that interface. More specifically, any IPv6 traffic that is routed to an Ethernet interface will require that interface to have IPv6 enabled. In the case of IPsec, this applies to traffic that sets up the tunnel but not to traffic that flows inside the tunnel. By default, IPv6 is disabled for all interfaces.At the same time that an interface is enabled for IPv6, an IPv6 address and IPv6 network (prefix) must be assigned to it. The interface can then be used in rules and routes with IPv6 properties.
Example 3.12. Enabling IPv6 on an Ethernet Interface
This example enables IPv6 on the wan Ethernet interface using the address objects created previously.
Command-Line Interface
Device:/> set Interface Ethernet wan
EnableIPv6=Yes
IPv6IP=wan_ip6
IPv6Network=wan_net6InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
An IPv6 gateway address could also be entered for the interface if it is connected to an ISP router.
An Interface Route is Added Automatically
When an IPv6 address and network are assigned to an Ethernet interface (both are required) then an IPv6 route for that interface should be added to the main routing table.The route is added, provided that the automatic route creation for the interface is enabled (it is enabled by default).
Alternative Methods of Creating Interface Address Objects
IPv6 address objects are created in the cOS Core address book as objects which are distinct from IPv4 objects.Only the all-nets6 object (IPv6 address ::/0) is already predefined in the cOS Core address book. This means that the IPv6 address and network objects associated with interfaces must be created. This can be done in one of the following ways:
By manually adding the address objects to the address book and then assigning these objects to the associated interface. This is shown in the previous example.
For Ethernet, VLAN and Link Aggregation interfaces, the DHCPv6 client function can be enabled on an individual interface and the IPv6 address objects will be created as needed when a client lease is received from an external DHCP server. The DHCPv6 client function is discussed further in Section 5.6.1, DHCPv6 Client.
For Ethernet, VLAN and Link Aggregation interfaces, by enabling the Autoconfigure property on the interface. This option is explained next.
The EUI-64 algorithm requires a /64 (64 bit) IPv6 network from which to choose the IP address. This /64 network can come from one of the following two sources:
It can be statically defined as the IPv6 Network property for the interface.
The Router Discovery option can be enabled so that cOS Core gets it from an external router which is accessible from the interface and is found through the neighbor discovery mechanism. This makes use of Stateless Address Auto-Configuration (SLAAC).
Example 3.13. Manually Adding IPv6 Interface Addresses
Assume that an IPv6 address and network have to be associated with the wan Ethernet interface. This example adds two new IPv6 address objects to the address book consisting of the network wan_net6 (the IPv6 prefix 2001:DB8::/32) and the single IP address wan_ip6 (2001:DB8::1) within that network.
Command-Line Interface
Device:/> add Address IP6Address wan_net6 Address=2001:DB8::/32Device:/> add Address IP6Address wan_ip6 Address=2001:DB8::1InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Add the network address (the IPv6 prefix):
Add the IP address:
IPv4 and IPv6 Cannot Share an Address Group Object
IPv6 address objects are created and managed in a similar way to IPv4 objects They are called an IP6 Address and can be used in cOS Core rules and other objects in the same way as an IPv4 address. However, it is not possible to combine the two in one configuration object.For example, it is not possible to create an Address Group that contains both. The standard Address Group object can contain only IPv4 address objects. For IPv6 there is a special object called an IP6 Group object that can contain only IPv6 addresses.
The predefined all-nets address object is a catch-all object only for all IPv4 addresses. Another object, all-nets6, represents all IPv6 addresses and only IPv6 addresses.Furthermore, it is not possible to combine all-nets (all IPv4 addresses) with all-nets6 in a single Address Group object. For example, if a DropAll rule is needed as the last "catch-all" rule in an IP rule set, two rules are required to catch all IPv4 and IPv6 traffic. This is discussed further in Section 3.6, IP Rule Sets.
In the same way, a routing table could route traffic for either an IPv4 network or an IPv6 network to the same interface but this must be done with two separate routes in the routing table, one for IPv4 and one for IPv6. It cannot be achieved using a single route.
Enabling IPv6 Router Advertisement
An additional option for an Ethernet interface is to enable IPv6 router advertisement. This means that any external client connected to the interface can solicit and receive IPv6 messages to allow it to perform Stateless Address Auto-Configuration (SLAAC). The SLAAC process allows the client to create its own unique global IPv6 address based on the MAC address of its interface and the prefix of the IPv6 address for the cOS Core interface it is connected to.Example 3.14. Enabling IPv6 Advertisements
This example enables IPv6 advertisements on the wan Ethernet interface.
Command-Line Interface
Device:/> set Interface Ethernet wan EnableRouterAdvertisement=YesInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Enabling ICMP Error Pass Through
Unlike IPv4, fragmentation of IPv6 packets is only done by the originating host using the host's selection of MTU size. Should the packets then encounter network equipment that cannot handle the chosen MTU size, ICMP error messages are sent back to the originating host to indicate that the MTU must be reduced and the packets resent.For this reason, it is recommended to always enable the Pass returned ICMP errors messages from destination property for any Service object used with an IP rule set entry for IPv6 traffic. An alternative to this is to set up IP rule set entries which explicitly allow the ICMP error messages in both directions.
The exception is if the MTU is initially set to 1280 which is the minimum MTU supported by IPv6. In this case, there is no need for ICMP messages to be passed since they should not occur.
IPv6 Neighbor Discovery (ND) is the IPv6 equivalent of the IPv4 ARP protocol.When IPv6 is enabled for a given Ethernet interface, cOS Core will respond to any IPv6 Neighbor Solicitations (NS) sent to that interface with IPv6 Neighbor Advertisements (NA) for the IPv6 address configured for that interface. cOS Core will also respond with neighbor advertisements for any networks configured using Proxy Neighbor Discovery.
cOS Core maintains a neighbor discovery cache for IPv6 and the contents of this cache are visible when displaying the neighbor cache (this is described further in Section 3.5.5, The Neighbor Cache).
The IPv6 feature of Proxy Neighbor Discovery (Proxy ND) in cOS Core functions in the same way as Proxy ARP does with IPv4 (described in Section 4.2.6, Proxy ARP). There are two ways of enabling proxy ND:A. Directly publish an address on an interface.
This is done in exactly the same way as ARP publish by setting option on an Ethernet interface. Both the options Publish and Xpublish are supported for IPv6. These options are explained in Section 3.5.3, ARP Publish.
B. Publish an address as part of a static route.
When a route for an IPv6 address on a given Ethernet interface is created, IPv6 should already be enabled for the interface which means that IPv6 neighbor discovery is operational. Optionally, Proxy Neighbor Discovery (Proxy ND) can also be enabled for an IPv6 route so that all or selected interfaces will also respond to any neighbor solicitations for the route's network.
An example of using this second method is given below.
Example 3.15. Adding an IPv6 Route and Enabling Proxy ND
Assume that a route needs to be in the main routing table so that the IPv6 network my_ipv6_net is routed on the interface If1 where that interface already has IPv6 enabled.
In addition, proxy neighbor discovery for my_ipv6_net needs to be enabled for the If3 interface.
Command-Line Interface
First, change the CLI context to be the main routing table:
Device:/> cc RoutingTable mainAdd the IPv6 route:
Device:/main> add Route6 Network=my_ipv6_net
Interface=If1
ProxyNDInterfaces=If3Lastly, return to the default CLI context:
Device:/main>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Troubleshooting IPv6 with ICMP Ping
The CLI command ping can be used for both IPv4 and IPv6 addresses. For example:Device:/> ping 2001:DB8::2Ping can also be initiated in the Web Interface by going to: Status > Tools > Ping.
Outgoing ICMP messages from the firewall do not require an IP rule set entry which allows them since the gateway is trusted. However, if the firewall is to be pinged by an external host then an IP rule set entry must be set up to allow this, just as it is needed for IPv4. Such an entry would use the predefined Service object called ping6-inbound The service object called all_icmpv6 covers all IPv6 ICMP messages except mobile ICMP messages.
An appropriate IP rule set entry to allow cOS Core to respond to IPv6 ping messages would be the following:
| Action | Source Interface |
Source Network |
Destination Interface |
Destination Network |
Service |
|---|---|---|---|---|---|
| Allow | wan | all-nets6 | core | wan_ip6 | ping6-inbound |
The above rule assumes that IPv6 has been enabled on the wan interface.
A general discussion of ping and its options along with IPv4 usage can be found in Section 2.6.2, The ping Command.
IPv6 Usage Restrictions
The following is a summary of IPv6 restrictions in the current version of cOS Core:Management access with any cOS Core management interface is not possible using IPv6.
IP rule set entries using IPv4 and IPv6 addresses can coexist in the same IP rule set but a single entry cannot combine IPv4 and IPv6.
IPv6 addresses are not currently supported in IP rule set entries that perform the following actions:
Routes using IPv4 and IPv6 addresses can coexist in the same routing table set but a single route cannot combine IPv4 and IPv6.
Routing rules using IPv4 and IPv6 addresses coexist but a single rule cannot combine IPv4 and IPv6.
IPv6 cannot be used with the following:
The address book object IP6 HA Address is the IPv6 equivalent of the IP4 HA Address object. This allows both shared and private IPv6 addresses to be assigned to interface pairs in an HA cluster. Private interface IPv6 addresses cannot be used for management access or as the source address for logging but they can be used for responding to ICMP ping messages when a cluster is active or for sending such messages when the cluster is inactive.
See Section 12.3, Setting Up HA for further discussion of using IP6 HA Address objects with an HA cluster.
IPv6 and Transparent Mode
Transparent Mode in cOS Core does not directly support IPv6 since Switched Routes cannot be defined for IPv6 networks (see Section 4.9, Transparent Mode).However, it is possible to split networks transparently in the same way that Proxy ARP is used for this with IPv4. Doing this for IPv4 is explained in Section 4.2.6, Proxy ARP. The only difference with IPv6 is that Neighbor Discovery (ND) is used instead of proxy ARP. The method is otherwise the same and the two can be used alongside each other to split both IPv4 and IPv6 networks at the same time.
Tunneling IPv6 Across IPv4 Networks
cOS Core allows the tunneling of IPv6 traffic across networks that only support IPv4. This can be done using an IP6in4 Tunnel object. This is described further in Section 3.4.8, 6in4 Tunnels.Tunneling IPv6 Through IPv4 IPsec Tunnels
The 6in4 tunneling solution does not provide encryption. For that, IPv6 traffic should be tunneled through an IPv4 IPsec tunnel. Setting this up is discussed in an article in the Clavister Knowledge Base at the following link:https://kb.clavister.com/324736072
Using Neighbor Discovery Advanced Settings
This section will look more closely at configuring Neighbor Discovery (ND) for IPv6. In particular, it examines the cOS Core neighbor discovery cache.Neighbor discovery handling in cOS Core resembles ARP handling in that a cache is maintained in local memory of IPv6 hosts, retaining information about external host's link-layer and IP address tuples. Below is a summary of the cOS Core ND cache states (these are also defined in RFC-4861):
INCOMPLETE
Address resolution is in progress and the link-layer address of the neighbor has not yet been determined.
REACHABLE
The neighbor is known to have been reachable recently (within the last tens of seconds).
STALE
The neighbor is no longer known to be reachable but until traffic is sent, no attempt will be made to verify its reachability.
DELAY
The neighbor is no longer known to be reachable and traffic has recently been sent. Before probing reachability, wait for a short time to allow reachability confirmation.
PROBE
The neighbor is no longer known to be reachable and unicast neighbor solicitation probes are being sent to verify reachability.
Neighbor entries appear in the cache for the following reasons:
When cOS Core is about to send a packet to a neighbor, an entry is created.
When cOS Core receives neighbor solicitations containing source link-layer address options, an entry is created.
When static entries are added by the administrator. These are regarded as always being in the REACHABLE state.
The key advanced settings for neighbor discovery are found in the ARPNDSettings object and include the following properties:
NDMatchEnetSender
Check if the Ethernet sender address does not match the sender Ethernet address derived from the source/target link-layer address option in a packet. This can be a sign of address spoofing and the default is to have this setting enabled so that non-matching packets are dropped. In some situations it might be desirable to skip this check.
NDValSenderIP
When enabled, cOS Core requires that the non-link local source address of neighbor discovery packets match the routing table routes. If they do not, the packets are dropped.
When no such matching routes have been configured, this setting needs to be disabled if the neighbor discovery packets are to be processed.
NDChanges
If occasional loss of connectivity to certain hosts is being experienced, this setting should be given the value AcceptLog. This can help identify if the cause is the same IPv6 address moving between hardware Ethernet addresses.
NDCacheSize
The neighbor discovery cache provides higher traffic throughput speeds by reducing neighbor discovery traffic and the time required to process this traffic. The size of the cache can be adjusted with this setting to suit particular scenarios with different network sizes.
A larger cache means a greater allocation of physical memory. However, if the cache is too small, items may be discarded because they cannot fit and this will lead to higher latency times and more neighbor discovery traffic.
There are a number of timing settings associated with neighbor discovery:
NDMulticastSolicit
NDMaxUnicastSolicit
NDBaseReachableTime
NDDelayFirstProbeTime
NDRetransTimer
Lower values for these means that the cache is better able to deal with stray hosts that only communicate for a short period but it also leads to an increase in neighbor discovery traffic. In order to increase the time an entry stays in the cache before triggering a time-out or sending probes, it is recommended to increase the value of NDBaseReachableTime.
All settings relevant to neighbor discovery can be found in the separate cOS Core CLI Reference Guide under the object name ARPNDSettings.
In IPv6, the fe80::/10 address range is reserved for link-local unicast addresses. These addresses are automatically generated by devices when IPv6 is enabled on an interface. They play a crucial role in local network communication and are used for tasks such as Neighbor Discovery and communication within the same network segment. Unlike global unicast addresses, link-local addresses do not require manual configuration and are automatically associated with the respective network interface.ff02 Multicast Addresses
IPv6 uses multicast addresses within the ff02::/16 range for various network operations, including Router Solicitation (RS), Neighbor Discovery (ND) and Duplicate Address Detection (DAD). These multicast addresses enable devices to discover routers on the network and verify the uniqueness of their IPv6 addresses. In the context of Clavister cOS Core, these multicast addresses are handled automatically by the IPv6 protocol stack and do not require manual configuration of routes or rules.
