Subject: Re: Comments on 2292bis (Adv. API)

From: Tim Hartrick <[email-masked]>
Date: Mon, 16 Aug 1999 09:20:33 -0700 (PDT)

Jinmei,

> 
> - if we set a non-zero value to sin6_scope_id and a link-local unicast
>   address to sin6_addr, should the corresponding packet be sent on the
>   interface specified by the value of sin6_scope_id field?
>

Yes.
 
> - if we receive a packet via recvfrom(or recvmsg, or whatever) and
>   the from(i.e. source) address of the packet is a link-local address, 
>   should the sin6_scope_id field be set the index of the receiving
>   interface? Should we allow the kernel to set zero to the field even
>   if the `from' address is link-local?
>

It should always be interface index of the receiving interface.
   
> - as RFC says, the specification is ambiguous for site-local
>   addresses.
> 
> - if we set a non-zero value to sin6_scope_id and a global unicast
>   address to sin6_addr, what should the kernel do? Return an error?
>   Ignore the value? Or send the packet to the interface whose index is
>   the specified value?

I intend to ignore it since it is not meaningful global scope addresses,
multicast or unicast.

>   Which value should the kernel set to sin6_scope_id when receiving
>   from a global address?
>

Zero.

> - all the above questions are also applied for multicast addresses.
> 
> - suppose that  we set a non-zero value to sin6_scope_id, set a
>   link-local address to sin6_addr, and call bind() with the socket
>   address. When we try to send a packet to the socket, should the
>   kernel send the packet to the interface specified by the
>   sin6_scope_id passed to bind()?

Not unless the packet would otherwise have gone out that interface.

The source address selection in this case could be tricky.  I would say
that if the datagram is going to exit from the interface specified in the
bind then use the bound address as the source, otherwise use a source address
from the sending interface.
 
>   What if we try to send a packet specifying the destination
>   by a socket address whose sin6_addr is also link-local and whose
>   sin6_scope_id is a different value than the value set by bind()?
>

Then I would do the above.  That is, send the datagram out the interface
specified in the address of the sendto call and use the source address
associated with the sending interface.
 
> Even granted that the above points were clear, it would be also
> complicated to define preference among related ancillary data,
> setsockopt, and system calls.
> 
> So, as a starter, let me clarify the methods to specify the source
> address and to specify the outgoing interface:
> 
> (possible)methods to specify the source address
>   IPV6_PKTINFO cmsg type
>   IPV6_PKTINFO setsockopt

I may have misread the specification but I didn't think you could use the
IPV6_PKTINFO option in a setsockopt.

>   bind system call
> 
> (possible)methods to specify the outgoing interface
>   IPV6_PKTINFO cmsg type
>   IPV6_PKTINFO setsockopt
>   IPV6_NEXTHOP cmsg type
>   IPV6_NEXTHOP setsockopt

I thought that this was ancillary data only as well.

>   IPV6_MULTICAST_IF setsockopt
>   connect system call
>   sendto and sendmsg system calls
>   (bind system call - see above question -)
> (maybe I miss something)
> 
> Then we should discuss the preference among them. It's not so trivial
> for me, so I'd like to stop here and listen to other implementors.
> 

You are correct that it is quite complicated.  Many of these methods were
developed a while ago when we hadn't considered all the ramifications of
scoped addresses.  We probably still haven't considered all the ramifications.

Once I get the specification in front of me I will try and provide some
opinions on the above.

tim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 Aug 1999 17:53:59 +0900

Tim, thanks for the quick response.

I should've shown the current KAME's behavior about my questions. I'll
show the behavior in this response.

>>>>> On Mon, 16 Aug 1999 09:20:33 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> Yes.

Yes for KAME.

> It should always be interface index of the receiving interface.

Ditto for KAME.
   
>> - as RFC says, the specification is ambiguous for site-local

Currently, KAME scarecely supports site-local (unicast)
addresses. They are treated as global.

> I intend to ignore it since it is not meaningful global scope addresses,

Ditto for KAME.

> Zero.

Ditto for KAME.

>> - all the above questions are also applied for multicast addresses.

When sending, KAME always regards a non-zero sin6_scope_id as the
identifier of the outgoing interface in order to choose the source
address. However, the sin6_scope_id isn't used when sending the
packet...KAME always needs IPV6_MULTICAST_IF or IPV6_PKTINFO, which
may be wrong and corrected.

Also, it might be wrong to regards sin6_scope_id as the outgoing
interface id even for a non link-local multicast address, since we
can't handle other scope(e.g. site-local).

For receiving, KAME sets the identifier of the receiving
interface to sin6_scope_id field only for a link-local scope multicast
address. I admit that this asynchronousness is unnatural...

> Not unless the packet would otherwise have gone out that interface.

I'm sorry, but I can't understand this. Could you tell me the behavior
more concretely?

> associated with the sending interface.

Hmm...but is it right for a TCP socket? Do we have to use the bound
address as source for a TCP socket?

By the way, KAME's source address selection in this case is strange...
- for a UDP socket, use an address on the sending interface, which is
  different than the bound address.
- for a TCP socket, use the bound address.
- for a IPv6 raw socket...bind system call is failed. Yes, it's a bug.

> IPV6_PKTINFO option in a setsockopt.

Section 4 of 2292bis says as follows:

   This is done by defining socket option
   types which can be used both with setsockopt and with ancillary data.
   Ancillary data is discussed in Appendix A.  The following optional
   information can be exchanged between the application and the kernel:

       1.  The send/receive interface and source/destination address,
(snip)
   The three socket option parameters and the three cmsghdr fields that
   describe the options/ancillary data objects are summarized as:

       opt level/    optname/          optval/
       cmsg_level    cmsg_type         cmsg_data[]
       ------------  ------------      ------------------------
       IPPROTO_IPV6  IPV6_PKTINFO      in6_pktinfo structure

It seems to me that the text allows us to call setsockopt(IPV6_PKTINFO).

> scoped addresses.  We probably still haven't considered all the ramifications.

Yes, it would be tough to define proper preference...maybe we have too
many methods.

> Once I get the specification in front of me I will try and provide some

Thanks. We KAME team will also work on this and will post here the
result.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------