Deployment of IPv6 is rapidly expanding. Support for IPv6 in applications is lagging behind. Application platform vendors are taking steps to to overcome this issue. This session starts reviewing why this evolution is happening, and what the benefits of IPv6 are to applications. The majority of the session focuses on how applications should adopt and support IPv6 so it does not require a rewrite when your customer enables IPv6. We will look at C, ObjC , Swift, Java, PHP, and others. We examine address family independent socket APIs and what additional APIs different Operating Systems offer, how to test, and how different communities have moved towards IPv6 centric. Finally, we are looking at more advanced IPv6 application aspects such as multi-address support. This presentation is primarily focussed at application developers but should also be of interest to network operators to understand how future proof IPv6 applications are going to leverage the network, and what to look for in good IPv6 applications to deploy in the network. Attendees are encouraged to also attend BRKIP6-2616 which provides background of a wide area of use cases for IPv6 applications. ... View more

Cisco Live is Ciscos's caravan of of hundreds of employees & partners traveling each year to multiple cities around the world to educate thousands of customers and be educated by them. "Cisco Live is Cisco’s premier education and training destination for IT professionals worldwide" (www.ciscolive.com) Cisco Live is the best place to learn about Ciscos technologies including IPv6. You can read up on all Cisco Live presentations of the last ca. 3 years on www.ciscolive.com/online. You do not need to have attended Cisco Live or have a registered customer account. You can simply search and access all presentations by creating a guest account on www.ciscolive.com. Presentation Title BRKRST-2616 Addressing Networking challenges with latest Innovations in IPv6 COCIP6-1013 IPv4 Address Exhaustion and IPv6 Progress across Cisco IT BRKRST-2116 Intermediate - IPv6 from Intro to Intermediate DevNet-1275 Developing Better Applications with IPv6 This application was specifically developed to address application developers. We have also uploaded a copy onto the community for easier access. BRKRST-2022 IPv6 Routing Protocols Update BRKSPG-2603 Intermediate - How to Securely Operate an IPv6 Network LABIPM-2007 Intermediate - IPv6 Hands on Lab CCSIP6-2006 BMW: Enterprise IPv6 adoption LABSPG-7122 Advanced IPv6 Routing and services lab BRKIP6-2100 IPv6-centric application development BRKRST-2667 How to write an IPv6 Addressing Plan BRKSPG-2300 Service Provider IPv6 Deployment PNLCRS-2307 Don't Be Left Behind: Consumer Internet Traffic is Shifting to IPv6, Will your Organization Follow? BRKRST-2312 Intermediate - IPv6 Planning, Deployment and Operation Considerations BRKSPG-2061 IPv6 Deployment Best Practices for the Cable Access Network BRKCOL-2020 IPv6 in Enterprise Unified Communications Networks BRKSEC-3003 Advanced IPv6 Security in the LAN BRKRST-3123 Segment Routing for IPv6 Networks BRKSEC-3200 Advanced IPv6 Security Threats and Mitigation BRKRST-2301 Intermediate - Enterprise IPv6 Deployment Note: Cisco Live Tech-tutorials cost extra when attending Cisco Live. On Cisco Live Online they are also only accessible to the attendees that paid to participate in them. ... View more

Revision 02/15/2016 Abstract The deployment of IPv6 is rapidly expanding in the Internet. Support for IPv6 in applications is lagging behind. Vendors such as Apple are taking steps to rectify this situation and raise awareness to the problem. This document intends to help application developers across platforms to understand IPv6 and support IPv6 in their applications. Overview Accelerating adoption of IPv6 in the Internet The current IPv6 specification, https://tools.ietf.org/html/rfc2460, was standardized in the IETF in 1998. It has been implemented in a number of operating systems including Windows, MacOSX, Linux, and FreeBSD, and used in research networks such as GEANT and Internet2. With the depletion of the IPv4 address space (http://www.potaroo.net/tools/ipv4/), the issue has come to a head, and at this point two thirds of traffic from Verizon Wireless to Google reportedly uses IPv6 (http://www.worldipv6launch.org/measurements/), Deutsche Telekom, Comcast, and AT&T (http://6lab.cisco.com/ciscolive) are pushing their residential customers toward IPv6 deployment, and T-Mobile among others is experimenting with IPv6-only operation to the handset. Worldwide IPv6 use is projected to be about 10% in mid-2016 (Projection of IPv6 Metrics ), and some countries are likely to see it predominate (Projection of IPv6 Metrics ). Application support for IPv6 The "socket" API is the predominant interface for applications to use IPv4 and IPv6. It was extended almost a decade ago to provide IP version-agnostic support. This means that with single API calls both IPv4 and IPv6 will work in the application - with equal or less application side code than to support only IPv4. Widely used applications like Apache were changed to use these APIs a long time ago. Nevertheless, the larger developer community has been unaware of these changes, and as a result has been using the same IPv4-only APIs for the last 30 years. Apple waking up developers In Q2 2015, Apple took a bold step mandating IPv6 support for iOS 9 Apps (http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/). The implication for the developer community - and Cisco DevNet - is that our networks and applications need to become IP version agnostic, happily running in IPv4-only networks, IPv6-only networks, and networks with both. Cisco DevNet DevNet is Cisco's developer program. In general, DevNet provides developers with the tools and resources they need to build innovative solutions involving Cisco products. In terms of IPv6, DevNet aims to help internal and external application developers transition from IPv4 specific applications to IP4/6 agnostic applications. With this goal in mind, this Cisco internal community page is being used to gather IPv6 info. When ready, an external version will be hosted within DevNet. Background What is IPv6 In short, IPv6 is the replacement for IPv4 being deployed around the world. The current specification is RFC 2460, as updated by a number of other RFCs, along with the addressing architecture, ICMP, Neighbor Discovery (the counterpart to ARP), etc. See the end of this document for the important reference documents for IPv6. Why does IPv4 need a replacement? It is out of addresses. The "poster" version of that observation is the IPv4 Address Report. Today (Q2 2015) strategically thinking service providers plan for networks that are IPv6-only at their core to be able to simplify and scale it, and support IPv4 only as a service overlay, expecting that the overlay will die of natural causes. How it works Detailed network operation in IPv6 differs from IPv4 in important ways. However, at a conceptual level, one can think of IPv6 as IPv4 with longer addresses. IPv6 provides fundamental improvements and simplifications for areas such as mobility, virtualization or multicast. All these derive from clever use of that extended address space. If you want to learn more about IPv6 operation in detail, while looking at it from the "What IPv4 problem does this new feature in IPv6 solve ?", you will enjoy reading this free eBook: IPv6 for IPv4 Experts (draft) - yartikhiy Example Facebook is an example of application centric improvements through the use of IPv6. In their network, Facebook was running private IPv4 addresses (RFC1918), and they where running out of that address space AND they where running out of available TCP/UDP port number space (< 16 bits) on their servers. Instead of using just a single IP address per host, they realized that they could route a separate IPv6 /64 or /80 prefix to each of those hosts and use the remaining bits of the IID ("host number", in IPv4-speak) to identify the application. This resolved their entire scale problem. Doing so, however, required them to become IPv6-only within their data centers, and they have chosen to do that. Unicast addressing The IPv6 address, specified in RFC 4291 - IP Version 6 Addressing Architecture​ , is either multicast or unicast. Unicast addresses (like IPv4 addresses) are CIDR addresses with a prefix that identifies a topological location in the network, and have an Interface Identifier (IID) that corresponds to a host or other device within that location. By convention, the global or unique local unicast IPv6 prefix allocated to a subnet on a LAN is 64 bits in length (a /64). The preferred way is for IPv6 host addresses to be auto-configured: Routers announce the allocated (e.g. /64) prefixes on LANs, and the host automatically fills in the remaining IID - for example by combination of its MAC-address (48 bits) with other locally generated bits - and then performs an IPv6 address collision detection and mitigation. However, by popular demand, there is support for traditional per-host DHCP address assignment to hosts, and by now all host operating systems support that as well. More importantly though, DHCP "prefix delegation" is used on e.g. home routers (also called home gateways) to learn an IPv6 prefix from the service provider. Instead of only getting a single IPv4 address, homes do in IPv6 therefore get a full /64 - without the need for NAT. NAT NAT is a lot less relevant in IPv6 than it is in IPv4, but it has a big role in moving to IPv6 for service providers. In this section we cover applicability of NAT to IPv6. In the section below on network operators we discuss its role for migration: There are definitions and support in some network devices for NATing IPv6 addresses to other IPv6 addresses (NAT66), but this is rarely used because the original purpose to do this in IPv4 (NAT44) was to multiplex limited (mostly global) IPv4 address space. Without this addressing scarcity, NAT is not needed for this purpose. The /64 prefix delegation to homes as opposed to a single IPv4 address is the most common example of this. Beside address scarcity, the other candidate reasons for NATing between IPv6 addresses are address obfuscation, e.g. NAT "benefits" for security in firewalls (FWs). Obscuring IP addresses is a contentious topic. Privacy addresses have been defined for IPv6 where dynamic changing of addresses is involved, which can make life of long-lived application more difficult. The authors of this document think it is of little value to the intended goals (e.g. privacy or security). For example take a look at an email envelope sometime and ask yourself where email goes. Routers that have to perform NAT to multiplex private IPv4 address space onto global IPv4 addresses (such as home gateways or Small Medium Business routers) also happen to be the routers where firewall functions are needed.  Because multiple addresses from the inside are mapped to a single address on the outside, this is actually called PAT - Port Address Translation. Different ports of the same global IPv4 address are dynamically used by different hosts on the inside. PAT also has the side-effect that without additional configuration, it is not possible to have arbitrary outside to inside connections. This is occasionally being sold as a security and firewall benefit of NAT/PAT in documents such as Cisco's Zone-Based Policy Firewall Design and Application Guide. ​ In reality, the ability to prohibit in a FW undesired connections, e.g. outside to inside is equally if not more easily possible without NAT in IPv6, so these historic FW recommendations simply confuse the need of address translation because of IPv4 address scarcity with privacy and security benefits. NAT64 between an IPv6 and IPv4 system is necessary as long as communication is necessary with IPv4 only hosts. There are various technologies for NAT64. In most cases, applications do not have to worry about this at all because they should use DNS names to establish communications, and well managed NAT64 setups will also support DNS: Instead of returning only the IPv4 address of a communications partner, the DNS setup in conjunction with the NAT will also provide the IPv6 address mapped to the IPv4 address. Multicast addressing Multicast addressing IPv6 has a range of improvements over IPv4: Architecturally defined scoped addresses: The idea of "scoped" addresses was invented in IPv4 but due to limited address space it was left to every network operator to define which address ranges belong to which scope. The range of scopes is scope 1 for within a host, scope 2 link-local, all the way up to scope 14, the Internet. Unicast prefix multicast addresses: In IPv4, the allocation of multicast group address is a mayor administrative hurdle due to limited IPv4 multicast group address space. In IPv6, RFC3306 ( Unicast-Prefix-based IPv6 Multicast Addresses) defines how to derive an IPv6 multicast prefix from an existing IPv6 unicast prefix. Therefore, once an organization owns an IPv6 unicast prefix, it also owns an IPv6 multicast address prefix without any further administrative work - with all scopes. SSM addresses: For every scope and every prefix, the is also a well-defined SSM address range (through additional bit combinations of the first 8 bits of the address), therefore, SSM is also auto-configuring in the network - for all scopes. PIM-SM Embedded RP addressing: PIM-SM is the most widely deployed network protocol to support IP multicast. Network wide manual configuration or hard to secure dynamic protocols are required to learn the address of the so-called PIM-SM "Rendezsvous Point". In IPv6, these configurations or protocols are unnecessary, because an extension to RFC3306 permits to indicate in the actual IPv6 multicast group address also the address of the Rendesvous Point. This also makes PIM-SM in IPv6 network 95% auto-configuring. Why network operators care Tactical - CGN When service providers can not aquire sufficient IPv4 addressing space to give at least each of their subscribers a separate IPv4 address, they look for mitigation. On the IPv4 side, this mitigation technique is called CGN - Carrier Grade NAT. It can use various forms of NATing to effectively make multiple subscribers share the same global IPv4 address. These CGN techniques are a mayor cost and painpoint for operators. The following is an incomplete list of problems with them: They are expensive They are scale limited. Every eg: web application run by a subscriber potentially adds to the state the CGN needs to keep (based on technology use). If state churn happens, application start to fail in mysterious ways because some TCP connections will not work - others will. This can become very expensive in support (hard to troubleshoot and confusing to the customers). They make potentially government mandated record keeping more difficult They eliminate the ability for accurate location services - the location possible to associate with such addresses in application from eg: Google, Facebook Apple or other ecosystems is often limited to only the location where the actual CGN device sits. To mitigate the problem of CGNs, most operators that run into these IPv4 addressing issues simultaneously enable subscribers for both IPv4 (with a CGN address) and IPv6. IPv6 then is the desired exit strategy from CGN problems: Because host operating systems do prefer IPv6 connectivity/addresses over IPv4, the CGN will only be used for those application connections where the remote side does not support IPv6. Being able to predict how much network traffic from such subscribers can already use IPv6 natively - and therefore mitigate problems with CGNs - is one of the key reasons for Cisco to track and predict IPv6 adoption via 6lab.cisco.com. Strategic - Wireline For wireline network operators like Comcast, AT&T, KDDI/JPNE, Reliance JIO Infocomm, and Deutsche Telekom Terastream, the issue probably comes down to the issues of Reliability, Availability, and Maintainability, and the correlated issues of Security. In short, complexity is the enemy of all of those attributes, and IPv4 networks, due to the need to multiplex address space, are becoming increasingly complex. For a discussion of that, see RFC 3439 - Some Internet Architectural Guidelines and Philosophy. In addition, there is the issue of cost - increased complexity drives cost in diagnosis of faults and of network planning, and buying extra boxes to perform functions like NAT is buying extra boxes. Strategic - Mobile Operators of mobile telecom networks have those same issues, and in addition have a fundamental business issue in the cost of an Access Point Name (APN). There is the possibility that this might change, but currently IPv4 and IPv6 use different APNs from a handset, and each has a cost. If the operator can only use one APN, he significantly reduces the operational cost of his network. Hence, mobile wireless operators are motivated by the same costs as wireline operators, but with an additional "thumb on the scale". Strategic - Enterprises Large enterprises also have business issues. Microsoft very publicly came to that realization in 2014 (IPv4 Exhaustion Gets Real – Microsoft Runs Out Of U.S. Addresses For Azure Cloud – Time To Move To IPv6! | Deploy360 Pro… ) and 2015 (Microsoft Execs Expressed ‘Shock and Disbelief’ at Internet Address Shortage - Digits - WSJ ). IPv6 only benefits Once a move into IPv6 is done, there turn out to be significant benefits to IPv6-only operation, especially in data centers. Facebook reports that, as it has converted to IPv6-only, they have been able to sidestep RFC 1918 and TCP/UDP port number limitations by running a prefix to a machine, and using the IID to identify an application or process. Additionally, anecdotal evidence from network operators such as Time-Warner Cable says that IPv6 RTTs are often less than IPv4 RTTs between the same two machines. It's difficult to make concrete statements about anecdotal evidence, but they conjecture that it is because the packet traverses less middleware. Summary Network operators care aboutt IPv6 because it is the only way to scale addressing, because makes their networks more reliable, more available, easier to maintain, and more secure, all of which reduces cost. In the end, it's a business argument, and a strong enough one that at least one operator has said that they want to charge back to their vendor anything that forces them to keep IPv4 running in their network. Why application developers should care Business requirements If the application does not support IPv6, it may not be possible to sell the application anymore as intended or a growing number of possible users of the application will either not be able to use the application all. "Oh, you wanted your app to be sold through the app store?": To pick one very prominent data point, Apple has recently announced that IOS 9 for iPhone and iPad will require demonstrated IPv6 support of any application sold through the application store (Your App and Next Generation Networks - WWDC 2015 - Videos - Apple Developer ). A clarification was made to the IETF's IPv6 Operations Working Group on the details of the requirement, in https://www.ietf.org/mail-archive/web/v6ops/current/msg22275.html​​. "But my market doesn't need it" Another example are operators such as T-Mobile USA, which is experimenting with IPv6-only operation for handsets that support it. as noted in "why mobile telecom operators care", T-mobile is of the perspective that a single APN, and a single protocol, gives them a less expensive network to operate. In return: If you do not care supporting IPv6 on the android version of your application because Google may not mandate it, you still may fall short getting sales with subscribers on such networks. And Apple is suggesting that such a network might prefer Apple phones. Support DNS naming If your app expects user to input or recognize IPv4 addresses anywhere in the user interface, you need to really rethink how to move to naming when starting to support IPv6. No user, not even a network administrator is willing or capable to deal directly with IPv6 addresses. Please strongly consider leveraging DNS with all its options. Reap application benefits of IPv6 A range of network services have started or are already thinking of leveraging the ample bits in IPv6 addresses to encode specific semantics that the applications may or want to care about. See below. Basic Application development for IPv6 Introduction Unless specifically mentioned later on this document, none of the application logic in a network facing application needs to change to support IPv6. In the first degree, it is only IPv4 with longer addresses. Port-numbers for UDP/TCP applications stay the same, when/how and why to set up network/web connections stays the same. QoS/DSCP stays the same, diagnostics/tools (traceroute, wireshark, netstat, ...) stay the same, IP multicast supports the same function, .... Therefore we will first describe how to port applications to IPv6 without using advanced functionality new or changed in IPv6. Sockets: Use address-agnostic APIs The original API to support IP network was - and still is with a lot of modifications - the  socket API. Originally from University California at Berkeley, now via various standards bodies: POSIX and others. Its IP support was originally very specific for IPv6, and when IPv6 was introduced it first was added as yet another so-called Address Family (AF), which resulted in the need for IPv4 and IPv6 capable applications to explicitly enumerate code dealing with both address families - resulting in more than duplication of the network facing code. This was later rectified with the so-called "address-agnostic" APIs which permitted for almost all intent and purposes to avoid duplication of code because the SDK itself would automatically figure out what address - IPV4 or IPv6 is being used. And if sometime in the future (eg: in 2150) IPv9 is introduced, the applications relying only on these address agnostic APIs could support this  without changes to the code - just a newer version of the SDK. Of course, as you will see, this is in real applications likely only 95% possible. We describe the details of these APIs below. Higher layer APIs: Most likely no additional work In higher layer APIs you will encounter either some modified/enhanced socket like API calls or even better purely address agnostic APIs. For example anything that deals with "web" level programming and therefore URIs is most likely already fully address agnostic without code changes. It is most likely only a matter of the actual SDKs to support IPv6 operations. For SDK/APIs that we are aware of with differences/changes needed for IPv6, we will include them below. OS specific API considerations Even if you do not plan to use Linux, it is recommended to read through the Linux section, because we consider it to be today's network programming reference platform, adopting fasted improvements and most often being used as the basis of vendor specific OSs to derive their API and functionality. Reference / Linux http://www.kame.net/newsletter/19980604/ Provide Linux Dev VM without v4 support in which app can be compiled Windows Support for IPv6 in Windows Server 2008 R2 and Windows 7 From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be. Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity. iOS Your App and Next Generation Networks - WWDC 2015 - Videos - Apple Developer - this video goes into details of IPv6 requirements of Apple and as well the available APIs and the means of testing. Android MacOS Most of the high-level frameworks are usable across iOS/OSX line, if using lower-level frameworks, refer to Linux section which discusses the POSIX APIs. see if Apple folks want to team up and help with iOS dev env/VM, check on iOS emulator Advanced IPv6 considerations Happy Eyeballs "Happy Eyeballs" has become a term for more or less intelligent decision mechanisms between alternative options for a network connection - to make the user most happy. This can be selection of the best web-ache, the best transport protocol (SCTP, TCP, UDP), or for IPv6 the selection of IPv6 vs. IPv4 when both may be available (v4/v6 happy eyeballs) or the selection or the best out of multiple possible IPv6 addresses for a communication partner (IPv6 address selection, discussed in the next section). IPv4/IPv6 happy eyeball  as well as IPv6 address selection are ideally done by network stacks where a connection is built to a (DNS) named communications partner. The happy function is then to build as fast as possible a working connection - via either v4 or v6, including DNS name resolution. How Apple  plans to perform happy eyeballs for IPv4/IPv6 in iOSv9 is explained here. Address selection The biggest challenge and opportunity with IPv6 is to determine how to select IPv6 addresses for specific connections. For example: It is quite common in IPv4 applications to support configuration or GUI parameters to specific what IP address to use for particular communications, whether it is the address for a server port to listen to, or as a client an address to use to connect to a server. The host could have  multiple interfaces and the application/user wants to select a specific one via the address, or it the addresses have different function. Eg: different web-services. In IPv6, the considerations if or how to do this become a lot more advanced and flexible: Local address assignment logic RFC 6555 (RFC 6555 - Happy Eyeballs: Success with Dual-Stack Hosts ) describes how the IPv6 network host stack of an application originating a connection to a remote IPv6 address will pick the best local IPv6 address and outgoing interface for this connection. You only need to bind(3) the local IPv6 address of a connection to a different address if your application wants to use a different IPv6 address. Link-local addresses Link-local addresses are automatically assigned by a host, but can not be routed, so they only allow to reach other hosts on the same LAN/subnet. In IPv4, the most commonly encountered link-local addresses are 169.254/16 as defined in RFC3927. Normally, these are only assigned when the host fails to assign a better address, eg: via DHCP, so it is uncommon to see them. In result, IPv4 applications do usually not deal with the specifics of link local addresses. In IPv6, link-local IPv6 addresses are always assigned on every interface, independent of what other global address(es) the host has on the interfaces, and IPv6 is going to be a lot more prevalent in ad-hoc or weak/not administered networks. If your application specifically knows that it wants to talk with another device If you application wants to specific communicate with other  result in a potentially badly set up network. IPv6 References The root document is RFC 2460, but there are a number of RFCs that update it in minor ways. In addition, there are important RFCs that document the addressing architecture, ICMPv6, Neighbor Discovery, and other components. RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification S. Deering, R. Hinden. December 1998. (Format: TXT=85490 bytes) (Obsoletes RFC1883) (Updated by RFC5095, RFC5722, RFC5871, RFC6437, RFC6564, RFC6935, RFC6946, RFC7045, RFC7112) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2460) RFC 3122 - Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification A. Conta. June 2001. (Format: TXT=40416 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3122) RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT=231402 bytes) (Updated by RFC4361, RFC5494, RFC6221, RFC6422, RFC6644, RFC7083, RFC7227, RFC7283, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3315) RFC 3363 - Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002. (Format: TXT=11055 bytes) (Updates RFC2673, RFC2874) (Updated by RFC6672) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3363) RFC 3633 - IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 O. Troan, R. Droms. December 2003. (Format: TXT=45308 bytes) (Updated by RFC6603, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3633) RFC 3756 - IPv6 Neighbor Discovery (ND) Trust Models and Threats P. Nikander, Ed., J. Kempf, E. Nordmark. May 2004. (Format: TXT=56674 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3756) RFC 4193 - Unique Local IPv6 Unicast Addresses R. Hinden, B. Haberman. October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4193) RFC 4291 - IP Version 6 Addressing Architecture R. Hinden, S. Deering. February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Updated by RFC5952, RFC6052, RFC7136, RFC7346, RFC7371) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4291) RFC 4389 - Neighbor Discovery Proxies (ND Proxy) D. Thaler, M. Talwar, C. Patel. April 2006. (Format: TXT=38124 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4389) RFC 4861 - Neighbor Discovery for IP version 6 (IPv6) T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. (Format: TXT=235106 bytes) (Obsoletes RFC2461) (Updated by RFC5942, RFC6980, RFC7048, RFC7527, RFC7559) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4861) RFC 4862 - IPv6 Stateless Address Autoconfiguration S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes RFC2462) (Updated by RFC7527) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4862) RFC 4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4941) RFC 5095 - Deprecation of Type 0 Routing Headers in IPv6 J. Abley, P. Savola, G. Neville-Neil. December 2007. (Format: TXT=13423 bytes) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5095) RFC 5722 - Handling of Overlapping IPv6 Fragments S. Krishnan. December 2009. (Format: TXT=11838 bytes) (Updates RFC2460) (Updated by RFC6946) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5722) RFC 5952 - A Recommendation for IPv6 Address Text Representation S. Kawamura, M. Kawashima. August 2010. (Format: TXT=26570 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5952) RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=41849 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6052) RFC 6434 - IPv6 Node Requirements E. Jankiewicz, J. Loughney, T. Narten. December 2011. (Format: TXT=64407 bytes) (Obsoletes RFC4294) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6434) RFC 6437 - IPv6 Flow Label Specification S. Amante, B. Carpenter, S. Jiang, J. Rajahalme. November 2011. (Format: TXT=35269 bytes) (Obsoletes RFC3697) (Updates RFC2205, RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6437) RFC 6564 - A Uniform Format for IPv6 Extension Headers S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia. April 2012. (Format: TXT=12879 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6564) RFC 6775 - Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) Z. Shelby, Ed., S. Chakrabarti, E. Nordmark, C. Bormann. November 2012. (Format: TXT=130616 bytes) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6775) RFC 6946 - Processing of IPv6 "Atomic" Fragments F. Gont. May 2013. (Format: TXT=18843 bytes) (Updates RFC2460, RFC5722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6946) RFC 6980 - Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery F. Gont. August 2013. (Format: TXT=20850 bytes) (Updates RFC3971, RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6980) RFC 7045 - Transmission and Processing of IPv6 Extension Headers B. Carpenter, S. Jiang. December 2013. (Format: TXT=21852 bytes) (Updates RFC2460, RFC2780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7045) RFC 7112 - Implications of Oversized IPv6 Header Chains F. Gont, V. Manral, R. Bonica. January 2014. (Format: TXT=15897 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7112) RFC 7136 - Significance of IPv6 Interface Identifiers B. Carpenter, S. Jiang. February 2014. (Format: TXT=23172 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7136) RFC 7217 - A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfigurati… F. Gont. April 2014. (Format: TXT=48497 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7217) RFC 7342 - Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers L. Dunbar, W. Kumari, I. Gashinsky. August 2014. (Format: TXT=28413 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7342) RFC 7346 - IPv6 Multicast Address Scopes R. Droms. August 2014. (Format: TXT=10831 bytes) (Updates RFC4007, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7346) RFC 7371 - Updates to the IPv6 Multicast Addressing Architecture M. Boucadair, S. Venaas. September 2014. (Format: TXT=18327 bytes) (Updates RFC3306, RFC3956, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7371) ... View more

I would like to build an applet/EEM-script that would run in the CLI when performing an exec level CLI command, eg: "show foobar status". What is the best option to do this ?     ... View more