128 bits for IPv6 addresses are divided into a 64 bit "network id" and a 64 bit "host id". The 64 bit network id isn't overkill. You could argue that, given allocation realities, and the need for several levels of aggregation, that it isn't enough.
But 64 bits for the host id does seem excessive. Most of the time, it is onlynecessary to provide enough bits to uniquely identify a host within its network. 64 bits is considerably more than is required for this, and is enough to give every host a globally unique identifier independent of the network ids. In fact, most hosts will have a host id that is based on their unique MAC address, and even this would have required only 48 bits.
The long host ids were done to permit autoconfiguration. But they raise privacy issues, and it doesn't seem logical to me that every one of trillions of network packets needs to carry a globally unique host id for the sake of an autoconfiguration event that happens only when the host joins the network.
It is hard to imagine that the proposed solution will ever really be needed by anyone.
By the time there are significant enough numbers of IPv6 clients with no connectivity to IPv4 web sites for this to be a potential concern for web site operators, this will have been solved on the IPv6 side of the fence. Otherwise, what value is the IPv6 connectivity? And probably this solution will not involve application-specific or protocol-specific gateways such as the one described (even for an important protocol like HTTP), but rather a more generalized IPv6 to IPv4 translator handling traffic leaving the IPv6 island for the IPv4 sea. . Many generalized IPv6-to-IPv4 translation technologies, such as RFC 3421, have been proposed and discussed by the ngtrans working group of IETF, and some kind of technology like this will be deployed long before anyone really needs a solution like the one proposed.
It is hard to imagine that the proposed solution will ever really be needed by anyone.
By the time there are significant enough numbers of IPv6 clients with no connectivity to IPv4 web sites for this to be a potential concern for web site operators, this will have been solved on the IPv6 side of the fence. Otherwise, what value is the IPv6 connectivity? And probably this solution will not be an application-specific gateway such as the one described, but rather a more generalized IPv6 to IPv4 gateway at the edges of the IPv6 islands in the IPv4 sea. Many generalized IPv6-to-IPv4 translation technologies have been proposed and discussed by the ngtrans working group of IETF, such as RFC 3421.
Way back in 1982, RFC 822 (STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES) defined most of the email headers currently in use, and those headers have been put on email by senders and mail servers for nearly two decades. In brief, the headers on a mail identify who sent it, what servers handled it as it wended its way to the final recipient, who it was delivered to along the way, who forwarded it, etc. For years, people running mail servers and recpients have been reading the headers to find out who sent the mails and what servers they passed through.
Now Microsoft says they have applied for a patent on reading the headers on an email to determine -- what? Who sent the mail! Could the writers of the RFC 822 have ever imagined that the headers on an email might be used for something so non-obvious -- so brilliant -- as determining the email address, including the domain name, of the person/entity that sent the email?
And Microsoft doesn't even have to be granted this amazing patent to throw the MARID working group into a tailspin. They only have to mention that they've applied for it...
Slashdot Mirror
128 bits for IPv6 addresses are divided into a 64 bit "network id" and a 64 bit "host id". The 64 bit network id isn't overkill. You could argue that, given allocation realities, and the need for several levels of aggregation, that it isn't enough.
But 64 bits for the host id does seem excessive. Most of the time, it is onlynecessary to provide enough bits to uniquely identify a host within its network. 64 bits is considerably more than is required for this, and is enough to give every host a globally unique identifier independent of the network ids. In fact, most hosts will have a host id that is based on their unique MAC address, and even this would have required only 48 bits. The long host ids were done to permit autoconfiguration. But they raise privacy issues, and it doesn't seem logical to me that every one of trillions of network packets needs to carry a globally unique host id for the sake of an autoconfiguration event that happens only when the host joins the network.
It is hard to imagine that the proposed solution will ever really be needed by anyone. By the time there are significant enough numbers of IPv6 clients with no connectivity to IPv4 web sites for this to be a potential concern for web site operators, this will have been solved on the IPv6 side of the fence. Otherwise, what value is the IPv6 connectivity? And probably this solution will not involve application-specific or protocol-specific gateways such as the one described (even for an important protocol like HTTP), but rather a more generalized IPv6 to IPv4 translator handling traffic leaving the IPv6 island for the IPv4 sea. . Many generalized IPv6-to-IPv4 translation technologies, such as RFC 3421, have been proposed and discussed by the ngtrans working group of IETF, and some kind of technology like this will be deployed long before anyone really needs a solution like the one proposed.
It is hard to imagine that the proposed solution will ever really be needed by anyone.
By the time there are significant enough numbers of IPv6 clients with no connectivity to IPv4 web sites for this to be a potential concern for web site operators, this will have been solved on the IPv6 side of the fence. Otherwise, what value is the IPv6 connectivity? And probably this solution will not be an application-specific gateway such as the one described, but rather a more generalized IPv6 to IPv4 gateway at the edges of the IPv6 islands in the IPv4 sea. Many generalized IPv6-to-IPv4 translation technologies have been proposed and discussed by the ngtrans working group of IETF, such as RFC 3421.
Now Microsoft says they have applied for a patent on reading the headers on an email to determine -- what? Who sent the mail! Could the writers of the RFC 822 have ever imagined that the headers on an email might be used for something so non-obvious -- so brilliant -- as determining the email address, including the domain name, of the person/entity that sent the email?
And Microsoft doesn't even have to be granted this amazing patent to throw the MARID working group into a tailspin. They only have to mention that they've applied for it...