[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v6-v4 transition scenarios, take 2
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.