ietf
[Top] [All Lists]

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

2010-10-11 10:26:43

Le 9 oct. 2010 à 04:47, Martin Rex a écrit :

Fred Baker wrote:

On Oct 8, 2010, at 3:42 PM, Martin Rex wrote:

Huh?  Hardly anyone support IPv6 these days.

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.


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



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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf