DOCSLIB.ORG

Ipv6 Security Threats and Mitigation Eric Vyncke, Distinguished System Engineer [email protected] @Evyncke

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ipv6 Security Threats and Mitigation Eric Vyncke, Distinguished System Engineer Evyncke@Cisco.Com @Evyncke Advanced IPv6 Security Threats and Mitigation Eric Vyncke, Distinguished System Engineer [email protected] @evyncke BRKSEC-3200 Session Objectives • Advanced IPv6 security topics like extension headers, transition options and dual stack environments • Including more details on attack • Main focus is on enterprise issues • Requirements: good knowledge of the IPv6 and IPsec protocols as well as IPv4 & IPv6 network security best practices (for example BRKSEC-2003 from www.ciscolive.com) 3 Roadmap For IPv6 Security Sessions BRKSEC-2003 Introduction to IPv6 Security: Threats and Mitigation www.ciscolive.com BRKSPG-2603 How to Securely Operate an IPv6 Network BRKSEC-3003 BRKSEC-3200 Advanced IPv6 Security in Advanced IPv6 Security: Operation the LAN Threats and Mitigation Architecture and design BRKSEC-3036 Advanced IPsec LTRSEC-3001 Advanced - IOS designs with FlexVPN FlexVPN Lab Dual-stack Products 4 For Your References... Reference • There are more slides in the hand-outs than presented during the class • Those slides are mainly for reference and are indicated by the book icon on the top right corner (as on this slide) • Some slides have also a call-out to another session (see below) BRKSEC- 3003 • Other slides are about demos and experiments (not to be repeated on a production network) 5 Agenda • Routing security • “Playing” with extension headers • More on tunnels and dual-stack • Enforcing a security policy • Summary “Experiment” with IPv6-only over WiFi at Cisco Live SSID: CL-NAT64 Passphrase: cl-nat64 6 Routing Security 7 IPv6 Bogon and Anti-Spoofing Filtering • Bogon filtering (data plane & BGP route-map): http://www.cymru.com/Bogons/ipv6.txt • Every network should implement two forms of anti-spoofing protections: • Prevent spoofed addresses from entering the network • Prevent the origination of packets containing spoofed source addresses • Anti-spoofing = uRPF Inter-Networking Device with uRPF Enabled IPv6 IPv6 Intranet X Intranet/Internet IPv6 Unallocated No Route to SrcAddr => Drop Source Address 8 For Your IPv6 uRPF and Cisco Devices Reference The Theory-Practice Gap • Supported everywhere except: • 7600 & Cat 6K • Sup720/32: no IPv6 uRPF at all • Sup 2T is OK • Cat 3750: no uRPF at all • GSR 12K • only strict mode • only with Engine 5, other engines uRPF not supported • requires IOS 12.0(31)S or IOS-XR rls 2.1 • ASR 5K • ASR 9K requires release 4.1.1 • Metro switch • ASA enables IPv4 and IPv6 uRPF in the same command • No VRF mode yet for IPv6 9 Remote Triggered Black Hole (RFC 5635) BGP update:BGP update: BGP update: BGP update: BGP update:BGP update: Block 2001:db8::bad BGP update Block 2001:db8::bad NOC 2001:db8::bad . BGP allows you to ”announce” a host/subnet IP address which you want to drop traffic to or from . By enabling BGP on selected choke points, it becomes possible to control traffic dynamically 10 How Does RTBH Work? • It’s Magic! • BGP allows specifying the next-hop IP address in routing updates. • Other routing protocols automatically use the announcing device IP address as the next-hop • By setting the next-hop of an IP address to the RFC 6666 discard prefix 100::/64, we can create a routing update containing this specific IP address • This routing update which when received, will merge the routing update with a pre- defined static route on the receiving router: • ipv6 route 100::/64 Null0 • Now, the routing table contains a routing entry specifying that traffic for this address, will be sent to the Null0 interface • By default: drop all packets to this address • By using loose uRPF: drop all packets from this address (because interface is Null0) • http://www.cisco.com/web/about/security/intelligence/ipv6_rtbh.html 11 Edge (Dropping) Router Configuration Do not DoS ourselves by generating ICMP interface Null0 no ipv6 unreachables Generic BGP configuration for IPv6 ! (to be localized of course and care must be taken to avoid router bgp 65444 forwarding RTBH specific routes outside of your AS) bgp router-id 10.10.10.2 neighbor 2001:db8::1 remote-as 65444 ! address-family ipv6 neighbor 2001:db8:::1 activate ! ipv6 route 100::/64 Null0 Static route for the RFC 6666 discard prefix to the Null0 12 Trigger (NOC) Router Configuration interface Null0 Generic BGP configuration for IPv6 no ipv6 unreachables (to be localized of course and care must be taken to avoid ! forwarding RTBH specific routes outside of your AS) router bgp 65444 bgp router-id 10.10.10.1 neighbor 2001:db8::2 remote-as 65444 no auto-summary st ! 1 part of the “magic” to send address-family IPv6 some route with the discard next- neighbor 2001:db8::2 activate hop network 2001:db8:0:ff::/64 redistribute static route-map ipv6-rm ! route-map ipv6-rm permit 10 2nd part of the “magic” all routes match tag 66 with a tag of 66 will be sent with set local-preference 200 the discard next-hop set origin igp set ipv6 next-hop 100::1 route-map ipv6-rm deny 20 13 Two Final Touches to RTBH ipv6 route 2001:db8::bad/128 100::1 tag 66 Create a static route to 2001:db8::bad with tag 66, this will trigger a BGP update with next-hop 100::1 and all edge routers will drop packets to 2001:db8::bad interface Gigabit0/0/1 ipv6 verify unicast source reachable-via any [allow-default] But, usually we want to drop packet FROM an address, so uRPF must be configured at the edge routers 14 Preventing IPv6 Routing Attacks Protocol Authentication • BGP, ISIS, EIGRP no change: • An MD5 authentication of the routing update • OSPFv3 has changed and pulled MD5 authentication from the protocol and instead rely on transport mode IPsec (for authentication and confidentiality) • But see 6506 7166 (but not widely implemented yet) • IPv6 routing attack best practices • Use traditional authentication mechanisms on BGP and IS-IS • Use IPsec to secure protocols such as OSPFv3 15 For Your Reference OSPF or EIGRP Authentication interface Ethernet0/0 ipv6 ospf 1 area 0 ipv6 ospf authentication ipsec spi 500 md5 1234567890ABCDEF1234567890ABCDEF interface Ethernet0/0 ipv6 authentication mode eigrp 100 md5 ipv6 authentication key-chain eigrp 100 MYCHAIN key chain MYCHAIN key 1 key-string 1234567890ABCDEF1234567890ABCDEF accept-lifetime local 12:00:00 Dec 31 2011 12:00:00 Jan 1 2012 send-lifetime local 00:00:00 Jan 1 2012 23:59:59 Dec 31 2013 No crypto maps, no ISAKMP: transport mode with static session keys 16 “Playing” with Extension Headers 17 Packet Forgery with SCAPY /1 • Scapy is a open source packet forgery tool built on Python • Powerful albeit complex to understand and to use: evyncke@host1:~# scapy Welcome to Scapy (2.1.0) >>> target="2001:db8:23:0:60de:29ff:fe15:2” >>> packet=IPv6(dst=target)/ICMPv6EchoRequest(id=0x1234, seq=RandShort(), data="ERIC") >>> sr1(packet) Begin emission: Finished to send 1 packets. Received 2 packets, got 1 answers, remaining 0 packets <IPv6 version=6L tc=0L fl=0L plen=12 nh=ICMPv6 hlim=62 src=2001:db8:23:0:60de:29ff:fe15:2 dst=2001:db8:1:0:60de:29ff:fe15:1 |<ICMPv6EchoReply type=Echo Reply code=0 cksum=0xdb04 id=0x1234 seq=0x956a data='ERIC' |>> 18 18 Packet Forgery with SCAPY /2 • Variable can be assigned a value with “=“ • Packets are built with the concatenation operator “/” • Headers are instantiated with default values (such as source address, checksum, next header, length, ...) all can be overwritten • Packet can be displayed in various format: ls(), packet.show() • Packet can be sent by • send(): simply send it • sr1(): send it and wait for one reply >>> target="2001:db8:23:0:60de:29ff:fe15:2” >>> packet=IPv6(dst=target)/ICMPv6EchoRequest(id=0x1234, seq=RandShort(), data="ERIC") 19 IPv6 Routing Header • Processed by intermediate routers • Three types • Type 0: similar to IPv4 source routing (multiple intermediate routers) • Type 2: used for mobile IPv6 • Type 3: used by RPL (Routing Protocol for Low-Power and Lossy Networks) • Type (4?): segment routing Next Header = IPv6 Basic Header 43 Routing Header Routing Header Routing Header Next Header Ext Hdr Length RHRouting Type Type Segments Left Routing Header Data 20 Type 0 Routing Header Amplification Attack • What if attacker sends a packet with RH containing • A -> B -> A -> B -> A -> B -> A -> B -> A .... • Packet will loop multiple time on the link A-B • An amplification attack! A B 21 Type 0 Routing Header Traffic Rebound . Rule on the Firewall . Allow proto tcp from any to webserver port 80 . Deny proto tcp from any to any Web Host1 src=host1,dst=web, payload proto=tcp, dport=80 rtheader=host2, segments left=1 src=host1, dst=host2 rtheader=web, segments left=0 payload proto=tcp, IPv6 dport=80 Network Host2 Firewall 22 Preventing Routing Header-0 Attacks • Apply same policy for IPv6 as for IPv4: • Block Routing Header type 0(RH-0) • Prevent processing at the intermediate nodes but forwarding is OK • no ipv6 source-route • Windows, Linux, Mac OS: default setting • IOS-XR before 4.0: a bug prevented the processing of RH-0 • IOS before 12.4(15)T: by default RH-0 were processed • At the edge to block forwarding • With an ACL blocking routing header • RFC 5095 (Dec 2007) RH-0 is deprecated • Default changed in IOS 12.4(15)T and IOS-XR 4.0 to ignore RH-0 • ASA drops all packets with any routing header • Type 2 and type 3 (+SR – type 4) are not dangerous and should be allowed 23 Let’s Try it With Scapy & Tcpdump a="2001:DB8:1::1" b="2001:DB8:23::2” route=[] for i in range(0, 30): route.append(a) route.append(b) packet=IPv6(dst=b,hlim=255)/IPv6ExtHdrRouting(addresses=route,type=0)/ICMPv6EchoRequest() sr1(packet) Using a recent IOS, the router refuses to process Routing Header Type 0 IP6 (hlim 63, next-header ICMPv6 (58) payload length: 384) 2001:db8:23::2 > scapy_host: [icmp6 sum ok] ICMP6, parameter problem, length 384, errorneous - octet 42 24 Let’s Try it Again With Ancient IOS, Scapy & Tcpdump Snapshot before: R1#sh ipv6 traffic interface ethernet 0/0 Ethernet0/0 IPv6 statistics: Rcvd: 26 total, 25 local destination 41 source-routed, 0 truncated ..
Load more

Recommended publications
  • Chapter 6: General Design Considerations
    ch01i.book Page 194 Friday, March 26, 2004 10:08 AM This chapter covers the following topics: • Physical Security Issues • Layer 2 Security Considerations • IP Addressing Design Considerations • ICMP Design Considerations • Routing Considerations • Transport Protocol Design Considerations • DoS Design Considerations ch01i.book Page 195 Friday, March 26, 2004 10:08 AM C H A P T E R 6 General Design Considerations Many things difficult to design prove easy to performance. —Samuel Johnson, Rasselas: The History of Rasselas, Prince of Abissinia, 1759 A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering. —Freeman Dyson, Physicist, Disturbing the Universe, 1979 At the beginning of any secure network design project, many best practices apply more or less uniformly to all areas of the design. This chapter presents these practices in a single location and then draws on them throughout the rest of the book. The designs presented in Chapter 13, “Edge Security Design,” Chapter 14, “Campus Security Design,” and Chapter 15, “Teleworker Security Design,” are based on many of the concepts described here and in the companion chapters (Chapters 7–11), which detail specific design considerations for certain technologies. The topics are presented in loose compliance with the seven-layer OSI model and, as such, cover a diverse set of topics. Chapter 1, “Network Security Axioms,” presented the security axioms; this chapter translates them into actionable guidance for secure network design. Physical Security Issues One common security truism is “Once you have physical access to a box, all bets are off.” This is a good beginning assumption for this section.
    [Show full text]
  • Enterprise Ipv6 Deployment
    Enterprise IPv6 Deployment Tim Martin CCIE #2020 BRKRST-2301 @bckcntryskr Agenda • General Design • Host Configuration • Access Layer • Routing Protocols • Data Center • WAN Deployment • Internet Edge • Conclusion Enterprise IPv6 Guidance • RFC 7381 enterprise IPv6 guidelines • Updated white paper – Cisco.com • No major change to 2/3 tier architecture Access Distribution Si Core Distribution Access WAN Data Center Internet BRKRST-2301 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 Global Address Assignment • Provider Allocated (PA) PA PI • From your ISP, single homed 2000::/3 2000::/3 • /48 - /60 IANA • Provider Independent (PI) Registries • Multi home, Multi provider /12 /12 RIR • /32 - /48 /32 • Local Internet Registry (LIR) ISP Org /32 /48 • Regional registry member • Acquire & manage space Level Four /48 • /29 - /32 Entity Subordinate /48 BRKRST-2301 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 Multinational Model • PA or PI from each region you operate in • Coordination of advertised space within each RIR • Most run PI from primary region as an LIR 2a00:0000::/12 2600:0000::/12 2400:0000::/12 2c00:0000::/12 2800:0000::/12 BRKRST-2301 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 Prefix Length Considerations • Anywhere a host exists /64 Hosts /64 • RFC 7421, rational for /64 Core /64 or /127 • Point to Point /127 • RFC 6164, cache exhaustion Pt 2 Pt • Reserve a /64, configure a /127 /127 Servers • Loopback or Anycast /128 /64 Loopback /128 Hosts /64 BRKRST-2301
    [Show full text]
  • Ipv6 Security: Myths & Legends
    IPv6 security: myths & legends Paul Ebersman – [email protected] 21 Apr 2015 NANOG on the Road – Boston So many new security issues with IPv6! Or are there… IPv6 Security issues • Same problem, different name • A few myths & misconceptions • Actual new issues • FUD (Fear Uncertainty & Doubt) Round up the usual suspects! Remember these? • ARP cache poisoning • P2p ping pong attacks • Rogue DHCP ARP cache poisoning • Bad guy broadcasts fake ARP • Hosts on subnet put bad entry in ARP Cache • Result: MiM or DOS Ping pong attack • P2P link with subnet > /31 • Bad buy sends packet for addr in subnet but not one of two routers • Result: Link clogs with routers sending packet back and forth Rogue DHCP • Client broadcasts DHCP request • Bad guy sends DHCP offer w/his “bad” router as default GW • Client now sends all traffic to bad GW • Result: MiM or DOS Look similar? • Neighbor cache corruption • P2p ping pong attacks • Rogue DHCP + rogue RA Solutions? • Lock down local wire • /127s for p2p links (RFC 6164) • RA Guard (RFC 6105) And now for something completely different! So what is new? • Extension header chains • Packet/Header fragmentation • Predictable fragment headers • Atomic fragments The IPv4 Packet 14 The IPv6 Packet 15 Fragmentation • Minimum 1280 bytes • Only source host can fragment • Destination must get all fragments • What happens if someone plays with fragments? IPv6 Extension Header Chains • No limit on length • Deep packet inspection bogs down • Confuses stateless firewalls • Fragments a problem • draft-ietf-6man-oversized-header-chain-09
    [Show full text]
  • ISP Column an Occasional Column on Things Internet
    The ISP Column An occasional column on things Internet Hunting the Bogon May 2004 There were a number of "adventure" games in the late 1970's and early 80's. By today's standards the original versions of these computer games were not just primitive, they make banging the rooks together look sophisticated. But at the time they were a pointer to the use of computers as something more than just numerical calculators, or business machines. Programs could be imaginative and even fun (well ok, 'fun' was different then!). One of the more widespread early versions of this kind of game was "Hunt the Wumpus'. The web being what it is these days you can meander back to 1976 at http://www.atariarchives.org/bcc1/showpage.php?page=247 For those who want a first-hand experience of 1970's computer games, check out: http://www.taylor.org/~patrick/wumpus/ As far as I can tell the only difference is that the original games proceeded at a pace that could only be described as glacial! What's a "Bogon"? Good question. The word bogon probably has lots of meanings in various contexts, but in the context of the Internet address realm a bogon refers to the use of an address or, more generally a route object, that is not duly authorized by the entity to which the address, or resource, was originally assigned. I must admit that I've yet to hear of any other word that succinctly takes that rather long- winded phrase and sums it up with one word! There are two kinds of bogon objects in the inter-domain space - the first is the advertisement of IP addresses, and the second is the use of Autonomous System numbers within the AS Path attribute.
    [Show full text]
  • ARIN 2005 Annual Report
    Public Participation Leading to Positive Results Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information ission Statement and educational outreach. M The American Registry for Internet Numbers (ARIN) publishes annual reports to document for its community Contents the operations and activities of the organization. The ARIN at a Glance . 4 audited financial statements for fiscal year 2005 will be published separately in mid-2006. Year in Review . 6 To view this report online or to review the annual reports and financial statements from previous years, please visit Reports & Updates . 9 the ARIN website at: Global Community Activities . 17 www.arin.net/about_us/corp_docs/annual_rprt.html Internet Number © ARIN Resource Policy . 19 All Rights Reserved. “ARIN” and the ARIN logo are registered trademarks 2005 Statistics . 23 Reg. U.S. Pat. & Tm. Off. oward the end of 2005, ARIN marked its eighth year of operation and service to the Internet community. Throughout its existence, there have been many changes both within the ARIN region and throughout the Internet as a whole, while at the same time ARIN’s mission has remained the same. Our Tcommitments to stewardship of Internet number resources and providing registration, organizational, and policy facilitation services have never been stronger. One of the most recent major changes took place in April 2005, when ICANN officially recognized AfriNIC as the fifth Regional Internet Registry. Encompassing the entire continent of Africa, AfriNIC now covers a region previously served by APNIC, ARIN, and the RIPE NCC.
    [Show full text]
  • Securing Networks with Mikrotik Router OS
    Securing Networks with Mikrotik Router OS Speaker: Tom Smyth, CTO Wireless Connect Ltd. Location: New Orleans Date: 28-09-2012 1 ©2006-2012 WirelessConnect.eu Wireless Connect Ltd. ✔Irish Company Incorporated in 2006 ✔Operate an ISP in the centre of Ireland. ✔Good Infrastructure Expertise. ✔ Certified MikroTik Partners ✔Training ✔Certified OEM Integrators ✔Consultants ✔Value Added Reseller 2 ©2006-2012 WirelessConnect.eu Speaker Profile: ✔Studied BEng. Mechanical & Electronic Engineering, DCU,Ireland ✔Has been working in Industry since 2000 ✔Server Infrastructure Engineer ✔Systems / Network Administrator ✔Internet Security Consultant ✔1st MikroTik Certified Trainer in June 2007 in Ireland 3 ©2006-2012 WirelessConnect.eu Security Information sources ✔ENISA –http://www.enisa.europa.eu/ ✔OWASP http://owasp.org ✔Rits Group – http://www.ritsgroup.com/ ✔ISAS – http://www.isas.ie/ ✔SANS Institute – http://sans.org ✔CIS Centre for Internet Security – http://cisecurity.org/ ✔NIST Computer Security http://csrc.nist.gov/ ✔Open BSD – http://OpenBSD.org/ ✔Spamhaus.org – http://spamhaus.org ✔nmap.org – http://nmap.org ✔ha.ckers.org – http://ha.ckers.org/ 4 ©2006-2012 WirelessConnect.eu Router OS ✔Highly Versatile ✔Highly Customisable ✔Highly Cost Effective ✔Allows one to manage Security Threats in many Ways 5 ©2006-2012 WirelessConnect.eu What Can MikroTik Router OS Do ? ✔It is a Stateful Firewall ✔It is a Web Proxy ✔It is a Socks Proxy ✔It is a DNS Cache / Proxy ✔It is a Router ✔It is an IPSEC Concentrator ✔It is an IDS – Intrusion Detection System
    [Show full text]
  • Guidelines for the Secure Deployment of Ipv6
    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
    [Show full text]
  • Ipv6, the DNS and Big Packets
    IPv6, the DNS and Big Packets Geoff Huston, APNIC The IPv6 Timeline… 2010 1990 2000 2020 The IPv6 Timeline… Yes, we’ve been working on this for close to 30 years! 2010 1990 2000 2020 The IPv6 Timeline… Yes, we’ve been working on this for close to 30 years! 2010 1990 2000 2020 In-situ transition… In-situ transition… Phase 1 – Early Deployment IPv4 Internet Edge Dual -Stack Networks IPv6 networks interconnect by IPv6-over-IPv4 tunnels In-situ transition… Phase 2 – Dual Stack Deployment Transit Dual-Stack Networks Edge Dual-Stack Networks IPv6 networks interconnect by Dual Stack transit paths In-situ transition… Phase 3 – IPv4 Sunset IPv6 Internet Edge Dual Stack Networks IPv4 networks interconnect by IPv4-over-IPv6 tunnels We are currently in Phase 2 of this transition Some 15% - 20% of Internet users have IPv6 capability Most new IP deployments use IPv6+ (NATTED) IPv4 IPv4-only Legacy networks are being (gradually) migrated to dual stack The Map of IPv6 penetration – August 2017 The Map of IPv6 penetration – August 2017 We are currently in Phase 2 of this transition Some 15% of Internet users have IPv6 capability Most new IP deployments use IPv6 IPv4-only Legacy networks are being (gradually) migrated to dual stack Today We appear to be in the middle of the transition! Dual Stack networks use apps that prefer to use a IPv6 connection over an IPv4 connection when both are available (*) This implies that the higher the IPv6 deployment numbers the less the level of use of V4 connection, and the lower the pressure on the NAT binding clients * Couple of problems with this: This preference is often relative, and in the quest for ever faster connections the ante keeps rising – Apple is now pressing for a 50ms differential.
    [Show full text]
  • Ipv6 Addressing and Basic Connectivity Configuration Guide Cisco IOS Release 15.1SG
    IPv6 Addressing and Basic Connectivity Configuration Guide Cisco IOS Release 15.1SG Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • Ipv6: the Next Generation Internet Protocol 2
    GENERAL I ARTICLE IPv6: The Next Generation Internet Protocol 2. New Features in IPv6 Harsha Srinath IPv4, the workhorse protocol of the currently popular TePI IP protocol suite, is fast becoming obsolete. The exponen­ tial growth of the Internet is the main reason that has required the creation of the next generation of Internet Protocol-IPv6. IPv6 is ~uch more flexible and promises to take care of the address space and security issues in the Harsha Srinath is currently pursuing his MS foreseeable future. degree in Computer Science at the Center for In this part we explain the new features introduced in the Advanced Computer emerging Internet Protocol standard and why they have Studies (CACS) in been introduced. University of Louisiana at Lafayette, USA. His Birth of IPv6 research interests include networking with an As mentioned in Part 11 of the paper, the growth of the global emphasis on wireless Internet was exponential since its inception in the 1980's. The networks, distributed databases and data designers of this Internet Protocol (lPv4) never envisioned the mining. scale of the Internet, nor could they imagine its potential for growth. Unfortunately, this unprecedented growth apart from benefiting millions of users was not without ill consequences. It posed a potential threat that a day might come when virtually all Part 1, IPv4 and its shortcom­ IP address are exhausted. Further, with increasing monetary ings, Resonance, Vol.8, NO.3, pp.33-41,2003. transactions being done using the Internet, there was a need for more security features in the Internet Protocol. A development of a potential solution for this problem began during the late 1990s;The creation of a new version of the Internet Protocol, IPv6, the next-generation Internet Protocol (IPng), was approved by the Internet Engineering Steering Keywords Group on November 17, 1994 as a proposed standard.
    [Show full text]
  • Internet Routing Registry Introduction • Presenters Objectives
    Welcome to the Internet Routing Registry APRICOT 2007, Bali, Indonesia 27 February, 2007 APNIC and RIPE NCC 1 Introduction • Presenters – Caz Merrison <[email protected]> • RIPE NCC Training Officer – Miwa Fujii<[email protected]> • APNIC Research and Development Training Officer 2 Objectives • To provide an introduction to the APNIC Routing Registry – Explain basic concepts of the global RR – Outline the benefits of the APNIC Routing Registry – A chance for practical exercise • NOT to: – Teach basic routing – Explain Internet resource policy and procedures – Provide advise on network configuration 3 1 Assumptions • The audience – Knowledgeable about BGP routing – Familiar with basic APNIC database operations – Curious about Internet Routing Registry usage (IRR) – But not yet familiar with Routing Policy Specification Language (RPSL) and IRR 4 Schedule • What is APNIC • Specifying routing • What is RIPE policies using RPSL • APNIC db recap • RPSL in practice • DB protection – Case studies – AS-sets, grouping peers • What is an IRR – Bogon filtering • Documenting policy • RtConfig • RPSL introduction • IRR Toolset 5 What is APNIC? • Regional Internet Registry (RIR) for the Asia Pacific region – One of five RIRs currently operating around the world – Non-profit, membership organisation • Open participation, democratic, bottom-up processes – Responsible for distributing Internet resources throughout the AP region • Industry self-regulatory body – Consensus-based, open, and transparent decision- making and policy development • Meetings and mailing
    [Show full text]
  • ICMP for Ipv6
    ICMP for IPv6 ICMP in IPv6 functions the same as ICMP in IPv4. ICMP for IPv6 generates error messages, such as ICMP destination unreachable messages, and informational messages, such as ICMP echo request and reply messages. • Information About ICMP for IPv6, on page 1 • Additional References for IPv6 Neighbor Discovery Multicast Suppress, on page 3 Information About ICMP for IPv6 ICMP for IPv6 Internet Control Message Protocol (ICMP) in IPv6 functions the same as ICMP in IPv4. ICMP generates error messages, such as ICMP destination unreachable messages, and informational messages, such as ICMP echo request and reply messages. Additionally, ICMP packets in IPv6 are used in the IPv6 neighbor discovery process, path MTU discovery, and the Multicast Listener Discovery (MLD) protocol for IPv6. MLD is used by IPv6 devices to discover multicast listeners (nodes that want to receive multicast packets destined for specific multicast addresses) on directly attached links. MLD is based on version 2 of the Internet Group Management Protocol (IGMP) for IPv4. A value of 58 in the Next Header field of the basic IPv6 packet header identifies an IPv6 ICMP packet. ICMP packets in IPv6 are like a transport-layer packet in the sense that the ICMP packet follows all the extension headers and is the last piece of information in the IPv6 packet. Within IPv6 ICMP packets, the ICMPv6 Type and ICMPv6 Code fields identify IPv6 ICMP packet specifics, such as the ICMP message type. The value in the Checksum field is derived (computed by the sender and checked by the receiver) from the fields in the IPv6 ICMP packet and the IPv6 pseudoheader.
    [Show full text]