Tag Archives: ipv6

IPv6 Migration: Host and Routing Functions on Cisco Catalyst Switches

IPv6 support is a hot topic today on any networking circle. Given the exhaustion of IPv4 addresses and the promisses of new services over IPv6, it is very natural for most customers to be concerned about buying products that already include v6 features or, at the very least, a sound roadmap. (Moreover, some industry segments have even defined regulations about IPv6 support on equipments to be acquired).

But, before you start selecting your IPv6-enabled devices, it is certainly advisable to understand the differences between the host and routing functions:

  • Host Functions: the ability to be inserted in an IPv6 network and managed using the classic protocols (over IPv6). For instance, ICMP, Telnet, Syslog, DNS. L2 devices such as the Catalyst 2960 (LAN Base) already include this type of functionality.
  • Routing Functions: the ability to route IPv6 packets. Support starts on the Catalyst 3560 series for Cisco L3 Switches (specifically in the IP Services feature set).

Given that Layer 2 Switching, in most environments,  is a suitable choice for the access layer,  you do not need to upgrade your entire base to L3 just to support v6. Deploying L2 (with IPv6 host functions) in the access layer, with IPv6 routing capabilities in the distribution and core layers, will typically guarantee a smooth transition to v6.

As a reference, a list of the IPv6 host features available in the Catalyst 2960 family (LAN Base image) is presented below:

  • Telnet and SSH for remote access to the CLI
  • HTTP and HTTPS for graphical management of the switches
  • DNS for name resolution over IPv6 (AAAA records)
  • TFTP for file transfer (OS images and configuration files)
  • SNMP and Syslog
  • ICMPv6 (including Ping and the Neighbor Discovery processes)
  • Stateless Autoconfiguration over IPv6
  • A small number of IPv6 Static Routes (to give you flexibility on reaching the switch from a management perspective). This is not intended to be used as an IPv6 router.

** Further Reading:

** Related Posts:

Leave a comment

Filed under English, IPv6, Routing

How IOS IPv6 ACLs handle ICMPv6 Neighbor Discovery messages

Traditional IPv4 ACLs are typically written as a sequence of permit statements that include an implicit deny clause as their last line. Although this implicit deny is also present on IOS IPv6 ACLs, there are some additional facts to be aware of:

  1. There are other implicit (permit) statements designed to allow two of the main Neighbor Discovery (ND) messages:  permit icmp any any nd-na (which handles Neighbor Advertisement messages) and permit icmp any any nd-ns (which takes cares of Neighbor Solicitation messages).
  2. If your environment requires Router Advertisement (RA) and Router Solicitation (RS) messages to be allowed, these lines will need to be configured explicitily (in the same way as the regular permits).
  3. In the event you add an explicit deny as the last line of the V6 ACL, this statement will take precedence over the implicit permits earlier described (for nd-na and nd-ns).

Now that you are aware of these characteristics of IPv6 ACLs with regards to Neighbor Discovery, don’t forget to add the following lines before the explicit deny (“deny ipv6 any any“):

     permit icmp any any nd-na

     permit icmp any any nd-ns

     permit icmp any any router-advertisement

     permit icmp any any router-solicitation

After all, as seen on a previous article, ND messages are necessary for the correct operation of IPv6 networks…

** Related Posts:

IPv6 Series: https://alexandremspmoraes.wordpress.com/tag/ipv6/

ACL Series: https://alexandremspmoraes.wordpress.com/tag/acl/

Leave a comment

Filed under English, Firewalls, IPv6, Security

Some IPv6 link-local processes and the associated ICMPv6 messages

ICMPv6 goes beyond the traditional diagnostic and error reporting services delivered by its IPv4 counterpart. Some ICMPv6 are simply indispensable for a series of link-local processes related to Neighbor Discovery (ND). The main messages and some of the processes they apply to, are described below:

  • Router Adverstisements (RA messages): identified by ICMP type 134, are sent periodically or in response to a Router Solicitation message. An RA is sent to the All-Nodes multicast address with a link-local scope (FF02::1) and includes one or more network prefixes and possibly other data, such as the default router and the MTU on that link.
  • Router Solicitation (RS messages): generated by hosts at boot time to request immediate sent of RAs by routers, so that they do not need to wait for the periodic RA and can promptly start autoconfiguration. ICMP type 133 is associated with RS messages.

Figure 1: ICMv6 Router Advertisement (RA) and Router Solicitation (RS) messages

Two other important ICMPv6 ND messages, Neighbor Solicitation (NS) and Neighbor Advartisement (NA), respectively identified by types 135 and 136, are mainly employed in the following tasks:

  • Duplicate Address Detection (DAD): to avoid address conflicts on a link, a node invokes the DAD mechanism whenever a new address is configured. For example, if host H1 wishes to configure the unicast address X1, it sends an ICMPv6 Neighbor Solicitation to the solicited-node multicast address corresponding to X1. If any other host on the link responds, it means that the intended address is already taken and cannot be assigned.
  • Layer 2 Address Resolution (ARP Replacement): If host H1 wants to send a packet to H2 on a local-link, it first needs to determine the layer 2 address of H2. H1 accomplishes that by sending a NS message to the solicited-node address corresponding to H2. The data portion of the NS contains the Query “what is your L2 address? “. H2 then sends a Neighbor Advertisement message  to H1, revealing its Layer 2 address. The hosts can now communicate using IPv6 unicast addresses.

Figure 2: Layer 2 Address Resolution and Duplicate Address Detection for IPv6

Due to the role played by ICMPv6, the (almost automatic) procedure of blocking ICMP (typical of IPv4 networks) will need to be reconsidered. Otherwise the basic IPv6 link-local processes will fail…

** Topics for Study:

  • Play with the ping and the show ipv6 neighbor commands to examine L2 Address Resolution
  • It may be interesting to enable the debug ipv6 icmp and debug ipv6 nd commands on your lab to get more familiar with the main ND processes.
  • Are you able to apply Flexible Netflow (described in a previous post) to gain visibility of the ND messages ?

** Related Posts:

Leave a comment

Filed under English, IPv6

Gaining visibility of your IPv6 traffic with Flexible Netflow

Within the context of computer networks, a flow is defined as an unidirectional sequence of packets between two network endpoints, one of which acts as the source and the other as the destination. Historically, the seven key fields that have been used to univocally identify an IPv4 flow are:

  • Source IP Address
  • Destination IP Address
  • Layer 3 Protocol Type
  • Source Port Number
  • Destination Port Number
  • Type of Service (ToS)
  • Input Logical Interface

Netflow is a powerful functionality that was designed to raise awareness about the utilization of network resources. The flow distribution data obtained by means of Netflow may be applied to domains such as capacity planning, network application monitoring, accounting and security analysis.

Although Netflow was originally defined for IPv4, it is also available for IPv6 and, as such, it becomes an interesting resource for gaining more visibility about the traffic flowing through your v6 network.

Figure 1 revisits, as a quick reference, the base IPv6 header. The motivation for inserting it here is to make your life easier on understanding the Netflow fields that will be analyzed later.

Figure 1: Base IPv6 Header

Flexible Netflow is an evolution that allows us to elect the fields that should be part of the flow record, meaning that we are not limited to a set of predefined fields anymore. The set of fields selected may provide a different perspective about a given group of packets crossing the L3 device. For instance, certain fields may be useful for capacity planning while a distinct combination could be more meaningful for security tasks such as spotting Denial of Service (DoS) attempts.

A sample configuration of Flexible Netflow for IPv6 is summarized in Figure 2 to facilitate the understanding of the basic concepts:

  • We established the fields that comprise the flow record. The match statements identify the key fields, whereas collect statements determine the non-key fields. (It is a good exercise to compare the IPv6 base header fields with those shown in Figure 2).
  •  If two packets differ in at least two of the key-fields they are not part of the same flow.
  • The flow export entity defines the way in which flow data will be exported (destination IP, destination port and source interface). Notice that v6 flow information is still exported using IPv4.
  • The flow monitor structure ties the flow record and flow export settings and is later bound to an interface (either in the ingress or egress direction).
  • Figure 2 also exemplifies a possible view of the flow monitor cache.

Figure 2: Sample configuration of Flexible Netflow for an IPv6 environment


** Related Posts:

Leave a comment

Filed under English, IPv6

Cisco IOS Zone-based Policy Firewall: L7 inspection for FTP over IPv6

In a previous post we examined the main usages of L7 inspection on a stateful firewall (IPv4 perspective):

  1. Fixing up misbehaved protocols, such as those that dynamically negotiate data connections inside the control channel. Classic examples are FTP and the telephony signaling protocols (SIP, H.323 framework, SCCP, MGCP).
  2. Perform Network Address Translation (NAT) at the application level for those protocols that embed the IP address in the L7 messages. This is critical within NAT and Port Address Translation (PAT) environments.
  3. Use the application knowledge to filter based on additional criteria pertaining to the specific L7 protocol, rather than just L4/L3.

On another article of the IPv6 series, we analyzed a basic L4 inspection policy for a v6 environment. Now we will apply the Cisco Zone-based Policy Firewall (ZFW) L7 awareness to a simple FTP scenario built upon IPv6. But, before we jump to the example itself, there are some relevant facts to highlight :

  • Current support for IPv6 in the ZFW covers case 1 of the main usages of L7 inspection listed before.
  • If you need to fixup an application protocol that is running over non-standard ports, you can leverage the ipv6 port-map command (pretty much in the same fashion we employed  the ip port-map command before).
  • The application knowledge is not used for filtering purposes yet.

The figure below depicts not only the ZFW policy structure but also the audit-trail logs for the FTP session (both the control and thedynamically  negotiated data channels). Notice that the match protocol statement uses the ftp keyword, which instructs the ZFW to use its understanding of the FTP application to handle this session. (It is not generic TCP !)

Sample Zone-based Policy Firewall scenario for FTP over IPv6 inspection

** Topics for Study:

  • What are the FTP over IPv6 commands that correspond, respectively, to the PORT and PASV commands ?
  • Examine the output of the show ipv6 port-map command
  • Play with the appropriate show commands for this setup. Good starting points are show zone security and show policy-firewall config zone-pair.

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Sample Configuration of the Cisco IOS Zone-based Policy Firewall with IPv6

Now that we have studied several practical scenarios for the Cisco IOS Zone-based Policy Firewall (ZFW), it is time to apply this knowledge to IPv6 environments. It is very important to emphasize that the logic of policy construction (as well as the building blocks) are identical to those employed for IPv4.
Our reference topology brings a simple network containing two security zones and an L4-only policy that defines the rules to allow the initiation of  outbound connections. The figure also documents the output of a typical debug command used to gain visibility about session creation.

Basic Zone-based Firewall configuration for IPv6

** Topics for Study:

  • By reviewing the contents of previous posts in the ZFW series, would you be able to insert L3 restrictions in this scenario ? (For example, the client host in the INSIDE should only be able to access FTP and HTTP on the OUTSIDE server).
  • How can you enable logging ? (both for connection setup/teardown and dropped packets)
  • What are the commands used to display information about existent security zones and structure of policy elements ?

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Introduction to IOS IPv6 ACLs

This post quickly discusses simple Cisco IOS IPv6 Access Control Lists (ACLs). As summarized in the figure, the construction logic of the ACL is basically identical to the classic v4 ACLs (those that do not use object-groups). The permit (or deny) statements are created by specifying the following elements (in this order):

  • source of the traffic
  • destination of the traffic
  • services involved (from source to destination)

One noticeable difference refers to the way in which v6 ACLs are applied to interfaces: the correct command to accomplish that task is the ipv6 traffic -filter (and not something such as “ipv6 access-group”).

Basic Description of simple IOS IPv6 ACLs

** Notes:

  • Object-groups for v6 elements are not supported on IOS yet.
  • IOS supports IPv6 ACLs that allow filtering based on the v6 extension headers.

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Understanding some tricky IPv6 Addresses

The first good thing about IPv6 is that you have an incredible number of addresses for each individual on planet Earth ( assuming a population of 10 billion, there would be something around 34,000 trillions of trillions of addresses per person !!) On the other hand, for someone that has worked with IPv4 all life long, understanding some of the addresses involved in basic v6 operations may be challenging.

Figure 1 brings, as a reference, the summarized output of the classic show ip interface command. The example highlights that v4 uses broadcast addresses, a concept that was not integrated into v6 definitions. To compensate for the absence of broadcast addresses, v6 employs various types of multicast group addresses to perform tasks such as neighbor discovery and duplicate address detection.

Figure 1: Summary output of the “show ip interface” command

Figure 2 documents a typical instance of the show ipv6 interface command, which reveals some interesting facts:

  • It underlines that IPv6 does not employ broadcast addresses.
  • It displays the link-local address, which are used in activities like automatic address configuration and neighbor discovery, or in situations when no routers are present. These addresses are, most of the time, automatically generated by combining the link-local prefix, FE80::/10, with a sequence of 54 zeros and a 64-bit interface identifier. As the name implies this class of addresses is not routed. They are significant only on the local link.
  • It shows the global unicast address, which is a routable IPv6 address. This address may be defined statically or be derived from some sort of auto-configuration process.
  • It reveals that the router has joined two reserved multicast group addresses of link-local scope, FF02::1 (all-nodes) and FF02::2 (all routers).
  • It documents the existence  of two solicited-node multicast addresses, which appear in messages used for tasks such as layer 2 address resolution. The solicited-node multicast address of a node has a link-local scope and is derived by juxtaposing the lower 24 bits of its unicast address to the prefix FF02::1:FF/104.

A question may arise at this point: what are these two solicited-node multicast addresses ?

  • One is associated with the link-local unicast address (dynamically generated from the MAC)
  • The second relates to the global unicast address (statically configured as 2001:db8:49::2/64)

Figure 2: Sample output of the “show ipv6 interface” command

 ** Topics for study:

  • Revisit the previous post to learn more about the EUI-64 interface ID.
  • Research and list some other reserved multicast addresses. What they are used for ?
  • Can you describe the concept of address scope in IPv6 ?
  • Consider that a router has the MAC address 001f.9e56.e4c8 on its interface FastEthernet3 and that it has not been assigned any unicast address. What would be its link-local address ? What reserved multicast-groups will the router join (on this interface) ? How many solicited-node multicast group addresses will the router use ? (What are these addresses ?)

** Related Posts:

Leave a comment

Filed under English, IPv6

IPv6: Deriving the EUI-64 Interface Identifier

IPv6 supports the automatic creation of an interface identifier for a host, by using an IEEE-defined format known as the modified Extended Unique Identifier (EUI-64) .

The modified EUI-64  interface ID, obtained from the MAC address (48 bits), is used to identify a host on a given IPv6 link (subnet). The process for deriving such an address from the MAC is described below:

  • The 24 least significant bytes of the EUI-64 correspond to the Extension ID of the MAC (24 lower bytes, as shown, in the figure)
  • The next 16 bits of the EUI-64 ID have the fixed value 1111-1111-1111-1110 ( = 0xFFFE)
  • The 24 most signifcant bytes are taken from the Company ID part of the MAC address (as depicted in the figure)
  • The universal/local (u) bit of the Company ID  part of the MAC address  (Organizationally Unique Identifier) is inverted.
Obtaining the EUI-64 interface ID from the MAC Address

The figure also documents the formats of two important types of IPv6 Addresses that can use the automatically generated Interface ID:

  • Link-local addresses: used in activities like automatic address configuration and neighbor discovery, or in situations when no routers are present on a link. These addresses are, most of the times, generated automatically by combining the link-local prefix, FE80::/10, with a sequence of 54 zeros and a 64-bit interface identifier. As the name implies, this class of addresses is not routed. They are significant only on the local link.
  • Global unicast addresses: these are routable IPv6 addresses, whose host portion may be defined statically or by using the EUI-64 ID. The prefix and the subnet ID are manually configured or obtained by some dynamic manner (such as stateless autoconfiguration or DHCP).

** Notes:

  • When you issue the ipv6 enable command on an interface of a Cisco IOS router, an IPv6 link-local address is automatically generated.
  • If ipv6 enable is the single v6 command you have configured, the router will behave as an IPv6 host on that interface (and join the all-nodes multicast group, FF02::1).
  • To instruct IOS to start operating as a v6 router, you will need to issue the ipv6 unicast-routing global configuration command. The router will then join the all-routers multicast group FF02::2).
  • Another post will examine the solicited-node multicast address.

** Related Posts:

Leave a comment

Filed under English, IPv6