I'd like to come back to the concept of a realm and a possible
definition for "IPv6 realm".
Thanks Fred to point out on the aspect of "mutual reachability".
Question: If a realm is characterized by reachability, then I would
assume that an "IPv6 realm" would equate to an "IPv6 routing domain",
right?
A follow-up consideration:
There'll be "IPv6 islands" during the transition from V4-to-V6.
Such islands are per se single IPv6 routing domains ("and then perhaps
"IPv6 realms").
Thanks,
Albrecht
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Chris Engel
> Sent: Samstag, 1. Mai 2010 00:20
> To: 'james woodyatt'
> Cc: NAT66 HappyFunBall
> Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"?
>
> 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
>
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
