James, Let me see if I have the functional nature of RISP correct (haven't worked with it before):
1) The devices that RISP hosts have permanent non-routable IP address space. RFC 3103 says RFC 1918 space....I'm assuming this would by ULA space in IPv6. 2) The RISP Gateway has a pool of availble PA addresses that it can assign. 3) The RISP host negotiates a short lease (4 or 5 seconds) for one of these PA addresses from it's RISP gateway and binds it. 4) The RISP host then uses that PA address to communicate directly for the duration of the (4 or 5 second) lease. Is that essentialy correct? If it is, this leads me to a few questions... - Either the the RISP host must communicate with a communication partner that has a staticaly assigned IP to initiate a communication session or the RISP hosts must have some out-of-band method to exchanging thier leased IP info.... else how would one RISP host ever initiate a communication session with another? Furthermore, how would the recieving RISP host know to obtain a PA lease without some out of band method for communicating that it was about to recieve an incoming communication? - If there is some out-of-band regsitration of RISP hosts then that effectively defeats the purposes of "obscuring" the devices IP address since another RISP host can query the out-of-band service to obtain the IP address for each RISP host whenever it wants to do so. Although this might not be horrible depending upon the kind of security required to query the out-of-band service. - What happens when the RISP host recieves INBOUND communication on it's leased PA from a device which is not it's current communication partner? Under dynamic NAT this would go nowhere since there isn't an entry in the NAT flow table that corresponds to that session. Am I left with a single point of failure (my FW filter rules) for stopping these...or does the RISP gateway functionaly stop it? In effect, the only way I could see this practicaly working would be if the RISP effectively permanently held open a lease...and either that lease was long term....or if it did change every few seconds then there would have to be some sort of automatic registration scheme with some sort of out-of-band registry. In either case, it wouldn't be doing what I want...since I don't want my hosts accessible/addressable unless THEY initiate communications. If my hosts are registering with some sort of out of band service then I've just introduced another method of profiling my devices...unless that service has a really air-tight method of establishing trust relationships. If the leases are effectively semi-permanent then it doesn't sound much more obscure then DHCP....and would seam to have alot of the same overhead and drawbacks. It doesn't sound like a terrible solution...but I still don't see why I would prefer it over NAT. It sounds like it has many (though not all) of the same drawbacks as NAT, may miss some of the functionality NAT provides.... and doesn't sound like it has any less overhead or complications that implimenting ALG's in NAT. If NAT provides me exactly the functionality I want now....doesn't break any protocols/applications I want to use. The applications/protocols it breaks I ACTUALY WANT broken.... why would I want to switch to RISP instead? But thank you for the information on it....it was interesting regardless. Christopher Engel > -----Original Message----- > From: james woodyatt [mailto:[email protected]] > Sent: Friday, April 30, 2010 4:16 PM > To: Chris Engel > Cc: NAT66 HappyFunBall > Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"? > > > On Apr 30, 2010, at 13:26, Chris Engel wrote: > > > > You are not going to achieve that level of "obscurity" without some > > form of address translation.... > > That's not true. It can also be done with encapsulation. > RFC 3103 is an existence proof. > > > and any solution that you do provide to achieve that obscurity will > > have much of the same side effects that todays NAT does. > > Also not true. As RFC 3103 shows. > > > -- > > james woodyatt <[email protected]> > member of technical staff, communications engineering > > > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
