home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   IPV6      The convoluted hot-mess that is IPV6      4,612 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,581 of 4,612   
   Alexey Vissarionov to Victor Sudakov   
   Two ISPs and backup for a home network (   
   04 Jul 21 17:27:22   
   
   REPLY: 2:5005/49 60e14ba9   
   MSGID: 2:5020/545 60e1ce69   
   CHRS: CP866 2   
   TZUTC: 0300   
   Good ${greeting_time}, Victor!   
      
   04 Jul 2021 12:44:50, 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 their   
    VS>>>>> outgoing src address?   
    AV>>>> This is the preferred mode of operation   
    AV>>>> 1. All hosts in the LAN must be able to do the switching|balancing   
    AV>>>> on thy own   
    AV>>>> 2. This may require some manual 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.   
      
   In general, IoT devices should reside in a separate VLAN without any access to   
   outer world. Whether you need to access any of them from outside, you have SSH   
   running on the gateway for that.   
      
    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?   
      
   FTP is dead. SIP clients normally use only LAN (everything else should be   
   performed by a gateway).   
      
   Well, I can imagine a SIP client connecting to the corporate SIP PBX. To work   
   properly in a multi-link environment, it have to establish _two_ connections   
   for the SIP control channels. Software PBXes (Asterisk and some others) are   
   known to work. Clients running on a PDAs are unlikely.   
      
    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 more   
    VS> advanced and interesting?   
      
   Trivial per-interface VRF.   
      
      
   --   
   Alexey V. Vissarionov aka Gremlin from Kremlin   
   gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii   
      
   ... god@universe:~ # cvs up && make world   
   --- /bin/vi   
    * Origin: ::1 (2:5020/545)   
   SEEN-BY: 1/123 30/0 80/1 90/1 105/81 120/340 123/131 124/5016 154/10   
   SEEN-BY: 203/0 221/0 1 6 226/30 227/702 229/424 426 550 700 1016 240/1120   
   SEEN-BY: 240/5832 249/206 317 400 261/38 280/464 5003 5006 5555 282/464   
   SEEN-BY: 282/1038 292/854 8125 301/0 1 101 113 812 310/31 317/3 322/757   
   SEEN-BY: 342/200 423/120 460/58 633/280 712/848 770/1 920/1 2452/250   
   SEEN-BY: 5020/545 736 1042 5058/104   
   PATH: 5020/545 280/464 301/1 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca