Subject: can we please postpone the ipv6 post-mortem?

From: james woodyatt <[email-masked]>
Date: Fri, 8 Oct 2010 10:02:32 -0700

everyone--

IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet.  The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4.

Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so "wrong" with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4->v6 transition start to happen?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 8 Oct 2010 17:53:06 +0000

+1

On 10/8/10 1:02 PM, "james woodyatt" <[email-masked]> wrote:

>everyone--
>
>IPv6 may have been born with a developmental disability, but we're not
>dealing with a corpse yet.  The patient is still alive, getting better,
>and with a bit of love and proper care, might yet grow up to make better
>and brighter music than IPv4.
>
>Maybe I'm being overly sentimental and using anthropomorphism
>inappropriately here, but really folks-- isn't it a bit unseemly to be
>arguing over how we went so "wrong" with IPv6-- and how we could do ever
>so much better the *next* time we get to reinvent the Internet if we
>avoid all the killing mistakes we made in bringing IPv6 up-- while there
>are, today, more people than ever before taking what are perceived to be
>enormous risks actually making the v4->v6 transition start to happen?
>
>
>--
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: David Conrad <[email-masked]>
Date: Fri, 8 Oct 2010 08:20:04 -1000

On Oct 8, 2010, at 7:02 AM, james woodyatt wrote:
> isn't it a bit unseemly to be arguing over how we went so "wrong" with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4->v6 transition start to happen?

You're just setting things up for more 'I told you so's when the routing system falls over as all those folks add (not transition) IPv6 to their announcements... :-)

Regards,
-drc

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 8 Oct 2010 15:03:53 -0400

+1

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Oct 2010 08:36:08 +1300

Another +1 from me.

And with respect to the alleged mistake made 15 years ago, two facts
may help:

1. The transition model was complete - because it was based on vendors
and ISPs supporting dual stack globally well *before* IPv4 exhaustion.
It's because that didn't happen that we have a bit of a panic now.
It didn't happen because short term economic incentives triumphed
over enlightened self interest. Fine, lesson learned, let's
move on, which the ISPs are now doing.

2. There is, mathematically and logically, no 'backwards compatible'
IP with bigger addresses than IPv4. That's because IPv4 doesn't
contain any provision for extensible addresses.  So please let's
not hear complaints that IPvN isn't backwards compatible; it never
could have been and never will be, and that is the fault of
the IPv4 design. So the issue of interworking between legacy
IPv4-only systems and the world of bigger addresses is an
unavoidable fact of the physical universe. Which is why BEHAVE
is currently doing NAT64.

Regards
   Brian Carpenter

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Oct 2010 15:38:41 -0400

On 10/8/10 1:02 PM, "james woodyatt" <[email-masked]> wrote:

> everyone--
> 
> IPv6 may have been born with a developmental disability, but
> we're not dealing with a corpse yet.  The patient is still
> alive, getting better, and with a bit of love and proper
> care, might yet grow up to make better and brighter music
> than IPv4.
> 
> inappropriately here, but really folks-- isn't it a bit
> unseemly to be arguing over how we went so "wrong" with
> IPv6-- and how we could do ever so much better the *next*
> time we get to reinvent the Internet if we avoid all the
> killing mistakes we made in bringing IPv6 up-- while there
> are, today, more people than ever before taking what are
> perceived to be enormous risks actually making the v4->v6
> transition start to happen?

James, I don't see this as a post-mortem.  I still expect to see
IPv6 widely deployed and certainly do not agree with anyone who
thinks it is time to pull the plug on it (or that we should have
done so several years ago).  However, I believe that the essence
of competent engineering involves trying to see whole systems,
to understand risk factors and make contingency plans, and to be
sure that we are not responding to transitional issues with
wishful thinking alone.  I don't think we are doing some of
those things as well as we need to.  I also think we have made
some assumptions along the way that come close to the old
cartoon about how one gets from Step 3 to Step 5 by writing down
"magic happens" or pretending that it is somehow intuitively
obvious.

While I can't speak for anyone else, I see my comments as a plea
that we not try to solve problems by stuffing our heads in the
sand like the proverbial ostrich, hoping that the problems will
have magically disappeared by the time we pull it out.  I think
that is important whether one's favorite problem from which to
try to hide is the danger of routing collapse when both IPv4 and
IPv6 addresses need to be advertised; the inability of
applications to meet implicit IPv6 assumptions about choices of
addresses and, through them, routes; our inability to get rid of
NATs or applications-layer knowledge of addresses or to design
better ways to co-exist with them; or something else.  

While I wish there were a lot less apparent rancor and "I told
you so" tone in this conversation, I don't believe that the
underlying issues can be dismissed by talking about what is, or
is not, "seemly" or by keeping silent because a lot of folks are
making major investments.  My hope is that, by asking these
questions now, we can be certain that all of the other ducks are
lined up to make IPv6 --as seen by the users and those who sign
the checks -- work really well after we get past the stages with
which those investments are involved.   And, again, I think that
is ultimately an optimistic message about our finally doing good
and realistic engineering to finish the puzzle of which IPv6
itself is a critical component, not a post-mortem on IPv6.

best,
   john

---

From: Bob Hinden <[email-masked]>
Date: Fri, 8 Oct 2010 13:56:45 -0700

+1 

Bob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Oct 2010 13:06:53 -0400

What if the key to IPv6 deployment is the realization that IPv6 can only be
deployed after we have solved the IPv4 address exhaustion problem?

On Fri, Oct 8, 2010 at 1:02 PM, james woodyatt <[email-masked]> wrote:

> dealing with a corpse yet.  The patient is still alive, getting better, and
> with a bit of love and proper care, might yet grow up to make better and
> brighter music than IPv4.
>
> arguing over how we went so "wrong" with IPv6-- and how we could do ever so
> much better the *next* time we get to reinvent the Internet if we avoid all
> the killing mistakes we made in bringing IPv6 up-- while there are, today,
> more people than ever before taking what are perceived to be enormous risks
> actually making the v4->v6 transition start to happen?
>
>
> --

-- 
Website: http://hallambaker.com/

---

From: Martin Rex <[email-masked]>
Date: Sat, 9 Oct 2010 00:42:38 +0200 (MEST)

> and ISPs supporting dual stack globally well *before* IPv4 exhaustion.

Huh?  Hardly anyone support IPv6 these days.

Sony KDL40*X70* internet-enabled LED-LCD-TV, 2010, IPv4-only (bought 7/2010)

Western Digital MyBookWorld2 HomeNAS, 2009, IPv4-only

Nintendo WII appears to be IPv4-only

> 95% of all home-DSL-Routers in Germany IP (100% from the folks I know)
  are IPv4 only.

most home users in Germany can not even get IPv6 from their ISP,
even when they had an IPv6-capable DSL-router.

What capabilities there are available on the internet backbone
or what could be enabled on newer operating systems by sophisticated
end users doesn't matter much, if most of the "internet-enabled"
end user equipment, that is being sold to consumers, is still IPv4-only.

What we desperately need is factory-enabled transparent
internetworking on all _NEW_ networking equipment and internet-enabled
gadgets and appliances.  As long as IPv4 and IPv6 are seperate worlds
the hen-and-egg stalemate is going to continue.  And the useful
lifetime of all brand-new IPv4-only equipment that is produced by
the electronic entertainment industry is about 5-15 years.

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 09 Oct 2010 08:26:17 +0900

> And with respect to the alleged mistake made 15 years ago, two facts

You are saying it's not post-mortem but vivisection. OK.

> IP with bigger addresses than IPv4.

Your statement is unfounded.

Port restricted IP is the mathematical and logical IP with bigger
*APPLICATION* address than IPv4 with full backward compatibility.

> So the issue of interworking between legacy
> unavoidable fact of the physical universe.

As the address space for transport and application layers is
address+protocol+port, the space is identical with both IPv4 and
port restricted IPv4. Thus, iterworking between IPv4 and PR-IPv4
just works.

> Which is why BEHAVE is currently doing NAT64.

With the existence of PR-IPv4, IPv6 including NAT64 is denied,
mathematically and logically.

						Masataka Ohta

---

From: Peter Dambier <[email-masked]>
Date: Sat, 09 Oct 2010 01:49:11 +0200

> even when they had an IPv6-capable DSL-router.

Curiously enough, our biggest and almost monopoly because most
others depend on them - dtag.de - released:

first half of 2011 they will start upward and peering IPv6.
Second half of 2011 everybody will be connected dual stack
and fixed addresses for both IPv4 and IPv6.

There is rumour that home users will get IPv4 addresses only
in the 10.x.x.x address space. IPv6 will be /56.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Oct 2010 13:23:45 +1300

> Huh?  Hardly anyone support IPv6 these days.

Sorry Martin, to write it more clearly:

The transition model in 1995 was based on the assumption that vendors
and ISPs would support dual stack globally well *before* IPv4 exhaustion.

The fact that this did not happen is the problem.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Oct 2010 17:45:29 -0700

> Huh?  Hardly anyone support IPv6 these days.

Well, the "hardly anyone" seems to include all Windows, Macosx, Linux, and Freebsd-based products, and routers from any vendor you care to name. But "hardly anyone" includes Canon printers like the one sitting next to me, all products from Sony that have a network interface (think Blue-Ray players, PS2, PS3, ...), Ericsson and Nokia telephones, Android 2.1 and later, iPhone OS 4 (in which it apparently can't be turned off), 

Yes, CPEs are a problem right now. Look for that to change.

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Oct 2010 17:50:25 -0700

> in the 10.x.x.x address space. IPv6 will be /56.

That's not limited to Germany. Would that dtag.de would use 172.16/12 rather than 10/8 or 192.168/16, as the latter two seem to find their way into so many home configurations. Having the same prefix on each side of the residential NAT could be a real pain...

---

From: "Michel Py" <[email-masked]>
Date: Fri, 8 Oct 2010 19:44:00 -0700

> Brian E Carpenter wrote:
> The transition model in 1995 was based on the assumption
> that vendors and ISPs would support dual stack globally
> well *before* IPv4 exhaustion. The fact that this did
> not happen is the problem.

Indeed. Unfortunately the NASDAQ went from ~800 in 1995 to peak at 5050
on March 10, 2000, leading everyone in the Internet thing for these 5
years to get used to unlimited money pouring from the sky. In the
economy at the time, the cost to dual-stack seemed bearable.

After it fell back below 2000 in 2001 and below 1500 in 2003, the game
changed. The ISP business model changed (at least the AOL-like model);
the customer business model changed too.
Today NASDAQ closed at 2401.91, less than half what it at peek was 10.5
years ago.

No bucks, no Buck Rogers.

Michel.

---

From: Martin Rex <[email-masked]>
Date: Sat, 9 Oct 2010 04:47:22 +0200 (MEST)

Fred Baker wrote:
> Well, the "hardly anyone" seems to include all Windows, Macosx,

50% of windows is on WindowsXP where IPv6 is off by default.

On home networks, DHCP on 192.168.x.x is the norm in Germany,
and when the DSL-router doesn't give out IPv6 addresses,
it doesn't matter whether your Windows7, Mac OS-X, Linux or FreeBSD
could use it -- it simply will not get it.

> Linux, and Freebsd-based products, and routers from any vendor
> you care to name.

Western Digital MyBook World 2 runs Linux and is IPv4-only

A very popular and very commonly used family of home DSL routers
in Germany ("Fritz") runs Linux and is IPv4-only -- only the
two newest models have sufficient resources and a beta-firmware
with IPv6 for download.

My DVB-S Receiver runs Linux and is IPv4 only.

> But "hardly anyone" includes Canon printers like
> the one sitting next to me, all products from Sony that have a network
> interface (think Blue-Ray players, PS2, PS3, ...),

*MY* brand-new Sony LED-LCD-TV has a RJ45 FastEthernet port and is IPv4-only

> Yes, CPEs are a problem right now. Look for that to change.

Admittedly, I'm IPv4-only myself.  I now little more about IPv6 than
that it uses an 128-bit address field and visualized with
hex-quads and colons instead of dotted decimal.

When I recently heard about dual-stack connectivity issues and
proposed app-level workarounds, I really started wondering whether
the existing worlds-apart approach of v4/v6 is part of the problem
rather than part of the solution.

A suggestion that an app should use two threads, look up the
seperate IPv4 and IPv6 address of the target and start two
seperate parallel connect()s for v4 and v6, my high expectations
about IPv6 were unexpectedly floored.

Seperate Addressing and seperate routing for IPv4 and IPv6 doesn't
seem right.  There should be a single transparent addressing
and routing scheme and a smooth migration.

Migration from PSTN to VoIP worked much better conceptually.
And it is up to the network to decide which intermediate links
use which technology, it doesn't (and shouldn't) matter to the
end nodes.

Would it really be so difficult to upgrade large parts of the
backbone to v6-only traffic and v6-only node addresses while
retaining the ability to route ipv4 datagrams across?

For a migration, it might also help not having to select either v4 or v6
at the end node, but instead run with both addresses on each
datagram, something like a reduced (96-x)IPng address space _plus_
a traditional IPv4 address to compose a single 128-bit address and let
the network and network stack figure out whether new addressing works.
i.e. each network interface with only a single address (IPv4, IPng
or composite IPv5+IPng) rather than two seperate addresses IPv4 and IPv6.

-Martin

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 16:16:33 +0200

Le 8 oct. 2010 à 19:02, james woodyatt a écrit :

> Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks

> -- isn't it a bit unseemly to be arguing over how we went so "wrong" with IPv6--

100% agreement

It's time to use all what already works.

It's also time to complete what already works with pieces that miss to quickly extend IPv6 use to more configurations.

> and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up--

> while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4->v6 transition start to happen?

It should be largely advertised that, v4->v6 transition HAS started (fortunately, not everybody is lagging behind):
- Since 2008, many users whose service providers offer IPv6 automatically access Google servers in IPv6.
- For the still numerous applications that are reachable only in IPv4, they didn't lose any IPv4 connectivity. 
- No NATs being traversed in IPv6, Google applications that use many parallel TCP connections have no risk, for these users, to encounter any port shortage in any traversed NAT.

Kind regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 16:30:26 +0200

Le 8 oct. 2010 à 19:06, Phillip Hallam-Baker a écrit :

> What if the key to IPv6 deployment is the realization that IPv6 can only be deployed after we have solved the IPv4 address exhaustion problem?

IPv6 HAS ALREADY BEEN deployed where there was absolutely no address exhaustion problem.
RFC 5569, at least its introduction, is useful reference material in this respect, to be read or re-read.

The key is IMHO to keep things as simple as they can be in each particular context. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 16:40:22 +0200

Le 9 oct. 2010 à 02:50, Fred Baker a écrit :
>> That's not limited to Germany. Would that dtag.de would use 172.16/12 rather than 10/8 or 192.168/16, as the latter two seem to find their way into so many home configurations.

> Having the same prefix on each side of the residential NAT could be a real pain...

With my understanding of how NATs work, I don't see why.
Could you elaborate?

Regards,
RD

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Oct 2010 23:48:55 +0900

> It's time to use all what already works.

That is, use IPv4 with or without port restrictions.

> It's also time to complete what already works with pieces that
> miss to quickly extend IPv6 use to more configurations.

See above.

> It should be largely advertised that, v4->v6 transition HAS started
> (fortunately, not everybody is lagging behind):

It has been starting for these 15 years.

						Masataka Ohta

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 17:14:57 +0200

> The fact that this did not happen is the problem.

Agreed.

Yet, the IETF has been IMHO, and to some extent still is, too slow to clarify the difference between DUAL-STACK SERVICE and DUAL-STACK ROUTING.

In the absence of IPv6 service to hosts, generalized IPv4 address sharing will lead to port shortage, and will PROGRESSIVELY lead to intermittent and random connectivity breakages (the worse kind).
With native IPv6 addresses offered to hosts (i.e. with THE IPv6 service), port shortages are completely avoided for all e2e IPv6 connections. (Besides, the danger of port shortages for the residual IPv4 traffic is consequently mitigated on paths that support the IPv6 service).

Consequently, what users urgently need is DUAL-STACK HOSTS, with all the useful ways for their ISPs to assign them native IPv6 addresses (i.e. to offer IPv6 service).
On the other hand, dual-stack routing isn't urgent, and may even, for some ISP, never need to be deployed.
(They can first tunnel IPv6 across IPv4, and later directly move to residual IPv4 across IPv6-only).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 17:25:58 +0200

> could use it -- it simply will not get it.

That's precisely the configuration for which Brian Carpenter, Sheng Jiang, and myself, propose 6a44 (a stateless and simple approach to offer native IPv6 across NAT44 CPEs).
The more it is understood that it can accelerate ubiquitous IPv6 availability in hosts, the more chances there are of having it quickly in vendor OSes.

Regards,
RD

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 14 Oct 2010 16:47:20 -0700

> With my understanding of how NATs work, I don't see why.

I can cause problems, it doesn't have to... there's a reason why nat
rewriting occurs before forwarding in for example linux iptables.

if you expect to connect to host in a overlapping assignment you're
going to have a problem but I think that's assumed.

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Oct 2010 23:34:54 -0700

> going to have a problem but I think that's assumed.

Yes. The simplest case is: the host you want to contact has the same address that your host does. Widen that to: the host you want to contact has an address that happens to also exists in your routing domain. In such cases, the datagram you send will not go to the NAT.

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Oct 2010 09:14:17 +0200

> going to have a problem but I think that's assumed.

Reaching hosts beyond a NAT44 should quite naturally be done only with global IPv4 addresses.
Problems can occur with some CPEs that don't comply with RFC 5382, and maybe with misconfigured split DNSs, but this isn't IMHO sufficient a reason to ban some configurations that do work today. (AFAIK, some mobile phones include NAT44s, and work on mobile networks that assign 10.x.y.z addresses).
Bugged CPEs should be fixed or replaced (BTW is there some indication of which proportion of the installed base can't work with possible external/internal address overlaps?)  

In my understanding, although NAT444 + 6rd is far from being the only model to offer IPv6 service while dealing with the IPv4 address shortage, IT IS a deployable approach. 
For some ISPs, it has a very good performance/cost ratio.

Regards,
RD

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 15 Oct 2010 09:25:09 +0200

> With my understanding of how NATs work, I don't see why.

Admin pain.

Many unixes today let you configure the same IP/netmask on two 
interfaces, and it can be used (don't ask, ok?), and it works as long as 
it works, but as soon as you get a problem it's a hard one.

(Btw, I've seen NATs that reject/discard all packets coming in on the 
world interface with source addresses in the inside-NAT range.)

Arnt

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 15 Oct 2010 17:29:22 +0900

Remi Respres wrote:

I acknowledge that NAT444 does not use two levels of private
networks, which makes me not sure what your point is.

> (AFAIK, some mobile phones include NAT44s, and work on mobile
> networks that assign 10.x.y.z addresses).

I'm afraid the mobile phone with an external IP address of 10.1.2.3
will likely to have difficulties if its internal client also have
the IP address of 10.1.2.3.

> Problems can occur with some CPEs that don't comply with RFC 5382,

RFC5382 is, by no means, a deployed standard.

> In my understanding, although NAT444 + 6rd is far from being the
> only model to offer IPv6 service while dealing with the IPv4
> address shortage, IT IS a deployable approach.

That's an argument similar to ones heard for these 15 years.

						Masataka Ohta

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Oct 2010 10:54:48 +0200

> RFC5382 is, by no means, a deployed standard.

Not even a standard-track document (but nevertheless useful to comply with).

Beside, assuming that ISPS assign 10/8 IPv4 addresses, the only customers to be concerned seem to be those:
- whose NAT doesn't comply with RFC 5382
- assign 10/8 addresses internally (not typical for default behaviors of unmanaged CPEs)

> That's an argument similar to ones heard for these 15 years.

Which, of course, isn't sufficient for it to be wrong.

RD

---

From: Stefan Winter <[email-masked]>
Date: Fri, 15 Oct 2010 11:22:24 +0200

Hi,

> Sony KDL40*X70* internet-enabled LED-LCD-TV, 2010, IPv4-only (bought 7/2010)

My TV is "bought 2009" and doesn't have any internet at all. And I don't 
care (much). It's a TV. Of all my gadgets, the TV is on my lowest 
priority for getting an IPv6 connectivity.

> Western Digital MyBookWorld2 HomeNAS, 2009, IPv4-only

I don't mean to criticise your buying decision, but if you are so 
serious about IPv6 connectivity, why didn't you just buy a QNAP device? 
Comes with IPv6 just fine.

> Nintendo WII appears to be IPv4-only

I do mean to criticise your buying decision: Playstation rocks :-) No, 
it won't give you IPv6 either; but it gets close to the TV argument. 
Probably my PS3 and TV will be dead (or administratively obsoleted) 
before I get headaches about them not reaching IPv6-only Firmware Update 
services etc. - because these devices still do dual-stack just fine.

> even when they had an IPv6-capable DSL-router.

Excuse me, but this is completely 1990s argumentation. I have native 
IPv4+IPv6 with a commodity DSL provider since years. 2006, IIRC. And my 
own /48 with it. And the operator works Germany wide. With reasonable 
costs; my flatrate costs 9,50 EUR per month (though that's a legacy 
tariff, you can't order it any more). If you want IPv6, just go order 
it. I keep hearing this very argument over and over again - and it is 
simply not at all true; at least not in Germany.

I'm not affiliated with the provider, other than being a satisfied 
customer: http://www.titan-dsl.de

> end user equipment, that is being sold to consumers, is still IPv4-only.

Windows 7: enabled by default. Mac OS: enabled by default. Linux: 
whatever your distro does. I fail to see your point.

> the electronic entertainment industry is about 5-15 years.

The main point that needs attention is router equipment, IMHO. There's a 
Fritz!Box beta firmware for IPv6 right now; when it's final, pushing 
that out will fix the deployment of IPv6 for most of Germany (as they 
happen to be quite popular there).

Dates are arguable, but: I suspect it will be + 15 years before content 
providers will switch to IPv6-only. If they do so before, this will 
reduce the "useful lifetime" of your already-bought electronics a bit. 
Hooray for the industry: they can sell new stuff to you then. That kind 
of thinking is probably not what you as a customer appreciate, but it's 
just fine if seen from the other side :-)

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 15 Oct 2010 22:06:58 +0900

> Not even a standard-track document (but nevertheless useful to

A BCP is a standard document of IETF, which has little influence
over NAT.

> Beside, assuming that ISPS assign 10/8 IPv4 addresses, the only
 > customers to be concerned seem to be those:

 > behaviors of unmanaged CPEs)

Hmmmmm,

You, perhaps, are worrying about deployment of NAT444 by Softbank
BB, which is, perhaps, the largest ISP in the world, using not
ISP independent addresses nor ISP shared addresses of NAT444 but
10/8 for its internal network.

But as its CPEs are fully under the control of it, it can arrange
so that the private network behind CPEs does not use 10/8.

> Which, of course, isn't sufficient for it to be wrong.

Well, NAT444 with LSN is not a good idea, because ISP internal
network can not be multihomed to external networks. It's a lot
more straight forward to use plain routers between ISP internal
and external networks. Or, if an LSN box fails, all the connections
will be lost, whereas if one of a router between the internal
and external networks fails, alternative routes will be used
without breaking external connections.

That is,

	External --- LSN --- ISP internal --- CPE --- customer private

is a lot less robust (prohibitively less robust, if you are a
serious IPv4 ISP) than

	External \
                    \
                      \
                        \
	External --- ISP internal --- CPE --- customer private
                        /
                      /
                    /
	External /

6rd?

Stateless 6 to 4 should be able to have multiple gateways with
the latter configuration.

						Masataka Ohta

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Oct 2010 16:34:38 +0200 (MEST)

> whatever your distro does. I fail to see your point.

Windows XP: disabled by default.  Has been sold on the majority of
Netbooks well into 2010, and Netbooks were 1/3rd of the PC sales.

> happen to be quite popular there).

IPv6-capable beta firmwares for Fritz DSL-routers exist only for the
two most recent models 7390 and 7270(v?).  Other models (like the 7112/7113)
or 7170, 7150) do *NOT* have sufficient resources to run IPv6 -- their
flash memory is close to full as well as their RAM when they're running.

-Martin

---

From: Stefan Winter <[email-masked]>
Date: Mon, 18 Oct 2010 10:08:34 +0200

Hi,

> Netbooks well into 2010, and Netbooks were 1/3rd of the PC sales.

By the time end consumers feel an actual *need* to run IPv6, popular 
computer magazines will have the "hot, new, hacker trick" 'cmd' -> 'ipv6 
install'.
But by that same time, people will probably not even remember the 
acronym "XP". Hopefully so, for all of us :-)

> flash memory is close to full as well as their RAM when they're running.

So you need to buy new IT equipment every n years, where "n" is by 
preference (for the vendor) a low number? I'm shocked. BTW, switching 
your DSL contract after the 2-year-handcuff of your favourite operator 
will give you a new model for free.

Stefan

Tel: +352 424409 1
Fax: +352 422473