REPLY: 2:5020/545 60e1ce69
MSGID: 2:5005/49 610aadfa
CHRS: CP866 2
TZUTC: 0700
TID: hpt/fbsd 1.9.0-cur 2019-12-05
Dear Alexey,

04 Jul 21 17:27, you wrote to me:

 VS>>>>>> I know that my home router can advertise multiple global IPv6
 VS>>>>>> prefixes into the LAN, but how will LAN hosts failover to the
 VS>>>>>> backup gateway if the primary ISP fails? They will have IPv6
 VS>>>>>> addresses from both blocks, which should they choose for
 VS>>>>>> their outgoing src address?
 AV>>>>> This is the preferred mode of operation
 AV>>>>> 1. All hosts in the LAN must be able to do the
 AV>>>>> switching|balancing on thy own 2. This may require some manual
 AV>>>>> configuration on every of them.
 VS>>>> This is not feasible because most of those LAN hosts are
 VS>>>> smartphones, smart TVs, vacuum cleaners, cameras and other IoT
 VS>>>> devices.
 AV>>> Most of these devices have Linux kernel, but crippled userspace.

 AV> In general, IoT devices should reside in a separate VLAN without any
 AV> access to outer world.

Most of the value of IoT devices depends on their access to the outer world.
By denying them access, you lose this value.

 AV> Whether you need to access any of them from
 AV> outside, you have SSH running on the gateway for that.

Who in their right mind would access their smart vacuum cleaner, thermostat or
security camera by SSH? I want the vaccuum cleaner to notify me on the mobile
app when it's finished or stuck.

I can agree that ingress access to the IoT device network is usually
unnecessary, egress access is enough for them.

 VS>>>>>> With two IPv4 ISPs and NAT, the setup is rather trivial,
 VS>>>>>> outgoing connections will work via either of the ISPs because
 VS>>>>>> the hosts needn't be aware of the failure, and their src
 VS>>>>>> private IP is always the same. Can anyone enlighten me?
 AV>>>>> This is second option, but you'd lose the main advantage of
 AV>>>>> IPv6: the use of publicly routed addresses.
 VS>>>> Indeed. I don't like the idea of using NAT in IPv6 even if I
 VS>>>> could. So what's the solution?
 AV>>> For dumb devices, especially portable, I'd suggest using NPT.
 VS>> How well does NPT (being stateless) work with FTP, SIP and other
 VS>> protocols which embed addresses into payload?

 AV> FTP is dead.

It is not. You just don't know.

 AV> SIP clients normally use only LAN (everything else should
 AV> be performed by a gateway).

Tell that to sipnet.ru and many other VoIP providers. I've seen even
semi-private VoIP networks (for admins) working over the Internet.

 AV> Well, I can imagine a SIP client connecting to the corporate SIP PBX.
 AV> To work properly in a multi-link environment, it have to establish
 AV> _two_ connections for the SIP control channels.

May be so, if a SIP client itself is multihomed. In this case, it may survive
the disconnection of one of the uplinks, is that what you mean?

 AV>>> Fully functional computers may be connected to some other VLANs
 AV>>> (two at once in your case) and configured to use real addresses.
 VS>> Speaking of those fully functional computers in the LAN, do you
 VS>> mean the setup when there is a script pinging some outside hosts/
 VS>> interfaces and modifying the IPv6 routing table, or something
 VS>> more advanced and interesting?

 AV> Trivial per-interface VRF.

And how do applications (e.g. a Web browser) decide which VRF to use for
outgoing connections? If one of the VRFs has no connection to the Internet, as
was the original question. The application must know that this VRF is
currently "disconnected" and act accordingly, how do you handle that?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20170303-b20170303
 * Origin: Ulthar (2:5005/49)
SEEN-BY: 1/123 30/0 50/109 80/1 90/1 105/81 120/340 123/131 154/10
SEEN-BY: 221/1 6 226/30 227/702 229/424 426 428 550 700 1016 240/1120
SEEN-BY: 240/5832 249/206 317 400 261/38 280/464 5555 282/464 1038
SEEN-BY: 301/0 1 101 113 812 317/3 322/757 342/200 460/58 463/68 467/239
SEEN-BY: 467/888 633/280 712/848 920/1 5000/111 5001/100 5005/49 53
SEEN-BY: 5015/46 5020/715 830 846 1042 2047 2140 4441 5053/54 5058/104
SEEN-BY: 5064/56 5083/1 444
PATH: 5005/49 5020/1042 301/1 229/426