CCIE R&S Prep: IPv6 Part 2

This is the second CCIE R&S prep blog on IPv6, IPv6 Part 2. On March 1, 2013 I blogged that I intended to start a series of CCIE R&S Written exam prep blogs. That blog contains the “ground rules” and some general advice. The full URL for it is http://netcraftsmen.net/blogs/entry/ccie-ras-written-review-blog-series.html. The first blog in the series was IPv6 Part 1.

It turns out there were three bits that should have been in the prior blog but dropped out somewhere along the way. So I’ll put them here, next. The rest of this blog covers IPv6 tunneling variants in summary form, with config samples.

IPv6 Filtering

IPv6 Redistribution

• IPv6 can redistribute routing protocols, here is the generic router command syntax:

• A route map can be used.
• Note the “include-connected” option. It redistributes connected prefixes on the interface where the source protocol is running.

IPv6 Other

• NAT64 is better in practice than NAT-PT, latter has ALG (App Layer Gateway) for DNS and the fixups can create problems. Cf. Ivan  Pepelnjak blogs, RFC’s, and other sources Ivan cites at ipspace.net.
• IPv6 only uses named ACLs. They can be used as access-class on the vty lines.
• IPv6 ACLs implicitly allow ND unless you block it.
• For QoS, you can use “match protocol ip” and “match protocol ipv6” to treat IPv4 and 6 differently, if desired.
• BGP and MPLS  6PE or 6VPN are not on the CCIE topics list above. Hence I omitted them here. 

IPv6 Tunneling

See also  http://ardenpackeer.com/tutorials/routeswitch/tutorial-ipv6-tunnels-part-1-manual-gre-ipv6ip-tunnels/ and  http://ardenpackeer.com/tutorials/routeswitch/tutorial-ipv6-tunnels-part-2-automatic-6to4-tunnels/

Types of IPv6 over IPv4 overlay tunnels:

• Manually coded destination:
  • Manual IPv6 over IPv4 (NOT “6over4”) tunnel uses IP protocol 41, no GRE header: tunnel mode ipv6ip
  • GRE (IPv4 | GRE | IPv6, slightly bigger header): tunnel mode gre
• Automatic:
  • IPv4-compatible: tunnel mode ipv6ip auto-tunnel. ISATAP is recommended by Cisco over IPv4-compatible.
  • 6to4 (and IPv6 Rapid Deployment, 6RD for SP’s): tunnel mode ipv6ip 6to4
    • 6to4 has no IGP support (there is no link-local capability in 6to4) but BGP will work. Cf. the PacketLife article at http://packetlife.net/blog/2010/mar/15/6to4-ipv6-tunneling/ . Also RFC 3056.
  • Intrasite Automatic Tunnel Addressing Protocol (ISATAP): tunnel mode ipv6ip isatap
  • 6over4: not implemented by Cisco – out of scope
  • Teredo: not supported on routers  – out of scope
  • 6RD (Rapid Deployment, for SP’s) – out of scope

Summary table to memorize:

Manual IPv6IP and GRE

GRE

IPv4 Compatible

• Automatic, uses IPv4-compatible IPv6 addresses, 0’s in the 96 high-order bits, then the IPv4 address in hex at end.
• Some examples show using BGP for dynamic routing with this.

6to4

• Automatic 6to4 allows pockets of IPv6 to be connected. The tunnel is point-to-multipoint. IPv4 treated as NBMA link.
• Uses IPv4 protocol type 41 (also used for ISATAP, IPv6IP manual tunnels). You can only have 1 6to4 and one IPv4 comptible tunnel on a router, and they’d best have different source interfaces (so the rotuer can tell inbound traffic apart, as both use IP protocol 41).
• Relay routers can connect 6to4 networks to native IPv6 networks.
• Format of address: 2002:border-router-ipv4::/48.
• Note: there is no link-local addressing, so IGP routing protocols won’t work. Use static or BGP.

ISATAP

• http://en.wikipedia.org/wiki/ISATAP
• Intra-Site Automatic Tunnel Addressing Protocol. ISATAP is intended for Intrasite IPv6 tunneling. ISATAP uses IPv4 as a virtual NBMA link. It regards the IPv4 as a single link for link-local communications. It does not require IPmc the way 6over4 does. Instead, it does neighbor discovery over IPv4. (Note the addresses contain a router IPv4 address in them.)
• ISATAP hosts must have a potential routers list. Or DNS: isatap.corp.com. This is used to obtain the prefixes on the ISATAP link, and to find the routers, since router discovery won’t work (if unicast only network).
• ISATAP addresses use a global or link local 64 bit prefix followed by 0000:5EFE, making it a /96, then the IPv4 address in last 32 bits.
• Generally you should block IP protocol 41 (IPv6 tunnel / ISATAP) at the firewall.

6over4 Tunnel

• Not implemented by Cisco. Scaling issues. RFC 2529.
• 6over4 tunnels use IPv4 virtual link layer addresses. The link local addresses are FE80::IPv4 address.
• 6over4 requires IPv4 multicast support.
• IP protocol type 41 (ISATAP, 6over4).
• Multicast is used for Neighbor Discovery. An IPv6 multicast packet gets encapsulated in an IPv4 multicast packet with destination 239.192.x.y, where x and y are the last two bytes of the IPv6 multicast address.
• The source interface IP and destination IP (from last 4 bytes of IPv6 address) then are used to tunnel the IPv6 traffic.
• ISATAP has the advantage of not relying on IPmc the way 6over4 does.

Teredo

Not configurable on Cisco routers, included here for completeness of review.

• http://en.wikipedia.org/wiki/Teredo_tunneling
• Teredo is encapsulated IPv6 in IPv4 UDP. Teredo server listens on IPv4 UDP 3544.
• Teredo diagnoses the type of NAT present. Symmetric NAT is not supported.
• Teredo prefix is normally 2001:://32, followed by IPv4 of Teredo server used.
• Teredo relays terminate that and pass traffic as native IPv6.
• Teredo servers do not forward traffic, stateless: supports initial tunnel configuration.
• Intended as temporary last resort.

Related Links

Prior blogs in this CCIE R&S Prep series:

• CCIE R&S Prep: Ground Rules:  https://netcraftsmen.com/blogs/entry/ccie-ras-written-review-blog-series.html
• CCIE R&S Prep: IPv6 Part 1:  https://netcraftsmen.com/blogs/entry/ccie-ras-prep-ipv6-part-1.html

My prior blogs / articles on IPv6:

• Preparing for IPv6
• Introduction to IPv6 — Part 1
• Introduction to IPv6 — Part 2
• Introduction to IPv6 — Part 3
• IPv6 Addressing Plans

Life Log

My consulting workload has picked up, so I’ll be blogging as much as I can around work necessities. I enjoyed the quick trip and final presentation in Boston (you know who you are!) this past Monday, a tightly focused trip. I’m glad Spring has come to the Washington/Annapolis/Baltimore area, making the commute more pleasant. For a while there, it seemed like Winter just wouldn’t end!

Disclosure

The vendors for NFD 5 paid for my travel expenses and perhaps small items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds. I’d like to think that my blogs aren’t influenced by that. Yes, the time spent in presentations and discussion gets me and the other attendees looking at and thinking about the various vendors’ products, marketing spin, and their points of view. I intend to try to remain as objective as possible in my blogs. I’ll concede that cool technology gets my attention!

Stay tuned!

Twitter: @pjwelcher