Text 34880, 199 rader
Skriven 2009-08-13 01:59:33 av Michiel van der Vlist (2:280/5555)
  Kommentar till text 34861 av Grant Taylor (108313.fidonews)
Ärende: FidoNews 26:32 [02/05]: Rebuttals To Previous Articles
==============================================================
Hello Grant,

On Tuesday August 11 2009 18:23, you wrote to me:

 >> I know of gateways that allow browsing IPv6 only websites over the IPv4
 >> network by Ipv4 clients. An example can be fond at
 >> http://ipv6gate.sixxs.net/ But those only work for one specific
 >> protocol, in this case http.

 GT> That gateway is a perfect example of an HTTP helper application.

Then I misunderstood what you meant by "helper programme". I was thinking of
something that runs on the system where the application runs. Something like a
fossil.

 GT> That gateway translates IPv4 HTTP traffic to IPv6 HTTP traffic.

Not exactly. What I gather is that the gateway downloads the content of the
target web site into its memory via an IPv6 connection and retransmits that to
the client via an IPv4 connection. It does not operate on the packet level, it
operates on the content level,

This is possible because the http protocol includes the url of the target in
its overhead. So the client does no have to know the IPv6 address of the
target. The gateway get it from the DNS system through the url.

If you go to www.vlist.eu you get the Dutch home page of my website. If you go
to www.vlist.org you get the English home page. Yet they both point to the same
IP number. But because you rweb browser send the url along with some other
information, my web server knows from the url which page you watn to see,

The IPv4 to IPv6 http gateway has its limitations. Note that there is no https
version of the gateway. I think there is a reason for that: no way to keep it
secure. In fact he gateway is a "man in the middle", it can see the content
that is exchanged. For a secure session you do not want that.

 GT> We would need a gateway that works for other protocols too.

I doubt such a gateway is possibole for binkp as binkp does not include the url
in the control information.

 >> The header contains the source and destination addresses. How do I
 >> translate an IPv4 address into an IPv6 address and vice versa? an
 >> Ipv4 address is 32 bits, an IPv6 address is 128 bits. Where does it
 >> ge the additional 96 bits of information from?

 GT> I personally do not know what the mapping is, but there are two or
 GT> three ways to map between IPv4 and IPv6 addresses, much like NAT maps
 GT> between different IPv4 addresses.

There is no standard mapping between IPv4 and IPv6 addresses. No one to one
mapping anyway.

 GT> It is my (mis)understanding that the translated IPv6 address includes
 GT> the IPv4 address and the remaining 96 bits are (partially) taken from
 GT> the IPv6 address of the gateway.

There is a block reserved in the IPv6 address space for representing IPv4
addresses in IPv6 format. The last 32 bit of that IPv6 address are the same as
the IPv4 address. But that is not how real life IPv6 addresses will look like.
There would be no point would there as there are no more of these mapped
addresses as there are IPv4 addresses. And those are running out.

In general there is no way to translate an IPv6 address to an IPv6 address and
vice versa.

 >> Take Irex for example. [...]  How can a helper application get the IPv6
 >> address if the application it is supposed to help simply does not have
 >> the information?

 GT> Irex will think that it is communicating with an IPv4 destination.

So far so good.

 GT> The helper application (proxy or IPv4 / IPv6 gateway) will take take
 GT> the IPv4 packet and tranlsate both the source and destination IPv4
 GT> addresses and map them to IPv6 addresses

How?

 GT> In this case, Irex does not have to know that it is really talking to
 GT> an IPv6 destnation (that may be converting from IPv6 to IPv4
 GT> internally).

 >> First, we should make the distinction between BBS's and FidoNet
 >> nodes. For Fidonet nodes, a Private Virtual network could work. It
 >> would put an extra strain on the coordinators, because they have to
 >> administrate the VPN as well, but that would be manageable. The
 >> solution is far from ideal, but it would probably work. And the
 >> article was about "FidoNet and IPv6" wasn't it?

 GT> Remember that FidoNet is not an IP(v4) aware application,

Fidonet is not, but some FidoNet software is.

 GT> we have used things like Telnet and BinkD to make it appear as such.

Telnet is a kludge to make sofware designed for dialup modems usable over the
Internet. It works on a character by charactert basis. That works reasonably
well for user-BBS interactions as that work on a character by character base as
well. For mailer to mailer it does not work that well because of timing
restraints. Binkp works much better as that protocol is tuned for use over
TCPIP.

 GT> This being the case, we can also make it appear to be an IPv6 aware
 GT> application,  at least for the FidoNet.

Yes we could by adding IPv6 capability to Fidonet IP software.

 GT> But I think we get in to a situation where we have to say what is
 GT> FidoNet? SysOps don't run FidoNet, they run BBS software that can
 GT> connect to FidoNet (or some other FTN).  So in effect we are really
 GT> talking about BBS software.  ;)

No. FidoNet sysops run FidoNet MAILERS. Some also run a BBS and some do not. (I
don't) Some software in use by Fidonet sysops have the mailer and the BBS
integrated in one package. But it is the MAILER that make it Fidonet, not the
BBS.

 GT> This brings us back to (part of) your original discussion about what
 GT> to do with software that can not be modified.  I think this is where
 GT> the helper applications (proxy or IPv4 / IPv6 gateway).

I think it will not work.

But then if we have to make use of the services of a third party to get mail
from A to B, we already have that build into FidoNet do we? It s called routed
mail...


 >> Yes, it probably would. But if the provider does not hand out a
 >> public IPv4 address any more, it is that or nothing. A BBS that
 >> does not have a public IPv4 address can not be reached by a user
 >> telnetting via IPv4 over the public Ipv4 network. Period.

 GT> If we have a way to allow older IPv4 software to run on IPv6 only
 GT> networks does it really hurt any thing if the providers only hand out
 GT> IPv6 addresses?

The older IPv4 only software needs an IPv4 address. Where does that come from
if the ISP only supplies public IPv6 addresses?

 GT> The problem that I see is we will need to populate an IPv4 to IPv6
 GT> translation table.  I.e. how to translate a.b.c.d to it's real IPv6
 GT> address.  This means that we now have an additional table to publis.
 GT> Or would it be possible to extend the nodelist to include the IPv6
 GT> address.

Adding the IPv6 address of the system would be no problem, there are several
ways to do that. Simplest is to add an AAAA record for the host name in the DSN
zone of the domain in question.

But what good would it do if the software can only do IPv4?

 >> Convincing the usesr to go IPv6 may not be the herdest part. Most
 >> OS in use by users are IPv6 capable and IPv6 capable Telnet clients
 >> are already available.

 GT> One of the biggest problems that I personally see with IPv6 is the
 GT> lack of ananimity in a network.  I.e. with out NAT (or some form of
 GT> proxy) every IPv6 server knows the difference between my notebook and
 GT> my girl friends computer and my printer.  This is something that I do
 GT> not want.

One way of assigning an IPv6 address to an interface it to use the subnet
identifier as provided by the ISP for the higher 64 bits and the MAC address
for the lower 64 bits. That allows easy autoconfiguration. But if you do it
that way, your laptop or PDA is uniquely identifiable no matter where you are.

But of you do not want that, there ar other ways. One way that some Window
versions do by default is to use a rndom number for the lower 64 bita and
change that from time to time. That way you canbe as anonymous as behind a NAt.

Other than that; "want" is irrelevant. Letting the cup of IPv6 pass by is not
an option. It is coming, no way to avoid it.

 >> Getting your favorite BBS software IPv6 capable may be the harder
 >> part. So what you propose may work. But it would make the sysop
 >> dependent on the sysop of the gateway system. FidoNet sysops in
 >> general do not like to be at the mercy of others... ;-)

 GT> I agree that the VPN gateway would require quite a bit of support.
 GT> However if the SysOp is the one that runs the IPv4 / IPv6 gateway at
 GT> the same place, possibly even on the same system,

That is not possible The gateway needs both a public IPv4 and an IPv6 address.
So it can not run on a line where only IPv6 addresses are available.

 GT> as the IPv4 only application, there is not such a dependency.  I.e.
 GT> IPv6 traffic would come in to the helper application which would then
 GT> proxy / translate to the IPv4 BBS (FidoNet).

If the IPv4 addy is not a public number, then we are back to my PVN...


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20070503
 * Origin: http://www.vlist.org (2:280/5555)