Ift Ipv6 A

education services courseware
IPv6 Technical Essentials

Student Guide
IPv6TechnicalEssentials
NOTE:PleasenotethisStudentGuidehasbeendevelopedfromanaudionarration.Thereforeitwillhave conversationalEnglish.Thepurposeofthistranscriptistohelpyoufollowtheonlinepresentationandmayrequire referencetoit.
Slide2
IPv6 Technical Essentials
Introduction
2010 Juniper Networks, Inc. All rights reserved. | www.juniper.net | Proprietary and Confidential
CourseIFTIPV6
JuniperNetworks,Inc.2
Slide3
Course Overview
Welcome to Juniper Networks training course on IPv6 Technical Essentials.
2010 Juniper Networks, Inc. All rights reserved.
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 3
Welcome to the Juniper Networks training program on Internet Protocol Version 6 or IPv6.
CourseIFTIPV6
Slide4
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
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 4
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, and Describe the transition from IPv4 to IPv6.

CourseIFTIPV6
Slide5
Introduction
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 5
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. With this information, you should be able to acquire complete technical knowledge about IPv6.

CourseIFTIPV6
Slide6
IPv6 Address Representation IPv6 addressing 128 bits Represented by 8 colon-separated segments Each 16-bit segment written in hexadecimal
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 6
Let's begin with IPv6 addressing. IPv6 introduces a new 128-bit addressing model. This creates a much larger address space than IPv4 addresses, which are made up of 32 bits. The 128 bits are broken up into eight 16-bit segments. The segments are separated by colons, and are represented in hexadecimal. Shown onscren here is an example of a 128-bit IPv6 address. This way of representing the IP address is inconvenient, and difficult to memorize and work with. Therefore, there are various methods designed to manipulate these addresses and make them easier to work with. We will look at each of them now.

CourseIFTIPV6
Slide7
IPv6 Address Compaction Compaction of Leading Zeros Leading zeroes in a 16-bit segment can be compacted.
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 7
One of the methods of address manipulation is the compaction of leading zeros. Look at this example. The 128 bit address can be compacted as shown onscreen. In this method, we do not write the leading zeros in any 16-bit quantity. Hence, the size of the address can be reduced. In the example, at the second segment in place of 0210, we can write 210. In other words, we discard the zero and it's understood that a blank leading space is a zero. Similarly, the fourth segment 0006 can be written as 6 and so on. An important point to note here is that we can only compact the leading zeros and not trailing zeros as that would obscure the address. In the third segment in the example, 1100 has to be written as 1100 and not just 11. Hence, in this method you can compact only leading zeros and not trailing zeros. There are better methods to perform compaction.

CourseIFTIPV6
Slide8
IPv6 Address Compaction - Double Colon Address Compaction All zeros in one or more contiguous 16-bit segments can be represented with a double colon(::)
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 8
Let's look at this address which consists of a full string of 16-bit segments that are all zeros. With IPv6 address compaction, you can represent a series of all zeros in the segment as a double colon as shown onscreen. Here, the entire address can be written as ff02::1. The double colon represents 1, 2,3,4,5, and 6 segments of zeros. The last segment contains 0001 which can be compacted to 1 discarding the leading zeros. Obviously, this method makes it much simpler than the previous one. However, there are some rules to be followed when using a double colon.
CourseIFTIPV6
Slide9
IPv6 Address Compaction - Double Colon Address Compaction Double colons can only be used once
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 9
The primary rule is that you can use a double colon only once in any IP address. In the example displayed, you can observe that two sets of segments consist of all zeros. They are segments 2 and 3 and also segments 5 and 6. This can be written in two ways: One, as 2001::13 and then just 0 in each other provision. Two, as 13::b0c, and then just 0 for the first half of the segment. The only thing which should not be done is, using the double colon in both the above places. It could represent the above, or the double colon could represent three segments of all zeros and this one, or this could be 1 and this could be 3 segments, you don't know for sure. The double colon is very useful in address compaction though it can be used only once in any address.
CourseIFTIPV6
Slide10
IPv6 Address Compaction - Double Colon Usage of Imbedded IPv4 Addresses Some transaction mechanisms imbed IPv4 addresses in IPv6 addresses. Imbedded IPv4 addresses are represented with dotted decimal.
CONFIDENTIAL
IFT-IPV6
www.juniper.net | 10
Another method of address compaction is the usage of Imbedded IPv4 addresses. Here, you can represent the last 32 bits of an IPv6 address in dotted decimals and that returns in Imbedded IPv4 address. It is used for some transition technologies

CourseIFTIPV6
Slide11
IPv6 Prefix Representation Prefix Length Specification CIDR-like notation used to specify prefix length.
CONFIDENTIAL
IFT-IPV6
For prefix length specification in IPv6, we use a CIDR notation, unlike the IPv4, where the older notations were used in the address map. In CIDR notation we use a forward slash (/) and the number of bits of that address that represent the prefix. In this case, the first 6 digits of this address is the prefix of that address. You can also compact a prefix just as you would compact a complete host-centric IPv6 address.
CourseIFTIPV6
Slide12
IPv6 Prefix Representation
Can be represented as follows:
CONFIDENTIAL
IFT-IPV6
Look at this example. Here, the IPv6 address can be represented in two ways. It is obvious that the second method is better as you can compact the address more with this kind of prefix representation.

CourseIFTIPV6
Slide13
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).
CONFIDENTIAL
IFT-IPV6
Now, let's move on to the address types of IPv6. Unicast address in IPv6 is no different from the unicast address in IPv4. A unicast address represents a single device. Multicast addresses are also just the same as in IPv4. The multicast address represents some group of devices. One significant difference with IPv6 is that there is no broadcast address. Broadcast address is just a special instance of a multicast address in which everyone is the member of the multicast group. IPv6 simply uses that concept, but there is no broadcast address in IPv6. The anycast address allows a packet to be routed to one of a number of different nodes all responding to the same address. The anycast address may be assigned to one or more network interfaces (typically on different nodes), with the network delivering each packet addressed to this address to the "nearest" interface based on the notion of "distance" determined by the routing protocols in use. A router leading services such as the rendezvous points from one of those devices simply attaches or routes to the closest of those addresses. But, if that address fails, it routes to the next closest device. Therefore, anycasting enhances the robustness of the network. There is no difference between the unicast address and an anycast address or in the format. The only difference is in its usage. Hence, an Anycast address is a unicast address that has been assigned to more than one device.

CourseIFTIPV6
Slide14
IPv6 Address Scope Link-Loca 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.
CONFIDENTIAL
IFT-IPV6
Now, let's discuss the different kinds of address scopes. IPv6 addresses have scope, which identifies the application suitable for the address. Unicast addresses support two types of scope: global scope and local scope. There are two types of local scope: link-local addresses and site-local addresses. Link-local unicast addresses are used within a single network link and are significant or unique. The first 10 bits of the prefix identifies the address as a link-local address. Linklocal addresses cannot be used outside a network link. That is, they are not allowed to be advertised off in a link as they may not be significant when distributed over multiple links. Site-local unicast addresses are used within a site or an intranet. A site consists of multiple network links, and site-local addresses identify nodes inside the intranet. Site-local addresses cannot be used outside the site. Site-local addresses or the applications of these can be thought of as the same source of application as RFC 1918 private IP addresses. The global addresses are globally unique throughout the Internet. Multicast addresses support 16 different types of scope, including node, link, site, organization, and global scope. A four-bit field in the prefix identifies the scope.

CourseIFTIPV6
Slide15
Identifying Address Types Different Address Types
CONFIDENTIAL
IFT-IPV6
The different address types can be identified by looking at the leading bits of the address. The address of all zeros is called an unspecified address. They are used in link-local application. It is represented as ::/128. A loopback address is all zeros with the final bit being 1. Multicast address consists of all 1s in the first eight bits. Hence, a multicast address will always be represented as ff. In a link-local unicast address, the first 10 bits are fe8. In a site-local unicast address, the first 10 bits are always fec. The global unicast or anycast addresses are everything else. Therefore, this kind of a table is a useful reference for quickly identifying link-local unicast, site-local unicast and multicast addresses.

CourseIFTIPV6
Slide16
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 SLAID = Site-level aggregation identifier Interface ID = Interface identifier
CONFIDENTIAL
IFT-IPV6
The topology of an IPv6 address is similar to the IPv4 address. The address is divided into two portions, the Network portion, and the node portion. The difference between IPv4 and IPv6 is that in most cases with IPv6 the field and sizes are fixed. Generally, the node portion and the network portion are 64 bits each. Originally, IPv6 addresses were broken up so that there was a format prefix. Currently, the format prefix is 001. There is a Top Layer Aggregation identifier or the TLA-ID, and a next layer aggregation identifier or NLA. Some reserve it for future use RES. There is also a site level aggregation identifier or SLA-ID which you can think of as the subnet ID which is generally 16 bit. But, this format is being rendered obsolete. Let's see the new format that is being used today.

CourseIFTIPV6
Slide17
Global Unicast Addresses: New Format The Address Topology
Global Routing Prefix uses CIRD-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)
CONFIDENTIAL
IFT-IPV6
The format just discussed was considered to be too complex. Now we still have a 64-bit network portion and a 64-bit node portion or an interface ID. The difference is that in place of TLA and NLA, we now simply have a global routing prefix. Apart from this, we also have 16 bits of subnetting. This new IPv6 format helps everyone right from corporation down to a whole network user. The IP address will be given to all the users in the same format. In other words, the users will get 16 bits of subnet space and can conceivably have up to 65,000 subnets. This seems to be a waste of address space. But, the IPv6 address space is so huge that significant depletion of the available addresses is to be expected. The trade off is worth doing that, and everyone gets a 48-bit prefix, starting with 001 and followed by a 45-bit prefix.

CourseIFTIPV6
Slide18
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
CONFIDENTIAL
IFT-IPV6
Though the format discussed is advantageous, it is also wasteful. Changing IP addresses can become much simpler when you have these six architectures for your IPv6 address. It eliminates the need to justify getting new address space. Unless it is for a very large corporation, 16 bits of subnetting is expected to serve very well. There is no need for new address space. Also, there is plenty of room to grow as the format prefix of 001 represents only 1/8th of the entire available IPv6 address space, and it is not expected to be depleted for quite some time. As mentioned earlier, the 16-bit subnet field is sufficient for most subscribers and the other advantage is that it could simplify multihoming. For more information about the address allocation, refer to RFC 3177.

CourseIFTIPV6
Slide19
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
CONFIDENTIAL
IFT-IPV6
In the address format, the last 54 bits are the interface ID. It is the node portion of the IPv6 address. The interface ID should be unique to the link. It identifies a specific interface on a link, and it can be automatically derived. This automatic derivation is done using the MACto-EUI conversion. It can be used for a link-local address; and with stateless autoconfiguration, it can be used to form the global address.

CourseIFTIPV6
Slide20
Multicast Address Format
CONFIDENTIAL
IFT-IPV6
Let's look at the multicast address format. As discussed earlier, in multicast addresses, the first 8 bits are all zeros. There are 4 bits of flags and 4 bits of scoping that define a multicast scope. In the last 112 bits, unlike the unicast address, there is the multicast group ID. Similar to IPv4 multicast addresses, the original sublink of multicast addresses always represent a single group.

CourseIFTIPV6
Slide21
Common Multicast Addresses
CONFIDENTIAL
IFT-IPV6
Displayed are some of the well known IPv6 multicast addresses compared with some well known IPv4 multicast addresses. You can observe the similarities here.

CourseIFTIPV6
Slide22
Configuration Example: JUNOS Router Interface
CONFIDENTIAL
IFT-IPV6
Let's look at a configuration example. One of the pre-requisites to understand this example is familiarity with the JUNOS configuration for JUNOS router. This is JUNOS configuration for a router interface that has an IPv4 address and two IPv6 addresses assigned. In this example, there is a show interface for a particular interface and for family inet, which is JUNOS language and simply means IPv4 with assigning address 206.196.180.113. To assign IPv6 addresses, we simply say family inet6, and you can observe that we have two IPv6 addresses assigned. A long way of the specified prefix link of those addresses. One of the things that is important to know here is that on this one interface we have both IPv4 and IPv6 addresses assigned. This will pop either IPv4 or IPv6. The other significant thing is that with IPv6 we can assign more than one IP address to an interface. You can have multiple IP addresses, and we will see some significance in that as we proceed.

CourseIFTIPV6
Slide23
IPv6 Addresses
MAC-to-EUI-64 conversion for Interface ID Solicited-node multicast IPv6 with imbedded IPv4 addresses IPv4 compatible IPv6 addresses
CONFIDENTIAL
IFT-IPV6
In IPv6 addressing, some of the important points to be learned are : How MAC-to-EUI-64 conversion works for automatically establishing an interface ID; solicited node multicast address; IPv6 addresses with imbedded IPv4 addresses; IPv4 compatible IPv6 addresses which are used for transition technology.

CourseIFTIPV6
Slide24
Header Format
CONFIDENTIAL
IFT-IPV6
Now, let's move on to the header format of IPv6. Displayed are the IPv6 header and the IPv4 header formats. A significant point to notice here is that even though IPv6 addresses are four times larger than IPv4 addresses, the IPv6 header is not very much bigger than the IPv4 header. The reason for this is IPv6 packet headers contain many of the fields found in IPv4 packet headers; some of these fields have been modified from IPv4. Here, you can observe the difference between IPv6 header format and IPv4 header format clearly. You can notice the fields that have been eliminated from the IPv4 header and also some of the generic IPv6 header having no equivalent fields. The 40-byte IPv6 header consists of the following eight fields: Traffic Class is the Class-of-Service or CoS priority of the packet. Destination address contains the final destination node address for the packet. Flow label contains the packet flows requiring a specific CoS. The flow label identifies all packets belonging to a specific flow, and routers can identify these packets and handle them in a similar fashion. Hop limit includes the maximum number of hops allowed. Next header contains the next extension header to examine. Payload length includes the length of the IPv6 payload. Source address includes the address of the source node sending the packet. Version contains the version of the Internet Protocol.

CourseIFTIPV6
Slide25
IPv4 vs. IPv6 Header Formats
CONFIDENTIAL
IFT-IPV6
One of the obvious differences between IPv4 and IPv6 is the version numbers 4 for IPv4 and 6 for IPv6. The Time To Leave or TTL field of IPv4 is changed to Hop Limit field in IPv6. There is no difference in the functionality of the two fields; the name change is for advertising. The original TTL field concept was that if a packet is buffered at a router as if it is moving along a path for more than one second, the time to leave field would be decimated. The time that packet is actually being buffered will not be considered in such a case. When a packet is buffered or passed through a router, the TTL field is simply decimated by 1. Therefore, the TTL field in actuality simply stops hop across the network, and the name change simply reflects that. It is now a hop layer or a hop count. The protocol number has been changed to the next header. The next header field indicates to the router which extension header to expect next. If there are no more extension headers, the next header field indicates the upper layer header such as the TCP header, UDP header, ICMPv6 header, an encapsulated IP packet, or other items. The source and the destination IP addresses are the same in IPv6. There are extra fields introduced in IPv6 as mentioned earlier. The traffic class field of IPv6 is similar to the Type Of Service or TOS field of IPv4 only in semantics. However, the usage is different and there is no one-to-one significance between the two. The flow label field is a new field available with IPv6. As the name implies, it tracks the flows across the network. There is still a lot of work and research being done on how the flow label fields can best be used. It is now available for identifying specific flows and can have significant impact in the future on quality of service. Now that we have seen both IPv4 and IPv6 header formats.
CourseIFTIPV6 JuniperNetworks,Inc.25
Slide26
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.
CONFIDENTIAL
IFT-IPV6
where do the other IP fields go? Some of those fields obviously are used at different times. The fragmentation header or fragmentation field you noticed is used when the packet is fragmented and yet eliminated in the IPv6 header. The answer here is, we now use header extensions. 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.
CourseIFTIPV6
Slide27
IPv6 eExtension hHeaders
CONFIDENTIAL
IFT-IPV6
Some of the fields in IPv4 are rarely used. Hence, such fields are now eliminated in IPv6 from the basic header. If we need that information, we add an extension header. Hence, header extension allows information to be added to the header only when needed, thus avoiding fields in the fifth header that may or may not be used. Let's look at these examples. In the first example, there is a simple IPv6 header encapsulating some TCP data. Therefore, the next header field will simply say that the next header is TCP. In the second example, there is more routing, so it includes a routing header. Therefore, the first next header field points to the second header, which is an extension header and has the information necessary for doing some source routing. Then, that header sends the next header a TCP. In the last example, there is fragmentation along with source routing. Therefore, the next header for the first three fields says a routing header, the next header says fragmentation, and that last header says TCP. Therefore, the next header field is not just a protocol number as in IPv4, but also specifies the information that is in the following header. One significant difference between IPv4 and IPv6 is that IPv6 fragmentation is always done from the source. In other words, routers along the path to some destination no longer do fragmentation. It is up to the source to either send packets at the MTU size or to test the path to the destination, discover the minimum MTU, and send the packets accordingly.

CourseIFTIPV6
Slide28
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.
CONFIDENTIAL
IFT-IPV6
As we mentioned, there are drawbacks in IPv4 fields. The IPv4 option field requires some special treatment in routers and is also not always used. Therefore, there may be some negative impact on forwarding performance in some routers. The main benefit with IPv6 extension headers is that, we add information only when it is necessary.

CourseIFTIPV6
Slide29
Examples of Extension Headers
CONFIDENTIAL
IFT-IPV6
Here, we have examples of extension headers and the next header values. There are some fields for all the types of headers. The hop-by-hop options header works somewhat like the options header in IPv4, in that it processes each router along the path. A destination options header holds information that is specific to a particular destination. It may be the end destination or some specified router along the path. The routing header is used for source routing. Fragmentation or the fragment header is for fragmentation. Authentication is new to IPv6. There is an in-built header for performing authentication between two communicating devices. There is an encapsulating security payload or ESP header for security IPSec. Here is an example of OSPF for IPv6. This is equivalent to OSPF version 3 which has a next header value of 89. This value is like the protocol number of OSPF.

CourseIFTIPV6
Slide30
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 packets 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.
CONFIDENTIAL
IFT-IPV6
Extension headers are not processed or examined by any node along the packet's delivery path until the packet reaches the node identified in the Destination Address field of the IPv6 header. There, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or if that is not present, the upper-layer header. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order in which they appear in the packet; a receiver must not scan through a packet looking for a particular kind of extension header, and process that header prior to processing all preceding ones. An exception for this is the Hop-by-Hop Options header, which carries information that must be examined and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header so that a router doesn't have to look through the header to try to find that options header.

CourseIFTIPV6
Slide31
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
CONFIDENTIAL
IFT-IPV6
When more than one extension header is used in the same packet, there is RFC 2460 recommendation to the extension headers to appear in a particular order. Obviously, the IPv6 header comes first. The hop-by-hop options header must follow immediately behind that if it's being used. An important point to notice here is that the destination options header is shown in two different places in the sequence. It's shown here in position three and again at position eight. If the destination options header is associated with source routing so that it needs to be processed by some routers along the path, it appears in position 3 and is followed by the routing header for source routing. If the destination options header is only being processed by the end destination then it appears down here, right before the upper layer header. The other headers are fragmentation, authentication, and ESP.

CourseIFTIPV6
Slide32
Currently Available IPv6 Options Hop-by-hop Must be processed by every node on the packets 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.
CONFIDENTIAL
IFT-IPV6
There are currently three options available for IPv6. The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header. The presence of this option in an IPv6 datagram informs the router that the contents of the datagram are of interest to the router and to handle any control data accordingly. The absence of this option in an IPv6 datagram informs the router that the datagram does not contain information needed by the router and hence can be safely routed without further datagram parsing. A jumbogram is an IPv6 packet containing a payload longer than 65,535 octets. Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. The Jumbo Payload option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. The Destination Options header is used to carry optional information that needs to be examined only by a packet's destination node or nodes. The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header.

CourseIFTIPV6
Slide33
Routing Header Next header value: 43 Provides source-routing functionality
Format
CONFIDENTIAL
IFT-IPV6
The Routing header is used by an IPv6 source to list one or more immediate nodes to be "visited" on the way to a packet's destination. This function is very similar to IPv4's Loose Source and Record Route option. The Routing header is identified by a Next Header value of 43 in the immediately preceding header.

CourseIFTIPV6
Slide34
Fragment header Next header value: 44 Used to provide datagram fragmentation
Format
CONFIDENTIAL
IFT-IPV6
The Fragment header is used by an IPv6 source when a packet is too large to fit in the path MTU to its destination. An important point to know here is that unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path. The Fragment header is identified by a Next Header value of 44 in the immediately preceding header.

CourseIFTIPV6
Slide35
Authentication Next header value: 51 Provides data integrity and authentication
Format
CONFIDENTIAL
IFT-IPV6
The IP Authentication Header or AH is used to provide connectionless integrity and data origin authentication for IP datagrams, and to provide protection against relays. The Authentication header is identified by a Next Header value of 51 in the immediately preceding header. AH provides authentication for as much of the IP header as possible, as well as for upperlevel protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable to the sender. The values of such fields cannot be protected by AH.

CourseIFTIPV6
Slide36
Encapsulating Security Payload (ESP) Next header value: 50 Provides confidentiality, data origin authentication, connectionless integrity, and antireplay service
Format
CONFIDENTIAL
IFT-IPV6
The Encapsulating Security Payload or the ESP header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header, or in a nested fashion, For example, through the use of tunnel mode. The ESP header is inserted after the IP header and before either the upper layer protocol header or an encapsulated IP header.

CourseIFTIPV6
Slide37
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
CONFIDENTIAL
IFT-IPV6
Let's now move on to ICMPv6. The Internet Control Message Protocol version 6 or the ICMPv6 is not the same as ICMPv4. ICMP for IPv4 has a protocol number of 1. ICMPv6 has a next header number of 58. ICMPv6 has many of the same functions as ICMPv4. But, there are also some new functions defined in ICMPv6. Specifically, there are new messages for neighbor discovery with stateless autoconfiguration and there is some functions defined specifically for mobile IPv6.

CourseIFTIPV6
Slide38
ICMPv6 Message Types RFC 2463 Common Functions Destination unreachable error messages Packet too big Time exceeded Parameter problem Echo request and reply
CONFIDENTIAL
IFT-IPV6
If you are well acquainted with the functions of ICMP for IPv4, according to RFC 2463, there are some similar functions in ICMP for IPv6. Some of the similar functions include Destination unreachable error messages, packet too big, time exceeded, parameter problem, and then echo request and reply.
CourseIFTIPV6
Slide39
ICMPv6 Message Types RFC 2461 Used for neighbor discovery protocol
CONFIDENTIAL
IFT-IPV6
But, RFC 2461 also defines some new functions. They are specifically for ICMP and all of these are used for neighbor discovery, router solicitation, and router advertisements. Neighbor solicitation, neighbor advertisements, and redirect are redefined under the concept of the neighbor discovery protocol. Let's now discuss router soliciting. On a network, if you want to find a router, you can send a router solicitation. If a router wants to make itself known, it will send the router advertisement and the same for a neighbor. You can solicit for a neighbor, or a neighbor can advertise its presence with a neighbor advertisement, or in both cases a router or a neighbor can answer solicitation with an advertisement.

CourseIFTIPV6
Slide40
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
CONFIDENTIAL
IFT-IPV6
Let's now move onto the neighbor discovery of IPv6, which is defined in RFC 2461. A neighbor can be a router or a host. The neighbor discovery performs several functions such as link-layer address resolution, router discovery, local prefix discovery, address autoconfiguration, next-hop determination, duplicate address detection, and redirect. We will discuss each of these functions.

CourseIFTIPV6
Slide41
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
CONFIDENTIAL
IFT-IPV6
There are some functions in IPv6 similar to those in IPv4. Though the ARP function of IPv4 is no longer included in IPv6, there is a similar function defined in the neighbor discovery. ICMP router discovery and ICMP redirect are similar to the IPv4 functions. IPv4 has no agreed mechanisms for neighbor unreachability detection, but this function is defined in IPv6. Therefore, with IPv6, you can detect failing routers and links. You can detect nodes that change their link layer address and unlike ARP you can detect half-link failures with IPv6.

CourseIFTIPV6
Slide42
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.
CONFIDENTIAL
IFT-IPV6
There are some major improvements in IPv6 over IPv4. The router discovery is a part of the base protocol in IPv6. Now, the host need not snoop for routing protocols. The router advertisements and redirects carry link-layer addresses. Therefore, no additional packet exchange is needed for that. Significantly, router advertisements carry the link prefix. This is very useful for address autoconfiguration. We had mentioned the MAC-to-EUI-64 conversion earlier, in which a device can determine its own interface ID. If that device is connected to a network, then there is the router advertisement in which the router is advertised in the prefix for that network. Hence, the device connecting now has everything it needs to form a global IP address that it has to prefix, and it also has its own interface ID. It can connect all this together to form its own address. Router advertisements can advertise the link MTUs, which is a significant improvement of router advertisements. The ICMPv6 in general is immune to off-link neighbor discovery messages. Let's see how it does this. Any message that is sent always sets the hop limit to 255. When you receive an ICMPv6 message on a link, you set a hop limit. If it is anything less than 255, it means that it has been decimated by a router and has been sent on to the link from off-link. Therefore, it is considered an ill agreement message and is dropped. This gives better security on a link for ICMP messages.

CourseIFTIPV6
Slide43
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.
CONFIDENTIAL
IFT-IPV6
For router discovery, router advertisements are sent periodically. The range is as displayed and is configurable. By default, it has a minimum interval of 200 seconds and a maximum of 600 seconds. The router advertisements are sent to an all-nodes multicast address. If a device connects to a link, it obviously doesn't want to wait for up to 600 seconds to hear a router advertisement to discover the router. Therefore, a device can send a router solicitation to the all router multicast addresses. Those routers on the link hearing a router solicitation will immediately reply with the router advertisement. This way, a device can solicit a router to get immediate information rather than waiting for a periodic router advertisement.

CourseIFTIPV6
Slide44
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
CONFIDENTIAL
IFT-IPV6
The information in the router advertisement is the current hop limits between users or two flags called the M bit and the O bit. These are used for address autoconfiguration. Other information includes the router lifetime, the reachable time, and retranslate timer for the router, source link-layer address, MTUs, and also prefix information which is very important for address autoconfiguration.

CourseIFTIPV6
Slide45
Unsolicited and Solicited Router Advertisement
CONFIDENTIAL
IFT-IPV6
Displayed are the networks to show the router advertisements. Here the router advertisements are sent unsolicited on a periodic basis. Here you can observe that devices are packed and it solicits on a single node by sending router solicitation.

CourseIFTIPV6
Slide46
Unsolicited and Solicited Router Advertisement
CONFIDENTIAL
IFT-IPV6
In this case router A, B, and C hear the solicitation and will respond to each one with a router advertisement. This node here sets up the default gateway list that tracks all routers that it has heard from.
CourseIFTIPV6
Slide47
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?
CONFIDENTIAL
IFT-IPV6
An important point in this particular case is that the device has listed three routers--router A, router B, and router C as known routers. Then, how does that device decide which router to use as a default gateway? The answer is, it randomly selects one of those routers as a default router if it is application specific. It could cycle through the default list in a round-robin fashion. It just depends on how the application is written for that specific device. The main concern here is what happens when the default router is the wrong router. The only solution for this is the redirect and that is the reason for rewriting the redirect into the neighbor discovery protocol.

CourseIFTIPV6
Slide48
Choosing a Default Gateway and Redirect
CONFIDENTIAL
IFT-IPV6
In the example displayed, this device has selected router A as default gateway. It needs to send a packet to host 3 down here or to some other network. It sends that packet to router A to forward the packet to the destination. Router A being a router knows that it is better to route it to the destination with router B. Therefore, router A will redirect to this host saying that subsequent packets that have to go to host 3 off of the link should be through router B. In the network, you can see subsequent packets are being sent to router B. This is redirection.

CourseIFTIPV6
Slide49
Neighbor Cache
CONFIDENTIAL
IFT-IPV6
A neighbor cache is built in each host. The neighbor cache stores information for all neighbors that have been heard on a specific link. Shown here is a neighbor cache copied from a system connected to the IPv6 network.

CourseIFTIPV6
Slide50
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
CONFIDENTIAL
IFT-IPV6
The neighbor address resolution is an equivalent function to IPv4 ARP which was mentioned earlier. But IPv6 uses multicast instead of broadcast. So, if a device has to reach a particular neighbor, it first checks the neighbor cache for that address. If it cannot find the address, it either creates an incomplete entry and then sends the solicited node multicast address, or sends a neighbor solicitation "sorry" to a solicited node multicast address. The target node then sends the neighbor advertisement in response with this link-layer address. At that point, a soliciting node changes the incomplete entry to a reachable entry.

CourseIFTIPV6
Slide51
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
CONFIDENTIAL
IFT-IPV6
The solicited node multicast address is another address format, and it has specifically reserved prefix 104 as shown. In those 104 bits, the last 24 bits of the target IPv6 node is appended. Let's look at some of the examples. If a target node has an interface, and the last 24 bits of the prefix is 45ee, then the solicited node multicast address becomes a mid prefix and the last 24 bits as shown onscreen. An important point here is that, if you know the last 24 bits of one address for a neighbor, and a node sends solicitation to that neighbor with the solicited node multicast address, then that neighbor will respond not only with the piece of the address but also with all of the IPv6 addresses on that interface. Hence, with that one solicited node multicast address the node can solicit all of the IPv6 addresses on an interface within some parameters.

CourseIFTIPV6
Slide52
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
CONFIDENTIAL
IFT-IPV6
To discover the next hop, one has to check the neighbor cache for an existing next-hop entry. If the link is on, it is sent directly to the neighbor. If it is off link, then it is sent through a default router.

CourseIFTIPV6
Slide53
Neighbor Unreachability Detection Neighbor cache stores information about neighbors IP address Link-layer address Reachability state Neighbor reachability states: INCOMPLETE REACHABLE STALE DELAY PROBE
CONFIDENTIAL
IFT-IPV6
For neighbor unreachability detection, the neighbor cache stores information such as the IP address, the link-layer address, and the reachability states. The neighbor reachability states include incomplete, reachable, stale, delayed, and probe. The reachability state is INCOMPLETE when the address resolution is being performed on the entry. This happens when an NS is sent to the solicited-node multicast address of the target, but the corresponding NA has not yet been received. The state is REACHABLE when the forward-direction communication has been verified within the past 30 seconds. The state is STALE when an entry in the neighbor cache has not been verified as reachable within the past 30 seconds. An unsolicited NA message will add an entry to the cache for the sender of the message, with the state STALE. No action is required until traffic is sent to the STALE entry. The state is DELAY when no reachable verification has been received within the past 30 seconds, and a packet has been sent to the specified neighbor within the past five seconds. If no positive confirmation is received within five seconds of entering DELAY state, an NS is sent and the state is changed to PROBE. The state is PROBE when an NS has been sent to verify reachability and no NA has yet been received. It tracks whether that neighbor is reachable or not and then it checks through protocol changes whether that neighbor continues to be reachable.

CourseIFTIPV6
Slide54
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
CONFIDENTIAL
IFT-IPV6
Now, let's move on to the address autoconfiguration. There are two types of address autoconfiguration defined for IPv6. One is stateless autoconfiguration and the other is stateful autoconfiguration. Stateless autoconfiguration is the one which we discussed till now. All that it requires is a router sending router advertisement. If the device itself can determine its interface ID from the router advertisement it can determine the global address to be used on a link. The device can then completely determine its own IPv6 address. Stateful autoconfiguration is useful when more control is desired over address autoconfiguration and that is simply DHCPv6. Stateless and stateful autoconfiguration can also be combined. We had already discussed that in a router advertisement there are two flags called the M flag and the O flag. The M flag indicates whether a stateless autoconfiguration from a router should be used for the address itself. The O flag is advertised by the router to tell devices whether stateless autoconfiguration for other parameters should be present. Hence, by combining the two, you could use stateless autoconfiguration to the address itself which can then go to a DHCP server for the other parameters for that address.

CourseIFTIPV6
Slide55
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
CONFIDENTIAL
IFT-IPV6
Let's discuss stateless autoconfiguration. The interface ID is automatically derived using the MAC-to-EUI-64 conversion. The procedure for stateless autoconfiguration is as follows. The host first creates a link-local address after it has derived its interface ID. It performs a duplicate address check which is very important when an automatic process occurs for determining the address. It is also important to make sure that no other device on the network has used the same address. It then sends the router solicitation to the all router multicast address through router response with a router advertisement with prefix information. The host now has both the prefix and the interface ID to create a global unicast address.

CourseIFTIPV6
Slide56
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
CONFIDENTIAL
IFT-IPV6
Here is a MAC-to-EUI- 64 conversion for automatically determining an interface ID from a 48bit MAC address. Here the 48 bit MAC address is broken into half in the middle. The first three octets form the company ID and the last three octets the node ID. It is important to know that the last three octets are 24 bits long which adds significance to the solicited node multicast address. The 0xfffe is inserted in between company ID and the node ID. This adds another 16 bits which is always 0xfffe. Hence, now what was a 48-bit address becomes a 64-bit address. The last thing we do for a global address is clip the universal local bit in the MAC address to 1.

CourseIFTIPV6
Slide57
MAC-to-EUI-64 Conversion Example
CONFIDENTIAL
IFT-IPV6
Let's look at an example for a MAC-to-EUI conversion. You can observe the MAC address of some device displayed in binary. The first three octets are the company ID, and the last three octets are the individual node ID. In between the company ID and the node ID, fffe has been inserted. We then slip in the universal local bit or the U/L bit shown here as 1 to make this a universal address. The resulting EUI-64 address is what is displayed here, which arrives from this MAC address.

CourseIFTIPV6
Slide58
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
CONFIDENTIAL
IFT-IPV6
We can add the EUI address on to our interface ID to get a full globally unique unicast address. A quick recap of the solicited node multicast. This is to show the significance of using 24 bits for the solicited node multicast because that last 24 bits will be the same when you do the MAC-to-EUI-64 conversion. Therefore by adding the last 24 bits, you can solicit for multiple addresses on a single interface.

CourseIFTIPV6
Slide59
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
CONFIDENTIAL
IFT-IPV6
With all these advantages, the address autoconfiguration has a problem, which is generally a security problem. In particular, if you are using this predictable algorithm for determining your interface ID and the ID is a part of a global address, you can be tracked. It is because the address becomes mobile across the Internet. For example, your employer can determine where you are at all times. The advertising might be able to determine your Internet usage traffic etc. To worsen the situation, more malicious things could happen to you. This was a concern for some people but not for others. However, the concern was raised and now there are two solutions. One, if the concern is that the MAC-to-EUI-64 conversion introduces privacy problems, you could always use stateful address autoconfiguration or DHCPv6. Two, you can use a new type of address called the privacy address.

CourseIFTIPV6
Slide60
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
CONFIDENTIAL
IFT-IPV6
Privacy addresses are defined in RFC 3041. The privacy address randomly generates the interface ID. Here, you can use both the autoconfigured public addresses and private addresses together. The idea behind this is, anyone wishing to reach you can use your autoconfigured public address. But, when you respond you use the private address. Due to the random nature of the private address and the fact that it will change, it becomes much more difficult to track someone through the Internet.

CourseIFTIPV6
Slide61
Stateful Autoconfiguration: DHCPv6 Currently in Internet-draft Many changes from DHCRv4 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
CONFIDENTIAL
IFT-IPV6
The DHCPv6 with stateful autoconfiguration is still in Internet draft form. Several significant changes have been included in DHCPv6. For example, with DHCPv6, you can configure dynamic updates to DNS; use address deprecation; and you can use authentication. DHCPv6 also includes many other features such as offering clients multiple IP addresses; reclaiming the addresses; and integrating stateful and stateless autoconfiguration. DHCPv6 also uses multicasting.

CourseIFTIPV6
Slide62
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
CONFIDENTIAL
IFT-IPV6
Now, let's discuss duplicate address detection. For duplicate address detection, the rule says that, because of the automatic nature of address configuration in IPv6 the duplicate address detection should always be performed BEFORE assigning an address to an interface and on interface initialization. It is performed with both stateful and stateless autoconfiguration. This is a safety step to ensure that all devices have unique addresses on the way. The address to be assigned to the interface is called the tentative address while the duplicate address detection process is taking place. These are some of the steps performed in duplicate address detection.
CourseIFTIPV6
Slide63
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.
CONFIDENTIAL
IFT-IPV6
The interface joins the all-nodes multicast group to ensure that the node receives Neighbor Advertisements from any node already using the address. It then sends a neighbor solicitation with the target address set. It then joins the solicited-node multicast group for the tentative address to ensure if another device that has the tentative IP address already assigned, and if it is attempting use the address. It then responds to the neighbor solicitation. The node sends a Neighbor Solicitation message, with the tentative IP address as the target. The source address is the unspecified double colon address, and the destination is the tentative address' solicited-node multicast address. By default, one solicitation is sent. Any neighbor that is already assigned the address receives the solicitation and sends a Neighbor Advertisement, in reply. The target specified in the advertisement is the tentative address. The destination address is the solicited-node address of the tentative address. If a node receives this Neighbor Advertisement, and the target address is the interface's tentative address, the address is a duplicate and must not be assigned to the interface.

CourseIFTIPV6
Slide64
Configuration Example: Router Discovery
CONFIDENTIAL
IFT-IPV6
Displayed here is the configuration sample from a Juniper router for setting the router for router advertisement. Here is an interface with two addresses assigned. The protocol router advertisement is saved on interface fe-2/1/0.0 Two prefixes are advertised. On some router products this is done automatically. Juniper does it based on the customer and manually sets the router advertisement. The router advertising can tell the router what it wants to advertise and the interface on which it is to be advertised. Another product that works more in an enterprise environment is 23 setup IPv6 on an interface. The router will automatically start sending neighbor advertising. Also displayed here is a statement for other stateful configuration. This shows how an object is set in the router advertisement. It says not to do a DHCP server for other configuration parameters.

CourseIFTIPV6
Slide65
Configuration Example: Windows XP Host
CONFIDENTIAL
IFT-IPV6
Here is an example using Windows XP. The interface used is the IPv6 interface 4 which is an Ethernet interface. You can observe that it is using neighbor discovery, and router discovery. Here is the link-layer address. Notice that it has two discovered IPv6 addresses and has both the public address to reach one and an anonymous address or a private IPv6 address. These four addresses are discovered together when the device attaches to the router on backing up. The two prefixes being advertised are attached to this router interface.

CourseIFTIPV6
Slide66
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
CONFIDENTIAL
IFT-IPV6
Now let's move on to the routing concepts of IPv6. As mentioned earlier, there is no fragmentation with IPv6 at the router. Hence, all devices sending IPv6 packets must either send a packet to the minimum MTU size or use MPU half discovered which is simply using IPMP messages to determine the maximum packet size that can be sent across a particular path. The recommended MTU is 1500 bytes. The minimum MTU for IPv6 is 1280 bytes. MTU path discovery works for both unicast and multicast. MTU path discovery uses ICMP "packet too big" error messages.

CourseIFTIPV6
Slide67
Configuration Example: Static Route
CONFIDENTIAL
IFT-IPV6
Let's look at some configuration examples from the Juniper routers. This is a static route for IPv6. Though it is using IPv6 addresses, the route works exactly like it works for a static route for IPv4. To be more elaborate, we perform the following steps. First, we define the static route, and the route is the prefix. To reach the prefix we have the next hop of a particular address. If this is an IPv4, it would follow the same steps. You would have some reachable prefix and a next-hop address. The only difference here is that you are using IPv6 prefixes and IPv6 interface addresses.

CourseIFTIPV6
Slide68
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
CONFIDENTIAL
IFT-IPV6
For RIP, IPv6 uses RIP next generation or RIPng. This is described in RFC 2080 and RIPng is actually RIPngv1. An important thing here is not to confuse between RIPngv1 of IPv6 and the RIPv1 of IPv4. RIPngv1 is based on RIPv2. It uses UDP port 521; the timers and protocols are very much similar to RIPv2. The only difference is that the message format has been changed to carry the larger IPv6 addresses.

CourseIFTIPV6
Slide69
RIPng
CONFIDENTIAL
IFT-IPV6
Displayed here is a configuration example for RIPng. This is from the Juniper Networks service provider environment. We view RIP differently from others. Though RIP is an IDP, we view it as an external protocol. You would never use RIP internally in a large service provider network. So for Juniper routers, we always see RIP as an edge protocol, and the routes are to be defined the way it is done for BGP. It is exactly the same for the Juniper RIP configuration. The only difference is protocol RIP is now replaced with RIPng in IPv6.

CourseIFTIPV6
Slide70
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
CONFIDENTIAL
IFT-IPV6
The IS-IS is an easily extendable protocol. For IPv6, there are two new TLVs defined for IS-IS. They are the IPv6 reachability TLV and the IPv6 interface address TLV. There is also a network layer PDUID of 142 that is defined. On Juniper routers, if you are running a JUNOS version that supports IPv6, which is any recent JUNOS version, and you enable IS-IS, you will automatically route for IPv6.

CourseIFTIPV6
Slide71
IS-IS and Configuration Example: IS-IS for IPv6 Only By default, IS-IS routes both IPv4 and IPv6
CONFIDENTIAL
IFT-IPV6
In the example, there is a command that says no IPv4 routing. This is just to make it interesting because otherwise the configuration looks just like the configuration for IPV4. There is no difference.

CourseIFTIPV6
Slide72
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
CONFIDENTIAL
IFT-IPV6
Unlike IS-IS, which we just discussed and which is very easily extendible, OSPF requires an entirely new version for IPv6. The OSPF version for IPv6 is OSPFv3 and OSPFv2 for IPv4. An important point to note here is that OSPFv3 will route only IPv6. If you want to route both IPv4 and IPv6 through a router using OSPF, you need to configure both OSPFv2 and OSPFv3. OSPFv3 is defined in RFC 2740. Fundamental mechanisms for both OSPFv3 and OSPFv2 are the same, but the packet and LSA formats are different. Let's look at the differences between OSPFv2 and OSPFv3 in detail now. OSPFv3 runs per-link rather than per-subnet. The implication is that you can have multiple instances and multiple adjacencies. You can therefore have different adjacencies on the same link. There is more flexibility in handling unknown LSA types with OSPFv3. With OSPFv2, it does not react well to LSA types when it doesn't know. It is unlike IS-IS which simply ignores the LVs it doesn't know. With OSPFv2, LSA will normally break on adjacency through the router that sends the unknown LSA. That shrinks in v3 so that a label will now simply ignore that unknown LSA. The significance in that is, transitioning OSPF and making network changes with OSPFv3 becomes easier because of the broken adjacencies during the transition. There is a link-local flooding scope added. Authentication has been removed from OSPFv3. The reason is because there is an authentication header for IPv6 itself. So, OSPF can now simply use that authentication built into IPv6 rather than having its own authentication processes. Neighboring routers are always identified by a router ID. With OSPFv2, in some cases it uses an interface ID and then there is some addressing semantics removed.
CourseIFTIPV6 JuniperNetworks,Inc.72
Most OSPF packets do not have IPv6 addresses inside them. Router IDs, area IDs, and LSA IDs remain 32 bits which makes everything more compatible with OSPFv2.

CourseIFTIPV6
Slide73
OSPFv3 LSAs
CONFIDENTIAL
IFT-IPV6
Here, you can see some of the OSPFv3 LSAs. The router and network LSAs remain the same to some extent, but there is a difference in function. Type 3 and type 4 LSAs of OSPFv3 have the same function as type 3 and type 4 LSAs in OSPFv2; only the names are changed. They are now called the inter-area-prefix LSAs and the inter-area-router LSAs. Type 5 is the same in both. Type 6 for multicast is the same, and type 7 for study areas also performs the same function. There are two LSAs defined, that are significant. Type 8 is a line LSA. This is a link local LSA. In OSPFv2, a router LSA and a network LSA carry some information that is only significant between directly connected neighbors and yet those LSAs are flooded throughout an area. It means that this information is carried throughout the area unnecessarily. With OSPFv3 any information that is only significant between two adjacent neighbors is removed from the router and network LSAs and added to the link LSA. Hence, it is exchanged through this link LSA and adds efficiency. The other difference is type 9 which is the intra-area-prefix LSA. With OSPFv2, prefixes are advertised by the router and network LSA. This means that if a stub network fails, a router LSA needs to be re-flooded and the SPF algorithm has to be recomputed. By removing the prefixes and adding them in a separate LSA, we reduce flooding pressure and simplify the SPF processes for OSPF. Therefore, this again adds some efficiency.
CourseIFTIPV6
Slide74
Configuration Example: OSPFv3
CONFIDENTIAL
IFT-IPV6
This is an example of configuring OSPFv3. If you are familiar with JUNOS, you know that this OSPF configuration looks exactly like OSPFv2, except for the addition of OSPF3 as a keyword to show that it is OSPFv3.

CourseIFTIPV6
Slide75
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 NLRIs Follows BGP-4 rules for next-hop attribute IPv6 BGP routers advertise global address of NH-router
CONFIDENTIAL
IFT-IPV6
Now, let's move on to multiprotocol BGP. BGP is extended to routers for functionalities other than IPv4. For all of these extensions, it uses multiprotocol BGP, which are simple extensions of the multiprotocol reachable NLRI and the multiprotocol unreachable NLRI. This is not only used for IPv6, but also for VPNs. You can use BGP to route IPXL appletalk using multiprotocol BGP. It can be used for IP multicasting, but in this state multiprotocol BGP is used to route for IPv6.

CourseIFTIPV6
Slide76
Multiprocotol BGP-4 and Example Configuration: BGP
CONFIDENTIAL
IFT-IPV6
Here is an example of the configuration of BGP. This is a typical BGP configuration. The real difference in this group is that, you configure both an internal and an external IPv6 group which are represented here by underscore external (_external) and underscore internal (_internal). If you know JUNOS, this looks familiar to you. The only real significant difference is to route for IPv6. We have already discussed the family inet6. Also, displayed are some neighbors defined that are IPv6 addresses.

CourseIFTIPV6
Slide77
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
CONFIDENTIAL
IFT-IPV6
Let's consider the multihoming problem which is a commonly known problem for Internet service providers. This problem contributes greatly to the increase in Internet routing table sizes. In this example, we have a customer with a prefix of 207.17.137/24. This prefix was inherited from this service provider. The addresses are just made up in this example. 207.17/16 is a customer who is also a multihome to the brother service provider. The problem here is that when this customer wants to advertise that prefix through both of these service providers to the rest of the world, this service provider has to advertise this more specific prefix out in the world. The problem is that this prefix being more specific than what the service provider would be advertising with it, aggregates all traffic which normally comes in through service provider 2. To overcome that problem, service provider 1 must also advertise this more specific prefix along with its aggregates. This kind of practice contributes to the huge growth in the size of the Internet routing table. From the point of view of the customer, it is obviously a good practice to be home to more than one service provider, but bad for the Internet in general.

CourseIFTIPV6
Slide78
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)
CONFIDENTIAL
IFT-IPV6
The most viable solution to the multihoming problem is IPv6. With IPv6, there are some opportunities to correct these multihoming problems, and it also influences the Internet routing table growth. Whether all the problems are resolved is another issue. Still, with the adoption of IPv6, there is the opportunity to take the lessons learned from IPv4 and apply them to reduce the routing table growth. Some of the possible approaches are mentioned below. You can have multiple unicast addresses per interface. However, the concern here is how DNS works in this environment, and how the source address is chosen. You could do exchange-based addressing where one TLA is assigned to many service providers. It could be assigning customers from the same prefix group, but then there are problems with that. There is also the router renumbering protocol, using globally unique node IDs. These features have been discussed but nothing has really been determined yet. Therefore, there are still lots of complexities behind trying to solve the multihoming problem. As said earlier, whether the problems get solved is yet to be seen, but a lot of the work that has been done is discussed in the IETF multi6 working group and other places.

CourseIFTIPV6
Slide79
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
CONFIDENTIAL
IFT-IPV6
Now, let's discuss transitioning to IPv6. Let's look at some of the assumptions for transitioning to IPv6. At the very first, there should be no flag day. The last large Internet transition occurred on January 1, 1983, when the Internet transitioned from NCP to TCP. The result was quite disastrous. It took about six months to actually make that transition. When it was expected to, the expectations were able to be met overnight. As a result, that lesson was learned well and it is expected that at no point should we have to do mapped transition from IPv4 to IPv6. In fact, IPv6 has been designed so that the two protocols can co-exist. The other requirement for the transition to be incremental is that there should be no IPv4 and IPv6 barriers at anytime. In other words, during all of the transition, every device should be able to communicate with every other device. There should be no transition dependency. To be clearer, node X should not have transition before node Y. This is to ease the end user as nothing gets broken. As mentioned earlier, IPv6 is designed with transition in mind and in fact there is an assumption that IPv4 will continue to be used for the entire time that IPv6 is in existence. Finally, many different transition technologies have been developed or at least proposed for IPv6. This is a good thing, as there are so many different networks. This generates many different scenarios for transitioning. The more the number of tools available, the better and more successful the transition will be.

CourseIFTIPV6
Slide80
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
CONFIDENTIAL
IFT-IPV6
There are three types of transition mechanisms or three classes that all transition mechanisms can fall into. The first is the dual stacks type, which simply means that IPv4 and IPv6 are operating at the same time on the same device. The second is the tunnels type, which allows IPv6 to communicate across the IPv4 cloud. At a later stage, tunneling will allow IPv4 devices to communicate across the IPv6 cloud. Tunnels are always used for either IPv6- to-IPv6 communication or IPv4-to-IPv4 communication. For an IPv6 device and an IPv4 device to communicate with each other, we need translators, the third class of transition mechanism.

CourseIFTIPV6
Slide81
Dual Stacks
Usually just dual layer, not entire stack.
CONFIDENTIAL
IFT-IPV6
This is the Dual stacks type of transition mechanism. The only thing we need to mention here is that the dual stack is dual layered. The applications tend to reside on top of the split IPv6 and IPv4 stacks.

CourseIFTIPV6
Slide82
Tunnel Applications and Types
CONFIDENTIAL
IFT-IPV6
These are the applications of the Tunnel mechanism. The tunnels could be router to router or host to host or also be host to router and router to host, as shown.

CourseIFTIPV6
Slide83
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
CONFIDENTIAL
IFT-IPV6
Let's look at some of the tunnel types here. One is the configured tunnels. There are various proposals for automatic tunnels and some RFCs as shown. They include the tunnel brokers, 6to4 tunnels, and ISATAP interfaces. 6over4 is a proposal that probably may not be implemented as 6over4 requires an IPv4 multicast network to operate and many are not available at this point of time. There is a thing called Teredo being proposed by Microsoft which is used for tunneling through a NAT device. Dual stack transition mechanisms or DSTM is one proposal. IPv64 has also been proposed.
CourseIFTIPV6
Slide84
Configuration Example: Configured GRE Tunnel, MPLS Tunnel
CONFIDENTIAL
IFT-IPV6
Let's now have a quick look at a few configuration examples which are again from JUNOS. This is a simple GRE tunnel. If you are familiar with configuring tunnels, you know that there is a source and a destination and you assign an address to the tunnel interface. A real simple difference here is that there is an inet6 and an IPv6 address assigned to the tunnel.

CourseIFTIPV6
Slide85
Configuration Example: Configured GRE Tunnel, MPLS Tunnel
CONFIDENTIAL
IFT-IPV6
This is the MPLS tunnel similar to the GRE one. Here, you can tunnel IPv6 over an MPLS LSP, and this could be a very significant transition mechanism.
CourseIFTIPV6
Slide86
6to4
Site must have at least one globally-unique IPv4 address. Uses IPv4 embedded address
Router advertises 6to4 prefix to hosts
CONFIDENTIAL
IFT-IPV6
6to4 is a router to router tunneling protocol. The site must have at least one globally unique IPv4 address. It uses an IPv4 embedded address which was mentioned earlier. Here, the device will go to a 6to4 router. A host device will actually have a 6to4 address, but it uses a 6to4 router and tunnels across an IPv4 cloud. For 6to4, there is a reserve prefix of 2002/16. If you have an IPv4 address for example of 138.14.85.210, it is equal to an 8a0e colon ( : ) 55d2. The reserved 6to4 TLA-ID is 2002 double colon ( :: ) 16. These addresses are represented onscreen as shown. To take a globally unique IP address we add this reserve 6to4 prefix onto the IPV4 address to get this entire prefix. Here, we have shown that as the resulting 6to4 prefix in this example.
CourseIFTIPV6
Slide87
6to4
CONFIDENTIAL
IFT-IPV6
This is a 6to4 router. The network consists of some device on an IPv6 site. The device needs to reach across an IPv4 cloud, either to another v6 site that might be in some larger corporation; or the 6to4 relay router must be used which gets you out to the large IPv6 Internet. The 6to4 router shown here has this IPv4 address assigned. It comes to that prefix; it advertises that prefix to this device which might then have something like what is shown as an end address.

CourseIFTIPV6
Slide88
Configuration Example: Windows XP 6to4 Interface
CONFIDENTIAL
IFT-IPV6
Displayed here is an example using Windows XP. When you enable IPv6, it automatically comes up with the 6to4 pseudo-interface, which is shown here. The interface 3 is 6to4 tunneling pseudo-interface. Here, you can see the 2002 6to4 prefix and here is a representation of 65.114.168.91 and then the rest of this address packed onto the end of it.

CourseIFTIPV6
Slide89
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
CONFIDENTIAL
IFT-IPV6
ISATAP is something else that spins heavily from Microsoft. With IPv6 you will come up with an ISATAP interface. It uses the IPv4 compatible addresses that we discussed earlier. Basically, the last 32 bits are represented in dotted decimal. You then add on a reserved portion here of 5efe to make the entire 64 bits. So for example, if you have an IPv4 address of 65.114.168.91 and also a global prefix of 2001:468:1100:1/64,using the ISATAP interface you can have a link local address of fe80 which is a well known prefix. Along with this, here is that reserve piece in the dotted decimals of 32 bits and a global IPv6 address based on this prefix. This is ISATAP addressing.
CourseIFTIPV6
Slide90
ISATAP
CONFIDENTIAL
IFT-IPV6
There is an IPv6 device operating on a v4 network. We can use ISATAP to tunnel over to a 6to4 router which then sets up a tunnel across some other v4 cloud. We can use it as a tunnel up to a dual stack v4 v6 router to get to an IPv6 cloud or we can tunnel directly to another host over v4 using ISATAP.

CourseIFTIPV6
Slide91
ISATAP
CONFIDENTIAL
IFT-IPV6
An important point to be mentioned here is that the 6to4 becomes an important transition technology as it matures.
CourseIFTIPV6
Slide92
Configuration Example: Windows XP ISATAP Interface
CONFIDENTIAL
IFT-IPV6
Here is an example of ISATAP. You just turn on IPv6 and you get the ISATAP interface automatically which in Microsoft is called the automatic tunneling pseudo-interface with its ISATAP. Here is the link-local prefix. You can also notice the ISATAP identifier which is 5efe. There is also an IPv4 address that is stacked onto the end of it.

CourseIFTIPV6
Slide93
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)
CONFIDENTIAL
IFT-IPV6
Now, let's move on to translators. There are different classes of translators. They are the network level translators, transport level, and application level translators. All of them have different applications. Let's discuss in detail the network address translation port translation or NAT-PT. This is an essential functionality during translation. Though NAT is used, you will still have some problems. However, it is a useful tool for transitioning with IPv6.

CourseIFTIPV6
Slide94
Transition Issues: DNS
Namesapace 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)
CONFIDENTIAL
IFT-IPV6
Let's now discuss DNS which is an obvious concern when talking about transition. The major issue is namespace fragmentation. What would happen if some names reside on IPv4 DNS and others on IPv6 DNS? How does an IPv4 host resolve to an IPv6 name for example or vice versa? There are concerns about MX records. Some solutions that are shown here include the dual stacked resolvers. Every zone has to be served by at least one IPv4 DNS server. You should also use translators although NAT-PT doesn't work for doing DNS translation.

CourseIFTIPV6
Slide95
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
CONFIDENTIAL
IFT-IPV6
The ogre method for DNS records is called AAAA records. This implies the fact that an IPv6 address is four times as big as an IPv4 address which is represented with an A record. Here is an example of an AAAA record. The only thing to really know is that a PTR record can get very ugly. The A record is basically returned in reverse in a PTR record. You know that it is 2001 and the rest of it is 4210 and so forth all the way out. There is no way to make that shorter or easier to work with and so PTR records can be a bit unwieldy. The problem is that renumbering a network is not as easy with AAAA records. As a result there are some proposals for six letters which are actually broken up in the trunk for address resolutions.

CourseIFTIPV6
Slide96
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
CONFIDENTIAL
IFT-IPV6
DNS A6 records are supported in BIND 9. The list displayed explains the A6 records. You can notice that everything works on the chain here.
CourseIFTIPV6
Slide97
DNS A6 Records and DNAME and A6 Record Chain
CONFIDENTIAL
IFT-IPV6
Shown here is an address that needs to be resolved. Let's say we have to resolve something called simpson.net. Here, you can see a particular device called Homer in A6 record. You get 1 piece of this address resolved, but then there is a reference to another record which gives you the next piece of that address, and another reference to another record. Thus you get a chain of records. The significance is that in a network renumbering project, for example, if you just need to change some prefixes, you only have to change one record in the full chain. Hence, changing all the records throughout your DNS and renumbering becomes much easier with this chain.

CourseIFTIPV6
Slide98
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
CONFIDENTIAL
IFT-IPV6
Let's discuss some transition issues for security. The issue for security pops up when it comes to open Internet and peer-to-peer. During transition, there are a lot of security risks that are still being debated such as DoS attacks. Here are some examples of abusing different kinds of addresses. There are some questions about the host's reaction if you have an intentionally corrupted IP address and you pass that into a network. The question here is will the host see that and somehow freeze up, as it will not know what to do with this corrupted address.

CourseIFTIPV6
Slide99
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.
CONFIDENTIAL
IFT-IPV6
There are some transition security guidelines. The guideline allows only explicitly configured tunnels either through manual configuration or automatic tunnels with proper authentication. Do not embed IPv4 addresses in IPv6 as it takes away for 6to4. Do not define address formats that do not appear on the wire. Filter carefully to block any kind of spoofed packets.

CourseIFTIPV6
Slide100
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
CONFIDENTIAL
IFT-IPV6
For transition planning, the assumption is that your transition is from an existing IPv4 network. Hence, you have to do it incrementally and carefully. Never try to plan a big forklift type of transition. You should always have a master plan for this. You should always think in terms of interoperability not just migration because the question that always comes up while transitioning is about v4 hosts speaking to v6 and vice versa. This, and interoperability should always be kept in mind. Carefully evaluate the hardware support, application porting, and so forth. It is a good idea to monitor the IETF ngtrans working group.

CourseIFTIPV6
Slide101
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
CONFIDENTIAL
IFT-IPV6
Finally, let's discuss some of the transition strategies. Edge-to-core is one of the strategies. The apt title for this edge is the killer apt. The services could be the ones which drive IPv6 conversion. Scarce addresses will drive conversions and such things could be user driven. As mentioned earlier, core-to-edge strategies may be a good strategy for some service providers. If you are in an enterprise, you might be converting by routing protocol area. For example, it's even possible to convert one subnet at a time although that is highly incremental.

CourseIFTIPV6
Slide102
Conclusion: Evaluation and Survey
Thank you for taking the time to complete this training program on Juniper Networks IPv6.
CONFIDENTIAL
IFT-IPV6
Thank you for taking the time to complete this training program on Juniper Networks IPv6. You can take additional classes or learn more about Juniper Networks by visiting the partner center website.

CourseIFTIPV6

Ift Ipv6 A

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

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

Ift Ipv6 A

Hochgeladen von

Copyright:

Verfügbare Formate

education services courseware

IPv6 Technical Essentials

NOTE:PleasenotethisStudentGuidehasbeendevelopedfromanaudionarration.Thereforeitwillhave conversationalEnglish.Thepurposeofthistranscriptistohelpyoufollowtheonlinepresentationandmayrequire referencetoit.

IPv6 Technical Essentials

Welcome to Juniper Networks training course on IPv6 Technical Essentials.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

Can be represented as follows:

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

Can simplify multihoming

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.

2010 Juniper Networks, Inc. All rights reserved.