 The migration to IP version 6 based NGN is a very important and desirable thing to discuss. The reason is IP version 6 is going to stay inshallah. We have been with IP version 4 for a very long time, but IP version 4 suffered from something known as the Roads problem that is running out address space. So we look at the need for IP version 6 migration to NGN as a specific focus, we look at the approaches that could possibly be taken and the phases in which this is going to happen. The need for migration cannot be overemphasized, it's very obvious that NGN is based on the packet communication, either IP version 4 or IP version 6, IP version 6 being more desirable. So it means the long-term NGN is expected to be based upon IP version 6. There are certain features which essentially turn out to be advantageous with regards to the operation in NGN. These include simplified header format, so many of the fields in IP version 4 were obviated. Then the addressing scheme was expanded from 32-bit to 128-bit. The auto-configuration such as a zero-conf or no-conf were introduced. This helps the IP version 6 network to be self-sustaining or self-configurable. Then unlike IP version 4, quality of service could be implemented in IP version 6 with relatively more ease because we have the concept of something known as a flow. Then we have the security implementation that has also been made convenient through IPsec, particularly the application header and encapsulation payload. Then using the concept of IP in IP, in fact, if you are using the option of next header IP in IP in IP in IP, you can think about providing mobility support with much more ease in IP version 6. So once we are planning to migrate to IP version 6, NGN, we can appreciate three relationships that we have to take care of. The first one is the relationship between the end user functions and the transport stratum. Since there are a variety of technologies which are quite heterogeneous, so we need interfaces belonging to each network type. Then we have the second relationship between the end user functions and the application services. So IPv6-based applications and services have to have a direct interface or interaction with the applications and services in NGN. And thirdly, we have the requirement to have an established explicit relationship between the core network or you can say the transport stratum as such and the application and services. This means that we can think about now some interesting approaches to achieve migration. The first one is probably quite redundant and heavy but easiest to implement and very straightforward, that is dual IP layer, IP version 4 and version 6 stacks are implemented both on each and every network equipment at the distribution side, the edge of the network and the end user equipment. The second option is basically translation that whenever a packet leaves or exits the IP version 4 network, 2 IP version 6 or vice versa, certain address or protocol translation has to take place. For that, different research proposals and prototypes were put forth, for instance, stateless IP, ICMP, network address translation, port translation and then something known as the bump in the stack which is a transport level interaction translation from IP version 4 to version 6 and vice versa. Then we have something known as the bump in API that is the application level translation that takes place above the IP version 4, version 6 placement. And lastly, the IP and IP concept of tunneling can be incorporated to allow the migration to take place from steadily from IP version 4 to version 6, essentially for NGN. Now the phases are going to be very intuitive. First of all, we can think about phase 0, which is let's say the starting point. Once we have no IP version 6 networks, so the NGN is only going to be based upon IP version 4. In phase 1, IP version 6 is introduced, although very sparingly and IP version 6 NGNs are connected across IP version 4 based NGNs. So it means the IP version 6 routers are on the stub side and the core and the distribution or the edge, if you may, are based upon IP version 4. Then we can think about moving to the dual stack implementation once IP version 4 and IP version 6 based networks are comparable in numbers. So what we can allow the end user equipment and NGNs is to help to facilitate them by looking at the logical partitioning of version 4 and version 6 stacks. So this is a logical implementation. It means each device is going to implement both of these. So NGN devices at any layer can access both of these transparently. And then we are going to move on to a better situation once we have an overwhelming number of NGN networks, which are IP version 6 based. And here slowly IP version 4 based routers are reducing in number. So we can expect the IP version 4 based NGNs to be on the across side or the stub side and on the core and the distribution side, we are expecting more IP version 6 NGNs to be present. And lastly, we can anticipate, we can hope for an all IP version 6 based NGN environment in which pull migration has taken place.