CCIE R&S Prep: IPv6 Part 1

Author
Peter Welcher
Architect, Operations Technical Advisor

On March 1, 2013 I blogged that I intended to start a series of CCIE R&S Written exam prep blogs. This is the first of those, IPv6 Part 1. Just for the fun of it! See my prior blog for the ground rules and some general discussion, at 
http://netcraftsmen.net/blogs/entry/ccie-ras-written-review-blog-series.htmll. I do recommend other books and sources for protocol details, the focus here is more on some selected key items to learn or memorize. And I’ve tried hard to be accurate.

In general, the Cisco documentation is a good resource on IPv6. See  http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/12-4t/ipv6-12-4t-book.html.

Published Study Topics

  • Implement IPv6 addressing and different addressing types
  • Implement IPv6 neighbor discovery
  • Implement basic IPv6 functionality protocols
  • Implement tunneling techniques
  • Implement OSPFv3
  • Implement EIGRPv6
  • Implement filtering and route redistribution

IPv6 Headers

From the Cisco documentation: see also  http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd80260042.pdf.

IPv6 header

  • The IPv6 Ethertype is 0x86DD.
  • The header is 40 bytes plus variable length extension headers.In contrast, IPv4 headers are 20 bytes (plus optional headers).
  • See also  IPv6 Addressing Plans
  • Anycast is formed out of IPv6 unicast addresses. The keyword “anycast” needs to be appended in a configuration since the anycast address should not be used as the source of a packet. An address with all 0s for the last 64 bits (interface ID part of address) is a subnet router anycast. Any address with all 1s (non-EUI-64) or all 1s in the last 57 bits is anycast, at the high end of a /64 subnet (leaving 7 bits for address). Note the U/L bit (bit 7 from the beginning of the 64 bits) should be 0 since the address is not unique. For more details include reserved numbers in that 0-127 range for 7 bits, etc., see RFC 2526 (content deemed unlikely to be on the test).

IPv6 Addresses and Types

IPv6 Unicast Addresses

From one of my presentations (IPv6 Addressing Plans).

ipv6-addressing-format

MEMORIZE

Address Type

Prefix in Hex

Bits

Global unicast

2000::/3

001x xxxx xxxx xxxx /3

Teredo client

2001::/32

0010 0000 0000 0001 0000 0000 0000 0000 /32

Followed by IPv4.

Documentation prefix

2001:db8::/32

0010 0000 0000 0001 0000 1101 1011 1000 /32

6to4 auto-tunnel

2002::/16

0010 0000 0000 0010 /16

2002:border-router-ipv4::/48

Unique local address (ULA)

FC00::/8 (managed)

FD00::/8 (random)

1111 1100 xxxx xxxx /8

1111 1101 xxxx xxxx /8

Link local

FE80::/10

(FE80::/64 in practice)

1111 1110 10xx xxxx /10

ISATAP tunnel

<64-bit global or link local prefix>::5EFE:/96

Prefix::5EFE:<ipv4 address of the link>

Site local unicast (deprecated)

FEC0::/10

1111 1110 11xx xxxx /10

IPv4-compatible IPv6

(Deprecated)

::pqrs:tuvw or ::M.N.P.Q

96 0 bits, then IPv4 in hex

IPv4 mapped

::FFFF:pqrs:tuvw or ::FFFF:M.N.P.Q

80 0 bits, then FFFF, then the IPv4 in hex

Unspecified

0::0 or ::/128

Loopback

::1

Multicast

FF00::/8

See below

Solicited node

FF02::0001:FF00:0000/104

Ends in last 24 bits of unicast or anycast IPv6 address. See below.

IPv6 SSM

FF3x::/96 (x=scope)

1111 1111 0011 xxxx:: /96

Treat as reserved /32 in case of changes.

Multicast, embedded RP

FF70::/12

1111 1111 0111 xxxx /12. See below.

Basic IPv6 Configuration
! CONFIG SAMPLE ————————————————————-
! CONFTYPE: Basic IPv6
ipv6 unicast-routing
interface ethernet 0
ipv6 address 2001:DB8::1/64
ipv6 address 2001:DB8::/64 eui-64
!
standby version 2
standby 2 ipv6 2001:DB8::789:1:0:0:1/64
standby 2 priority 150
standby 2 preempt
! alternatives:
ipv6 address ipv6-address / prefix-length link-local
ipv6 address ipv6-prefix / prefix-length anycast
ipv6 enable
!
ipv6 access-list SAMPLE
permit tcp 2001:DB8:0100:0200::/32 any
deny ipv6 fec0::/16 any
!
interface ethernet 0
ipv6 traffic-filter SAMPLE in
!
IPv6 Ports

Usage

Protocol

Port

DHCPv6 Client to server

UDP

547

DHCPv6 Server to client

UDP

546

Basic IPv6 Functionality
  • IPv6 uses AAAA and PTR records for DNS.
  • Note Cisco IPv6 general prefixes (useful for changing prefix):
! CONFIG SAMPLE ————————————————————-
! CONFTYPE: IPv6 general-prefix
ipv6 general-prefix prefix-name {ipv6-prefix/prefix-length | 6to4 interface-type interface-number | 6rd interface-type interface-number}
!
! example:
ipv6 general-prefix my-prefix 2001:DB8:2222::/48
!
interface …
ipv6 address my-prefix 0:0:0:A0::1 ! First /48 gets over-written
!
EUI-64 Address Format
  • All interfaces must have a link-local address. It can be the link local prefix ending in an EUI-64 address derived from the MAC address. I.e. FE80::<EUI-64 address>.
  • EUI-64: put FF:FE into the middle of the MAC, and toggle the 7th initial bit to 1 to indicate it is global. (Usually ends up as hex 2.)
  • Cisco routers have a MAC pool for use if there are no Ethernet interfaces and EUI-64 is needed.
MTU / P-MTU-D 
  • In IPv6, hosts do Path MTU Discovery. It uses ICMPv6 “TooBig” messages. (PJW note: the proposed standard for IPv4 PMTUD black hole detection is not a standard, still. So I imagine that IPv6 counting on it working is rather optimistic, for similar reasons.)
  • Routers don’t fragment in IPv6.
  • The IPv6 minimum MTU is 1280. Cisco recommends 1500.
  • Fragments use header extension.
  • Otherwise similar to IPv4.
ICMPv6
  • ICMPv6: 0x3a (decimal 58) in next header field.
  • ICMPv6 is used for Neighbor Discovery, Path MTU Discovery, Multicast Listener Discovery or MLD.
  • See also   http://en.wikipedia.org/wiki/ICMPv6. It includes a list of all the many types of ICMPv6 messages.
IPv6 Neighbor Discovery

From   http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol (view the link for more details):

  • NDP defines the following five ICMPv6 packet types:

Message Type

Destination IPv6 Address

Router Advertisement

To FF02::1 periodically, or to querying host

Router Solicitation

To FF02::2

Neighbor Advertisement

FF02::1 periodically, or to requesting node

Neighbor Solicitation

Solicited node multicast or host address if known

Redirect

Source of request

  • Router Advertisements provide for a default gateway and support auto-configuration (SLAAC).
  • Neighbor Solicitation does Duplicate Address Detection (“DAD”), verifies reachability, and maps L3 to L2 addresses (ARP replacement).
  • Solicited node multicast is used for ARP replacement neighbor discovery. It uses a special link local multicast address, FF02::0001:FFxx:xxxx, where x is the low-order 24 bits of the unicast or anycast address.
DHCPv6 / SLAAC
  • Stateless auto-configuration or SLAAC: append EUI-64 to the 64 bit prefix in the RA messages, then do DAD (Duplicate Address Detection).
  • There are gaps in SLAAC, e.g. DNS server addresses and domain name to use.
  • DHCPv6 or stateful auto-configuration can be used to assign addresses.
  • DHCPv6 client sends to FF02::1:2, all DHCP relay agents and servers. Port 547. Or to FF05::1:3, all DHCP servers. The reply goes back on UDP 546.

IPv6 Routing

  • IPv6 on Frame Relay needs mapping of both link local (w/ “broadcast”), and link address: 2 lines of configuration. If only the link-local information is configured, routing will come up but (local subnet?) traffic cannot be sent due to FR encapsulation failure (subnet mapping issue). (Per Odom book.)
  • IPv6 redistribution can use a route-map based on ACL or prefix list.
  • Since IPv6 has nothing like proxy ARP, static routes to interfaces on multi-access media must include the next hop address. (“Fully specified static route”.)
  • Directly attached (interface) static routes have admin distance 1, unlike IPv4.
IPv6 RIPng
  • RIPng is a new protocol (different than RIPv2) so uses UDP port 521.
  • Routing is configured on the interface, not under the router command.
IPv6 EIGRP
  • IPv6 EIGRP: Need not configure EIGRP on passive interface, just the router mode passive command – the prefix will be included in routing updates.
  • Adjacency: same as IPv4 EIGRP.
  • EIGRP route filtering distribute lists use a prefix list, route maps are not supported with them. (Route-maps are OK in redistribute commands.)
  • Note that a router ID must be configured for EIGRP! (per Odom; per lab testing this is only if no IPv4 address is on an active interface.)
  • IPv6 has no classful routing, so “no auto-summary” is not relevant / not needed.
! CONFIG SAMPLE ————————————————————-
! CONFTYPE: IPv6 EIGRP
ipv6 unicast-routing
!
interface gigabitethernet0/0
no shut
ipv6 enable
ipv6 router eigrp 1
!
! SYNTAX: ipv6 router eigrp as-number [eigrp event-log-size event-log-size]
!
ipv6 router eigrp 1
eigrp router-id 10.1.1.1 ! required (TFM: if no IPv4 address active)
no shutdown ! EIGRP for IPv6 defaults to shutdown
passive-interface [default | interface-type interface-number]
!
IPv6 OSPFv3
General Info
  • See also   http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/prod_presentation0900aecd80311e31.pdf.
  • OSPFv3 can fragment. The Link State ID is a fragment number. Recall that IPv6 routers do not fragment.
  • OSPF protocol processing is per-link, not per-subnet. This accommodates having several addresses on a link. It is also tied to why there are two new LSA types, to carry the addressing info separately from the link info.
  • The size of the header is reduced from 24 to 16 bytes. Instance ID (1 Byte) is OSPF process ID, link local. Authentication fields were suppressed. IPsec is to be used instead.
  • Link state ID in the LSA header carries the interface ID for the DR interface.
  • OSPFv3 supports multiple instances on links. The instance ID must match to form an adjacency.
  • OSPFv3 needs a router ID to operate. If there is an interface with an IPv4 address, the OSPFv2 router ID rules apply. If not, you must specify a router ID, which is a 4 octet number.
  • Note the router ID is a number in the IPv4 address format. The manual says it is a 32 bit number. 0.0.0.0 is reserved and per online / experiment, Cisco routers will not accept it. So perhaps in show output it indicates a lack of OSPFv3 router ID. I can’t get OSPFv3 running without a router ID however. Putting OSPFv3 on an interface auto-creates the OSPF process / router ID if there is an up IPv4 interface to provide a router ID as per OSPFv2. Removing all IPv4 IP addresses and clearing the OSPF process does not change the router ID.
  • As with OSPFv2, redistribution into OSPFv3 does not require a metric. Default is 20.
  • OSPFv3 authentication and encryption can be applied per-interface or per-area. It uses one of AH or ESP.
  • Requirements for OSPFv3 adjacency:
  • (Connectivity)
  • Dead timer >= 4 x hello timer
  • Instance ID !!
  • Plus the OSPFv2 list:
  • Area ID
  • Area type (options like stub, NSSA)
  • Subnet and mask
  • Authentication
  • Not duplicate router ID
  • Timers: HelloInterval, RouterDeadInterval
  • (Not verified but must be appropriate: the network type)
OSPFv3 LSA Function Codes
  • There are two new LSA types carrying info in lower numbered LSA types in OSPFv2: types 8 and 9. They allow separating multiple interface addresses from link topology.
  • Function codes are the counterpart of the OSPFv2 LSA type numbers.
  • The OSPFv3 type code indicates function but also scope. See the table below.
  • Prefix 0x0 is link local, 0x2 floods w/in the area, 0x4 the AS.
  • Most LSA’s 1-7 are area flooding, type 5 (external) is AS scope, types 8 and 11 are link local (addresses on the link, local graceful restart).
  • Type 9 carries prefix info that OSPFv2 carried in router and network LSA’s (addresses and subnet masks).
  • OSPFv3 headers contain: version, type, packet length, router ID, area ID, checksum, instance ID, 0.
  • The LSA header contains: LS age, LS type, Link state ID, advertising router, LS sequence number, LS checksum, Length.
  • See also  http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xml or RFC4970.
MEMORIZE

OSPFv2 Type = OSPFv3 Function Code

OSPFv2 Description

OSPFv3 Description

OSPFv3 Type Code

Scope

LSA type 1

Router LSA

Router LSA

0x2001

Area scope

LSA type 2

Network LSA

Network LSA

0x2002

Area scope

LSA type 3

Network Summary LSA

Inter-Area-Prefix-LSA

0x2003

Area scope

LSA type 4

ASBR summary LSA

Inter-Area-Router-LSA

0x2004

Area scope

LSA type 5

AS external LSA

AS external LSA

0x4005

AS scope

LSA type 6

Group Membership LSA (N/A)

Group Membership LSA (N/A)

N/A

N/A

LSA type 7

NSSA External LSAs

Type 7 LSA

0x2007

Area scope

LSA type 8

External Attribute LSA (N/A)

Link local LSA

0x0008

**Link local scope**

LSA type 9

Opaque LSA (link scope)

Intra-area-Prefix-LSA

0x2009

Area scope

LSA type 10

Opaque LSA (area scope)

LSA type 11

Opaque LSA (AS scope)

Used for grace LSA

Used for Grace LSA

0x000b

NSF graceful restart

Sample Config
! CONFIG SAMPLE ————————————————————-
! CONFTYPE: IPv6 OSPFv3
interface Ethernet7/0
ipv6 address 2001:DB8:0:7::/64 eui-64
ipv6 enable
ipv6 ospf 1 area 1
!
ipv6 router ospf 1
router-id 10.11.11.1
area 1 range 2001:DB8::/48
!
! AUTHENTICATION
! On an interface:
interface Ethernet0/0
ipv6 ospf authentication ipsec spi 500 md5 1234567890ABCDEF1234567890ABCDEF
!
! Authentication in an area:
ipv6 router ospf 1
area 0 authentication ipsec spi 1000 md5 1234567890ABCDEF1234567890ABCDEF
!
IPv6 VRF
! CONFIG SAMPLE ————————————————————-
! CONFTYPE: IPv6 VRF
!
! mls ipv6 vrf ! enables it on 6500, not needed on router (or on by default)
vrf definition Test_IPv6     ! generic for both IPv4 and 6, note new syntax
rd rd-num
route-target both rt-info
address-family ipv4       ! can put different route-targets here

address-family ipv6       ! ditto

!
! To upgrade from old to new syntax, use the config command:
vrf upgrade-cli multi-af-mode common-policies vrf vrf1
!
  • Doing this removes IPv6 addresses on interfaces belonging to the upgraded VRFs.

Related Links

If you look at the dates, you’ll notice I wrote these blogs about IPv6 a while ago. But they’re still valid.

My prior articles on IPv6:

Life Log

I taught the Nexus class for Firefly two weeks ago in Hawaii. I’d like to thank the folks in that class for an especially enjoyable class from my perspective, and their great hospitality. I went early and treated myself to  three days of beach time in advance, which certainly also helped improve my attitude in general. (Hint: I’m always glad to teach or consult in Hawaii!) Last week involved some catching up. I hope I’m now better positioned to write blogs and continue both blogs from NFD5 and on the CCIE R&S prep topic. I’ve got lots of ideas, it’s time to research details and write that’s in short supply. (The perennial complaint of the blogger: my job keeps getting in the way!)

Disclosure

The vendors for NFD 5 paid for my travel expenses and small items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds.This blog says nothing favorable about any of them, so there should be no conflict of interest.

Stay tuned!

Twitter: @pjwelcher

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.