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.

   RBERRYPI      Support for the Raspberry Pi device      21,939 messages   

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

   Message 21,776 of 21,939   
   The Natural Philosopher to All   
   Re: RPi associating two IPs with its one   
   01 Jan 26 12:09:50   
   
   MSGID: <10j5o6e$3etcd$2@dont-email.me> 24f5d47f   
   REPLY:  7e99fc3b   
   PID: PyGate 1.5.2   
   TID: PyGate/Linux 1.5.2   
   CHRS: CP1252 2   
   TZUTC: 0000   
   REPLYADDR tnp@invalid.invalid   
   REPLYTO 3:633/10 UUCP   
   On 01/01/2026 11:34, Richard Kettlewell wrote:   
   > The Natural Philosopher  writes:   
   >> On 31/12/2025 20:18, Richard Kettlewell wrote:   
   >>> Pancho  writes:   
   >>>> The Natural Philosopher wrote:   
   >>>>> David Higton wrote:   
   >>>>>> What I particularly like about IPv6 is that NAT/NAPT are simply not   
   >>>>>> necessary   
   >>>>> So making the implementation of a firewall absolutely mandatory   
   >>>>>   
   >>>>   
   >>>> Linux IPv6 does appear to use random IPv6 address for outbound   
   >>>> connections, which have a limited lifespan. This appears to be   
   >>>> something like 1-7 days, but if very short lifespans were used it   
   >>>> could offer a protection similar to NAT. I need to investigate a bit   
   >>>> further, but I don't think IPv6 needs to be inherently less safe.   
   >>>   
   >>> NAT does not offer any protection. The reason that a typical domestic   
   >>> NAT-equipped router protects you from inbound connections is that it   
   >>> has a firewall as well.  (Getting a packet addressed to your internal   
   >>> addresses to your external interface is inconvenient for many   
   >>> attackers, for sure, but straightforward for your ISP or anyone who   
   >>> can hack or coerce them.)   
   >>   
   >> How?   
   >> Genuine question.   
   >    
   > Same as routing any other packet. Make sure there?s an appropriate   
   > routing table entry for the customer addresses on the ISP?s   
   > customer-facing router (and whatever intermediate routers there are   
   > between that and the attack source), then call socket/connect/write.   
   >    
   > The question is then what the customer router does with it.   
   >    
   > * If it follows the strong end system then the packet is discarded   
   >    before NAT even comes into the question.   
   >    Linux follows the weak end system model by default, so this   
   >    possibility doesn?t apply to Linux-based router unless someone has   
   >    taken the trouble to change its behavior somehow.   
   >    
   > * If there?s a basically competent firewall on the customer router then   
   >    the packet is discard by that.   
   >    
   > * If there?s a NAT then it gets to look at the packet, but it won?t   
   >    match any of the rules that enable translation, so it will not be   
   >    modified at this stage.   
   >    
   Ah. I misunderstood your original post.  Sure the ISP can send an    
   internally addressed packet to your router. If it wants to lose its    
   customer base.   
      
   But will that get forwarded along?   
      
   > * All that?s now left is normal routing, so the packet passes on to its   
   >    destination on the customer network.   
   >    
   > https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.   
   >   
   I can't believe that my router  would accept arbitrary  packets with an    
   internal destination address on its external facing port...if the    
   destination is not in its tables, it will be automatically discarded...   
      
      
      
   --    
   "In our post-modern world, climate science is not powerful because it is    
   true: it is true because it is powerful."   
      
   Lucas Bergkamp   
      
      
   --- PyGate Linux v1.5.2   
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)   
   SEEN-BY: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700   
   SEEN-BY: 226/30 227/114 229/110 112 134 200 206 275 300 317 400 426   
   SEEN-BY: 229/428 470 616 664 700 705 266/512 291/111 292/854 320/219   
   SEEN-BY: 322/757 342/200 396/45 460/58 633/10 280 414 418 420 422   
   SEEN-BY: 633/509 2744 712/848 770/1 902/26 2320/105 5020/400 5075/35   
   PATH: 633/10 280 229/426   
      

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


(c) 1994,  bbs@darkrealms.ca