Carroll, No doubt you are correct and in most contexts I would never advise people to consider prefixes >64. But Christian's question is in a very specific context where we don't have products or operational practice today.
IPv6 has had variable-length subnet masks since 1995; it's too bad if some manufacturers haven't noticed. Regards Brian Carpenter On 2009-10-15 01:40, Perkins, Carroll G wrote: > "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" > > Not sure which vendor router implementations of IPv6 you are talking about, > but the /64 division is almost universally used across so many router > configuration panels, IPv6 address management applications, etc that ignoring > or changing it basically kills any chance of having a proposed standard > accepted by IETF. For example, read the manual on the D-Link DIR-615 > Hardware ver C1 Firmware ver 3.11NA to see what I am talking about. The /64 > BOUNDARY IS HARDCODED INTO THE FIRMWARE AND IS UNCHANGEABLE. > > One of the situations occurring with todays IPv6 adoption is that long-time > IPv4 techies are looking for the variability that IPv4 embodies because of > it's definition on the fly during the last 20 years. But IPv6 basically > defines out as much variability as possible to keep IPv6 implementations > compatible across vendors. Think like Japanese cars, they all have different > names, but most of the underlying parts come from the same suppliers. So > IPv4 techies knowledge base on protocol variabilities is basically factored > out of IPv6 definitions to the greatest extent possible. Formal evidence of > variabliity limitation is that NIST has set up standardized testing lab > structures for IPv6 devices to be certified, process modeled after what > Underwriter Labs has done for electrical appliances. By the end of 2010, all > commercial IPv6 devices should be NIST lab certified against a given set of > IETF standards or there will be no commercial market for them. But the best > thought ex periment is: How many 47 cycle AC hairdryers have you seen at Wal-Mart lately? > > Above comments based on 2 years of IPv6 implementation experience. Carroll > Perkins > > > > ________________________________________ > From: ipv6-boun...@ietf.org [ipv6-boun...@ietf.org] On Behalf Of Brian E > Carpenter [brian.e.carpen...@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@ietf.org >> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
