Text 34883, 202 rader
Skriven 2009-08-12 22:29:38 av Grant Taylor (108335.fidonews)
Kommentar till text 34880 av Michiel van der Vlist (2:280/5555)
Ärende: FidoNews 26:32 [02/05]: Rebuttals To Previous Articles
==============================================================
Re: FidoNews 26:32 [02/05]: Rebuttals To Previous Articles
By: Michiel van der Vlist to Grant Taylor on Thu Aug 13 2009 01:59 am
> Hello Grant,
Hi.
> 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.
I am considering the "helper application" to be any thing that performs any
action to help communications happen. If the helper application can operate on
the TCP/IP layer, great. If it has to operate much closer to the application
layer (OSI layer 7) so be it.
> 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,
*nod*
This is a form of an application layer proxy / gateway.
> 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.
Correct. That is the Host: header required in HTTP 1.1.
> 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,
As long as you are using an HTTP 1.1 complient browser, yes. If not, your
browser does not send the Host: header, you will not get the same results. ;)
> 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.
Agreed.
There is no reason why a SysOp can not run their own SSL IPv4 to IPv6 gateway
much like a reverse proxy pointing to thier own equipment.
> I doubt such a gateway is possibole for binkp as binkp does not include the
> url in the control information.
Why not?
There is nothing from preventing me from running a gateway that takes inbound
connections to its IPv6 address and passes them on to my IPv4 address. (Think
an HTTP reverse proxy.)
Granted, I don't think there will be public IPv4 to IPv6 gateways for things
like this. They will all have to be run by the SysOp that is running the IPv4
only software.
> There is no standard mapping between IPv4 and IPv6 addresses. No one to one
> mapping anyway.
Correct. Nor should there be. Just like there is no standard mapping from
private (internal) IPv4 addresses to public (external) IPv4 addresses. The
mapping is dependent on your existing public IPv4 address (space).
Similarly, it is my (mis)understanding that the IPv4 to IPv6 translation uses
something like the first 64 bits of your IPv6 address, something as filler
(that does not really matter) for the next 32 bits, and then your IPv4 address
as the last 32 bits of the 128 bit IPv6 address.
> 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.
There is no requirement that the IPv6 address contain an actual (encoded) IPv4
address. The lowerend of the address can really contain any thing you want.
There are really a couple of different possible translation that are happening:
1) IPv6 client talking to an IPv4 server.
2) IPv4 client talking to an IPv6 server.
The first method is more trivial to implement as it's really a form of reverse
proxying.
The second form is more difficult because you have to have something client
side in the communications path that translates the destination IPv4 address in
to an IPv6 address.
> In general there is no way to translate an IPv6 address to an IPv6 address
> and vice versa.
I think you meant IPv4 to an IPv6 (or vice versa), correct?
Per problem 1 above, I think it will actually be trivial to translate IPv6 to
IPv4 and back. Remember that NATs are translating from one IP to another
millions of packets a day. The scenario would be something like this:
1) Src6 -> Dst6
2) : Src4 -> Dst4
3) : Dst4 <- Src4
4) Dst6 <- Src6
":" is where the helper application would do its work. In this scenario, the
helper application would know that any traffic coming in to it's IPv6 address
to a given port needs to be resent from its IPv4 address to the internal IPv4
destination. Similarly when the helper application receives the reply from the
internal IPv4 source to its IPv4 destination it would look up the state of the
translation and retransmit the translated packet from its IPv6 source to the
remote IPv6 destination. This is in effect what NAT does for IPv4 and I see no
reason why such can't be done to translate simple protocols for IPv6 <-> IPv4.
> How?
Continuing with the above example, let's say we have these three systems, a
Client with an IPv6 address (::1), a Gateway with both IPv6 (::2) and IPv4 (.3)
addresses, and a Server with an IPv4 (.4) address.
Cv6 Gv6|Gv4 Sv4
::1 -> ::2 Client send IPv6 request to IPv6 gateway.
.3 -> .4 Gateway sends IPv4 request to IPv4 server.
.3 <- .4 Server sends IPv4 reply to IPv4 gateway.
::1 <- ::2 Gateway sends IPv6 reply to IPv6 client.
> Fidonet is not, but some FidoNet software is.
Yes. This FidoNet software is what I was referring to as the BBS. If you want
to call it something else for the sake of discussion, that's fine, just let me
know what to call it.
> 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.
Ok. That (telnet verses modem) makes sense to me.
For mailer to mailer, I think we simply will either need to use other kludges,
or a mailer that is IPv6 aware.
That or we need to use another Fido node as a higher level gateway in such as
it speaks IPv6 for the non-IPv6 aware application and then forwards it to the
non-IPv6 aware Fido node using some method that it does speak.
> Yes we could by adding IPv6 capability to Fidonet IP software.
*nod*
> 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.
Ok. Please forgive me for my BBS / FidoNet / FTN ignorance and use of the
wrong terms.
> I think it will not work.
I maintain that I think it can.
Even an IPv4 client talking to an IPv6 server can be translated (with a file
for looking up the IPv6 address based on a mach IPv4 address).
> 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...
I'm new enough to BBS / FidoNet / FTNs that I think so but I'm not sure.
> The older IPv4 only software needs an IPv4 address. Where does that come
> from if the ISP only supplies public IPv6 addresses?
This is the exact scenario that I was describing above where an IPv6 client is
trying to talk to an IPv4 (only) server connected to a provider that only hands
out IPv6 addresses.
> 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.
Eh... Blindly adding an AAAA record has some disadvantages. DNS clients /
servers will prefer to use an IPv6 AAAA record over an IPv4 A record. So care
must be taken to make sure that this does not break other things.
> But what good would it do if the software can only do IPv4?
This is what the IPv6 to IPv4 helper / translater / NAT is for.
> 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
--- SBBSecho 2.12-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)
|