Transition & Coexistence IPv4-IPv6

Transcription

1 Mar02 ransition & Coexistence - Case studies & Conclusions Francisco Fontes 13 March

2 resentation contents Introduction ransition mechanisms organisation Case studies Host-to-Network communication Network-to-Network communication Network Level services: QoS, Mobility Application level services IRC Example: company network migration Conclusions 2

3 Classification of ransition Mechanisms Several techniques have been defined to support the transition towards an all- Internet: Dual Stack techniques, allowing and to coexist in devices and networks; Layer 2 supporting infra-structure, allowing native communication to co-exist with communication (AM, FR, MLS,...) ranslation allows and devices and networks to establish communication Network layer SII, NA- Upper layers ALG, R, SOCKS64, BIS, BIA unnelling/encapsulation allows end-to-end communication between devices and networks Configured tunnels Automatic tunnels unnel broker 6to4 6over4 eredo 3

4 LONG Main Objectives Define and deploy an test-bed network, which includes the combination and exploitation between the following technologies: rotocol Advanced Network Services: DNS, Mobility, Multicast, Anycast Security, QoS, Auto-configuration - ransition Mechanisms Access and ransport echnologies Applications and services based on protocol and on / mixed scenarios 4

5 LONG est-bed ADSL Cabe Router CAV Cable Network (DOCSIS) Routing or bridge mode CMS Servers Access System LONG Network Clients Router b Bridg b ISDN Swicth Copper Access Network Wireless ISDN ADSL Router Copper Access Network DSLAM Ethernet Router AM Swicth AM Network Servers AM Interconnection Services 5

6 Isolated host-to-net communication -only host NA-, R, SOCKS64 (requires sockification ) -only host 6

7 Isolated host-to-net communication -only host -only host NA-, R, SOCKS64 (requires sockification ) Configured tunnels, unnel Broker Automatic unnels (requires - compatible addresses) 6to4 (use globally unique 6to4 prefix) 6over4 (multicast required in the net.) NA-, R, SOCKS64 (requires sockification ) Dual stack host SOCKS64, R and NA- are applicable to the same scenarios and seem to be the most versatile mechanisms NA-, R, SOCKS64 (requires sockification ) DSM (requires DSM server and 4over6 encapsulation) Dual stack host 7

8 Network-to-Network communication 8

9 Network-to-Network communication DSM (requires DSM server, 4over6 encapsulation and starts comm.) Configured tunnels NA- (not recommended) SOCKS64 (multiple chained NA-, SOCKS64, R relay) 9

10 Network-to-Network communication DSM (requires DSM server, 4over6 encapsulation and starts comm.) Configured tunnels NA- (not recommended) SOCKS64 (multiple chained NA-, SOCKS64, R relay) Configured unnels, unnel Broker, Automatic unnels (requires -compatible addresses) 6to4 (use globally unique 6to4 prefix) 6over4 (multicast required in the net.; not recommended) NA- (but not expected) SOCKS64 (multiple chained relay) 10

11 Network-to-Network communication DSM (requires DSM server, 4over6 encapsulation and starts comm.) Configured tunnels NA- (not recommended) SOCKS64 (multiple chained NA-, SOCKS64, R relay) Configured unnels, unnel Broker, Automatic unnels (requires -compatible addresses) 6to4 (use globally unique 6to4 prefix) 6over4 (multicast required in the net.; not recommended) NA- (but not expected) SOCKS64 (multiple chained relay) DSM (requires DSM server, 4over6 encapsulation and starts comm.) NA- SOCKS64 R (but not expected) 11

12 Network-to-Network communication DSM (requires DSM server, 4over6 encapsulation and starts comm.) Configured tunnels NA- (not recommended) SOCKS64 (multiple chained NA-, SOCKS64, R relay) Configured unnels, unnel Broker, Automatic unnels (requires -compatible addresses) 6to4 (use globally unique 6to4 prefix) 6over4 (multicast required in the net.; not recommended) NA- (but not expected) SOCKS64 (multiple chained relay) DSM (requires DSM server, 4over6 encapsulation and starts comm.) NA- SOCKS64 R (but not expected) 12

13 QoS (I) DiffServ [RFC2475] adopted as the basis for e2e QoS comparison DiffServ concepts are applicable to both protocol versions: classification, shaping, metering, marking, dropping & scheduling (see [RFC2474]) Routers in both v4 and v6 must implement the technology, making usage of OS in and raffic Class in wo possible scenarios for QoS in - transition: In association to a ranslation Mechanism (A) In association to a unnelling Mechanism (B) 13

14 QoS (II) ranslation mechanisms & QoS (A) ranslate OS field to raffic Class field ranslate raffic Class field to OS field In both situations If different networks correspond to different domains, the translator must also implement DS border functions Issue addressed in ranslation Mechanisms (NA-/SII) OS NA- C +Classification +Shaping +Metering +Marking +Dropping +scheduling 14

15 QoS (III) unnelling mechanisms & QoS (B) How will the outer packet () have a correct treatment with the DSC field in the inner packet ()? he C field in the inner packet must be copied to the OS field at network ingress It makes possible to use DiffServ implementations while ones are not available DSC field may change inside the domain Issue not addressed by unnelling Mechanisms 15

16 I Mobility Mobile I has implementations for both and Concepts and required entities are similar but M presents some improvements relatively to the v4 standard (for example regarding triangle-routing) I Mobility adoption in real scenarios is growing BU all transition mechanisms assume devices are static inside some or network Is there any solution for I Mobility in transition scenarios? Discovery, Registration & unnelling operations are supported? MN, HA, HN, FA, FN, COA, CN will interoperate and be valid? Recent drafts RFC appeared addressing this topic Almost all require Dual-stack MN roposals for new entities are introduced M operates similar to, in several situations (no BC in - only hosts) 16

17 I Mobility between same I version A.1 H- CNv4 A.2 MNv6 F- MNv4 H- F- CNv6 No problem for mobility! Just use an appropriate tunnelling mechanism B.1 B.2 H- M CNv6 MNv6 F- M MNv4 H- F- M M CNv4 If MN is single stack ( or ) mobility is only possible between networks having the same I version! Use M mechanisms like SII or NA- MN sends M or M registration messages to the HA If MN is double-stack, DSM can also be used with Binding restrictions 17

18 I Mobility between and C.1 MN DS H- M F- M CNv6 C.2 MN DS H- M F- M CNv4 Dual-stack MN is required C.1: New entity introduced (draft-engelstad-ngtrans-mipv4- over-mipv6-01.txt): Dual Stack Mobility Agent (DSMA) Mobility reduced to M functionality ( connectivity) May operate in the HN as (DS)HA or (DS)FA or in the FN as a (DS)FA Requires that M registration requests include Address Extension DSMA may also be used with 6to4 (as well as Automatic unnelling) 18

19 Case studies: Application Level Services Requests for new End user Applications & Services represent a major driver for deployment (taking benefit from always-on facility, for instance) Besides network level services (QoS, Mobility,...), application level services operation (F, Web, Mail, LDA,...) must be guaranteed (while implementations should be migrated to ) is supported by all major terminal Operating Systems (Windows, Solaris, FreeBSD, Linux) Services transition phases: Use upper layer translation mechanisms (like BIS and BIA) ort server applications to Run server applications in dual-stack hosts Other M will be required to give access to the server, depending in the network I version the server and the clients are placed 19

20 Client Server service architectures Scenario: Client-server services used in full /v6 communication configurations here is at least one implementation for the following service servers and clients: F, Mail, News, IRC, LDA, DNS, DHC Some of these services require Application Level Gateways (e.g DNS and F) Server M Server Client M M Client 20

21 IRC scenario (I) Objective: o allow seamless communication between and IRC clients No ALG required for IRC Simplest scenario: Dual-stack server accepting connections from both and clients IRC Client socket opened to accept connection in all interfaces can also accept packets /v6 IRC Server IRC Client 21

22 IRC scenario: Servers At UC3M site: alarcan & matrix, - only, and mira, -only, servers R connects mira to alarcan; NA- was a possibility but R (FreeBSD faithd) was used instead, only for the required communication port (C 7000) It must be the IRC server establishing the connection to the IRC server (faithd limitation) connection matrix () UC3M mira R translator connection alacran () At UM site: malpica viena (/) connection viena, Dual-stack, accepts connections from and clients; malpica, - only, connects to viena and accepts connections from -only clients UM 22

23 IRC scenario: Clients UC3M will access to alacran using an client (for example, xchat is supported form version 1.8) UM will access to viena using an client ID will access mira using an client IN will access viena using an client he rest of the partners can choose what protocol and server they can use connection matrix () UC3M mira R translator connection alacran () malpica viena (/) connection UM 23

24 Example: Company network evolution towards IS Internet NA/ /FW he company has three sites communicating through dedicated lines (L2) Actually, the company only runs hosts and applications Access to Internet, mail and other company services is made at the central site he company wants to deploy a strategy towards a full operation and seeks for an IS Addressing: Internal private addressing Servers: all native Clients: all native Internet: Access: through NA and FW (routing and DNS are not addressed) 24

25 Step I: First local tests IS Internet NA/ /FW BR erform first tests selecting or deploying a new network section to deploy Dual-stack and -only hosts; this section is likely to be connected by a Dual-stack router (Border Router) Dual-stack servers should also be deployed, serving as servers for Dual-stack hosts and also as relay for servers ( official company servers); hosts may also experiment to connect to servers Use NA- to connect this network section Servers can also use R to connect to other company servers 25

26 Step II: Start internal and external remote connections IS Internet BR NA/ /FW BR Start deploying remote connectivity over the internal infra-structure Keep previous translation mechanisms and start using appropriate tunnelling mechanisms he company intends to start connections to external networks, like 6Bone; the actual IS still does not provide connectivity Use a configured tunnel or 6to4 (may require current firewall conf. or install a new firewall) 6Bone 26

27 Step III: Create extranets with partners IS Internet NA/ /FW BR BR One of the sites is completely moved to (using both Dual-stack and -only hosts) DSM can de used at that site, as well as any other M to connect to other islands; translation is required to reach hosts and servers (if those are not isolated Dual-stack nodes) islands of interest start to appear in the Internet, maybe belonging to external partners; extranets may/must now be established; 6to4 is the adopted mechanism 6Bone 27

28 Step IV: becomes the main protocol IS IS Internet sites NA/ /FW BR Company servers are migrated to Dual-stack or -only; now -only devices (hosts and servers) represent an island inside the company network or are isolated hosts; BIS may be required; BIA may also be used At this time it may be expected that a native IS may appear and, besides native access to Internet sites, Multi-homing can also be tested 28

29 Final situation At this phase the company has moved completely to, even if it may exist some islands in the Internet IS NA/ /FW NA- at these networks entry-points should be used Internet 29

30 Additional aspects But, what about required native network management?... -VN services at L2 and L3? IS NA/ /FW... Applications and services or I version independent ones?... Hardware acceleration for? Internet 30

31 Conclusions Most of the existing ransition Mechanisms are devoted to the end-to-end transmission of packets in an routing environment All transition mechanisms require at least one dual-stack device in communication path (end-points or terminals) Even if covers almost all basic aspects (even improving most of them), actual ransition Mechanisms do not fully support all of the advanced network services: Connectivity and application operation is well supported Advanced network aspects, like QoS, Mobility and Security are not fully supported or are impossible to be deployed 31

32 Conclusions oday s experience, do not fully guarantee that ranslation do not have unknown effects on aplics & servs running between end-points with different I versions; in the same way, unelling may take to unexpected network effects on aplics & servs usage even if transparent to I versions from end-points point-of-view Where protocol translation is necessary, translators operating at upper layer should be used; I-layer protocol translators should be used when there is no alternative 6to4 encapsulating mechanism is one of the most flexible Anyway, today we have good conditions to start migrating to, running real services 32

33 HANK YOU!! Francisco Fontes 33