Above comments based on 2 years of IPv6 implementation experience. Carroll Perkins
________________________________________
From: ipv6-bounces at ietf.org [ipv6-bounces at ietf.org] On Behalf Of Brian E Carpenter [brian.e.carpenter at gmail.com]
Sent: Tuesday, October 13, 2009 8:46 PM
To: Christian Huitema
Cc: 6man 6man
Subject: Re: What flexibility do 6to4 NAT have with address formats?
On 2009-10-14 03:38, Christian Huitema wrote:
...
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.
As I understand it, routers should never treat /64 as special
or as any kind of limit. It's just a convention that /64 is
considered the longest normal subnet prefix, which happens to
be compatible with SLAAC. So I can't see any fundamental
reason why the IPv4 address bits can't straddle the /64
boundary. However, they should clearly skip over the UG bits
so the resulting 64-bit IID is consistent with the IID rules.
That will break byte alignment.
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.
If you do straddle the /64 boundary, you will not have a null
IID so the issue goes away. If not, using null feels wrong to
me. Firstly, it conflicts with the current (harmless and
possibly implemented) spec. Secondly, specifying a value is no
big deal as far as I can see.
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?
Why wouldn't it be OK? I can't see why it's a question.
The normal expectation is that different hosts have different
IIDs so I am curious why this matters.
Brian
-- Christian Huitema
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6 at ietf.org
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
