Presentation is loading. Please wait.

Presentation is loading. Please wait.

Hierarchical IPv4 Framework Patrick Frejborg 18 Dec 2009.

Published byPhoenix Alliston Modified over 10 years ago

Similar presentations

Presentation on theme: "Hierarchical IPv4 Framework Patrick Frejborg 18 Dec 2009."— Presentation transcript:

1 Hierarchical IPv4 Framework Patrick Frejborg pfrejborg@gmail.com 18 Dec 2009

2 Why hIPv4 ? Addressing RFC 4984 It is commonly recognized that today’s Internet routing and addressing system is facing serious scaling problems. The ever increasing user population, as well as multiple other factors including multi-homing, traffic engineering, and policy routing, have been driving the growth of the Default Free Zone (DFZ) routing table size at an increasing and potentially alarming rate. While it has been long recognized that the existing routing architecture may have serious scalability problems, effective solutions have yet to be identified, developed, and deployed.

3 Influence sources The Locator/Identifier Separation Protocol research work at RRG MPLS solutions, mainly the shim header that made it possible to create new services on top of an IP backbone Anycast Rendezvous Point (RP) with Multicast Source Discovery Protocol (MSDP) PSTN hierarchical numbering scheme Active participants on the RRG mailing-list Multipath enabled transport protocols, SCTP and MTCP

4 Adding scalability by introducing hierarchy in the address space Global Locator Block (GLB)  An IPv4 address block that is globally unique. Area Locator (ALOC)  An IPv4 address assigned to locate an ALOC realm in Internet. The ALOC is assigned by a RIR to a service provider or a multi-homed enterprise. The ALOC is globally unique because it is allocated from the GLB. Endpoint Locator (ELOC)  An IPv4 address assigned to locate an endpoint in an ALOC realm. The ELOC block is assigned by a RIR to a service provider or to an enterprise. The ELOC block is only unique in a geographical region or globally unique in a business area defined by the RIRs. The final policy of uniqueness shall be defined by the RIRs.

5 The hIPv4 header IPv4 header still valid, new IP option added – idea similar as in MPTCP and RFC1385 New IP option called locator header

6 Fundamental elements ALOC realm  An area in the Internet with at least one attached Locator Swap Router (LSR), also an ALOC must be assigned to the ALOC realm. The RIB of an ALOC realm holds both local ELOC prefixes and global ALOC prefixes. An ALOC realm exchanges only ALOC prefixes with other ALOC realms. Locator Swap Router (LSR)  A router or node which is capable to process the hIPv4 header; once the header is processed the LSR will forward the packet upon the IPv4 destination address. The LSR must have the ALOC assigned as its locator.

7 LSR per packet tasks (the swap) verify the received packet that it uses the locator header ID in the IP option field verify IP and transport header checksums replace the source address in the IPv4 header with the ALOC value of the locator header replace the destination address in the IPv4 header with the ELOC value of the locator header replace the ALOC value in the locator header with the destination IP address of the IPv4 header replace the ELOC value in the locator header with the source IP address of the IPv4 header set the S-field to 1 decrease TTL value with one calculate IP and transport protocol checksums forward the packet upon the destination IP address of the IPv4 header No FIB nor cache required at the LSR

8 Life of a hIPv4 session

9 Client -> server www.foo.com? A-record: 10.2.2.2 ALOC: 172.16.0.5 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 S:172.16.0.3 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:10.2.2.2 S:172.16.0.3 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:10.2.2.2 IPv4 API IPv4 header Locator header

10 Client -> server, return path A:172.16.0.3 E:10.2.2.2 S:172.16.0.5 D:10.1.1.1 A:172.16.0.3 E:10.2.2.2 S:172.16.0.5 D:10.1.1.1 S:10.2.2.2 D:172.16.0.3 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 S:10.2.2.2 D:172.16.0.3 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 IPv4 API IPv4 header Locator header

11 Multi-homing and impact on DFZ

12 The new routing architecture Advertizing whole RIB of the ALOC realm, generating 0.0.0.0/0 towards DFZ Advertizing only ALOC prefixes 172.16.0.5 /32 172.16.0.1 /32 172.16.0.4 /32 172.16.0.5 /32 10.1.1.0 /24 172.16.0.5 /32 172.16.0.1 /32 172.16.0.4 /32 172.16.0.5 /32 172.16.0.5 /32 172.16.0.1 /32 172.16.0.4 /32 172.16.0.5 /32 10.2.2.0 /24

13 Multi-homing becomes multi-pathing www.foo.com? A-record: 10.2.2.2 ALOC: 172.16.0.5 ALOC: 172.16.0.4 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.5 E:10.1.1.1 S:172.16.0.3 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.4 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.4 A:172.16.0.4 E:10.1.1.1 S:172.16.0.3 D:10.2.2.2 New subflow Policy-based routing, Valiant load-balancing IPv4 API IPv4 header Locator header

14 Integrating hIPv4 with map-and- encapsulate solutions

15 Fundamental elements Three types of locator is needed  Endpoint Locator, ELOC (regionally unique)  Area Locator, ALOC (globally unique)  Routing Locator, RLOC (globally unique) DNS need to have two new records, for ALOC and RLOC but an endpoint have only one type of record (ALOC or RLOC) in DNS MPTCP is used to achieve new type of multi-homing at hIPv4 enabled sites, i.e. migrating from multi-homing to multi-pathing ITR/ETR should support MPTCP and the hIPV4 framework Outcome is that the Internet citizen can choose the upgrade path that is most convenient for him Note! Scenario not yet documented in draft-frejborg-hipv4!

16 Legacy client -> hIPv4 server S:10.1.1.1.1 D:10.2.2.2 Mapping Request Where is 10.2.2.2? www.foo.com? A-record: 10.2.2.2 A:192.168.0.1 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 Reply ALOC 172.16.0.5 ALOC 172.16.0.4 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 IPv4 API IPv4 header Locator header S:10.1.1.1 D:10.2.2.2

17 Legacy client -> hIPv4 server, return path S:10.1.1.1.1 D:10.2.2.2 Mapping Request Where is 10.2.2.2? www.foo.com? A-record: 10.2.2.2 A:192.168.0.1 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 Reply ALOC 172.16.0.5 ALOC 172.16.0.4 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 S:10.2.2.2 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 IPv4 API IPv4 header Locator header S:10.1.1.1 D:10.2.2.2 S:10.2.2.2 D:10.1.1.1

18 Legacy client -> hIPv4 server, adding MPTCP subflow S:10.1.1.1.1 D:10.2.2.2 Mapping Request Where is 10.2.2.2? www.foo.com? A-record: 10.2.2.2 A:192.168.0.1 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 Reply ALOC 172.16.0.5 ALOC 172.16.0.4 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 A:192.168.0.1 E:10.2.2.2 S:10.1.1.1 D:172.16.0.4 A:172.16.0.4 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 A:172.16.0.4 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 IPv4 API IPv4 header Locator header S:10.1.1.1 D:10.2.2.2

19 hIPv4 client -> legacy server S:10.2.2.2 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 www.foo.com? A-record: 10.1.1.1 RLOC:192.168.0.1 RLOC:192.168.0.2 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 IPv4 API IPv4 header Locator header S:10.2.2.2 D:10.1.1.1

20 hIPv4 client -> legacy server, return path S:10.2.2.2 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 www.foo.com? A-record: 10.1.1.1 RLOC:192.168.0.1 RLOC:192.168.0.2 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 S:10.1.1.1 D:10.2.2.2 A:192.168.0.1 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 IPv4 API IPv4 header Locator header S:10.1.1.1 D:10.2.2.2 S:10.2.2.2 D:10.1.1.1 S:10.1.1.1 D:10.2.2.2

21 hIPv4 client -> legacy server, adding MPTCP subflow S:10.2.2.2 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 www.foo.com? A-record: 10.1.1.1 RLOC:192.168.0.1 RLOC:192.168.0.2 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.4 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.4 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 IPv4 API IPv4 header Locator header S:10.2.2.2 D:10.1.1.1

22 The new routing architecture 172.16.0.3 /32 172.16.0.4 /32 172.16.0.5 /32 10.1.1.0 /24 192.168.0.0 /21 192.168.8.0 /21 192.168.16.0 /21 172.16.0.3 /32 172.16.0.4 /32 172.16.0.5 /32 10.2.2.0 /24 192.168.0.0 /21 192.168.8.0 /21 192.168.16.0 /21 Advertizing whole RIB of the ALOC realm, generating 0.0.0.0/0 towards DFZ Advertizing only ALOC prefixes

23 Multicast

24 Multicast considerations Source address (S) for a group (G) is no longer visible outside the local ALOC realm (only GLB prefixes are seen), therefore Reverse Path Forwarding (RPF) is only valid within the local ALOC realm In order to enable RPF globally for a (S,G), the multicast enabled LSR (mLSR) must at the source ALOC realm replace the source address with the local ALOC identifier LSR in the source ALOC realm shall act as an Anycast RP with MSDP capabilities The mLSR will decide which multicast groups are announced to other ALOC realms The receiver will locate the source via MSDP, the shared tree can be established to the mLSR Source Specific Multicast schema will need an extension, ALOC options shall be added to SSM

25 Multicast forwarding S:10.1.1.1 G:225.5.5.5 A:172.16.0.3 E:10.1.1.1 S:172.16.0.3 D:225.5.5.5 S:10.1.1.1 D:225.5.5.5 A:172.16.0.3 l E:10.1.1.1 S:172.16.0.3 D:225.5.5.5 A:172.16.0.3 E:10.1.1.1 S:172.16.0.3 D:225.5.5.5 S:10.1.1.1 D:225.5.5.5 A:172.16.0.3 E:10.1.1.1 IPv4 API IPv4 header Locator header

26 RTCP receiver reports S:10.1.1.1 G:225.5.5.5 S:10.2.2.2 D:172.16.0.3 A:172.16.0.5 E:10.1.1.1S:172.16.0.5 D:10.1.1.1 A:172.16.0.3 E:10.2.2.2 S:10.2.2.2 D:172.16.0.3 A:172.16.0.5 E:10.1.1.1 S:172.16.0.5 D:10.1.1.1 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:225.5.5.5 IPv4 API IPv4 header Locator header

27 Mobility

28 Mobility considerations Site mobility: a site wishes to changes its attachment point to the Internet without changing its IP address block  The change of attachment point is possible when PI addresses are allocated to the site. Only ALOC prefix(es) needs to be changed at the endpoints. Endpoint mobility: an endpoint moves relatively rapidly between different networks, changing its IP layer network attachment point  SCTP or MPTCP is providing “session mobility” on the transport layer Mobile site: mobile vehicles that are crossing RIR boundaries and the vehicle (e.g. aircraft, train, ferry etc) carries a local network.  Depending upon forthcoming RIR policies, NAT might be needed, see following slides

29 Mobile site: client -> server behind NAT S:10.2.2.2 D:192.168.1.1 PLR: 111 A:172.16.0.3 E:10.2.2.2 S:172.16.0.5 D:10.1.1.1 S:10.2.2.2 D:192.168.1.1 S:10.2.2.2 D:172.16.0.3 PLR: 111 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 IPv4 API IPv4 header Locator header S:10.2.2.2 D:172.16.0.3 PLR: 111 A:172.16.0.5 E:10.1.1.1 www.foo.com? A-record: 10.1.1.1 ALOC: 172.16.0.3 PLR: 111 A-record: 10.3.3.3 ALOC: 172.16.0.1 PLR: 111

30 Mobile site: client -> server behind NAT, return path S:10.2.2.2 D:192.168.1.1 PLR: 111 A:172.16.0.3 E:10.2.2.2 S:172.16.0.5 D:10.1.1.1 S:10.2.2.2 D:192.168.1.1 S:10.2.2.2 D:172.16.0.3 PLR: 111 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 IPv4 API IPv4 header Locator header S:10.2.2.2 D:172.16.0.3 PLR: 111 A:172.16.0.5 E:10.1.1.1 www.foo.com? A-record: 10.1.1.1 ALOC: 172.16.0.3 PLR: 111 A-record: 10.3.3.3 ALOC: 172.16.0.1 PLR: 111 S:192.168.1.1 D:10.2.2.2 PLR: 111 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 PLR: 111 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 PLR: 111 A:172.16.0.5 E:10.1.1.1 S:172.16.0.3 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2

31 Mobile site: client -> server behind NAT, adding subflow IPv4 API IPv4 header Locator header www.foo.com? A-record: 10.1.1.1 ALOC: 172.16.0.3 PLR: 111 A-record: 10.3.3.3 ALOC: 172.16.0.1 PLR: 111 S:192.168.1.1 D:10.2.2.2 PLR: 111 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 PLR: 111 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 PLR: 111 A:172.16.0.5 E:10.1.1.1 S:172.16.0.3 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 PLR: 111 A:172.16.0.1 E:10.2.2.2 S:10.3.3.3 D:172.16.0.5 PLR: 111 A:172.16.0.5 E:10.3.3.3 A:172.16.0.1 E:10.2.2.2

32 Mobile site: client -> server behind NAT, roaming completed IPv4 API IPv4 header Locator header www.foo.com? A-record: 10.1.1.1 ALOC: 172.16.0.3 PLR: 111 A-record: 10.3.3.3 ALOC: 172.16.0.1 PLR: 111 S:192.168.1.1 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 PLR: 111 A:172.16.0.1 E:10.2.2.2 S:10.3.3.3 D:172.16.0.5 PLR: 111 A:172.16.0.5 E:10.3.3.3 A:172.16.0.1 E:10.2.2.2

33 Mobile site: client behind NAT -> server A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 S:192.168.1.1 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 IPv4 API IPv4 header Locator header www.foo.com? A-record: 10.2.2.2 ALOC: 172.16.0.5 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.5 E:10.1.1.1 A:172.16.0.3 E:10.2.2.2 A:0.0.0.0 E:10.2.2.2 S:192.168.1.1 D:172.16.0.5

34 Mobile site: client behind NAT -> server, adding subflow A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 S:192.168.1.1 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 IPv4 API IPv4 header Locator header www.foo.com? A-record: 10.2.2.2 ALOC: 172.16.0.5 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.5 E:10.1.1.1 A:172.16.0.3 E:10.2.2.2 A:0.0.0.0 E:10.2.2.2 S:192.168.1.1 D:172.16.0.5 A:172.16.0.1 E:10.2.2.2 S:10.3.3.3 D:172.16.0.5 A:172.16.0.5 E:10.3.3.3 S:172.16.0.1 D:10.2.2.2 S:10.3.3.3 D:10.2.2.2

35 Mobile site: client behind NAT -> server, roaming completed S:192.168.1.1 D:10.2.2.2 IPv4 API IPv4 header Locator header www.foo.com? A-record: 10.2.2.2 ALOC: 172.16.0.5 A:0.0.0.0 E:10.2.2.2 S:192.168.1.1 D:172.16.0.5 A:172.16.0.5 E:10.3.3.3 S:172.16.0.1 D:10.2.2.2 S:10.3.3.3 D:10.2.2.2 A:172.16.0.1 E:10.2.2.2 S:10.3.3.3 D:172.16.0.5

36 Traffic Engineering

37 Traffic Engineering considerations Load balancing is influenced by the placement of LSRs within a ALOC realm; LSR provides a “nearest routing” scheme A service provider might have several ALOC assigned; traffic engineering and filtering can be done upon ALOC addresses If needed an ALOC identifier based Traffic Engineering solution might be developed. Establish explicit routing paths upon ALOC prefixes, that is create explicit paths that can be engineered via specific ALOC realms. Valiant Load-Balancing can be added, more studies is required around this technology

38 Summary

39 Cost and issues Upgrade of the stack at an endpoint or the endpoint should make use of an ITR/XTR In a multi-homing solution the border routers should be able to apply policy based routing upon the ALOC value in the locator header New policies must be set by the RIRs Short timeframe before the expected depletion of the IPv4 address space occurs Will enterprises give up their global allocation of the current IPv4 address block they have gained? Co-ordination with MPTCP is highly desirable

40 Carrots for everyone Enterprises  No need to learn a totally new protocol  Minimize porting of applications to a new protocol, IPv4 socket API is extended  Achieve site mobility  MPTCP and SCTP supports endpoint mobility  Remove IPv4 address constraints Internet Service Providers  No need to learn new routing protocols  Remove IPv4 address constraints  Hierarchical routing architecture, smaller RIB for each ALOC realm  Internal prefix flaps are not seen in other ALOC realms, only GLB state changes are reflected globally – “update churn” is reduced

Download ppt "Hierarchical IPv4 Framework Patrick Frejborg 18 Dec 2009."

Similar presentations

Architectural Approaches to Multi-Homing for IPv6 A Walk-Through of draft-huston-multi6-architectures-00 Geoff Huston June 2004.

Architectural Approaches to Multi-Homing for IPv6 A Walk-Through of draft-huston-multi6-architectures-00 Geoff Huston June 2004.
1 An Update on Multihoming in IPv6 Report on IETF Activity IPv6 Technical SIG 1 Sept 2004 APNIC18, Nadi, Fiji Geoff Huston.

1 An Update on Multihoming in IPv6 Report on IETF Activity IPv6 Technical SIG 1 Sept 2004 APNIC18, Nadi, Fiji Geoff Huston.
LISP Mobile Node LISP Mobile Node draft-meyer-lisp-mn-00.txt Dino Farinacci, Vince Fuller, Darrel Lewis and David Meyer IETF StockholmHiroshima LISP Working.

LISP Mobile Node LISP Mobile Node draft-meyer-lisp-mn-00.txt Dino Farinacci, Vince Fuller, Darrel Lewis and David Meyer IETF StockholmHiroshima LISP Working.
M2M Architecture Inge Grønbæk, Telenor R&I ETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007.

M2M Architecture Inge Grønbæk, Telenor R&I ETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007.
MPLS VPN.

MPLS VPN.
Chapter 1: Introduction to Scaling Networks

Chapter 1: Introduction to Scaling Networks
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.24-1 MPLS VPN Technology Introducing the MPLS VPN Routing Model.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v MPLS VPN Technology Introducing the MPLS VPN Routing Model.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.24-1 MPLS VPN Technology Introducing MPLS VPN Architecture.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v MPLS VPN Technology Introducing MPLS VPN Architecture.
IPv4 to IPv6 Network Address Translation. Introduction 4 What is the current internet addressing scheme and what limitations does it face. 4 A new addressing.

IPv4 to IPv6 Network Address Translation. Introduction 4 What is the current internet addressing scheme and what limitations does it face. 4 A new addressing.
1 Network Address Translation (NAT) Relates to Lab 7. Module about private networks and NAT.

1 Network Address Translation (NAT) Relates to Lab 7. Module about private networks and NAT.
A Hierarchical IPv4 Framework Patrick Frejborg 24 Feb 2009.

A Hierarchical IPv4 Framework Patrick Frejborg 24 Feb 2009.
Ch. 23, 25 Q and A (NAT and UDP) Victor Norman IS333 Spring 2014.

Ch. 23, 25 Q and A (NAT and UDP) Victor Norman IS333 Spring 2014.
Why do current IP semantics cause scaling issues? −Today, “addressing follows topology,” which limits route aggregation compactness −Overloaded IP address.

Why do current IP semantics cause scaling issues? −Today, “addressing follows topology,” which limits route aggregation compactness −Overloaded IP address.
Internetworking II: MPLS, Security, and Traffic Engineering

Internetworking II: MPLS, Security, and Traffic Engineering
Introduction to IPv6 Presented by: Minal Mishra. Agenda IP Network Addressing IP Network Addressing Classful IP addressing Classful IP addressing Techniques.

Introduction to IPv6 Presented by: Minal Mishra. Agenda IP Network Addressing IP Network Addressing Classful IP addressing Classful IP addressing Techniques.
Future Directions For IP Architectures Ipv6 Cs686 Sadik Gokhan Caglar.

Future Directions For IP Architectures Ipv6 Cs686 Sadik Gokhan Caglar.
IPv4 - IPv6 Integration and Coexistence Strategies Warakorn Sae-Tang Network Specialist Professional Service Department A Subsidiary.

IPv4 - IPv6 Integration and Coexistence Strategies Warakorn Sae-Tang Network Specialist Professional Service Department A Subsidiary.
IPv6 The New Internet Protocol Integrated Network Services Almerindo Graziano.

IPv6 The New Internet Protocol Integrated Network Services Almerindo Graziano.
Transitioning to IPv6 April 15,2005 Presented By: Richard Moore PBS Enterprise Technology.

Transitioning to IPv6 April 15,2005 Presented By: Richard Moore PBS Enterprise Technology.
TCOM 509 – Internet Protocols (TCP/IP) Lecture 06_b Subnetting,Supernetting, CIDR IPv6 Instructor: Dr. Li-Chuan Chen Date: 10/06/2003 Based in part upon.

TCOM 509 – Internet Protocols (TCP/IP) Lecture 06_b Subnetting,Supernetting, CIDR IPv6 Instructor: Dr. Li-Chuan Chen Date: 10/06/2003 Based in part upon.

Similar presentations

Ads by Google