Hi, . Aren't we suppose to have sufficient IP address so that each can have globally unique address? If that is the case, can't each user get his/her own IP address without bothering about renumbering in the service provider? Why are we trying to constrain the end user, to solve the routing problem? IPV4 doesn't work well with NAT. We are trying to address many limitation of IPV4 in IPv6. Why not try to make IPv6 such that, it can work well even when technology like NAT is deployed i.e. the end address is different from the transport address. Any way we are modifying application, won't it be better if they are modified in more flexible way.For example: We use one address to address the end systems, this address has certain bits that are unique globally, but certain bits that are used only for routing and can take any value depending on the routing path that exist at that moment? When somebody uses a new service provider, the upper bits are changed by the gateway routers (or by the routing component in the host itself by doing a dns queery), and since the end systems don't use those upper bits at all, they could care less who is the service provider? In telephone system we have the countrycode-areaCode-number, may be for Ip we need serviceProviderCode-countryCode-areaCode-number. When we want to ping or do any such thing, we keep the service provider code as zero or something else. Address aggregation can be done at service provider code or using country code or any other combination.(May be in IP world we would use domaincode like.com, .edu instead of country code so the address also reflect the DNS hierarchy). There can be many other use of separating the transport address from the end address as there are advantages of decoupling them (one can argue that the dns name are the end address but a string doesn't usually form a good thing for end address). One can also have certain bit in the transport address (or can be in ipHeader) to indicate that this packet is from a customer and service provider may treat this packet differently. Regards, Vijay
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
