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

From: Christian Huitema <[email-masked]>
Date: Tue, 13 Oct 2009 14:38:43 +0000

We were having a discussion when preparing the next version of the "translated addresses" document. This document describes the address format used by protocol translators, including "stateless translators" that rely on algorithms to map an IPv6 address to an IPv4 address. The work is going on in the BEHAVE working group, but the expertise on address formats lies in the IPv6 WG. Hence the questions to this list.

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: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Oct 2009 13:46:21 +1300

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 [email-masked] 
> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 14 Oct 2009 01:09:45 +0000

> IIDs so I am curious why this matters.

I just realize I made "typo". I meant to say " The two hosts will have
different addresses, in different 64 bit subnets, but they will also have 
the same host identifiers. Is that OK?

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Oct 2009 14:37:56 +1300

> the same host identifiers. Is that OK?

Well, that would be OK if you set U=0 as far as I can see.
It might be an odd situation, but then nobody should ever rely on
their uniqueness. It might be safer to make U=0 mandatory
for these synthetic addresses in all cases.

If you don't respect the UG bits we are asking for trouble anyway.

   Brian

---

From: "Perkins, Carroll G" <[email-masked]>
Date: Wed, 14 Oct 2009 08:40:45 -0400

"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 experiment 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: [email-masked] [[email-masked]] On Behalf Of Brian E Carpenter [[email-masked]]
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?

   Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Oct 2009 16:57:38 +0200

> considered the longest normal subnet prefix, which happens to be  

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?
>
> From: [email-masked] [[email-masked]] On Behalf Of  
> Brian E Carpenter [[email-masked]]

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 14 Oct 2009 11:26:02 -0400

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.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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?

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Oct 2009 10:43:55 -0700

Jeffrey,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dunn, Jeffrey H.
> Sent: Wednesday, October 14, 2009 8:26 AM
> To: Ole Troan; Perkins, Carroll G
> 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
[email-masked]

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 14 Oct 2009 14:15:52 -0400

Fred.

We have indentified two use cases for a prefix not equal to 64 bits. First, most OS implementations ship with SLAAC turned on. By using a prefix length not equal to 64, SLAAC is inhibited. I know that most implementations allow SLAAC to be configured off, but this guarantees it will not work. Second, in cases where there are numerous VLANs in use, configuring a /64 on the physical interface and /80 on each VLAN, mapping the IEEE 802.1Q Tag Control Information to the low order 16 bits, might make sense. This is especially true where VoIP, NAC and different privileges all have their own VLAN. 

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2009 1:44 PM
To: Dunn, Jeffrey H.; Ole Troan; Perkins, Carroll G
Cc: Christian Huitema; 6man 6man; Brian E Carpenter
Subject: RE: What flexibility do 6to4 NAT have with address formats?

Jeffrey,

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Oct 2009 11:13:05 +1300

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:
> 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?

---

From: Brian Haberman <[email-masked]>
Date: Fri, 16 Oct 2009 16:35:48 -0400

I wonder if there isn't some confusion here.  Routers need to handle 
IPv6 prefixes in a number of ways.  If the router supports SLAAC, then 
it currently needs to be cognizant of the /64 boundary for the PIO. 
But, routers should be (and are in my experience) capable of supporting 
arbitrary prefix lengths in the routing protocols as well as the route 
lookup process.

I suspect that some lower-end routers mention the hard-coded /64 
boundary without specifying that it may be that the boundary is only for 
SLAAC.

Regards,
Brian