We were having a discussion when preparing the next version of the "translated addresses" document. This document describes the address format used by protocol translators, including "stateless translators" that rely on algorithms to map an IPv6 address to an IPv4 address. The work is going on in the BEHAVE working group, but the expertise on address formats lies in the IPv6 WG. Hence the questions to this list.
There are a couple of constraints, of various importance, that we need to address. You mention checksum neutrality, and we can certainly accommodate that, but there are a few others that lead to discussions. For example, for stateless translation, we need to be able to route packets in the IPv6 network based on the IPv4 address. If we want to protect against address spoofing, we need to also perform reverse path checks based the IPv4 address. Even for stateful translation, we may need to select the translator based on the target IPv4 address, e.g. to perform load balancing. That requirement can be accommodated in several ways, the simplest one being to format the addresses a prefix (well known or network specific), concatenated with the IPv4 address and a suffix. That way, the network can perform internal routing and checks on the combination of prefix+IPv4 address. But then, there are a few complications. First, we wonder about the importance of the 64 bit boundary. Addressing documents specify that the global address is essentially formed of a 64 bit subnet prefix and a 64 bit host identifier, with the host identifier compatible with IEEE 802 identifiers. Does that mean that the "routing" requirement of stateless translation can only be addressed if the IPv4 bytes are entirely contained within the subnet prefix? Different authors have different opinions, so WG input would be beneficial. Second, we wonder about the constraints of host identifiers. A first question is whether an all null identifier would be legitimate and practical. There is some evidence that it works with most stacks. But there is also a statement in the addressing document that the all null address is reserved for the subnet anycast address. Do stacks actually implement the subnet anycast function? Should the specification be removed from the addressing RFC? Can we just ignore it? If we cannot ignore it, we will have to specify some value different from zero for the suffix. A "checksum neutrality" field might do that, but please consider the second question. The second question regards the uniqueness of host identifiers. Suppose we define the address used for stateless translation as: 32 bit "provider" prefix, 32 bit IPv4 address, and a constant identifier, either 0 or the "checksum neutrality" value, which is only a function of the provider prefix. Suppose now that for some reason there are two "IPv4 addressed" hosts on the same link, e.g. because many servers are located in the same server room. The two hosts will have different addresses, in different 64 bit subnets, but they will also have different host identifiers. Is that OK? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
