[ale] IPv4 devices on IPv6 network

[Alex Carver]

On 6/30/2012 05:46, Michael H. Warfield wrote:
> On Fri, 2012-06-29 at 22:37 -0700, Alex Carver wrote:
>> On 6/29/2012 22:20, mike at trausch.us wrote:
>>> On 06/30/2012 01:10 AM, Alex Carver wrote:
>>>> Everything I've searched for with whatever Google-fu I could use
>>>> indicates I'll need to perform translation using NAT64 or equivalent but
>>>> there's nothing out there that says how this should be done specifically
>>>> (i.e. what magical incantations of iptables are needed if indeed
>>>> iptables is the eventual handler of this).  The various docs just say
>>>> "You need it".  Well no kidding.
>>>
>>> You can have your 10.0.0.0/8 as well as your IPv6 space.  That simply
>>> means that you'll need a DHCP server that hands addresses in that space out.
>>>
>>> You will also likely be able to keep at least a single IPv4 address from
>>> your ISP for quite some time, so you can still do normal IPv4 NAT for
>>> your RFC 1918 segment(s).
>>>
>>> You'll only need some form of proxy or protocol translator if you
>>> absolutely need to have the device(s) have IPv6 addresses and be able to
>>> communicate on the IPv6 network.  That would be a pain in the rear end,
>>> but it would work just fine for many types of protocols (e.g., not ones
>>> like SIP or FTP).
>
>> There's no guarantee I'll keep an IPv4.  This is both a home plan ahead
>> and a work plan ahead.  At home it's up to AT&T whether they give me an
>> extra IPv4 or not.  At work I likely wouldn't get the choice and get
>> handed an IPv6 and that's it.
>
> Actually, that's extremely unlikely to happen in our lifetimes.  You
> will continue to have (albeit fewer and fewer) IPv4-only devices but
> they will continue to exist.  I already have some devices (mostly
> Avocent IP KVMs) which can be IPv4 or IPv6, but not both (sucks but
> their firmware is horrible anyways).  And we may, in the future, see
> some IPv6 only devices start showing up, but I doubt that will happen
> anytime soon.

[snip]

> IPv6 will deliver those services that will not longer work over multiple
> layers of NAT / CGNAT, but the basic stuff will continue to work for
> IPv4 and it's not going away anytime soon.  IPv6 isn't even in full
> saturation deployment yet and may be decades away from that even still.
> 20 or 30 years from now we'll still find IPv4 squatting on our networks
> like an ugly step child that just will not move out.

The problem I have is that the devices would need to be available to an 
IPv6 client and not necessarily one in which they're willing (or able) 
to install any tunneling systems, dual stacks or anything else.  It 
would have to work for a native IPv6-only client.  So it's an IPv4 
server talking to an IPv6 client with something in between to make the 
transition.  The problem is that there is currently nothing I can find 
online that describes the device in the middle beyond the very basic 
statement that it translates from IPv4 to IPv6 (I'm comparing the level 
of documentation to something like NAT44 which has who knows how many 
millions of documents that describe what to do, how to do it, and where 
to get it).


Additionally, at least at work there may not be a choice for IPv6-only 
infrastructure.  All of the new hardware provided by IT supports IPv6 
(phones, computers, printers, etc.)  As far as they are concerned, the 
system is ready for a switchover.  However, it's the individual bits of 
hardware that a single user or group might get for the lab (data 
loggers, PLCs, whatever else) that won't support IPv6 but may still need 
to talk to a remote IPv6 machine for whatever purpose (usually for 
control purposes).

I suppose I'm taking the worst case situation and just planning (way) 
ahead but I don't want surprises.  With IPv4 NAT, I read ahead, learned 
how it was supposed to work, studied the magical incantations of 
iptables and had enough of an understanding that it didn't take long to 
fix an issue once I started using it.  Right now, these IPv4-IPv6 
translators are mythical beasts mentioned only once, very briefly with 
no real detail and never again discussed.