= Сообщение: 4678 из 7440 ============================================= IPV6 = От : Tony Langdon 3:633/410 24 Jul 17 21:59:00 Кому : Michiel van der Vlist 24 Jul 17 21:59:00 Тема : Re: The future of IPv4 (was: vanity mode engaged) FGHI : area://IPV6?msgid=3135.fido-ipv6@3:633/410+1ddb23b1 На : area://IPV6?msgid=2:280/5555+5975d40e = Кодировка сообщения определена как: ASCII ================================== Ответ: area://IPV6?msgid=2:280/5555+59761474 ============================================================================== -=> Michiel van der Vlist wrote to Tony Langdon <=-
MvV> I am a bit more optimistic. I expect that onc IPv6 becomes the dominant MvV> protocol, it will go very quick. In Belgium IPv6 already is the MvV> dominant protocol.
There's been hardly any movement at the retail end of the market here in years. :(
TL> Here, the situation is different. Few ISPs actually own access TL> infrastructure, and with the new national network rolling out, pretty TL> much all will be dependent on this network to reach their customers.
MvV> I think that is a good development. Here the owner(s) of the old copper MvV> originally designed for POTS are by law required to allow competitors MvV> to make use of the infrastructure. But oddly enough that does not apply MvV> to the coax cable originally designed for broadcasting TV. The owner of MvV> the coax has a monopoly on it.
That was the situation here, but the copper network is being replaced by the NBN, which is currently government owned. It will eventually be privatised. Some of the HFC cable TV networks are actually being incorporated into the new network, from what I understand.
TL> Still a good question. :) Not one I have to consider for quite a TL> while, though I have proven that as long as I have access to a public TL> IPv4 from _somewhere_, a tunnel will work, and I'm sure that will hold TL> even if I have to run my own NAT on the far end of the VPN.
MvV> So you are planning on supporting incoming IPv4 for as long as you can. MvV> If need be at extra cost.
Ham radio apps at a class lag behind, very few of them actually support IPv6, so there will be somewhat of a need - use IPv6 where I can, IPv4 where there's no other choice.
MvV> I am going the other way. I plan on fasing out IPv4 as soon as MvV> practical. Dual stack and DS-Lite are transition mechanisms. One can MvV> not switch from IPv4 to IPv6 overnight, because that would require all MvV> of the word wide internet to throw the switch at the same time. That is MvV> not going to work, so we need a period of overlap where both IPv4 and MvV> IPv6 are supported. But I am not a member of the "more is better club". MvV> Supporting two protocols in parallel increases the chance of bugs and MvV> the effort required to trace and fix them. Also I would gladly get rid MvV> of NAT. The sooner I can get rid of IPv4 the better I say. I encourage MvV> the use of IPv6. But when the IPv6 train really gets on steam, the next MvV> step would be to discourage the use of IPv4.
That is a sound plan. I'm not able to go there yet, because of thos whole class of IPv4 apps, and some of those being infrastructure, they face similar migration issues that their creators haven't yet started to address. :(
MvV> I have been running IPv6 via 6to4 tunnels for over half a decade. MvV> Technically the reverse, IPv4 via a 4to6 tunnel should work just as MvV> well. If need be, I will go that way. But that is plan C. Plan A is to MvV> have dual stack until my provider forces me to DS-Lite. My hope is that MvV> when that happens, I no longer need a public IPv4 address. Plan B is to MvV> switch provider.
MvV> I am exploring the options...
And I'm keeping mine open. :)
... Forbidden fruit is responsible for many a bad jam. --- MultiMail/Win32 v0.49 * Origin: Freeway BBS - freeway.apana.org.au (3:633/410)
