Subject: [Ipoverib] Question on IPv6 over IB

From: "Anand Parthasarathy" <[email-masked]>
Date: Thu, 13 Jan 2005 14:47:12 -0800

Hi, 
 
Section 9.3 of "Transmission of IP over Infiniband" draft states that:
           " 
            [DISC] specifies the length of source/target option in
            number of 8-octets as indicated by a length of '3' above.
            Since the IPoIB link-layer address is only 20-octet long,
            two octets of zero MUST be prepended to fill the total
            option length of 24 octets.
            ".
 
However, if you look at the linux ipv6 ndisc implementation, the pad is
"appended" to the 20-byte hardware address for infiniband and not
"prepended". Could someone comment on this?
 
Thanks,
Anand.
 
_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Roland Dreier <[email-masked]>
Date: Thu, 13 Jan 2005 15:35:11 -0800

Anand> However, if you look at the linux ipv6 ndisc
    Anand> implementation, the pad is "appended" to the 20-byte
    Anand> hardware address for infiniband and not "prepended". Could
    Anand> someone comment on this?
 
Yes, it seems the Linux stack assumes that all link address types
behave the same way as RFC 2464 IPv6-over-Ethernet, namely that
padding in the ndisc option comes at the end of the link address.  If
I'm reading the code in FreeBSD's nd6_ns_output() correctly, it makes
the same assumption.

It would seem to make the most sense to update the IPoIB draft to
state that link address padding goes at the end of the ndisc option.

 - Roland

---

From: Vivek Kashyap <[email-masked]>
Date: Thu, 13 Jan 2005 15:54:53 -0800 (PST)

> padding in the ndisc option comes at the end of the link address.  If

Isn't the length of the option already 8 when used on Ethernet (type+length+
48bit)? Then it wouldn't require the padding.

> state that link address padding goes at the end of the ndisc option.

Will it not align the local address at 2 byte boundary as against 4?

---

From: Roland Dreier <[email-masked]>
Date: Thu, 13 Jan 2005 16:32:55 -0800

Vivek> Isn't the length of the option already 8 when used on
    Vivek> Ethernet (type+length+ 48bit)? Then it wouldn't require the
    Vivek> padding.

Of course you are correct.  The 6 octet length of the ethernet address
confused me, sorry.

    Vivek> Will it not align the local address at 2 byte boundary as
    Vivek> against 4?

That's true.  It seems there is some precedent for putting the padding
at both ends: IPv6-over-ARCnet (RFC 2497) puts the (one octet!?) 
ARCnet address at the beginning of the option followed by 5 octects of
padding, while IPv6-over-Fibre Channel (RFC 3381) puts two octets of
padding at the beginning followed by 12 octets of address.

I will generate a patch for the Linux kernel to pad appropriately and
forward it to the networking maintainers.

Does anyone know what Solaris's IPoIB implementation does?

Thanks,
  Roland

---

From: "Anand Parthasarathy" <[email-masked]>
Date: Thu, 13 Jan 2005 16:57:22 -0800

Vivek & Roland,

It will be much easier to integrate into the Linux implementation if the pad
is after the MAC address of the net-device in the Source/Target Link-layer
address option as the net-device's mac address is directly used in
generating the IPv4 ARP packets and the Source Link-layer address option.

Thanks,
Anand.
-----Original Message-----
From: Roland Dreier [mailto:[email-masked]] 
Sent: Thursday, January 13, 2005 4:33 PM
To: Vivek Kashyap
Cc: Anand Parthasarathy; [email-masked]
Subject: Re: [Ipoverib] Question on IPv6 over IB

That's true.  It seems there is some precedent for putting the padding at
both ends: IPv6-over-ARCnet (RFC 2497) puts the (one octet!?) ARCnet address
at the beginning of the option followed by 5 octects of padding, while
IPv6-over-Fibre Channel (RFC 3381) puts two octets of padding at the
beginning followed by 12 octets of address.

Thanks,
  Roland

---

From: Roland Dreier <[email-masked]>
Date: Thu, 13 Jan 2005 17:02:51 -0800

Anand> It will be much easier to integrate into the Linux
    Anand> implementation if the pad is after the MAC address of the
    Anand> net-device in the Source/Target Link-layer address option
    Anand> as the net-device's mac address is directly used in
    Anand> generating the IPv4 ARP packets and the Source Link-layer
    Anand> address option.

We're only talking about IPv6, right?  IPv4 ARP packets have no
alignment requirements and thus no need for padding as far as I know.

For IPv6, I have already written a patch for net/ipv6/ndisc.c that
adds the padding before the link address.  It makes sense to make this
more generic because RFC 3381 already requires padding before the
address.  Unless we decide to modify the IPoIB draft it's no problem
to send this patch upstream.

 - Roland