REPLY: 2:5001/100.1 60ddc92c   
   MSGID: 2:5005/49 60e14a9f   
   CHRS: CP866 2   
   TZUTC: 0700   
   TID: hpt/fbsd 1.9.0-cur 2019-12-05   
   Dear Dmitry,   
      
   01 Jul 21 16:46, you wrote to me:   
      
    VS>> The original IPv4 was also miserable with its classful networks,   
    VS>> RIPv1 etc. I still cannot imagine however what "real life"   
    VS>> problem they are solving by creating NAT for ipv6.   
      
    DP> For example - rerouting traffic via VPN to get thru RKN's DPI.   
    DP> Real life scenario :)   
      
   Why would you need NAT for that? Get a VPN/tunnel provider who offers a global   
   /64 or /56 or even a /48, like HE does.   
      
    DP>>> translation. It's much more lightweight and easy to implement.   
      
    VS>> Either you translate only the higher 64 bits of the address, or   
    VS>> the whole 128 bits of the address, you still rewrite the packet.   
    VS>> True, you don't do PAT, that's why I said that it looks like a   
    VS>> one-to-one IPv4 NAT (much like in AWS VPC "public" subnets).   
      
    DP> Yeah, but you can have "host" part the same for several uplinks and   
    DP> change prefix only on NPTv6 gateway. It's the best ipv6 can offer for   
    DP> you, sorry.   
      
   Too bad and a bit unexpected. There are/were rather complex things like Mobile   
   IPv6 and HMIP, and they have not thought of a simple failover?   
      
    VS>> Nope, but I think $subj can be implemented today, e.g. via some   
    VS>> field in RAs etc. In FreeBSD (and I'm sure in other IPv6   
    VS>> implementations) you can select the prerred source address, you   
    VS>> only have to add some way to change it automatically when a "dead   
    VS>> gateway" is detected.   
      
    DP> It adds more complexity and cannot be implemented easily in userland   
    DP> across multiple OSes.   
      
   OK, let's start anew with a simple setup. If there are two routers in a home   
   LAN advertising different global prefixes, and one of them goes offline, will   
   IPv6 end hosts detect that and remove the corresponding addresses from their   
   configuration?   
      
   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 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