DOCSLIB.ORG

Mobile IP Constraints

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

EvolutionEvolution ofof thethe InternetInternet CoreCore andand EdgeEdge IPIP WirelessWireless NetworkingNetworking USENIX Annual Technical Conference June 28, 2001 Boston, MA JimJim BoundBound PrinciplePrinciple MemberMember ofof TechnicalTechnical StaffStaff [email protected]@compaq.comom CharlieCharlie PerkinsPerkins NokiaNokia FellowFellow charliepcharliep@@iprgiprg..nokianokia.com.com 1 DiscussionDiscussion § Internet and Current Wireline IP Evolution § Wireless Evolution § IPv6 Evolution § Mobile IP Evolution § The Future: Wireless and Wireline Integrated 2 Internet and Current Wireline IP Evolution 3 InternetInternet CoreCore andand EdgeEdge Edge Communications Core Communications 4 InternetInternet AccessAccess PointPoint End User Wireline Internet Edge and Core Internet Services Workstation Workstation Workstation Access Points Access Points Wireless IP SS7 IP Gateway Gateway Comm. Tower Comm. Tower Comm. Tower 5 End User Wireless End User Telephony InternetInternet CharacterizationCharacterization TodayToday § Virtual Private Networks – Tunnels – Private Addresses – Secure at Edge or Access Only § Network Address Translation (NAT) Required § End-2-End Model is Lost § Try getting a Globally Routable IPv4 Address in Europe or Asia; or a set of them for your business !!! § These are not optimal conditions for the evolution of the Internet 6 InternetInternet engineersengineers areare workingworking onon itit !!!!!! § The Next Generation Internet Protocol is IPv6 and will restore the End-2-End model of the Internet § 2.5G and 3G Wireless requires the End-2-End model as it moves its use model to the Internet. § Mobile IP computing will revolutionize the Internet as the WEB did in the 90’s. § So lets discuss how this will happen!!! 7 Wireless Evolution 8 WirelessWireless EvolutionaryEvolutionary StagesStages Timeline Today 2002-2003 2003+ 2G 2.5G 3G GSM GPRS UMTS TDMA TDMA CDMA 1G CDMA CDMA 3G IPv4/IPv6 Mobile IPv6 2G 2.5G 3G IS-41 CDMA200 Full IP Voice 1XRTT Data 2.MB+ Digital Voice Digital Voice IP Transports + Analog Voice Data 100K+ Data 19.2K Gateways Voice Some IP Gateways Data 2MB 9 GSMGSM ArchitectureArchitecture PSTN ISDN Modem Bank PDN MS BTS MSC GMSC Modem Bank MS BTS BSC Modem Bank BTS EIR MS AUC HLR VLR 10 GSM/GPRSGSM/GPRS SystemSystem ArchitectureArchitecture PLMN’s PSTN SGSN GGSN ISDN Modem Bank MS BTS PDN Modem Bank BTS MS BSC Modem Bank BTS Other MS PLMN’s HLR EIR MSC/VLR User Plane AUC Control Plane 11 3G3G WirelessWireless ArchitectureArchitecture HLR/VLR Subscriber, Radio Access Network Policy, AAA, and Security Services Services Wireless Nodes Modem Bank Voice, Video, and Gaming Services Comm. Tower Internet Comm. Tower Core/Edge Comm. Tower Radio Access SGSN and GGSN and Comm. Tower Network Control Services Services Base Stations Other ISP Control Plane Services Server Content and User Plane Gateway Services Internet Plane 12 WhatWhat aboutabout thethe TelephoneTelephone NetworkNetwork Today?Today? § Circuit Based not Packet Based § Signal and Voice Channels for communications § These networks are evolving to IP § But IP will have to coexist with the Signaling System #7 Protocol for coexistence § So we need to discuss in this Wireless model briefly too !!! § Because it has Internet Engineering work in process too 13 SS7SS7 andand thethe WirelineWireline NetworkNetwork SCPSCP SCPSCP STPSTP STPSTP IPIP SS7 SS7 Links SSP SSPSSP SSP Voice Trunks 14 SS7SS7 andand thethe WirelessWireless NetworkNetwork SMSCSMSC HLRHLR AUCAUC EIREIR STPSTP STPSTP VLRVLR SS7 SS7 Links MSCMSC MSCMSC Comm. Tower Comm. Tower 15 IETFIETF SIGTRANSIGTRAN protocolsprotocols suitesuite § SCTP – Set of functions for reliable signaling transport § M2UA M2UAMGCP/MEGACO/H.248M3UA SUA IUA – transport the MTP2 user (MTP3) over IP SCTP § M3UA – transport the MTP3 users (SCCP, IP ISUP) over IP § SUA Physical – transport the SCCP user (TCAP) over IP § IUA – transport the ISDN signaling (Q.931) over IP 16 SCTPSCTP WhatWhat isis it?it? § New Transport Protocol and architectural peer component to TCP and UDP above the IP network Layer § It is NOT an application protocol or replacement for UDP or TCP § Architected to be transparent to IPv4 or IPv6 network layer component § IETF recommendations RFC 2960 17 Where SCTP will be added to a typical IP stack Internet Server Applications Network Utilities Autoconfiguration of Addresses RSVP DNS Network Mgmt Routing Mgmt Neighbor Processing Tunnel Configuration RSVP APIs Network APIs System Kernel APIs Socket Layer Protocol Control Blocks Transport Layer TCP/UDP + SCTP***** IPv4/IPv6 Routing Routing and Neighbor Caches Network Layer, ICMP, and Virtual Tunnel Interfaces IPv4 Module Callout Switch Firewall Screening IPv4 IPv4/IPv6 RSVP/QOS Processing IPv4/IPv6 ARP IPv4 Neighbor Discovery IPv6 Network Interface Control, Adapter Interfaces and Processing Queues, Mgmt, and Statistics 18 IPv6 Evolution 19 IPv4…IPv4… AA victimvictim ofof itsits ownown successsuccess § 1990 – IPv4 addresses being consumed at an alarming rate, projections show: § Class B address space exhausted by 1994 § All IPv4 address space exhausted between 2005 - 2011 – Internet routing tables suffering explosive growth – Efforts started to address these problems 20 InterimInterim measuresmeasures § CIDR (Classless Inter-Domain Routing) – Eased routing table growth for awhile – Multihoming punching holes in CIDR today § Private addresses – Reduced pressure on address space, but… – Necessitated NAT, ALGs – Obstacle to renumbering § Example: merger of 2 companies using net 10 – Additional management burden 21 NATNAT (Network(Network AddressAddress Translation)Translation) § Single point of failure § Performance penalty § Breaks applications that rely on End-2-End IP addressing (FTP, DNS, others) – Use ALGs § Prevents End-2-End IPsec 22 ALGsALGs (Application(Application LayerLayer Gateways)Gateways) § Example: www proxy servers § Single point of failure § Performance penalty § Requires detailed knowledge of each application – Barrier to deployment of new applications § Barrier to growth 23 InterimInterim measuresmeasures helped,helped, but…but… § Address space consumption slowed, but Internet growth accelerated § 1B mobile users by 2003 § 1B Internet users by 2005 § 90% of all new mobile phones will have internet access by 2003 (Morgan Stanley Dean Witter, May 2000) § Projections of address space exhaustion by 2010, pain sooner (Europe and Asia) 24 …… aa longerlonger termterm solutionsolution waswas soughtsought § 1991: Work starts on next generation Internet protocols – More than 6 different proposals were developed § 1993: IETF forms IPng Directorate – To select the new protocol by consensus § 1995: IPv6 selected – Evolutionary (not revolutionary) step from IPv4 § 1996: 6Bone started § 1998: IPv6 standardized § Today: Initial products and deployments 25 GrowthGrowth ofof wirelesswireless andand broadbandbroadband InternetInternet 1 Billion Subscribers WIRELESSWIRELESS && BroadbandBroadband InternetInternet Server-based 1 Billion Users Applications 300 Million Subscribers Switched Networks Market Size WIRELESSWIRELESS INTERNETINTERNET 200 Million Users 26 Source Cisco Systems 1998 2005 IPv6IPv6 ImmediateImmediate BenefitsBenefits § Increased Address Space – 128 bits § 2^128 is a really big number – Efficient addressing and routing topology – NAT is not required § Restores End-2-End IP addressing § And while we’re at it, we might as well make a few other improvements… 27 IPv6IPv6 ImmediateImmediate BenefitsBenefits (continued)(continued) § Architecture – Simplified IP header – Optimized for 64 bit architecture – Efficient and extensible IP datagram – Improved host and router discovery – Improved multicast scalability § Plug and Play – Dynamic Address Autoconfiguration (Stateless, Stateful) 28 IPv6IPv6 ImmediateImmediate BenefitsBenefits (continued)(continued) § Enhancements for dynamic renumbering of networks § Improved Mobile IP support § Mandatory network-layer authentication and privacy § Coexists with IPv4 § Other functions still evolving from the extensibility of the architecture 29 IETFIETF StandardizationStandardization statusstatus ofof IPv6IPv6 § Core specifications achieved Draft Standard status No No Yes RFC Yes RFC Yes RFC Internet Proposed Draft Internet Draft Standard Standard Standard Technically Multiple Significant complete Interoperable Operational Implementations Experience 6bone test bed Today 1991 1996 1998 timeline IPv6IPv6 IndustryIndustry DeploymentDeployment StatusStatus § Many products and Early Adopters kits available § Internet Registries are handing out IPv6 addresses. § Internet Service Providers are starting to provide IPv6 § IPv6 Forum (http://www.ipv6forum.com) – World-wide consortium including vendors and research/education community, to promote IPv6 by raising market and user awareness 31 IPv4IPv4 vs.vs. IPv6IPv6 HeaderHeader 0 bits 8 16 24 31 0 4 12 16 24 31 Ver IHL Service Type Total Length Version Class Flow Label Identifier Flags Fragment Offset Payload Length Next Header Hop Limit Time to Live Protocol Header Checksum 32 bit Source Address 128 bit Source Address 32 bit Destination Address Options and Padding IPv4 Header 128 bit Destination Address 20 octets, 12 fields, including 3 flag bits + fixed max number of options Changed Removed IPv6 Header 40 octets, 8 fields + Unlimited Chained Extension (options) Header 32 What has happened to our beloved IP stack? Internet Server Applications Network Utilities Autoconfiguration of Addresses RSVP DNS Network Mgmt Routing Mgmt Neighbor Processing
Recommended publications
  • Kirjoituspohja VTT Science

    Kirjoituspohja VTT Science

    IENCE C • •S T S E C Small world for dynamic wireless cyber-physical N O H I N systems S O I V Dissertation L • O S 142 G T Y H • R Industries and consumer markets are today increasingly using G I E L VTT SCIEN CE S H E G services exposed from wireless sensor and actuator networks, A I R H C cyber-physical machine-to-machine systems. The motivation for H the research arises from problems detected in the remote 1 4 2 interaction with embedded devices over dynamic wireless networks in such systems. The selected approach is based on the application of the small- world paradigm to cyber-physical systems. It is here assumed that the concept of small world, "six degrees of separation", can be expanded to also cover communication with wireless embedded devices in cyber-physical systems context. The main contributions are the technical enablers referred to as dynamic communication spaces, dynamic M2M service spaces, configuration and remote use of services, communication overlay, access systems selection, integrated mobility, secure ad hoc networking, situated opportunistic communication, hierarchical networking for small-world networks, and short-cuts for network optimization. The enablers have been evaluated as separate technical methods and means by means of experiments and/or simulations. According to the evaluations, the enablers seem to work well as separate building blocks and that they can be combined to expand the concept of small world to also cover communication with embedded devices. Wireless short-cuts can improve the scalability and efficiency of dynamic wireless networking and weak links are essential in the neighbour discovery process.
  • QUESTION 20-1/2 Examination of Access Technologies for Broadband Communications

    QUESTION 20-1/2 Examination of Access Technologies for Broadband Communications

    International Telecommunication Union QUESTION 20-1/2 Examination of access technologies for broadband communications ITU-D STUDY GROUP 2 3rd STUDY PERIOD (2002-2006) Report on broadband access technologies eport on broadband access technologies QUESTION 20-1/2 R International Telecommunication Union ITU-D THE STUDY GROUPS OF ITU-D The ITU-D Study Groups were set up in accordance with Resolutions 2 of the World Tele- communication Development Conference (WTDC) held in Buenos Aires, Argentina, in 1994. For the period 2002-2006, Study Group 1 is entrusted with the study of seven Questions in the field of telecommunication development strategies and policies. Study Group 2 is entrusted with the study of eleven Questions in the field of development and management of telecommunication services and networks. For this period, in order to respond as quickly as possible to the concerns of developing countries, instead of being approved during the WTDC, the output of each Question is published as and when it is ready. For further information: Please contact Ms Alessandra PILERI Telecommunication Development Bureau (BDT) ITU Place des Nations CH-1211 GENEVA 20 Switzerland Telephone: +41 22 730 6698 Fax: +41 22 730 5484 E-mail: [email protected] Free download: www.itu.int/ITU-D/study_groups/index.html Electronic Bookshop of ITU: www.itu.int/publications © ITU 2006 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. International Telecommunication Union QUESTION 20-1/2 Examination of access technologies for broadband communications ITU-D STUDY GROUP 2 3rd STUDY PERIOD (2002-2006) Report on broadband access technologies DISCLAIMER This report has been prepared by many volunteers from different Administrations and companies.
  • Ipv6 Security: Myths & Legends

    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
  • Mobile IP Administration Guide

    Mobile IP Administration Guide

    Mobile IP Administration Guide Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303-4900 U.S.A. Part Number 806-6542–10 January 2001 Copyright 2001 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303-4900 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and SunTM Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
  • Guidelines for the Secure Deployment of Ipv6

    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.
  • Ipv6, the DNS and Big Packets

    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.
  • Mobile IP Versus Ipsec Tunneling with MOBIKE: a Comparison Under Wireless Vertical Handover with NS-2

    Mobile IP Versus Ipsec Tunneling with MOBIKE: a Comparison Under Wireless Vertical Handover with NS-2

    ENSC835: COMMUNICATION NETWORKS SPRING 2011 FINAL PROJECT Mobile IP versus IPsec Tunneling with MOBIKE: A Comparison Under Wireless Vertical Handover With NS-2 http://www.sfu.ca/~cdk4 Christopher Kilgour 301106137 [email protected] Team #1 Abstract Mobile devices are increasingly including support for multiple heterogeneous wireless networks like 3G cellular, 4G, and IEEE 802.11. When an IP-equipped mobile device attaches to a network, it typically obtains a temporary network address allocated by the visited network provider. One approach to provide a permanent IP address to a mobile device is Mobile IP. Mobile IP has some objectionable aspects: it often requires network provider support, and it can drop data during vertical handover. IPsec tunneling with IKEv2 Mobility and Multihoming Protocol (MOBIKE) may be used as an alternative to Mobile IP. IPsec tunnels do not require any special support from the network provider. Because it supports multi-homing, MOBIKE can provide make-before-break operation, eliminating the data interruption during vertical handover. The ns-2 simulation tool is enhanced, and a comparison of vertical handover scenarios is performed, in this report. Table of Contents Introduction.....................................................................................................................................................4 IP Mobility And Tunneling............................................................................................................................5 Mobile IP....................................................................................................................................................5
  • Secure Firewall Traversal in Mobile IP Network

    Secure Firewall Traversal in Mobile IP Network

    Secure Firewall Traversal in Mobile IP Network Jung-Min Park1, Min-Jung Jin2, and Kijoon Chae2 1 Intelligent System Control Research Center, KIST, Korea [email protected] 2 Department of Computer Science and Engineering, Ewha Womans Univ., Korea {mjjin,kjchae}@ewha.ac.kr Abstract. With recent advances in wireless communication technology, mobile computing is an importance research area. Mobile IP is designed to provide IP services to roaming nodes. Mobile users take advantage of this protocol to ob- tain the services as if they were connected to their home network. In many cases mobile users is connected through a wireless link and is protected by corpora- tion’s firewall in virtual private network. In order to have a successful deploy- ment of Mobile IP as an extension of a private network, security services should be provided as if the mobile node were attached to its home network. In this pa- per, we propose the security mechanism of combining Mobile IP and IPSec tun- nels, which can provide secure traversal of firewall in a home network. The simulation results show that the proposed mechanism provides the secure and efficient communication. 1 Introduction Mobility in IP networks is a significant issue due to the recent increase of many port- able devices such as notebook and PDA and the development of wireless network interface. Many popular applications such as E-commerce and remote access require transmission of highly sensitive information, often over wireless links. Mobility im- plies higher security risk than static operation in fixed network, because the traffic may at times take unexpected network paths with unknown or unpredictable security characteristics.
  • Ipv6 Addressing and Basic Connectivity Configuration Guide Cisco IOS Release 15.1SG

    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.
  • Ipv6 Configuration Guide, Cisco IOS XE Everest 16.5.1A (Catalyst 3850 Switches)

    Ipv6 Configuration Guide, Cisco IOS XE Everest 16.5.1A (Catalyst 3850 Switches)

    IPv6 Configuration Guide, Cisco IOS XE Everest 16.5.1a (Catalyst 3850 Switches) First Published: 2017-05-31 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 © 2017 Cisco Systems, Inc. All rights reserved. CONTENTS CHAPTER 1 Configuring MLD Snooping 1 Finding Feature Information 1 Information About Configuring IPv6 MLD Snooping 1 Understanding MLD Snooping 2 MLD Messages 3 MLD Queries 3 Multicast Client Aging Robustness 4 Multicast Router Discovery 4 MLD Reports 4 MLD Done Messages and Immediate-Leave 4 Topology Change Notification Processing 5 How to Configure IPv6 MLD Snooping 5 Default MLD Snooping Configuration 5 MLD Snooping Configuration Guidelines 6 Enabling or Disabling MLD Snooping on the Switch (CLI) 6 Enabling or Disabling MLD Snooping on a VLAN (CLI) 7 Configuring a Static Multicast Group (CLI) 8 Configuring a Multicast Router Port (CLI) 9 Enabling MLD Immediate Leave (CLI) 10 Configuring MLD Snooping Queries (CLI) 10 Disabling MLD Listener Message Suppression (CLI) 12 Displaying MLD Snooping Information 13 Configuration Examples for Configuring MLD Snooping 13 Configuring a Static Multicast Group: Example 13 Configuring a Multicast Router Port: Example 14 Enabling MLD Immediate Leave: Example 14 IPv6 Configuration Guide, Cisco IOS XE Everest 16.5.1a (Catalyst 3850 Switches) iii Contents Configuring MLD Snooping Queries: Example 14 CHAPTER 2 Configuring IPv6 Unicast Routing 15 Finding Feature Information 15
  • Ipv6: the Next Generation Internet Protocol 2

    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.
  • Large Scale Addressing and Routing Mechanisms for Highly Mobile Networks of Networks Sofiane Imadali

    Large Scale Addressing and Routing Mechanisms for Highly Mobile Networks of Networks Sofiane Imadali

    Large scale addressing and routing mechanisms for highly mobile networks of networks Sofiane Imadali To cite this version: Sofiane Imadali. Large scale addressing and routing mechanisms for highly mobile networks ofnet- works. Other. Université Paris Sud - Paris XI, 2015. English. NNT : 2015PA112049. tel-01180150 HAL Id: tel-01180150 https://tel.archives-ouvertes.fr/tel-01180150 Submitted on 24 Jul 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. UNIVERSITE PARIS-SUD ÉCOLE DOCTORALE : STITS DIASI, LIST, Laboratoire des Système Communicants (LSC) THÈSE DE DOCTORAT Discipline: Sciences de l'information et de la communication soutenue le 02/04/2015 par Sofiane IMADALI ALGORITHMES D'ADRESSAGE ET ROUTAGE POUR DES RÉSEAUX FORTEMENT MOBILES À GRANDE ÉCHELLE Directeur de thèse : Véronique Vèque Professeur à l’université de Paris-Sud Encadrant CEA : Alexandre Petrescu Ingénieur-chercheur au CEA-Saclay Composition du jury : Rapporteurs : Yacine Ghamri-Doudane Professeur à l’université de La Rochelle Jérome Haerri Maitre de conférences, HDR à Eurecom Président du jury : Samir Tohme Professeur à l’université de Versailles (UVSQ) Examinateurs : Anthony Busson Professeur à l’université de Lyon 1 Anne Fladenmuller Maitre de conférences, HDR Université Paris 6 (UPMC) Abstract After successfully connecting machines and people later (world wide web), the new era of In- ternet is about connecting things.