|
|
|
|
An Analytical Business Performance Comparison of the IPv6 and IPv4 Protocols in Fixed and Mobile Communication Services
Prof. L-F Pau, Rotterdam School of Management, Netherlands; and Ericsson Core Networks, Sweden
Abstract
This paper gives an analytical business model comparison of the Internet IPv4 and IPv6 protocols, focussing on the business implications of intrinsic technical properties of these protocols .The technical properties modeled in business terms are: address space, payload, autoconfiguration, IP mobility, security, and flow label. Three operational cash flow focussed performance indexes are defined for respectively an Internet operator or ISP, for the address domain owner, and for the end user. Special considerations are made and modeling changes for mobile Internet traffic. The effects of technical innovation in the Internet services and protocols is taken into account, as are special considerations for N.A.T. and content owners. A numerical case is provided which mimics the current state of the Internet network and services ,and around which sensitivity analysis can be carried out, or such that additional service models can be added. It establishes in the Case the relative advantages or disadvantages of IPv4 and IPv6 for each of the three main parties, i.e. the ISP operator, the address domain owner, and the end user.
1 Introduction
Conceived in the mid-1990’s by pioneers and IETF (Internet engineering task force) under the term “Next generation Internet protocol” [1] ,standardized since by IETF [2] , promoted by the IPv6 Forum [3] and recommended as the base protocol from of Release 2 of the third generation mobile standards 3GPP [4], the Internet Protocol version 6 ( IPv6) protocol suite [2,5] has been heavily debated and evaluated in technical fora .In such technical circles , it has more and more believers and supporters , but also some opponents with arguments in the installed bases relying on the older Internet Protocol version 4 (IPv4) , and in migration costs or technical difficulties . However, the debate and analysis regarding the intrinsic business benefits of IPv6 in communication services is by and large totally absent, or at best based on conjectures from some technical properties and on some market forecasts types of statements. Even worse, the situation of such a debate and analysis is about the same in other sectors, such as the computer software industry, the consumer electronics industry, and content providers. Actual deployment is mapped out e.g. in [6].
The purpose of this paper is to attempt to propose a business characterization of the intrinsic business implications of IPv6, in comparison with the today dominating IPv4 protocol. The point of view is that of an enabling evolving technology affecting a wide range of products and services .The methodology is analytical, so users can carry out parametric studies for various deployment assumptions and scenarios .These business implications can either be:-socio-economic benefits : direct or indirect-innovation benefits: affecting existing products and services , or enabling new products and services with some characteristics falling into the two above categories .Policy implications [7] are beyond the scope of this paper , and should rely primarily on the socio-economic and innovation implications . Likewise, organizational implications are outside the scope of this paper, although ultimately IPv6 implications will drive organizational evolution .Likewise, this paper does not consider higher level routing, flow control , interaction, streaming , and management protocols [1,7,8] with can enhance or reduce specific information flow attributes (quantitative or qualitative) . Are only considered the lowest levels of the IP packets, which set the intrinsic traffic, and thus revenue /cost attributes before transformations.
2 Technical Protocol Characteristics
An Internet protocol (IP) is a standard for the structure of information packetized into packets of bits, which each have a tag or identifier called an address, and which can be sent, distributed and received while supporting end-to-end services with or without communication networks [5]. When networks are used, all nodes from source(s) to destination(s) must be able to packetize the digital information (i.e. transform larger information files or flows into smaller pieces called packets), and to re-assemble the packets into meaningful information, after transmission, switching or routing, and in all cases with management and control.
This Section aims solely at linking this paper with technical work or standards [2, 9, 10], through a set of technical attributes of IPv6 to be analyzed later in terms of the business implications. As IPv4 is assumed here to be the base technology, the technical attributes are those in comparison with the technical characteristics of IPv4. The main relative technical attributes of IPv6 versus IPv4 are:
a.Address space: IPv6 uses 128 bit addresses for each packet, creating a virtually infinite number of alternative fixed IP addresses (actually approx. 3, 4 * 10**38 IP addresses), as opposed to IPv4 which uses 32 bit addresses and can only accomodate approximately 4 Billion fixed IP addresses .These limits take into account the address hierarchies in IP, but not such walk-arounds as pre-assigned prefixes.
b.Packet payload : an Internet packet can contain meaningful information chunks (so called payload) .The number and size of these has some bounds set by the operating systems , the buffering in systems ,but by and large we can here make the simplifying assumption that payload characteristics for the same service with IPv4 and IPv6 are similar .
c.Security : IPv6 comes native with a security protocol called IPSECv6, whereas IPv4 needs IPSECv4 to be provisioned specially to have security at packet level, meaning that there is an overhead for IPv4 security.
d.Mobility (limited to a given piece of information assuming different identities or instances under the same control): IPv6 comes native with such a mobility feature called MobileIPv6, whereas IPv4 needs MobileIPv4 to be provisioned specially to support this type of mobility at packet level, meaning that there is an overhead for this type of IPv4 mobility. The overhead is both in installation (unless pre configured), in execution, and in above all in management. Please note that this specific mobility has nothing to do with mobility in wireless communication services [8] .Also MobileIPv6 does not need a foreign agent and is free from triangular routing, although of course IPv4 can be optimized separately to avoid such a triangular routing.
e.Autoconfiguration : if information is packetized into IPv6 packets, with the corresponding levels of control , then a neighbor discovery feature (care-of-address, and stateless Prefix or Stateful DHCPv6) will in principle allow the device carrying these packets to configure itself for a consistent dialogue with other devices or software interfaces [9] .The same can be done with IPv4 packets, but with the intervention of humans or specific tools and services ,and only for selected information and software architectures . f.Flow label: to each IPv6 packet payload is attached a tag which can be customized or not to enable a better quality in the packet flow, or to tag by a price or other class instance. This feature does not exist natively in IPv4, although part of payload could be used for the same, reducing unique information amount carried by the packet.
3 Business Values of IPv6 Technical Attributes
For each of the technical attributes surveyed in Section 2, an economic relation applies, for which a limited analytical modeling is given, with model properties:
The number of IPv4 addresses available is nearly exhausted as legal entities , systems and services have established ownership (usually de-facto as opposed to legal) of single or multiple addresses (called domains or sub-domains) .Many services now, and even more in the future, will require that everyone and every device /machine have one or several fixed IP addresses ,as opposed to the present Internet control whereby addresses are assigned to meet temporary situational requirements .The dilemma is comparable to the early days of telephony ,where there were party lines with several groups of people in the same community sharing the same telephone number ,and where operators put people in relation based on their numbers .Likewise, in the so called peer-to-peer concept , anyone or any device should be able to communicate directly with any other party without going through a server enacting control ,and there too own fixed IP addresses are needed .
The simplest economic model is thus one of a finite resource (IP address space) being exhausted by a flow of use with exponentially increasing value of the residual resource items, i.e. the individual IP addresses:
(Value (Address) (n+1)-Value (Address) (n))/Value(Address(n) )= kValAddress / (AddressCapacity- n) (Eq.1)
Where:-n is address number, initialized with Internet network service’s first use
-AddressCapacity is 2**32 in the IPv4 case, and 2**128 in the IPv6 case
-Value (Address (n)) is the market value of address number n
-kValAddress is a constant, protocol dependent
The same variables can have the protocol x=4, 6 as argument.
If we assume that:
-a user will want to migrate to an IPv6 address from an IPv4 address (assuming the same set of services and functionalities available) when say the residual IPv4 address capacity is kExhaust = æ exhausted, just to ensure service perenity ,
-and that address market values for IPv(4) and IPv(6) are then identical,
Then the following relations can be demonstrated by simple approximations owing to orders of magnitude in data:
((Val (n+1, 6)-Val (n, 6))/Val (n, 6) = kValAddress(6)/ (AddressCapacity(6) n(6)) (Eq 2)
Val (n+1, 4)/Val (n+1, 6) ~1+(kValAddress(4)/(1-kExhaust)*AddressCapacity(4)) (Eq 3)
This means that tangential address value slope ,at time of predicted address exhaust (set by kExhaust) is going to change from a high Val(Address(n,4)) slope to a lower Val(Address(n,6)) slope ,as IPv6 has at that time much larger residual capacity.
Assuming that the same network infrastructure ,control and management can handle IPv4 and IPv6 payloads, e.g. by the technique called tunnelling (2,5) whereby the packets obeying to one protocol are shuffled as payload inside the payload of another protocol , the handling cost of a packet (totally disconnected from the information/knowledge value it represents) should be such that the same information service should have the same handling cost although the number of packets (each with their respective overheads) can change, and that transmission capacity is assumed unlimited :
N (4)*Payload (4)) =N (6)*Payload (6) (Eq 4)
Where:
-N(x) is number of packets required by the service completion, with IPv(x) protocol
-Header(x) is the header (and equivalent) size for IPv(x protocol which here is only affecting transmission costs, supposed nil ;
-Payload(x) is the maximum information payload size for IPv(x) protocol
The handling cost for the completion of the same service operating on same content/information, should be proportional to the number of packets required, thus:
ServiceHandlingCost(x) = PacketHandlingCost x N(x) (Eq 5)
ServiceHandlingCost (6)/ServiceHandlingCost (4) = Payload(6)/Payload(4) (Eq 6)
Taking the least favourable case for IPv6 , where it is assumed that the same level of security at IPSEC level can be ensured by IPv4 with suitable functional and protocol additions, assuming furthermore that all services will mandate the highest level of security to ensure business transactions and/or privacy , and assuming finally that the same costs apply to the DNS and authentification levels , we can approximate the IPv4 additions as a decrease in the Payload(4) value , plus a higher processing cost for additional protocols . Thus:
SecurePayload (6) = Payload (6)
SecureServiceHandlingCost (6) = Service HandlingCost (6)
SecurePayload(4) =Payload(4)- SecurityOverhead(4)
SecureHandlingCost(4) = (1+SecurityProcessing(4)) *ServiceHandlingCost(4) (Eq 7)
Some may argue that SecurityOverhead(4) is the same with IPv6 as it may be considered as appended to the header; however, earlier expressions have already compensated for a bigger IPv6 header size. Thus, Equation (6) becomes:
SecureHandlingCost(6)/SecureHandlingCost(4)= SecurePayload(6)/ ((1+SecurityProcessing(4)) (SecurePayload(4)) (Eq 8)
If we assume that for said service, users or the end user devices used will mandate the same level of IP mobility as defined in Section 2.d , in view of their ubiquitous access to the service, then we can handle the IPv4 disadvantage in the same way as security disadvantage, e.g. with an overhead at processing level to run MobileIPv4 and maintain the suitable server information updates .As this processing compounds with the security processing overhead:
SecureMobileHandlingCost(6) / ServiceHandlingCost(4) =SecurePayload(6) / ((1+SecurityProcessing(4)) (1+MobilityProcessing(4)) (SecurePayload(4)) (Eq 9)
Neighbor discovery , loading of API’s and of missing data or files for autoconfiguration will exist both for IPv6 and IPv4 ,and will ultimately cost set-up time but also imply servicing overheads and user support needs [9] .Ultimately the effect will depend on the software quality and the quality and responsiveness of the service or product customer support , while the effect on wasted bandwidth or transmission capacity will be hard to model .Also the rarity of software and/or support will affect ease of use and the user perception of the quality and flexibility .
One economic way of handling this is by a technology diffusion function, driving associated explicit or perceived costs:
SetUpAndSupportCosts(x,t) = kSupp(x) Diffusion ( n(x),t) (Eq 10)
Where:
-Diffusion (n(x), t) is the diffusion curve over time, driven by n(x) number of fixed addresses for IPv(x) protocol at time t; this diffusion is within reachable customer base for a given operator; unit is in users over time each with their fixed IP address n(x)
-kSupp(x) is a constant, where it is reasonable to believe that for same address diffusion level n(x) , the relative costs for IPv6 are less than for IPv4 , thus kSupp(6) < kSupp(4) ;unit is set up and support cost per user per session of the specified service
The use of the flow label functionality ,and of its equivalents ,is to be treated as a revenue booster as higher quality of service should allow to charge more for the same (improved) service, and likewise a customized tariffing per packet flow (ultimately an individual packet tariff) should boost average revenue per payload information bit (see [12]) .It must be assumed that infrastructure ,such as billing or routing , to enable this quality of service or tariffing service diversity, is the same ,and not significantly larger than for default quality of service and billing/rating . The average boost is obviously service dependent ,and it is not possible here to consider a service usage distribution .The difference with the business models above is that this one affects revenue for the service modelled here ,thus :
ServiceRevenue (x) = kServRev(x) * N(x) * Payload(x) (Eq 11)
Where:
-kServRevBoost(x) is the average revenue per payload bit in a service with quality of service or tariff diversity boosters , for IPv(x) protocol ; whereas values for kServRev(4) can only be enhanced with higher level processing and routing , higher values for kServRev(6) are achieved natively via the IPv6 flow label field ,thus kServRev(6)>kServRev(4)
-ServiceRevenue(x) is average revenue for one normalized service session using IPv(x) protocol.
4 Innovation effects from IPv6
There is a fundamental trend for enterprise, as well as for consumer and for machine-to-machine services, that such applications as MMS messaging, e-Commerce, Mobile Business, multimedia Content delivery networks, will increase vastly the address usage mandated by one single such service as its richness goes up .In parallel and separately the information transmitted for fulfillment of a service session will go up especially if marginal bandwidth costs tend to have a very small value. Both evolutions rely ultimately upon innovation at service level as well as at network infrastructure and terminals.
We therefore must introduce a Session richness function with will drive the address usage as well as the information amount needed. Let Rich(t,x) be the multiplicator of the number of addresses needed by a service deployed with IPv(x) protocol ,and also the multiplicator for the number of packets N(x) needed to fulfill a session (assuming the two multiplicators to be identical for reasons of simplicity) .Time t is the exogeneous diffusion parameter. There is obviously an upper limit to this Rich (t, x) multiplier, as above some value, the service will change in nature and scope, which is not assumed here. Rich (t, x) can also be looked upon as the operator or ISP margin for competing with enhanced features for a given service for which tariff is set and fixed due to competitive pressures.
5 Business indicators for 4 Internet Service parties
In this Section four types of basic business players are considered, each assumed to have a “pure” definition, although in practice some real players will have mixed roles. The special case of wireless Internet services is touched upon in Section 6, and illustrates this last comment.
Note: Also, it should be stressed that, whereas technically Internet Service Providers “de facto” own the prefixes of the IP addresses granted to them as part of their registration, they should NOT in economic and business terms be considered as the owners of IP addresses .Thus the in the taxonomy of players below, the role as an owner of addresses is NOT made identical to the role as an Internet Service provider.
The net operations revenue to an Internet service operator, within its reachable customer base is, when he does NOT own the address domain, for independence reasons, are :
NetRevenue(x,t) = (Rich(t,x)* ServiceRevenue(x)-SecureMobileHandlingCost(x)-Rich(t,x) * Value(n(x) )) *Diffusion(n(x),t) (Eq 12)
The address domain owner (de facto ownership via management and registration, rather than legal ownership) is to be measured by the value of his address assets, from the customer base of previously mentioned ISP operator:
DomainAssets(x) = Value(Address(n,x) x Diffusion(n(x),t) (Eq 13)
User can retain same domain owner management if he/she switches ISP operators.
We assume here that the Internet user is watching the net real and perceived costs for a service session he is requesting, including support and set-up:
UserServiceCosts(x,t) = Rich(t,x)*ServiceRevenue(x) + SetUpAndSupportCosts(x,t) (Eq 14)
This indicator does not incorporate the propensity nor frequency of accessing these service sessions. This is because this model focusses on intrinsic properties and not at market forecasts; session usage can always be added to get total revenues, by a generic Usage (service, t, n) function.
Content owners are not directly affected in their content provisioning by the IP protocol issues ,as their data anyway must be packetized to reach content receivers ,and content billing must be enabled per session, flow, or by subscription .However ,they are affected indirectly by the structure of the content based services they may provision , in that their needs must be matched by the capabilities in the content delivery networks embodied in the Rich(t,x) parameter .Multimedia services mandate more data and more addresses.
6 Special case of Mobile IPv6 Traffic
The 3GPP standardization body has decided from its Release 3 in 2001, that all IP traffic in third generation services will rely on the IPv6 protocol with controls in the backbone and in the wireless and IP access networks [4]. This leads to the interesting issue of any changes to the above IPv6 characterization for the parts of the 3G traffic which are based on IPv6, and in particular Mobile Internet and Voice-over-IPv6 (thus ignoring conventional voice traffic) . There are many others aspects linked to hand-over for physical terminal mobility, and others [8].
Based on the nature of the service (i.e. for example VOIPv6 as opposed to WAP 2.0 traffic) the number of packets and their length in a session will vary. For example for VOIP there is likely to be a dominance of bursty short packets .To alleviate waste of spectrum , various packet and header compression algorithms have been researched and some have been standardized [4] . Some of these algorithms have to be compromized with wireless codec efficiency.
The main resulting changes are that:
-Header (x) and Payload(x) become respectively CompressedMobileHeader (x) and CompressedMobilePayload(x), resulting in ServiceMobileRevenue(x) per session
-PacketHandlingCost (x) becomes a larger MobilePacketHandlingCost(x) to account for the systematic packet and header compression, and decompression tasks
-N(x) is reduced for the compressed packets, but not in UTRA networks
-number of addresses needed when roaming between mobile operators is at least 2 x n(x) as the mobile terminals must have an address in each of the home and visited networks, and thus MobileRich(t,x) is approximately equal to 2 x Rich (t,x)
This results, for the wireless access operator carrying the Mobile IP traffic, in a net operations revenue, within its reachable customer base, which is :
NetMobileRevenue(x,t) = (Rich(t,x)* ServiceMobileRevenue(x)-SecureMobileHandlingCost(x)-MobileRich(t,x) *Value(n(x)))*Diffusion(n(x),t) (Eq 15)
where the addresses n(x) are of course those in the mobile operator’s domain, and which the operator thus get the MobileRich(t,x) *Value(n(x)) value from ,and which are explicitely or implicitely payable to the mobile operator by the Mobile Internet user (thus increasing the terms in Equation 12) .
Further analysis is provided in Section 7 on NAT’s ,and it should be highlighted that due to the shear number of mobile service users demanding IP services, there is a risk that some of the largest numbers of needed addresses and address increases in Equation (1) will be driven by mobile services.
7 Operating costs for N.A.T’s
Network Address Translation tables [10,11] are systems , used mostly in conjunction with IPv4 networks ,which allow to set in correspondence a set of private IP addresses in a closed domain, with fixed or dynamic addresses set on the Internet by a server in the backbone. In other words, when NAT’s are used, no one knows how many addresses exist and are reachable in total, and furthermore it may be very difficult to maintain “always-on” status for the closed domain users unless the NAT systems scale up dynamically 2G and 3G wireless networks essentially operate under this concept as the wireless access network is handled as a closed domain interfacing with the backbone via a system called GGSN.
If a network operates on the basis of NAT’s and only of closed domain users:
-the ISP operator will only have to pay to address domain owner for the dynamically established temporary needed addresses in backbone (usually in bulk or by a fixed sum)
-there are substantial operating costs involved in installing, reconfiguring and managing NAT’s ,and these costs may more than offset the savings from the above mentioned address management
-user may se problems in lower availability or session set-up and configuration costs for some services.
8 A Calculation case
The case considered here is pretty much matching the current situation in IP networks , where IPv4 dominate fixed operators, Internet service providers, and most of 1st and 2nd generation mobile services , both in terms of infrastructure but also of billing systems .At the same time, policy warnings have been sent out [7,8] ,as well as mobile networks are about to hit the address exhaustion very soon , urging a migration which is not evidenced by other than a number of research networks , of support by some IT and telecommunication equipment suppliers ,but with no real users [6] .
The technical characteristics are either set in the standards, or linked to state-of-the-art technology. For the costs, see [12], the main ones assumed being a normal payload of 16384 kbytes, and PacketHandlingCosts of 0.001 Euros.
Using the analytical model and data above, we get per session the following revenues for the ISP operator:
NetRevenue(4,t)= (0,5*Rich(4,t)-0,305-Rich(4,t)*Val(n,4))*Dif(n(4),t)
NetRevenue(6,t)=(1,0*Rich(6,t)-0,24154-Rich(6,t)*Val(n,6))*Dif(n(6),t)
If we make the simplifying assumption ,that , for same level of infrastructure and at the same time t , the service “richness” of IPv6 representing its enhancements at service level, for the same service concept , to be 2 versus 1 for IPv4 , we get :
NetRevenue(4,t)=(0,195-Val(n,4))*Dif(n(4),t)
NetRevenue(6,t)=(1,75846-2*Val(n,6))*Dif(n(6),t)
If IPv6 services and addresses are not available, obviously Dif(n(6),t) will be minimal. If however migration is offered ,defined as the free choice of a fixed IPv6 address or fixed IPv4 address by the user (or his proxy, such as mobile operator) ,and if the same service is offered via IPv4 and IPv6 payloads to end user, then the service access and diffusion curves Dif(n(4),t) and Dif(n(6),t) should be identical .A lot of sensitivity analysis can be made here, but Dif(n(x),t) ,it should be stressed, is not to be confused with the market based functions Usage(service,t,x) (not used at all in this model) .
If furthermore we assume that approximation Equation 3 is valid for an address n before exhaust where switching is possible, we get:
NetRevenue(6,t)-NetRevenue(4,t)= 1.56346- Val(n,6) (1,5-0,5*(kValAddress(4)/((1-kExhaust)*AddressCapacity(4)))
or, using initial values in Equation 2:
NetRevenue(6,t)-NetRevenue(4,t)= 1.56346 Val(n,6)(1.5-0.5*((Val(1,4)/Val(0,4))-1)/(1-kExhaust)))
This analytical expression shows that for the ISP operator, net revenue with IPv6 for the service is intrinsically and systematically higher than for IPv4 , unless the market value of IPv6 addresses is set too high and to increase too fast . It also shows that the later the migration is decided (higher values of kExhaust) ,the higher the payoff ,as the factor affecting Val(n,6) can even take negative values .The expression also shows the legacy effect of past and initial policy in market value of the IPv4 addresses, in that too low increases ( if not subsidized market prices) ,or low market values, force current IPv6 address market values to be low to achieve an overall revenue gain . Finally, as far as the initial constant 1.56346 is concerned, it should be pointed out that this systematic gain is explained by the technical attributes of IPv6, most of them accounted for explicitely in this model, although sensitivity analysis must be done.
The ratio of domain owner assets is:
DomainAssets(4)/DomainAssets(6) = (Value(Address(n,4) / ValueAddress(n,6)) *(Diffusion(n(4),t)/Diffusion(n(6),t))
Which under the same assumptions as in previous calculation Section 8.1 can be approximated at address exhaust by:
ValueAddress(n,4)/ValueAddress(n,6) = (1+kValueAddress(4)/((1-kExhaust) * AddressCapacity(4))/ (1+kValueAddress(6) /(AddressCapacity(6)-n))
Where the denominator can be approximated to 1 due to large value of AddressCapacity(6), thus:
DomainAssets(4)/DomainAssets(6) ~ 1+((ValueAddress(1,4)/ValueAddress(0,4))-1)/(1-kExhaust))
This can be interpreted by the fact that DomainAssets for IPv4 addresses will always be lower than DomainAssets for IPv6, unless the market value of IPv4 addresses has always been dropping (which is not the case) .It also shows that the fall in DomainAssets is all the larger than the switching decision is late, which explains a stubborn attitude not to switch.
The user service costs for a service session are:
UserServiceCost(4,t)=(0.5*Rich(t,4)+1))*Diff(n(4),t)
UserServiceCost(6,t)=(1.0*Rich(t,6)+0.5)*Diff(n(6),t)
Which under the same simplifying assumptions as above in Section 8.1 become very simply:
UserServiceCost(6,t)/UserServiceCost(4,t)= 2.5/1.5 = 1.66
which implies that the total real and perceived user service costs for a session ,albeit enhanced , is about 66% higher for IPv6 .If the user would not want the Rich(t,6)=2 value but the same service capabilities without enhancements than with IPv4 , he could get them and the user service costs would then be identical .The reason for this is the fact that larger IPv4 setup and configuration costs are just balanced off with higher user payments to the IPv6 ISP operator .
9 Conclusion
This paper provides an analytical model, not to be confused with a forecasting model using real traffic or revenue/cost data .It models the fundamental and intrinsic characteristics of the IPv4 and IPv6 protocols, to result in performance indicators for ISP and operator net revenues, for address domain owner assets, and for end user costs .All these are analyzed in the context of a single Internet based service session. Special aspects and modifications for wireless services are provided.
A numerical business case is given which matches closely the present situation in Internet services .Of course, the analytical model offers a framework for full sensitivity analysis, or to add service specific characteristics, as well as other business relation flows between parties to such Internet services.
Nevertheless, the business case provides some interesting conclusions limited to the case, but which seem to have wider implications.
The model shows that for the ISP operator, net revenue with IPv6 is intrinsically and systematically higher than for IPv4 , unless the market value of IPv6 addresses is set too high and to increase too fast . It also shows that the later the migration is decided, the higher the payoff, as the factor affecting the value of the IPv6 addresses can even turn negative .The model also shows the legacy effect of past and initial pricing policy in market value of the IPv4 addresses, in that too low increases (if not subsidized market prices) or too low market values, force current IPv6 address market values to be low to achieve an overall revenue gain for IPv6. Finally, it should be pointed out that the steady component of the IPv6 net revenue gain is explained by the technical attributes of IPv6, most of them accounted for explicitely in this model, although sensitivity analysis must be done.
The model shows that for address domain owners, domain owner assets for IPv4 addresses will always be lower than domain owner assets for IPv6, unless the value of addresses for IPv4 have always been dropping previously (which is not the case) .It also shows that the fall in domain assets is all the larger than the switching decision is late, which explains a stubborn attitude not to switch.
The model shows that the total user service costs for a session, albeit enhanced, are about 66% higher for IPv6 .If the user would not want only the same service capabilities (without enhancements) than with IPv4, he could, and then the user service costs would be identical .The reason for this is the fact that larger IPv4 setup and configuration costs are just balanced off with higher expenses paid to IPv6 ISP operator.
Ultimately this paper also raises interesting dilemmas:
-how can IPv4 ISP‘s, already rather poor, survive with basic services?
-should new regulation be put in place to ensure no de-facto address ownership, and no possible market pricing thereof once and for all, meaning that both equipment suppliers, incumbent operators and regulators each would have to give up something?
-should legislation be put in force giving legal address ownership in the hands of end users?
-users are bound to pay more for better services ,but can also get differentiated services and tariffs ,although this is still not exploited fully in protocol standards , billing and business terms .
References
[1] RFC 1287 , “Towards the future Internet architecture” , december 1991 , www.ietf.org
[2] RFC 1883,”Internet protocol,Version 6 (IPv6) Specification” ,december 1995 , www.ietf.org
[3] IPv6 Forum : www.ipv6forum.org/
[4] www.3gpp.org
[5] IPv6 tutorial : www.viagenie.qc.ca/en/ipv6forum.pdf
[6] Worldwide deployment map of IPv6 : noc.ntua.gr/~adamo/6bone
[7] John C.Klensin, A policy look at IPv6 : a tutorial paper, ITU , Geneva, 16 April 2002, www.itu.int/itudoc/itu-t/workshop/ipv6/003.html www.itu.int/ITU-T/worksem/ipv6/index.html
[8] L-F Pau,IPv6 in Mobile systems ,IPv6 Forum,Paris , May 1999 , www.ipv6forum.org
[9] RFC 2462, “IPv6 stateless address autoconfiguration” , december 1998 , www.ietf.org
[10] RFC 2766,”Network address translation-Protocol Translation(NAT-PT)”,february 2000, www.ietf.org
[11 Ken Wieland,Addressing the IPv6 issue, Telecommunications International, May 2002,27-30, www.telecommagazine.com
[12] L-F Pau, A business analysis of the IPv4 and IPv6 protocols in fixed and mobile communication services , Research report, ERIM, Rotterdam School of Management , August 2002
Contact the author: