Re: Ream-Specific IP (Was: IPv4)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I like Reaming much more the Realms.  Much more in the spirit of NAT :-)


On 8/6/07 9:16 AM, "Julien Laganier" <julien.IETF@xxxxxxxxxxx> wrote:

> On Friday 03 August 2007, Keith Moore wrote:
>>> NAT isn't the only answer to the question "I can't
>>> get IPv4 addresses, what do I do?" Using IPv6 and
>>> a proxy to reach the IPv4 world is much, much
>>> cleaner. And it also works from v4 to v6. We
>>> really should start advocating this as the
>>> preferred transition mechanism.
>> 
>> NAT and proxies are not mutually exclusive.  There
>> are advantages to having a proxy that can forward
>> TCP and UDP traffic from an outside address/port to
>> an inside address/port and vice versa; there are
>> also advantages to a NAT that can do the same thing
>> on a per-packet level. But a good, explicit protocol
>> and API for doing each would be welcome. It would
>> also be useful if the forwarder/NAT had explicit
>> means of communicating the "external" source and
>> destination address/port to the "internal" host -
>> say via the same control protocol used to establish
>> and maintain the address binding.
> 
> FWIW, there's a protocol that would give you the same
> functionality as a NAT while preserving end-to-end
> transparency of the network (i.e. IPv4 packets won't
> be modified between the internal host on the IPv6-only
> network and its IPv4 correspondent outside in the IPv4
> Internet). It would also let the internal host to know
> what address/port pair it was using to communicate,
> without change to the application.
> 
> That's Ream-Specific IP [RFC3102][RFC3103].
> 
>> That would make it relatively easy
>> to, say, have a server inside an IPv6-only network
>> establish presence on an IPv4 network provided by an
>> ISP, while still allowing the application to see the
>> real IPv4 source address (say for logging or spam
>> filtering).
> 
> Yes, that was pretty easy on an RSIP-enabled server on
> an IPv6-only network connected to the IPv4 world via
> an RSIP gateway, e.g. /etc/init.d/inetd start on the
> server!
> 
> Last but not least, provided that an IKE implementation
> would be modified to work hand-in-hand [RC3104] with
> RSIP, it would also be possible to support end-to-end
> IPv4 IPsec while one or both ends are on an IPv6 only
> network.
> 
> --julien
> 
> [RFC3102] Realm Specific IP: Framework
> [RFC3103] Realm Specific IP: Protocol Specification
> [RFC3104] RSIP Support for End-to-end IPsec
> 
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]