How can I create IPv6 over IPv4 UDP tunnelling network device driv

Discussion in 'Windows Vista Drivers' started by Seong Moon, Feb 22, 2007.

  1. Seong Moon

    Seong Moon Guest

    Hi !

    I'm finding the method how I can create and build network device driver
    of which major functions are encapsulation/decapsulation of IPv4(UDP) header
    on the IPv6 Packet.

    I've also looked into NDIS, miniport driver manual of the windows DDK.
    But I couldn't find useful infomation about the tunneling of IPv6 packets.

    Actually, my idea is follows

    <encapsulation>
    1. An application of IPv6 send a ipv6 packet to the network
    2. My miniport driver receives the sent packet
    3. My miniport driver encapsulate the IPv4(UDP) header on the packet
    4. My miniport driver sends the encapsulated packet through the IPv4
    Protocol Stack which passes the packet to the adaquate destination network
    adaptor automatically via routing table.

    <decapsulation>
    1. An IPv4(UDP) header encapped IPv6 packet arrives at the windows system
    2. IPv4 Protocol stack receives the packet. If the UDP port number of the
    received packet is the port bound to IPV6_OVER_IPV4_UDP, the packet is
    transferred to the my miniport driver's routine.
    3. My miniport driver decapsulate the IPv4(UDP) header.
    4. Then, My miniport driver transfer the packet to the IPv6 Protocol Stack.

    My question is as follows :
    1. In the process of encapsulation, How can my miniport driver send the
    encapped packet to the IPv4 Protocol Stack ?

    2. In the process of decapsultaion, How can I receive the packet from the
    IPv4 Protocol Stack ?

    3. In my project, Does the miniport driver the right solution ?

    4. I've looked over Teredo tunnel. It seems very similar with my project.
    But I can't see the driver source code of the Teredo. Could anyone give me a
    helpful advice ?

    Any comment, I'll appreciate.
     
    Seong Moon, Feb 22, 2007
    #1
    1. Advertisements

  2. Seong Moon

    Anton Bassov Guest

    First of all, it does not make any sense to write such driver for Vista,
    because Vista
    provides native support for IPv6. Therefore, I will make an assumption that
    your target OS is <= W2K3.
    Miniport driver is *NOT* the right solution here, because sending and
    receiving packets is done by their protocol drivers. Furthermore, the
    statement that "My miniport driver sends the encapsulated packet through the
    IPv4 Protocol Stack which passes the packet to the adaquate destination
    network adaptor automatically via routing table" is just ridiculous -
    miniport driver is at the very bottom of the network stack and protocol
    drivers are bound to it, so that it is protocol who sends data via miniport
    and not the other way around.


    What you need here is NDIS IM filter, which presents itself as protocol
    driver to miniport and as miniport one to protocols.
    When miniport drivers indicates incoming packets to protocols, your filter
    will be first to see them. Therefore, you will check all incoming packets,
    and if you see the one of interest, you will forward it to your client app
    (or driver -more on this below), without passing it up the stack
    As I told you already, it is protocol who sends data via miniport, and not
    the other way round. You have 2 options:

    1. Send it right from NDIS IM - it will receive outgoing data from the app,
    prepend
    UDP, IP and MAC headers, and forward it to the miniport. If you do it this
    way,
    you will have to translate destination IP address to the MAC one, and, in
    case if the target machine is multihomed, choose the right adapter to send it
    through. In other words, you will have to provide your own partial
    re-implementation of functionality, offered by TCPIP.SYS

    2. Write an additional client driver that deals with app, so that it is
    totally unaware of NDIS IM. When this client driver receives incoming data
    from NDIS IM, it will forward it to the app. When it receives outgoing data
    from the app, it will send the whole thing just IPv4 UDP packet via the TDI
    interface of TCPIP.SYS. If you do it this way, you will have no need to think
    about ARP and routing


    Anton Bassov
     
    Anton Bassov, Feb 22, 2007
    #2
    1. Advertisements

  3. network adaptor automatically via routing table" is just ridiculous -
    Nothing ridiculous, this is how PPTP works - a WAN miniport over raw IP.
     
    Maxim S. Shatskih, Feb 22, 2007
    #3
  4. Seong Moon

    Anton Bassov Guest

    Maxim,
    I think that in this context it is - if I got it right, the OP is unaware
    that such solution would require 2 independent stacks and that TCPIP.SYS
    cannot be bound to this miniport.

    Certainly, it does not really matter what underlying transport miniport
    driver actually relies upon - indeed, it can do everything via the IP.
    However, in such case
    you need a custom protocol driver that is bound to your virtual miniport on
    its lower edge, and deals with the client apps/drivers on its upper one. Your
    miniport will send and receive packets via TCPIP on its lower edge, and
    indicate them to
    your custom protocol driver on the upper one.

    However, using UDP is rather problematic here. First of all, communication
    have to be done on some certain UDP port, and there is no guarantee that it
    is not currently in use by some client. Furthermore, such solution hasa good
    chance to get into the conflict with FW/PF. Therefore, raw IP seems to be a
    better option.

    At this point a logical question arises - what is the reason to go for so
    complex solution if you can simply write TDI client that will send and
    receive IPv6 packets
    as IPv4 data????

    Anton Bassov
     
    Anton Bassov, Feb 23, 2007
    #4
  5. Nothing ridiculous, this is how PPTP works - a WAN miniport over raw IP.
    It can. The tunneling miniports are possible. They create the virtual adapters
    in the OS with IP addresses on them. The traffic of these virtual adapters can
    be sent to underlying TCP/IP or IPv6 stack using another adapters.

    This is just fine. This is how VPNs work.
    It can also indicate them _to TCPIP on the upper edge_.
     
    Maxim S. Shatskih, Feb 23, 2007
    #5
  6. Seong Moon

    Anton Bassov Guest

    Maxim,

    You have mentioned WAN miniport in your previous post as an example.
    However, TCPIP does not bind to it - instead, we have a separate TCPIP
    -WANARP protocol driver that is bound to WAN miniport.......


    Anton Bassov
     
    Anton Bassov, Feb 23, 2007
    #6
  7. Maxim,
    So what? One can write a tunneling miniport with TCPIP bound to it without
    WANARP+NDISWAN.
     
    Maxim S. Shatskih, Feb 23, 2007
    #7
  8. Seong Moon

    Anton Bassov Guest

    Maxim,
    Sure you can bind TCPIP to your tunnelling miniport.... The only thing I am
    not sure about is that this miniport may have TCPIP as its underlying
    transport on the lower edge - to be honest, it looks pretty much like the
    story about a bloke who pulled himself out of the swamp by his own hair.

    The only reason why I mentioned TCPIP -WANARP protocol driver is that MSFT had
    a reason to implement things this way. What is the reason (apart from code
    modularity, of course) to do things this way if, according to you, they could
    simply bind TCPIP to the tunneling miniport????

    I believe that there may be some details, private to TCPIP.SYS's
    implementation, that make the scheme that you have mentioned rather
    problematic. Once MSFT knows these datails, it chose to introduce a separate
    protocol driver....

    Let's see what the other guys say - probably, Thomas and Stephan will read
    this thread.....

    Anton Bassov
     
    Anton Bassov, Feb 24, 2007
    #8
  9. Hi,

    I've read through the debate between Anton and Maxim. I'll avoid jumping in
    and offer a solution that we've given our customers for similar tunneling
    projects. We use our DNE framework with a transparent proxy plugin. This is
    essentially an IM and you could write an IM to do something similar.

    In this case, your IM (like our transparent proxy DNE plugin) would capture
    all IPv6 packets, then redirect them to an application in user space which
    would in turn send them out over an IPV4 'tunnel'. You should definitely
    review the IETF standards for IPv6 over IPv4 (e.g. RFC 2529) at www.ietf.org.

    There are several methods you can use to redirect the V6 packets up to the
    tunneling application. Our customers typically either send them up through
    the stack and have the tunneling application listen on a pre-agreed port, or
    use IOCTLs.

    Alternatively, you could include a IPv4 subset in your IM (or as some of our
    customers do, in their DNE plugins). If your tunnel is private, you likely
    need only a subset of TCP/IP, so this isn't as bad as it sounds. Still, it
    is likely safer and easier to use the transparent proxy/redirector approach
    and use the MS stack for your TCP/IP support.

    Surprisingly, the overhead with the triple stack (V6 down, redirect to app,
    app to V4) traversal isn't much, though I suspect at very high data rates
    (>100Mbps) it might be a challenge on some processors.

    If you have further questions, feel free to contact me offline at
    .


    Steve
     
    Steve Jackowski, Feb 25, 2007
    #9
  10. Seong Moon

    Seong Moon Guest

    First of all, thanks a lot of your interest of my question.

    I couldn't understand exactly the debates of yours. While I'm reading your
    articles, I've felt that more explanation of my project will be helpful to
    everyone.
    Here, I wanna explain my project more details.

    1. Applications which uses ipv6 address
    I'm not assuming a special custom application. I'm thinking the major
    user of my driver is the general IPv6 application. So I'm not planing to
    write a custom application program on my project.

    2. Application which controls the tunnelling action.
    It can be written to interact with my device drivers

    3. the virtual adaptor
    Every IPv6 packets that the applications sent to the network will be
    arrived at my virtual adaptor. That is, the IPv6 default route would set as
    my virtual adaptor.

    4. writing custom protocol driver
    It seems to be very hard-work and bad soultion. I do "NOT" want to do that.

    5. IPv4 route information
    I'm not actually control the IPv4 route entries. In the multi-home
    environment, the IPv4 protocol stack(TCPIP.SYS) is responsible to determine
    that which packets will be transferred to which miniport adaptor. In other
    words, I do NOT want to do such determination on my device drivers or control
    application.

    6. the process of received packet
    The final goal of this is that the ipv6 application will be received the
    packet as if the packet is the original ipv6 packet.

    regards seong
     
    Seong Moon, Feb 25, 2007
    #10
  11. Seong Moon

    Seong Moon Guest

    I'm very interested in you suggest solution.
    So, what I understood is as follows. Is it right ?
    1. Sending : IPv6 applications send ipv6 packets ==> IM captures the ipv6
    packets ==> the ipv6 packets redirects to my control application ==> my
    control appliction sends the packet to the network through TCPIP.sys, which
    is resulted that the ipv6 packets are tunnelled with IPv4 (UDP) header.

    2. Receiving : IPv6 packet tunnel with IPv4(UDP) header is arrived at
    windows system. ==> My control application receives the packet because my
    control application has been bound the pre-agreed UDP port. ==> Then, my
    control application send the packet to the my IM device driver. ==> Then the
    IM indicates the arrival of IPv6 packet to the protocol drivers. ==> Then the
    IPv6 application receives the IPv6 packet.
    Could you explain more detail about the above methods ?
    What does that mean "send them up through the stack" and "have the
    tunnelling application listen on a pre-agreed port" and "or use IOCTLs" ?
    Actually, I'm a newbie on windows device driver. To success my project,
    Which chapters of which book should I learn in detail ?

    Followings are additional information of my project which is posted for the
    previous debates between Anton and Maxim. I think that is also helpful to
    you. So I attached that here.

    --------------------------------------------------------------

    Here, I wanna explain my project more details.

    1. Applications which uses ipv6 address
    I'm not assuming a special custom application. I'm thinking the major
    user of my driver is the general IPv6 application. So I'm not planing to
    write a custom application program on my project.

    2. Application which controls the tunnelling action.
    It can be written to interact with my device drivers

    3. the virtual adaptor
    Every IPv6 packets that the applications sent to the network will be
    arrived at my virtual adaptor. That is, the IPv6 default route would set as
    my virtual adaptor.

    4. writing custom protocol driver
    It seems to be very hard-work and bad soultion. I do "NOT" want to do that.

    5. IPv4 route information
    I'm not actually control the IPv4 route entries. In the multi-home
    environment, the IPv4 protocol stack(TCPIP.SYS) is responsible to determine
    that which packets will be transferred to which miniport adaptor. In other
    words, I do NOT want to do such determination on my device drivers or control
    application.

    6. the process of received packet
    The final goal of this is that the ipv6 application will be received the
    packet as if the packet is the original ipv6 packet.
     
    Seong Moon, Feb 25, 2007
    #11
  12. Seong Moon

    Anton Bassov Guest

    Steve,
    Actually, our debate is mainly of theoretical nature - we discuss whether it
    is possible to use TCPIP services *DIRECTLY* from miniport driver TCPIP is
    bound to,
    without introducing any additional "helper" drivers( additional network stack,
    TDI client that is technically unrelated to NDIS, etc). When it comes to the
    particular
    situation the OP has described, we both seem to agree that NDIS IM is a best
    option
    here.


    Concerning the solution that you have described, it seems to be a
    good one, although I would *probably* avoid using an app, and replace it
    with TDI client driver....

    Anton Bassov
     
    Anton Bassov, Feb 25, 2007
    #12
  13. Hi Anton,

    My reason for not suggesting a TDI driver (we have customers doing that as
    well as some of our other software that complements DNE) is for portability
    reasons. The claim to fame on our products is that if you follow our
    approach you don't have to worry about differences between OSs. Today our
    DNE framework supports everything from 95 through Vista 64-bit,
    WinCE/PocketPC/Mobile 5, Linux, Solaris, MacOS, HP-UX, etc). My primary
    concern with using TDI (which I agree is better than an application) is that
    it varies somewhat between Windows platforms, but even more importantly,
    Microsoft has announced they will be deprecating it in upcoming releases of
    Vista and Longhorn. To provide a future-proof solution, I suspect an
    application is the best route and since this particular OP has little Windows
    experience, is likely easier to implement.


    Steve
     
    Steve Jackowski, Feb 25, 2007
    #13
  14. Seong,

    If your interest is in a commercial application and you need assistance
    beyond what can be provided on this message board, please contact me directly
    at and we can help you with
    design/implementation of a solution. I've tried to answer your questions
    below.
    Yes. This is a good summary of my suggested approach.
    In Windows and most other operating systems, IOCTL is one method for
    communicating between user space and kernel space. On Windows, the IOCTL
    must be initiated in user space so moving large amounts of data between the
    two at high speeds can be challenging since the movement is driven by the
    application (and completed by the kernel driver). It's not terribly
    complicated, but unless it's well designed can be problematic.

    An alternative is to use the TCP stack to forward data back up. In this
    case, an application listens on one or more ports. The IM driver consumes
    packets, places an IP header on them or modifies the existing one (using
    out-of band (e.g. IOCTL) signalling to help identify flows), and sends the
    packet up as if it has received the packet from the network. The application
    receives the packet on the listening port and can then process it as it
    likes. In your case, it would open a raw socket and send the packet out.

    As for documentationis concerned, there's a lot of it on MSDN for
    Intermediate Miniports (IMs), device drivers, TDI, etc. A number of the
    posters on this forum have tutorials and products to help with development.
    However, unless you have a fair amount of Windows expertise, I suspect this
    will be a lengthy learning and debugging process.


    Steve
     
    Steve Jackowski, Feb 25, 2007
    #14
  15. Sure you can bind TCPIP to your tunnelling miniport.... The only thing I am
    Everything is OK. Just do not use the IP addresses of your own upper edge :)
    The reason for WANARP to exist? Very simple.

    MS decided to split the PPP protocol implementation in Windows to 2 binaries -
    WANARP and NDISWAN.

    WANARP's upper edge is custom ARP (IPRegisterArp). NDISWAN's lower edge talks
    to WAN miniports.

    The egde between the two uses fake Ethernet packets (with fake MAC addresses),
    and decompressed/decrypted PPP data.

    The reasons for this:
    a) allow PPP for protocols other then TCP/IP - IPX etc. WANARP is only for
    TCP/IP, NDISWAN is generic PPP.
    b) allow the _nearly unmodified Ethernet NDIS IMs_ to filter the PPP traffic.

    This split does not exist in Windows CE (at least 4.2), where you have a
    monolithic PPP.DLL, which custom ARP upper egde and lower egde talking to WAN
    miniports.

    So, on WinCE, it is very hard to filter PPP. Hooking the custom ARP's entry
    points is maybe the only solution.
     
    Maxim S. Shatskih, Feb 25, 2007
    #15
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.