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

From: Tim Hartrick <[email-masked]>
Date: Wed, 1 Sep 1999 09:33:01 -0700 (PDT)

Erik,

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

I would say yes.  The scope-id (the interface index in your example) is really
part of the address.  For systems that use the same link token on all their
interfaces the ability to bind to a specific local address and get only
datagrams destined for that address is, in my opinion, essential.

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: Erik Nordmark <[email-masked]>
Date: Wed, 1 Sep 1999 20:16:27 -0700 (PDT)

> I would say yes.  The scope-id (the interface index in your example) is
> really part of the address.  For systems that use the same link token on all
> their interfaces the ability to bind to a specific local address and get only

Tim,
I'm not directly disagreeing with you but in general this is not
sufficient.
Certain applications might desire to only receive packets on one
interface while still being able to receive both unicast as well as
one or more multicast addresses.

Either the app can use N sockets each bound to a link local unicast/multicast
address with the appropriate scope-ip, or use single in6addr_any
socket and IPV6_RCVPKTINFO to throw away the undesired packets.

It seems like we are creating multiple mechanisms to do the same thing.
How do we gauge when we have enough mechanism?

  Erik