RE: Transfer a sending packet to upper TCP/IP protocol layer in IM

Seong,

The proper way to do this is to add your IPv4 header, recompute the checksum
and send it out (down). If the IPv6 address can be resolved, and the route
is correct, then the gateway address is the same. If you're sending it out
through another Gateway or adapter, you'll need to arp for the correct
gateway or check the routing table.

Note that you may run into problems with MTU size since IPv6 packets with an
IPv4 header will be larger than the MTU. Then you have to handle
fragmentation and reassembly - along with sequencing, and you effectively
need a significant part of an IP stack implementation to do this. However if
the V4 tunnel is UDP, it's not too bad - perhaps you can adjust the V6 MTU to
account for the size increase to avoid fragmentation.

Note that injecting it up to the stack to handle all of this won't work. If
you keep the local IPv4 Source address, the stack will reject it. If you
change the source address, then because the stack is only routing, the
destination will have an invalid source address and you'll never get a
response.

My recommendation is to proceed with what I suggested in the other thread -
use an IM as a transparent redirector to a waiting application. Have that
application open one or more raw sockets to create the tunnel, then send the
redirected IPv6 packet over the tunnel/socket(s). This way, the stack
handles all the IPv4 work.


Steve

"Anton Bassov" wrote:

On one hand, you said the following:

My IM driver has a mapping table which consists of
> o. destination IPv6 address
> o. local IPv4 address
> o. remote IPv4 address
******
On another hand, you said the following:

The original MAC header is INVALID because my IM driver will assign a new
destination IPv4 address and the original MAC header was built for original
IPv6 destination IPv6 address.

Don't you see any logical contradiction between these 2 statements (I assume
you understand what MAC address is) ???

Once you have IPv6-to-IPv4 destination address mapping, it somehow implies
that
the actual destination NIC is the same for both IPv6 and IPv4 addresses
(actual source is the same for understandable reasons - it is just sender's
NIC). Therefore, no matter if you use IPv4 or IPv6, the *physical* route is
still the same, and, hence,
source and destination MAC addresses are the same for both IP versions.

Actually, how are you going to build IPv6-to-IPv4 address translation table
without
knowing MAC addresses ??? Has it ever occured to you to think that MAC
address is just a missing link between these two???

Anton Bassov

"Seong Moon" wrote:

In the sending procedure,
The original MAC header is INVALID because my IM driver will assign a new
destination IPv4 address and the original MAC header was built for original
IPv6 destination IPv6 address.

After prepending IPv4 header and UDP header to the original IPv6 packet, the
original MAC header is useless. That is the reason why I indicate the
encapped IPv4 packet up to the TCP/IP layer.

So, I can't agree with that you mentioned "forward the packet to miniport
with NdisSend()". Do I misunderstand ?

regards seong


"Anton Bassov" wrote:

As I told you already, you should NOT indicate outgoing packet to TCPIP.
Instead, you should just prepend UDP and IPv4 IP headers to IPv6 packet
without removing MAC header, then prepend MAC header to it (if we assume that
TCPIP has chosen the appropriate adapter, then source and destination MAC
addresses in the original MAC header are still valid), and then forward the
packet to miniport with NdisSend().
This is how you should deal with sends


When it comes to receives, you should detect IPv4 packet of interest, and
remove its
MAC, IPv4 and UDP headers. As a result, you will get exactly the same IPv6
packet (i.e. with its MAC, IPv4 and UDP headers) that was passed to your
NDIS IM on the sender machine, so that you just indicate this packet to NDIS

Anton Bassov

"Seong Moon" wrote:

Hi Anton!

I'm the one who posted the question about IPv6 over IPv4 UDP tunnel driver.

I'm now thinking the IM driver for my objective.

In the process of packet transmission, I have a following scenario.

1. IPv6 application sends a IPv6 packet.

2. The packet can be captured on my IM driver. The captured packet will be
as following
______________________________
| L2 header| IPv6 header | Payload |
------------------------------------------

3. My IM driver has a mapping table which consists of
o. destination IPv6 address
o. local IPv4 address
o. remote IPv4 address
o. local UDP Port number
o. remote UDP Port number
the above information should set correctly via the other control
application.

4. If the captured IPv6 packet on my IM driver has a destination IPv6
address which
has already configured on the above mapping table, the packet should be
proccessed as follows :
o. The IPv4 header and UDP header are prepended on the original IPv6
packet.
o. Of course, L2 header(e.g. MAC header) should be ignored.
o. So, the final packet will be the following format.
____________________________________________
| IPv4 header | UDP header | IPv6 header | Payload |
-------------------------------------------------------------

5. Now, I can indicate the encapsulated packet the the upper TCP/IP layer.
As result, I'd like to have the IP layer forward the IPv4 packet correctly.

6. As you mentioned, the MAC header should be processed correctly.
I'm not sure how I can process the MAC header. Any idea ?

Until here is my idea about the transmission of the tunneled packet.

I'll appreciate any comment.

regards seong

"Anton Bassov" wrote:

Can the TCP/IP driver foward the packet correctly ?

Forward to whom???? MiniportSendPackets() deals only with outgoing packets,
which means that packet' s source IP and MAC addresses are local and
destination ones are remote, i.e. the packet is outgoing one and TCPIP
already made its routing decision to send a packet via either underlying
adapter (if you speak about filter), or via your virtual miniport (if you
speak about MUX). If you want to change the adapter the packet gets sent
through, you have to call NdisSend() and, specify NDIS_HANDLE that
corresponds to that adapter ( apparently, it is a good idea to replace MAC
addresses in a packet's ARP header as well), rather than indicating it
to TCPIP as incoming one. Apparently, TCPIP is going to silently discard
your packet if you indicate it, and that's it......

If you want TCPIP to treat you packet as incoming one, you have to modify
both physical and logical transport addresses in the packet's headers.
However, if TCPIP
takes it for incoming one, why should it send it to any remote
address(unless logical IP address in the packet's header is remote and the
system is configured as a router)????

In other words, no matter what you do, you have to modify packet's headers
in such way that it conforms to the logic of the bound protocol...

Another option (at least in MUX) could be taking the whole packet simply as
data, and resubmitting it to TCPIP via its TDI interface, i.e. to act simply
as TCPIP's client

If you tell us a bit more about your objectives, probably, we will be able
to give you the most appropriate advice....

Anton Bassov




"Seong Moon" wrote:

Hi ! There !

I'm now designing Intermediate Driver for my project.

I'd like to transfer sending packet to the upper TCP/IP protocol layer on my
MiniportSendPackets function as if the packet is received from the NIC.
And I'd like to have IP protocol layer forward the transferred packet to the
adaquate adaptor.

Is it possible ?

That is, Can I call NdisMIndicateReceivePacket() in my MiniportSendPacket() ?
If that possible, Can the TCP/IP driver foward the packet correctly ?

Thanks in advance.
regards seong

.

Relevant Pages

  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... He's building a gateway across an IPV4 segment. ... AFAIK, all systems that support IPv6 provide this feature anyway, so that I ... the destination NIC of IPv6 packet is the same as the destination NIC of my ... was assuming that tcpip stack can rebuild the L2 header for the encapped IPv4 ...
    (microsoft.public.development.device.drivers)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... source and destination MAC addresses are the same for both IP versions. ... the destination NIC of IPv6 packet is the same as the destination NIC of my ... encapped IPv4 packet. ...
    (microsoft.public.development.device.drivers)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... If the IPv6 address can be resolved, ... When I indicate the packet to upper tcpip stack, I'll prepend IPv4 header ... The proper way to do this is to add your IPv4 header, ...
    (microsoft.public.development.device.drivers)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... The stack can route the IPv4 packets to the mapped ... encapped IPv4 packet. ... source and destination MAC addresses are the same for both IP versions. ... was assuming that tcpip stack can rebuild the L2 header for the encapped IPv4 ...
    (microsoft.public.development.device.drivers)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... destination IPv4 address and the original MAC header was built for original ... IPv6 destination IPv6 address. ... The original MAC header is INVALID because my IM driver will assign a new ... After prepending IPv4 header and UDP header to the original IPv6 packet, ...
    (microsoft.public.development.device.drivers)