RE: What flexibility do 6to4 NAT have with address formats?

["Templin, Fred L" <[e-mail]>]

Jeffrey,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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
[e-mail]

> 
> Best Regards,
> 
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
> [phone] (mobile)
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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: [e-mail] [[e-mail]] On Behalf Of
> > Brian E Carpenter [[e-mail]]
> > 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 [e-mail]
> >> Administrative Requests:
> >> https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >>
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------