Subject: Re: v6-v4 transition scenarios, take 2

From: Nathan Ward <[email-masked]>
Date: Tue, 5 Aug 2008 01:43:36 +1200

On 29/07/2008, at 5:29 AM, Pekka Savola wrote:

> 2. ISP moves customers from v4 public to rfc1918, may provide v6
>
> Due to IPv4 exhaustion, an ISP stops providing public IPv4 addresses  
> through DHCP to its residential, SOHO and small enterprise  
> customers. Instead, it provides only private IPv4 addresses and NATs  
> these.  The change is involuntary, and the customer needs to pay a  
> premium rate if it wants to continue getting public v4 address  
> space.  This causes some problems with some customers' internal  
> networks which use overlapping private address space, but the ISP's  
> troubleshooting guides give instructions on renumbering the internal  
> network to a different private address space.
>
> In addition, the ISP may start providing IPv6 service to the  
> customers as a way to show the users this is actually "the good  
> thing for the continued health of Internet".  IPv6->IPv4 NAT service  
> is not generally provided because IPv4 private addressing + NAT is  
> still a workable service. However, on the longer term, the ISP may  
> be interested in piloting a similar v6->v4 NAT solution as above.

The problem with using RFC1918 addressing, is end users expect to be  
able to use that in their networks. Different CPE vendors use  
different parts of RFC1918 by default, each vendor seems to do it  
their own way - some even differing between products and product  
software versions.

To this end, my recommendation that I am giving ISPs is to take a  
block of addresses from your existing IPv4 pool (say a /24 or so), and  
assign this multiple times across your network, placing a v4 NAT  
address in 'front' of each instance.

Do not advertise this /24, or if you do, blackhole traffic. Perhaps  
it's useful to blackhole and analyse, to detect badly behaving  
protocols.

I.E. re-use the same /24 on each NAS[1], then NAT all customers on  
that NAS behind a single IPv4 address.

The problem here of course is that Vista and some XP service pack 2  
machines, should they be given one of these addresses will attempt to  
bring up 6to4 as it is a non-RFC1918 address.
There are two work-arounds for this that I can see, and I think it is  
a good idea to do both.
1) Enable IPv6 on the access. If windows has a native IPv6 address it  
won't attempt to bring up 6to4.
      - If you don't have an IPv6 transit service, still do this, but  
simply return ICMPv6 destination unreachable messages.
2) Direct all IPv4 protocol 41 (IPv6 over IPv4, 6to4) messages to a  
6to4 relay, which returns ICMPv6 destination unreachable messages,  
encapsulated in IPv4 as per 6to4. Windows will bring up 6to4, but will  
get error messages back so will fall back to IPv4 without waiting for  
a time out.

Perhaps in the future, a vendor will develop a NAS product that allows  
the same /30 to be re-used many times, and the NAT table keeps tracks  
of inside interface on each translation.
Perhaps that same vendor will develop a feature to have that 6to4  
relay that returns ICMPv6 destination unreachable messages built in to  
their NAT product.

Speaking of big scale NAT and vendors - I mentioned this approach to a  
technical sales engineer for a large vendor recently, who promptly  
made scary noises about whether or not anyone had boxes that could be  
reasonably expected to do NAT on this sort of scale.

If you are buying NAS hardware now and expect it to last more than a  
few years, I strongly recommend asking for IPv4 NAT features (and not  
just software NAT).

On 29/07/2008, at 5:29 AM, Pekka Savola wrote:

> 5. Nearing 2015, ISP wants to ensure its users can reach all the
>     services in Internet, and deploys a v4-to-v6 NAT
>
> Enterprises, content providers, etc. may have problems obtaining  
> enough IPv4 addresses to provide their services over IPv4 even if  
> they wanted to. During the next 5 years, this is not going to be a  
> major obstacle because existing IP address usage can be made more  
> efficient with some O&M expense (and more addresses freed e.g. by  
> moving client-only users behind NATs).
>
> However, some years after the IANA free pool has been exhausted this  
> may become a problem, depending on how much money the content  
> provider is willing to use to obtain public v4 addresses.
>
> Sometime in 2015-2020 range it may be that the pain of providing  
> IPv4 services becomes so big that some significant content providers  
> want to stick to just IPv6 (and don't even want to pay for someone  
> else to deal with this problem for them as in scenario 4) above).
>
> Around the time when this happens, even those ISPs which have wanted  
> to ignore IPv6 as long as they could, may decide that they will need  
> to do something.  (Or the case could be that the ISP still has  
> customers with only v4 capabilities.)  The possible fixes to this  
> problem are to a) deploy v6 to customers (if v4-only customers is  
> rare enough) or b) to provide a v4->v6 translation service for v4- 
> initiated short local handle -type applications.

I agree with this, but, this is the part of the IPv6 transition that  
scares me the most.

I suppose the potential scenarios here with IPv6-only content are:
1) User has IPv6 capable equipment and provider - OK!
2) User has IPv6 capable equipment, but no IPv6 provider - OK! (Teredo/ 
6to4, assuming service provider NAT is NOT taking place)
3) User has no IPv6 capable equipment, but an IPv6 capable provider -  
OK! (Some NAT46 thing in the provider network saves the day)
4) User has no IPv6 capable equipment, and no IPv6 capable provider -  
NOT OK!

Hopefully (4) is rare.
(2) breaks down if the provider is doing NAT as per my suggestions at  
the start of this email, as 6to4 will come up, and time out. Teredo  
will not come up. I don't yet have a solution to this that doesn't  
involve either:
1) 6to4 qualification mechanism on all boxes attempting to do 6to4.
2) ISP distributing a "patch" that hacks the Windows registry to  
disable 6to4, but keep Teredo enabled.

(2) is quite feasible I suppose, and it is easy enough to detect users  
who are attempting 6to4 on networks that don't support it.

--
Nathan Ward

[1] AKA BRAS, Access Router, whatever is appropriate.

---

From: Nathan Ward <[email-masked]>
Date: Tue, 5 Aug 2008 01:47:38 +1200

On 29/07/2008, at 1:51 AM, Pekka Savola wrote:

> As an observation after writing this, I'm focusing pretty much only  
> on client-server type applications because I've yet to see p2p or  
> other _inter-domain_ applications that are business critical.   
> Another reason may be that I don't know them in detail, and that  
> will likely require application-specific transition scenarios, not  
> just ALG extensions.  But I'm willing to be convinced otherwise...

(Also RE. other comments in this thread about p2p)

Some time last year I was talking about IPv6 in bit torrent. At  
APNIC26 in Christchurch, NZ I'm hoping to talk about some research I'm  
doing with that at the moment, which will hopefully provide some  
insight in to whether we can start recommending that ISPs break IPv4  
end-to-end, and pushing peer-to-peer protocols on to IPv6. Indications  
from my brief look at this last year are "yes, we can".
Further, I hope that we can encourage p2p software vendors who are  
holding off (Skype, etc.) to update their applications to support IPv6.

I'll post any data etc. I have to the list when it's in a form that  
makes sense to people other than myself.

--
Nathan Ward

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Aug 2008 07:44:35 -0700

>get error messages back so will fall back to IPv4 without waiting for  

Another possibility is to configure the NAT as an ISATAP
router and have the end systems use ISATAP.

Fred
[email-masked]

---

From: Nathan Ward <[email-masked]>
Date: Tue, 5 Aug 2008 03:07:44 +1200

> router and have the end systems use ISATAP.

I considered this, however:
1) End user PCs seldom have their domain name configured to be that of  
their ISP.[1]
2) Any host behind customer NAT will also attempt ISATAP - if this  
succeeds the end host will use its interface address for the last part  
of the ISATAP IPv6 address, which if RFC1918 (more than likely!), will  
not be unique within the SP's ISATAP domain.
3) If the SP doesn't have IPv6 transit, they still have to return  
ICMPv6 destination unreachable messages.

[1] My understanding is that Windows looks for A records for ISATAP. 
$domain.. Section 9 of RFC4214 suggests that that's the right thing to  
do. Perhaps looking for ISATAP. before ISATAP.$domain. would have been  
preferable, but I'm operating under the assumption that we have to  
allow for the behaviour of anything in the wild as of now, as as we  
know, not everyone runs their Windows updates every week.

--
Nathan Ward

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Aug 2008 08:26:48 -0700

Hi Nathan, 

>-----Original Message-----
>From: Nathan Ward [mailto:[email-masked]] 
>Sent: Monday, August 04, 2008 8:08 AM
>To: v6ops WG
>Subject: Re: v6-v4 transition scenarios, take 2
>

I'm not sure I see the problem. The end-user PCs will see
a connection-specific DNS suffix, and will have a well-
formed FQDN to use when they concatenate that with the
prefix "isatap".

>not be unique within the SP's ISATAP domain.

There is no requirement that the interface ID be unique as
long as the IPv6 prefixes are distinct. Consider that if you
have a prefix delegation hierarchy, and each level of the
hierarchy is doing ISATAP, you will always have distinct
prefixes and distinct, non-overlapping ISATAP domains.

>ICMPv6 destination unreachable messages.

The idea is that the cusomter NAT becomes an IPv6 router.
It does ISATAP on the customer-facing side and some other
IPv6 capability on the SP-facing side. That could be a
native IPv6 service, 6to4, or it could even be another
ISATAP domain that is distinct and separate from the
customer's ISATAP domain.

If the SP can't provide an IPv6 service of any kind,
then there is always the possibility to use Teredo.

Fred

---

From: Nathan Ward <[email-masked]>
Date: Tue, 5 Aug 2008 03:49:24 +1200

> customer's ISATAP domain.

Right, your assumption is that the customer NAT device changes - my  
assumption is that the customer NAT device stays the same, which is  
where we're differing here.

I agree with you - ISATAP is absolutely appropriate inside customer  
networks that have IPv4-only internal routing equipment, but have an  
IPv6 capable NAT box and hosts, and at least a single IPv6 /64.

It is not clear to me how ISATAP can be used between the ISP and the  
customer CPE, should that CPE support ISATAP. My understanding is that  
ISATAP gives hosts single addresses, not a /64 as would be required by  
a second ISATAP domain, or by a subnet behind the CPE.

> then there is always the possibility to use Teredo.

Yes - however Teredo is selected after 6to4 on Windows. There are two  
ways a customer might use, for example, an ADSL service:
1) Have a NAT box. Teredo will work fine.
2) Plug their Windows PC in to an ADSL device that lets the ISP  
assigned IPv4 address exist on the PC ("modem"). The PC tries to bring  
up 6to4, as in my recommendation RFC1918 addressing is not used by the  
ISP for customer assignments to avoid address conflicts. Teredo will  
not come up, as a Windows host will assume 6to4 is functioning.

The two ways to avoid (2) being a problem are in my initial post in  
this thread, under "There are two work-arounds for this that I can  
see, and I think it is a good idea to do both.".

--
Nathan Ward

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Aug 2008 09:02:04 -0700

>Sent: Monday, August 04, 2008 8:49 AM
>To: Templin, Fred L
>Cc: v6ops WG

The NAT box would be a natural location for the ISATAP
router function, and I don't think entirely out of
the question for change given the benefit. But, I'm not
entirely sure that it is the only location; I will have
to study more on what is meant by "Internet Connection
Sharing" on Windows, for example. 

>a second ISATAP domain, or by a subnet behind the CPE.

ISATAP is about *hosts* receiving a single IPv6 address
with an embedded IPv4 address. VET is about *routers*
receiving IPv6 prefixes for sub-delegation on their
site-internal interfaces:

http://tools.ietf.org/html/draft-templin-autoconf-dhcp-14

The ISP/CPE routing region would use VET, which can be
thought of as ISATAPv2.

Fred

---

From: Nathan Ward <[email-masked]>
Date: Tue, 5 Aug 2008 05:01:54 +1200

On 5/08/2008, at 4:02 AM, Templin, Fred L wrote:

> with an embedded IPv4 address.

Yes, I understand that.
Your comment here seems contradictory to your previous comment:
<snip>
The idea is that the cusomter NAT becomes an IPv6 router.
It does ISATAP on the customer-facing side and some other
IPv6 capability on the SP-facing side. That could be a
native IPv6 service, 6to4, or it could even be another
ISATAP domain that is distinct and separate from the
customer's ISATAP domain.
</snip>
It sounds here as though you are suggesting that a customer's NAT box/ 
CPE/whatever is receiving IPv6 connectivity with ISATAP, and then  
using ISATAP to distribute that connectivity within the customer's  
network.

> VET is about *routers*

I will read more about VET tomorrow.

While it might be worthwhile for an ISP to consider using for rolling  
out their v6 service, I'm not sure we're having the same discussion,  
maybe I have mis-understood the intent of this thread.

I am talking about how to do IPv4 SP NAT in such a way that existing  
(ie. deployed as of the moment I write this email) IPv6 connectivity  
mechanisms do not fail, or if they do fail, they do so gracefully so  
that end users do not notice. While at the same time, preventing IPv4  
address network overlaps on both sides of a CPE.

It would be nice if we could tell everyone to upgrade their CPE, OS  
etc. immediately to support new protocols, but really, our inability  
to do so is why we are having this discussion.

--
Nathan Ward

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Aug 2008 10:27:11 -0700

Nathan, 

>Sent: Monday, August 04, 2008 10:02 AM
>To: Templin, Fred L
>Cc: v6ops WG

Taken literally you are right, but I was meaning to refer
to ISATAP behind the customer's NAT and VET (ISATAPv2)
within the CPE/ISP network. Think of VET as just ISATAP
plus support for router-to-router tunneling and multicast. 

>I will read more about VET tomorrow.

OK.

>address network overlaps on both sides of a CPE.

Right, and I don't see the disconnect.

>to do so is why we are having this discussion.

I'm not sure any upgrade is needed; only configuration.
I don't know enough about CPE to comment, but I believe
OS support is there already.

Fred