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

From: Tim Hartrick <[email-masked]>
Date: Thu, 12 Aug 1999 12:31:52 -0700 (PDT)

Francis, Vladislav,

> 
>  In your previous mail you wrote:
> 
>    Section 2.1.2 [Page 9]
>    - The reviewers were questioning the need for the following definition:
>      490      struct in6_addr  ip6r0_addr[1];  /* up to 127 addresses */
>    
>    This definition made the ip6_rthdr0 structure stick out from all the others.
>    The suggestion is to remove this line and add a comment (just like all the
>    other header structures) that states that the Routing Header 0 is followed
>    by an array of IPv6 addresses.
>    
> => I agree. In fact you can have zero addresses in a routing header
> (not very useful if you are not tracking bug). I believe one'd like
> to have ip6r0_addr[0] but some compilers don't like that...
>

Removing this field seems like a win.
 
>    Section 2.2.1 [page 11]
>    - The following definition is no longer valid:
>      614     #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */
>    
>    It now refers to an address that is beyond the scope of source address as
>    defined in Section 3.1 of draft-ietf-ipngwg-icmp-v3-00.txt
>    The draft defines the code value 2 as "beyond scope of source address".
>    
> => I propose ICMP6_DST_UNREACH_BEYONDSCOPE
>

Sounds fine to me.
 
>    Section 5.1 [page 26]
>    - What is the precedence of sin6_scope_id relative to the interface
>    specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP
>    options?
> 
> => this is an important issue (one already found a code with conflicting
> IPV6_MULTICAST_IF, IPV6_PKTINFO and sin6_scope_id...)
>

I would say that a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF
option and that the interface indices in the IPV6_PKTINFO and IPV6_NEXTHOP
options override the sin6_scope_id.

The logic being that if the application goes to the trouble to specify a
scope identifier in the sockaddr_in6 it probably wants it to override a
previous setting of the IPV6_MULTICAST_IF option.

Likewise, if the application goes to the effort of building ancillary data
items (IPV6_PKTINFO and IPV6_NEXTHOP) it probably intends for the values
specified in the ancillary data to be authoritative.

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: Mon, 16 Aug 1999 19:51:06 +0900

>>>>> On Thu, 12 Aug 1999 12:31:52 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> specified in the ancillary data to be authoritative.

Basically agreed, but as for sin6_scope_id, I'd rather discuss a more
fundamental issue; its semantics.

RFC 2553 says about sin6_scope_id just as follows:

   The sin6_scope_id field is a 32-bit integer that identifies a set of
   interfaces as appropriate for the scope of the address carried in the
   sin6_addr field.  For a link scope sin6_addr sin6_scope_id would be
   an interface index.  For a site scope sin6_addr, sin6_scope_id would
   be a site identifier.  The mapping of sin6_scope_id to an interface
   or set of interfaces is left to implementation and future
   specifications on the subject of site identifiers.
   (section 3.3)

The description seems to me not enough specific to ensure
portability. For example, the followings are not clear:

- 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?

- 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?

- 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?
  Which value should the kernel set to sin6_scope_id when receiving
  from a global address?

- 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()?
  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()?

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
  bind system call

(possible)methods to specify the outgoing interface
  IPV6_PKTINFO cmsg type
  IPV6_PKTINFO setsockopt
  IPV6_NEXTHOP cmsg type
  IPV6_NEXTHOP setsockopt
  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.

Thanks,

					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]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Aug 1999 18:27:04 +0200

=> I interprete the specs as :
 - for link-local addresses and multicast addresses the sin6_scope_id
   is the index of the:
   * incoming interface on reception
   * outgoing interface on emission
 - for site-local addresses the sin6_scope_id should be a site number
   (something new, zero can be a real site number, ...) ???
 - for other sin6_scope_id has no meaning (ignore on emission, zero on
   reception)
As the sin6_scope_id is a local parameter it should be in host order.

   
=> 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?

=> yes

     Should we allow the kernel to set zero to the field even
     if the `from' address is link-local?
   
=> no

=> we are going to know what is a site... (:-)
It is on my plan to implement real multi-sited node one day
(I believe I know a solution for the kernel/API stuff but routing
daemon is still a problem, perhaps OSPFv6 (which is multi-process,
ie one can run an OSPFv6 process per site on the same router) can help?)

=> ignore the value which can be no more than a hint (ie if you have
multiple routes for the destination you should select the one via the
specified interface if there is one). If you can't say if it is an
interface index or a site identifier (are spaces separate?) you are
again in trouble (I have no multiple routes but this point should not
be a reason to never get that!)

=> zero (should not be the interface index because why not the site
identifier... the user doesn't need it and will ignore it).

=> multicast addresses are exactly like link-local addresses even
they have their own scope because a multicast destination without
the outgoing interface is incomplete.

=> sin6_scope_id in bind() should be for reception (ie. the socket
will not received packet from another interface).

=> argh! This is a real point and another case of precedence
(here between bind and connect/send/... sin6_scope_id).
I've just tried on my implementation: I consider sin6_scope_id has
a small precedence then connect() sin6_scope_id is overruled by
the bind() sin6_scope_id: packets (neighbor solicitations in fact)
are sent on the previous interface...

=> you have just added a new item in the precedence table (in fact
a new line without a value :-).

Thanks

[email-masked]

PS: *tentative* precedence table (according to what I believe to have coded):

source address: this can't be bound again when this is already bound.

outgoing interface:
IPV6_MULTICAST_IF < connect/send* < bind < full IPV6_PKTINFO

(IPV6_NEXTHOP is not yet implemented; I've written "full IPV6_PKTINFO"
because the address can be unspecified and/or the index zero.
There are two reasons for the highest precedence for IPV6_PKTINFO:
 - it is the first proposed way to solve the multi-homed/interface issue
 - it is the only way to specify the outgoing interface address in
   a send* system call (bind() needs a fresh socket each time)
An interface address is stronger than an interface index then IPV6_MULTICAST_IF
has the lowest precedence. It is a rationate for connect/send* < bind
even I've got this in my code by a side effect :-))

---

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

Sorry for the delayed response...

>>>>> On Mon, 16 Aug 1999 18:27:04 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> the outgoing interface is incomplete.

As I said in the previous response to Tim, this behavior resembles
KAME're behavior, and I agree that a multicast destination without
the outgoing interface is incomplete. However, does the behavior
prevent to support other scope than link-local? If we regard
sin6_scope_id as the outgoing i/f for any multicast destinations, how
do we specify, for example, the site identifier for a site-local scope
multicast address?

> will not received packet from another interface).

But the bound address uses as packets' source address sent via the
socket, doesn't it? Do you allow the packet to be sent on a different
interface than the interface to which the source address belongs?

> are sent on the previous interface...

The precedence seems fine for a TCP socket, but it would break the
link border...

> IPV6_MULTICAST_IF < connect/send* < bind < full IPV6_PKTINFO

Thanks for the tentative idea. It would be a good start point for
discussion.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Thu, 19 Aug 1999 15:09:39 +0200

However, does the behavior (the important thing for a multicast address
   is the outgoing interface) prevent to support other scope than link-local?
   If we regard sin6_scope_id as the outgoing i/f for any multicast
   destinations, how do we specify, for example, the site identifier for
   a site-local scope multicast address?
   
=> I have considered *-local scopes and multicast scopes are different
notions and to use the same identifier for site-local unicast and multicast
(ie. fuse them) is only simpler... But in general a site identifier does
not point to one interface then the site identifier is not enough even
for a site-local multicast address. IPV6_MULTICAST_IF argument is an
interface index and not a scope id.

   socket, doesn't it?

=> yes

   Do you allow the packet to be sent on a different interface
   than the interface to which the source address belongs?

=> the IPV6_PKTINFO will try to overwrite both the interface and the
source address then will fail: this is not allowed but is not a real
problem because bind() and IPV6_PKTINFO are alternatives.
   
Thanks

[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 21 Aug 1999 03:42:35 +0900

>>>>> On Thu, 19 Aug 1999 15:09:39 +0200, 

> for a site-local multicast address.

Hmm...maybe you're right. I'll reconsider the semantics of
sin6_scope_id for (any scope) multicast addresses.

> IPV6_MULTICAST_IF argument is an

Exactly. So I didn't mean IPV6_MULTICAST_IF, whose semantics is
clear. The problem is sin6_scope_id filed.

> => yes

OK, then...

> problem because bind() and IPV6_PKTINFO are alternatives.

I don't think so. First, a problematic situation could happen even
without IPV6_PKTINFO. For example, consider the following sample code.

struct sockaddr_in6 sa1, sa2;
sa1.sin6_scope_id = 1;
sa1.sin6_addr = fe80::1;
sa2.sin6_scope_id = 2;
sa2.sin6_addr = fe80::2;
bind(sa1);
sendto(sa2);

then, what should happen? In the above example, we don't use
IPV6_PKTINFO at all!

Secondly, I belive that bind() and IPV6_PKTINFO can coexist. What if
you call bind() then call sendmsg with IPV6_PKTINFO and if the interface
specified by sin6_scope_id of bind() contradicts the interface
specified by IPV6_PKTINFO?

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Aug 1999 13:37:24 +0200

> problem because bind() and IPV6_PKTINFO are alternatives.
   
=> I should have been more precise: IPV6_PKTINFO with a not-unspecified
address.

   
   
=> I've already recognized I have not taken into account the bind() then
send() case... Of course the document should give some guide-lines!

   Secondly, I believe that bind() and IPV6_PKTINFO can coexist. What if
   you call bind() then call sendmsg with IPV6_PKTINFO and if the interface
   specified by sin6_scope_id of bind() contradicts the interface
   specified by IPV6_PKTINFO?
   
=> I still believe it is and will be very seldom that both bind() and
IPV6_PKTINFO with an address will be used in a program but I think
this is not a good reason to forget to specify the precedence between
all the different ways to give the source address or/and the outgoing
interface.

Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 Aug 1999 13:59:44 -0700 (PDT)

> options override the sin6_scope_id.

For IPV6_NEXTHOP are you talking about an ifindex in a sockaddr_dl?
If so, will this override IPV6_PKTINFO or the other way around?

For IPV6_PKTINFO there might be a difference whether it is a sticky option
or in ancillary data.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 Aug 1999 14:22:59 -0700 (PDT)

Here are my personal opinions. Once I've gotten to the end of
this thread of email I'll try to figure out where the consensus is
heading.

>    [...]

Yes.

>   if the `from' address is link-local?

No. We want the application which does recvfrom + sendto
to work with link-local addresses on a multihomed system.
Thus if the source is link-local then recvfrom MUST return the ifindex
as sin6_scope_id.

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

I think it is as well-specified given the state of any notion
of "site identifiers".
Doing anything more requires at least something like the if_nametoindex
type functionality for site indentifiers, as well as some (node local)
name space for site identifiers.

>   Ignore the value? Or send the packet to the interface whose index is

Ignore or error sounds reasonable.

>   Which value should the kernel set to sin6_scope_id when receiving

Zero.

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

For link scope same as link-local.
For site scope same as site-local.
Don't know what to to do with the reserved values between those two.

>   sin6_scope_id passed to bind()?

Good question.
bind() conceptually specifies the local part of the address and not
where things are sent.

Thus it would make more sense to ask
	if you bind to link-local X with ifindex 2
will that reject packets sent to link-local address X which arrive on some
other interface?

  Erik