Jeffrey, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Dunn, > Jeffrey H. > Sent: Wednesday, October 14, 2009 8:26 AM > To: Ole Troan; Perkins, Carroll G > Cc: Christian Huitema; 6man 6man; Brian E Carpenter > Subject: RE: What flexibility do 6to4 NAT have with address formats? > > Colleagues, > > In support of one our customers, we tested several Cisco implementations and > found that they work > just fine with prefix lengths not equal to 64. That said, most operating > systems we tested only > support a 64-bit prefix for address configuration, SLAAC or DHCPv6. Because > of this, I suspect that > routers that support DHCPv6, e.g., home WiFi routers, will probably require > the prefix to be 64 bits > on any premise-facing interface. This is not the case for "industrial > strength" routers. > Specifically, Cisco shows a prefix delegation example with a /48 prefix and > the prefix length must be > specified on the DHCPv6 server configurations.
Prefix delegation with, e.g., /48 is standard operating procedure; what matters is how the prefix gets sub-delegated and how portions of the prefix get assigned interfaces. Do you see cases where a prefix other than /64 is assigned to an interface? Fred fred.l.temp...@boeing.com > > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > (301) 448-6965 (mobile) > > > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Ole > Troan > Sent: Wednesday, October 14, 2009 10:58 AM > To: Perkins, Carroll G > Cc: Christian Huitema; 6man 6man; Brian E Carpenter > Subject: Re: What flexibility do 6to4 NAT have with address formats? > > > "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 trying to speak for every platform or operating system that Cisco > has, but this is what's been done for the IPv6 implementations I'm > aware of, in particular IOS. > > the 64 bit boundary is policy. I have thought for a long time that we > should rather fix SLAAC to work with longer prefixes. > > cheers, > Ole > > > > > 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 exper > > iment 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
