Junos Training

TheJuniper Networks
new network Sales Education

is here.
© 2014 Juniper Networks, Inc. All rights reserved. CONFIDENTIAL IFT-IPV6-B-ML5 www.juniper.net | 1
IPv6 Technical Essentials
Introduction
© 2014 Juniper Networks, Inc. All rights reserved. | www.juniper.net | Proprietary and Confidential
Navigation
Course Objectives
 On completing this course, you will be able to:
•Describe IPv6
•Describe IPv6 addressing
•Describe IPv6 header format
•Describe IPv6 header extensions
•Describe ICMPv6
•Describe IPv6 neighbor discovery
•Describe IPv6 address auto configuration
•Describe IPv6 routing
•Describe the transition from IPv4 to IPv6
Agenda: IPv6 Technical Essentials
 In this course, we will provide you with:

•An overview of Internet Protocol Version 6 or IPv6.
•We will cover various technical concepts related to IPv6 such
as the IPv6 addressing, header format, header extension,
ICMPv6, neighbor discovery, address auto configuration, and
routing.
•We will also talk about the transition to IPv6 from IPv4.0
With this information, you should be able to acquire complete

technical knowledge about IPv6.
IPv6 Address Representation
 IPv6 addressing
 128 bits
•Represented by 8 colon-separated segments
•Each 16-bit segment written in hexadecimal
IPv6 Address Compaction
 Compaction of Leading Zeros
• Leading zeroes in a 16-bit segment can be compacted.
IPv6 Address Compaction – Double Colon
 Address Compaction
• All zeros in one or more contiguous 16-bit segments can be
represented with a double colon(::)
 Address Compaction
• Double colons can only be used once
 Usage of embedded IPv4 Addresses
•Some transaction mechanisms embed IPv4 addresses in
IPv6 addresses.
•Embedded IPv4 addresses are represented with dotted
decimal.
IPv6 Prefix Representation
 Prefix Length Specification
• CIDR-like notation used to specify prefix length.
IPv6 Prefix Representation
Can be represented as follows:
IPv6 Address Types
 Unicast
• Identifies a single interface
• Packet sent to a unicast address is delivered to the interface identified
by that address.
 Multicast
• Identifies a set of interfaces
• Packet sent to a multicast address is delivered to all interfaces
identified by that address.
• IPv6 has no broadcast addresses
• IPv6 uses “all nodes” multicast instead
 Anycast
• Identifies a set of interfaces
• Packet sent to an anycast address is delivered to the nearest interface
identified by that address (as defined by the routing protocol).
IPv6 Address Scope
 Link-Local
• Used on a single link
• Packets with link-local source or destination addresses are not
forwarded to other links.
 Site-Local
• Used for a single site
• Packets with site-local source or destination addresses are not
forwarded to other sites.
• Applications similar to RFC 1918
 Global
• A globally unique address
• Packets with global addresses can be forwarded to any part of the global
network.
Identifying Address Types
 Different Address Types
Global Unicast Addresses: TLA/NLA Format
 The Address Topology
• FP = Format Prefix (001 for global aggregated unicast addresses)

• TLA-ID = Top- level aggregation identifier
• NLA = Next-level aggregation identifier
• RES = Reserved for future use
• SLA–ID = Site-level aggregation identifier
• Interface ID = Interface identifier
Global Unicast Addresses: New Format
 The Address Topology
• Global Routing Prefix uses CIDR-like hierarchy

• Everyone (from corporations to residences) gets 48-bit prefix
• Everyone gets 16-bit subnet space
• There are some exceptions (very large subscribers, mobile nodes)
Global Unicast Addresses
 Why Fixed Prefix and Subnet Lengths?
• Changing ISPs becomes simpler.
• Eliminates need to justify address space
• Plenty of room to grow:
• 001 is only 1/8th of total address space
• 16-bit subnet field sufficient for most subscribers
•Can simplify multihoming
Interface ID
 Unique to the link
 Identifies interface on a specific link
 Can be automatically derived:
•IEEE addresses use MAC-to-EUI-64 conversion
•Other addresses use other automatic means
 Can be used to form link-local address
 Can be used to form global address with stateless
auto configuration
Multicast Address Format
Common Multicast Addresses
Configuration Example: Junos Router
Interface
IPv6 Addresses
•MAC-to-EUI-64 conversion for Interface ID

•Solicited-node multicast
•IPv6 with embedded IPv4 addresses
•IPv4 compatible IPv6 addresses
Header Format
IPv4 vs. IPv6 Header Formats
IPv4 vs. IPv6 Header Formats
 Where did all the IP fields go?
•In IPv6, extension headers are used to encode optional
Internet-layer information.
•Extension headers are placed between the IPv6 header and
the upper layer header in a packet.
•Extension headers are chained together using the next
header field in the IPv6 header.
IPv6 Extension Headers
Benefits of IPv6 Extension Headers
•IPv4 options required special treatment in routers.

•Options had negative impact on forwarding performance.
•Rarely used
•Extension headers are external to IPv6.

•Routers do not look at these options except for Hop-by-Hop
options.
•No negative impact on routers forwarding performance.
•Easy to extend with new headers and option.
Examples of Extension Headers
IPv6 Extension Header Processing
 Extension Headers
• Extension headers are NOT examined or
processed by any node along a packets delivery
path.
• Only hop-by-hop extension header is processed by
every node along a packet’s delivery path
(including source and destination).
• Hop-by-hop (if present) must immediately follow
IPv6 header.
• Extension headers are processed strictly in order
they appear in the packet.
IPv6 Extension Header Orders
 RFC 2460 recommends following order:
•IPv6 header
•Hop-by-hop options header
•Destination options header
•Destination options header
•Routing header
•Fragment header
•Authentication header
•ESP header
•Upper-layer header
Currently Available IPv6 Options
 Hop-by-hop
•Must be processed by every node on the packet’s path
•Must always appear immediately after IPv6 header
•Two hop-by-hop options already defined:
• Router alert option
• Jumbo payload option
 Destination
•Meant to carry information intended to be examined by the
destination node
•Only options currently defined are padding options to fill out
header on a 64-bit boundary if (future) options require it.
Routing Header
 Next header value: 43
 Provides “source-routing” functionality
Format
Fragment Header
 Used to provide datagram fragmentation
Format
Authentication
 Provides data integrity and authentication
Format
Encapsulating Security Payload (ESP)
 Provides confidentiality, data origin authentication,
connectionless integrity, and anti-replay service
Format
ICMPv6
 Many of the same functions as ICMPv4
•ICMPv4 Protocol Number = 1
•ICMPv6 Next Header Number = 58
 Adds new message and functions
•Neighbor discovery
•Stateless autoconfiguration
•Mobile IPv6
ICMPv6 Message Types
 RFC 2463
•Common Functions
• Destination unreachable error messages
• Packet too big
• Time exceeded
• Parameter problem
• Echo request and reply
ICMPv6 Message Types
 RFC 2461
• Used for neighbor discovery protocol
IPv6 Neighbor Discovery
 RFC 2461
•Neighbor can be router or host.
•Performs several functions:
•Link-layer address resolution
•Router discovery
•Local prefix discovery
•Address autoconfiguration
•Parameter discovery
•Next hop determination
•Tracks neighbor and router rechargability
•Duplicate address detection
•Redirects
Comparison to IPv4 Functions
 Similar IPv4 functions:
•ARP
•ICMP Router Discovery
•ICMP Redirect
 IPv4 has no agreed-upon mechanism for neighbor
unreachability detection:
•Detects failing routers and links
•Detects nodes that change their link-layer address
•Unlike ARP, detects half-link failures
Improvements Over IPv4
 Router discovery part of base protocol
• Hosts do not need to “snoop” routing protocols.
 RAs and redirects carry link-layer addresses
• No additional packet exchange needed.
 RAs carry link prefixes
• No separate mechanism to configure “netmasks”
• Enables address autoconfiguration
• Multiple prefixes can be associated with same link.
 RAs can advertise link MTUs
• Ensures all nodes on link use same MTU value.
 Immune to reception of off-link ND messages
• Hop limit always set to 255
• IPv4 ICMP Redirects and Router Discovery messages can be sent from
off link.
Router Discovery
 Router Advertisements sent periodically
•Interval randomized to prevent synchronization.
•Configurable range determined by:
• MinRtrAdvinterval (default 200 seconds)
• MaxRtrAdvinterval (default 600 seconds)
•RAs sent to All-Nodes multicast address (ff01::1)
 RAs sent in response to Router Solicitations
•RAs sent to All-Router multicast address (ff01::2).
•RA unicast to soliciting node.
Router Advertisement Information
 Current hop limit
• Value to be used by outgoing IP packets
 Address configuration flags
•“M” and “O” bits
 Router lifetime
• Lifetime for default router
 Reachable time/Retrains timer
• Used for router unreachability detection
 Source link-delay address (optional)
• Can be omitted for in-bound load balancing
 MTU (optional)
• If AdvLinkMtu is configured
 Prefix information (optional)
• Used for address autoconfiguration
Unsolicited and Solicited Router
Advertisement
Unsolicited and Solicited Router
Advertisement
Choosing a Default Gateway and Redirect
 Implementations may randomly select a default router.

 Implementations may cycle through default list round-robin.
 What happens when default router is the wrong router?
Choosing a Default Gateway and Redirect
Neighbor Cache
Neighbor Address Resolution
 Equivalent function to IPv4 ARP:
 But multicast instead of broadcast
 Check Neighbor Cache for address
 If no address, create an Incomplete entry for target
address
 Send Neighbor Solicitation to Solicited-Node
Multicast address
 Solicited node changes Incomplete entry to
Reachable
Solicited-Node Multicast Address
 All multicast-capable interfaces require to listen.
 Formed to appending low-order 24 bits of target IPv6
address to prefix ff02:0:0:0:1:ff00::/104
 Address differing only in high-order bits will map to same
solicited-node multicast:
• Useful when multiple addresses assigned the interface
• Reduces number of multicast addresses a node must listen for
Next-Hop Discovery
 Check Neighbor Cache for existing next-hop

entry for particular destination
 Check whether destination is on- or off- link
 On-link: Sent directly to destination
 Off-link: Sent to default router
 Identify link-layer address of next-hop
Neighbor Unreachability Detection
 Neighbor cache stores information about neighbors
•IP address
•Link-layer address
•Reachability state
 Neighbor reachability states:
•INCOMPLETE
•REACHABLE
•STALE
•DELAY
•PROBE
Address Autoconfiguration
 Stateless autoconfiguration
•Requires only a router
•Key advantage for applications such as mobile IP
 Stateful autoconfiguration
•When more control is desired
•DHCPv6
 Stateless and Stateful can be combined
• “M” and “O” flags in RA
• M flag: Stateless Address Autoconfiguration Y/N
• O flag: Stateless Autoconfigure Other Parameters Y/N
Stateless Autoconfiguration
 Interface ID automatically derived
•IEEE addresses use MAC-to-EUI-64 conversion
•Other addresses use other means, such as random number
generation
 Host creates a link-local address
 Host performs duplicate address check
 Host sends RA to the all-routers multicast address
(ff01::2)
 Router unicasts RA with prefix information
 Host adds prefix to Interface ID to form global
unicast address
MAC-to-EUI-64 Conversion
 First three octets of MAC becomes Company-ID
 Last three octets of MAC becomes Node-ID
 Oxfffe inserted between Company-ID and Node-ID
 Universal/Local-Bit (U/L-bit) is set to 1 for global
scope
MAC-to-EUI-64 Conversion Example
Using the EUI-64 Interface ID and Solicited-
Node Multicast Revisited
 EUI-64 Address: 200:bff:fe0a:2d51
 Link-Local Address: fe80:200:bff:fe0a:2d51
 Global Unicast Address:
3ffe:3700:1100:1:200:bff:fe0a:2d51
 Interface Address #1:
3ffe:3700:1100:1:200:bff:fec6:45ee
 Interface Address #2:
2001:468:1100:1:200:bff:fec6:45ee
 Solicited-Node Multicast Address: ff02::1:ffc6:45ee
•Last 24 bits are not changed by autoconfiguration or by
solicited node multicast
Address Autoconfiguration: A Security
Problem? and Privacy Addresses
 Interface ID remains constant for a host
•Even when prefix information changes
•Unlike IPv4, when entire address changes
 Mobile users can be tracked
 Usage for always-on addresses can be tracked
 This is of some concern for some, not for others
 Two solutions:
•Always use stateful autoconfiguration (DHCPv6)
•Use privacy addresses for outgoing connections
Address Autoconfiguration: A Security
Problem? and Privacy Addresses
 RFC 3040
 A new Interface ID is randomly generated
•Whenever a new public address is configured
•Periodically (period is configurable)
 Both autoconfigured public and private addresses
are used
•Public for incoming connections (DNS registered)
•Private for outgoing connections
Stateful Autoconfiguration: DHCPv6
 Currently in Internet-draft
 Many changes from DHCPv6
•Configuration of dynamic updates to DNS
•Address deprecation for dynamic renumbering
•Authentication
•Clients can ask for multiple IP addresses
•Addresses can be reclaimed
•Integration between stateful and stateless autoconfiguration
 Uses multicasting
•All_DHCP_Agents: ff02::1:2
•All_DHCP_Servers: ff05::1:3
Duplicate Address Detection
 Must be performed by all nodes
 Performed with both stateless and stateful
autoconfiguration
 Performed before assigning a unicast address to an
interface
 Performed on interface initialization
 Not performed for anycast addresses
 Link must be multicast capable
 New address is called “tentative” as long as
duplicate address detection takes place
Duplicate Address Detection
 Interface joins all-nodes multicast group
 Interface joins solicited-node multicast group
 Node sends one NS with:
• Target address = tentative IP address
• Source address = unspecified (::)
• Destination address = tentative solicited-node address
 If any address already exists, the particular node sends a NA
with:
• Target address = tentative IP address
• Destination address = tentative solicited-node address
 If soliciting node receives NA with target address set to the
tentative IP address, the address must be duplicate.
Configuration Example: Router Discovery
Configuration Example: Windows XP Host
MTU Path Discovery
 IPv6 routers do not fragment packets
 Minimum MTU for IPv6: 1280 bytes
 Recommended MTU: 1500 bytes
 Nodes should implement MTU PD
 Otherwise they must use minimum MTU
 MTU path discovery works for unicast and multicast
 MTU path discovery uses ICMP “packet too big” error
messages
Configuration Example: Static Route
RIPng
 RFC 2080 describes RIPngv1, not to confused with
RIPv1
 Based on RIP Version 2 (RIPv2)
 Uses UDP port 521
 Operational procedures, timers and stability
functions remain unchanged
 RIPng is not backward compatible to RIPv2
 Message format changed to carry larger IPv6
addresses
RIPng
IS-IS and Configuration Example: IS-IS for
IPv6 Only
 ‘draft-isis-ipv6-02.txt’, Routing IPv6 with IS-IS
 2 new TLVs are defined:
•IPv6 Reachability (TLV type 236)
•IPv6 Interface Address (TLV type 232)
 IPv6 NLPID = 142
IS-IS and Configuration Example: IS-IS for
IPv6 Only
•By default, IS-IS routes both IPv4 and IPv6
OSPFv3 and OSPFv3 Differences from
OSPFv2
 Unlike IS-IS, entirely new version required
 RFC 2740
 Fundamental OSPF mechanisms and algorithms unchanged
 Packet and LSA formats are different
 Runs per-link rather than per-subnet
 Multiple instances on a single link
 More flexible handling of unknown LSA types
 Link-local flooding scope added
• Similar to flooding scope of type 9 Opaque LSAs
• Area and AS flooding remain unchanged
 Authentication removed
 Neighboring routers always identified by RID
 Removal of addressing semantics
• IPv6 addresses not present in most OSPF packets
• RIDs, AIDs, and LSA IDs remain 32 bits
OSPFv3 LSAs
Configuration Example: OSPFv3
Multiprocotol BGP-4 and Example
Configuration: BGP
 Two new attributes support multiprotocol BGP-4 (aka BGP+)
• Multiprotocol reachable NLRI (MP_REACH_NLRI)
• Multiprotocol unreachable NLRI (MP_UNREACH_NLRI)
 MBGP extensions use for IPV6 is described in RFC 2545
 MP_REACH_NLRI attribute describes reachable destinations
 Attribute contains information about:
• Network layer protocol (i.e. IPv6)
• Prefixes
• Next-hop to reach prefixes
 MP_REACH_NLRI updates include:
• One next-hop address
• List of associated NLRI’s
 Follows BGP-4 rules for next-hop attribute
 IPv6 BGP routers advertise global address of NH-router
Multiprocotol BGP-4 and Example
Configuration: BGP
The Multihoming Problem
 ISP1 must “punch a hole” in its CIDR block

 ISP2 must advertise additional prefix
 Contributes to routing table explosion
 Contributes to Internet instability
• Due to visibility of customer route flaps
• Due to increased convergence time
 Same problem applies to provider-independent (PI) addresses
Possible IPv6 Multihoming Solutions
 IPv6 provides opportunities to fix multihoming problem
• Multiple unicast addresses per interface
• How does DNS work in this environment?
• How is source address chosen?
 Exchanged based addressing
• One TLA assigned to multiple metro ISPs
• How do ISPs negotiate and manage interconnects?
 Router Renumbering Protocol
 Globally unique node IDs
 Work has begun in this area:
• IETF multi6 WG
• Various R&D bodies
• LIN6 (Location-Independent Networking for IPv6)
Transitioning to IPv6
 No “Flag Day”
• Last Internet transition was 1983 (NCP->TCP)
 Transition will be incremental
• Possibly over several years
 No IPv4/IPv6 barriers at this time
 No transition dependencies
• No requirement of node X before node Y
 Must be easy for end user
• Transition from IPv4 to dual stack must not break anything
 IPv6 is designed with transition in mind
• Assumption of IPv4/IPv6 coexistence
 Many different transition technologies are A Good Thingtm
• “Transition Toolbox” to apply to myriad unique situations
Types of Transition Mechanisms
 Dual Stacks
•IPv4/IPv6 coexistence on one device
 Tunnels
•For tunneling IPv6 across IPv4 clouds
•Later, for tunneling IPv4 across IPv6 clouds
•IPv6 <-> IPv6 and IPv4 <-> IPv4
 Translators
•IPv6 <-> IPv4
Dual Stacks
 Usually just “dual layer,” not entire stack.
Tunnel Applications and Types
Tunnel Applications and Types
 Configured tunnels
• Router to router
 Automatic tunnels
• Tunnel brokers (RFC 3053)
• Server-based automatic tunneling
• 6to4 (RFC 3056)
• Router to router
• ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
• Host to host, host to router, router to host
• 6over4 (RFC 2529)
• Host to host, host to router, router to router
• Requires IPv4 multicast network
• Ter-E-do
• aka Shipworm
• For tunneling through IPv4 NAT
• Uses UDP
• DSTM (Dual Stack Transition Mechanism)
• aka 4over6
• IPv4 in IPv6 tunnels
• IPv64
Configuration Example: Configured GRE
Tunnel, MPLS Tunnel
Configuration Example: Configured GRE
Tunnel, MPLS Tunnel
6to4
 Site must have at least one globally-unique IPv4 address.
 Uses IPv4 embedded address
 Router advertises 6to4 prefix to hosts
6to4
Configuration Example: Windows XP 6to4
Interface
ISATAP
 Uses IPv4 compatible IPv6 address:
•Format: ::5efe:W.X.Y.Z
•W.X.Y.Z = IPv4 address mapped to last 32 bits
•5efe = IANA-reserved identifier
ISATAP
ISATAP
Configuration Example: Windows XP
ISATAP Interface
Translators
 Network level translators:
•NAT-PT (RFC 2766)
•Stateless IP/ICMP Translation Algorithm (SIIT) (RFC 2765)
•Bump in the Stack (BIS/mBIS) (RFC 2747)
 Transport level translators:
•Transport level translators (RFC 3142_
 Application level translators:
•Application Level Gateway (ALG)
•Bump in the API (BIA)
•SOCKS64 (RFC 3089)
Transition Issues: DNS
 Namespace fragmentation
•Some names of IPv4-only host resolve a name in the IPv6
namespace, and vice versa?
•How does a dual-stack host know which server to query?
•How do root servers share records?
 MX records
•How does an IPv4 user send mail to an IPv6 user and vice
versa?
 Solutions
•Dual stacked resolvers
•Every zone must be served by at least one IPv4 DNS server
•Use translators (NAT-PT does not work for this)
DNS AAAA Records
 RFC 1886
 BIND 4.9.4 and up; BIND 8 is recommended
 Simple extension of A records
 Ipv6.int analogous to in-addr.arpa for reverse mapping
 Difficult network renumbering
• New TLA, NLA, or SLA means changing all AAA records in zone
DNS A6 Records and DNAME and A6 Record
Chain
 A6 records replace AAA records
•RFC 2874
 DNAME and blistering labels for reverse mapping
•RFC 2672 and RFC 2673
•DNAME not much more complex than CNAME
 BIND 9
 More complicated records, but easier renumbering
•Segments of IPv6 address specified in chain of records
•Only relevant records must be changed when renumbering
•Separate records can reflect addressing topology
DNS A6 Records and DNAME and A6 Record
Chain
Transition Issues: Security
 Many transition technologies open security risks
such as DoS attacks.
 Examples:
•Abuse of IPv4 compatible addresses
•Abuse of 6to4 addresses
•Abuse of IPv4 mapped addresses
•Attacks by combining different address formats
Transition Security Guidelines
 Allow only explicitly configured tunnels:
•Manual configuration
•Automatic tunnels with proper authentication
 Do not embed IPv4 addresses in IPv6 address.
 Do not define IPv6 address formats that do not
appear on the wire.
 Filter carefully to block spoofed packets.
Transition Planning
 Assumption: Existing IPv4 network
 Easy Does it
•Deploy IPv6 incrementally, carefully
 Have a master plan
 Think IPv4/IPv6 interoperability, not migration
 Evaluate hardware support
 Evaluate application porting
 Monitor IETF ngtrans WG
Transition Strategies
 Edge-to-core
•The edge is the killer app!
•When services are important
•When addresses are scarce
•User (customer) driven
 Core-to-edge
•Good ISP strategy
 By routing protocol area
•Where areas are small enough
 By subnet
•Probably too incremental
Additional Resources
 Education Services training classes

•http://www.juniper.net/training/technical_education/
 Juniper Networks Certification Program Web site
•www.juniper.net/certification
 Juniper Networks documentation and white papers
•www.juniper.net/techpubs
 To submit errata or for general questions
•elearning@juniper.net
Evaluation and Survey
 You have reached the end of this Juniper Networks
eLearning module
 You should now return to your Juniper Learning
Center to take the assessment and the student
survey
•After successfully completing the assessment, you will earn
credits that will be recognized through certificates and non-
monetary rewards
•The survey will allow you to give feedback on
the quality and usefulness of the course
© 2014 Juniper Networks, Inc.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and

ScreenOS are registered trademarks of Juniper Networks, Inc. in the
United States and other countries. The Juniper Networks Logo, the
Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All
other trademarks, service marks, registered trademarks, or registered
service marks are the property of their respective owners. Juniper
Networks reserves the right to change, modify, transfer, or otherwise
revise this publication without notice.
CONFIDENTIAL

Junos Training

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Junos Training

Hochgeladen von

Copyright:

Verfügbare Formate

TheJuniper Networks

new network Sales Education

 In this course, we will provide you with:

With this information, you should be able to acquire complete

Can be represented as follows:

• FP = Format Prefix (001 for global aggregated unicast addresses)

• Global Routing Prefix uses CIDR-like hierarchy

•MAC-to-EUI-64 conversion for Interface ID

•IPv4 options required special treatment in routers.

•Extension headers are external to IPv6.

 Implementations may randomly select a default router.

 Check Neighbor Cache for existing next-hop

 ISP1 must “punch a hole” in its CIDR block

 Router advertises 6to4 prefix to hosts

 Education Services training classes

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and

Das könnte Ihnen auch gefallen