netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Gatzka <stephan.gatzka@gmail.com>
To: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: netdev@vger.kernel.org, linux1394-devel@lists.sourceforge.net
Subject: Re: IPv6 over Firewire
Date: Sun, 23 Dec 2012 14:25:01 +0100	[thread overview]
Message-ID: <50D7062D.8040901@gmail.com> (raw)
In-Reply-To: <50D6F488.7060308@linux-ipv6.org>

>
> Please, please try best not to mangle packets
> and keep/make IPsec, SEND right.
>

O.k., a small excerpt from RFC 3146:
The Source/Target Link-layer Address option has the following form when 
the link layer is IEEE1394.
                          1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Length = 3   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                            ---+
    |                    node_unique_ID (EUI-64 identifier)         |
    +---                            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |    max_rec    |      spd      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          unicast_FIFO                         |
    +---                            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |            reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            reserved                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is what I _have_ to send to comply with RFC 3146. In the skb I get 
in the firewire net driver I have: Type, Length and node_unique_ID (the 
hardware address), all tail padded to a 8 byte boundary:

                          1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Length = 3   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                            ---+
    |                    node_unique_ID (EUI-64 identifier)         |
    +---                            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |    0x00     |      0x00       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          0x00000000                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So may aim is to rewrite the LL address option both while transmitting 
and receiving IPv6 data on firewire. While transmitting, I append the 
required information, while receiving I cut away the the firewire 
specific stuff. So the upper layers will not see the firewire related 
information. Yes, that mangling also involves recalculation of the 
ICMPv6 checksum.

Again, if I shall not mangle the ndisc packets in the driver I have to 
build RFC 3146 conformant packets in ndisc_build_skb(). But I see no 
(general) way to get the firewire specific information into the linux 
ndisc stuff. Of course I can add some if/else into 
ndisc_fill_addr_option() and ndisc_recv_na(). But then I have to pull a 
lot of firewire related stuff into the ndisc code.

I think this makes no sense, especially because I need that firewire 
specific information in the firewire net driver to send correct firewire 
packets. Besides that, the IPv4 portion of the firewire net drivers does 
exactly the same with ARP packets what I want to do with IPv6 LL address 
options.

Regards,

Stephan

  reply	other threads:[~2012-12-23 13:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 17:03 IPv6 over Firewire Stephan Gatzka
2012-12-21 17:53 ` YOSHIFUJI Hideaki
2012-12-21 18:39   ` Stephan Gatzka
2012-12-21 19:49     ` YOSHIFUJI Hideaki
2012-12-21 23:12       ` Stefan Richter
2012-12-22  6:03         ` Stephan Gatzka
2012-12-22  6:10       ` Stephan Gatzka
2012-12-22  9:15         ` Stefan Richter
2012-12-22 18:33           ` Stephan Gatzka
2012-12-23  8:23         ` YOSHIFUJI Hideaki
2012-12-23 11:13           ` Stephan Gatzka
2012-12-23 12:09             ` YOSHIFUJI Hideaki
2012-12-23 13:25               ` Stephan Gatzka [this message]
2012-12-23 17:09                 ` YOSHIFUJI Hideaki
2012-12-23 18:25                   ` Stephan Gatzka
2012-12-23 19:38                     ` YOSHIFUJI Hideaki
2012-12-23 23:52                     ` Stefan Richter
     [not found] <50EF1AEB.1080704@gmail.com>
     [not found] ` <50EFE095.2040505@linux-ipv6.org>
     [not found]   ` <50F10C53.4000803@gmail.com>
2013-01-12  8:27     ` IPv6 over firewire Stefan Richter
     [not found] ` <20130110210912.09c62d38@stein>
     [not found]   ` <50F10E94.9090302@gmail.com>
2013-01-12  9:24     ` Stefan Richter
2013-01-12 10:54       ` Stephan Gatzka
2013-01-12 13:57         ` Stefan Richter
2013-01-12 14:37         ` Stefan Richter
2013-01-12 14:42           ` Stephan Gatzka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50D7062D.8040901@gmail.com \
    --to=stephan.gatzka@gmail.com \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).