[arin-ppml] The non-deployment of IPv6
Lee Dilkie wrote:
> Steve Bertrand wrote:
>> Lee Dilkie wrote:
>>> Don't you essentially *have* multi-homing if you are dual-stack?
>> No. Multi-homing != dual stack. Dual stack can be as simple as having a
>> link local v6 address on your machine without even being able to see any
>> other v6 devices on the network.
> Baloney. A link local address isn't routeable and if that's all that you
> have bound to an interface, then you don't have IPv6 nor will the stack
> attempt to make any connections over IPv6.
what? If I have only a link local address, then I most certainly DO have
IPv6, and I can also tell my SSH client to talk to the machine beside me
using only link-local if I tell it the neighbours address:
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::207:e9ff:febe:43f%fxp0 prefixlen 64 scopeid 0x1
inet 184.108.40.206 netmask 0xffffff80 broadcast 220.127.116.11
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::2c0:f0ff:fe30:b41f%de0 prefixlen 64 scopeid 0x1
inet 18.104.22.168 netmask 0xffffff80 broadcast 22.214.171.124
cohiba% ssh -l steve fe80::2c0:f0ff:fe30:b41f%fxp0
The authenticity of host 'fe80::2c0:f0ff:fe30:b41f%fxp0
(fe80::2c0:f0ff:fe30:b41f%fxp0)' can't be established.
DSA key fingerprint is 24:a1:72:d8:3d:91:0e:c5:33:38:a2:af:9b:16:62:e1.
Are you sure you want to continue connecting (yes/no)?
I didn't say that link-local was routable. All I said was that having a
simple link-local address tells you that the machine you are on is
> "Multi-homing", the term, refers to multiple methods to access the same
> network resource. By that definition, dual-stack suffices. Whether it'll
> survive a physical outage is another matter.
Well, I always thought that when referring to "Multi-homing" on an ARIN
mailing list, most members would consider this in the context of:
An organization is multihomed if it receives full-time connectivity from
more than one ISP and has one or more routing prefixes announced by at
least two of its upstream ISPs.
...over a *single* protocol.
>>> If you
>>> are multi-homed on IPv4, you don't really need it on IPv6, do you?
>> Yes, you do (imho). The two are mutually exclusive, even if all of your
>> IPv6 transits are over v4 tunnels, redundant paths will better protect
>> you from having your v6 prefixes fall off the earth.
> And if they do? So what? Your IPv4 connection will be used with no loss
> of service. Isn't that what you are looking for?
No, what I am looking for is per-protocol redundancy. Switching back and
forth between v4 and v6 is not the type of redundancy that I am after at
It *is* a loss of service to me if I lose IPv6 connectivity. I have
clients that connect via IPv6, and some of my own services are v6 only.
>>> If an
>>> IPv6 route is unavailable, the connection will be established on IPv4.
>> ...and the time-out value in some applications (such as my preferred SSH
>> client for Windows) to fall-over to v4 can become frustrating. For a
>> content provider, the time for a browser to switch to v4 when the
>> providers internal v6 is unreachable could be potentially disasterous.
> I don't disagree that the timeouts can be annoying when there's a
> problem in the IPv6 route. So then, start by enabling it on smtp?
> Machines are patient and don't mind the 30 second timeout and will
> happily retry on IPv4.
Done. SMTP was the first user-facing service that I had converted.
>>> Multi-homing IPv6 will matter once IPv6-only networks get rolled out and
>>> I don't see that happening for some time yet.
>> I disagree completely. The same mentality that is applied to v4
>> resiliency should be applied all the same to v6. Not only that, it is
>> extremely easy to v6 multi-home, as there are several very large ISPs
>> who offer *free* peering/transit over tunnels that you can use in
>> conjunction with your existing providers. [plug: he.net].
> Got it, you don't want to roll out IPv6 and you need excuses to defend
> your position. Fine by me.
? I'm confused ;)