Subject: [BEHAVE] Need another case in 3.2.5

From: Fred Baker <[email-masked]>
Date: Fri, 9 Oct 2009 11:17:14 -0700

The draft proposes three formats, two of which are checksum neutral,  
and says that the result SHOULD be checksum neutral - basically  
stacking the deck against the third option. They are:

3.2.3:
    |                96 bits                    |      32 bits        |
    +-------------------------------------------+---------------------+
    |                PREFIX                     |    IPv4 address     |
    +-------------------------------------------+---------------------+

    This format is not checksum-neutral unless the PREFIX is checksum-
    neutral.  Hence, a well-known prefix can ensure checksum neutrality,
    but using this format with network-specific prefixes in general
    cannot.
3.2.4:
    |                80 bits               | 16 |      32 bits        |
    +--------------------------------------+----+---------------------+
    |                PREFIX                |comp|    IPv4 address     |
    +--------------------------------------+----+---------------------+

This is by definition checksum neutral with a provider-assigned  
prefix, as the value of the 16 bits is determined by the 80 bit prefix.

3.2.5:
    |           n bits         |      32 bits        |    96-n bits   |
    +--------------------------+---------------------+----------------+
    |           PREFIX         |    IPv4 address     |      Zero      |
    +--------------------------+---------------------+----------------+

This is not checksum neutral as specified.

3.2.3 and 3.2.4 neglect one of the primary requirements that led to  
3.2.5, however: it doesn't allow a /64 to include a portion of the  
embedded IPv4 address, and hence doesn't allow a service provider to  
distribute small numbers of such an address to each of a set of  
customers without using a well-known prefix, which as we have noted  
presents other problems in service provider routing.

This can be fixed, and trivially. Add one more case

3.2.++:
    |           n bits         |      32 bits        | 80-n bits  | 16 |
    +--------------------------+---------------------+------------+----+
    |           PREFIX         |    IPv4 address     |    Zero    |comp|
    +--------------------------+---------------------+------------+----+

This provides checksum neutrality *and* addresses use by a service  
provider.

I believe that Xing Li has proposed something similar in another  
document.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 9 Oct 2009 20:08:36 +0000

We were having a similar discussion when preparing the next version of the addressing documents. 

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

---

From: Xing Li <[email-masked]>
Date: Wed, 14 Oct 2009 20:55:46 +0800

Hi, Christian,

> 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…

Based on our understanding and our large scale IPv6 network operation 
experience:

(1) The IPv6 network should be able to route any prefix length from 
default to /128. However, the wire-speed forwarding may require /80 or 
shorter for some routers.
(2) The stateless host configuration requires the /64 as the subnet 
prefix length. However, if DHCPv6 or static configuration is 
implemented. The subnet prefix can be with any prefix length.

> 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 sta…

Based on Section 2 of RFC4291, it reads: "In IPv6, all zeros and all 
ones are legal values for any field, unless specifically excluded. 
Specifically, prefixes may contain, or end with, zero-valued fields."

Based on Section 2.6.1 of RFC4291, all zeros are used for the 
subnet-router anycast address. However, we don't need to remove this 
specification from RFC4291, since we never use "all null identifier" for 
the IPv4-translatable addresses. For example, if 202.38.108.0/24 is 
mapped into IPv4-translatable addresses, it will become 
2001:da8:ffca:266c:0::/64 (for easier demonstration, we use four 
consecutive octets and the PREFIX is 2001:da8:ff00::/40). It is clear 
that the individual IPv4-translatable addresses are 
2001:da8:ffca:266c:100::/64, 2001:da8:ffca:266c:200::/64, ..., 
2001:da8:ffca:266c:fe00::/64. while the subnet-router anycast address is 
2001:da8:ffca:266c:0::/64. They are different. Note that we are not 
using 2001:da8:ffca:266c:0000::/64, because it is the network identifier 
in IPv4.

Based on the above analysis, we don't need to specify some value 
different from zero for the suffix.
> 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 identi…

Based on the above reasons, it is OK.

Regards,

xing, congxiao

> -- Christian Huitema
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>
>