Sunday, January 29, 2012

Transition from IPv4 to IPv6


The Internet Protocol is the foundation of the TCP/IP protocol suite and the Internet, and thus somewhat comparable to the foundation of a house in terms of its structural importance. Given this, changing IP is somewhat analogous to making a substantial modification to the foundation of your house. Since IP is used to connect together many devices, it is in fact, like changing not just your house, but every house in the world!

How do you change the foundation of a house? Very carefully. The same caution is required with the implementation of IPv6. While to most people IPv6 is something “new”, the reality is that the planning and development of IPv6 has been underway for nearly a full decade, and if we were starting from scratch the protocol would have been ready for action years ago. However, there is a truly enormous installed base of IPv4 hardware and software. This means the folks who develop TCP/IP could not just “flip a switch” and have everyone move over to using IPv6. Instead, a transition from IPv4 to IPv6 had to be planned.


IPv4-IPv6 Transition: Differences of Opinion
The transition is already underway, though most people don't know about it. As I said, development of IPv6 itself is pretty much complete, though work continues on refining the protocol and also on development of IPv6-compatible versions of other protocols. The implementation of IPv6 began with the creation of development networks to test IPv6's operation. These were connected together to form an experimental IPv6 internetwork called the 6BONE (which is a contraction of the phrase “IPv6 backbone”.) This internetwork has been in operation for several years.
Experimental networks are well and good, but of course the big issue is transitioning the “real” Internet to IPv6—and here, opinion diverges rather quickly. In one camp are the corporations, organizations and individuals who are quite eager to transition to IPv6 quickly, to gain the many benefits it promises in the areas of addressing, routing and security. Others are taking a much more cautious approach, noting that the dire predictions in the mid-1990s of IPv4's imminent doom have not come to pass, and arguing that we should take our time to make sure IPv6 is going to work on a large scale.
These two groups will continue to play tug-of-war for the next few years, but it seems that the tide is now turning towards those who want to speed up the now-years-long transition. The move towards adoption of IPv6 as a production protocol is being spearheaded by a number of groups and organizations. IPv6 has a lot of support in areas outside the United States, many of which are running short of IPv4 addresses due to small allocations relative to their size. One such area is Asia, a region with billions of people, rapidly-growing Internet use and a shortage of IPv4 addresses.
Within the United States, which has the lion's share of IPv4 addresses (due to the Internet having been developed in the U.S.A.), there seems to be a bit less enthusiasm for rapid IPv6 deployment. Even here, however, IPv6 got a major “shot in the arm” in July 2003 when the United States Department of Defense (DoD) announced that starting in October of that year, it would only purchase networking products that included compatibility with IPv6. The DoD—which of course was responsible for the development of the Internet in the first place—hopes to be fully transitioned to IPv6 by 2008. This will likely have a big impact on the plans of other governmental and private organizations in the United States.
Of course, the creators of IPv6 knew from the start that transition was going to be an important issue with the new protocol. IPv6 is not compatible with IPv4 because the addressing system and datagram format are different. Yet the IPv6 designers knew that since the transition would take many years, it was necessary that they provide a way for IPv4 and IPv6 hosts to interoperate. Consider that in any transition there are always “stragglers”. Like the old Windows 3.11 PC in the corner that you still need to use once in a while, even when most of the Internet is IPv6 there will still likely be some devices that are still on IPv4 because they were never upgraded.

IPv4-IPv6 Transition Methods
Due to the time that change takes, IETF has been working on specific provisions to allow a smooth transition from version 4 to version 6, and hardware and software interoperability solutions to let newer IPv6 devices access IPv4 hosts. A technique was included in IPv6 to allow administrators to embed IPv4 addresses within IPv6 addresses. Special methods are defined to handle interoperability, including:
  • “Dual Stack” Devices: Routers and some other devices may be programmed with both IPv4 and IPv6 implementations to allow them to communicate with both types of hosts.

  • IPv4/IPv6 Translation: “Dual stack” devices may be designed to accept requests from IPv6 hosts, convert them to IPv4 datagrams, send the datagrams to the IPv4 destination and then process the return datagrams similarly.

  • IPv4 Tunneling of IPv6: IPv6 devices that don't have a path between them consisting entirely of IPv6-capable routers may be able to communicate by encapsulating IPv6 datagrams within IPv4. In essence, they would be using IPv6 on top of IPv4; two network layers. The encapsulated IPv4 datagrams would travel across conventional IPv4 routers.
Bear in mind that these solutions generally only address backward compatibility, to allow IPv6 devices to talk to IPv4 hardware. Forward compatibility between IPv4 and IPv6 is not possible because IPv4 hosts cannot communicate with IPv6 hosts—they lack the knowledge of how IPv6 works. It is possible that certain special adaptations might be created to allow IPv4 hosts to access IPv6 hosts. But eventually, all IPv4 devices of any importance will want to migrate to IPv6.
The IETF has done such a good job in the past with introducing new technologies, and so much effort has been put into the IPv6 transition, that I am quite confident that the transition to IPv6 will come off with few, if any, problems. One good thing about the transition is that IPv4 is, at the present time, still getting the job done, so there is no big hurry to make the move to version 6. While technologies such as CIDR and NAT are “band-aids” on IPv4, they have been very successful ones in extending the useful life of the aging protocol.



IPv6 Addressing

The primary motivation for creating IPv6 was to rectify the addressing problems in IPv4. More addresses were required, but more than this, the IPv6 designers desired a way of interpreting, assigning and using them that was more consonant with modern internetworking. Based on this, it's no surprise that many of the changes in IPv6 are associated with IP addressing. The IPv6 addressing scheme is similar in general concept to IPv4 addressing, but has been completely overhauled to create an addressing system capable of supporting continued Internet expansion and new applications for the foreseeable future.
This section describes the concepts and methods associated with addressing under IPv6. I begin with a look at some addressing generalities in version 6, including the addressing model, address types size and address space. I discuss the unique and sometimes confusing representations and notations used for IPv6 addresses and prefixes. Then I look at how addresses are arranged and allocated into types, beginning with an overall look at address space composition and then the global unicast address format. I describe the new methods used for mapping IP addresses to underlying physical network addresses. I then describe special IPv6 addressing issues, including reserved and private addresses, IPv4 address embedding, anycast and multicast addresses, and autoconfiguration and renumbering of addresses.
Addressing under IPv6 is outlined in the main IPv6 RFC, RFC 2460 (Internet Protocol, Version 6 (IPv6) Specification). However, most of the details of IPv6 addressing are contained in two other standards: RFC 3513 (Internet Protocol Version 6 (IPv6) Addressing Architecture) and RFC 3587 (IPv6 Global Unicast Address Format). These replaced the 1998 standards RFC 2373 (IP Version 6 Addressing Architecture) and RFC 2374 (An IPv6 Aggregatable Global Unicast Address Format).

IPv6 Addressing Model and Address Types 

In the IPv6 overview section I explained that IPv6 represents a significant update to the Internet Protocol, but that its modifications and additions are made without changing the core nature of how IP works. Addressing is the place where most of the differences between IPv4 and IPv6 are seen, but the changes are mostly in how addresses are implemented and used. The overall model used for IP addressing in IPv6 is pretty much the same as it was in IPv4; some aspects have not changed at all, while others have changed only slightly.
Unchanged Aspects of Addressing in IPv6
Some of the general characteristics of the IPv6 addressing model that are basically the same as in IPv4:
  • Core Functions of Addressing: The two main functions of addressing are still network interface identification and routing. Routing is facilitated through the structure of addresses on the internetwork.

  • Network Layer Addressing: IPv6 addresses are still the ones associated with the network layer in TCP/IP networks, and are distinct from data link layer (also sometimes called physical) addresses.

  • Number of IP Addresses Per Device: Addresses are still assigned to network interfaces, so a regular host like a PC will usually have one (unicast) address, and routers will have more than one, for each of the physical networks to which it connects.

  • Address Interpretation and Prefix Representation: IPv6 addresses are like classless IPv4 addresses in that they are interpreted as having a network identifier part and a host identifier part, but that the delineation is not encoded into the address itself. A prefix length number, using CIDR-like notation, is used to indicate the length of the network ID (prefix length).

  • Private and Public Addresses: Both types of addresses exist in IPv6, though they are defined and used somewhat differently.
IPv6 Address Size and Address Space
Of all the changes introduced in IPv6, easily the most “celebrated” is the increase in the size of IP addresses, and as a result, the increase in the size of the address space as well. It's not surprising that these sizes were increased compared to IPv4—everyone has known for years that the IPv4 address space was too small to support the future of the Internet. What's remarkable is just how much the increase is, and what the implications are for how Internet addresses are used.
IPv6 Address Size
In IPv4, IP addresses are 32 bits long; these are usually grouped into four octets of eight bits each. The theoretical IPv4 address space is 232, or 4,294,967,296 addresses. To increase this address space we simply increase the size of addresses; each extra bit we give to the address size doubles the address space. Based on this, some folks expected the IPv6 address size to increase from 32 to 48 bits, or perhaps 64 bits. Either of these numbers would have given a rather large number of addresses.
However, IPv6 addressing doesn't use either of these figures; instead, the IP address size jumps all the way to 128 bits, or sixteen 8-bit octets/bytes. This represents a truly remarkable increase in the address size, which surprised a lot of people.
IPv6 Address Space
The 128 bits of IPv6 addresses mean the size of the IPv6 address space is, quite literally, astronomical; like the numbers that describe the number of stars in a galaxy or the distance to the furthest pulsars, the number of addresses that can be supported in IPv6 is mind-boggling. See Figure for an idea of what I mean by “astronomical”.

Figure : A (Poor) Representation of Relative IPv4 and IPv6 Address Space Sizes
I wanted to make a cool graphic to show the relative sizes of the IPv4 and IPv6 address spaces. You know, where I’d show the IPv6 address space as a big box and the IPv4 address space as a tiny one. The problem is that the IPv6 address space is so much larger than the IPv4 space that there is no way to show it to scale! To make this diagram to scale, imagine the IPv4 address space is the 1.6-inch square above. In that case, the IPv6 address space would be represented by a square the size of the solar system. J


Since IPv6 addresses are 128 bits long, the theoretical address space if all addresses were used is 2128 addresses. This number, when expanded out, is 340,282,366,920,938,463,463,374,607,431,768,211,456, which is normally expressed in scientific notation as about 3.4*1038 addresses. That's about 340 trillion, trillion, trillion addresses. As I said, it's pretty hard to grasp just how large this number is. Consider:
  • It's enough addresses for many trillions of addresses to be assigned to every human being on the planet.

  • The earth is about 4.5 billion years old. If we had been assigning IPv6 addresses at a rate of 1 billion per second since the earth was formed, we would have by now used up less than one trillionth of the address space.

  • The earth's surface area is about 510 trillion square meters. If a typical computer has a footprint of about a tenth of a square meter, we would have to stack computers 10 billion high blanketing the entire surface of the earth to use up that same trillionth of the address space.
Okay, I think you get the idea. It's clear that one goal of the decision to go to 128-bit addresses is to make sure that we will never run out of address space again, and it seems quite likely that this will be the case.

Why Were IPv6 Addresses Made So Large?
However, there are drawbacks to having such a huge address space too. Consider that even with a 64-bit address, we'd have a very large address space: 264 is 18,446,744,073,709,551,616 or about 18 million trillion, still probably more addresses than we will ever need. However, by going instead to 128 bits we have made dealing with IP addresses unruly (as we'll see in the next topic) and we have also increased overhead, since every datagram header or other place where IP addresses are referenced must use 16 bytes for each address instead of the 4 that were needed in IPv4, or the 8 that might have been required with a 64-bit address.
So why the “overkill” of going to 128 bits? The main reason is flexibility. Even though we can have a couple zillion addresses if we allocate them one at a time, that makes assignment difficult. We got rid of class-oriented addressing in IPv4 due to the fact that it wasted address space, which is true. The reality, though, is that being able to “waste” address space is a useful luxury.
Having 128 bits allows us to divide the address space and assign various purposes to different bit ranges while still not having to worry about running out of space. In the topic describing the IPv6 global unicast address format we'll see one way that those 128 bits are put to good use; it allows us to create a hierarchy of networks while still saving 64 bits for host IDs, which has its own advantages.



VMware vCenter - Alarm Network uplink redundancy lost


had similar issues as far as the network speed dropping to 10 or 100. First thing is that I make sure both sides are set to Auto if it's 1 GB links. Second, is that I have our hardware team reseat the cabling all the way back to the switch. 9/10 times that has resolved it. The root cause is usually the cabling was a little loose, not snapped all the way in, or the cable was bent forcing a pin or two to lose contact with the port.

In a few rare cases they were due to bad patch cables.

This may not be good for you since you only have 2 ports, but on our servers I've also modified the host profile to fail a port if the link speed is below 999MB, that way it forces all of the traffic over to the other port without dropping speed as the switches try to renegotiate.

Lost power or temporary power shortage on the network could also caused alarm Network uplink redundancy lost issue. Acknowledge and  reset to Green on Alarm messages. 

Monday, January 9, 2012

17 Roles and 41 Features


---------------------------------------------------------------------------------------------------
There are 17 Roles and 41 features listed in the Server Manager of the Windows Server 2008 R2.
The following server roles are available in Windows Server 2008 R2 Enterprise Edition.

17 Roles:
·         Active Directory Certificate Services
·         Active Directory Domain Services
·         Active Directory Federation Services
·         Active Directory Lightweight Directory Services
·         Active Directory Rights Management Services
·         Application Server
·         DHCP Server
          DNS Server
·         Fax Server
·         File Services
·         Hyper-V
·         Network Policy and Access Services
·         Print and Document Services
·         Remote Desktop Services
·         Web Server (IIS)
·         Windows Deployment Services
·         Windows Server Update Services

41 Features:
·         .NET Framework 3.5.1 Features
·         Background Intelligent Transfer Service (BITS)
·         BitLocker Drive Encryption
·         BranchCache
·         Connection Management Console
·         Desktop Experience
·         DirectAccess Management Console
·         Group Policy Management
·         Ink and Handwriting Services
·         Internet Printing Client
·         Internet Storage name Server
·         LPR Port Monitor
·         Message Queuing
·         Multipath I/O
·         Network Load Balancing
·         Peer name Resolution Protocol
·         Quality Windows Audio Video Experience
·         Remote Assistance
·         Remote Differential Compression
·         Remote Server Administration Tools
·         RPC over HTTP Proxy
·         Simple TCP/IP Services
·         SMTP Server
·         SNMP Services
·         Storage Manager for SANs
·         Subsystem for UNIX-based Applications
·         Telnet Client
·         Telnet Server
·         TFTP Client
·         Windows Biometric Framework
·         Windows Internal Database
·         Windows PowerShell Integrated Scripting Environment (ISE)
·         Windows Process Activation Service
·         Windows Server Backup Features
·         Windows Server Migration Tools
·         Windows System Resource Manager
·         Windows TIFF IFiliter
·         WinRM IIS Extension
·         WINS Server
·         Wireless LAN Service
·         XPS Viewer
---------------------------------------------------------------------------------------------------